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

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

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

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

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

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

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

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

Представим, что проводим документ «Реализация товаров и услуг» в типовой УТ 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).

99 Comments

yuraos 11.03.2013 at 06:22

Прочитал заголовок,

подумал что очередной пересказ «желтых методичек»

но был приятно удивлен

глубоким знанием автором архитектуры базы данных 1С.

Reply ↓
yuraos 11.03.2013 at 06:31

(1)

наверное стоит отметить в публикации,

что картинки с результатами запросов

сделаны в SQL Server Management Studio

для клиент-серверной базы данных.

—

Возможно кому-то будет интересно,

запросы к итогам из статьи можно также сделать

в обработке «Консоль запросов 1С + ADO»

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

Reply ↓
PowerBoy 11.03.2013 at 07:06

Автор мог еще упомянуть про разделение итогов и их свертку при пересчете, что тоже положительно влияет на производительность.

Reply ↓

yuraos 11.03.2013 at 08:07

(3) PowerBoy,

можно также упомянуть про регламентное задание в типовых конфигурациях

выполняющих пересчет итогов.

В УПП-1.2 например крутится регламентное задание «ПересчетИтоговРегистровНакопления»,

выполняющее следующий код:


Процедура ПересчетИтоговРегистров() Экспорт

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

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

Процедура ПересчетРегистров(МенеджерРегистров, НаДату, ОграничениеПоВидуРегистра = Неопределено)

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

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

КонецЦикла;

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


Процедура ПересчитатьРегистрПоДате(МенеджерРегистра, НаДату)

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

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

Показать

Reply ↓

adhocprog 11.03.2013 at 12:11

Полезная статья )

Reply ↓
fomix 11.03.2013 at 12:28

Весьма полезная статья. Еще бы подробнее про полное обновление статистики в СУБД и очистку процедурного кэша после проведения пересчета.

Reply ↓
Aleksey.Bochkov 11.03.2013 at 12:32

(3), спасибо, забыл про этот момент. Дополню как будет время.

(6), регламентные задания в СУБД — изъезженная тема, подробной информации в сети много.

Reply ↓
Yashazz 11.03.2013 at 12:54

Да, про разделение итогов было бы хорошо.

И ещё, лучше всё-таки писать так: «Если рег.ВидРегистра=Метаданные.СвойстваОбъектов.ВидРегистраНакопления.Остатки Тогда…», а не через СокрЛП

Reply ↓
melenaspb 11.03.2013 at 14:31

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

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

Reply ↓
antik69 11.03.2013 at 14:52

Спасибо за статью. К регламентной операции пересчета итогов добавилось понимание того как и на что этот пересчет влияет.

Reply ↓
gr0ck 11.03.2013 at 16:17

Статья была бы лучше, если бы уж все разом изложили, и про разделение, и про пересчет итогов, полностью от А до Я. А так, т что отражено, отражено понятным языком, с картинками, за это спасибо!

Reply ↓
ksai 11.03.2013 at 16:54

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

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

Присоединяюсь к вопросу

Reply ↓
DenisCh 11.03.2013 at 17:09

Статья хорошая.

Хотя для себя ничего нового не вынес..

Присоединяюсь к замечанию о разделении итогов.

Плюс поставил.

Reply ↓
Aleksey.Bochkov 11.03.2013 at 18:34

(8) Yashazz, а я последние годы периодически ломал голову — что же за переменная отвечает за тип регистра :).

Все время хотелось написать «Если рег.ВидРегистра=ВидРегистраНакопления.Остатки ..», а, оказывается, надо было через Метаданные.

Спасибо!

Reply ↓
Aleksey.Bochkov 11.03.2013 at 18:37

(6), (9), (12) посмотрите тут

http://infostart.ru/public/60740/

http://infostart.ru/public/65955/

Reply ↓
yuraos 11.03.2013 at 18:43

(14) Семен Семенович!

А как можно ищо?

Reply ↓
Aleksey.Bochkov 11.03.2013 at 18:46

(16) Ну не зря же существует фраза «Век живи, век учись!» 🙂

Reply ↓
metmetmet 11.03.2013 at 23:10
Спасибо автору, хорошая статья, добавила понимания работы итоговых таблиц на уровне СУБД.

Возник вопрос, а почему в процедуре пересчета текущих итогов используются строки
```
РегистрНакопления.УстановитьИспользованиеТекущихИтогов(Ложь);
РегистрНакопления.УстановитьИспользованиеТекущихИтогов(Истина);
```
вместо
```
РегистрНакопления.ПересчитатьТекущиеИтоги();
```
?

И еще вопрос: есть количественные оценки в росте производительности в связи с избавлением от «нулевых» строк?

Reply ↓
Gilev.Vyacheslav 12.03.2013 at 00:51

поставил плюс за «нулевые записи» — проблема старая, но от этого актуальность она не потеряла

Reply ↓
sanches 12.03.2013 at 07:46

Спасибо, а что-нибудь для 77 и 2000 SQL можете посоветовать? Наверняка там такая же ситуация.

Reply ↓
mcher 12.03.2013 at 07:59

Автору спасибо за статью. Всегда были вопросы по этой теме, теперь все более ли менее ясно.

Reply ↓
kasper076 12.03.2013 at 08:28

Почему код 1С вставлен, как картинка? Есть же теги для оформления кода.

Reply ↓
DenisCh 12.03.2013 at 08:55

(20) sanches, для 77 верны те же утверждения. Только там не так удобно регистры считать. Нужно или ТИИ в конфигураторе делать, или ТА двигать. Всё — в монопольном режиме.

Но я обходился и простым удалением нулевых записей через sql.

По поводу прироста — если такая операция давно не делалась, то прирост ощутим (количественно не скажу). Если её делать каждый месяц… То явного прироста не будет.

Reply ↓
sanches 12.03.2013 at 09:04

(23) DenisCh, спасибо. ТИИ не подойдет, поскольку база большая , больше 30Гиг, работают каждый день. Думаю, средствами SQl придется решать проблему.

Reply ↓
DenisCh 12.03.2013 at 09:21

(24) sanches, Ну, это не проблема 🙂

Запрос по выявлению пишется по метаданным за 5 минут.

На удаление — ещё 3…

Reply ↓
ksai 12.03.2013 at 09:42

(15)

Спасибо!

Reply ↓
fomix 12.03.2013 at 09:54

(15)Спасибо за ссылки!

Reply ↓
yuraos 12.03.2013 at 18:23

(20)(23)(24)

sanches,

вот здеся есть много вякой вкуснятины для 1С-77

правда требуется ВК 1cpp.dll

—

в том числе обработка «Установка ТА«, которая:

позволяет переустанавливать ТА,

расчитывая итоги регистров прямыми запросами 1с++

Позволяет также:

— пересчитать итоги по указанным регистрам (остатков и оборотов);

— все действия можно проводить в разделенном режиме (устанавливается блокировка);

— каждый месяц открывать за вас новый период, не выгоняя срочно всех из базы;

Reply ↓
sanches 12.03.2013 at 18:38

(28) yuraos, Спасибо! Посмотрю

Reply ↓
CheBurator 12.03.2013 at 18:48

(28) не работает под дбф.

Reply ↓
CheBurator 12.03.2013 at 18:50

Коллеги, а поясните неграмотному.

Если при расчетах задним числом. модифицируются промежуточные и актуальные итоги. и вдруг получается в итогах ноль. Итог — это по сути куча. Куча — всегда итог правильный, например нулевой. Почему тупо скулем не удалить нулевые итоги…?????

Reply ↓
Aleksey.Bochkov 12.03.2013 at 19:00

(31) CheBurator, можно и напрямую в СУБД удалить. Лично я бы так и делал, но для массового применения такую рекомендацию никогда не дам.

Reply ↓
yuraos 12.03.2013 at 19:03

(30) CheBurator, да не работает,

там запросы писать надо по другому и

желательно прирулить какие-нибудь примочки, чтобы

прямые запросы в dbf в монопольном режиме работали.

🙂

…

но клиент просил

Спасибо, а что-нибудь для 77 и 2000 SQL можете посоветовать? Наверняка там такая же ситуация.

Reply ↓
yuraos 12.03.2013 at 19:07

(31)

а платформа сама не удаляет эти нулевые записи?

иначе бы таблицы итогов пухли бы …

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

но пухли бы точно.

Reply ↓
CheBurator 12.03.2013 at 19:16

(33) прямые запросы в дбф в монопольном режиме чтобы работали — это уже вроде как давно есть такая возможность

Reply ↓
CheBurator 12.03.2013 at 19:16

(32) хм.. а почему..? скуль же вроде сам все разложит/проиндексирует..?

Reply ↓
Aleksey.Bochkov 12.03.2013 at 19:22

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

Reply ↓
Diversus 12.03.2013 at 22:14

(0) Интересно, а нет ли у кого скрипта на SQL, чтобы удалил лишние нулевые значения?

Да и быстрее это дело было бы…

Reply ↓
yuraos 13.03.2013 at 05:55

(36)

а не кто и не говорит что эти примочки к 1С

для монопольного режима какая-то новость

(разве что субъективно 🙂 ).

—

просто их надо будет прикручивать,

если захочется что бы прямые запросы в dbf

работали в монопольном режиме.

Reply ↓
maldinitaly 13.03.2013 at 10:47

Спасибо, огромное автору за статью.Все четко и понятно.Плюс

Reply ↓
maxpiter 13.03.2013 at 10:55

albochkov, т.е. вы хотите сказать, что можно просто удалить в регистре остатков все нулевые значения?

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

p.s. Я сам про это думал и как-то даже на тестовой удалял (SQL запросом), но на рабочую перенести так и не решился, хотя никаких отклонений в работе системы выявлено не было.

Reply ↓
rassylka-new@yandex.ru 13.03.2013 at 11:11

Все просто прекрасно с технической стороны, просто здорово и весело, НО какой эффект это дает в реальных боевых условиях (я сейчас не говорю про теоретические аспекты а-ля лишние ресурсы участвующие в блокировках)? Есть какие-нибудь статистические данные хоть у кого-нибудь?

Reply ↓
Kopman 13.03.2013 at 11:32

Спасибо за статью..

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

http://infostart.ru/public/177538/

Reply ↓
maxpiter 13.03.2013 at 11:50

(42) у меня вышло, что для таблиц:

РезервыТМЦ, доля нулевых записей на таблицу составила 53%

ПланыПродаж, 23%

остальные регистры не более 5%

Reply ↓
maxpiter 13.03.2013 at 12:13

(38) для 7.7 http://infostart.ru/public/177579/

Reply ↓
Aleksey.Bochkov 13.03.2013 at 12:32

(41) — удалить нулевые записи нужно не в регистре остатков, а таблице итогов регистра остатков. Появление нулевых записей — это нормальная работа системы и не является ошибкой. Конечно, было бы хорошо, если бы платформа сама проверяла наличие нулей после окончания проведения документов и удаляла их, то это требовало бы дополнительных затрат ресурсов. Но это лишь предположение — разработчикам платформы видней почему так сделано.

Reply ↓
Aleksey.Bochkov 13.03.2013 at 12:36

(42) — конкретный пример, побудивший написать статью — база УТ 10.3, года 3 не пересчитывали итоги, база небольшая — около 40 Гб чистых данных. В результате в актуальных итогах только по регистру партий 300 тысяч записей, из них 290 тысяч — нулевые. Длительность проведения одной реализации — 2,9 с.

После пересчета итогов производительность упала — 5,1 с. на 1 реализацию.

После обновления статистики — 0,9 с. на 1 реализацию.

Примерно трехкратный прирост.

Но каждая ситуация индивидуальна.

Reply ↓
Diversus 13.03.2013 at 12:36

(0) (45)

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

сделать две тестовые базы, копии рабочей

— в одной удалить все нулевые записи SQL-скриптом

— в другой сделать пересчет регистров штатными средствами платформы

Потом запросом сравнивать по два регистра из этих двух баз что получается и где есть различия.

Если различий нет, то можно смело использовать в повседневной жизни, если есть станет ясно что делать дальше и какие записи не удалять…

Reply ↓
maxpiter 13.03.2013 at 12:48

(46) именно это я и хотел выразить, видимо не совсем ясно донес мысль 🙂

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

Reply ↓
rassylka-new@yandex.ru 13.03.2013 at 13:51

(47) Впечатляющий прирост. Спасибо!

Reply ↓
skyp 13.03.2013 at 13:51

Большое спасибо за статью!

Очень информативно, кратко и действенно. Очень качественное дополнение к ЖКК.

Reply ↓
Kopman 14.03.2013 at 07:24

Заметил в базе следующую ситуацию, таблицы итогов по нескольким регистрам содержат 1-2 нулевых записей начиная с 2201-02-01 00:00:00.000 и смещение 2000(т.е щас 4013-03..) получаются даты совершенно нереальные.

Простыми расчетами выходит, что там периодов итогов 1812*12=21744 штук. Умножив это на число нулевых записей в каждом периоде можно сильно удивиться:-)

Reply ↓
l-Rain 14.03.2013 at 10:50

Спасибо, полезно.

Reply ↓
YPermitin 15.03.2013 at 14:16

Отличная статья!

Reply ↓
Ibrogim 15.03.2013 at 14:32

+

из остатка на 01.11.3999 отнимается списанное количество.

Найдут потомки таблицы 1С и будут думать, что мы предсказали конец света 1 ноября 3999 года

Reply ↓
TrinitronOTV 16.03.2013 at 08:39

Спасибо за статью. Много нового почерпнул для себя

Reply ↓
lustin 17.03.2013 at 01:24

Reply ↓
pulpik 19.03.2013 at 13:59

Всем добрый день. Благодарю автора за статью. Прояснила нашу ситуацию.

БД — SQL 11 Gb

Это бухгалтерия за один год.

Выявились проблемы при формировании отчета Обороты счета за год по 20 счету по 3 субконто + подразделения.

за 1 кв отчет Формируется в течении 20 секунд

за 2 квартала 8 минут

за три и четыре квартала отчет не формируется…

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

Это ответ на вопросы по реальному приросту после пересчета итогов.

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

Так что я думаю что там еще есть кое что с дефрагментацией БД.

Спасибо.

Reply ↓
headMade 19.03.2013 at 20:21

(59) pulpik,

а в ЗУПе за счет чего такой выйгрыш?

Насколько я понял это больше актуально для регистров ~~расчета~~ накопления (поправьте если ошибаюсь), а в ЗУПе они не так (наверное) интенсивно используются. Или всеравно это дало такой прирост?

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

Спасибо.

Reply ↓
Aleksey.Bochkov 19.03.2013 at 22:09

(61) — файловый вариант — это тоже работа с СУБД, с теми же табличками и алгоритмами. Просто СУБД встроена в 1С. Соответственно, пересчет итогов для файлового варианта также актуален.

Reply ↓
pulpik 20.03.2013 at 00:24

в ЗиУП работаем уже пять лет, итоги не пересчитывал, никогда не было проблем, но последние пол года диагностировалась проблема с отчетами по регистрам расчетов. Не знаю с чем связано — у них я понимаю нет нулевых ресурсов в виртуальных таблицах, но после пересчета время отчетов сократилось с 15-40 и более до 2-4 минут. (все применимо к клиент серверной архитектуре.)

Reply ↓
LexSeIch 20.03.2013 at 05:25

Мир этому дому!

Хорошая добротная статья. Спасибо автору за детальное освещение вопроса.

Reply ↓
kurvik 20.03.2013 at 10:17

Спасибо за статью. Добавилось понимание того как и на что пересчет итогов влияет.

Reply ↓
Yackov 20.03.2013 at 11:12

Спрошу на всякий случай:) Если я делаю реиндексацию через конфигуратор, нужно ли запускать ее на sql (или это одно и тоже)?

Reply ↓
mulla1979 20.03.2013 at 11:45

Автору респект! Хорошая статья!

Reply ↓
CheBurator 20.03.2013 at 21:40

(66) хм.. наскольо мне помнится в скульном варианте базы нет доступа к реиндексации…

Reply ↓
CheBurator 20.03.2013 at 21:42

такс, надо у себя в торговой базе прогнать будет..

Reply ↓
Aleksey.Bochkov 20.03.2013 at 22:19

(66) реиндексация в 1С и СУБД — это разные процессы и результат может отличатся, хотя цель одна.

Реиндексация через Конфигуратор — это физическое удаление всех индексов и новое их создание. Соответственно, устраняются все возможные проблемы (а платформа с индексами до сих пор иногда косячит).

Реиндексация в СУБД — это перестроение уже существующих индексов, но СУБД понятия не имеет что такое 1С и какие индексы должны быть в каких табличках. И, если они у вас неправильные по структуре (например, кто-нибудь залез ручками поправил), то они такими и останутся.

Reply ↓
DitriX 21.03.2013 at 02:04

(0) а можно такой вопрос:

недели 3 назад — пытался перерасчитать итоги, после того как внес дополнительно в базу около 100 000 документов.

База тогда весила около 170Гб. Бэкап базы весил около 2.7Гб.

В итоге — перерасчитать итоги у меня не удалось, ибо на это ушло более суток и клиенты начали кричать, пришлось жестко кикнуть 1С. Я боялся худшего. Что случилось в итоге — размер быза вырос до 270Гб, однако бэкап — теперь весит 1.7 Гига. Я уже думал что капут. Но — отчеты строится начали быстрее, данные показывали верные, в любых итогах строил и т.д.

Теперь я на тестовом сервере поднимаю бэкап и база весит всего лишь 60Гб. Но все работает отлично и даже лучше.

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

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

Если не нужны, то как их можно отключить? Ну так что бы навсегда 🙂

Reply ↓
echo77 21.03.2013 at 08:51

Интересный вопрос: при выгрузке базы(средствами 1С в .dt) итоги выгружаются? Или они заново расчитываются при загрузке?

Reply ↓
Aleksey.Bochkov 21.03.2013 at 09:37

(72) — в 8.2 итоги не выгружаются, т.к. это бессмысленно и их при загрузке всегда можно заново посчитать. Выгружается их статус — включеныотключены и дата расчета (таблица AccumRgOpt* с одной строкой).

В 8.1 вроде еще выгружались, но точно не уверен.

Reply ↓
Martinian 21.03.2013 at 09:53

Прошу прощения за вопрос: для файловых баз 1С:8 тема актуальна?

Reply ↓
headMade 21.03.2013 at 17:22

(74) Martinian,

см. в (62) — уже отвечали.

«файловый вариант — это тоже работа с СУБД, с теми же табличками и алгоритмами. Просто СУБД встроена в 1С. Соответственно, пересчет итогов для файлового варианта также актуален.»

Reply ↓
Степанова Н. 22.03.2013 at 17:11

Я думаю мне это пригодится. Обязательно возьму на заметку

Reply ↓
Геннадьевич 22.03.2013 at 18:27

Спасибо за информацию, буду тестировать.

Не увидел, как это повлияет на файловый вариант базы?

Reply ↓
rеd80 23.03.2013 at 03:20

По умолчанию для регистров существуют итоги по месяцам и актуальные итоги (только для регистров остатков).

У регистров бухгалтерии тоже есть актуальные итоги.

Reply ↓
rеd80 23.03.2013 at 04:34

(58) lustin, Даже не знаю что полезнее, статья или комментарий…

Reply ↓
lustin 23.03.2013 at 05:02

(79) rеd80, я бы в комплексе рассматривал. Тем более что Алексей Бочков скорее всего тоже в курсе того что я написал. Как сказал Вячеслав — проблема известная, но на данный момент так спокойно и коротко на Инфостарте (да и в тырнете) не описана — Алексей собственно и сделал такую статью.

Меня же зацепило «разработчикам платформы виднее» ;-).

Reply ↓
Aleksey.Bochkov 23.03.2013 at 11:32

(78) — регистры бухгалтерии — это тоже регистры остатков.

Reply ↓
Aleksey.Bochkov 23.03.2013 at 11:41

(80) — Алексей, поясню эту фразу 🙂

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

2) Стараюсь быть осторожен в формулировках относительно работы фирмы 1С. Уже несколько раз попадал на цензуру и замечания с их стороны. А в немилость впасть не хочется :).

Reply ↓
yuraos 23.03.2013 at 13:48

(81) Aleksey.Bochkov,

еще какие регистры!

и еще каких остатков!!!

самые гемморойные наверное объекты в платформе.

🙂

Особенно если какой-нибудь умник замутит субконто с примитивными типами

Reply ↓
Miha.L 24.03.2013 at 01:54

Автору спасибо, полезная статья.

Reply ↓
Martinian 24.03.2013 at 17:30

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

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

Reply ↓
lustin 25.03.2013 at 03:05

(85) Martinian, нет MSSQL — нет обновления статистики.

хотя правды ради надо отметить — что и на Postgres есть обновление статистики 😉 http://www.postgresql.org/docs/9.2/static/maintenance.html

Так что нет сервера SQL — негде обновлять статистику

Reply ↓
CheBurator 25.03.2013 at 03:20

В принципе, не для десятковогигабайтных баз можно тупо почистить нулевые строки для всех периодов (м.б. за исключением последнего предшествующего текущему) как описал Лустин в (58), если вдруг окажется что нужных итогов нет — ну понесет платформа платформа при проведении допзатраты на их создание — но понесет эти допзатраты для одной номенклатуры один раз. А затраты на регулярное чтение при оставлении отчетов и обращения к итогам при обильном наличии пустых записей могут быть больше/чаще..? (рассуждаю применительно к файловым клюшкам)

Reply ↓
pbabincev 25.03.2013 at 19:42

Добрый вечер.

Алексей, огромное спасибо за статью, очень познавательно и кратко.

У меня появились пара вопросов «в тему» (в статье ответа не увидел):

1. В случае, если к примеру у меня рассчитаны итоги на конец января 31.01.2013, а я делаю запрос к остаткам на конец февраля 28.02.2013, а сегодня — 25.03.2013, и существует много движений за весь этот период, то каким образом система предоставит мне запрашиваемые данные: будет рассчитывать «на лету»?

2. Тот же пример что и в п.1. Но в данном случае я провожу «задним числом» приход от 10.01.2013, то как поведет себя система в этом случае: она будет пересчитает уже рассчитанный итог на конец января и актульный итог, верно? А если бы у меня были рассчитаны итоги еще и на конец февраля, то система бы пересчитывала еще и их? Если это так, то делаю вывод: рассчитанные итоги «мешают» при больших объемах изменений «задним числом» (например, при первом закрытии квартала после запуска системы с начала года, когда всё еще корректируются начальные остатки). То есть не всегда расчет итогов приведет к повышению производительности. Правильный ли вывод я сделал?

Спасибо.

Reply ↓
rеd80 26.03.2013 at 13:19

(88) p_tj, 1. Да, будет рассчитывать «на лету». Возьмет из таблицы остатков данные на начало периода, прибавит обороты оттуда же и отсчитает из таблицы движений строчки с конца. Такой хитрый алгоритм.

2. Если меняем данные в прошлом, например 25.05.12, система меняет обороты в мае 2012 и остатки во всех последующих итогах. Поэтому не рекомендуется рассчитывать итоги на будущее, в идеале — на последний прошедший месяц.

Reply ↓
pbabincev 26.03.2013 at 20:39

(89) Спасибо.

Reply ↓
CheBurator 27.03.2013 at 23:03

Наваяна обработочка для 7.7 файловый режим

результат на моей маленькой базе

Итог по размерам: http://screencast.com/t/rHtIDzJlkD

Reply ↓
CheBurator 27.03.2013 at 23:25

обработка здесь: http://infostart.ru/public/180018/

(может быть недоступна, т.к. не прошла еще модерацию)

Reply ↓
CheBurator 28.03.2013 at 03:07

на файловых клюшках, объем исходной базы дбф+cl[ менее 5Гб

.

Перепровел тестовую и контрольные базы, пордяка 3200 доков, все задним числом, какого-то мега ощутимого прироста не наблюдал — процентов5-8, что можно списать на погрешности… Правда львиная доля тяжелых доков, по которым существенно упаковались таблицы итогов — у меня при заднем числе не перепроводятся, поэтом м.б. и не показательно у меня.. тем более что база достаточно маленькая — чуть более 4 гига всего, ожидаемый эффект м.б. на ней и не проявится…?

Reply ↓
Ленкина 04.04.2013 at 11:12

Спасибо. Полезная статья.

Reply ↓
Mudrii_Gankster 10.04.2013 at 14:14

(47) А объем БД уменьшился? В моей БД происходит регламентная дефрагментация индексов, пересчета статистики, но пересчета итогов к сожалению делаю не так часто. Попробую сделать и проверить на результат проведения базы, давность данных 8 лет.

P.S. дописанная УТ 10.2

Reply ↓
Aleksey.Bochkov 10.04.2013 at 14:25

(95) — да, чистый объем информации в базе уменьшился процентов на 20%. Но это совсем уж запущенный случай :).

Reply ↓
Bukaska 10.04.2013 at 15:16

(28) yuraos,

Спасибо за ссылки)))

(34) yuraos,

Чтобы таблицы итогов не опухли бы, для этого есть в бухучете инструмент: Закрытие месяца, закрытие года

А без этого было бы вообще жесть..

за статью ставлю однозначно «+», так как меня давно интересовал такой вопрос, для чего закрывать месяц, год, что будет… Теперь ясно что к чему)))

Reply ↓
pisarevEV 24.08.2015 at 07:27

можно вопрос: если регулярно делается полное перепроведение всех документов (77) в базе, вопрос нулевых итогов теряет актуальность?

Reply ↓
Aleksey.Bochkov 24.08.2015 at 22:18

(118) pisarevEV,

Наоборот. Чем интенсивнее проводятся документы — тем быстрее появляются «нулевые» строки, и тем чаще требуется производить пересчет итогов.

Reply ↓
pisarevEV 25.08.2015 at 12:49

(119) Aleksey.Bochkov, а если перед перед проведением удалить файлы RG*, то после перепроведения мы получим итоги без нулевых записей?

Reply ↓
lustin 24.05.2016 at 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% случаев вопрос к бизнес-пользователям системы и прикладникам

Reply ↓