Категория: Инструкции
Откуда: Севастополь
Сообщений: 247
DBCC CHECKDB
( 'database_name'
[. NOINDEX
| { REPAIR_ALLOW_DATA_LOSS
| REPAIR_FAST
| REPAIR_REBUILD
} ]
) [ WITH { [ ALL_ERRORMSGS ]
[. [ NO_INFOMSGS ] ]
[. [ TABLOCK ] ]
[. [ ESTIMATEONLY ] ]
[. [ PHYSICAL_ONLY ] ]
}
]
REPAIR_ALLOW_DATA_LOSS Performs all repairs done by REPAIR_REBUILD and includes allocation and deallocation of rows and pages for correcting allocation errors, structural row or page errors, and deletion of corrupted text objects. These repairs can result in some data loss. The repair may be done under a user transaction to allow the user to roll back the changes made. If repairs are rolled back, the database will still contain errors and should be restored from a backup. If a repair for an error has been skipped due to the provided repair level, any repairs that depend on the repair are also skipped. After repairs are completed, back up the database.
REPAIR_FAST Performs minor, nontime-consuming repair actions such as repairing extra keys in nonclustered indexes. These repairs can be done quickly and without risk of data loss.
REPAIR_REBUILD Performs all repairs done by REPAIR_FAST and includes time-consuming repairs such as rebuilding indexes. These repairs can be done without risk of data loss.
Re: DBCC checkdb что это? [new]
Откуда: Tomsk
Сообщений: 107
Инструкция DBCC CHECKDB выполняет оперативный анализ целостности всех структур хранения в базе данных. Оперативная проверка, как и другие операции, связанные с поддержкой сервера SQL Server, оказывает минимальное воздействие на основную рабочую нагрузку.
По умолчанию инструкция DBCC CHECKDB выполняет детальную проверку всех структур данных. Для повышения эффективности использования больших многопроцессорных систем эта проверка выполняется в параллельном режиме.
Обычно инструкция DBCC CHECKDB используется с параметром PHYSICAL_ONLY для проверки физической структуры страницы и заголовков записей. Данная операция позволяет выполнить быструю проверку для выявления ошибок, вызванных оборудованием.
Только еще не понял (извините за непонятливость) эта команда устраняет ошибки или нет?
Бывают ситуации, когда базаданных MS SQL внезапно переключается в режим "Suspect Mode". Перевести базу в нормальный режим без починка базы, не представляется возможным. DBCC checkdb также не запускается если база данных находится в этом режиме. Что делать? Следуйте следующим инструкциям.
Прежде всего следует перевести БД в режим EMERGENCY:
Затем выполните тестирование базы данных:
О компании:info@center-comptech.ru
Написать директору
О компании
В ваши обязанности, как DBA, вероятно входит оптимизация производительности, восстановление, настройка прав доступа и тд. Но многие склонны забывать о такой важной операции, как проверка целостности БД (DBCC CHECKDB). Вы можете решить данную задачу просто создав план обслуживания «»Check Database Integrity Task», однако это всего лишь checkdbox.
Как вы видите, здесь мы почти не можем ничего контролировать, хотя для данной операции существует множество интересных ключей. Я думаю, что вам следует более детально погрузиться в DBCC CHECKDB и создать собственное, подходящее именно вам, задание. Основным преимуществом собственного задания будет сокращение времени работы и как следствие уменьшение требуемых ресурсов для данной операции. Так же могут быть такие преимущества как универсальность, управляемость, обработка ошибок и тд.
Уменьшение вывода и сбор всех ошибок:Не важно где вы запускаете CHECKDB, всегда запускайте с опцией WITH NO_INFOMSGS. Эта простая опция подавляет все информационные сообщения, которые просто сообщают вам как много строк в каждой таблице, если вам необходима данная информация, вы можете получить её из DMV, вне команды CHECKDB.
Так же вы всегда должны использовать опцию WITH ALL_ERRORMSGS, особенно если вы используете SQL Server 2008 RTM или SQL Server 2005 (тогда вы сможете увидеть более 200 строк). Любая CHECKDB операция обрезается 1000 строками в Management Studio и иногда может потребоваться перенаправить вывод в файл. Понимание данного механизма позволит вам получать всю информацию с первого раза и не будет надобности перезапускать процесс.
Используйте только физическую проверку данных на продуктивной среде:В большинстве случаев, CHECKDB тратит основное время на логические проверки данных. Если у вас есть возможность провести данную проверку на достоверной копии данных, то вы можете сфокусироваться только на физической структуре на вашей продуктивной системе. Под достоверной копией данных я понимаю ТОЛЬКО восстановление БД из backup на другом сервере.
Такие способы как:
Не являются достоверной копией данных и логическая проверка на данных технологиях, не даст достоверный результат относительно продуктивной среды. Только точно такая же копия БД может быть достоверной.
Эксперименты с флагами трассировки 2549, 2562, and 2566:Я нашёл, что флаги трассировки 2549 и 2562 могут улучшить производительность CHECKDB. Найти описание данных флагов можно в KB #2634571. но в целом:
Trace Flag 2549 (оптимизирует процесс проверки из расчёта, что каждый файл данных БД лежит на своём собственном диске. Флаг можно использовать когда БД имеет один файл данных или каждый файл данных лежит на своём диске, в противном случае это может ухудшить производительность CHECKDB)
Trace Flag 2562 (процесс CHECKDB будет запущен в одном батче, что будет более дорогой операцией для tempdb (до 5% от размера проверяемой БД). Это более лучший алгоритм для чтений страниц из БД, который уменьшает latch contention). Данный флаг уже включён в SQL Server 2012, так что начиная с этой версии включать его отдельно не требуется.
Trace Flag 2566 (Если вы до сих пор используете SQL Server 2005 (напоминаю что Microsoft уже не поддерживает данную версию), то вы можете использовать флаг 2566, который представлен в SP2 CU9. Флаг исправляет проблему производительности DATA_PURITY на x64 системах. Вы можете посмотреть подробности KB #945770. Данный флаг не требуется включать на других версиях SQL Server)
Если вы решитесь использовать данные флаги, то я настоятельно рекомендую включать их с помощью DBCC TRACEON, а не через параметры запуска SQL Server. Это даст вам возможность выключить флаги без перезагрузок.
Уменьшение нагрузки на дисковую подсистему (оптимизация tempdb):DBCC CHECKDB может сильно нагружать tempdb, постарайтесь выделить для данной БД достаточно ресурсов (тестируйте).
Уменьшение нагрузки на дисковую подсистему (snapshot):Запуская DBCC CHECKDB, современные версии SQL Server создают скрытый snapshot вашей БД на том же диске (или на тех же дисках если вы используете несколько файлов tempdb). Вы не можете контролировать данный механизм, но если вы хотите указать где именно необходимо создавать snapshot, то вы можете сделать свой snapshot на любой диск (доступно только в Enterprise Edition) и запустить DBCC CHECKDB по данному snapshot. Лучше всего пользоваться данным методом в период минимальной активности на запись-обновление вашей БД.
Вы можете ускорить DBCC CHECKDB запустив его в offline mode (с блокировками) используя опцию WITH TABLOCK. Я строго не рекомендую этим пользоваться, так как это значительно ухудшит доступность БД.
Уменьшение нагрузки на CPU:DBCC CHECKDB запускается в параллельном режиме по-умолчанию, но только если у вас Enterprise Edition. Если у вас недостаточно CPU ресурсов, то вы можете уменьшить параллелизм несколькими способами:
К сожалению, Microsoft не планирует реализовывать использование MAXDOP для CHECKDB, хотя их об этом неоднократно просили.
Мои результаты:Я хотел бы продемонстрировать влияние описанных выше способов на время выполнения DBCC CHECKDB. Тесты производились на БД AdventureWorks2012 и с запуском скрипт а, который увеличил размер данной БД до 7 ГБ:
CHECKDB results against 7 GB database
Далее я увеличил размер БД до 70 ГБ и провёл тесты снова:
CHECKDB results against 70 GB database
Главные мысли после тестов:
Хотелось бы продемонстрировать нагрузку на CPU во времяDBCC CHECKDB:
На больших БД результаты могут отличаться, поэтому вам обязательно надо проводить своё собственное тестирование.
Заключение:DBCC CHECKDB очень важная и часто недооцененная задача DBA. Не совершайте ошибки других DBA.
История началась с того, что умер винт в RAID(0). Слава Богам, удалось создать виртуальный образ с помощью RAID Reconstructor от Runtime Software. С помощью приложения Captain Nemo (от того же Runtime Software) часов за 8-10(два винта по 300 ГБ) удалось построить структуру и файловой системы опираясь на виртуальный образ созданный RAID Reconstructor»ом. Ещё за несколько часов восстановились базы, общим весом около 10 ГБ. 70% работы, казалось бы, выполнено! Особо не радуясь, принялся восстанавливать сервер.
Взял новые винты. Установил ту же систему, тот же SQL Server 2005 с тем же collation. Сделал Attach DataBase для всех восстановленных баз, кроме системных. Для того, чтобы избежать лишних проблем, базы нужно размещать в те же папки что и до того как система упала. Заменил базу master на свою восстановленную(о том как перемещать системные базы, в том числе master и MSDB, читал тут http://msdn.microsoft.com/ru-ru/library/ms345408.aspx ; позже выложу у себя весь текст статьи).
Выполнил несколько селектов – кажется, всё ок.
Запускаю приложение, использующие эти базы… и на одной из форм получаю красивенький exception: «SQL Server detected a logical consistency-based i/o error: incorrect pageid».
Выполняю DBCC DBReindex() – не спасло.
Пробую DBCC CHECKDB( ‘DatabaseName’ ) - после ряда сообщений, команда прерывается с сообщением об ошибке:
Msg 8967, Level 16, State 216, Line 1
An internal error occurred in DBCC which prevented further processing. Please contact Product Support.
Выполнение остановилось как раз на самой большой таблице в базе.
Деваться некуда, запускаю
ALTER DATABASE ‘DatabaseName’ SET SINGLE_USER
DBCC CHECKDB ( ‘DatabaseName’ , REPAIR_REBUILD )
ALTER DATABASE ‘DatabaseName’ SET MULTI_USER
REPAIR_REBUILD- попробует восстановить БД без потери данных.
Жду завершения выполнения команды.
Если не восстановит, буду пробовать
Обязательно отпишусь чем всё закончилось. Ещё не выполнял DBCC CHECKDB( ‘DatabaseName’ ) для остальных баз.
Рассмотрим несколько вариантов восстановления БД, в зависимости от того, насколько повреждены файлы БД зависит успешность того или иного метода. Все описанные способы были лично мной проверены на практике и все случаи восстановления, за исключением одного, были успешны. Используйте данное руководство на свой страх и риск, за совершенные вами действия ответственность несете, вы сами.
Итак, во-первых останавливаем службу SQL Server и копируем файлы базы данных (*.mdf и *.ldf) в другую папку, чтобы можно было восстановить их в случае неудачи.
Если у вас есть свежий актуальный бэкап, то дальше можете не читать, а просто восстановите БД из него, тем самым сэкономите драгоценное время, далее я приведу алгоритмы восстановления для разных версий SQL Server. Надеюсь вам это поможет, как в свое время помогло и мне.
Для всех версий SQL Server подойдет следующий вариант: делаем Detach database(отсоединить базу данных), удаляем журнал транзакций(файл с расширением ldf) и делаем Attach database(присоединить базу данных). В мастере выбираем наш mdf файл и жмем ОК.
Если mdf файл не поврежден, то он успешно присоединится и мы увидим нашу базу в диспетчере объектов целую и невредимую.
Радуемся успешному восстановлению. (Этот вариант сработает только если mdf файл не поврежден, поэтому срабатывает не всегда). Если не получилось, то создаем новую базу данных с таким же именем, останавливаем сервер. Подменяем файл mdf файлом от нашей базы, стартуем службу SQL Server и открываем Query analyzer(SQL 2000) или Management studio(SQL 2005/2008) в зависимости от нашей версии сервера.
если DBCC не хочет выполняться, то вместо REPAIR_REBUILD нужно подставить REPAIR_ALLOW_DATA_LOSS
Жмем F5, ждем некоторое время. Сервер вернет кучу сообщений. Если там будут содержаться ошибки, то лучше еще раз выполнить DBCC CHECKDB с параметром REPAIR_REBUILD. пока все ошибки не будут устранены.
Для SQL 2005/2008 действия несколько иные:
DBCC CHECKDB ( 'db_name'. REPAIR_ALLOW_DATA_LOSS )
GO
Тут без вариантов. В SQL 2005 и выше нет инструкции REBUILD_LOG. вместо этого выполняется CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS .
После того как сервер закончит выполнять запрос и вернет результат, меняем REPAIR_ALLOW_DATA_LOSS на REPAIR_REBUILD и выполняем запрос еще раз, это должно убрать оставшиеся ошибки в бд.
После всего этого наша база становится в нормальное состояние и уже доступна для работы с ней, но только в однопользовательском режиме, поэтому завершаем наш процесс возвращением бд в многопользовательский режим.