Ситуация, когда из-за проблем с электропитанием сервер 1С:Предприятие 7.7 на MS SQL Server внезапно отключается, часто приводит к повреждению структуры базы данных. Режим Suspect — это верный признак того, что SQL-сервер не может гарантировать целостность транзакций. Если стандартные средства восстановления не помогают, а у вас есть бэкап, в котором не хватает данных за последний рабочий день, необходимо извлечь информацию из «битой» базы. Разберем пошагово, как это сделать, используя различные инструменты и методики.
Прежде чем приступать к переносу данных, проанализируем текущее состояние. Если база перешла в режим Suspect, сначала ее нужно вернуть в онлайн, чтобы SQL-сервер позволил хотя бы читать данные. Обычно это делается через перевод базы в EMERGENCY режим и выполнение DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS. Помните, что эта команда может удалить поврежденные страницы, что приведет к потере части записей, но база станет доступна для запуска в 1С.
Если база запускается в режиме 1С, но «вылетает» при обращении к определенным документам или отчетам, значит, физические ошибки остались на уровне таблиц данных. В этом случае стандартная выгрузка в .zip (через Конфигуратор) может не сработать.
Рассмотрим самый популярный метод — использование внешних обработок. Поскольку конфигурация может быть сильно измененной, нам нужны инструменты, которые работают по принципу метаданных, а не жестко прописанных структур.
Проанализируем продвинутый способ, который может быть самым быстрым, если конфигурации идентичны. Даже если ваша база не была распределенной, мы можем временно задействовать этот механизм.
Алгоритм действий следующий:
1sUpdts).Если 1С не может прочитать таблицу из-за ошибок в данных, попробуем обратиться к ней напрямую через SQL Management Studio. Выясним, какие таблицы отвечают за нужные документы. Например, заголовки документов хранятся в _1SJOURN, а их табличные части в таблицах вида _1SXXXXX.
Мы можем попытаться перекачать данные из битой таблицы в новую базу следующим запросом:
INSERT INTO BackupDB.dbo._1SJOURN
SELECT * FROM CorruptedDB.dbo._1SJOURN
WHERE DATE_TIME_IDDOC >= '20231026000000' -- Дата вчерашнего дня
Если запрос спотыкается на поврежденной странице, можно использовать TOP и ORDER BY, чтобы выгружать данные частями, обходя «плохие» записи. Это кропотливая работа, требующая понимания структуры таблиц 1С 7.7, но иногда это единственный способ спасти данные.
Если повреждения SQL-файлов настолько критичны, что таблицы не читаются совсем, нам поможет текстовый файл 1cv7.mlg, который находится в папке SYSLOG внутри каталога базы. Этот файл не зависит от SQL-сервера.
Проанализируем его структуру: в нем в текстовом виде зафиксированы все действия пользователей. Мы можем увидеть, кто, когда и какой документ создал. Даже если восстановить значения всех реквизитов автоматически не удастся, у нас будет точный список того, что нужно ввести заново. Существуют сторонние утилиты (LogReader), которые позволяют преобразовать этот лог в таблицу Excel или даже в набор скриптов для 1С.
При любом способе переноса данных «вчерашнего дня» в бэкап, помните о следующих моментах:
Чтобы не сталкиваться с подобными «казусами» в будущем, проанализируем стратегию защиты данных. Очевидно, что наличие ИБП — это база, но программная защита не менее важна.
Во-первых, переведите базу в модель восстановления FULL. Это позволит делать бэкап лога транзакций (Transaction Log) каждые 15–30 минут. В случае краха базы вы сможете восстановиться на любой момент времени с минимальными потерями.
Во-вторых, настройте ежедневное выполнение DBCC CHECKDB в рамках Maintenance Plan. Это позволит обнаружить повреждение страниц на ранней стадии, пока оно не попало во все копии бэкапов. Как показывает практика, вовремя замеченная ошибка экономит десятки часов работы программиста и системного администратора.