Проблемы
Рассмотрим следующий сценарий.
-
В Microsoft SQL Server 2014 есть две секционированные таблицы, а разделы первой таблицы сопоставляются с разными файлами и файловыми группами с использованием одной и той же схемы и функции секционирования.
-
Вы переключились на одну из этих секций во вторую и затем вырезается из второй таблицы.
-
Вы удаляете файлы и файловые группы, которые сопоставлены с переключенной секцией.
-
Вы запускаете инструкцию SELECT во второй таблице.
В этом случае появляется следующее сообщение об ошибке:
Сообщение 606, уровень 21, несогласованность состояния 1Metadata. Идентификатор файловой группы<идентификатор файловой группы> указан для таблицы <имя таблицы> не существует. Запустите DBCC CHECKDB или CHECKCATALOG.
При запуске DBCC CHECKDB/CHECKTABLE появляется следующее сообщение об ошибке:
Не удалось обработать индекс <IndexName> таблицы <TableName> из-за неправильной файловой группы (ИД файловой группы <FileGroupNumber>).
Решение
Эта проблема впервые устранена в следующих накопительных обновлениях SQL Server:
Все новые накопительные обновления для SQL Server содержат все исправления и все исправления для системы безопасности, которые были включены в предыдущий накопительный пакет обновления. Мы рекомендуем вам загрузить и установить последние накопительные обновления для SQL Server.
Примечание. Это исправление предотвращает появление этой проблемы в будущем. Если вы уже столкнулись с этой проблемой, экспортируйте данные в новую базу данных без повреждений существующих метаданных. Для этого выполните следующие действия:
-
Чтобы определить, содержит ли секция недопустимую файловую группу, выполните следующий запрос, чтобы убедиться, что он возвращает результат.
SELECT * FROM sys.allocation_units AS au WHERE au.data_space_id NOT IN (SELECT data_space_id FROM sys.filegroups)
-
Сделайте таблицу с повреждением метаданных еще раз видна. Если запрос из шага 1 возвращает результат, раздел с поврежденными метаданными не позволяет просмотреть (SELECT * FROM) строки в таблице. Чтобы обойти эту проблему, удалите поврежденный раздел.Примечание. Неправильный раздел должен быть пустым. В противном случае файлы и файловую группу, в которых они находились, не были удалены или удалены. Для этого переместите этот раздел в другую таблицу, использующую ту же схему секционирования. Это может быть только фиктивная таблица. Используйте container_id из запроса в шаге 1, а затем установите для него соответствие partition_id из sys. partitions. (Обратите внимание, что partition_number). С помощью partition_number можно выполнить инструкцию ALTER TABLE SWITCH PARTITION for Table, которая была непроверяема для фиктивной таблицы. Фиктивная таблица должна иметь один и тот же набор столбцов и использовать одну и ту же схему секционирования. Запрос на обнаружение непоследовательного раздела может выглядеть примерно так:
SELECT au.container_id, au.data_space_id, p.partition_number FROM sys.partitions AS p JOIN sys.allocation_units AS au ON p.partition_id = au.container_id LEFT JOIN sys.filegroups AS fgs ON fgs.data_space_id = au.data_space_id WHERE object_id = OBJECT_ID('MyTableName') AND fgs.data_space_id IS NULL;
-
Скопируйте данные из ранее непросмотренной таблицы в новую базу данных.
Статус
Корпорация Майкрософт подтверждает наличие этой проблемы в своих продуктах, которые перечислены в разделе "Применяется к".