Ха - мой (не) любимый вопрос, который мне задают (как я писал DBCC CHECKDB).
Ну вот:
Есть только один раз, когда вы должны попытаться выяснить, сколько времени займет CHECKDB, - когда вы планируете регулярное обслуживание базы данных. Если вы столкнулись с поврежденной (или предположительно поврежденной) базой данных и только начинаете задумываться о том, сколько времени займет CHECKDB, - вы допустили ошибку при планировании стратегии аварийного восстановления. Вам всегда нужно знать, сколько времени занимает CHECKDB (в среднем) для запуска вашей базы данных, поэтому:
- Вы можете определить, занимает ли конкретный запуск CHECKDB больше времени, чем обычно, - признак того, что он обнаружил какое-то повреждение
- Вы знаете, сколько времени потребуется, чтобы получить результаты в ситуации аварийного восстановления.
На каждой конференции, на которую я приезжаю, кто-то спрашивает меня, сколько времени потребуется CHECKDB для работы с их базой данных. Я могу ответить на этот вопрос несколькими способами:
- Бесполезный ответ - понятия не имею.
- Практически полезный ответ - сколько времени потребовалось для запуска в прошлый раз и такие же ли условия?
- Ответ, который я обычно даю - зависит от обстоятельств.
Многие люди сочли бы третий ответ в некоторой степени эквивалентным первому - бесполезным. Проблема в том, что существует множество факторов, влияющих на то, сколько времени потребуется для запуска CHECKDB. Позвольте мне объяснить десять наиболее важных факторов, чтобы вы поняли, почему это действительно полезный ответ. Они не находятся в каком-либо определенном порядке важности.
- Размер базы данных Довольно очевидно ... CHECKDB должен читать каждую выделенную страницу в базе данных, поэтому чем она больше, тем больше времени потребуется для чтения всех страниц.
- Одновременная нагрузка ввода-вывода на сервере На простейшем уровне, что будет делать CHECKDB? Он читает каждую выделенную страницу в базе данных. Это много ввода-вывода. CHECKDB прилагает большие усилия, чтобы выполнить максимально эффективный ввод-вывод, и считывать страницы базы данных в их физическом порядке с большим количеством опережающих операций чтения, чтобы головки дисков плавно перемещались по дискам (вместо того, чтобы беспорядочно прыгать и вызывать задержки при поиске головки диска). Если на сервере нет одновременной нагрузки ввода-вывода, операции ввода-вывода будут настолько эффективными, насколько это может сделать CHECKDB. Однако введение любого дополнительного ввода-вывода из SQL Server означает, что головки дисков будут прыгать, замедляя операции ввода-вывода CHECKDB. Если подсистема ввода-вывода уже загружена в соответствии с требованиями ввода-вывода CHECKDB, любой дополнительный ввод-вывод будет уменьшать пропускную способность ввода-вывода, доступную для CHECKDB, - замедляя ее.
- Одновременная активность ЦП на сервере На следующем уровне простоты CHECKDB будет каким-то образом обрабатывать каждую прочитанную страницу. В зависимости от различных параметров, которые вы указали, и схемы базы данных (подробности ниже), это будет использовать много ЦП - возможно, что сервер может быть привязан к 100% ЦП при работе CHECKDB. Если на сервере есть дополнительная рабочая нагрузка, это отнимет у CHECKDB циклы ЦП и замедлит его. В основном пункты №2 и №3 говорят о том, что CHECKDB очень ресурсоемкий! Вероятно, это одна из самых ресурсоемких задач, которые вы можете попросить сделать SQL Server, поэтому обычно рекомендуется не запускать его во время пиковых нагрузок, поскольку вы не только заставите CHECKDB работать дольше, но и замедлит одновременная нагрузка, возможно, недопустимо.
- Одновременное обновление базы данных Это актуально как для SQL 2000, так и для SQL 2005, но по разным причинам. В SQL 2000 CHECKDB получает согласованное представление о базе данных из анализа журнала транзакций параллельных транзакций DML (подробности см. Здесь). Чем больше одновременных DML-файлов во время работы CHECKDB, тем больше будет сгенерировано журнала транзакций - и, следовательно, тем больше времени потребуется CHECKDB для анализа этого журнала транзакций. Возможно, что на большом многопроцессорном компьютере с множеством одновременных DML и CHECKDB, ограниченных одним процессором, эта фаза CHECKDB может занять в несколько раз больше времени, чем чтение и обработка страниц базы данных! (Я видел это в реальной жизни несколько раз.) В SQL 2005 CHECKDB получает согласованное представление о базе данных из моментального снимка базы данных, который хранится на тех же дисковых томах, что и сама база данных. Если во время работы CHECKDB в базе данных происходит много изменений, измененные страницы помещаются в моментальный снимок, чтобы он оставался согласованным. Поскольку файлы моментальных снимков хранятся в том же месте, что и файлы базы данных, каждый раз, когда страница помещается в моментальный снимок, головка диска должна перемещаться, что прерывает эффективный ввод-вывод, описанный в №2. Кроме того, всякий раз, когда CHECKDB отправляется на чтение страницы и ему необходимо прочитать страницу из файлов моментальных снимков, а не из файлов базы данных, это еще одно перемещение головки диска и еще одно эффективное прерывание ввода-вывода. Чем больше одновременных изменений в базе данных, тем больше прерываний для эффективного ввода-вывода и тем медленнее работает CHECKDB.
- Пропускные возможности подсистемы ввода-вывода Это просто. CHECKDB собирается выполнить загрузку операций ввода-вывода и может даже оказаться привязанной к вводу-выводу (что означает, что ЦП периодически простаивают, ожидая завершения операций ввода-вывода) в зависимости от указанных параметров и схемы базы данных. Это означает, что пропускная способность подсистемы ввода-вывода будет иметь прямое влияние на время выполнения CHECKDB. Итак, если у вас есть база данных 1 ТБ, а подсистема ввода-вывода может управлять только 100 МБ / с, на чтение базы данных уйдет почти 3 часа (1 ТБ / 100 МБ / 3600 секунд), и вы ничего не можете сделать, чтобы ускорить это, кроме обновить подсистему ввода-вывода. Я потерял счет, сколько раз слышал, как клиенты жалуются на то, что CHECKDB (или перестройка индексов или другие операции с интенсивным вводом-выводом) выполняются медленно, только чтобы обнаружить, что длины дисковых очередей огромны, а подсистема ввода-вывода совершенно не имеет себе равных. сервер и рабочая нагрузка.
- Количество процессоров (процессорных ядер) на коробке Это также действительно включает в себя запускаемый выпуск SQL Server. В Enterprise Edition CHECKDB может работать параллельно на всех ЦП в коробке (или столько, сколько процессор запросов решит распараллелить при компиляции внутренних запросов CHECKDB). Параллельная работа может значительно повысить производительность CHECKDB и снизить время выполнения, если база данных также распределена по нескольким файлам (так что операции ввода-вывода могут быть распараллелены). Используется отличный алгоритм, который позволяет CHECKDB работать параллельно, о чем я подробно расскажу в одном из следующих постов. С другой стороны, тот факт, что CHECKDB может работать параллельно в Enterprise Edition, может быть плохим для некоторых сценариев, и поэтому некоторые администраторы баз данных решили принудительно использовать CHECKDB в однопоточном режиме. SAP обычно рекомендует это для обеспечения предсказуемости запросов пользователей. Для этого нужно включить задокументированный флаг трассировки 2528.
- Скорость дисков, на которых размещена база данных tempdb. Запуск CHECKDB для VLDB использует много памяти для внутреннего состояния, а для VLDB требования к памяти обычно превышают объем памяти, доступный для SQL Server. В этом случае состояние передается в буфер tempdb, и поэтому производительность tempdb может быть критическим фактором для производительности CHECKDB. См. Этот пост для получения дополнительной информации об этом и о том, как CHECKDB может не хватить дискового пространства, если tempdb слишком мал.
- Сложность схемы базы данных Это может иметь очень большое влияние на время выполнения CHECKDB, поскольку влияет на количество ресурсов ЦП, необходимых для CHECKDB. Например, самые дорогие проверки, которые выполняет CHECKDB, относятся к некластеризованным индексам. Необходимо проверить, что каждая строка в некластеризованном индексе соответствует ровно одной строке в куче или кластеризованном индексе для таблицы, и что каждая строка кучи / кластеризованного индекса имеет ровно одну совпадающую строку в каждом некластеризованном индексе. Хотя для этого существует высокоэффективный алгоритм, он все равно занимает около 30% всего ЦП, который использует CHECKDB! Есть множество других проверок, которые выполняются только в том случае, если функции были использованы в базе данных - например, вычисляемая оценка столбца, связи между внешними значениями LOB, Service Broker, XML-индексы, индексированные представления - так что вы можете видеть, что эмпирических факторов недостаточно для определения времени выполнения.
- Какие параметры указаны Это почти то же самое, что и №7 в том, что, задавая различные параметры, вы ограничиваете, какие проверки выполняет CHECKDB. Например, использование параметра WITH NOINDEX отключит проверки некластеризованного индекса, которые я описал в # 7, а использование параметра WITH PHYSICAL_ONLY отключит все логические проверки, значительно уменьшив время выполнения CHECKDB и сделав его почти всегда вводом-выводом. -bound, а не CPU (фактически, это наиболее распространенный вариант, который администраторы баз данных VLDB используют для обеспечения управляемости времени выполнения CHECKDB). Следует помнить об одном: если вы укажете какие-либо параметры восстановления, CHECKDB всегда будет работать в однопоточном режиме, даже на многопроцессорном компьютере в Enterprise Edition.
- Количество и тип повреждений, существующих в базе данных. Опять же, это похоже на № 7 и № 8. Если есть какие-либо повреждения, могут быть запущены дополнительные проверки, чтобы попытаться выяснить более подробную информацию о повреждениях. Например, для проверок некластеризованного индекса алгоритм очень сильно настроен для случая, когда нет никаких повреждений (подавляющее большинство случаев, учитывая миллионы раз, когда CHECKDB запускается каждый день по всему миру). Когда обнаруживается повреждение некластеризованного индекса, необходимо использовать более глубокий алгоритм, чтобы точно определить, где находится повреждение, что включает повторное сканирование группы данных и, таким образом, занимает больше времени. Есть еще несколько подобных алгоритмов.
Теперь еще одна вещь, о которой следует помнить, заключается в том, что использование REPAIR_ALLOW_DATA_LOSS заставляет проверки выполняться в однопоточном режиме, поэтому исправления заказываются правильно, что увеличивает время его выполнения. Посмотрите в журнале ошибок 2005 SP2 + сообщение 5268 - оно указывает на глубокое погружение, как я упоминал выше.
Резюме Как видите, однозначного ответа нет. Надеюсь это поможет!
PS Забыл сказать, что в SQL 2005 я добавил в DBCC CHECKDB отчет о проделанной работе. Вы можете запросить sys.dm_exec_requests DMV и ищите percent_complete столбец.
Это полностью зависит от размера БД (вы указали 47 МБ), количества повреждений, скорости системы и т. Д. Я бы продолжал запускать ее, пока вы не получите тайм-аут или другую ошибку, на всякий случай. Либо так, либо восстановите заведомо исправную резервную копию, если она у вас есть.
Вы также можете запустить ProcessExplorer и посмотрите на использование ЦП / диска, чтобы увидеть, действительно ли он что-то делает или «завис».
Этот ответ явно не соответствует замечательному ответу Пола на ваш конкретный вопрос.
Однако чтение между строками, если у вас есть поврежденная база данных поиска в SharePoint, при 47 МБ, вероятно, будет намного быстрее сбросить индекс поиска и повторно сканировать контент, чем пытаться исправить любые повреждения в базе данных поиска. . Шаги здесь (статья базы знаний посвящена другой проблеме, но шаги по сбросу индекса поиска / базы данных такие же): http://support.microsoft.com/kb/948909
По-прежнему не помешало бы выяснить основную причину повреждения и установить базовую среду выполнения CheckDB в ваших базах данных контента, но база данных поиска сама по себе является полупереходной сущностью. Вашим единственным успехом будет полный обход (который вы, вероятно, захотите запустить в непиковые часы ... это довольно интенсивно для ЦП и ввода-вывода).