Коллеги, нужен совет. Бэкап падает:
BACKUP 'MyDB' detected an error on page (8:144922587) in file 'MyDB_4.ndf'
checkdb выдаёт:
Msg 2576, Level 16, State 1, Line 1
The Index Allocation Map (IAM) page (0:0) is pointed to by the previous pointer of IAM page (1:5847919) in object ID 0, index ID -1, partition ID 0, alloc unit ID 72057718624026624 (type Unknown), but it was not detected in the scan.
Куда копать, как лечить?

Запускайте DBCC CHECKDB

уже, checkdb выдаёт:
Msg 2576, Level 16, State 1, Line 1
The Index Allocation Map (IAM) page (0:0) is pointed to by the previous pointer of IAM page (1:5847919) in object ID 0, index ID -1, partition ID 0, alloc unit ID 72057718624026624 (type Unknown), but it was not detected in the scan.

Спасибо. Это общее направление или там есть про мой конкретный случай?

У вас обычный случай ) первая статья вам вполне подойдет.

Может активней работать начали? Или объём данных вырос?

Да тут  разница в 3 дня. Не похоже

Ну тогда в битву экстрасенсов

Обновления последния для сиквела стоят?

Да, само собой. Последний CU

Тогда смотрите что выполняется

Чудес не бывает

Добрый день. Подскажите, пожалуйста, если кто сталкивался с похожим? Есть запрос, в плане запроса для одной из таблиц в 2016 sql server есть операция index seek, а в 2019м index scan, который работает дольше. С хинтом запрос работает быстро(как в 2016), есть ли ещё способы поменять поведение оптимизатора? Compatibility level 150, legacy cardinality estimation on

переписать запрос?

План запроса нужно смотреть, сам запрос, миллион вариантов, от простого - индекса нет или он имеет фрагментацию, до бесконечности

Индексы есть, поменялся план от seek к scan. Запрос там особо не переписать(

Что-то можно сделать в этом случае, кроме добавления хинта?

Можно - перестать себя обманывать и показать запрос + план запроса

Ну и ? Разные сервера, разные базы... Почему ты думаешь, что планы должны быть одинаковые?