Как восстановить базу данных 1С 7.7 на MS SQL Server из статуса SUSPECT?

← На главную

Каждый системный администратор, обслуживающий старые конфигурации на платформе 1С:Предприятие 7.7, рано или поздно сталкивается со сбоями оборудования. Физические дефекты жесткого диска, внезапное отключение электропитания или сбои в контроллере RAID могут привести к тому, что база данных СУБД перейдет в критический статус SUSPECT (подозрительная). База перестает открываться, а стандартные попытки восстановить ее стандартными SQL-скриптами возвращают ошибки синтаксиса или монопольного доступа. Чтобы исключить риск потери информации в будущем, стоит рассмотреть переход на современные платформы, выбрав подходящий раздел с решениями для переноса данных из 1С 7.7.

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

Выясняем причины проблемы: почему ломаются старые базы?

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

Server: Msg 102, Level 15, State 6, Line 1. Incorrect syntax near 'EMERGENCY'.

Эта ошибка однозначно указывает на то, что в качестве СУБД используется легендарный, но крайне устаревший MS SQL Server 2000 (или его бесплатный аналог MSDE 2000). Конструкция ALTER DATABASE ... SET EMERGENCY появилась только в версии SQL Server 2005. В версии SQL 2000 изменить статус базы на аварийный обычным запросом невозможно. Именно поэтому стандартные инструкции из интернета не работают.

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

Ниже мы рассмотрим два детальных сценария решения этой проблемы.

---

Вариант 1. Использование механизмов УРБД (Рекомендуемый и самый безопасный способ)

Если база данных является периферийной (филиальной) в распределенной структуре 1С (УРБД), то проведение сложных и опасных операций над поврежденным SQL-файлом чаще всего не имеет практического смысла. Физическое повреждение таблиц СУБД после аварийного восстановления почти всегда приводит к логическим ошибкам в учете. Это может вызвать появление «битых» ссылок, которые при очередной синхронизации попадут в центральную базу данных и повредят учет во всей компании.

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

Создаем резервную копию: Перед любыми манипуляциями обязательно скопируйте поврежденные файлы .mdf и .ldf в надежное место. Даже если мы планируем пересоздать базу, исходные файлы должны остаться на случай непредвиденных обстоятельств.
Подготовка в Центральной Базе (ЦБ):
- Запустите конфигуратор Центральной Базы 1С 7.7.
- Перейдите в меню Администрирование — Распределенная ИБ — Управление.
- Выберите в списке периферийную базу, которая вышла из строя.
- Нажмите кнопку Создать базу данных (образ). Система сгенерирует актуальный файл инициализации (переноса данных), который будет содержать всю необходимую информацию для филиала.
Подготовка СУБД на филиале:
- В консоли управления MS SQL Server Enterprise Manager (для SQL 2000) удалите старую поврежденную базу данных TiS_Dalm_2015 (предварительно убедившись, что файлы скопированы).
- Создайте новую чистую базу данных на SQL-сервере с тем же именем.
Загрузка образа в филиале:
- Запустите пустой Конфигуратор 1С 7.7 на периферийном компьютере, указав путь к новой пустой базе SQL.
- Выберите пункт меню Администрирование — Распределенная ИБ — Инициализация периферийной ИБ.
- Укажите файл образа, сгенерированный в Центральной Базе.
- Дождитесь окончания процесса. Платформа сама создаст все необходимые таблицы, индексы и загрузит актуальные документы и справочники.

Этот метод гарантирует 100% физическую целостность восстановленной базы данных и исключает появление логического мусора.

---

Вариант 2. Техническое восстановление базы в MS SQL Server 2000

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

Рассмотрим детальный алгоритм действий через Query Analyzer (для SQL Server 2000):

Шаг 1. Разрешаем редактирование системных таблиц

По умолчанию MS SQL Server запрещает пользователям напрямую изменять системные каталоги. Нам необходимо временно снять это ограничение в базе master. Выполним следующий скрипт:


USE master
GO
EXEC sp_configure 'allow updates', 1
RECONFIGURE WITH OVERRIDE
GO

Шаг 2. Принудительная установка статуса EMERGENCY

Поскольку команда ALTER DATABASE в старой СУБД не поддерживает нужный синтаксис, мы изменим статус базы данных напрямую в таблице sysdatabases. Нам нужно установить статус базы в значение 32768 (что соответствует режиму EMERGENCY в SQL 2000):


UPDATE sysdatabases 
SET status = 32768 
WHERE name = 'TiS_Dalm_2015'
GO

Шаг 3. Возвращаем запрет на изменение системных таблиц

После изменения статуса базы обязательно вернем настройки безопасности СУБД в исходное состояние:


EXEC sp_configure 'allow updates', 0
RECONFIGURE WITH OVERRIDE
GO

Шаг 4. Перезапуск службы SQL Server

Это критически важный шаг для SQL Server 2000. Изменения в таблице sysdatabases не вступят в силу мгновенно. Необходимо полностью перезапустить службу СУБД (MSSQLSERVER) через диспетчер служб Windows или SQL Server Service Manager.

Шаг 5. Перевод базы в однопользовательский режим

После перезапуска СУБД база данных должна перейти в режим EMERGENCY (вы увидите соответствующую пометку в Enterprise Manager). Теперь мы можем перевести ее в монопольный режим работы для исправления ошибок:


EXEC sp_dboption 'TiS_Dalm_2015', 'single user', 'true'
GO

Шаг 6. Пересоздание поврежденного лога транзакций

Так как файл журнала транзакций .ldf поврежден или утерян, нам нужно заставить СУБД создать абсолютно новый, чистый файл лога. Для этого в SQL Server 2000 используется специальная недокументированная команда DBCC REBUILD_LOG. Укажем путь к новому файлу журнала:


DBCC REBUILD_LOG('TiS_Dalm_2015', 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\TiS_Dalm_2015_log.ldf')
GO

Примечание: убедитесь, что указанный путь к новому файлу действительно существует и у службы SQL Server есть права на запись в эту папку.

Шаг 7. Проверка базы и исправление ошибок с потерей данных

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


DBCC CHECKDB('TiS_Dalm_2015', REPAIR_ALLOW_DATA_LOSS)
GO

Шаг 8. Возврат базы в многопользовательский режим

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


EXEC sp_dboption 'TiS_Dalm_2015', 'single user', 'false'
GO

---

Важные действия в 1С:Предприятии после восстановления СУБД

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

Чтобы восстановить работоспособность платформы, выполним следующие действия:

Запустите базу данных 1С:Предприятие 7.7 исключительно в режиме Конфигуратора.
Перейдите в меню Администрирование — Тестирование и исправление ИБ.
Обязательно установите флажки на следующих пунктах:
- Реиндексация таблиц — полностью перестроит физические индексы таблиц базы данных SQL, которые могли пострадать при сбое диска.
- Проверка физической целостности — проверит корректность внутренней структуры таблиц 1С.
- Проверка ссылочной целостности — если СУБД удалила битые строки, в базе появятся ссылки «Объект не найден». Режим тестирования позволит автоматически создать пустые элементы-заглушки для таких битых ссылок.
- Пересчет итогов — принудительно пересчитает регистры накопления и бухгалтерии. Из-за сбоя транзакций детальные записи движений документов могут расходиться с агрегированными итогами.
Запустите процесс тестирования и внимательно изучите отчет о результатах работы.

Только после успешного завершения всех этапов тестирования в Конфигураторе базу данных можно открывать в обычном режиме предприятия для возобновления работы пользователей.