Обновление 1С на корпоративной базе. Обычно это два часа в выходные: остановили сервис, обновили конфигурацию, реструктуризация прошла, запустили обратно. В понедельник утром все довольны.
В эту субботу всё идёт не так. Реструктуризация идёт восемь часов. Десять часов. Двенадцать. На индикаторе — «Обработка таблицы РегистрНакопления.ТоварыНаСкладах», и эта строчка не меняется уже три часа. Поднимать сервис нельзя — таблица в неконсистентном состоянии. Откатывать поздно — никто не делал бэкап сразу перед обновлением. В понедельник утром у вас не работает база.
Это типичная история, и мы её видели не один раз. Чаще всего реструктуризация буксует не потому, что обновление «тяжёлое», а потому, что её никто не подготовил. Существует несколько простых приёмов, которые сокращают её время в разы.
Что делает реструктуризация на самом деле
Когда вы меняете в конфигурации структуру таблицы — добавляете реквизит, меняете тип, индексируете поле, меняете состав измерений регистра — платформа обязана привести физическую структуру базы данных в соответствие. Это не «выполнить ALTER TABLE». Это последовательность действий: создать новую таблицу с нужной структурой, скопировать в неё данные из старой, удалить старую, переименовать новую. Для каждой изменённой таблицы. С пересчётом всех данных в новые типы.
На таблице из миллиона строк это занимает минуты. На десяти миллионах — часы. На ста миллионах (привет, регистр накопления крупного склада за пять лет) — может занять сутки. И всё это время таблица недоступна для записи.
Хуже того: реструктуризация часто идёт последовательно по всем изменённым объектам. Если в обновлении вендор изменил пятнадцать регистров, платформа будет реструктурировать их по очереди. Не параллельно. На большой базе это и есть причина «обновление идёт сутки».
Где смотреть, что именно зависло
Когда индикатор реструктуризации стоит на одной строчке часами, первый вопрос: оно работает или повисло? Внешне разницы нет. Внутри — есть.
Откройте SQL Server Management Studio (или pgAdmin для PostgreSQL) и посмотрите активные запросы. В MS SQL это sp_who2 или sys.dm_exec_requests. Найдите процесс, который выполняется со стороны сервера 1С — он будет с нагрузкой на CPU и активной транзакцией. Если такой процесс есть и у него растут счётчики (CPU time, logical reads) — реструктуризация работает, просто медленно. Если процесса нет или он спит без активности — что-то зависло, ждать бесполезно.
Параллельно посмотрите блокировки. sys.dm_tran_locks покажет, не висит ли сервер 1С в ожидании какой-то блокировки. Бывает, что реструктуризация ждёт освобождения таблицы от другого процесса (например, регламентного задания, которое не остановилось перед обновлением). В таком случае нужно найти и убить блокирующий процесс.
Также посмотрите в свободное место на диске. Реструктуризация создаёт копию таблицы во время преобразования. Если на диске нет места под удвоенный размер самой большой таблицы — операция будет крайне медленной из-за роста файла или вообще зависнет. Это легко проверить заранее, и это первая причина срывов обновлений на крупных базах.
Что делать перед обновлением
Большинство проблем с реструктуризацией решается до того, как вы нажали «Обновить конфигурацию БД». Не пренебрегайте этой подготовкой — она экономит часы.
Снять полный бэкап. Не тот, что снимался ночью, а свежий, прямо перед началом обновления. Если что-то пойдёт не так, у вас будет точка возврата. На крупной базе бэкап тоже занимает время — закладывайте его в окно. Как настроить регулярные и быстрые бэкапы — отдельная история, в основе которой лежит правильное обслуживание SQL Server для 1С.
Сжать журнал транзакций (Shrink log). Если у вас модель восстановления Full и журнал транзакций давно не сжимался, реструктуризация быстро его раздует. На некоторых базах это приводит к тому, что свободное место на диске заканчивается посередине операции. Перед обновлением — переключите модель в Simple временно, сделайте Shrink, после обновления верните в Full и снимите свежий полный бэкап.
Остановить регламентные задания. Прежде чем запускать обновление, отключите все регламентные задания в кластере. Иначе одно из них может стартовать посреди реструктуризации и заблокировать таблицу. Это делается через консоль администрирования сервера 1С: «Регламентные задания → Заблокированы».
Отключить пользователей. Если в кластере есть активные сеансы, реструктуризация будет ждать их завершения. Завершите сеансы вручную через консоль администрирования. Не полагайтесь на «они сами разойдутся».
Проверить доступное место на диске. Минимум — двойной размер самой большой таблицы свободно. Лучше — четверной, с запасом. Если места мало, либо очистите диск, либо перенесите файл базы на временный быстрый диск, либо отложите обновление.
Как ускорить саму реструктуризацию
Подготовились, запустили, и теперь хочется, чтобы это шло быстрее. Несколько приёмов реально работают.
Перенести базу на быстрый диск. Реструктуризация — это интенсивные операции записи. Если файл базы лежит на медленном HDD, это и есть основной тормоз. На SSD таблица в десять миллионов строк реструктурируется в десять раз быстрее, чем на HDD. Если не хотите переносить базу постоянно, можно временно: остановили сервис, скопировали файл базы на SSD, перецепили базу к SQL-серверу, выполнили обновление, скопировали обратно. Это плановая работа на пару часов, которая экономит сутки реструктуризации.
Дать СУБД больше памяти. На время обновления можно временно увеличить лимит памяти для SQL Server (параметр max server memory). Чем больше СУБД может держать в кэше, тем меньше она читает с диска. Не забудьте после обновления вернуть значение обратно — иначе постоянный рабочий режим может пострадать.
Убрать ненужные индексы заранее. Если в таблице есть индексы, которые вы добавляли «для отчёта раз в квартал» — на время реструктуризации они только мешают. Каждый индекс перестраивается вместе с таблицей. Удалите лишние индексы перед обновлением, восстановите после. На таблице с десятью индексами это сокращает время в полтора-два раза.
Очистить устаревшие данные. Если в регистре накопления лежат данные за десять лет, а реально нужны три — самое время архивировать. Это не работа на час, но если вы планируете крупные обновления вперёд — заведите процедуру архивации устаревших данных. На таблице, в которой осталась треть строк, реструктуризация идёт втрое быстрее.
Отключить логирование сервером 1С. Платформа во время реструктуризации пишет в журнал регистрации каждое событие. На больших таблицах это десятки тысяч записей. Отключите запись в журнал регистрации на время обновления через настройки информационной базы.
Что делать, если уже зависло
Допустим, вы не подготовились, обновление идёт восьмой час, и индикатор стоит на одной строке. Что делать?
Первое — не паниковать и не убивать процесс. Если вы прервёте реструктуризацию посередине, таблица останется в неконсистентном состоянии, и восстановление займёт больше времени, чем дождаться завершения текущей операции. Откат через бэкап — самый чистый, но не всегда быстрый вариант.
Второе — оценить прогресс через SQL. Посмотрите в SSMS, какая таблица сейчас обрабатывается и сколько строк в неё уже скопировано. Сравните с общим количеством. Если уже скопировано 80% — ждите, осталось немного. Если 5% — придётся принимать тяжёлое решение.
Третье — посмотрите, не упёрлась ли операция в место на диске, в блокировку или в нагрузку CPU. Если упёрлась в место — освободите дисковое пространство, после чего операция продолжится. Если в блокировку — найдите блокирующий процесс и снимите его. Если в CPU — терпение, ничего не сделать.
Четвёртое — если решили откатываться, сначала остановите сервер 1С (не через kill, а через консоль), потом восстановите базу из бэкапа. Не из снапшота — снапшоты не гарантируют целостности после прерванной транзакции 1С. Только полный бэкап.
Процедура регулярных безопасных обновлений
Большинство аварий с реструктуризацией происходит у тех, у кого нет регулярного процесса. Раз в год накатывается крупное обновление, всё ломается, потом полгода никто не хочет этого касаться. Когда наконец берутся снова — снова ломается, потому что между обновлениями накопилось ещё больше данных.
Лучше так: маленькие обновления каждый месяц, по чуть-чуть. Тогда и реструктуризация маленькая, и риск низкий, и команда привыкает к процедуре.
В нашей практике процедура обновления выглядит так. За день до обновления — снимаем бэкап, разворачиваем тестовую копию базы, накатываем обновление на тестовой. Замеряем длительность реструктуризации. Если на тесте обновление прошло за 30 минут — на проде закладываем час. Если на тесте час — закладываем три. Никогда не идём на прод вслепую.
В день обновления — заранее предупреждаем пользователей, останавливаем регламентные задания, выгоняем сеансы, снимаем свежий бэкап. Обновление запускаем с запасом времени. После обновления — проверяем критичные операции (закрытие месяца, основные отчёты, проведение нескольких документов разных типов). Только после этого даём пользователям.
Эта процедура перекликается с подходом из статьи про инфраструктурные причины тормозов 1С — там же про роль медленных дисков и недостатка памяти в подобных авариях. Но даже без сложной автоматизации, по чек-листу, риск аварии падает в разы.
Главное про реструктуризацию
Реструктуризация буксует не сама по себе. У неё всегда есть причина: медленный диск, недостаток памяти, неубранные регламенты, конкурирующие транзакции. Если вы за двадцать минут до обновления знаете все эти факторы — обновление пройдёт за то время, которое вы запланировали. Если нет — окно растягивается, и вы получаете звонок в воскресенье вечером.
Самое главное — не верьте в магию обновлений. Не существует «обновления, которое всегда занимает два часа». Длительность зависит от объёма данных, аппаратной части и подготовки. Растущая база — это растущее окно обновлений. Если у вас была привычка «обновляю в субботу за два часа», и эта привычка сформировалась пять лет назад, — почти наверняка пора пересмотреть. Иначе одна из суббот закончится воскресным авралом.
И последнее: если реструктуризация регулярно занимает больше двух часов, это уже не «нормально». Это сигнал, что нужно работать с архитектурой данных — архивировать устаревшее, убирать лишние индексы, переезжать на быстрые диски. Каждое следующее обновление будет медленнее. Каждое следующее окно — больше. Лучше потратить выходные на очистку базы, чем потом терять рабочую неделю на восстановление после неудачного обновления.
