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

0. Алексей Бочков (Aleksey.Bochkov) 2854 10.03.13 19:16 Сейчас в теме
Мы часто слышим рекомендацию о том, что пересчет итогов нужно проводить регулярно и эта операция проводит к улучшению производительности, но что скрывается за этой процедурой и какие именно проблемы решаются?

Перейти к публикации

Комментарии
1. Юрий Осипов (yuraos) 932 11.03.13 06:22 Сейчас в теме
Прочитал заголовок,
подумал что очередной пересказ "желтых методичек"
но был приятно удивлен
глубоким знанием автором архитектуры базы данных 1С.
kolya_tlt; dj_serega; dzhenn; trdm; +4 Ответить
2. Юрий Осипов (yuraos) 932 11.03.13 06:31 Сейчас в теме
(1)
наверное стоит отметить в публикации,
что картинки с результатами запросов
сделаны в SQL Server Management Studio
для клиент-серверной базы данных.
--
Возможно кому-то будет интересно,
запросы к итогам из статьи можно также сделать
в обработке "Консоль запросов 1С + ADO"
так же в консоли можно выполнить код на языке 1С для пересчета итогов.
3. Александр Окулов (PowerBoy) 2830 11.03.13 07:06 Сейчас в теме
Автор мог еще упомянуть про разделение итогов и их свертку при пересчете, что тоже положительно влияет на производительность.
marchenko.y; +1 Ответить
4. Юрий Осипов (yuraos) 932 11.03.13 08:07 Сейчас в теме
(3) PowerBoy,
можно также упомянуть про регламентное задание в типовых конфигурациях
выполняющих пересчет итогов.

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

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

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

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


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

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

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

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


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

Плюс поставил.
18. metal doctor (metmetmet) 56 11.03.13 23:10 Сейчас в теме
Спасибо автору, хорошая статья, добавила понимания работы итоговых таблиц на уровне СУБД.

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

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

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


?

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

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

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

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

p.s. Я сам про это думал и как-то даже на тестовой удалял (SQL запросом), но на рабочую перенести так и не решился, хотя никаких отклонений в работе системы выявлено не было.
46. albochkov (Aleksey.Bochkov) 13.03.13 12:32 Сейчас в теме
(41) - удалить нулевые записи нужно не в регистре остатков, а таблице итогов регистра остатков. Появление нулевых записей - это нормальная работа системы и не является ошибкой. Конечно, было бы хорошо, если бы платформа сама проверяла наличие нулей после окончания проведения документов и удаляла их, то это требовало бы дополнительных затрат ресурсов. Но это лишь предположение - разработчикам платформы видней почему так сделано.
49. Максим Шуйский (maxpiter) 142 13.03.13 12:48 Сейчас в теме
(46) именно это я и хотел выразить, видимо не совсем ясно донес мысль :)
Удалить нулевые записи в таблицах промежуточных итогов.
58. Алексей Лустин (lustin) 901 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 (просмотр).
alexey.shesterikov@bk.ru; mytg; Gang031; ice-net; Goga1979; ChessCat; RegrZ; dr.death; Irwin; Paradise.87; alexkmbk; корум; 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; adm134; TIS_08; mtv:); soulsteps; shalimski; Anesk; pisarevEV; Silenser; kwazi; engineer74; vadimlp77; Артано; dgolovanov; pchela751; aexeel; artbear; jif; Dmitryiv; 4rtehouse; 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; igorynets; 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; +120 Ответить
79. red 80 (rеd80) 23.03.13 04:34 Сейчас в теме
(58) lustin, Даже не знаю что полезнее, статья или комментарий...
80. Алексей Лустин (lustin) 901 23.03.13 05:02 Сейчас в теме
(79) rеd80, я бы в комплексе рассматривал. Тем более что Алексей Бочков скорее всего тоже в курсе того что я написал. Как сказал Вячеслав - проблема известная, но на данный момент так спокойно и коротко на Инфостарте (да и в тырнете) не описана - Алексей собственно и сделал такую статью.

Меня же зацепило "разработчикам платформы виднее" ;-).
82. Алексей Бочков (Aleksey.Bochkov) 2854 23.03.13 11:41 Сейчас в теме
(80) - Алексей, поясню эту фразу :)
1) Все-таки, решение проблемы с нулевыми записями на уровне платформы не такое тривиальное, есть разные варианты и везде есть плюсы и минусы. Вряд ли можно угодить всем. А переложить ответственность за чистку итогов на конечного пользователя системы - в принципе, хороший вариант.
2) Стараюсь быть осторожен в формулировках относительно работы фирмы 1С. Уже несколько раз попадал на цензуру и замечания с их стороны. А в немилость впасть не хочется :).
87. Сергей Коцюра (CheBurator) 3541 25.03.13 03:20 Сейчас в теме
В принципе, не для десятковогигабайтных баз можно тупо почистить нулевые строки для всех периодов (м.б. за исключением последнего предшествующего текущему) как описал Лустин в (58), если вдруг окажется что нужных итогов нет - ну понесет платформа платформа при проведении допзатраты на их создание - но понесет эти допзатраты для одной номенклатуры один раз. А затраты на регулярное чтение при оставлении отчетов и обращения к итогам при обильном наличии пустых записей могут быть больше/чаще..? (рассуждаю применительно к файловым клюшкам)
128. Алексей Лустин (lustin) 901 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% случаев вопрос к бизнес-пользователям системы и прикладникам
support; hulio; DimaP; +3 Ответить
42. Rassyl Rsaayl (rassylka-new@yandex.ru) 13.03.13 11:11 Сейчас в теме
Все просто прекрасно с технической стороны, просто здорово и весело, НО какой эффект это дает в реальных боевых условиях (я сейчас не говорю про теоретические аспекты а-ля лишние ресурсы участвующие в блокировках)? Есть какие-нибудь статистические данные хоть у кого-нибудь?
44. Максим Шуйский (maxpiter) 142 13.03.13 11:50 Сейчас в теме
(42) у меня вышло, что для таблиц:
РезервыТМЦ, доля нулевых записей на таблицу составила 53%
ПланыПродаж, 23%
остальные регистры не более 5%
47. albochkov (Aleksey.Bochkov) 13.03.13 12:36 Сейчас в теме
(42) - конкретный пример, побудивший написать статью - база УТ 10.3, года 3 не пересчитывали итоги, база небольшая - около 40 Гб чистых данных. В результате в актуальных итогах только по регистру партий 300 тысяч записей, из них 290 тысяч - нулевые. Длительность проведения одной реализации - 2,9 с.
После пересчета итогов производительность упала - 5,1 с. на 1 реализацию.
После обновления статистики - 0,9 с. на 1 реализацию.
Примерно трехкратный прирост.
Но каждая ситуация индивидуальна.
51. Rassyl Rsaayl (rassylka-new@yandex.ru) 13.03.13 13:51 Сейчас в теме
(47) Впечатляющий прирост. Спасибо!
95. Руслан Программист 1с (Mudrii_Gankster) 10.04.13 14:14 Сейчас в теме
(47) А объем БД уменьшился? В моей БД происходит регламентная дефрагментация индексов, пересчета статистики, но пересчета итогов к сожалению делаю не так часто. Попробую сделать и проверить на результат проведения базы, давность данных 8 лет.

P.S. дописанная УТ 10.2
96. Алексей Бочков (Aleksey.Bochkov) 2854 10.04.13 14:25 Сейчас в теме
(95) - да, чистый объем информации в базе уменьшился процентов на 20%. Но это совсем уж запущенный случай :).
43. Андрей Антипенко (Kopman) 16 13.03.13 11:32 Сейчас в теме
Спасибо за статью..
сделал генератор скрипта для проверки таблиц итогов, основываясь на запросах автора статьи.
http://infostart.ru/public/177538/
48. Виталий Барилко (Diversus) 1765 13.03.13 12:36 Сейчас в теме
(0) (45)

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

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

Потом запросом сравнивать по два регистра из этих двух баз что получается и где есть различия.
Если различий нет, то можно смело использовать в повседневной жизни, если есть станет ясно что делать дальше и какие записи не удалять...
50. Сергей Концеропятов (skyp) 35 13.03.13 13:51 Сейчас в теме
Большое спасибо за статью!
Очень информативно, кратко и действенно. Очень качественное дополнение к ЖКК.
53. Андрей Антипенко (Kopman) 16 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. Юрий Пермитин (YPermitin) 638 15.03.13 14:16 Сейчас в теме
56. Иван Титов (Ibrogim) 972 15.03.13 14:32 Сейчас в теме
+
из остатка на 01.11.3999 отнимается списанное количество.
Найдут потомки таблицы 1С и будут думать, что мы предсказали конец света 1 ноября 3999 года
корум; Artem-B; Fatov_DI; bulpi; Keu2; bandru; nv_suvorova90@mail.ru; the1; DenisCh; recon; +10 Ответить
57. Александр Лыткин (TrinitronOTV) 16.03.13 08:39 Сейчас в теме
Спасибо за статью. Много нового почерпнул для себя
59. pulpik pulpik (pulpik) 106 19.03.13 13:59 Сейчас в теме
Всем добрый день. Благодарю автора за статью. Прояснила нашу ситуацию.
БД - SQL 11 Gb
Это бухгалтерия за один год.
Выявились проблемы при формировании отчета Обороты счета за год по 20 счету по 3 субконто + подразделения.
за 1 кв отчет Формируется в течении 20 секунд
за 2 квартала 8 минут
за три и четыре квартала отчет не формируется...

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

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

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


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

Спасибо.
62. Алексей Бочков (Aleksey.Bochkov) 2854 19.03.13 22:09 Сейчас в теме
(61) - файловый вариант - это тоже работа с СУБД, с теми же табличками и алгоритмами. Просто СУБД встроена в 1С. Соответственно, пересчет итогов для файлового варианта также актуален.
63. pulpik pulpik (pulpik) 106 20.03.13 00:24 Сейчас в теме
в ЗиУП работаем уже пять лет, итоги не пересчитывал, никогда не было проблем, но последние пол года диагностировалась проблема с отчетами по регистрам расчетов. Не знаю с чем связано - у них я понимаю нет нулевых ресурсов в виртуальных таблицах, но после пересчета время отчетов сократилось с 15-40 и более до 2-4 минут. (все применимо к клиент серверной архитектуре.)
64. Сергей Маслов (LexSeIch) 193 20.03.13 05:25 Сейчас в теме
Мир этому дому!
Хорошая добротная статья. Спасибо автору за детальное освещение вопроса.
65. Viktor (kurvik) 20.03.13 10:17 Сейчас в теме
Спасибо за статью. Добавилось понимание того как и на что пересчет итогов влияет.
66. Yackov . (Yackov) 96 20.03.13 11:12 Сейчас в теме
Спрошу на всякий случай:) Если я делаю реиндексацию через конфигуратор, нужно ли запускать ее на sql (или это одно и тоже)?
68. Сергей Коцюра (CheBurator) 3541 20.03.13 21:40 Сейчас в теме
(66) хм.. наскольо мне помнится в скульном варианте базы нет доступа к реиндексации...
70. Алексей Бочков (Aleksey.Bochkov) 2854 20.03.13 22:19 Сейчас в теме
(66) реиндексация в 1С и СУБД - это разные процессы и результат может отличатся, хотя цель одна.
Реиндексация через Конфигуратор - это физическое удаление всех индексов и новое их создание. Соответственно, устраняются все возможные проблемы (а платформа с индексами до сих пор иногда косячит).
Реиндексация в СУБД - это перестроение уже существующих индексов, но СУБД понятия не имеет что такое 1С и какие индексы должны быть в каких табличках. И, если они у вас неправильные по структуре (например, кто-нибудь залез ручками поправил), то они такими и останутся.
67. Юрий Муллабакиев (mulla1979) 8 20.03.13 11:45 Сейчас в теме
Автору респект! Хорошая статья!
69. Сергей Коцюра (CheBurator) 3541 20.03.13 21:42 Сейчас в теме
такс, надо у себя в торговой базе прогнать будет..
Evil Beaver; +1 Ответить
71. Дмитрий Шерстобитов (DitriX) 2729 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) 828 21.03.13 08:51 Сейчас в теме
Интересный вопрос: при выгрузке базы(средствами 1С в .dt) итоги выгружаются? Или они заново расчитываются при загрузке?
73. Алексей Бочков (Aleksey.Bochkov) 2854 21.03.13 09:37 Сейчас в теме
(72) - в 8.2 итоги не выгружаются, т.к. это бессмысленно и их при загрузке всегда можно заново посчитать. Выгружается их статус - включены\отключены и дата расчета (таблица AccumRgOpt* с одной строкой).
В 8.1 вроде еще выгружались, но точно не уверен.
74. Martinian Martinian (Martinian) 7 21.03.13 09:53 Сейчас в теме
Прошу прощения за вопрос: для файловых баз 1С:8 тема актуальна?
75. Анатолий Бритько (headMade) 135 21.03.13 17:22 Сейчас в теме
(74) Martinian,
см. в (62) - уже отвечали.


"файловый вариант - это тоже работа с СУБД, с теми же табличками и алгоритмами. Просто СУБД встроена в 1С. Соответственно, пересчет итогов для файлового варианта также актуален."
76. Наталия Степанова (Степанова Н.) 22.03.13 17:11 Сейчас в теме
Я думаю мне это пригодится. Обязательно возьму на заметку
77. Геннадьевич Бу (Геннадьевич) 10 22.03.13 18:27 Сейчас в теме
Спасибо за информацию, буду тестировать.
Не увидел, как это повлияет на файловый вариант базы?
118. Евгений Писарев (pisarevEV) 24.08.15 07:27 Сейчас в теме
можно вопрос: если регулярно делается полное перепроведение всех документов (77) в базе, вопрос нулевых итогов теряет актуальность?
119. Алексей Бочков (Aleksey.Bochkov) 2854 24.08.15 22:18 Сейчас в теме
(118) pisarevEV,
Наоборот. Чем интенсивнее проводятся документы - тем быстрее появляются "нулевые" строки, и тем чаще требуется производить пересчет итогов.
120. Евгений Писарев (pisarevEV) 25.08.15 12:49 Сейчас в теме
(119) Aleksey.Bochkov, а если перед перед проведением удалить файлы RG*, то после перепроведения мы получим итоги без нулевых записей?
78. red 80 (rеd80) 23.03.13 03:20 Сейчас в теме
По умолчанию для регистров существуют итоги по месяцам и актуальные итоги (только для регистров остатков).

У регистров бухгалтерии тоже есть актуальные итоги.
81. Алексей Бочков (Aleksey.Bochkov) 2854 23.03.13 11:32 Сейчас в теме
(78) - регистры бухгалтерии - это тоже регистры остатков.
83. Юрий Осипов (yuraos) 932 23.03.13 13:48 Сейчас в теме
(81) Aleksey.Bochkov,
еще какие регистры!
и еще каких остатков!!!
самые гемморойные наверное объекты в платформе.
:)
Особенно если какой-нибудь умник замутит субконто с примитивными типами
84. Михаил Лыков (Miha.L) 24.03.13 01:54 Сейчас в теме
Автору спасибо, полезная статья.
85. Martinian Martinian (Martinian) 7 24.03.13 17:30 Сейчас в теме
Поэтому нужно не забывать запускать полное обновление статистики в СУБД и очистку процедурного кэша после проведения пересчета.

Правильно ли я понимаю, что в случае файлового режима работы этого делать не нужно, и пересчет итогов сразу должен дать положительный результат?
86. Алексей Лустин (lustin) 901 25.03.13 03:05 Сейчас в теме
(85) Martinian, нет MSSQL - нет обновления статистики.

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

Так что нет сервера SQL - негде обновлять статистику
88. p_tj (pbabincev) 25.03.13 19:42 Сейчас в теме
Добрый вечер.

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

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

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

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

Спасибо.
89. red 80 (rеd80) 26.03.13 13:19 Сейчас в теме
(88) p_tj, 1. Да, будет рассчитывать "на лету". Возьмет из таблицы остатков данные на начало периода, прибавит обороты оттуда же и отсчитает из таблицы движений строчки с конца. Такой хитрый алгоритм.
2. Если меняем данные в прошлом, например 25.05.12, система меняет обороты в мае 2012 и остатки во всех последующих итогах. Поэтому не рекомендуется рассчитывать итоги на будущее, в идеале - на последний прошедший месяц.
for_questions; pbabincev; +2 Ответить
90. p_tj (pbabincev) 26.03.13 20:39 Сейчас в теме
91. Сергей Коцюра (CheBurator) 3541 27.03.13 23:03 Сейчас в теме
Наваяна обработочка для 7.7 файловый режим
результат на моей маленькой базе
Итог по размерам: http://screencast.com/t/rHtIDzJlkD
92. Сергей Коцюра (CheBurator) 3541 27.03.13 23:25 Сейчас в теме
обработка здесь: http://infostart.ru/public/180018/
(может быть недоступна, т.к. не прошла еще модерацию)
93. Сергей Коцюра (CheBurator) 3541 28.03.13 03:07 Сейчас в теме
на файловых клюшках, объем исходной базы дбф+cl[ менее 5Гб
.
Перепровел тестовую и контрольные базы, пордяка 3200 доков, все задним числом, какого-то мега ощутимого прироста не наблюдал - процентов5-8, что можно списать на погрешности... Правда львиная доля тяжелых доков, по которым существенно упаковались таблицы итогов - у меня при заднем числе не перепроводятся, поэтом м.б. и не показательно у меня.. тем более что база достаточно маленькая - чуть более 4 гига всего, ожидаемый эффект м.б. на ней и не проявится...?
94. Лена (Ленкина) 04.04.13 11:12 Сейчас в теме
Спасибо. Полезная статья.
Оставьте свое сообщение