← На главную

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

В этой статье мы подробно разберем механику процесса реструктуризации базы данных 1С на уровне СУБД (в частности, MS SQL Server и PostgreSQL), анализируя SQL сервер глазами 1С-ника, проанализируем риски аварийного завершения и выясним, как работает кнопка отмены.

Суть проблемы: изменение типа данных

Рассмотрим сценарий, описанный в теме: в документе изменяется длина строкового реквизита с фиксированной (например, 100 символов) на «Неограниченную». Для платформы 1С это кажется простым действием, но для СУБД это кардинальное изменение способа хранения данных.

Давайте разберемся, почему это вызывает долгую реструктуризацию:

1. Хранение строк ограниченной длины: В SQL Server типы вроде nvarchar(100) обычно хранятся непосредственно на странице данных (in-row), если строка помещается в размер страницы (8 Кб).
2. Хранение строк неограниченной длины: Тип «Строка неограниченной длины» в 1С соответствует типу nvarchar(max) или text (в старых версиях) в SQL. Это так называемые LOB-типы (Large Objects). Они могут храниться отдельно от основной страницы данных, оставляя в строке только указатель.

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

Механизм классической реструктуризации (v1)

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

При использовании стандартного механизма (версия 1) процесс выглядит следующим образом:

1. Анализ метаданных: Платформа сравнивает конфигурацию базы данных (таблица Config) с новой конфигурацией поставщика, а также анализирует конфигурацию и состав расширений на наличие ошибок. Если обнаружены изменения структуры (например, изменение типа поля), запускается реструктуризация.
2. Создание временной таблицы: СУБД создает новую таблицу. Обычно ее имя формируется как имя старой таблицы + суффикс (например, _Document123_New или случайный набор символов). Эта таблица уже имеет новую, правильную структуру. Посмотреть соответствие имен таблиц в SQL объектам метаданных поможет обработка «Структура хранения базы данных».
3. Перенос данных: Это самый длительный этап. Платформа выполняет SQL-запрос вида:
   Скопировать код

   
   INSERT INTO _Document123_New (Field1, Field2, NewStringField, ...)
   SELECT Field1, Field2, CAST(OldStringField AS nvarchar(max)), ...
   FROM _Document123
   

   В этот момент в базе данных существуют две версии таблицы: старая (с исходными данными) и новая (заполняемая данными). Старая таблица продолжает существовать в неизменном виде.
4. Построение индексов: После переноса данных для новой таблицы заново строятся все индексов. Это также занимает значительное время и требует места на диске.

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

Момент истины: Принять или Отменить?

Когда полоса прогресса в конфигураторе доходит до конца и появляется окно подтверждения, состояние СУБД следующее:

• Существует старая таблица Table_Old (используется системой).
• Существует новая таблица Table_New (полностью готова, данные сконвертированы).

Разберем действия системы при выборе вариантов:

Сценарий 1: Нажатие кнопки «Принять»

Если вы подтверждаете изменения, происходит короткая, но критически важная транзакция:

1. Старая таблица удаляется (DROP TABLE).
2. Новая таблица переименовывается в имя старой (sp_rename).
3. Обновляются записи в системной таблице Config/DBSchema, фиксируя, что структура теперь соответствует новой версии.

Эта операция занимает доли секунды, так как это просто операции с метаданными СУБД.

Сценарий 2: Нажатие кнопки «Отмена»

Если вы нажимаете «Отмена», платформа выполняет откат изменений:

1. Новая таблица (копия) удаляется (DROP TABLE _Document123_New).
2. Старая таблица остается на месте.
3. Данные в старой таблице не менялись, поэтому целостность системы гарантирована.

Вывод: Нажимать кнопку «Отмена» безопасно. Вы просто потеряете время, потраченное на создание копии таблицы, но данные останутся в том виде, в котором они были до начала обновления.

Опасность принудительного завершения

В обсуждении был поднят важный вопрос: «А что если убить процесс через диспетчер задач или консоль сервера?». Вот здесь кроются серьезные риски.

Если вы принудительно завершите работу конфигуратора (1cv8.exe) или процесса на сервере приложений (rphost) во время реструктуризации, последствия могут быть непредсказуемыми.

Риск 1: Рассинхронизация метаданных

Самая большая проблема — это несоответствие между таблицей Config (где 1С хранит описание того, как база должна выглядеть) и реальной структурой таблиц в SQL (DBSchema). Если процесс будет убит в момент финальной подмены таблиц, может возникнуть ситуация, когда:

• 1С «думает», что реструктуризация прошла.
• В SQL осталась старая таблица.

При следующем запуске вы получите ошибки вида «Поле объекта не обнаружено» или «Invalid column name», так как платформа будет пытаться выполнить запросы к несуществующим полям.

Риск 2: Повреждение кэша

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

Риск 3: Мусор в базе данных

При аварийном завершении новая таблица-копия (_New) может не удалиться автоматически. Она останется в базе данных как «мусор», занимая место (в случае с 1 Тб базой это могут быть сотни гигабайт), пока администратор не удалит ее вручную средствами SQL. Для предварительной проверки доступной базы обработка просмотра метаданных сопоставит штатные таблицы с объектами 1С и, после загрузки SQL-данных, покажет несопоставленные таблицы; назначение временных копий нужно устанавливать отдельно.

Реструктуризация v2: Оптимизированный подход

Начиная с версии платформы 8.3.11, фирма «1С» внедрила механизм оптимизированной реструктуризации (v2). Давайте проанализируем, как он меняет ситуацию.

Основная идея v2 — избегать копирования данных через INSERT INTO ... SELECT там, где это возможно. Вместо этого платформа пытается использовать команды DDL (Data Definition Language), такие как:

ALTER TABLE _Document123 ADD COLUMN NewField ...

Преимущества v2:

• Скорость: Добавление поля в конец таблицы происходит практически мгновенно, так как не требует перезаписи всех страниц данных.
• Место на диске: Не создается дубликат таблицы, экономится пространство.
• Лог транзакций: Генерируется существенно меньше логов.

Однако, в рассматриваемом случае (изменение строки на неограниченную), v2 не всегда может отработать мгновенно. Смена типа данных на LOB в SQL Server все равно требует сложных манипуляций со страницами данных. Тем не менее, использование v2 рекомендуется для больших баз.

Чтобы включить этот режим, в параметрах запуска конфигуратора или в файле conf.cfg можно использовать параметр реструктуризации, но в современных версиях платформа старается использовать его по умолчанию, если это возможно.

Проблема разрастания лога транзакций (LDF)

При реструктуризации базы объемом 1 Тб критически важно помнить о журнале транзакций (Transaction Log). Когда происходит копирование огромной таблицы (операция INSERT INTO ... SELECT), каждое вставленное действие записывается в лог. Это означает, что если ваша таблица документов весит 200 Гб, то при ее реструктуризации:

1. База данных (файл .mdf) вырастет на 200 Гб (новая таблица).
2. Журнал транзакций (файл .ldf) может вырасти на 200-400 Гб (записи о вставке данных).

Частая ошибка: На диске есть место для самой базы, но нет места для лога. Когда диск переполняется, SQL Server останавливает транзакцию и начинает откат (Rollback). Откат гигантской транзакции может занять больше времени, чем сама операция. В это время база будет недоступна.

Рекомендация: Перед реструктуризацией больших таблиц убедитесь, что корректно настроены регламентные операции MS SQL SERVER под 1С, переведите модель восстановления SQL Server в режим Simple (если это допустимо) или убедитесь, что на диске с логами достаточно свободного места.

Резюме и план действий

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

1. Не бойтесь нажать «Отмену» в штатном диалоге. Если система сама предлагает это сделать — это безопасно. Старые данные не затронуты, пока вы не нажмете «Принять».
2. Никогда не убивайте процесс принудительно. Это может привести к повреждению внутренней логической структуры базы (несоответствие метаданных), что потребует восстановления из бэкапа или сложного "лечения".
3. Следите за свободным местом. Для реструктуризации таблицы размером X вам нужно минимум 2.5 * X свободного места (под копию таблицы, индексы и лог транзакций).
4. Делайте бэкапы. Совет из темы «бэкапов много не бывает» актуален всегда. Перед началом реструктуризации всегда должен быть свежий полный бэкап средствами SQL.
5. Используйте фоновое обновление. В современных версиях 1С (8.3.11+) доступно фоновое обновление конфигурации базы данных, которое позволяет выполнять реструктуризацию v2 параллельно с работой пользователей и применять изменения в удобный момент.