M
Двух зайцев одним хинтом!
Size: a a a
2021 June 09
A
И медальку "меткий стрелок"
ПЛ
С tablock он принудительно все подключения сбросит к БД, или есть шанс что DBCC так и будет в ожидании висеть?
O
Будет висеть, только всякие WITH ROLLBACK IMMEDIATE сбрасывают соединения.
ПЛ
Понял, спасибо
O
Но, пока он будет висеть, то все, кому надо почитать ту же таблицу, будут вставать в очередь за ним. Не самый лучший вариант. А реплики нигде нет?
A
Реплику проверять это не совсем то. Физически это другая бд.
O
Я пытался решить такую задачу через разделение DBCC CHECKDB на кучу CHECK TABLE, CHECK ALLOC и CHECK CATALOG. Это было в рамках попытки сделать обслуживания БД управляемым и ограничить его по времени. вот тут то, что получилось. писалось довольно давно, за некоторые куски кода мне немного неловко. https://github.com/trootnev/VBMS
O
Да, верно. Мы не проверим таким образом исходный носитель информации на физическом уровне. Но если БД поднимается из бэкапа, то это почти полностью покрывает проблему.
A
Как вариант - проверять с noindex. Не будут проверяться некластерные индексы, но это не особо страшно - их можно перестроить.
O
Мне кажется, это только на скорость повлияет, но не на размер снимка.
DI
У меня подобная задача была, нужно было проверять кучу баз с множеством партиционированных таблиц и желательно ежедневно. Делал так: самые старые партиции проверял раз в неделю, далее за последний год по дням от самой старой до самой новой с учётом изменений данных в конкретной партиции. Это все конечно работает, но долго как ни крути. Лучшее решение это конечно делать регулярное восстановление базы отдельно и там же проверять. Таким образом вы делаете ещё и проверку вашего бэкапа, что тоже не помешает.
А
Здесь работают с экспортом бд в визуал студио?
А
P
что значит в вижуал студию? надо модельки сгенерить?
С
я думаю всё же речь про проект базы через ssdt и потом его деплой через azure с помощью dacpac и sqlpackage