Это 2020 год, действительно ли мне нужно DBCC CHECKDB?

дата:

 Я начну с того, что клянусь, что я опубликовал это в какой-то момент в прошлом, но я не могу найти это, пролистывая старые сообщения. Это было 19 августа ‘хотя я не видел никаких заметок о сбоях в Azure.

Допустим, вы видите запрос на восстановление резервной копии базы данных в управляемом экземпляре Azure. Вы выполняете эту задачу, а затем через несколько дней команда, запросившая восстановление, говорит, что у них возникли проблемы с подключением к недавно восстановленной резервной копии.

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

Msg 40863, Уровень 14, Состояние 2, Строка 1

Подключения к этой базе данных больше не допускаются.

Это безумие! И что теперь? Открыть тикет с MSFT? Казалось, это был единственный выход, и какова же была его первопричина? Очевидно, в управляемых экземплярах Azure Microsoft будет проверять базы данных на наличие повреждений и отключит их в автономном режиме, если они будут обнаружены.

Когда в этом особом автономном состоянии нет никакого способа получить доступ к базе данных, и с Microsoft необходимо связаться. Вы не можете установить БД в режим восстановления или изменить его на онлайн. Microsoft действительно "связывается" с кем-то, чтобы уведомить, что база данных была отключена из-за сбоя, но если вы работаете в более крупной компании, это уведомление может никогда не дойти до нужных людей.

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

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

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


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

    Это 2020 год, имеет ли значение DBCC CHECKDB? Для миграций абсолютно! Представьте себе, что вы входите в prod в течение 3 дней, а затем не можете использовать эти 3 дня данных. К счастью, это была тестовая база данных. За эти годы я видел много клиентов, которые говорили: “мы не можем сделать CHECKDB, потому что он не будет завершен или база данных слишком велика”. Имейте в виду, что вы можете запустить CHECK ALLOC, CHECKTABLE и CHECKCATALOG по отдельности.

    Что мы узнали сегодня?

    1. Всегда запускайте CHECKDB в качестве предварительного шага миграции. Если вам дали резервную копию, восстановите ее и запустите CHECKDB.
    2. Решения для баз данных PaaS могут быть болезненными в некоторых сценариях, потому что вы отказались от контроля над некоторыми задачами управления (проще-не всегда лучше).
    3. Вы можете запустить CHECKDB в управляемом экземпляре,но не можете использовать восстановление.
    4. CHECKDB может быть слишком ресурсоемким, поэтому ежедневно запускайте CHECKALLOC, CHECKCATALOG и CHECKTABLE независимо друг от друга.
    5. Microsoft запускает проверку на наличие коррупции в фоновом режиме с вашими резервными копиями (это не значит, что CHECKDB не нужен. Вы все еще должны выполнять свои задачи DBA 101.)

    Боковое Примечание: группы доступности предлагают “автоматическое восстановление страниц", которое может быть полезно, если это произошло в Azure или было на месте, откуда когда-либо поступала эта резервная копия БД.