← На главную

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

Суть проблемы: почему 1С настаивает на реструктуризации?

Основная причина, по которой 1С инициирует длительную реструктуризацию в описанном сценарии, кроется в изменении метаданных и, как следствие, структуры ключевой колонки таблиц регистра в базе данных. Рассмотрим подробнее:

1. Каждый регистр в 1С (будь то регистр накопления, регистр бухгалтерии или регистр сведений, подчиненный регистратору) имеет ключевое поле, связывающее его с документами, — это поле Регистратор.
2. Поле Регистратор имеет составной тип. Это означает, что его тип данных в СУБД (например, SQL Server или PostgreSQL) фактически представляет собой комбинацию ссылок на все документы, которые потенциально могут делать движения по данному регистру.
3. Когда вы добавляете или удаляете документ из списка "Движений" регистра на закладке конфигуратора, вы фактически изменяете составной тип поля Регистратор. Даже если в базе ещё нет ни одного документа нового типа, или если удаляется тип документа, по которому нет записей, для СУБД это означает изменение структуры данных поля.
4. СУБД требует, чтобы структура данных была согласованной. Изменение типа колонки Регистратор требует перестроения соответствующей таблицы регистра, что в случае с большими таблицами оборачивается их полным копированием, созданием новой структуры, переносом данных и удалением старой. Это и есть та самая длительная реструктуризация.

Таким образом, логика 1С в данном случае вполне обоснована: она гарантирует целостность и корректность данных. Однако для разработчика или администратора, столкнувшегося с ошибкой, это становится серьезной проблемой, особенно когда речь идёт о терабайтах информации.

Оптимизированный механизм реструктуризации V2: официальное и наиболее эффективное решение

Платформа 1С:Предприятие, начиная с версии 8.3, предлагает существенно доработанный и оптимизированный механизм обновления структуры базы данных, известный как V2. Это не просто улучшение, а фактически новый подход к реструктуризации, разработанный для значительного сокращения времени проведения изменений в больших базах.

Что такое V2 и почему он быстрее?

Механизм V2 (от англ. "Version 2") был создан для устранения узких мест предыдущего механизма реструктуризации, который часто требовал полного копирования больших таблиц даже при незначительных изменениях метаданных. Ключевые преимущества V2 включают:

• Минимизация копирования таблиц: V2 старается по возможности избегать полного копирования таблиц. Например, при добавлении нового реквизита в шапку документа, имеющего множество табличных частей, старый механизм мог скопировать все связанные таблицы. V2 же изменяет только таблицу шапки, если это возможно.
• Оптимизация работы с индексами: V2 более интеллектуально работает с индексами, не всегда перестраивая их полностью, что также экономит время.
• Параллелизация: В некоторых случаях V2 может использовать параллельные операции, ускоряя процесс.
• Улучшенная обработка составных типов: Хотя изменение составного типа поля Регистратор по-прежнему требует особого внимания, V2 справляется с этим значительно быстрее за счёт более эффективного использования СУБД-специфичных команд.

На практике это означает, что операции, которые раньше занимали часы или дни, теперь могут быть выполнены за минуты или часы. Например, добавление реквизитов к документам или измерений к регистрам сведений в базе размером 400 Гб может сократиться с 2 часов до 15 минут. Изменение режима совместимости на базе 6 Тб ускорилось с 5 дней до 12 часов.

Условия использования V2

Для корректной работы механизма V2 необходимо соблюдение определённых требований к инфраструктуре:

1. Клиент-серверный вариант работы: Информационная база должна функционировать в клиент-серверном варианте (файл-серверный вариант не поддерживается).
2. Поддерживаемые СУБД: В качестве системы управления базами данных должен использоваться Microsoft SQL Server или PostgreSQL.
3. Установленная Java: На сервере 1С должна быть установлена Java 8 или более поздняя версия. Важно, чтобы разрядность Java (32-бит или 64-бит) совпадала с разрядностью сервера 1С.
4. Настройки для MS SQL Server: Для MS SQL Server должны быть разрешены подключения по TCP/IP для службы агента SQL. Это необходимо для взаимодействия 1С с СУБД на низком уровне.

Без выполнения этих условий 1С будет использовать старый (V1) механизм реструктуризации, даже если платформа достаточно свежая.

Как включить механизм V2

Существует несколько способов принудительно активировать использование механизма V2:

1. Через файл conf.cfg: Это наиболее распространённый и удобный способ для постоянного использования V2. Мы добавляем специальную строку в конфигурационный файл сервера 1С.

   Шаги:

   1. Найдите файл conf.cfg. Он обычно расположен в каталоге bin установленной платформы 1С:Предприятия. Например, для 64-битной платформы путь может быть таким: C:\Program Files\1cv8\версия_платформы\bin\conf. Для 32-битной: C:\Program Files (x86)\1cv8\версия_платформы\bin\conf.
   2. Откройте файл conf.cfg в любом текстовом редакторе (например, Блокнот) с правами администратора.
   3. Добавьте в конец файла новую строку: UpdateDBCfg=v2.
   4. Сохраните изменения в файле.
   5. Перезапустите службу сервера 1С:Предприятия (1C:Enterprise 8.3 Server Agent в оснастке "Службы" Windows).

   После этих действий обновление конфигурации базы данных через Конфигуратор будет использовать механизм V2.

2. Через командную строку (пакетный режим): Этот метод удобен для разовых или скриптованных обновлений.

   Шаги:

   1. Откройте командную строку от имени администратора.
   2. Перейдите в каталог bin установленной платформы 1С:Предприятия.
   3. Запустите Конфигуратор в пакетном режиме со следующими аргументами:
      Скопировать код

      
      1cv8.exe DESIGNER /S "ИмяСервера\ИмяБазы" /UpdateDBCfg -Server -v2 /СравнитьОбъединитьКонфигурациюФайлов <путь_к_файлу_cf> -ОбновитьКонфигурациюБазыДанных
      

      Где:

      • /S "ИмяСервера\ИмяБазы" – параметры подключения к информационной базе.
      • /UpdateDBCfg -Server -v2 – ключевые аргументы для активации V2.
      • /СравнитьОбъединитьКонфигурациюФайлов <путь_к_файлу_cf> -ОбновитьКонфигурациюБазыДанных – эти аргументы используются, если вы обновляете конфигурацию из файла .cf. Если вы просто хотите применить изменения, сделанные в Конфигураторе, то можно обойтись без них, используя просто /UpdateDBCfg -Server -v2 после открытия Конфигуратора, применения изменений и попытки обновить БД.

Как проверить, что V2 используется?

При использовании V2 в окне сообщений Конфигуратора (обычно на закладке "Служебные сообщения" или "Сообщения") при обновлении конфигурации базы данных должна появиться информация, явно указывающая на использование нового механизма, например, "Используется механизм обновления структуры базы данных V2". Если вы не видите таких сообщений, вероятно, V2 не был активирован или не смог запуститься из-за несоответствия требованиям.

Ограничения и нюансы V2

Несмотря на свою эффективность, V2 имеет некоторые особенности и ограничения, о которых следует помнить:

• PostgreSQL и кластерные индексы: Для PostgreSQL изменение кластерного индекса по-прежнему может приводить к копированию таблиц, что является особенностью данной СУБД.
• Режим хранения EXTENDED: Если база данных изначально была реструктуризирована старым механизмом или загружена из файла .dt, и некоторые поля сохранили режим хранения EXTENDED (вместо оптимального PLAIN), V2 может вызвать копирование таблиц, если обнаружит это несоответствие. В таких случаях перед переходом на V2 рекомендуется добавить недостающие индексы 1С для больших таблиц на PostgreSQL.
• Создание индексов: Иногда V2 может инициировать длительный процесс создания индексов, если они отсутствовали или были некорректны между 1С и СУБД. Это не ошибка, а скорее попытка привести базу в оптимальное состояние для будущей работы.
• Не все объекты оптимизированы: V2 оптимизирует реструктуризацию не всех объектов конфигурации, а только основных. В некоторых специфических случаях старый механизм может быть задействован частично.

В целом, V2 является наиболее безопасным, поддерживаемым и эффективным методом решения проблемы долгой реструктуризации при изменении состава регистраторов документа.

Манипуляции со схемой базы данных через SQL (нерекомендуемый, рискованный подход)

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

Принцип метода

Идея заключается в том, чтобы "обмануть" 1С. Когда вы удаляете регистр из движений документа, 1С видит необходимость изменения структуры таблицы регистра. Если же таблицы регистра временно "скрыть" от 1С, она не сможет их реструктуризировать, а затем, после фиктивного быстрого обновления конфигурации, таблицы возвращаются на место. Этот метод работает на предположении, что 1С изменяет только метаданные в своих внутренних таблицах, а физические таблицы регистров остаются нетронутыми, если на момент обновления конфигурации они недоступны или имеют "неверное" имя.

Примерный алгоритм (для понимания рисков):

Предположим, у нас есть регистр РегистрНакопления.Продажи, и мы хотим удалить из него тип документа без реструктуризации.

1. Создайте полную резервную копию базы данных 1С и СУБД. Это критически важный шаг.
2. Отключите всех пользователей 1С от информационной базы.
3. Переименуйте таблицы движений регистра в СУБД.

   Мы используем среду управления СУБД (например, SQL Server Management Studio для MS SQL Server или pgAdmin для PostgreSQL).

   Найдите таблицы, соответствующие движениям вашего регистра. Имена таблиц 1С обычно выглядят как _AccumRgNNNNN для регистров накопления, _AcRgNNNNN для регистров бухгалтерии, _InfoRgNNNNN для регистров сведений. Также могут быть таблицы итогов (_AccumRgTNNNNN) и агрегатов.

   Например, для регистра РегистрНакопления.Продажи мы можем переименовать его основную таблицу и таблицу итогов:

   Скопировать код

   
   -- Для MS SQL Server
   EXEC sp_rename '_AccumRg12345', '_AccumRg12345_OLD';
   EXEC sp_rename '_AccumRgT12345', '_AccumRgT12345_OLD';
           
   -- Для PostgreSQL (пример)
   ALTER TABLE _AccumRg12345 RENAME TO _AccumRg12345_OLD;
   ALTER TABLE _AccumRgT12345 RENAME TO _AccumRgT12345_OLD;
   

   (Вместо 12345 будет числовой идентификатор вашего регистра, который можно узнать из метаданных 1С или по структуре таблиц СУБД.)

4. В Конфигураторе 1С удалите лишний регистр из списка "Движений" документа.
5. Выполните обновление конфигурации базы данных через Конфигуратор.

   Поскольку 1С не "видит" старые таблицы регистра, она не сможет их реструктуризировать и просто зафиксирует изменение в своих метаданных, "поверив", что таблиц для реструктуризации нет или они новые. Этот процесс пройдёт быстро.

6. Удалите "новые" пустые таблицы регистра (если они были созданы 1С).

   В некоторых случаях 1С может создать новые, пустые таблицы для регистра с новым типом поля Регистратор. Эти таблицы нам не нужны, так как мы хотим использовать старые данные. Их нужно удалить.

7. Переименуйте старые таблицы регистра обратно.
   Скопировать код

   
   -- Для MS SQL Server
   EXEC sp_rename '_AccumRg12345_OLD', '_AccumRg12345';
   EXEC sp_rename '_AccumRgT12345_OLD', '_AccumRgT12345';
           
   -- Для PostgreSQL (пример)
   ALTER TABLE _AccumRg12345_OLD RENAME TO _AccumRg12345;
   ALTER TABLE _AccumRgT12345_OLD RENAME TO _AccumRgT12345;
   

8. Проверьте целостность и работоспособность базы.

Риски и опасности этого подхода

Как уже было сказано, данный метод крайне опасен из-за следующих причин:

• Несогласованность метаданных и физической структуры: 1С активно работает с внутренними идентификаторами полей и таблиц. При реструктуризации она может не просто изменить тип поля, но и переименовать его в СУБД, добавить новые служебные поля или изменить их порядок. Если вы просто вернете старые таблицы, их структура может не соответствовать новым ожиданиям 1С, что приведёт к непредсказуемым ошибкам, некорректной работе или даже потере данных. Сообщение 7 из форума подтверждает этот риск: "оказывается, что 1с поля переименовала в СУБД при реструктуризации. Сталкивался в прошлой такой же ситуации:("
• Проблемы с таблицами итогов, агрегатов, регистрации изменений: Регистры часто имеют связанные таблицы итогов (для быстрого получения остатков/оборотов), агрегатов (для оптимизации отчётов) и таблицы регистрации изменений (для обмена данными, например, РИБ). Ручные манипуляции с основной таблицей регистра, без учёта этих связанных объектов, почти гарантированно приведут к их порче или несогласованности. Сообщение 6 справедливо указывает на это: "не забываешь про таблицы итогов, агрегатов, регистрации изменений... А не, забываешь..."
• Отсутствие поддержки: Если после таких манипуляций возникнут проблемы, техническая поддержка 1С не будет оказывать помощь, так как это прямое нарушение рекомендаций по работе с базой данных.
• Потенциальная потеря данных: Даже если система будет казаться работающей, могут возникнуть скрытые повреждения данных, которые проявятся позже, приводя к некорректным отчётам или ошибкам в бизнес-логике.

Использование этого метода является "последним средством" для отчаянных ситуаций и должно быть предпринято только в тестовой среде с целью изучения или в условиях, когда другие варианты (например, V2) невозможны, и при этом полностью осознаются все риски.

Полная выгрузка/загрузка базы данных (.dt) (стандартный, но времязатратный подход)

Ещё один стандартный способ обновить структуру базы данных 1С и избежать прямой длительной реструктуризации — это полная выгрузка информационной базы в файл .dt с последующей загрузкой в новую, пустую базу данных. Этот метод широко используется для различных целей, включая исправление логических ошибок в структуре базы или переход между СУБД.

Как это работает

1. Выгрузка в .dt: Конфигуратор 1С выгружает все данные и метаданные из существующей базы в единый файл .dt. На этом этапе данные считываются, и при этом 1С сохраняет их в универсальный формат, без привязки к текущей физической структуре таблиц.
2. Изменение конфигурации: В конфигураторе вы вносите необходимые изменения (в нашем случае, удаляете лишний регистр из движений документа).
3. Создание новой, пустой базы: Вы создаёте абсолютно новую, пустую информационную базу (без данных) на сервере 1С и в СУБД. При этом 1С создаёт все таблицы в СУБД согласно новой, изменённой конфигурации.
4. Загрузка из .dt: Вы загружаете ранее созданный файл .dt в эту новую, пустую базу. В процессе загрузки 1С читает данные из файла и записывает их в таблицы, которые уже имеют правильную, обновлённую структуру, соответствующую вашей изменённой конфигурации. Таким образом, прямого процесса "реструктуризации" старых таблиц не происходит, поскольку данные записываются уже в новые таблицы.

Почему это может быть нежелательным для 1Тб+ баз

Хотя этот метод является надёжным и поддерживаемым, для больших баз данных (1 Тб и более) он может быть крайне времязатратным:

• Время выгрузки: Выгрузка 1 Тб данных в файл .dt может занять многие часы или даже дни, в зависимости от производительности дисковой подсистемы и сервера.
• Место на диске: Файл .dt для такой базы будет также очень большим, требуя значительного объёма свободного дискового пространства.
• Время загрузки: Загрузка 1 Тб данных в новую базу также является длительным процессом, сравнимым или даже превосходящим по времени выгрузку.
• Простои системы: Весь этот процесс требует полного простоя системы 1С, что может быть неприемлемо для непрерывно работающего предприятия.

Сообщение 9 из форума ("булком тогда перегоняешь, ну минут 5-10 потратишь на выгрузку-загрузку") скорее относится к очень маленьким базам или метаданным, а не к 1Тб+ базе, где этот процесс займёт на порядки больше времени.

Заключение

Проблема длительной реструктуризации базы 1С при изменении состава регистраторов документа является актуальной и требует внимательного подхода. Мы рассмотрели несколько методов решения:

1. Оптимизированный механизм V2: Это официальное, безопасное и наиболее эффективное решение, способное значительно сократить время реструктуризации. Его использование требует соблюдения определённых технических условий, но полностью оправдывает себя на больших базах. Мы настоятельно рекомендуем в первую очередь рассмотреть возможность его применения.
2. Манипуляции со схемой базы данных через SQL: Это крайне рискованный и неподдерживаемый подход, который может привести к повреждению данных и нестабильной работе системы. Мы крайне не рекомендуем его использование на продуктивных базах.
3. Полная выгрузка/загрузка базы (.dt): Это стандартный и надёжный метод, но его применимость для баз объёмом 1 Тб и более сопряжена со значительными временными затратами и простоями.

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