Каждый системный администратор или специалист 1С рано или поздно сталкивается с критической ситуацией: база данных на MS SQL Server работает, пользователи могут вносить документы, но при попытке сделать резервную копию средствами СУБД, выгрузить базу в формат .dt или просто скопировать файлы базы данных .mdf и .ldf на другой диск, процесс прерывается ошибкой ввода-вывода (CRC error). Это явный признак появления «битых секторов» (bad blocks) на жестком диске именно в том месте, где лежат данные одной из таблиц 1С.
В этой статье мы подробно разберем, как локализовать поврежденную таблицу, безопасно скопировать файлы базы данных даже при наличии аппаратных сбоев, а также рассмотрим несколько эффективных программных способов восстановления работоспособности базы данных СУБД и 1С:Предприятия.
Проанализируем ситуацию. Если СУБД выдает ошибку чтения при обращении к определенным страницам данных, нам нужно понять, какому объекту метаданных 1С соответствует сбойная таблица в SQL. СУБД MS SQL в системных логах обычно указывает имя таблицы (например, _InfoRG21904). Чтобы сопоставить техническое имя таблицы SQL с понятным объектом конфигурации 1С, выполним следующие действия:
В нашем случае таблица _InfoRG21904 соответствует регистру сведений РегистрСведений.ДвоичныеДанныеФайлов. Этот регистр используется в Библиотеке стандартных подсистем (БСП) для хранения прикрепленных к документам файлов, сканов и картинок непосредственно внутри базы данных SQL.
Критически важно: перед проведением любых восстановительных работ необходимо попытаться сделать резервную копию. Поскольку обычные средства копирования Windows прерывают операцию при первой ошибке CRC, нам потребуются специализированные инструменты, умеющие обходить поврежденные участки диска.
Рассмотрим лучшие варианты для создания резервной копии «наживую»:
После того как копия файлов .mdf и .ldf успешно создана и перенесена на исправный накопитель, мы можем приступать к программным методам исправления структуры СУБД.
Вместо запуска долгой и ресурсоемкой проверки всей базы данных DBCC CHECKDB, которая на поврежденном диске может окончательно вывести его из строя, мы можем выполнить точечную операцию восстановления конкретной таблицы _InfoRG21904 с помощью команды DBCC CHECKTABLE. Разберем этот процесс по шагам:
Переведем базу данных в однопользовательский режим, чтобы монопольно заблокировать объекты конфигурации:
ALTER DATABASE [Имя_Вашей_Базы] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
Запустим исправление конкретной сбойной таблицы с флагом удаления поврежденных данных. СУБД найдет битую страницу памяти, очистит ее и восстановит логическую структуру таблицы. Обратите внимание, что поврежденная запись при этом сотрется, но вся остальная таблица останется работоспособной:
DBCC CHECKTABLE ('_InfoRG21904', REPAIR_ALLOW_DATA_LOSS);
Вернем базу данных в стандартный многопользовательский режим работы:
ALTER DATABASE [Имя_Вашей_Базы] SET MULTI_USER;
Этот метод хорош тем, что он требует минимум времени, не затрагивает другие таблицы и позволяет мгновенно вернуть базу данных к нормальной работе и возобновить создание регулярных бэкапов.
Если поврежденная запись находится в некритичном регистре (например, история версий объектов или кэш файлов) и потеря данных в этой таблице не повлияет на ведение бухгалтерского учета, мы можем быстро пересоздать структуру таблицы в SQL «с нуля» без потери всей остальной базы данных. Рассмотрим пошаговый алгоритм выполнения этой операции:
Создадим новую пустую таблицу с точно такой же структурой, как и у нашей поврежденной таблицы. Для этого используем конструкцию SELECT TOP 0:
SELECT TOP 0 *
INTO _InfoRg21904_New
FROM _InfoRg21904;
Удалим поврежденную таблицу, которая мешает выполнять бэкапы и выгрузку базы:
DROP TABLE _InfoRg21904;
Переименуем нашу новую пустую таблицу, присвоив ей имя удаленной сбойной таблицы:
EXEC sp_rename '_InfoRg21904_New', '_InfoRg21904';
После выполнения этих команд структура базы данных 1С останется полностью корректной, платформа не выдаст ошибку «Нарушена целостность структуры конфигурации», а битый сектор больше не будет мешать процессу резервного копирования.
Если диск работает крайне нестабильно и мы боимся проводить любые операции записи на исходном накопителе, мы можем пойти по пути создания абсолютно новой базы данных на исправном физическом диске и переноса туда всех «здоровых» данных. Именно этот способ успешно применил автор темы на форуме. Разберем этот процесс детально:
_InfoRG21904. Запускаем процесс копирования.
CREATE TABLE [dbo].[_InfoRg21904] (
[_Fld21905_TYPE] binary(1) NOT NULL,
[_Fld21905_RTRef] binary(4) NOT NULL,
[_Fld21905_RRRef] binary(16) NOT NULL,
[_Fld21906] varbinary(max) NOT NULL,
[_Fld1099] numeric(7,0) NOT NULL
);
Таким образом, мы получаем полностью работоспособную и чистую базу данных на надежном оборудовании. Ошибки чтения СУБД исчезнут, и база данных снова будет корректно выгружаться в файл формата .dt.
Если в таблице ДвоичныеДанныеФайлов хранятся очень важные документы организации и нам категорически нельзя терять всю таблицу из-за одной битой строки, мы можем применить алгоритм построчного переноса данных с обработкой ошибок. Для этого пишется T-SQL скрипт с использованием курсора, который считывает каждую запись по отдельности. Примерная схема работы такого скрипта выглядит следующим образом:
_InfoRG21904.BEGIN TRY ... END TRY / BEGIN CATCH ... END CATCH.CATCH перехватит эту ошибку, запишет идентификатор поврежденного файла в лог-таблицу для последующего анализа и позволит скрипту продолжить работу со следующей строки.Выясним причину, как пересоздание или частичная очистка регистра ДвоичныеДанныеФайлов повлияет на работу пользователей в программе «1С:Бухгалтерия 3.0»:
%userprofile%\AppData\Local\Temp\1C.... Проанализировав эти папки, можно вернуть значительную часть важных документов.Чтобы своевременно обнаруживать физический износ жестких дисков и предупреждать повреждение баз данных до того, как они станут критическими, крайне важно правильно настроить параметры СУБД MS SQL Server.
Проанализируем настройку Page Verify (Проверка страниц) в свойствах базы данных. По умолчанию она должна иметь значение CHECKSUM. При такой конфигурации SQL Server рассчитывает контрольную сумму для каждой записываемой страницы данных и сверяет ее при каждом чтении. При первых признаках деградации диска система мгновенно запишет ошибку в системный журнал Windows (Event Viewer), что позволит вам вовремя заменить жесткий диск или перенести базу данных без экстренной остановки работы предприятия.