Індекс стовпців стовпців у групі файлів read_only заважає CheckDB

Здається, встановлення групи файлів read_onlyзапобігає dbcc checkdbдля всієї бази даних, якщо група файлів містить індекс стовпців стовпців. При спробі запуску checkdbабо checkfilegroup( для будь-якої групи файлів у базі даних, включаючи вторинники для читання і запису[PRIMARY] ), повертається нижче помилка ...

Msg 8921, Level 16, State 1, Line 24
Check terminated. A failure was detected while collecting facts. 
Possibly tempdb out of space or a system table is inconsistent. Check previous errors.

Чи підтримується метод зберігання даних стовпців у групі файлів лише для читання? Або мені в цьому сценарії не дозволяється перевірити цілісність?

Репро

create database check_fg_ro
go
use check_fg_ro
go
exec sp_changedbowner 'sa';
go
alter database check_fg_ro add filegroup check_fg_ro_2;
alter database check_fg_ro
    add file (
         name='check_fg_ro_2'
        ,filename='C:\check_fg_ro_2.ndf'
    ) to filegroup check_fg_ro_2;
go
create table foo ( 
    i int not null primary key
) on check_fg_ro_2;
go
create columnstore index ccix_foo on foo(i);
go
use master
go
alter database check_fg_ro modify filegroup check_fg_ro_2 read_only;
go
dbcc checkdb( check_fg_ro ) with no_infomsgs, all_errormsgs, extended_logical_checks;
/*
Msg 8921, Level 16, State 1, Line 24
Check terminated. A failure was detected while collecting facts. 
Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
*/
go

_{Відмова: перехресне повідомлення на форумах технологій}

Проблема виникає, коли DBCC намагається перевірити видалену растрову карту для таблиці зберігання стовпців, доступних лише для читання.

Видалені растрові карти зберігаються в тій же групі файлів, що і таблиця стовпців стовпців. Вони відстежують рядки, логічно видалені зі стислих груп рядків.

Наскільки я можу сказати, все організовано правильно у внутрішніх системних таблицях (на SQL Server 2017 CU3), і більшість кодів DBCC правильно обліковує приховані набори рядків, що містять видалені бітові карти стовпців.

Чомусь перевірка наявності файлів у режимі офлайн або лише для читання призводить до необробленого винятку:

Msg 8921, Level 16, State 1, Line 69
Check terminated. A failure was detected while collecting facts.
Possibly tempdb out of space or a system table is inconsistent.
Check previous errors.

Ця сама перевірка в режимі офлайн / лише для читання виконується кілька разів раніше в обробці DBCC (коли збираються факти) без проблем.

Проблема виникає під час DBCC CHECKDBабо DBCC FILEGROUPзапуску (у будь-якій групі файлів), або DBCC CHECKTABLEйого просять перевірити певну таблицю зберігання стовпців, доступних лише для читання. Жодне з них не повинно створювати фатальну помилку, яка перешкоджає виконанню решти перевірок DBCC, тому це має бути помилка.

Або мені в цьому сценарії не дозволяється перевірити цілісність?

Як вирішення, запустіть DBCC CHECKFILEGROUPгрупу файлів стовпців безпосередньо перед тим, як вона буде зроблена лише для читання (або запустити DBCC CHECKDBв цей час), тоді:

1. DBCC CHECKALLOC на базі даних
2. Біжи DBCC CHECKCATALOG
3. Запустити DBCC CHECKTABLEдля кожної таблиці (крім таблиць зберігання стовпців у групі файлів лише для читання)
4. Ви також можете побігти DBCC CHECKCONSTRAINTS.

Див. Параметри перевірки послідовності для VLDB від Пола Рандала та Q&A, що розділяє DBCC CHECKDB протягом декількох днів .

По-перше, дякую за інформацію та відтворюючий код / ​​ситуацію.

Я взяв це і подав внутрішній предмет, він призначений і незабаром буде розглянуто.

Ви можете проголосувати за роботу у групі файлів, щоб read_only запобігає запуску dbcc checkdb на сайті зворотного зв’язку на SQL Server.

Я оновлю цю відповідь більшою інформацією, коли вона стане доступною.