Делимся опытом, как исправить ошибки в логической целостности в базе 1С, размещенной на Microsoft SQL Server.
Поступила жалоба от бухгалтера о проблемах с проведением документов в 1С.
Из скриншота выяснилось, что 1С «ругается» на проблемы с согласованностью «внутри» базы данных и предлагает провести проверку на согласованность.
Переходим в SQL Server Management Studio и, сделав, на всякий случай, бэкап текущего состояния, выполняем проверку:
Для начала переводим нужную нам БД в однопользовательский режим
Запускаем Окно запросов (CTRL+N). Выбираем Новый запрос и вводим запрос Transact-SQL (T-SQL) в этом окне:
ALTER DATABASE KA SET SINGLE_USER WITH ROLLBACK IMMEDIATE
Далее, вводим запрос на сканирование базы данных:
USE [ka] GO DBCC CHECKDB(N'ka') WITH NO_INFOMSGS GO
Проверка продлилась около 15 минут, после чего выдала следующее:
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в таблице "sys.sysdbfiles" (идентификатор объекта 20).
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в таблице "sys.sysxmlcomponent" (идентификатор объекта 91).
CHECKDB обнаружил 0 ошибок размещения и 49 ошибок согласованности в таблице "_AccRg1025" (идентификатор объекта 1778313595).
CHECKDB обнаружил 0 ошибок размещения и 3 ошибок согласованности в таблице "_AccRgAT21046" (идентификатор объекта 1826313766).
CHECKDB обнаружил 0 ошибок размещения и 1783 ошибок согласованности в таблице "_AccRg1051" (идентификатор объекта 1906314051).
CHECKDB обнаружил 0 ошибок размещения и 2603 ошибок согласованности в базе данных "KA".
Вариант решения №1: восстановление из бэкапа выявило накопительный характер ошибки: чем раньше сделан бэкап – тем меньше в базе ошибок, вплоть до самого «дальнего» (14 дней). Примерно на третьем бэкапе количество ошибок перестало уменьшаться – стало ясно, что этим путём мы придём только к потере актуальности базы и проблему не решить
Вариант решения №2: В справочной информации описаны три возможных варианта исправления этих ошибок, рассмотрим каждый:
REPAIR_FAST
Синтаксис поддерживается только для обеспечения обратной совместимости. Действия по восстановлению не выполняются.
REPAIR_REBUILD
Выполняет действия по восстановлению данных, которые можно выполнить без риска их потери. Это может быть быстрое восстановление (например, восстановление отсутствующих строк в некластеризованных индексах) или более ресурсоемкие операции (например, перестроение индекса).
REPAIR_ALLOW_DATA_LOSS
Пытается устранить все обнаруженные ошибки. Эти исправления могут привести к частичной потере данных.
Аргумент REPAIR_FAST нам не подходит, REPAIR_ALLOW_DATA_LOSS оставим на крайний случай - пробуем REPAIR_REBUILD:
DBCC CHECKDB(N'ka', REPAIR_REBUILD) WITH NO_INFOMSGS
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в таблице "sys.sysdbfiles" (идентификатор объекта 20).
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в таблице "sys.sysxmlcomponent" (идентификатор объекта 91).
CHECKDB обнаружил 0 ошибок размещения и 49 ошибок согласованности в таблице "_AccRg1025" (идентификатор объекта 1778313595).
CHECKDB обнаружил 0 ошибок размещения и 3 ошибок согласованности в таблице "_AccRgAT21046" (идентификатор объекта 1826313766).
CHECKDB обнаружил 0 ошибок размещения и 1783 ошибок согласованности в таблице "_AccRg1051" (идентификатор объекта 1906314051).
CHECKDB обнаружил 0 ошибок размещения и 2603 ошибок согласованности в базе данных "KA".
Не помогло, переводим базу данных обратно в многопользовательский режим:
ALTER DATABASE KA SET MULTI_USER
На всякий случай, я попробовал провести обслуживание базы данных и перепроверил – результат тот же.
Решил провести тестирование и исправление информационной базы средствами 1С, на что получил ошибку
Выгрузить базу данных в *.dt файл тоже не удалось:
Что ж, стало понятно, что часть потерянных данных – меньшее зло, по сравнению с «развалившейся» базой данных, пробуем REPAIR_ALLOW_DATA_LOSS:
DBCC CHECKDB (N'KA', REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS
И, наконец, после нескольких прогонов, количество ошибок немного уменьшилось:
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в таблице "sys.sysdbfiles" (идентификатор объекта 20).
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в таблице "sys.sysxmlcomponent" (идентификатор объекта 91).
CHECKDB обнаружил 0 ошибок размещения и 1783 ошибок согласованности в таблице "_AccRg1051" (идентификатор объекта 1906314051).
CHECKDB обнаружил 0 ошибок размещения и 2518 ошибок согласованности в базе данных "KA ".
Ситуацию это не спасло: база, по-прежнему не выгружалась и не «лечилась» средствами 1С.
Дальнейшие попытки (по очереди несколько раз запускал REPAIR_REBUILD и REPAIR_ALLOW_DATA_LOSS) не увенчались успехом: количество ошибок не уменьшилось, база, по-прежнему, не выгружалась и не «лечилась».
Коллеги подсказали попробовать очистить (именно очистить, без удаления самой таблицы) «проблемную» таблицу в MS SQL.
Больше всего ошибок в таблице "_AccRg1051" – ей и было принято решение заняться:
Вводим запрос
TRUNCATE TABLE _AccRg1051
И, после успешного выполнения, прогоняем проверку еще раз:
DBCC CHECKDB(N'ka') WITH NO_INFOMSGS
15 минут ожидания и, о чудо – все ошибки исчезли, в том числе и в остальных таблицах.
Перевожу базу в многопользовательский режим, выгружаю в *.dt файл и загружаю обратно.
Звоню бухгалтеру – прошу проверить проблемные документы: всё работает нормально. Пускаю остальных пользователей в базу.
Через час снова ошибка:
Делаем вывод, что выгрузка в *.dt – не панацея. Выгоняем Вежливо просим пользователей выйти и ещё немного потерпеть и тестируем базу с исправлением ошибок в режиме конфигуратора 1С со следующими параметрами
Видим, что всё ОК
Пускаем обратно пользователей в 1С и идём молиться настраивать планы обслуживания баз данных.