Что делать, если после сбоя питания сервер 1С работает некорректно?

← На главную

Внезапная аппаратная перезагрузка сервера — это критическое событие для любой информационной системы, работающей под управлением MS SQL Server. Если после «ХРЯСЬ и ребут» пользователи жалуются на то, что отчеты возвращают пустые данные, а запросы отрабатывают некорректно, это является прямым сигналом о возможной деградации целостности данных. В этой статье мы разберем по шагам, как локализовать проблему и восстановить штатную работу системы.

Шаг 1: Обеспечение безопасности данных

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

Остановите работу всех пользователей в базе.
Переведите базу в режим Single User Mode на уровне SQL Server, чтобы исключить подключение внешних процессов.
Обязательно сделайте физическую копию файлов базы .mdf и .ldf. Это ваш «страховой полис», если в ходе дальнейших действий ситуация ухудшится.

Шаг 2: Диагностика целостности на уровне СУБД

Так как симптомы указывают на проблемы с данными (пустые запросы), необходимо проверить, не пострадали ли страницы данных. Для этого используем встроенный инструмент DBCC CHECKDB. Это стандарт де-факто для проверки логической и физической целостности базы данных.

Запустите команду в SQL Server Management Studio:

DBCC CHECKDB ('ИмяВашейБазы') WITH NO_INFOMSGS, ALL_ERRORMSGS;

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

Шаг 3: Проверка кэша платформы 1С

Часто после сбоя питания повреждаются не только сами данные в SQL, но и локальные или серверные файлы кэша 1С. Это может приводить к тому, что метаданные читаются некорректно, и отчеты СКД выдают пустой результат. Разберем, как произвести очистку:

Очистите кэш на стороне клиентов (папки в профиле пользователя Local/1C/1cv8/...).
Очистите кэш сервера 1С на самом сервере приложений (папка с конфигурационными файлами и файлами сеансов).
Удалите базу из списка 1С и добавьте её заново, чтобы перечитать список метаданных.

Шаг 4: Тестирование и исправление конфигурации 1С

Если диагностика SQL не выявила критических физических повреждений, можно прибегнуть к штатным средствам 1С. Запустите базу в режиме «Конфигуратор» под пользователем с полными правами и откройте пункт меню Администрирование -> Тестирование и исправление.

Важно: На первом этапе выберите только проверку логической целостности без исправления. Это позволит вам увидеть лог ошибок, не меняя структуру базы. Только после анализа лога принимайте решение о запуске процесса исправления.

Шаг 5: Восстановление из резервной копии — самый надежный путь

Если DBCC CHECKDB показал глубокие повреждения, а Тестирование и исправление не дает результата или удаляет слишком много данных, единственно верным решением остается восстановление из резервной копии.

Действуйте по алгоритму:

Откатите рабочую базу на последний корректный бэкап.
Запустите пользователей для сверки данных.
Если были созданы документы в период между сбоем и моментом восстановления бэкапа, их необходимо перенести из «битой» копии базы вручную (через файлы XML или выгрузку/загрузку данных).