← На главную

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

Механизмы обеспечения целостности данных в MS SQL Server

Прежде всего, проанализируем, как ведет себя современная СУБД при внезапном прекращении работы. MS SQL Server спроектирован так, чтобы гарантировать физическую целостность базы данных благодаря принципу ACID и использованию журнала транзакций (файл .ldf).

Когда сервер запускается после внезапной перезагрузки, он автоматически инициирует процесс, называемый Crash Recovery. Разберем этот процесс по стадиям:

1. Analysis (Анализ): СУБД просматривает журнал транзакций, чтобы определить, какие операции были успешно зафиксированы (commit) до момента падения, а какие остались активными.
2. Redo (Накат): Процесс повторяет все операции, которые были подтверждены пользователем, но еще не успели физически записаться из кеша в файлы данных (.mdf). Это гарантирует, что данные не потеряются.
3. Undo (Откат): СУБД находит все транзакции, которые не были завершены на момент перезагрузки (как в нашем случае с документом РасчетСебестоимости). Все внесенные ими изменения полностью отменяются, возвращая базу в состояние «как до начала проведения».

Важный нюанс: Время выполнения стадии Undo напрямую зависит от объема транзакции. Если документ Расчет себестоимости проводился 4 часа и сформировал миллионы записей, SQL Server может потратить сопоставимое время на их удаление из таблиц. В это время база данных может находиться в статусе In Recovery и быть недоступной.

Анализ состояния через Журнал регистрации 1С

Рассмотрим ситуацию, когда пользователь заходит в Журнал регистрации и видит записи серого цвета со статусом Не завершена. Выясним причину этого явления. Статус «Не завершена» появляется из-за особенностей работы рабочего процесса rphost.

Запись в журнал регистрации делает сам сервер 1С в момент начала транзакции. Поскольку сервер был перезагружен жестко, процесс rphost просто «умер», не успев отправить финальное событие об отмене или успешном завершении. Это не означает, что транзакция в SQL все еще активна. Это лишь свидетельствует о том, что лог 1С остался «разорванным». Исправить программно статус такой записи в журнале невозможно, она так и останется серой, выполняя роль исторического свидетельства сбоя.

Риски переполнения лога транзакций (LDF)

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

В таком случае база данных может перейти в критическое состояние SUSPECT или RECOVERY_PENDING. Если вы столкнулись с этим, база станет недоступна для пользователей, и потребуется вмешательство администратора для расширения дисковой квоты или восстановления из бэкапа. Мы рекомендуем всегда держать запас свободного места на дисках с логами не менее 30-50% от размера самой базы данных при выполнении таких тяжелых операций.

Очистка серверного кеша и сеансов

После того как SQL Server завершил восстановление и база стала доступна, необходимо обратить внимание на уровень сервера приложений 1С. Несмотря на то, что СУБД откатила данные, в оперативной памяти сервера и во временных файлах (каталог srvinfo) могут остаться «хвосты» прерванного сеанса.

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

1. Остановите службу сервера 1С:Предприятие.
2. Перейдите в каталог с данными сервера (по умолчанию это C:\Program Files\1cv8\srvinfo).
3. Очистите содержимое папок snccntx (кеш сеансов) и временные файлы в папках конкретных информационных баз (каталоги с именами-GUID).
4. Запустите службу сервера заново.

Это гарантирует, что старые закэшированные данные не приведут к логическим ошибкам при повторном запуске расчета.

Логическая целостность в конфигурации УПП 1.3

Выясним, существуют ли риски на уровне кода. В типовой УПП 1.3 документ Расчет себестоимости по умолчанию работает в рамках одной глобальной транзакции. Однако, если в вашей конфигурации есть доработки, использующие прямые запросы к внешним источникам данных, запись в текстовые файлы на диске или вызовы через COM-соединение, помните: эти действия не откатываются транзакцией SQL.

Если в процессе проведения расчет записывал какие-то данные во внешнюю систему (например, в «Битрикс» или другую базу через ADO), эти данные останутся там в «полуфабрикатном» состоянии. В таком случае потребуется ручная корректировка внешних данных.

Алгоритм проверки и восстановления работоспособности

Посмотрим на итоговый список действий, который поможет убедиться, что все в порядке:

1. Мониторинг SQL: Откройте SQL Management Studio и проверьте статус базы. Если идет восстановление, вы можете отследить прогресс запросом:
   Скопировать код

   
   SELECT percent_complete, start_time, status 
   FROM sys.dm_exec_requests 
   WHERE command = 'DBCC TABLE CHECK' OR command LIKE '%RECOVERY%';
   

2. Проверка физической целостности: После запуска базы выполните команду DBCC CHECKDB. Это позволит убедиться, что файлы базы данных не повреждены на физическом уровне: DBCC CHECKDB ('Имя_Вашей_Базы') WITH PHYSICAL_ONLY;
3. Повторный расчет: Мы настоятельно рекомендуем запустить документ Расчет себестоимости заново. Поскольку SQL гарантирует откат к состоянию «до проведения», повторный запуск просто выполнит ту же работу с нуля, обеспечив корректность всех регистров.

Заключение: В большинстве случаев (при использовании MS SQL Server) физическая перезагрузка не наносит непоправимого урона данным, так как механизмы транзакционности надежно защищают базу. Основная задача администратора — дождаться завершения отката транзакций в SQL, очистить кеш сервера 1С и запустить процесс расчета повторно, убедившись в наличии свободного места на дисках.