SQL-Ex blog

Вы открываете SSMS, и не обнаруживаете базы данных в браузере объектов. При этом база существует, если обратиться запросом к sys.databases; но почему её нет в браузере объектов? Это странно, но не беспокоит. Вы пытаетесь подключиться к базе данных с помощью "USE", но получаете следующую ошибку:

Msg 40863, Level 14, State 2, Line 1
Connections to this database are no longer allowed.
(Подключения к этой базе данных больше не разрешаются.)

Это безумие! Что теперь? Открыть тикет в MSFT? Это казалось единственным выходом, и в чем была основная причина? По-видимому, в Azure Managed Instances Майкрософт проверяет базы данных на повреждения, и отключает их, если таковые обнаруживаются.

В этом отключенном состоянии нет возможности получить доступ к базе данных, и требуется обращаться к Майкрософт. Вы не можете установить базу данных в режим восстановления или изменить его на ONLINE. Microsoft действительно «связывается» с кем-то, чтобы уведомить о том, что база данных была отключена из-за повреждения, но если вы работаете в более-менее крупной компании, это уведомление может никогда не дойти до нужных людей.

После того, как база данных снова станет доступной, у вас, вероятно, будет ограниченное время для устранения неполадок, потому что повторная проверка на наличие повреждений снова отключит базу данных при ее запуске.

Что еще хуже, имеется ограниченное число вариантов пофиксить базу данных.

• Вы можете запустить CHECKDB в Managed Instance, однако они не допускают режима SINGLE_USER, что означает отсутствие возможности использовать опцию REPAIR в CHECKDB. В идеале вы хотели бы исправить обнаруженное повреждение, но в этом сценарии CHECKDB либо занял бы слишком много времени, и база данных сама бы отключилась, либо процесс потерпел неудачу из-за нехватки ресурсов. Поэтому я не смог бы даже выяснить, какое было повреждение, т.к. suspect_pages не содержит строк.
  
  


• Вы не можете выполнить восстановление с помощью REPLACE, поскольку это не допускается.


• Удалить существующую базу данных? Вероятно, нет. В этом случае процесс застрял бы из-за сбоя в конце резервного копирования журнала, и было бы невозможно удалить базу данных. Это должно быть исправлено Майкрософт.

Итак, востребована ли DBCC CHECKDB в 2020? Безусловно в случае миграции! Представьте себе, что вы работаете 3 дня, а потом не можете использовать данные этих трех дней. Хорошо, если это тестовая база данных. Я встречал много клиентов, которые говорили: "Мы не можем использовать CHECKDB, поскольку она не завершается, или база данных слишком велика". Помните, что вы можете по отдельности выполнять CHECK ALLOC, CHECKTABLE или CHECKCATALOG.

Что мы узнали?

1. ВСЕГДА выполняйте CHECKDB как шаг, предшествующий миграции. Если у вас есть бэкап, восстановите его и запустите CHECKDB.


2. Решение PaaS для баз данных может стать головной болью в некоторых сценариях, поскольку вы отказываетесь от контроля над некоторыми задачами управления.


3. Вы можете выполнить CHECKDB в Managed Instance, но вы не можете использовать восстановление.


4. CHECKDB может быть очень расточителен к ресурсам, поэтому запускайте CHECKALLOC, CHECKCATALOG и CHECKTABLE порознь ежедневно.


5. Майкрософт выполняет проверки повреждений в фоновом режиме с вашими бэкапами (это не означает, что CHECKDB не нужна. Вы по-прежнему должны выполнять свои 101 задачу DBA.)

Примечание: Availability Groups предлагает “Automatic Page Repair” (автоматическое восстановление страниц), которое может быть полезно, если это произошло в Azure или там, где был сделан этот бэкап.