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

18.07.15

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    КонецЕсли;

КонецЦикла;

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

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

КонецЦикла;

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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


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

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

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

 

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

См. также

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

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

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

12000 руб.

06.12.2023    2980    13    1    

34

SALE! 20%

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

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

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

10000 8000 руб.

10.11.2023    3544    11    1    

34

SALE! 30%

PowerTools

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

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

3600 2520 руб.

14.01.2013    177758    1073    0    

849

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

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

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

14400 руб.

29.04.2020    27383    79    146    

59

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

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

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

4200 руб.

10.11.2015    61320    88    59    

73

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

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

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

20000 руб.

12.09.2019    11746    5    9    

7

Брандмауэр для сервера 1С Предприятие 8 - внешнее управление сеансами

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

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

3600 руб.

06.02.2017    31111    31    18    

47

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

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

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

12000 руб.

09.10.2019    10986    5    8    

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

Подскажите, пожалуйста, в чем может быть проблема?
101. denezhka 26.04.13 16:08 Сейчас в теме
По моей проблеме получается следующее:
У регистра в конфигураторе стоит признак "Разрешить разделение итогов", в пользовательском режиме данное свойство не стоит, после пересчета итогов через запрос SQL видно что нулевые записи в регистре остались, при этом количество нулевых записей в 2 раза меньше, чем записей всего. Если раскрыть эти нулевые записи, то видно, что у них поле _Splitter = 1. Т.е. к каждой ненулевой записи, у которой _Splitter = 0 таблицы итога создалась нулевая запись, у которой _Splitter = 0.
104. nixel 1403 28.05.14 14:33 Сейчас в теме
(101) denezhka, при выключении разделения итогов столбец _Splitter физически из таблицы итогов не удаляется. У вас в итогах остались записи с тех времен, когда разделение итогов было включено (об этом свидетельствует значение 1 в сплиттере). Перерасчет итогов добавил строчку для выключенного разделителя (значение сплиттера 0). Интуитивно догадываюсь, что можно проапдейтить записи с заменной сплиттера на 0 в строках, где сумма по всем значениям сплиттера для данного набора измерений равна нулю. Но на ваш страх и риск и только на копии. По-хорошему, это действие как раз и должно проводиться при перерасчете итогов, странно, что платформа ведет себя таким образом.

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

Статья 1334. Исключительное право изготовителя базы данных
1. Изготовителю базы данных, создание которой (включая обработку или представление соответствующих материалов) требует существенных финансовых, материальных, организационных или иных затрат, принадлежит исключительное право извлекать из базы данных материалы и осуществлять их последующее использование в любой форме и любым способом (исключительное право изготовителя базы данных). Изготовитель базы данных может распоряжаться указанным исключительным правом. При отсутствии доказательств иного базой данных, создание которой требует существенных затрат, признается база данных, содержащая не менее десяти тысяч самостоятельных информационных элементов (материалов), составляющих содержание базы данных (абзац второй пункта 2 статьи 1260).
Никто не вправе извлекать из базы данных материалы и осуществлять их последующее использование без разрешения правообладателя, кроме случаев, предусмотренных настоящим Кодексом. При этом под извлечением материалов понимается перенос всего содержания базы данных или существенной части составляющих ее материалов на другой информационный носитель с использованием любых технических средств и в любой форме.
2. Исключительное право изготовителя базы данных признается и действует независимо от наличия и действия авторских и иных исключительных прав изготовителя базы данных и других лиц на составляющие базу данных материалы, а также на базу данных в целом как составное произведение.
3. В течение срока действия исключительного права на базу данных правообладатель по своему желанию может зарегистрировать базу данных в федеральном органе исполнительной власти по интеллектуальной собственности. К такой регистрации применяются правила статьи 1262 настоящего Кодекса.
(п. 3 в ред. Федерального закона от 12.03.2014 N 35-ФЗ)
113. CheBurator 3119 10.06.15 00:17 Сейчас в теме
(104) "По лицензионному соглашению 1С разработчики не имеют что-либо менять в скульных базах в обход платформы :)"
я думаю, это - фигня.
очень сомнительно, когда в лицензионном соглашении фигурируют ограничения, накладываемые на использование продуктов третьих фирм.

скуль - 1сине не принадлежит.
и что там кто и как в скуле будет делать - пофиг.
если в случае проблем 1с скажет типа "структура вашей базы в скуле не соответсвует типовому шаблону построения 1Сной базы" - тады да... но \то имхо совсем не относится к тому что я в скульной базе что-то в обход платофрмы сделаю. можем мне какой-нить тривиальный update на 100 миллионов записей быстрей скулем сделать чем через всяких передастов.
117. mkalimulin 1148 19.07.15 01:20 Сейчас в теме
(113) CheBurator, Вовсе это не фигня. Читай лиц. соглашение. Там русским по белому написано: не сметь ничего делать с нашей базой иначе, как через нашу платформу. И это понятно почему.
122. alexqc 150 30.09.15 10:52 Сейчас в теме
(117) mkalimulin, Мало ли что там написано. Пункты ЛС противоречащие законодательству - ничтожны. В (106) конкретно указано что именно противоречит.

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

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

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

Правильно ли я понимаю, что "ПересчитатьИтогиЗаПериод" обновит данные по месяцам за выбранный период?
103. Ele1234567 11.04.14 14:39 Сейчас в теме
105. JohnConnor 64 18.06.14 10:45 Сейчас в теме
хорошая статья, автору спасибо!
107. DoctorRoza 24.12.14 09:18 Сейчас в теме
Отмечусь! За статью спасибо! :)
108. cargobird 306 05.01.15 09:54 Сейчас в теме
Присоединяюсь к благодарностям за статью.
Вопрос по мат.части.
Макс.дата рассчитываемых итогов 01.11.3999 00:00:00.
В приведенных таблицах видно даты с 4011.01.01 по 4011.11.01 и даже 5999.01.01.
Чем это объясняется?
109. Aleksey.Bochkov 3660 06.01.15 03:02 Сейчас в теме
(108) CargoBird,
Для MS SQL, как правило, используется сдвиг дат на 2000 лет вперед.
Обусловлено ограничениями MS SQL на минимальное значение даты.
cargobird; +1 Ответить
110. bashirov.rs 31 30.04.15 08:36 Сейчас в теме
Отличная статья! Спасибо. Пересчет итогов делаю 1 раз в месяц. Закрытие месяца происходит быстрее- было 2-3 часа, стало 20-30 мин.
111. Katren 12.05.15 08:13 Сейчас в теме
В самом простом случае помогает не ПересчитатьТекущиеИтоги(), а ПересчитатьИтоги(), лучше даже с отбором по нужным регистром
112. Aleksey.Bochkov 3660 09.06.15 05:07 Сейчас в теме
UPD - добавил в конце про фрагментацию индексов при пересчете итогов.
114. AlexeyPapanov 458 10.06.15 23:56 Сейчас в теме
Есть база КА 1.1 ms sql на 26 Гб. Работает около 15 пользователей.
Сейчас итоги пересчитываю два раза в неделю. Сама процедура занимает около 1,5 часа.
Я так понимаю, что чаще делать смысла нет?
115. Aleksey.Bochkov 3660 18.07.15 02:19 Сейчас в теме
UPD - добавил вариант решения для запущенных случаев.

(114) El_Loco, все записит от интенсивности работы пользователей. Если после пересчета итогов время выполнения запросов не уменьшается, то чаще делать нет смысла.. можно, наверное, даже реже.
116. dgolovanov 19.07.15 00:55 Сейчас в теме
Здравствуйте. При выгрузке в DT и обратной загрузке нулевые записи удаляются?
121. Aleksey.Bochkov 3660 25.08.15 22:12 Сейчас в теме
(116) dgolovanov,
Платформа 8.3 выгружает в dt итоги наряду с движениями. Соответственно при восстановлении базы из dt они не пересчитываются, а загружаются из файла.

(120) pisarevEV,
К сожалению, я уже не помню назначение эти файлов.
Если вы удалите эти файлы, а потом перепроведете абсолютно все документы в базе, то это не сильно поможет, т.к. в итогах все равно будут нулевые записи.
Нужен именно пересчет итогов.
123. tormozit 7136 07.05.16 11:22 Сейчас в теме
Есть ли способ очистить таблицы итогов штатными средствами пусть и медленно? Сделал свертку регистра бухгалтерии и как всегда остатки остались ненулевыми на предшествующую дате свертки дату. Через СУБД очистить конечно могу, но хотелось бы по возможности штатный способ найти. Уже пробовал варианты
1. пересчет итогов методом менеджера
2. сдвинуть границу итогов на 1900г, потом сдвигать вперед
Эти способы не помогают (8.2.19).
124. echo77 1868 08.05.16 11:16 Сейчас в теме
(123) tormozit, попробуй отключить использование итогов для регистра, затем включить
125. tormozit 7136 08.05.16 11:34 Сейчас в теме
(124) echo77, конечно же свертку я делал с выключением итогов, а в конце их включил и только потом смотрел остатки.
126. пользователь 08.05.16 14:15
Сообщение было скрыто модератором.
...
127. tormozit 7136 10.05.16 08:52 Сейчас в теме
Добавил инструмент "Управление итогами" в подсистему "Инструменты разработчика" в версию 3.62. Там
- показывается количество нулевых строк итогов и можно их удалять до заданного периода
- видно сколько строк итогов в каждом месяце
- можно очищать таблицы итогов
- можно выполнять все штатные операции с итогами
fatman78; myoker; proonec; rudak_a; Albert_2008; aegoncharov; user777757; purgin; biformatus; DimaP; ingmar; Fatov_DI; pbabincev; CheBurator; lustin; Bukaska; vikad; +17 Ответить
129. CheBurator 3119 24.05.16 16:25 Сейчас в теме
"что платформа 1С тут не причем: нулевые записи - в 90% случаев вопрос к бизнес-пользователям системы и прикладникам" - очень сильно сомневаюсь.
130. GROOVY 2505 25.05.16 11:10 Сейчас в теме
Нулевые итоги, шикарно размножаются при разделении итогов, и при перепроведении "задним числом".
user598655_ilia-bers; charushkin; Anton_BooR; lustin; +4 Ответить
131. Viktor_Ermakov 363 30.11.16 21:31 Сейчас в теме
У меня вопрос к знатокам, ситуация такая: ЗУП 2.5 регистр накоплений "ВзаиморасчетыССотрудникамиОрганизации.ОстаткиИОбороты", есть записи с "Регистратор" = Неопределено, эти записи присутствуют только в виртуальной таблице, в физической этих записей нет. Вопрос, как можно удалить эти записи? Кодом не могу т.к. отбор по регистратору не могу сделать, пересчет итогов их не удаляет, Тестирование и испр не делал т.к. база очень большая. Подскажите кто знает пожалуйста!
132. kasper076 101 01.12.16 07:12 Сейчас в теме
(131) Откуда удалить-то? Из виртуальной таблицы что-ли?
133. Viktor_Ermakov 363 09.12.16 22:18 Сейчас в теме
(131) Вопрос решен, проблема в другом была.
134. mika_mika 1 12.04.17 12:28 Сейчас в теме
Спасибо за статью. Помогла решить проблему: после обновления вдруг запросы к регистрам накопления стали выдавать неверные результаты. После выполнения (цитата):
"1) отключаем всех пользователей и делаем бэкап базы средствами MSSQL;
2) генерируем запросы на очистку всех таблиц итогов по регистрам накопления:
В контексте базы данных выполняем запрос:
SELECT 'TRUNCATE TABLE ' + name FROM sys.tables
WHERE name like '_AccumRgT%'
Результат вывода копируем, вставляем в окно запроса и выполняем в контексте базы данных.
3) Запускаем пересчет итогов через Тестирование и исправление в Конфигураторе."
все встало на свои места.
135. user_2010 871 07.11.17 12:35 Сейчас в теме
Можно ли перерасчитать итоги одного регистра накопления? Или нужно всегда по всем регистрам перерассчитывать итоги?
136. user_2010 871 13.11.17 14:41 Сейчас в теме
(135)
Можно ли перерасчитать итоги одного регистра накопления? Или нужно всегда по всем регистрам перерассчитывать итоги


вопрос пока без ответа - может кто-то знает ответ?
137. user777757 14.06.18 10:21 Сейчас в теме
Спасибо за отличную статью. Почитал комментарии, вообще все вопросы отпали! :)
138. scherbakovya 20.09.18 09:48 Сейчас в теме
Если в свойствах БД стоит авто обновление статистики, нужно ли запускать принудительное обновление статистики в sql?
139. Gilev.Vyacheslav 1910 23.09.18 00:11 Сейчас в теме
(138) если она не успевает обновляться, то да
140. CTDEVIce 4 21.12.18 11:39 Сейчас в теме
Хм. Посмотрел несколько своих баз на УПП крутящихся на сервере (не файловые). Итоги актуальные, выставлены на последний день предыдущего месяца. Получается что они автоматически пересчитываются. Тогда зачем их еще пересчитывать?
141. zayden 17 20.03.19 07:23 Сейчас в теме
Прям зачитался. Много нового узнал.
142. user1194547 21.06.19 11:02 Сейчас в теме
Спасибо, очень полезная статья.
143. Ankare 91 13.02.20 12:17 Сейчас в теме
код

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

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

        РегистрыНакопления[Рег.Имя].УстановитьПериодРассчитанныхИтогов(Дата1, Дата2);
        РегистрыНакопления[Рег.Имя].ПересчитатьТекущиеИтоги();

    КонецЕсли;

КонецЦикла;
Показать


где дата1 и дата2 где-то в начале периода ведения учета,
вполне себе хорошо справляется с проблемой, быстро и качественно,
без установки периода рассчитанных итогов база некорректные записи не пересчитывает, может конечно с недавних версий платформы, так как статья старая
clarion807; +1 Ответить
146. ansh15 12.12.21 04:05 Сейчас в теме
Начиная с версии платформы 8.3.18 "Реализована возможность параллельного пересчета итогов регистров при реструктуризации информационной базы и при выполнении тестирования и исправления информационной базы. Для пересчета используются системные фоновые задания (идентификатор такого фонового задания SystemBackgroundJob.RecalcTotals). Реализован параметр Количество заданий пересчета итогов для диалога Параметры информационной базы. По умолчанию количество фоновых заданий пересчета итогов равно 4." (из описания программы на сайте вендора).
Выполнение этой трудоемкой операции(пересчет итогов), при наличии современных высокопроизводительных ресурсов, должно ощутимо ускориться, по идее.
149. serko8547 110 04.10.22 12:48 Сейчас в теме
Спасибо тебе, добрый человек! Столкнулся с тем, что у меня есть таблицы в SQL не привязанные ни к какой таблице в 1с. в ней хранятся итоги. никакие перепроведения не влияют на эти итоги, никоим образом. пересчет итогов тоже. почистил вашим способом таблицы, запустил пересчет итогов, и эти таблицы не заполнились. а места занимали больше всего! 16 млн строк!
благодарю Вас. Возможно, я не прав, и что-то не так сделал, но из 42 гиг занятых базой, освободилось 17 гиг.
150. mars2005 27 24.01.23 21:17 Сейчас в теме
Очень хорошая статья. Применил в деле.
Спасибо автору.
Оставьте свое сообщение