Как долго следует ожидать запуска CheckDB с REPAIR_ALLOW_DATA_LOSS?

Ха - мой (не) любимый вопрос, который мне задают (как я написал DBCC CHECKDB).

Ну вот:

Есть только один раз, когда вы должны пытаться определить, сколько времени займет CHECKDB - когда вы планируете регулярное обслуживание базы данных. Если вы столкнулись с поврежденной (или предположительно испорченной) базой данных и только начинаете задумываться о том, сколько времени займет CHECKDB - вы допустили ошибку при планировании стратегии аварийного восстановления. Вам всегда нужно знать, сколько времени CHECKDB (в среднем) занимает для работы с вашей базой данных, так:

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

На каждой конференции, на которой я бываю, кто-то спрашивает, сколько времени CHECKDB займет для работы с их базой данных. Есть несколько способов ответить на это:

• Бесполезный ответ - я понятия не имею.
• Почти полезный ответ - сколько времени потребовалось для запуска в прошлый раз, и условия точно такие же?
• Ответ я обычно даю - это зависит.

Теперь многие люди считают третий ответ несколько эквивалентным первому ответу - бесполезным. Проблема в том, что существует много факторов, которые влияют на то, как долго CHECKDB будет работать. Позвольте мне объяснить десять самых важных факторов, чтобы вы поняли, почему это действительно полезный ответ. Это не в каком-то определенном порядке важности.

1. Размер базы данных довольно очевиден... CHECKDB должен читать каждую выделенную страницу в базе данных, поэтому чем она больше, тем больше времени займет чтение всех страниц.
2. Нагрузка параллельного ввода-вывода на сервере На самом простом уровне, что собирается делать CHECKDB? Он читает каждую выделенную страницу в базе данных. Это много IO. CHECKDB делает все возможное, чтобы сделать наиболее эффективный ввод-вывод и читать страницы базы данных в их физическом порядке с большим количеством чтения, чтобы головки дисков плавно перемещались по дискам (вместо случайного скачкообразного перемещения и задержки поиска головки диска). Если на сервере нет одновременной нагрузки ввода-вывода, то эти операции ввода будут такими же эффективными, как и CHECKDB. Тем не менее, введение любого дополнительного ввода-вывода из SQL Server означает, что головки дисков будут прыгать, замедляя операции ввода-вывода CHECKDB. Если подсистема ввода-вывода уже загружена в соответствии с требованиями ввода-вывода CHECKDB, любой дополнительный ввод-вывод приведет к уменьшению пропускной способности ввода-вывода, доступной для CHECKDB, и замедлит ее.
3. Параллельная активность ЦП на сервере На следующем уровне простоты CHECKDB собирается обработать каждую страницу, которую он каким-то образом читает. В зависимости от различных опций, которые вы указали, и схемы базы данных (подробности ниже), будет использоваться много ЦП - возможно, что сервер может быть привязан к 100% ЦП во время работы CHECKDB. Если на сервере есть какая-либо дополнительная нагрузка, это отнимает циклы процессора от CHECKDB и замедляет его. В основном, пункты № 2 и № 3 говорят о том, что CHECKDB очень ресурсоемкий! Вероятно, это одна из самых ресурсоемких вещей, которую вы можете попросить SQL Server сделать, и поэтому обычно лучше не запускать ее во время пиковых нагрузок, поскольку вы не только заставите CHECKDB работать дольше, но и замедлит параллельная рабочая нагрузка, возможно, недопустимо.
4. Параллельное обновление базы данных. Это относится как к SQL 2000, так и к SQL 2005, но по разным причинам. В SQL 2000 CHECKDB получает согласованное представление базы данных из анализа журнала транзакций одновременных транзакций DML (подробности см. Здесь). Чем больше одновременного DML существует во время работы CHECKDB, тем больше будет сгенерировано журнала транзакций - и, следовательно, CHECKDB будет дольше анализировать этот журнал транзакций. Вполне возможно, что на большом многопроцессорном компьютере с множеством одновременных DML и CHECKDB, ограниченных одним процессором, этот этап CHECKDB может занять в несколько раз больше времени, чем чтение и обработка страниц базы данных! (Я видел это в реальной жизни несколько раз.) В SQL 2005 CHECKDB получает согласованное представление базы данных из снимка базы данных, который хранится на тех же дисковых томах, что и сама база данных. Если во время работы CHECKDB в базе данных происходит много изменений, измененные страницы помещаются в моментальный снимок, чтобы он оставался согласованным. Поскольку файлы моментальных снимков хранятся в том же месте, что и файлы базы данных, каждый раз, когда страница перемещается в моментальный снимок, необходимо перемещать головку диска, что прерывает эффективный ввод-вывод, описанный в # 2. Кроме того, всякий раз, когда CHECKDB отправляется на чтение страницы, и ему необходимо прочитать страницу из файлов моментальных снимков, а не из файлов базы данных, это еще одно перемещение головки диска и еще одно эффективное прерывание ввода-вывода. Чем больше параллельных изменений в базе данных, тем больше прерываний для эффективного ввода-вывода и тем медленнее выполняется CHECKDB.
5. Пропускная способность подсистемы ввода-вывода. Это просто. CHECKDB собирается выполнить загрузку IO, и он может даже оказаться связанным с IO (это означает, что процессоры периодически простаивают, ожидая завершения IO) в зависимости от указанных опций и схемы базы данных. Это означает, что пропускная способность подсистемы ввода-вывода будет иметь прямое влияние на время выполнения CHECKDB. Итак, если у вас есть база данных объемом 1 ТБ, а подсистема ввода-вывода может управлять только 100 МБ / с, то на чтение базы данных уйдет почти 3 часа (1 ТБ / 100 МБ / 3600 с), и вы ничего не можете сделать, чтобы ускорить это, кроме обновить подсистему ввода-вывода. Я потерял счет, сколько раз я слышал, что клиенты жалуются, что CHECKDB (или перестроение индекса, или другие операции с интенсивным вводом-выводом) выполняются неоправданно только для того, чтобы обнаружить, что длина дисковой очереди огромна, а подсистема ввода-вывода совершенно не соответствует сервер и рабочая нагрузка.
6. Количество процессоров (процессорных ядер) на коробке Это также действительно включает Выпуск SQL Server, который запускается. В Enterprise Edition CHECKDB может работать параллельно на всех процессорах в блоке (или столько, сколько процессор запросов решит распараллелить, когда скомпилированы внутренние запросы CHECKDB). Параллельная работа может значительно повысить производительность CHECKDB и сократить время выполнения, если база данных также распределена по нескольким файлам (поэтому операции ввода-вывода могут быть распараллелены). Существует изящный алгоритм, который позволяет CHECKDB работать параллельно, что я подробно объясню в следующем посте. С другой стороны, тот факт, что CHECKDB может работать параллельно в Enterprise Edition, может быть плохим для некоторых сценариев, и поэтому некоторые администраторы баз данных решили заставить CHECKDB быть однопоточным. SAP обычно рекомендует это, чтобы помочь с предсказуемостью пользовательских запросов. Способ сделать это состоит в том, чтобы включить задокументированный флаг трассировки 2528.
7. Скорость дисков, на которых находится база данных tempdb. Запуск CHECKDB для VLDB использует много памяти для внутреннего состояния, а для VLDB требование к памяти обычно превышает объем памяти, доступный для SQL Server. В этом случае состояние выводится в буфер базы данных tempdb, поэтому производительность базы данных tempdb может быть критическим фактором в производительности CHECKDB. См. Этот пост для более подробной информации об этом и о том, как CHECKDB может исчерпать место на диске, если tempdb слишком мал.
8. Сложность схемы базы данных. Это может оказать очень сильное влияние на время выполнения CHECKDB, поскольку оно влияет на количество ЦП, которое требуется CHECKDB. Например, самые дорогие проверки, которые выполняет CHECKDB, относятся к некластеризованным индексам. Необходимо проверить, что каждая строка в некластеризованном индексе отображается точно на одну строку в куче или кластеризованном индексе для таблицы, и что каждая строка кучи / кластеризованного индекса имеет ровно одну подходящую строку в каждом некластеризованном индексе. Несмотря на то, что для этого существует высокоэффективный алгоритм, он по-прежнему занимает около 30% от общего процессора, используемого CHECKDB! Существует множество других проверок, которые выполняются только в том случае, если функции используются в базе данных - например, вычисление вычисляемых столбцов, связи между значениями внеблоковых больших объектов, компонент Service Broker, индексы XML, индексированные представления - так что вы можете видеть, что эмпирические факторы вместе не достаточно, чтобы определить время выполнения.
9. Какие параметры указаны Это почти то же самое, что #7 в этом, указав различные параметры, вы ограничиваете, какие проверки CHECKDB фактически выполняет. Например, использование параметра WITH NOINDEX отключит некластеризованные проверки индекса, которые я описал в #7, а использование параметра WITH PHYSICAL_ONLY отключит все логические проверки, значительно сократив время выполнения CHECKDB и сделав его почти всегда IO привязанный, а не привязанный к процессору (фактически это наиболее распространенный вариант, который используют администраторы баз данных VLDB для обеспечения управляемости среды выполнения CHECKDB). Следует помнить одну вещь - если вы укажете какие-либо параметры восстановления, CHECKDB всегда работает однопоточным, даже на многопроцессорном компьютере в Enterprise Edition.
10. Количество и тип повреждений, существующих в базе данных. Опять же, это похоже на № 7 и № 8. Если присутствуют какие-либо искажения, могут быть запущены дополнительные проверки, чтобы попытаться выяснить более подробную информацию о повреждениях. Например, для некластеризованных проверок индекса алгоритм очень сильно настроен для случая, когда нет никаких искажений (подавляющее большинство случаев, учитывая миллионы раз, когда CHECKDB выполняется каждый день по всему миру). При обнаружении искажения некластеризованного индекса необходимо использовать более глубокий алгоритм, чтобы точно определить, где именно происходит повреждение, что включает повторное сканирование группы данных и, таким образом, отнимает больше времени. Есть и несколько других подобных алгоритмов.

Еще одна вещь, которую нужно иметь в виду, заключается в том, что использование REPAIR_ALLOW_DATA_LOSS делает проверки однопоточными, поэтому ремонтные операции заказываются правильно - что делает его дольше. Посмотрите в журнале ошибок 2005 SP2+ сообщение 5268 - оно указывает на глубокое погружение, как я упоминал выше.

Резюме Итак, вы можете видеть, что нет простого ответа. Надеюсь это поможет!

PS Забыл сказать, что в SQL 2005 я добавил отчеты о прогрессе в DBCC CHECKDB. Вы можете запросить sys.dm_exec_requests DMV и искать percent_complete колонка.