Как исправить ошибку при попытке выборки логической страницы в базе данных 1С на MS SQL Server?

← На главную

Ошибки, связанные с выборкой логических страниц, — это один из самых серьезных сигналов для системного администратора или разработчика 1С. Как правило, такая проблема возникает после аварийного завершения работы сервера, сбоев в электропитании или деградации дискового массива. В данной ситуации база данных SQL Server теряет физическую или логическую целостность, что делает невозможным чтение определенных данных, проведение документов или даже создание резервной копии в формате .dt.

В этой статье мы подробно рассмотрим, как восстановить работоспособность системы, проанализируем причины возникновения ошибки и разберем по шагам методы «лечения» базы данных методами MS SQL и средствами самой платформы 1С:Предприятие.

Выясним причину: что такое логическая страница и почему она «битая»?

База данных MS SQL Server хранит информацию в страницах объемом 8 КБ. Логическая целостность означает, что структура данных внутри этих страниц и связи между ними (указатели на следующие и предыдущие страницы) корректны. Когда SQL Server сообщает об ошибке выборки страницы, это значит, что контрольная сумма страницы не совпадает с записанной или указатель ссылается на несуществующий или поврежденный объект. Проанализируем ситуацию: если ошибка возникает только при проведении конкретных документов (например, реализаций), значит, повреждена конкретная таблица, к которой обращается этот процесс.

Шаг 1. Диагностика и попытка мягкого восстановления через DBCC CHECKDB

Первым делом нам необходимо определить масштаб катастрофы. Для этого воспользуемся встроенной утилитой SQL Server — командой DBCC CHECKDB. Рассмотрим алгоритм действий в SQL Server Management Studio (SSMS).

Для выполнения восстановительных работ базу необходимо перевести в монопольный режим. Разберем пример кода для базы с именем MyBase1C:


-- Переводим базу в однопользовательский режим, обрывая все активные соединения
ALTER DATABASE MyBase1C SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO

-- Запускаем проверку с попыткой исправления без потери данных
DBCC CHECKDB (N'MyBase1C', REPAIR_REBUILD) WITH NO_INFOMSGS;
GO

-- Возвращаем многопользовательский режим
ALTER DATABASE MyBase1C SET MULTI_USER;
GO

Параметр REPAIR_REBUILD является безопасным — он пытается перестроить индексы и исправить ошибки, которые не влекут за собой удаление данных. Однако, как показывает практика (и сообщения с форумов), при серьезных повреждениях страниц данных этот метод может не помочь.

Шаг 2. Анализ конкретной поврежденной таблицы

Если после выполнения предыдущей команды ошибки сохраняются, нам нужно внимательно изучить лог проверки. Ищем строки вида Object ID 12345678, index ID 1... Page (1:3605) could not be processed. Чтобы понять, какая таблица 1С пострадала, выполним запрос:


SELECT name FROM sys.objects WHERE object_id = 12345678;

Рассмотрим ситуацию, когда поврежденной оказывается таблица с префиксом AccumRgT (например, AccumRgT6441). Это критически важный момент для понимания архитектуры 1С. Таблицы AccumRgT — это таблицы итогов регистров накопления. Сами данные (движения) хранятся в таблицах AccumRg.

Шаг 3. Эффективное решение для таблиц итогов

Если диагностика показала, что «битая» страница находится в таблице итогов, мы можем применить радикальный, но безопасный метод — очистку и пересчет итогов. Поскольку итоги являются расчетными данными, их можно удалить и сформировать заново на основе движений.

Выясняем имя таблицы в SQL.
Выполняем команду очистки: TRUNCATE TABLE _AccumRgT6441; (будьте осторожны, делайте это только после подтверждения, что это таблица итогов!).
Заходим в 1С:Предприятие в режиме «Администрирование».
Переходим в «Управление итогами» и запускаем «Полный пересчет итогов».

Этот метод позволяет физически удалить битые страницы, так как TRUNCATE освобождает место на диске и создает новую структуру таблицы, а последующий пересчет заполняет её корректными данными.

Шаг 4. Крайняя мера — REPAIR_ALLOW_DATA_LOSS

Если повреждена основная таблица с данными (например, _Document или _Reference), и REPAIR_REBUILD не помог, остается вариант REPAIR_ALLOW_DATA_LOSS. Проанализируем риски: SQL Server просто удалит поврежденную страницу целиком, чтобы восстановить структуру базы. Данные на этой странице будут потеряны навсегда.


ALTER DATABASE MyBase1C SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
DBCC CHECKDB (N'MyBase1C', REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS;
GO
ALTER DATABASE MyBase1C SET MULTI_USER;
GO

Важно: После выполнения этой команды обязательно запустите в 1С процедуру Тестирование и исправление (ТиИ) с включенными галочками «Проверка логической целостности» и «Проверка ссылочной целостности». Это необходимо, так как после удаления страниц в базе могут появиться «битые ссылки» (объекты, которые ссылаются на удаленные данные).

Шаг 5. Работа с системной таблицей suspect_pages

Посмотрим на проблему с точки зрения SQL-администрирования. SQL Server ведет учет всех обнаруженных поврежденных страниц в системной базе msdb. Мы можем проверить состояние дисковой подсистемы следующим запросом:


SELECT * FROM msdb.dbo.suspect_pages;

Если вы видите там много записей, это серьезный повод проверить аппаратную часть: RAID-контроллер, кэш дисков и состояние HDD/SSD. Возможно, батарейка контроллера (BBU) разряжена, и при аварийном отключении данные из кэша не дошли до диска, что и вызвало логические ошибки.

Подведем итоги

Для успешного решения проблемы мы должны действовать методично:

Сначала локализуем ошибку через DBCC CHECKDB.
Определяем тип поврежденной таблицы 1С (данные или итоги).
Используем REPAIR_REBUILD для безопасного восстановления.
При повреждении итогов — используем TRUNCATE и пересчет в 1С.
В безнадежных случаях используем REPAIR_ALLOW_DATA_LOSS с последующим ТиИ.

Помните, что регулярное создание бэкапов и их проверка (восстановление из бэкапа на тестовый сервер) — единственный гарантированный способ защиты от подобных инцидентов. Если ваш последний рабочий бэкап был сделан несколько месяцев назад, описанные выше методы SQL-восстановления станут вашим единственным шансом сохранить данные.

← На главную