Причины реструктуризации. Практический пример

17.08.18

База данных - Технологический журнал

Получение и анализ подробной информации о причинах реструктуризации.

Коллеги, хотел бы с вами поделиться свежей историей из собственной практики. В один момент, при обновлении конфигурации получил реструктуризацию сразу нескольких регистров накопления с большим объемом данных + регистр бухгалтерии в нагрузку. При этом текущие работы не подразумевали столь масштабных изменений. 

Стал искать причину. Анализ через "Сравнение/объединение" ответов на вопрос "Что является причиной" не дал (изменена по чуть-чуть почти вся конфигурация). Из интернета, документации и бесед с коллегами следовало проверять:

  • изменение общих реквизитов;
  • изменение регистрации в планах обменов;
  • изменение в ролях;
  • изменения в регистраторах;

Быстро проблему обнаружить не смог, а смотреть подробно каждое изменение в хранилище не радовало.

Решение оказалось простым: технологический журнал. В техжурнал пишется подробно, по какой причине платформа решила выполнить реструктуризацию, в т.ч. и для регистров накопления и сведений. Описывать настройку техжурнала не буду – это тема простая и давно разобрана, но приведу на всякий случай содержание моего logcfg.xml:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
    <system level="trace"/>
    <log history="48" location="D:\Database\Log">
        <event>
            <eq property="EventType" value="Workflow"/>
        </event>
        <event>
            <eq property="EventType" value="Analysis"/>
        </event>
        <event>
            <eq property="EventType" value="Restructuring"/>
        </event>
        <property name="RestructMode"/>
        <property name="Description"/>
        <property name="Duration"/>
    </log>
    <dump create="false"/>
</config>

И в заключении приведу часть самого техжурнала:
31:55.157190-0,SYSTEM,3,Description=Starting restructuring of accumulation register for РегистрНакопления.ЗапасыНаСкладах
31:55.157191-0,SYSTEM,3,Description=Starting analysis of changes for РегистрНакопления.ЗапасыНаСкладах
31:55.157192-0,SYSTEM,3,Description=Analyzing РегистрНакопления.ЗапасыНаСкладах. Hash column usage not changed. Does not require restructuring,RestructMode=None
31:55.157193-0,SYSTEM,3,Description=Analyzing РегистрНакопления.ЗапасыНаСкладах. Register type was balance and it remains balance
31:55.157194-0,SYSTEM,3,Description=Analyzing РегистрНакопления.ЗапасыНаСкладах. Data lock control mode not changed. Does not require restructuring,RestructMode=None
31:55.157195-0,SYSTEM,3,Description=Analyzing РегистрНакопления.ЗапасыНаСкладах. Register type not changed. Does not require restructuring,RestructMode=None
31:55.157196-0,SYSTEM,3,Description=Analyzing РегистрНакопления.ЗапасыНаСкладах. Compatibility mode 8.3.2 not changed. Does not require restructuring,RestructMode=None
31:55.157197-0,SYSTEM,3,Description=Analyzing РегистрНакопления.ЗапасыНаСкладах. Totals splitting not changed. Does not require restructuring,RestructMode=None
31:55.157198-0,SYSTEM,3,Description=Analyzing РегистрНакопления.ЗапасыНаСкладах. Recorders cardinality not changed. Does not require restructuring,RestructMode=None
31:55.157199-0,SYSTEM,3,Description=Analyzing РегистрНакопления.ЗапасыНаСкладах. Recorder deleted. Requires full restructuring,RestructMode=Full
31:55.157200-0,SYSTEM,3,Description=Analyzing РегистрНакопления.ЗапасыНаСкладах. РегистрНакопления.ЗапасыНаСкладах.Измерение.Организация. Dimension type not changed. Does not require restructuring,RestructMode=None
31:55.157201-0,SYSTEM,3,Description=Analyzing РегистрНакопления.ЗапасыНаСкладах. РегистрНакопления.ЗапасыНаСкладах.Измерение.Организация. Dimension order not changed. Does not require restructuring,RestructMode=None
31:55.157202-0,SYSTEM,3,Description=Analyzing РегистрНакопления.ЗапасыНаСкладах. РегистрНакопления.ЗапасыНаСкладах.Измерение.Организация. Dimension indexing not changed. Does not require restructuring,RestructMode=None
31:55.157203-0,SYSTEM,3,Description=Analyzing РегистрНакопления.ЗапасыНаСкладах. РегистрНакопления.ЗапасыНаСкладах.Измерение.Организация. Dimension usage in totals not changed. Does not require restructuring,RestructMode=None
31:55.157204-0,SYSTEM,3,Description=Analyzing РегистрНакопления.ЗапасыНаСкладах. РегистрНакопления.ЗапасыНаСкладах.Измерение.Номенклатура. Dimension type not changed. Does not require restructuring,RestructMode=None
31:55.157205-0,SYSTEM,3,Description=Analyzing РегистрНакопления.ЗапасыНаСкладах. РегистрНакопления.ЗапасыНаСкладах.Измерение.Номенклатура. Dimension order not changed. Does not require restructuring,RestructMode=None

и т.д.

ключевую запись (Recorder deleted. Requires full restructuring,RestructMode=Full) выделил жирным. Из чего следует, что в моем случае коллега случайно удалил регистрацию движений по регистру накопления ЗапасыНаСкладах для нескольких документов. Ошибку исправили.

Спасибо за внимание )))

Вступайте в нашу телеграмм-группу Инфостарт

причины реструктуризации поиск регистры накопления регистры сведений регистры бухгалтерии

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

HighLoad оптимизация Технологический журнал Разработчик 1С:Предприятие 8 Бесплатно (free)

В этой статье рассматривается только первый этап диагностики производительности: как получить длительный SQL-запрос из технологического журнала, связать его с прикладным кодом 1С и точно локализовать место выполнения. Причины длительности и оптимизация самого запроса разбираются уже после локализации.

21.09.2026    823    markbraer    1    

5

Технологический журнал Системный администратор Разработчик 1С 8.3 Бесплатно (free)

База ERP, 400 пользователей, сервер загружен, 1С подвисает, доступа к SQL Server нет. Оптимизировать можно бесконечно, вопрос в том, с чего начать. ЦУП это платная лицензия и отдельная стройка, а технологический журнал встроен в платформу, включается одним файлом и на боевой базе в рабочее время не вызвал ни одной жалобы от пользователей. Разбираю, что он собой представляет, где лежит настройка, как читается строка события и что означает каждое из одиннадцати событий, которые я видел в журналах боевой ERP. Плюс рабочий logcfg.xml, три ловушки, на которых отчёт получается красивым и неверным, и шесть находок за один прогон.

07.09.2026    1905    nedomolkov.ivan    0    

3

Технологический журнал Системный администратор Разработчик 1С 8.3 Абонемент ($m)

Обработка включает технологический журнал, читает его и отвечает на 13 вопросов человеческим языком: кто блокирует базу, какой запрос к СУБД самый тяжёлый, какой код суммарно грузит СУБД больше всех, какой вызов съедает память. Настройка идёт галочками с человеческими формулировками, logcfg.xml обработка пишет сама, права администратора для этого обычно не нужны. Отдельная кнопка сводит журнал в один markdown-файл: на боевой ERP 288 МБ и 2 055 229 строк ужались в 17 459 знаков, файл кладётся в чат с нейросетью и разбирается за минуту. Имена баз и пользователей в нём заменены псевдонимами. Без внешних компонент, к СУБД обращений нет.

10 стартмани

07.09.2026    1070    2    nedomolkov.ivan    0    

2

Технологический журнал Мониторинг Мессенджеры и боты Системный администратор Разработчик 1С 8.3 1С 8.5 Россия Абонемент ($m)

Лёгкое расширение для 1С, которое ловит ошибки — включая упавшие внутри транзакции проведения и не замеченные типовыми средствами — и сразу шлёт алерты в Telegram и на почту. Не заимствует ни одного объекта конфигурации, ставится на любую базу (типовую или самописную, с БСП или без) за 5 минут. Дедуплицирует повторы, не спамит при шторме ошибок, маскирует персональные данные перед отправкой наружу. Работает даже при отключённом администратором штатном Журнале регистрации — у расширения есть собственный независимый журнал самодиагностики.

3 стартмани

25.08.2026    660    1    KonMa    0    

2

Технологический журнал Системный администратор 1С 8.3 Бесплатно (free)

Профессиональное (почти) руководство по поиску и устранению утечек памяти в 1С: анализ дампов, технологического журнала, временного хранилища, форм, фоновых заданий и циклов удержания. Полный алгоритм расследования мёртвого кэша.

24.08.2026    1476    Ninel_S    3    

2

Технологический журнал Разработчик 1С 8.3 Россия Бесплатно (free)

Устал парсить ТЖ 1С gawk-скриптами каждый раз заново - собрал нормальный инструмент. DuckDB под капотом, разбор ТЖ, планов под MS SQL и PostgreSQL, AI-объяснения опционально.

08.07.2026    6021    nazarovss    33    

27

Технологический журнал Системный администратор Разработчик Бесплатно (free)

Чтобы перейти от тушения инцидентов в 1С к превентивному подходу, нужно заранее видеть рост данных, блокировок, времени выполнения операций и другие признаки будущих проблем. Разбираем, какие метрики технологического журнала 1С и СУБД стоит мониторить в реальном времени и как использовать простые ML-модели – регрессию и классификацию – для прогноза падения производительности. Объясняем, как автоматически выявлять аномалии в поведении пользователей и фоновых заданий, настраивать proactive-алерты за часы или дни до инцидента и создавать тикеты в ITSM-системах на превентивные действия.

02.07.2026    4717    aidar_safin    17    

32

Технологический журнал Разработчик Бесплатно (free)

Парсинг техжурнала 1С – это не просто «распарсить JSON» или CSV, а работа с множеством неочевидных особенностей формата. Показываем, какие проблемы могут возникнуть из-за дублей свойств и событий, «полей-призраков», нестандартных имен свойств, разрозненного контекста, кавычек, апострофов и других нюансов, которые легко ломают парсеры и искажают результаты анализа. Объясняем, чем может помочь ИИ при работе с техжурналом и почему даже при использовании современных инструментов важно понимать внутреннюю логику логов. В статье собраны главные правила надежного парсинга и примеры ситуаций, где техжурнал может неожиданно показать свою «темную сторону».

17.06.2026    5409    Andreynikus    9    

26
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. SanyMaga 77 17.08.18 20:05 Сейчас в теме
Если у измерения свойство "ведущий" тогда получите реструктуризации тоже. А еще версионировние ))))
3. _KaA 115 20.08.18 09:58 Сейчас в теме
(1)
Для меня большим откровением стал тот момент, что изменение состава поля составного типа не отобразилось при сравнении/объединении... не логично как-то.
10. l1ike 23.08.18 12:55 Сейчас в теме
(3)
Ссылочные типы 1с хранятся в БД как два поля Тип и ГУИД, если в составной тип добавляется еще одна ссылка - то это не влечет реструктуризацию, если добавить, к примеру, строковый тип - будет реструктуризация.
2. user700035_6550355 37 20.08.18 08:36 Сейчас в теме
Как обычно виноваты кривые пальчики
4. maslennikov_ea 6 20.08.18 11:37 Сейчас в теме
а при сравнении (с бекапом) разве удаление регистрации из регистра не видно?!
7. _KaA 115 21.08.18 12:09 Сейчас в теме
(4) (6)

У меня правлено 70-80% конфигурации, коммитов около 100 -> я просто устану сравнивать )))
8. nvv1970 21.08.18 22:02 Сейчас в теме
(7) как вы до такого дотянули? 100??? 70% - это много лет разработки ))
5. kiruha 389 20.08.18 17:07 Сейчас в теме
А коллега не мог еще случайно удалить еще что нибудь ...
Как искать то будете ?
6. nvv1970 20.08.18 18:41 Сейчас в теме
Однако, автор молодец, что дальним маршрутом быстро добрался

Основной список обычно невелик:
- удаление регистратора из движений
- удаление значения перечисления
- удаление объектов
Но в если изменений много - глаза не помогут (
11. ProgrammistC 67 18.12.19 16:53 Сейчас в теме
(6) критерии отбора еще
9. Serg O. 337 22.08.18 07:24 Сейчас в теме
Отчет сравнения в файл можно выгрузить табличный... Или текстовый...Там удобнее что-то искать... Не думал, что тех.журнал так можно использовать, ставлю +
YuriOvs; jaroslav.h; +2 – Ответить
12. user612295_death4321 15.01.20 11:01 Сейчас в теме
Жаль, что похоже работает не на всех версиях платформы. На 8.3.9.2170 в режиме совместимости 8.2 - не работает :(
13. _KaA 115 21.01.20 09:15 Сейчас в теме
(12)

К сожалению нет времени проверять в других версиях, но и платформа, сказать откровенно, не нова...
14. kalyaka 1186 28.07.23 15:22 Сейчас в теме
Прекрасно работает на платформе 8.3.22.2106.
Чтобы быстро понять, где будет реструктуризация, можно поступить следующим образом: создать пустую базу, выполнить изменение, посмотреть технологический журнал.
В событиях Description нужно искать строку "type CHANGED", например вот такую
...Реквизит.Организация. Tabular section attribute type CHANGED. Requires full restructuring,RestructMode=Full
Далее, зная место возникновения реструктуризации, нужно проверить изменяемые типы и реквизиты.
15. kalyaka 1186 28.07.23 15:54 Сейчас в теме
Еще одно важно замечание: этот технологический журнал собирается на клиенте! Т.е. если у вас клиент-серверная база, то журнал нужно настраивать на клиенте. Файлы тех журнала будут складываться в подкаталоги вида 1cv8_NNNNN.

Если использовать команду "Обновить конфигурацию базы данных на сервере", то файлы будут в подкаталогах rphost_NNNNN на сервере 1С.
Для отправки сообщения требуется регистрация/авторизация