IE 2016

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

Опубликовал Aleksey.Bochkov в раздел Администрирование - Системное

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

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

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

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

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

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

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

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

См. также

PowerTools от 1 000

Лучшие комментарии

58. lustin 17.03.2013 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 (просмотр).
Ответили: (79) (87) (128)
+ 103 [ 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; ]
# Ответить
56. Ibrogim 15.03.2013 14:32
+
из остатка на 01.11.3999 отнимается списанное количество.
Найдут потомки таблицы 1С и будут думать, что мы предсказали конец света 1 ноября 3999 года
# Ответить
127. tormozit 10.05.2016 08:52
Добавил инструмент "Управление итогами" в подсистему "Инструменты разработчика" в версию 3.62. Там
- показывается количество нулевых строк итогов и можно их удалять до заданного периода
- видно сколько строк итогов в каждом месяце
- можно очищать таблицы итогов
- можно выполнять все штатные операции с итогами
# Ответить
4. yuraos 11.03.2013 08:07
(3) PowerBoy,
можно также упомянуть про регламентное задание в типовых конфигурациях
выполняющих пересчет итогов.

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

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

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

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


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

...Показать Скрыть
# Ответить
8. Yashazz 11.03.2013 12:54
Да, про разделение итогов было бы хорошо.
И ещё, лучше всё-таки писать так: "Если рег.ВидРегистра=Метаданные.СвойстваОбъектов.ВидРегистраНакопления.Остатки Тогда...", а не через СокрЛП
Ответили: (14)
# Ответить

Комментарии

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

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

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

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

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


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

...Показать Скрыть
# Ответить
5. adhocprog 11.03.2013 12:11
Полезная статья )
# Ответить
6. fomix 11.03.2013 12:28
Весьма полезная статья. Еще бы подробнее про полное обновление статистики в СУБД и очистку процедурного кэша после проведения пересчета.
Ответили: (7) (15)
# Ответить
7. albochkov 11.03.2013 12:32
(3), спасибо, забыл про этот момент. Дополню как будет время.
(6), регламентные задания в СУБД - изъезженная тема, подробной информации в сети много.
# Ответить
8. Yashazz 11.03.2013 12:54
Да, про разделение итогов было бы хорошо.
И ещё, лучше всё-таки писать так: "Если рег.ВидРегистра=Метаданные.СвойстваОбъектов.ВидРегистраНакопления.Остатки Тогда...", а не через СокрЛП
Ответили: (14)
# Ответить
9. melenaspb 11.03.2013 14:31
Поэтому нужно не забывать запускать полное обновление статистики в СУБД и очистку процедурного кэша после проведения пересчета.

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

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


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

Плюс поставил.
# Ответить
14. albochkov 11.03.2013 18:34
(8) Yashazz, а я последние годы периодически ломал голову - что же за переменная отвечает за тип регистра :).
Все время хотелось написать "Если рег.ВидРегистра=ВидРегистраНакопления.Остатки ..", а, оказывается, надо было через Метаданные.
Спасибо!
Ответили: (16)
# Ответить
15. albochkov 11.03.2013 18:37
16. yuraos 11.03.2013 18:43
(14) Семен Семенович!
А как можно ищо?
Ответили: (17)
# Ответить
17. albochkov 11.03.2013 18:46
(16) Ну не зря же существует фраза "Век живи, век учись!" :)
+ 1 [ marchenko.y; ]
# Ответить
18. metmetmet 11.03.2013 23:10
Спасибо автору, хорошая статья, добавила понимания работы итоговых таблиц на уровне СУБД.

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

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

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


?

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

По поводу прироста - если такая операция давно не делалась, то прирост ощутим (количественно не скажу). Если её делать каждый месяц... То явного прироста не будет.
Ответили: (24) (28)
# Ответить
24. sanches 12.03.2013 09:04
(23) DenisCh, спасибо. ТИИ не подойдет, поскольку база большая , больше 30Гиг, работают каждый день. Думаю, средствами SQl придется решать проблему.
Ответили: (25) (28)
# Ответить
25. DenisCh 12.03.2013 09:21
(24) sanches, Ну, это не проблема :-)
Запрос по выявлению пишется по метаданным за 5 минут.
На удаление - ещё 3...
+ 1 [ sanches; ]
# Ответить
26. ksai 12.03.2013 09:42
(15) albochkov,

Спасибо!
# Ответить
27. fomix 12.03.2013 09:54
(15)Спасибо за ссылки!
# Ответить
28. yuraos 12.03.2013 18:23
(20)(23)(24)
sanches,
вот здеся есть много вякой вкуснятины для 1С-77
правда требуется ВК 1cpp.dll
--
в том числе обработка "Установка ТА", которая:
позволяет переустанавливать ТА,
расчитывая итоги регистров прямыми запросами 1с++
Позволяет также:
- пересчитать итоги по указанным регистрам (остатков и оборотов);
- все действия можно проводить в разделенном режиме (устанавливается блокировка);
- каждый месяц открывать за вас новый период, не выгоняя срочно всех из базы;
Ответили: (29) (30) (97)
# Ответить
29. sanches 12.03.2013 18:38
(28) yuraos, Спасибо! Посмотрю
# Ответить
30. CheBurator 12.03.2013 18:48
(28) не работает под дбф.
Ответили: (33)
# Ответить
31. CheBurator 12.03.2013 18:50
Коллеги, а поясните неграмотному.
Если при расчетах задним числом. модифицируются промежуточные и актуальные итоги. и вдруг получается в итогах ноль. Итог - это по сути куча. Куча - всегда итог правильный, например нулевой. Почему тупо скулем не удалить нулевые итоги...?????
Ответили: (32) (34)
# Ответить
32. albochkov 12.03.2013 19:00
(31) CheBurator, можно и напрямую в СУБД удалить. Лично я бы так и делал, но для массового применения такую рекомендацию никогда не дам.
Ответили: (35)
# Ответить
33. yuraos 12.03.2013 19:03
(30) CheBurator, да не работает,
там запросы писать надо по другому и
желательно прирулить какие-нибудь примочки, чтобы
прямые запросы в dbf в монопольном режиме работали.
:)
...
но клиент просил

Спасибо, а что-нибудь для 77 и 2000 SQL можете посоветовать? Наверняка там такая же ситуация.
Ответили: (36)
# Ответить
34. yuraos 12.03.2013 19:07
(31)
а платформа сама не удаляет эти нулевые записи?
иначе бы таблицы итогов пухли бы ...
ну может не так, когда по измерениям расходняк в движениях делается
но пухли бы точно.
Ответили: (97)
# Ответить
35. CheBurator 12.03.2013 19:16
(32) хм.. а почему..? скуль же вроде сам все разложит/проиндексирует..?
Ответили: (37)
# Ответить
36. CheBurator 12.03.2013 19:16
(33) прямые запросы в дбф в монопольном режиме чтобы работали - это уже вроде как давно есть такая возможность
Ответили: (39)
# Ответить
37. albochkov 12.03.2013 19:22
(35) с точки зрения техники все отлично - хоть руками удаляйте своими запросами, хоть методами встроенного языка - эффект будет один и тот же. Но для написания прямых запросов к базе, модифицирующих данные, нужны прямые руки и понимание смысла, а похвастаться этим могут не все :).
# Ответить
38. Diversus 12.03.2013 22:14
(0) Интересно, а нет ли у кого скрипта на SQL, чтобы удалил лишние нулевые значения?
Да и быстрее это дело было бы...
Ответили: (45)
# Ответить
39. yuraos 13.03.2013 05:55
(36)
а не кто и не говорит что эти примочки к 1С
для монопольного режима какая-то новость
(разве что субъективно :) ).
--
просто их надо будет прикручивать,
если захочется что бы прямые запросы в dbf
работали в монопольном режиме.
# Ответить
40. maldinitaly 13.03.2013 10:47
Спасибо, огромное автору за статью.Все четко и понятно.Плюс
# Ответить
41. maxpiter 13.03.2013 10:55
albochkov, т.е. вы хотите сказать, что можно просто удалить в регистре остатков все нулевые значения?
Правильно ли я понимаю, что в регистре остатков нулевых значений в принципе не должно быть, а 0 это ошибка в логике пересчета регистров?

p.s. Я сам про это думал и как-то даже на тестовой удалял (SQL запросом), но на рабочую перенести так и не решился, хотя никаких отклонений в работе системы выявлено не было.
Ответили: (46)
# Ответить
42. rassylka-new@yandex.ru 13.03.2013 11:11
Все просто прекрасно с технической стороны, просто здорово и весело, НО какой эффект это дает в реальных боевых условиях (я сейчас не говорю про теоретические аспекты а-ля лишние ресурсы участвующие в блокировках)? Есть какие-нибудь статистические данные хоть у кого-нибудь?
Ответили: (44) (47)
# Ответить
43. Kopman 13.03.2013 11:32
Спасибо за статью..
сделал генератор скрипта для проверки таблиц итогов, основываясь на запросах автора статьи.
http://infostart.ru/public/177538/
# Ответить
44. maxpiter 13.03.2013 11:50
(42) у меня вышло, что для таблиц:
РезервыТМЦ, доля нулевых записей на таблицу составила 53%
ПланыПродаж, 23%
остальные регистры не более 5%
# Ответить
45. maxpiter 13.03.2013 12:13
46. albochkov 13.03.2013 12:32
(41) - удалить нулевые записи нужно не в регистре остатков, а таблице итогов регистра остатков. Появление нулевых записей - это нормальная работа системы и не является ошибкой. Конечно, было бы хорошо, если бы платформа сама проверяла наличие нулей после окончания проведения документов и удаляла их, то это требовало бы дополнительных затрат ресурсов. Но это лишь предположение - разработчикам платформы видней почему так сделано.
Ответили: (49) (58)
# Ответить
47. albochkov 13.03.2013 12:36
(42) - конкретный пример, побудивший написать статью - база УТ 10.3, года 3 не пересчитывали итоги, база небольшая - около 40 Гб чистых данных. В результате в актуальных итогах только по регистру партий 300 тысяч записей, из них 290 тысяч - нулевые. Длительность проведения одной реализации - 2,9 с.
После пересчета итогов производительность упала - 5,1 с. на 1 реализацию.
После обновления статистики - 0,9 с. на 1 реализацию.
Примерно трехкратный прирост.
Но каждая ситуация индивидуальна.
Ответили: (51) (95)
+ 1 [ 1yh1; ]
# Ответить
48. Diversus 13.03.2013 12:36
(0) (45)

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

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

Потом запросом сравнивать по два регистра из этих двух баз что получается и где есть различия.
Если различий нет, то можно смело использовать в повседневной жизни, если есть станет ясно что делать дальше и какие записи не удалять...
# Ответить
49. maxpiter 13.03.2013 12:48
(46) именно это я и хотел выразить, видимо не совсем ясно донес мысль :)
Удалить нулевые записи в таблицах промежуточных итогов.
# Ответить
50. skyp 13.03.2013 13:51
Большое спасибо за статью!
Очень информативно, кратко и действенно. Очень качественное дополнение к ЖКК.
# Ответить
51. rassylka-new@yandex.ru 13.03.2013 13:51
(47) Впечатляющий прирост. Спасибо!
# Ответить
53. Kopman 14.03.2013 07:24
Заметил в базе следующую ситуацию, таблицы итогов по нескольким регистрам содержат 1-2 нулевых записей начиная с 2201-02-01 00:00:00.000 и смещение 2000(т.е щас 4013-03..) получаются даты совершенно нереальные.
Простыми расчетами выходит, что там периодов итогов 1812*12=21744 штук. Умножив это на число нулевых записей в каждом периоде можно сильно удивиться:-)
# Ответить
54. l-Rain 14.03.2013 10:50
Спасибо, полезно.
# Ответить
55. YPermitin 15.03.2013 14:16
Отличная статья!
# Ответить
56. Ibrogim 15.03.2013 14:32
+
из остатка на 01.11.3999 отнимается списанное количество.
Найдут потомки таблицы 1С и будут думать, что мы предсказали конец света 1 ноября 3999 года
# Ответить
57. TrinitronOTV 16.03.2013 08:39
Спасибо за статью. Много нового почерпнул для себя
# Ответить
58. lustin 17.03.2013 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 (просмотр).
Ответили: (79) (87) (128)
+ 103 [ 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; ]
# Ответить
59. pulpik 19.03.2013 13:59
Всем добрый день. Благодарю автора за статью. Прояснила нашу ситуацию.
БД - SQL 11 Gb
Это бухгалтерия за один год.
Выявились проблемы при формировании отчета Обороты счета за год по 20 счету по 3 субконто + подразделения.
за 1 кв отчет Формируется в течении 20 секунд
за 2 квартала 8 минут
за три и четыре квартала отчет не формируется...

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

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

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


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

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

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

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

Если не нужны, то как их можно отключить? Ну так что бы навсегда :)
# Ответить
72. echo77 21.03.2013 08:51
Интересный вопрос: при выгрузке базы(средствами 1С в .dt) итоги выгружаются? Или они заново расчитываются при загрузке?
Ответили: (73)
# Ответить
73. Aleksey.Bochkov 21.03.2013 09:37
(72) - в 8.2 итоги не выгружаются, т.к. это бессмысленно и их при загрузке всегда можно заново посчитать. Выгружается их статус - включены\отключены и дата расчета (таблица AccumRgOpt* с одной строкой).
В 8.1 вроде еще выгружались, но точно не уверен.
# Ответить
74. Martinian 21.03.2013 09:53
Прошу прощения за вопрос: для файловых баз 1С:8 тема актуальна?
Ответили: (75)
# Ответить
75. headMade 21.03.2013 17:22
(74) Martinian,
см. в (62) - уже отвечали.


"файловый вариант - это тоже работа с СУБД, с теми же табличками и алгоритмами. Просто СУБД встроена в 1С. Соответственно, пересчет итогов для файлового варианта также актуален."
# Ответить
76. Степанова Н. 22.03.2013 17:11
Я думаю мне это пригодится. Обязательно возьму на заметку
# Ответить
77. Геннадьевич 22.03.2013 18:27
Спасибо за информацию, буду тестировать.
Не увидел, как это повлияет на файловый вариант базы?
Ответили: (118)
# Ответить
78. rеd80 23.03.2013 03:20
По умолчанию для регистров существуют итоги по месяцам и актуальные итоги (только для регистров остатков).

У регистров бухгалтерии тоже есть актуальные итоги.
Ответили: (81)
# Ответить
79. rеd80 23.03.2013 04:34
(58) lustin, Даже не знаю что полезнее, статья или комментарий...
Ответили: (80)
# Ответить
80. lustin 23.03.2013 05:02
(79) rеd80, я бы в комплексе рассматривал. Тем более что Алексей Бочков скорее всего тоже в курсе того что я написал. Как сказал Вячеслав - проблема известная, но на данный момент так спокойно и коротко на Инфостарте (да и в тырнете) не описана - Алексей собственно и сделал такую статью.

Меня же зацепило "разработчикам платформы виднее" ;-).
Ответили: (82)
# Ответить
81. Aleksey.Bochkov 23.03.2013 11:32
(78) - регистры бухгалтерии - это тоже регистры остатков.
Ответили: (83)
# Ответить
82. Aleksey.Bochkov 23.03.2013 11:41
(80) - Алексей, поясню эту фразу :)
1) Все-таки, решение проблемы с нулевыми записями на уровне платформы не такое тривиальное, есть разные варианты и везде есть плюсы и минусы. Вряд ли можно угодить всем. А переложить ответственность за чистку итогов на конечного пользователя системы - в принципе, хороший вариант.
2) Стараюсь быть осторожен в формулировках относительно работы фирмы 1С. Уже несколько раз попадал на цензуру и замечания с их стороны. А в немилость впасть не хочется :).
# Ответить
83. yuraos 23.03.2013 13:48
(81) Aleksey.Bochkov,
еще какие регистры!
и еще каких остатков!!!
самые гемморойные наверное объекты в платформе.
:)
Особенно если какой-нибудь умник замутит субконто с примитивными типами
# Ответить
84. Miha.L 24.03.2013 01:54
Автору спасибо, полезная статья.
# Ответить
85. Martinian 24.03.2013 17:30
Поэтому нужно не забывать запускать полное обновление статистики в СУБД и очистку процедурного кэша после проведения пересчета.

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

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

Так что нет сервера SQL - негде обновлять статистику
# Ответить
87. CheBurator 25.03.2013 03:20
В принципе, не для десятковогигабайтных баз можно тупо почистить нулевые строки для всех периодов (м.б. за исключением последнего предшествующего текущему) как описал Лустин в (58), если вдруг окажется что нужных итогов нет - ну понесет платформа платформа при проведении допзатраты на их создание - но понесет эти допзатраты для одной номенклатуры один раз. А затраты на регулярное чтение при оставлении отчетов и обращения к итогам при обильном наличии пустых записей могут быть больше/чаще..? (рассуждаю применительно к файловым клюшкам)
# Ответить
88. p_tj 25.03.2013 19:42
Добрый вечер.

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

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

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

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

Спасибо.
Ответили: (89)
# Ответить
89. rеd80 26.03.2013 13:19
(88) p_tj, 1. Да, будет рассчитывать "на лету". Возьмет из таблицы остатков данные на начало периода, прибавит обороты оттуда же и отсчитает из таблицы движений строчки с конца. Такой хитрый алгоритм.
2. Если меняем данные в прошлом, например 25.05.12, система меняет обороты в мае 2012 и остатки во всех последующих итогах. Поэтому не рекомендуется рассчитывать итоги на будущее, в идеале - на последний прошедший месяц.
Ответили: (90)
+ 1 [ p_tj; ]
# Ответить
90. p_tj 26.03.2013 20:39
(89) Спасибо.
# Ответить
91. CheBurator 27.03.2013 23:03
Наваяна обработочка для 7.7 файловый режим
результат на моей маленькой базе
Итог по размерам: http://screencast.com/t/rHtIDzJlkD
# Ответить
92. CheBurator 27.03.2013 23:25
обработка здесь: http://infostart.ru/public/180018/
(может быть недоступна, т.к. не прошла еще модерацию)
# Ответить
93. CheBurator 28.03.2013 03:07
на файловых клюшках, объем исходной базы дбф+cl[ менее 5Гб
.
Перепровел тестовую и контрольные базы, пордяка 3200 доков, все задним числом, какого-то мега ощутимого прироста не наблюдал - процентов5-8, что можно списать на погрешности... Правда львиная доля тяжелых доков, по которым существенно упаковались таблицы итогов - у меня при заднем числе не перепроводятся, поэтом м.б. и не показательно у меня.. тем более что база достаточно маленькая - чуть более 4 гига всего, ожидаемый эффект м.б. на ней и не проявится...?
# Ответить
94. Ленкина 04.04.2013 11:12
Спасибо. Полезная статья.
# Ответить
95. Mudrii_Gankster 10.04.2013 14:14
(47) albochkov, А объем БД уменьшился? В моей БД происходит регламентная дефрагментация индексов, пересчета статистики, но пересчета итогов к сожалению делаю не так часто. Попробую сделать и проверить на результат проведения базы, давность данных 8 лет.

P.S. дописанная УТ 10.2
Ответили: (96)
# Ответить
96. Aleksey.Bochkov 10.04.2013 14:25
(95) - да, чистый объем информации в базе уменьшился процентов на 20%. Но это совсем уж запущенный случай :).
# Ответить
97. Bukaska 10.04.2013 15:16
(28) yuraos,
Спасибо за ссылки)))
(34) yuraos,
Чтобы таблицы итогов не опухли бы, для этого есть в бухучете инструмент: Закрытие месяца, закрытие года
А без этого было бы вообще жесть..

за статью ставлю однозначно "+", так как меня давно интересовал такой вопрос, для чего закрывать месяц, год, что будет... Теперь ясно что к чему)))
# Ответить
99. daho 17.04.2013 15:50
Как говориться "Это должен знать каждый!", кажется так брошюрка по Гражданской обороне называлась во времена хождения к комунизмам!.. :)) Ставлю плюс и больше сказать нечего.. Лишь только чтоб такая, полезная инфа почаще появлялась на просторах инфостарта.. что в принципе, к счастью, и происходит. Беру на вооружение.
# Ответить
100. denezhka 25.04.2013 17:15
Здравствуйте,

Очень полезная статья. Пересчитала итоги всех регистров и заметила, что в некоторых регистрах нулевые записи частично остались.
Например, РегистрНакопления.ТоварыПолученныеИтог до пересчета нулевых записей в актуальных итогах 271, после пересчета 63, а в помесячных итогах нулевые записи совсем не ушли.

Подскажите, пожалуйста, в чем может быть проблема?
# Ответить
101. denezhka 26.04.2013 16:08
По моей проблеме получается следующее:
У регистра в конфигураторе стоит признак "Разрешить разделение итогов", в пользовательском режиме данное свойство не стоит, после пересчета итогов через запрос SQL видно что нулевые записи в регистре остались, при этом количество нулевых записей в 2 раза меньше, чем записей всего. Если раскрыть эти нулевые записи, то видно, что у них поле _Splitter = 1. Т.е. к каждой ненулевой записи, у которой _Splitter = 0 таблицы итога создалась нулевая запись, у которой _Splitter = 0.
Ответили: (104)
# Ответить
102. rise 04.06.2013 15:44
Похожим образом выполняется пересчет итогов по месяцам.
Необходимо использовать метод "УстановитьПериодРассчитанныхИтогов()" - пересчитать можно, например, только несколько последних месяцев и не нагружать систему лишним пересчетом прошлых лет.

Подскажите пожалуйста, что именно делает "УстановитьПериодРассчитанныхИтогов"? Почему рекомендуется использовать этот метод, а не "ПересчитатьИтогиЗаПериод"?

Правильно ли я понимаю, что "ПересчитатьИтогиЗаПериод" обновит данные по месяцам за выбранный период?
# Ответить
103. Ele1234567 11.04.2014 14:39
Спасибо за материал!
# Ответить
104. nixel 28.05.2014 14:33
(101) denezhka, при выключении разделения итогов столбец _Splitter физически из таблицы итогов не удаляется. У вас в итогах остались записи с тех времен, когда разделение итогов было включено (об этом свидетельствует значение 1 в сплиттере). Перерасчет итогов добавил строчку для выключенного разделителя (значение сплиттера 0). Интуитивно догадываюсь, что можно проапдейтить записи с заменной сплиттера на 0 в строках, где сумма по всем значениям сплиттера для данного набора измерений равна нулю. Но на ваш страх и риск и только на копии. По-хорошему, это действие как раз и должно проводиться при перерасчете итогов, странно, что платформа ведет себя таким образом.

P.S. По лицензионному соглашению 1С разработчики не имеют что-либо менять в скульных базах в обход платформы :)
Ответили: (106) (113)
# Ответить
105. JohnConnor 18.06.2014 10:45
хорошая статья, автору спасибо!
# Ответить
106. AlexanderKai 05.11.2014 09:01
(104) nixel,
Да, только скорей всего это вступает в противоречие с лицензией от Майкрософт и с гражданским кодексом РФ.

Статья 1334. Исключительное право изготовителя базы данных
1. Изготовителю базы данных, создание которой (включая обработку или представление соответствующих материалов) требует существенных финансовых, материальных, организационных или иных затрат, принадлежит исключительное право извлекать из базы данных материалы и осуществлять их последующее использование в любой форме и любым способом (исключительное право изготовителя базы данных). Изготовитель базы данных может распоряжаться указанным исключительным правом. При отсутствии доказательств иного базой данных, создание которой требует существенных затрат, признается база данных, содержащая не менее десяти тысяч самостоятельных информационных элементов (материалов), составляющих содержание базы данных (абзац второй пункта 2 статьи 1260).
Никто не вправе извлекать из базы данных материалы и осуществлять их последующее использование без разрешения правообладателя, кроме случаев, предусмотренных настоящим Кодексом. При этом под извлечением материалов понимается перенос всего содержания базы данных или существенной части составляющих ее материалов на другой информационный носитель с использованием любых технических средств и в любой форме.
2. Исключительное право изготовителя базы данных признается и действует независимо от наличия и действия авторских и иных исключительных прав изготовителя базы данных и других лиц на составляющие базу данных материалы, а также на базу данных в целом как составное произведение.
3. В течение срока действия исключительного права на базу данных правообладатель по своему желанию может зарегистрировать базу данных в федеральном органе исполнительной власти по интеллектуальной собственности. К такой регистрации применяются правила статьи 1262 настоящего Кодекса.
(п. 3 в ред. Федерального закона от 12.03.2014 N 35-ФЗ)
Ответили: (122)
# Ответить
107. DoctorRoza 24.12.2014 09:18
Отмечусь! За статью спасибо! :)
# Ответить
108. CargoBird 05.01.2015 09:54
Присоединяюсь к благодарностям за статью.
Вопрос по мат.части.
Макс.дата рассчитываемых итогов 01.11.3999 00:00:00.
В приведенных таблицах видно даты с 4011.01.01 по 4011.11.01 и даже 5999.01.01.
Чем это объясняется?
Ответили: (109)
# Ответить
109. Aleksey.Bochkov 06.01.2015 03:02
(108) CargoBird,
Для MS SQL, как правило, используется сдвиг дат на 2000 лет вперед.
Обусловлено ограничениями MS SQL на минимальное значение даты.
+ 1 [ cargobird; ]
# Ответить
110. bashirov.rs 30.04.2015 08:36
Отличная статья! Спасибо. Пересчет итогов делаю 1 раз в месяц. Закрытие месяца происходит быстрее- было 2-3 часа, стало 20-30 мин.
# Ответить
111. Katren 12.05.2015 08:13
В самом простом случае помогает не ПересчитатьТекущиеИтоги(), а ПересчитатьИтоги(), лучше даже с отбором по нужным регистром
# Ответить
112. Aleksey.Bochkov 09.06.2015 05:07
UPD - добавил в конце про фрагментацию индексов при пересчете итогов.
# Ответить
113. CheBurator 10.06.2015 00:17
(104) "По лицензионному соглашению 1С разработчики не имеют что-либо менять в скульных базах в обход платформы :)"
я думаю, это - фигня.
очень сомнительно, когда в лицензионном соглашении фигурируют ограничения, накладываемые на использование продуктов третьих фирм.

скуль - 1сине не принадлежит.
и что там кто и как в скуле будет делать - пофиг.
если в случае проблем 1с скажет типа "структура вашей базы в скуле не соответсвует типовому шаблону построения 1Сной базы" - тады да... но \то имхо совсем не относится к тому что я в скульной базе что-то в обход платофрмы сделаю. можем мне какой-нить тривиальный update на 100 миллионов записей быстрей скулем сделать чем через всяких передастов.
Ответили: (117)
# Ответить
114. El_Loco 10.06.2015 23:56
Есть база КА 1.1 ms sql на 26 Гб. Работает около 15 пользователей.
Сейчас итоги пересчитываю два раза в неделю. Сама процедура занимает около 1,5 часа.
Я так понимаю, что чаще делать смысла нет?
Ответили: (115)
# Ответить
115. Aleksey.Bochkov 18.07.2015 02:19
UPD - добавил вариант решения для запущенных случаев.

(114) El_Loco, все записит от интенсивности работы пользователей. Если после пересчета итогов время выполнения запросов не уменьшается, то чаще делать нет смысла.. можно, наверное, даже реже.
# Ответить
116. dgolovanov 19.07.2015 00:55
Здравствуйте. При выгрузке в DT и обратной загрузке нулевые записи удаляются?
Ответили: (121)
# Ответить
117. mkalimulin 19.07.2015 01:20
(113) CheBurator, Вовсе это не фигня. Читай лиц. соглашение. Там русским по белому написано: не сметь ничего делать с нашей базой иначе, как через нашу платформу. И это понятно почему.
Ответили: (122)
# Ответить
118. pisarevEV 24.08.2015 07:27
можно вопрос: если регулярно делается полное перепроведение всех документов (77) в базе, вопрос нулевых итогов теряет актуальность?
Ответили: (119)
# Ответить
119. Aleksey.Bochkov 24.08.2015 22:18
(118) pisarevEV,
Наоборот. Чем интенсивнее проводятся документы - тем быстрее появляются "нулевые" строки, и тем чаще требуется производить пересчет итогов.
Ответили: (120)
# Ответить
120. pisarevEV 25.08.2015 12:49
(119) Aleksey.Bochkov, а если перед перед проведением удалить файлы RG*, то после перепроведения мы получим итоги без нулевых записей?
Ответили: (121)
# Ответить
121. Aleksey.Bochkov 25.08.2015 22:12
(116) dgolovanov,
Платформа 8.3 выгружает в dt итоги наряду с движениями. Соответственно при восстановлении базы из dt они не пересчитываются, а загружаются из файла.

(120) pisarevEV,
К сожалению, я уже не помню назначение эти файлов.
Если вы удалите эти файлы, а потом перепроведете абсолютно все документы в базе, то это не сильно поможет, т.к. в итогах все равно будут нулевые записи.
Нужен именно пересчет итогов.
# Ответить
122. alexqc 30.09.2015 10:52
(117) mkalimulin, Мало ли что там написано. Пункты ЛС противоречащие законодательству - ничтожны. В (106) конкретно указано что именно противоречит.

Кроме того, на базу у 1С не может быть никаких прав в принципе - даже потенциальных. Поэтоу она принципиально и не может быть объектом ЛС. Могут быть какие-то иные документы, нормы, правила эксплуатации, отказы от гарантий при нарушении - но точно не ЛС, как раз ЛС тут не в тему.

Этот пункт легко оспорить, просто никому не надо (ибо геморрой без цели).
+ 1 [ bulpi; ]
# Ответить
123. tormozit 07.05.2016 11:22
Есть ли способ очистить таблицы итогов штатными средствами пусть и медленно? Сделал свертку регистра бухгалтерии и как всегда остатки остались ненулевыми на предшествующую дате свертки дату. Через СУБД очистить конечно могу, но хотелось бы по возможности штатный способ найти. Уже пробовал варианты
1. пересчет итогов методом менеджера
2. сдвинуть границу итогов на 1900г, потом сдвигать вперед
Эти способы не помогают (8.2.19).
Ответили: (124)
# Ответить
124. echo77 08.05.2016 11:16
(123) tormozit, попробуй отключить использование итогов для регистра, затем включить
Ответили: (125)
# Ответить
125. tormozit 08.05.2016 11:34
(124) echo77, конечно же свертку я делал с выключением итогов, а в конце их включил и только потом смотрел остатки.
# Ответить
127. tormozit 10.05.2016 08:52
Добавил инструмент "Управление итогами" в подсистему "Инструменты разработчика" в версию 3.62. Там
- показывается количество нулевых строк итогов и можно их удалять до заданного периода
- видно сколько строк итогов в каждом месяце
- можно очищать таблицы итогов
- можно выполнять все штатные операции с итогами
# Ответить
128. lustin 24.05.2016 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% случаев вопрос к бизнес-пользователям системы и прикладникам
# Ответить
129. CheBurator 24.05.2016 16:25
"что платформа 1С тут не причем: нулевые записи - в 90% случаев вопрос к бизнес-пользователям системы и прикладникам" - очень сильно сомневаюсь.
# Ответить
130. GROOVY 25.05.2016 11:10
Нулевые итоги, шикарно размножаются при разделении итогов, и при перепроведении "задним числом".
+ 2 [ Anton_BooR; lustin; ]
# Ответить
Внимание! За постинг в данном форуме $m не начисляются.
Внимание! Для написания сообщения необходимо авторизоваться
Текст сообщения*
Прикрепить файл






IE 2016