В процессе эксплуатации крупных информационных баз 1С на платформе MS SQL Server администраторы иногда сталкиваются с критическими ошибками целостности данных. Одной из самых неприятных является ситуация, когда физическое повреждение страницы данных (ошибка BUF_IOERR) происходит в таблицах итогов регистра бухгалтерии. В этом случае стандартные механизмы 1С, такие как "Тестирование и исправление" или "Выгрузка информационной базы", перестают работать, так как при чтении битой страницы процесс аварийно завершается. Рассмотрим, как решить эту проблему путем принудительной очистки таблиц и их последующего восстановления.
Разберем ситуацию, описанную в логе CHECKDB. Ошибка указывает на несоответствие идентификаторов единиц размещения и невозможность обработки страницы. Фраза Тест (IS_OFF (BUF_IOERR, pBUF->bstat)) не прошел прямо сигнализирует о том, что SQL Server не может прочитать данные с диска. Это может быть вызвано сбоем контроллера, "битыми" секторами на диске или ошибкой файловой системы.
Проанализируем структуру поврежденного объекта. Таблица _AccRgAT21781 — это таблица итогов регистра бухгалтерии "Хозрасчетный" (в разрезе счетов и субконто). Важно понимать, что данные в этой таблице являются производными. Это означает, что они не вводятся пользователем напрямую, а рассчитываются платформой на основании основной таблицы движений (записей регистра). Следовательно, удаление данных из этой таблицы не приведет к потере первичной информации, если основная таблица движений (обычно _AccRg21774 или аналогичная) цела.
Существует несколько подходов к решению проблемы, когда DBCC CHECKDB выдает ошибки согласованности:
TRUNCATE TABLE не сканирует записи по одной, а просто освобождает пространство (деаллоцирует страницы), занятое таблицей. Это позволяет "выбросить" поврежденную страницу без необходимости ее чтения.Выполним последовательность действий для безопасного восстановления работоспособности системы. Рассмотрим процедуру на примере таблицы _AccRgAT21781.
Шаг 1: Подготовка и создание резервной копии
Перед любыми манипуляциями с таблицами SQL обязательно создадим полную резервную копию базы данных. Даже если база "битая", копия позволит нам вернуться к исходной точке в случае неудачи.
Шаг 2: Очистка поврежденных таблиц в SQL Management Studio
Выясним, какие еще таблицы относятся к данному регистру бухгалтерии. Обычно это таблицы с префиксами _AccRgT (общие итоги) и _AccRgAT (итоги по субконто). Проанализируем ситуацию: если мы очистим только одну поврежденную таблицу, может возникнуть рассинхронизация между разными уровнями итогов. Поэтому правильнее очистить весь набор таблиц итогов для конкретного регистра.
Выполним следующую команду в SQL Query Analyzer:
TRUNCATE TABLE _AccRgAT21781;
-- Также рекомендуется очистить связанные таблицы итогов того же регистра
TRUNCATE TABLE _AccRgT21782;
Использование TRUNCATE вместо DELETE критически важно. DELETE записывает каждое удаление в лог транзакций и пытается прочитать строку перед удалением, что приведет к ошибке на битой странице. TRUNCATE просто помечает страницы как свободные.
Шаг 3: Сброс состояния рассчитанных итогов в 1С
После очистки таблиц на уровне SQL, платформа 1С все еще "думает", что итоги рассчитаны по определенную дату. Нам нужно заставить систему понять, что итогов нет и их нужно пересчитать с самого начала. Рассмотрим программный способ сделать это через внешнюю обработку:
Менеджер = РегистрыБухгалтерии.Хозрасчетный;
// Устанавливаем период рассчитанных итогов в пустую дату (начало времен)
Менеджер.УстановитьПериодРассчитанныхИтогов('00010101');
Менеджер.УстановитьПериодЗавершенияРассчитанныхИтогов('00010101');
Шаг 4: Полный пересчет итогов
Теперь перейдем к финальному этапу. Запустим пересчет итогов. Это можно сделать двумя способами:
Менеджер = РегистрыБухгалтерии.Хозрасчетный;
// Запускаем полный пересчет
Менеджер.ПересчитатьИтоги();
Проанализируем процесс: система начнет последовательно считывать данные из таблицы движений (которая, как мы надеемся, не повреждена) и заново заполнять очищенные нами таблицы _AccRgAT и _AccRgT.
Рассмотрим альтернативный инструмент, упомянутый в документации 1С — утилиту 1cv8a.exe. Она предназначена для исправления проблем с хеш-полями и некоторых структурных дефектов без запуска конфигуратора. Если стандартные средства вылетают с ошибкой APPCRASH (как в Сообщении 8), это подтверждает серьезность повреждения файла базы или библиотек. В таких случаях утилита может не помочь, но попробовать её стоит на ранних этапах диагностики, используя команду исправления хешей.
Выясним причину, по которой возникла ошибка CHECKDB. Если мы просто пересчитаем итоги, но не устраним физическую причину, ошибка вскоре появится в другом месте — например, в таблице документов или справочников, где данные уже не являются производными и их потеря будет безвозвратной.
Обязательно выполним следующие действия:
chkdsk /f /r.Disk.Подводя итог, можно подтвердить: да, таблицы итогов регистра бухгалтерии можно "грубо" очищать средствами SQL. Это является стандартной практикой при восстановлении после сбоев. Главное — соблюдать последовательность: полная копия, использование TRUNCATE, программный сброс периода итогов и последующий полный пересчет. После завершения всех процедур обязательно запустите DBCC CHECKDB повторно, чтобы убедиться, что база данных полностью здорова.