Как исправить ошибку MS SQL «Запись каталога не обнаружена для идентификатора секции» в базе 1С

← На главную

При работе с базами данных 1С:Предприятие на платформе MS SQL Server системные администраторы иногда сталкиваются с критической ошибкой: «Запись каталога не обнаружена для идентификатора секции ... в базе данных. Метаданные несогласованы». Эта проблема опасна тем, что стандартные средства восстановления, такие как DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS, не всегда могут её устранить, а сама база при этом может продолжать работать, создавая иллюзию благополучия. В этой статье мы подробно разберем, как локализовать поврежденный объект и восстановить работоспособность системы.

Анализируем природу ошибки

Разберем ситуацию: ошибка чаще всего возникает при попытке выгрузки базы в файл .dt, при создании начального образа РИБ или во время выполнения операции «Тестирование и исправление». Суть проблемы заключается в рассинхронизации системных таблиц SQL Server. Идентификатор секции (Partition ID), на который ссылается ошибка, — это внутренний номер, который должен указывать на конкретную таблицу или индекс. Если SQL Server не находит описание этого ID в своих системных каталогах, он останавливает процесс проверки, считая структуру базы нарушенной.

Важно понимать, что перенос базы через Full Backup на другой сервер (даже на более новую версию SQL 2019 или 2022) не решит проблему, так как повреждение находится внутри страниц данных самого файла .mdf. Ошибка просто «переедет» на новое место.

Шаг 1: Первичная диагностика через SQL-запросы

Первым делом попробуем найти, какому объекту принадлежит проблемный идентификатор. Рассмотрим стандартный запрос к системным представлениям. В тексте ошибки всегда указано число (например, 72339071758893056). Выполним поиск в контексте вашей базы данных:


SELECT 
    p.partition_id, 
    p.object_id, 
    OBJECT_NAME(p.object_id) AS TableName, 
    i.name AS IndexName
FROM sys.partitions AS p
JOIN sys.indexes AS i ON p.object_id = i.object_id AND p.index_id = i.index_id
WHERE p.partition_id = 72339071758893056;

Если этот запрос вернул имя таблицы, нам повезло — мы точно знаем «виновника». Однако часто бывает так, что запрос ничего не находит. Это происходит потому, что запись в sys.partitions уже отсутствует, а ссылка на неё в других системных структурах (например, в единицах распределения) осталась.

Шаг 2: Глубокий поиск через системные таблицы распределения

Если первый шаг не дал результатов, проанализируем ситуацию глубже. Попробуем найти идентификатор в таблице sys.allocation_units, которая отвечает за физическое размещение данных на диске. Выясним, с какой секцией связан этот блок:


SELECT 
    au.allocation_unit_id, 
    au.container_id, 
    au.type_desc, 
    p.object_id, 
    OBJECT_NAME(p.object_id) AS TableName
FROM sys.allocation_units AS au
LEFT JOIN sys.partitions AS p ON au.container_id = p.partition_id
WHERE au.container_id = 72339071758893056 
   OR au.allocation_unit_id = 72339071758893056;

Проанализируем результат: если поле TableName заполнено, мы нашли объект. Если оно пустое, но есть object_id, используйте функцию OBJECT_NAME(ID) для получения имени таблицы вручную.

Шаг 3: Проверка целостности каталогов

Прежде чем переходить к радикальным мерам, выполним команду проверки системных каталогов. Это поможет понять, насколько масштабны повреждения метаданных:

DBCC CHECKCATALOG ('Имя_Вашей_Базы');

Если команда завершилась без ошибок, но DBCC CHECKDB все равно «падает», значит, проблема кроется в конкретном индексе или таблице, которые ссылаются на несуществующую секцию. Рассмотрим, как это исправить средствами 1С.

Шаг 4: Использование инструментов 1С:Предприятие

Поскольку наша база — это прикладное решение 1С, мы можем заставить платформу пересоздать структуру таблиц и индексов. Это часто помогает «вычистить» мусорные записи в метаданных SQL Server.

Запустим 1С:Предприятие в режиме Конфигуратор.
Перейдем в меню Администрирование — Тестирование и исправление.
Выберем только два пункта: «Реиндексация таблиц» и «Пересчет итогов».
В поле «При наличии ссылок на несуществующие объекты» выберем «Очищать».

Во время реиндексации платформа 1С дает команду SQL Server удалить старые индексы и построить новые. В процессе удаления старых структур SQL Server может игнорировать битые ссылки, а новые индексы будут созданы уже с корректными partition_id.

Шаг 5: Радикальное решение — миграция данных таблицы

Если тестирование и исправление не помогло, и мы определили имя «битой» таблицы (например, _InfoRg12345), разберем метод ручного восстановления. Рассмотрим алгоритм действий:

Создадим в SQL Management Studio скрипт создания (CREATE TO) для поврежденной таблицы, включая все её индексы.
Переименуем поврежденную таблицу в SQL (например, в _InfoRg12345_OLD).
Создадим новую пустую таблицу с оригинальным именем _InfoRg12345, используя полученный ранее скрипт.
Попробуем перелить данные из «старой» таблицы в «новую» командой:


INSERT INTO _InfoRg12345 WITH (TABLOCK)
SELECT * FROM _InfoRg12345_OLD;

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

Шаг 6: Альтернатива через выгрузку XML

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

Выгрузим данные только поврежденного объекта (например, конкретного регистра сведения) в XML-файл из текущей базы.
Если выгрузка не проходит из-за ошибки SQL, попробуем выгружать частями (по периодам).
Очистим таблицу в базе (через удаление объекта в конфигурации или через TRUNCATE TABLE в SQL, если вы уверены в своих действиях).
Загрузим данные обратно из XML.