Зачем в 1С нужно периодически пересчитывать итоги по регистрам?

18.07.15

База данных - Инструменты администратора БД

Мы часто слышим рекомендацию о том, что пересчет итогов нужно проводить регулярно и эта операция проводит к улучшению производительности, но что скрывается за этой процедурой и какие именно проблемы решаются?

Попробуем разобраться...

Что такое итоги по регистрам?

Это агрегированные значения из таблицы движений регистров, которые используются для быстрого вычисления остатка или оборота по каким-либо измерениям. Хранятся они в отдельных таблицах.

Какие итоги бывают?

По умолчанию для регистров существуют итоги по месяцам и актуальные итоги (только для регистров остатков).
Почему "по умолчанию"? Потому что администратор базы может управлять наличием итогов с помощью методов "УстановитьИспользованиеИтогов" и "УстановитьИспользованиеТекущихИтогов".

Что происходит, когда документ записывает движения по регистру?

Представим, что проводим документ "Реализация товаров и услуг" в типовой УТ 10.3 с 1 строкой в табличной части задним числом за 01.01.2013, а дата расчета итогов - 28.02.2013. Во время проведения происходит запись регистра накопления "Товары на складах".
При этом в СУБД:
1) добавляется новая запись в таблицу движений регистра накопления
2) в таблице итогов происходит обновление актуальных итогов - из остатка на 01.11.3999 отнимается списанное количество.
3) если дата документа меньше крайней даты расчета итогов, то происходит обновление итогов по месяцам (причем столько раз, насколько месяцев дата документа меньше даты расчета итогов) - т.е. будут обновлены итоги на 01.02.2013 и 01.03.2013.
Итого в результате записи документа произошла модификация 4-х строк только по этому регистру.

И где проблема?

А проблема в том, что с течением времени в таблице итогов накапливаются записи с нулевыми значениями. Представим, что в предыдущем примере реализация полностью списала весь остаток товара на тот момент. Получается, что 2 итога по месяцам и актуальные итоги будут обнулены - сначала поступление добавило положительное значение в итоги, а реализация его обнулила. В виртуальных таблицах значение пропадет, но нулевые записи в физических таблицах остаются.

Посмотрим на таблицу итогов этого регистра в СУБД - получим по периодам общее число записей и число записей, для которых все ресурсы равны 0:

Получается, что мы имеем некое количество "мусорных" записей в итогах по месяцам и почти 30% "мусорных" записей в актуальных итогах.
А ведь актуальные итоги - это наиболее часто используемые данные для оперативно проводимых документов. И лишние строки в этом массиве данных приводят к замедлению выполнения запросов, т.е. документы проводятся дольше, больше риск возникновения блокировок.

Как исправить ситуацию?

Следует отметить, что делать это нужно регулярно. Частота проведения определяется в индивидуальном порядке в зависимости от интенсивности работы с базой.
Есть несколько вариантов.

Самый простой и очевидный - в конфигураторе запустить полный пересчет итогов. Минусы - если база большая, то этот процесс займет длительное время.

Другой вариант - запуск пересчет итогов средствами встроенного языка.
Например, для пересчета актуальных итогов (как наиболее важных с точки зрения оперативной работы пользователей) можно использовать следующий код:

Для каждого Рег из Метаданные.РегистрыНакопления Цикл

    Если
Рег.ВидРегистра = Метаданные.СвойстваОбъектов.ВидРегистраНакопления.Остатки Тогда

       
РегистрыНакопления[Рег.Имя].ПересчитатьТекущиеИтоги();

    КонецЕсли;

КонецЦикла;

Для каждого
Рег из Метаданные.РегистрыБухгалтерии Цикл

   
РегистрыБухгалтерии[Рег.Имя].ПересчитатьТекущиеИтоги();

КонецЦикла;

Если ваша база работает уже не один год и ее объем достаточно большой, то этот код выполниться на порядок быстрее полного пересчета итогов. Поэтому можно даже сделать этот код регламентным заданием и выполнять каждую ночь или на выходных.
Выполним эту процедуру и посмотрим в СУБД на ту же таблицу:

Видно, что в актуальных итогах (первая строка) нулевых записей больше нет.

Похожим образом выполняется пересчет итогов по месяцам.
Необходимо использовать метод "УстановитьПериодРассчитанныхИтогов()" - пересчитать можно, например, только несколько последних месяцев и не нагружать систему лишним пересчетом прошлых лет. 

В совсем запущенных случаях пересчет итогов только средствами 1С занимает очень много времени.

Фактически платформе 1С сначала надо очистить огромный объем записей в таблицах итогов, а потом заново их наполнить обновленными данными меньшего размера.
При этом платформа удаляет итоги помесячно с помощью DELETE. Соответственно, это требует много ресурсов и времени.
Сильно ускорить процесс можно путем предварительной очистки итогов в СУБД с помощью TRUNCATE TABLE.

Как один из вариантов:

1) отключаем всех пользователей и делаем бэкап базы средствами MSSQL;

2) генерируем запросы на очистку всех таблиц итогов по регистрам накопления:

В контексте базы данных выполняем запрос:

SELECT 'TRUNCATE TABLE ' + name FROM sys.tables
WHERE name like '_AccumRgT%'

Результат вывода копируем, вставляем в окно запроса и выполняем в контексте базы данных.

3) Запускаем пересчет итогов через Тестирование и исправление в Конфигураторе.

При таком подходе процесс займет существенно меньше времени, т.к. СУБД не будет тратить время на тяжелую операцию удаления старых записей.

 

Что еще следует помнить?

Пересчет итогов влияет на статистику - она становится не актуальной. Соответственно, после пересчета итогов вы можете получить не улучшение, а, наоборот, ухудшение производительности. Поэтому нужно не забывать запускать полное обновление статистики в СУБД и очистку процедурного кэша после проведения пересчета.

Пересчет итогов также приводит к практически 100% фрагментации индексов по таблицам итогов.
Для больших баз данных это может существенно сказываться на производительности.


Варианта решения этой проблемы два:

1) (долгий, но простой) - После пересчета итогов запускать реиндексацию таблиц из конфигуратора через "Тестирование и исправление".
Не запускайте одновременно пересчет итогов и реиндексацию, т.к. конфигуратор сначала перестроит индексы, а затем пересчитает итоги, т.е. таблицы итогов все равно будут фрагментированы. Необходимо выполнять эти операции раздельно.

2) (более быстрый, только для клиент-серверного варианта) - Воспользоваться одним из множества скриптов в интернете для перестроения только наиболее фрагментированных индексов.

 

UPD. Посмотрите также очень содержательный комментарий Алексея Лустина в этой теме (сообщение №58).

См. также

Автоподбор ролей для профилей и групп доступа в любых типовых базах 1С УТ 11, КА 2, ERP2, Розница 2/3, УНФ 16/3, БП 3, ЗУП 3 и подобных (УФ, Платформа 8.3.14+)

Инструменты администратора БД Роли и права 8.3.14 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Документооборот 1С:Зарплата и кадры государственного учреждения 3 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Платные (руб)

Роли… Вы тратите много времени и сил на подбор ролей среди около 2400 в ERP или 1500 в Рознице 2, пытаясь понять какими правами они обладают? Вы все время смотрите права в конфигураторе или отчетах чтоб создать нормальные профили доступа? Вы хотите наглядно видеть какие права дает профиль и редактировать все в простом виде? А может хотите просто указать подсистему и дать права на просмотр и добавление на объекты и не лезть в дебри прав и чтоб обработка сама подобрала нужные роли? Все это теперь стало возможно! Обновление от 15.12.2023, версия 1.1.

14400 руб.

06.12.2023    3478    18    1    

38

Infostart УДиФ: Управление данными и формами

Инструменты администратора БД Инструментарий разработчика Роли и права Платформа 1С v8.3 Конфигурации 1cv8 Россия Платные (руб)

Расширение позволяет без изменения кода конфигурации выполнять проверки при вводе данных, скрывать от пользователя недоступные ему данные, выполнять код в обработчиках. Не изменяет данные конфигурации, легко устанавливается практически на любую конфигурацию на управляемых формах.

10000 руб.

10.11.2023    4186    12    2    

36

SALE! %

PowerTools

Инструментарий разработчика Инструменты администратора БД Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Россия Платные (руб)

Универсальный инструмент программиста для администрирования конфигураций. Сборник наиболее часто используемых обработок под единым интерфейсом.

3600 2880 руб.

14.01.2013    178475    1083    0    

861

Ускоренное проведение документов (x4), устранение ошибок 60/62 счетов и зачет авансов (Бухгалтерия 3.0)

Закрытие периода Инструменты администратора БД Корректировка данных Бухгалтерский учет 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Платные (руб)

Расширение «Оперативное проведение» в 4 раза уменьшает время проведения документов и закрытия месяца. Является комплексным решением проблем 62 и 60 счетов. Оптимизирует проведение при включенной функциональной опции «Раздельный учет НДС». Используется в более 10 организациях уже 2 года. Совместимо с конфигурацией Бухгалтерия 3.0 (+КОРП).

14400 руб.

29.04.2020    27772    82    146    

60

Система хранения присоединенных файлов в томах на диске

Инструменты администратора БД Платформа 1С v8.3 1С:Комплексная автоматизация 1.х 1С:Управление производственным предприятием Платные (руб)

Конфигурация Комплексная автоматизация 1.1 (и УПП 1.3 тоже) хранит файлы и изображения в справочнике Хранилище дополнительной информации в реквизите Хранилище типа ХранилищеЗначений. Та же история с ВложениямиЭлектроннойПочты. Но при этом присоединенные файлы в Электронном документообороте хранит в томах на диске. Эта доработка позволяет использовать стандартный механизм хранения файлов, изображений и вложений электронных писем в томах на диске. При этом можно разделить тома хранения по объектам конфигурации.

4200 руб.

10.11.2015    61486    89    59    

74

"Менеджер потоков 2.1": УПП: "Восстановление партий"

Инструменты администратора БД Платформа 1С v8.3 1С:Управление производственным предприятием Россия Бухгалтерский учет Управленческий учет Платные (руб)

Как оптимизировать то, что, считалось, не поддается оптимизации? Как повысить доступность базы данных? Как проводить самую «времяемкую» операцию не по паре раз в неделю, а по несколько раз в день*? Ответ есть!

20000 руб.

12.09.2019    11833    5    9    

7

Хранилище файлов на SQL

Инструменты администратора БД Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Управленческий учет Платные (руб)

Привязка файлов / сканов к объектам 1С с сохранением их на SQL-сервере

12000 руб.

09.10.2019    11133    5    8    

9

Конфигурация Session Monitor

Мониторинг Инструменты администратора БД Платформа 1С v8.3 Россия Платные (руб)

Конфигурация Session Monitor предназначена для мониторинга сервера 1С с целью отслеживания чрезмерной нагрузки от конкретных сеансов и скорости реакции рабочих процессов.

1500 руб.

01.12.2020    14346    33    0    

48
Отзывы
58. lustin 17.03.13 01:24 Сейчас в теме
(46) а разработчики платформы тут не причем, это довольно известное архитектурное решение, не удалять "нулевые" записи. Я бы даже сказал что это давняя "священная война".

Тут самое главное понять что запись с нулевым количеством в итоге, совершенно не означает что эта запись не нужна.

При проектировании реляционных СУБД считается (считалось) что операции CRUD (Create, Read, Update, Delete) по затратам ресурсов распределяются следующим образом

1. Легкие: Read, Update
2. Средние: Create
3. Тяжелая: Delete

И исходя из логики поведения объекта Регистр, который меняется часто; и из-за больших затрат на удаление записей, существует позиция что:

запись итога не имеет смысла удалять синхронно в момент возникновения нулевого итога, потому что "ноль" не означает "NULL" и потому что велика вероятность того что следующая транзакция "захочет" увеличить или уменьшить итог и он станет ненулевым и нам необходимо будет понести затраты еще и на операцию вставки.

отсюда и посыл, что записи с нулевым итогом имеет смысл удалять асинхронно, то есть в определенный момент времени - но опять же неизвестно как определить этот самый "определенный момент". Такое определение должно лежать на ответственных за приложение - чаще всего как мы знаем пересчет итогов возникает в один момент времени при закрытии периодов учета и подается как некая подготовительная процедура. Вот тут и кроется проблема о которой давно известно - бизнес-задача Закрытие периода не является задачей обеспечения технической стабильности и бизнес иногда может на неё "забить".
У меня в практике была таблица с 400 миллионами записей с нулевым итогом.

И вот тут я могу сказать что разработчики платформы слегка "недочлись" (от слова "недочет") - дело в том что согласно вышеописанному архитектурному решению явно становится понятно, что:

Удалять записи с нулевым итогом нужно по тем ключам (комплектам измерений), по которым длительное время не было операций UPDATE. А этого функционала в платформе нет - есть только глобальный пересчет. В крупных конторах это решается SQL Job'ом выполняющем примерно следующую работу:

1. найти 1 комплект ключей (измерений) по которому не было движений за последний месяц и которые на данный момент нулевые
2. по данному комплекту измерений удалить запись из таблицы итогов

обычно данный Job запускается раз в 10 секунд, выбирается TOP 1 чтобы уменьшить время блокировки на затратную операцию удаления. Естественно в такие базы уже встроены и планы обслуживания по пересчету статистики и перестроению дефрагментированных индексов. В случаях когда таких "ненужных" записей очень много - то обычно уменьшают период запуска Job, либо отказываются от Регистра Итогов - потому что если у вас много ключей уходит в "ноль" и больше не используется, скорее всего у вас по данным ключам 2 операции движения "пришел" и "ушел" - зачем хранить такую информацию в регистре итогов совершенно не ясно.

Ну и про статистику тут тоже все изъезжено - масcовые операции CREATE И DELETE, а также UPDATE ключевого столбца ведут к нарушению дерева поиска по индексу (диапазона распределений ключа по страницам данных) - ну то есть в поисковом диапазоне 1..10 вполне себе может оказаться ключ со значением 23 - так SQL было удобней, потому страница данных была рядом со страницей ключа 7, а ключ 6 заместо которого встал ключ 23 окажется в диапазоне 100..134 - что тоже было удобней исходя из страниц данных. Пример на пальцах - но думаю суть отражает.

Вообще про статистику в момент массовых операций удобно понять следующее: когда вы делается массовую вставку данных SQL пытается вам помочь и оперирует близостью страниц данных для оптимизации вставки и совершенно забывает про оптимизацию операций чтения, где параметром является статистика (диапазоны поиска ключа в таблице - распределение ключа), поэтому чтобы после массовых вставок операции чтения были тоже быстрыми - необходимо восстановить работоспособность инструмента оптимизации чтения выполнив UPDATE STATS.

---

Да и еще забыл сказать - массовое удаление ведет к массовому возникновению фантомных записей: запись числится удаленной но место занимает - такая ситуация ведет к снижению производительности операций выборок типа SCAN (просмотр).
Roootru; zykininho; wildhog; Восьмой; AndrewVVS; Rick148; YuriOvs; Merkalov; Alex_vk; alekslis; JohnConnor; purgin; Soloist; 1C_Lab; criptid; kievanton; Anna_arbuz; Skif1989; vlasin; СаморезикРу; tyazhovkin; zfilin; legenda-nsh; Михаська; e.kogan; logarifm; arabesca; Shmell; marzhinator; Cat43r; lamaker9876; ДимокШ; =Kollega=; user1232315; A_Max; Kinestetik; Созинов; AndreySchel; Rans; vatkir; rudak_a; Ганс; Anikrion; Albert_2008; Niberu; ser6702; MarchTomCat; olezhe; user598655_ilia-bers; klaus38; LordKim; lmnlmn; spenser123; Monte Carlo; acanta; zaharknyaz; Aggressorak; vesd; SnegIL; Waanneek; SkyJack; letarch; aegoncharov; user777757; alexey.shesterikov@bk.ru; mytg; Gang031; ice-net; Goga1979; ChessCat; Pavel_Vladivostok; 1cprogr_nsk; Irwin; Paradise.87; KAV2; корум; Roman100; for_questions; ragimi; EugeneMIPT; kai nk; kitaevay; crosby; Noxie41; Alex_grem; nixel; new_user; tdml; NeviD; RimidalV; reboot; denis_aka_wolf; Flashill; marchenko.y; freya-khv; asg.aleks; denis13; adm67; TIS_08; mtv:); soulsteps; shalimski; Anesk; pisarevEV; Silenser; kwazi; engineer74; vadimlp77; Артано; dgolovanov; pchela751; aexeel; artbear; jif; Dmitryiv; RomanMartynenko; slavap; WizaXxX; IvanBoychuk123; fishca; Evil Beaver; Dach; RodinMax; sanches; mdmdvd; zakakvo; Krio2; jacksonp; adeich; afedor; MaximStav; DoctorRoza; Serg0FFan; sanfoto; kinazarov; Bukaska; theshadowco; oitnur; JesteR; detec; audion; laeg; morok1983; krv2k; Di-dog; sparklemal; awa; KAPACEB.AA; Chif13; sa1m0nn; CratosX; AllexSoft; galich; vlad.frost; igordynets; tormozit; vasiliy_b; vladir; meuses; Poopkeen; Andreynikus; Prad2002; dicwork; JohnyDeath; An-Aleksey; It-developer; rgrisha; Bronislav; 7o2uYXg; HolodZar; адуырщдв; AzagTot; Рамзес; DenisCh; PONOM; rеd80; w-divin; metmetmet; CheBurator; PressaLod; Diversus; sevushka; Aleksey.Bochkov; yuraos; +184 Ответить
Остальные комментарии
Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. yuraos 991 11.03.13 06:22 Сейчас в теме
Прочитал заголовок,
подумал что очередной пересказ "желтых методичек"
но был приятно удивлен
глубоким знанием автором архитектуры базы данных 1С.
Izumov; any__uta; SagittariusA; alexovik; user811769; user777757; kolya_tlt; dj_serega; dzhenn; trdm; +10 Ответить
2. yuraos 991 11.03.13 06:31 Сейчас в теме
(1)
наверное стоит отметить в публикации,
что картинки с результатами запросов
сделаны в SQL Server Management Studio
для клиент-серверной базы данных.
--
Возможно кому-то будет интересно,
запросы к итогам из статьи можно также сделать
в обработке "Консоль запросов 1С + ADO"
так же в консоли можно выполнить код на языке 1С для пересчета итогов.
3. PowerBoy 3363 11.03.13 07:06 Сейчас в теме
Автор мог еще упомянуть про разделение итогов и их свертку при пересчете, что тоже положительно влияет на производительность.
Waanneek; marchenko.y; +2 Ответить
4. yuraos 991 11.03.13 08:07 Сейчас в теме
(3) PowerBoy,
можно также упомянуть про регламентное задание в типовых конфигурациях
выполняющих пересчет итогов.

В УПП-1.2 например крутится регламентное задание "ПересчетИтоговРегистровНакопления",
выполняющее следующий код:

Процедура ПересчетИтоговРегистров() Экспорт
		
	НаДату = НачалоМесяца(ТекущаяДата())-1;	
	ПересчетРегистров(РегистрыНакопления, НаДату, Метаданные.СвойстваОбъектов.ВидРегистраНакопления.Остатки);
	ПересчетРегистров(РегистрыБухгалтерии, НаДату);	

КонецПроцедуры

Процедура ПересчетРегистров(МенеджерРегистров, НаДату, ОграничениеПоВидуРегистра = Неопределено)
	
	Для Каждого МенеджерРегистра ИЗ МенеджерРегистров Цикл
		МетаданныеРегистра = Метаданные.НайтиПоТипу(ТипЗнч(МенеджерРегистра));
		
		Если ОграничениеПоВидуРегистра <> Неопределено И МетаданныеРегистра.ВидРегистра <> ОграничениеПоВидуРегистра Тогда
			Продолжить;
		КонецЕсли;
		ПересчитатьРегистрПоДате(МенеджерРегистра, НаДату);
		
	КонецЦикла;
	
КонецПроцедуры


Процедура ПересчитатьРегистрПоДате(МенеджерРегистра, НаДату)
	
	Если МенеджерРегистра.ПолучитьПериодРассчитанныхИтогов()<НаДату Тогда
		МенеджерРегистра.УстановитьПериодРассчитанныхИтогов(НаДату);
	Иначе
		МенеджерРегистра.ПересчитатьИтоги();
	КонецЕсли;
	
КонецПроцедуры

Показать
AndreySchel; user1194547; ksewa!; mgor; anderson; w-divin; Redokov; +7 Ответить
7. Aleksey.Bochkov 3661 11.03.13 12:32 Сейчас в теме
(3), спасибо, забыл про этот момент. Дополню как будет время.
(6), регламентные задания в СУБД - изъезженная тема, подробной информации в сети много.
5. adhocprog 1139 11.03.13 12:11 Сейчас в теме
6. fomix 33 11.03.13 12:28 Сейчас в теме
Весьма полезная статья. Еще бы подробнее про полное обновление статистики в СУБД и очистку процедурного кэша после проведения пересчета.
15. Aleksey.Bochkov 3661 11.03.13 18:37 Сейчас в теме
26. ksai 12.03.13 09:42 Сейчас в теме
27. fomix 33 12.03.13 09:54 Сейчас в теме
8. Yashazz 4721 11.03.13 12:54 Сейчас в теме
Да, про разделение итогов было бы хорошо.
И ещё, лучше всё-таки писать так: "Если рег.ВидРегистра=Метаданные.СвойстваОбъектов.ВидРегистраНакопления.Остатки Тогда...", а не через СокрЛП
AndrewVVS; cleaner_it; marchenko.y; Bukaska; catena; Aleksey.Bochkov; +6 Ответить
14. Aleksey.Bochkov 3661 11.03.13 18:34 Сейчас в теме
(8) Yashazz, а я последние годы периодически ломал голову - что же за переменная отвечает за тип регистра :).
Все время хотелось написать "Если рег.ВидРегистра=ВидРегистраНакопления.Остатки ..", а, оказывается, надо было через Метаданные.
Спасибо!
user811769; +1 Ответить
16. yuraos 991 11.03.13 18:43 Сейчас в теме
(14) Семен Семенович!
А как можно ищо?
Heinrich2906; +1 Ответить
17. Aleksey.Bochkov 3661 11.03.13 18:46 Сейчас в теме
(16) Ну не зря же существует фраза "Век живи, век учись!" :)
user811769; marchenko.y; +2 Ответить
9. melenaspb 208 11.03.13 14:31 Сейчас в теме
Поэтому нужно не забывать запускать полное обновление статистики в СУБД и очистку процедурного кэша после проведения пересчета.

А про это можно подробнее?
10. antik69 11.03.13 14:52 Сейчас в теме
Спасибо за статью. К регламентной операции пересчета итогов добавилось понимание того как и на что этот пересчет влияет.
11. gr0ck 11.03.13 16:17 Сейчас в теме
Статья была бы лучше, если бы уж все разом изложили, и про разделение, и про пересчет итогов, полностью от А до Я. А так, т что отражено, отражено понятным языком, с картинками, за это спасибо!
user777757; +1 Ответить
12. ksai 11.03.13 16:54 Сейчас в теме
Поэтому нужно не забывать запускать полное обновление статистики в СУБД и очистку процедурного кэша после проведения пересчета.

А про это можно подробнее?


Присоединяюсь к вопросу
13. DenisCh 11.03.13 17:09 Сейчас в теме
Статья хорошая.
Хотя для себя ничего нового не вынес..
Присоединяюсь к замечанию о разделении итогов.

Плюс поставил.
user777757; +1 Ответить
18. metmetmet 81 11.03.13 23:10 Сейчас в теме
Спасибо автору, хорошая статья, добавила понимания работы итоговых таблиц на уровне СУБД.

Возник вопрос, а почему в процедуре пересчета текущих итогов используются строки

РегистрНакопления.УстановитьИспользованиеТекущихИтогов(Ложь);
РегистрНакопления.УстановитьИспользованиеТекущихИтогов(Истина);

вместо
РегистрНакопления.ПересчитатьТекущиеИтоги();


?

И еще вопрос: есть количественные оценки в росте производительности в связи с избавлением от "нулевых" строк?
19. Gilev.Vyacheslav 1910 12.03.13 00:51 Сейчас в теме
поставил плюс за "нулевые записи" - проблема старая, но от этого актуальность она не потеряла
20. sanches 256 12.03.13 07:46 Сейчас в теме
Спасибо, а что-нибудь для 77 и 2000 SQL можете посоветовать? Наверняка там такая же ситуация.
marchenko.y; +1 Ответить
23. DenisCh 12.03.13 08:55 Сейчас в теме
(20) sanches, для 77 верны те же утверждения. Только там не так удобно регистры считать. Нужно или ТИИ в конфигураторе делать, или ТА двигать. Всё - в монопольном режиме.
Но я обходился и простым удалением нулевых записей через sql.

По поводу прироста - если такая операция давно не делалась, то прирост ощутим (количественно не скажу). Если её делать каждый месяц... То явного прироста не будет.
24. sanches 256 12.03.13 09:04 Сейчас в теме
(23) DenisCh, спасибо. ТИИ не подойдет, поскольку база большая , больше 30Гиг, работают каждый день. Думаю, средствами SQl придется решать проблему.
25. DenisCh 12.03.13 09:21 Сейчас в теме
(24) sanches, Ну, это не проблема :-)
Запрос по выявлению пишется по метаданным за 5 минут.
На удаление - ещё 3...
28. yuraos 991 12.03.13 18:23 Сейчас в теме
(20)(23)(24)
sanches,
вот здеся есть много вякой вкуснятины для 1С-77
правда требуется ВК 1cpp.dll
--
в том числе обработка "Установка ТА", которая:
позволяет переустанавливать ТА,
расчитывая итоги регистров прямыми запросами 1с++
Позволяет также:
- пересчитать итоги по указанным регистрам (остатков и оборотов);
- все действия можно проводить в разделенном режиме (устанавливается блокировка);
- каждый месяц открывать за вас новый период, не выгоняя срочно всех из базы;
Vortigaunt; lustin; Зеленоград; Bukaska; sanches; +5 Ответить
29. sanches 256 12.03.13 18:38 Сейчас в теме
(28) yuraos, Спасибо! Посмотрю
30. CheBurator 3119 12.03.13 18:48 Сейчас в теме
33. yuraos 991 12.03.13 19:03 Сейчас в теме
(30) CheBurator, да не работает,
там запросы писать надо по другому и
желательно прирулить какие-нибудь примочки, чтобы
прямые запросы в dbf в монопольном режиме работали.
:)
...
но клиент просил

Спасибо, а что-нибудь для 77 и 2000 SQL можете посоветовать? Наверняка там такая же ситуация.
36. CheBurator 3119 12.03.13 19:16 Сейчас в теме
(33) прямые запросы в дбф в монопольном режиме чтобы работали - это уже вроде как давно есть такая возможность
39. yuraos 991 13.03.13 05:55 Сейчас в теме
(36)
а не кто и не говорит что эти примочки к 1С
для монопольного режима какая-то новость
(разве что субъективно :) ).
--
просто их надо будет прикручивать,
если захочется что бы прямые запросы в dbf
работали в монопольном режиме.
97. Bukaska 140 10.04.13 15:16 Сейчас в теме
(28) yuraos,
Спасибо за ссылки)))
(34) yuraos,
Чтобы таблицы итогов не опухли бы, для этого есть в бухучете инструмент: Закрытие месяца, закрытие года
А без этого было бы вообще жесть..

за статью ставлю однозначно "+", так как меня давно интересовал такой вопрос, для чего закрывать месяц, год, что будет... Теперь ясно что к чему)))
21. mcher 12.03.13 07:59 Сейчас в теме
Автору спасибо за статью. Всегда были вопросы по этой теме, теперь все более ли менее ясно.
22. kasper076 102 12.03.13 08:28 Сейчас в теме
Почему код 1С вставлен, как картинка? Есть же теги для оформления кода.
31. CheBurator 3119 12.03.13 18:50 Сейчас в теме
Коллеги, а поясните неграмотному.
Если при расчетах задним числом. модифицируются промежуточные и актуальные итоги. и вдруг получается в итогах ноль. Итог - это по сути куча. Куча - всегда итог правильный, например нулевой. Почему тупо скулем не удалить нулевые итоги...?????
32. Aleksey.Bochkov 3661 12.03.13 19:00 Сейчас в теме
(31) CheBurator, можно и напрямую в СУБД удалить. Лично я бы так и делал, но для массового применения такую рекомендацию никогда не дам.
Waanneek; +1 Ответить
35. CheBurator 3119 12.03.13 19:16 Сейчас в теме
(32) хм.. а почему..? скуль же вроде сам все разложит/проиндексирует..?
37. Aleksey.Bochkov 3661 12.03.13 19:22 Сейчас в теме
(35) с точки зрения техники все отлично - хоть руками удаляйте своими запросами, хоть методами встроенного языка - эффект будет один и тот же. Но для написания прямых запросов к базе, модифицирующих данные, нужны прямые руки и понимание смысла, а похвастаться этим могут не все :).
Heinrich2906; Waanneek; +2 Ответить
34. yuraos 991 12.03.13 19:07 Сейчас в теме
(31)
а платформа сама не удаляет эти нулевые записи?
иначе бы таблицы итогов пухли бы ...
ну может не так, когда по измерениям расходняк в движениях делается
но пухли бы точно.
38. Diversus 2310 12.03.13 22:14 Сейчас в теме
(0) Интересно, а нет ли у кого скрипта на SQL, чтобы удалил лишние нулевые значения?
Да и быстрее это дело было бы...
45. maxpiter 147 13.03.13 12:13 Сейчас в теме
40. maldinitaly 13.03.13 10:47 Сейчас в теме
Спасибо, огромное автору за статью.Все четко и понятно.Плюс
41. maxpiter 147 13.03.13 10:55 Сейчас в теме
albochkov, т.е. вы хотите сказать, что можно просто удалить в регистре остатков все нулевые значения?
Правильно ли я понимаю, что в регистре остатков нулевых значений в принципе не должно быть, а 0 это ошибка в логике пересчета регистров?

p.s. Я сам про это думал и как-то даже на тестовой удалял (SQL запросом), но на рабочую перенести так и не решился, хотя никаких отклонений в работе системы выявлено не было.
46. Aleksey.Bochkov 3661 13.03.13 12:32 Сейчас в теме
(41) - удалить нулевые записи нужно не в регистре остатков, а таблице итогов регистра остатков. Появление нулевых записей - это нормальная работа системы и не является ошибкой. Конечно, было бы хорошо, если бы платформа сама проверяла наличие нулей после окончания проведения документов и удаляла их, то это требовало бы дополнительных затрат ресурсов. Но это лишь предположение - разработчикам платформы видней почему так сделано.
49. maxpiter 147 13.03.13 12:48 Сейчас в теме
(46) именно это я и хотел выразить, видимо не совсем ясно донес мысль :)
Удалить нулевые записи в таблицах промежуточных итогов.
58. lustin 17.03.13 01:24 Сейчас в теме
(46) а разработчики платформы тут не причем, это довольно известное архитектурное решение, не удалять "нулевые" записи. Я бы даже сказал что это давняя "священная война".

Тут самое главное понять что запись с нулевым количеством в итоге, совершенно не означает что эта запись не нужна.

При проектировании реляционных СУБД считается (считалось) что операции CRUD (Create, Read, Update, Delete) по затратам ресурсов распределяются следующим образом

1. Легкие: Read, Update
2. Средние: Create
3. Тяжелая: Delete

И исходя из логики поведения объекта Регистр, который меняется часто; и из-за больших затрат на удаление записей, существует позиция что:

запись итога не имеет смысла удалять синхронно в момент возникновения нулевого итога, потому что "ноль" не означает "NULL" и потому что велика вероятность того что следующая транзакция "захочет" увеличить или уменьшить итог и он станет ненулевым и нам необходимо будет понести затраты еще и на операцию вставки.

отсюда и посыл, что записи с нулевым итогом имеет смысл удалять асинхронно, то есть в определенный момент времени - но опять же неизвестно как определить этот самый "определенный момент". Такое определение должно лежать на ответственных за приложение - чаще всего как мы знаем пересчет итогов возникает в один момент времени при закрытии периодов учета и подается как некая подготовительная процедура. Вот тут и кроется проблема о которой давно известно - бизнес-задача Закрытие периода не является задачей обеспечения технической стабильности и бизнес иногда может на неё "забить".
У меня в практике была таблица с 400 миллионами записей с нулевым итогом.

И вот тут я могу сказать что разработчики платформы слегка "недочлись" (от слова "недочет") - дело в том что согласно вышеописанному архитектурному решению явно становится понятно, что:

Удалять записи с нулевым итогом нужно по тем ключам (комплектам измерений), по которым длительное время не было операций UPDATE. А этого функционала в платформе нет - есть только глобальный пересчет. В крупных конторах это решается SQL Job'ом выполняющем примерно следующую работу:

1. найти 1 комплект ключей (измерений) по которому не было движений за последний месяц и которые на данный момент нулевые
2. по данному комплекту измерений удалить запись из таблицы итогов

обычно данный Job запускается раз в 10 секунд, выбирается TOP 1 чтобы уменьшить время блокировки на затратную операцию удаления. Естественно в такие базы уже встроены и планы обслуживания по пересчету статистики и перестроению дефрагментированных индексов. В случаях когда таких "ненужных" записей очень много - то обычно уменьшают период запуска Job, либо отказываются от Регистра Итогов - потому что если у вас много ключей уходит в "ноль" и больше не используется, скорее всего у вас по данным ключам 2 операции движения "пришел" и "ушел" - зачем хранить такую информацию в регистре итогов совершенно не ясно.

Ну и про статистику тут тоже все изъезжено - масcовые операции CREATE И DELETE, а также UPDATE ключевого столбца ведут к нарушению дерева поиска по индексу (диапазона распределений ключа по страницам данных) - ну то есть в поисковом диапазоне 1..10 вполне себе может оказаться ключ со значением 23 - так SQL было удобней, потому страница данных была рядом со страницей ключа 7, а ключ 6 заместо которого встал ключ 23 окажется в диапазоне 100..134 - что тоже было удобней исходя из страниц данных. Пример на пальцах - но думаю суть отражает.

Вообще про статистику в момент массовых операций удобно понять следующее: когда вы делается массовую вставку данных SQL пытается вам помочь и оперирует близостью страниц данных для оптимизации вставки и совершенно забывает про оптимизацию операций чтения, где параметром является статистика (диапазоны поиска ключа в таблице - распределение ключа), поэтому чтобы после массовых вставок операции чтения были тоже быстрыми - необходимо восстановить работоспособность инструмента оптимизации чтения выполнив UPDATE STATS.

---

Да и еще забыл сказать - массовое удаление ведет к массовому возникновению фантомных записей: запись числится удаленной но место занимает - такая ситуация ведет к снижению производительности операций выборок типа SCAN (просмотр).
Roootru; zykininho; wildhog; Восьмой; AndrewVVS; Rick148; YuriOvs; Merkalov; Alex_vk; alekslis; JohnConnor; purgin; Soloist; 1C_Lab; criptid; kievanton; Anna_arbuz; Skif1989; vlasin; СаморезикРу; tyazhovkin; zfilin; legenda-nsh; Михаська; e.kogan; logarifm; arabesca; Shmell; marzhinator; Cat43r; lamaker9876; ДимокШ; =Kollega=; user1232315; A_Max; Kinestetik; Созинов; AndreySchel; Rans; vatkir; rudak_a; Ганс; Anikrion; Albert_2008; Niberu; ser6702; MarchTomCat; olezhe; user598655_ilia-bers; klaus38; LordKim; lmnlmn; spenser123; Monte Carlo; acanta; zaharknyaz; Aggressorak; vesd; SnegIL; Waanneek; SkyJack; letarch; aegoncharov; user777757; alexey.shesterikov@bk.ru; mytg; Gang031; ice-net; Goga1979; ChessCat; Pavel_Vladivostok; 1cprogr_nsk; Irwin; Paradise.87; KAV2; корум; Roman100; for_questions; ragimi; EugeneMIPT; kai nk; kitaevay; crosby; Noxie41; Alex_grem; nixel; new_user; tdml; NeviD; RimidalV; reboot; denis_aka_wolf; Flashill; marchenko.y; freya-khv; asg.aleks; denis13; adm67; TIS_08; mtv:); soulsteps; shalimski; Anesk; pisarevEV; Silenser; kwazi; engineer74; vadimlp77; Артано; dgolovanov; pchela751; aexeel; artbear; jif; Dmitryiv; RomanMartynenko; slavap; WizaXxX; IvanBoychuk123; fishca; Evil Beaver; Dach; RodinMax; sanches; mdmdvd; zakakvo; Krio2; jacksonp; adeich; afedor; MaximStav; DoctorRoza; Serg0FFan; sanfoto; kinazarov; Bukaska; theshadowco; oitnur; JesteR; detec; audion; laeg; morok1983; krv2k; Di-dog; sparklemal; awa; KAPACEB.AA; Chif13; sa1m0nn; CratosX; AllexSoft; galich; vlad.frost; igordynets; tormozit; vasiliy_b; vladir; meuses; Poopkeen; Andreynikus; Prad2002; dicwork; JohnyDeath; An-Aleksey; It-developer; rgrisha; Bronislav; 7o2uYXg; HolodZar; адуырщдв; AzagTot; Рамзес; DenisCh; PONOM; rеd80; w-divin; metmetmet; CheBurator; PressaLod; Diversus; sevushka; Aleksey.Bochkov; yuraos; +184 Ответить
79. rеd80 23.03.13 04:34 Сейчас в теме
(58) lustin, Даже не знаю что полезнее, статья или комментарий...
user1998342; Anna_arbuz; Skif1989; bav_itritm; tka4enk0; user753293; klaus38; Fargoth; +8 Ответить
80. lustin 23.03.13 05:02 Сейчас в теме
(79) rеd80, я бы в комплексе рассматривал. Тем более что Алексей Бочков скорее всего тоже в курсе того что я написал. Как сказал Вячеслав - проблема известная, но на данный момент так спокойно и коротко на Инфостарте (да и в тырнете) не описана - Алексей собственно и сделал такую статью.

Меня же зацепило "разработчикам платформы виднее" ;-).
82. Aleksey.Bochkov 3661 23.03.13 11:41 Сейчас в теме
(80) - Алексей, поясню эту фразу :)
1) Все-таки, решение проблемы с нулевыми записями на уровне платформы не такое тривиальное, есть разные варианты и везде есть плюсы и минусы. Вряд ли можно угодить всем. А переложить ответственность за чистку итогов на конечного пользователя системы - в принципе, хороший вариант.
2) Стараюсь быть осторожен в формулировках относительно работы фирмы 1С. Уже несколько раз попадал на цензуру и замечания с их стороны. А в немилость впасть не хочется :).
87. CheBurator 3119 25.03.13 03:20 Сейчас в теме
В принципе, не для десятковогигабайтных баз можно тупо почистить нулевые строки для всех периодов (м.б. за исключением последнего предшествующего текущему) как описал Лустин в (58), если вдруг окажется что нужных итогов нет - ну понесет платформа платформа при проведении допзатраты на их создание - но понесет эти допзатраты для одной номенклатуры один раз. А затраты на регулярное чтение при оставлении отчетов и обращения к итогам при обильном наличии пустых записей могут быть больше/чаще..? (рассуждаю применительно к файловым клюшкам)
128. lustin 24.05.16 11:34 Сейчас в теме
Подниму тему в связи с актуальностью в части PostgreSQL
Итак - для PostgreSQL и статья и комментарий (58) также действуют в полном объеме.

Поэтому тем кто будет читать эту статью и комментарии напомню, что правильный подход к исправлению выглядит следующим образом (в не зависимости от сервера СУБД)

0. Если вы вдруг обнаружили что у вас много нулевых записях в таблице итогов
1. садитесь совместно группой - ключевой пользователь системы 1С, ведущий разработчик системы 1С, DBA системы (или тот кто считает себя таковым)
2. договариваетесь о том когда у бизнес-пользователя происходят фиксация бизнес-результатов по регистрам накопления - для УТ это обычно неделя, для БП - месяц и т.д. Это время называем "Время Ч"
3. ведущий разработчик реализует регламентную очистку "за день до сдачи финансовых результатов" - то есть "Время Ч минус 1 рабочий день" назовем это "время X"
3.1 крайне желательно фиксировать в журнал регистрации количество записей до очистки, и после очистки - то есть "было 1 миллион, стало 100 тысяч"
4. DBA запускает регламентные операции "по приведению в порядок базы после массового удаления" - запускает он это в технологическое окно после "Времени X"
4.1 крайне желательно фиксировать результаты приведения в порядок базы - по крайне мере в простых текстовые файлики.

через 6 регламентных запусков по очистке регистров - группа встречается и смотрит результаты по очистке.

5. регистры сокращающиеся при очистке на 80% и более - регистры на гарантированный рефакторинг:
5.1 потому как "регистры накопления" должны накапливать данные, они же не "регистры ежедневного обнуления" - скорее всего это регистры сведений
5.2 потому как такие регистры скорее всего означают незнания функционала типовых конфигураций - скорее всего функционал бизнес-пользователями связанных регистраторов таких регистров используются не по назначению


Еще раз напомню - что платформа 1С тут не причем: нулевые записи - в 90% случаев вопрос к бизнес-пользователям системы и прикладникам
A_Max; Kinestetik; Rans; CratosX; Krio2; LordKim; zaharknyaz; Waanneek; Aleksey.Bochkov; support; charushkin; DimaP; +12 Ответить
151. G_117966775639297348820 25.03.24 13:37 Сейчас в теме
(58)
При проектировании реляционных СУБД считается (считалось) что операции CRUD (Create, Read, Update, Delete) по затратам ресурсов распределяются следующим образом

1. Легкие: Read, Update
2. Средние: Create
3. Тяжелая: Delete

Операция Update никогда не считалась в реляционных СУБД легкой по затратам ресурсов как и Delete
Это самы тяжелые операции, где помимо поиска самой записи требуется обеспечить возможность отката/возврата измененного блока, а так же журнала повтора.
Проектировщики-диверсанты какие-то...
(58)
42. rassylka-new@yandex.ru 13.03.13 11:11 Сейчас в теме
Все просто прекрасно с технической стороны, просто здорово и весело, НО какой эффект это дает в реальных боевых условиях (я сейчас не говорю про теоретические аспекты а-ля лишние ресурсы участвующие в блокировках)? Есть какие-нибудь статистические данные хоть у кого-нибудь?
44. maxpiter 147 13.03.13 11:50 Сейчас в теме
(42) у меня вышло, что для таблиц:
РезервыТМЦ, доля нулевых записей на таблицу составила 53%
ПланыПродаж, 23%
остальные регистры не более 5%
47. Aleksey.Bochkov 3661 13.03.13 12:36 Сейчас в теме
(42) - конкретный пример, побудивший написать статью - база УТ 10.3, года 3 не пересчитывали итоги, база небольшая - около 40 Гб чистых данных. В результате в актуальных итогах только по регистру партий 300 тысяч записей, из них 290 тысяч - нулевые. Длительность проведения одной реализации - 2,9 с.
После пересчета итогов производительность упала - 5,1 с. на 1 реализацию.
После обновления статистики - 0,9 с. на 1 реализацию.
Примерно трехкратный прирост.
Но каждая ситуация индивидуальна.
VyacheslavShilov; Shmell; Coderfather; A_Max; 1yh1; +5 Ответить
51. rassylka-new@yandex.ru 13.03.13 13:51 Сейчас в теме
(47) Впечатляющий прирост. Спасибо!
95. Mudrii_Gankster 10.04.13 14:14 Сейчас в теме
(47) А объем БД уменьшился? В моей БД происходит регламентная дефрагментация индексов, пересчета статистики, но пересчета итогов к сожалению делаю не так часто. Попробую сделать и проверить на результат проведения базы, давность данных 8 лет.

P.S. дописанная УТ 10.2
96. Aleksey.Bochkov 3661 10.04.13 14:25 Сейчас в теме
(95) - да, чистый объем информации в базе уменьшился процентов на 20%. Но это совсем уж запущенный случай :).
147. Heinrich2906 06.08.22 09:47 Сейчас в теме
(47)
Уважаемый автор, для меня "упала" = стала хуже, а Вы как бы намекаете, что это прекрасно.
148. Gilev.Vyacheslav 1910 06.08.22 15:29 Сейчас в теме
(147) - статье 9 лет
- автор указал длительность в секундах
- чего вам сделал Алексей, что вы ему всякую хрень приписываете
43. Kopman 23 13.03.13 11:32 Сейчас в теме
Спасибо за статью..
сделал генератор скрипта для проверки таблиц итогов, основываясь на запросах автора статьи.
http://infostart.ru/public/177538/
48. Diversus 2310 13.03.13 12:36 Сейчас в теме
(0) (45)

Можно проверить, что будет если удалить все нулевые записи в регистрах в 8-ке:

сделать две тестовые базы, копии рабочей
- в одной удалить все нулевые записи SQL-скриптом
- в другой сделать пересчет регистров штатными средствами платформы

Потом запросом сравнивать по два регистра из этих двух баз что получается и где есть различия.
Если различий нет, то можно смело использовать в повседневной жизни, если есть станет ясно что делать дальше и какие записи не удалять...
50. skyp 36 13.03.13 13:51 Сейчас в теме
Большое спасибо за статью!
Очень информативно, кратко и действенно. Очень качественное дополнение к ЖКК.
52. пользователь 13.03.13 17:48
Сообщение было скрыто модератором.
...
53. Kopman 23 14.03.13 07:24 Сейчас в теме
Заметил в базе следующую ситуацию, таблицы итогов по нескольким регистрам содержат 1-2 нулевых записей начиная с 2201-02-01 00:00:00.000 и смещение 2000(т.е щас 4013-03..) получаются даты совершенно нереальные.
Простыми расчетами выходит, что там периодов итогов 1812*12=21744 штук. Умножив это на число нулевых записей в каждом периоде можно сильно удивиться:-)
54. l-Rain 14.03.13 10:50 Сейчас в теме
55. пользователь 15.03.13 14:16
56. Ibrogim 1313 15.03.13 14:32 Сейчас в теме
+
из остатка на 01.11.3999 отнимается списанное количество.
Найдут потомки таблицы 1С и будут думать, что мы предсказали конец света 1 ноября 3999 года
CheBurator; QueenBagira; savauu; EugeneMIPT; CratosX; slavikss; корум; Artem-B; Fatov_DI; bulpi; Keu2; bandru; nv_suvorova90@mail.ru; ixijixi; DenisCh; recon; +16 Ответить
57. TrinitronOTV 14 16.03.13 08:39 Сейчас в теме
Спасибо за статью. Много нового почерпнул для себя
59. pulpik 106 19.03.13 13:59 Сейчас в теме
Всем добрый день. Благодарю автора за статью. Прояснила нашу ситуацию.
БД - SQL 11 Gb
Это бухгалтерия за один год.
Выявились проблемы при формировании отчета Обороты счета за год по 20 счету по 3 субконто + подразделения.
за 1 кв отчет Формируется в течении 20 секунд
за 2 квартала 8 минут
за три и четыре квартала отчет не формируется...

после пересчета итогов за четыре квартала формируется в течении 2 минут.
Это ответ на вопросы по реальному приросту после пересчета итогов.

В ЗиУП тоже самое... при чем за месяц формировался отчет по разному от 15 минут до 45 минут... сейчас в пределах 15 секунд.

Так что я думаю что там еще есть кое что с дефрагментацией БД.
Спасибо.
61. headMade 144 19.03.13 20:21 Сейчас в теме
(59) pulpik,
а в ЗУПе за счет чего такой выйгрыш?
Насколько я понял это больше актуально для регистров расчета накопления (поправьте если ошибаюсь), а в ЗУПе они не так (наверное) интенсивно используются. Или всеравно это дало такой прирост?


И еще возник вопрос: пересчет итогов также актуален и для файлового варианта? (или это все важно для клиент-серверном варианте работы).

Спасибо.
62. Aleksey.Bochkov 3661 19.03.13 22:09 Сейчас в теме
(61) - файловый вариант - это тоже работа с СУБД, с теми же табличками и алгоритмами. Просто СУБД встроена в 1С. Соответственно, пересчет итогов для файлового варианта также актуален.
60. пользователь 19.03.13 14:01
Сообщение было скрыто модератором.
...
63. pulpik 106 20.03.13 00:24 Сейчас в теме
в ЗиУП работаем уже пять лет, итоги не пересчитывал, никогда не было проблем, но последние пол года диагностировалась проблема с отчетами по регистрам расчетов. Не знаю с чем связано - у них я понимаю нет нулевых ресурсов в виртуальных таблицах, но после пересчета время отчетов сократилось с 15-40 и более до 2-4 минут. (все применимо к клиент серверной архитектуре.)
64. LexSeIch 210 20.03.13 05:25 Сейчас в теме
Мир этому дому!
Хорошая добротная статья. Спасибо автору за детальное освещение вопроса.
65. kurvik 20.03.13 10:17 Сейчас в теме
Спасибо за статью. Добавилось понимание того как и на что пересчет итогов влияет.
66. Yackov 98 20.03.13 11:12 Сейчас в теме
Спрошу на всякий случай:) Если я делаю реиндексацию через конфигуратор, нужно ли запускать ее на sql (или это одно и тоже)?
68. CheBurator 3119 20.03.13 21:40 Сейчас в теме
(66) хм.. наскольо мне помнится в скульном варианте базы нет доступа к реиндексации...
70. Aleksey.Bochkov 3661 20.03.13 22:19 Сейчас в теме
(66) реиндексация в 1С и СУБД - это разные процессы и результат может отличатся, хотя цель одна.
Реиндексация через Конфигуратор - это физическое удаление всех индексов и новое их создание. Соответственно, устраняются все возможные проблемы (а платформа с индексами до сих пор иногда косячит).
Реиндексация в СУБД - это перестроение уже существующих индексов, но СУБД понятия не имеет что такое 1С и какие индексы должны быть в каких табличках. И, если они у вас неправильные по структуре (например, кто-нибудь залез ручками поправил), то они такими и останутся.
67. mulla1979 9 20.03.13 11:45 Сейчас в теме
Автору респект! Хорошая статья!
69. CheBurator 3119 20.03.13 21:42 Сейчас в теме
такс, надо у себя в торговой базе прогнать будет..
Evil Beaver; +1 Ответить
71. DitriX 2093 21.03.13 02:04 Сейчас в теме
(0) а можно такой вопрос:
недели 3 назад - пытался перерасчитать итоги, после того как внес дополнительно в базу около 100 000 документов.
База тогда весила около 170Гб. Бэкап базы весил около 2.7Гб.
В итоге - перерасчитать итоги у меня не удалось, ибо на это ушло более суток и клиенты начали кричать, пришлось жестко кикнуть 1С. Я боялся худшего. Что случилось в итоге - размер быза вырос до 270Гб, однако бэкап - теперь весит 1.7 Гига. Я уже думал что капут. Но - отчеты строится начали быстрее, данные показывали верные, в любых итогах строил и т.д.

Теперь я на тестовом сервере поднимаю бэкап и база весит всего лишь 60Гб. Но все работает отлично и даже лучше.
Например отчет по регистру по всей номенклатуре (около 120 000) по партиям на складах (около 10 000 000 записей) строится всеголишь 10 - 15 секунд (я не считаю тут расчет ширины колонок, с нима намного дольше, но это отдельная история), за весь период, со всеми выбранными ресурсами.

Отсюда вопрос - нужны ли вообще эти итоги? Так как в нашем случае - они реально замедляли работу, ибо работаем мы с партиями, т.е. для нас не критично строить отчеты по месяцам, нам важно именно партия.

Если не нужны, то как их можно отключить? Ну так что бы навсегда :)
72. echo77 1880 21.03.13 08:51 Сейчас в теме
Интересный вопрос: при выгрузке базы(средствами 1С в .dt) итоги выгружаются? Или они заново расчитываются при загрузке?
73. Aleksey.Bochkov 3661 21.03.13 09:37 Сейчас в теме
(72) - в 8.2 итоги не выгружаются, т.к. это бессмысленно и их при загрузке всегда можно заново посчитать. Выгружается их статус - включены\отключены и дата расчета (таблица AccumRgOpt* с одной строкой).
В 8.1 вроде еще выгружались, но точно не уверен.
145. Suxar 05.03.21 14:06 Сейчас в теме
(72) ни в 7.х ни в 8.х итоги не выгружаются. Индексы и итоги при загрузке всегда создаются заново.
Кстати по этой причине частенько выгрузка/загрузка БД даёт прирост производительности, особенно в базах которые не обслуживались.
VyacheslavShilov; +1 Ответить
74. Martinian 10 21.03.13 09:53 Сейчас в теме
Прошу прощения за вопрос: для файловых баз 1С:8 тема актуальна?
75. headMade 144 21.03.13 17:22 Сейчас в теме
(74) Martinian,
см. в (62) - уже отвечали.


"файловый вариант - это тоже работа с СУБД, с теми же табличками и алгоритмами. Просто СУБД встроена в 1С. Соответственно, пересчет итогов для файлового варианта также актуален."
76. Степанова Н. 22.03.13 17:11 Сейчас в теме
Я думаю мне это пригодится. Обязательно возьму на заметку
77. Геннадьевич 18 22.03.13 18:27 Сейчас в теме
Спасибо за информацию, буду тестировать.
Не увидел, как это повлияет на файловый вариант базы?
118. pisarevEV 8 24.08.15 07:27 Сейчас в теме
можно вопрос: если регулярно делается полное перепроведение всех документов (77) в базе, вопрос нулевых итогов теряет актуальность?
119. Aleksey.Bochkov 3661 24.08.15 22:18 Сейчас в теме
(118) pisarevEV,
Наоборот. Чем интенсивнее проводятся документы - тем быстрее появляются "нулевые" строки, и тем чаще требуется производить пересчет итогов.