Я работаю над реализацией метода Пола Рэндала, который заключается в том, чтобы вручную распределять DBCC CHECKDB в течение нескольких дней для очень больших баз данных, который в основном состоит из:
- Разделение таблиц в базе данных примерно поровну между 7 сегментами
- Запуск DBCC CHECKALLOC два раза в неделю
- Запуск DBCC CHECKCATALOG один раз в неделю
- Запуск DBCC CHECKTABLE для одного сегмента каждый день недели
Кто-нибудь использовал эту технику? Есть какие-нибудь существующие сценарии?
Я обеспокоен тем, что это может не охватывать все, что делает CHECKDB; В документации по электронной документации для CHECKDB говорится, что в дополнение к CHECKALLOC, CHECKCATALOG и CHECKTABLE также:
- Проверяет содержимое каждого индексированного представления в базе данных.
- Проверяет согласованность на уровне ссылок между метаданными таблицы и каталогами и файлами файловой системы при хранении данных varbinary (max) в файловой системе с использованием FILESTREAM. (Только SQL 2008)
- Проверяет данные компонента Service Broker в базе данных.
Итак, вот мои вопросы:
Эти дополнительные проверки необходимы / важны? (Индексированные представления, вероятно, немного больше относятся ко мне, я не думаю, что мы пока используем Service Broker или FILESTREAM.)
Если да, есть ли способы выполнить эти дополнительные проверки отдельно?
CHECKALLOC и CHECKCATALOG, кажется, работают очень быстро, даже на больших БД. Есть ли причина не запускать их каждый день?
(Примечание: это будет стандартная процедура для тысяч существующих баз данных на сотнях серверов или, по крайней мере, для каждой базы данных более определенного размера. Это означает, что такие варианты, как реструктуризация всех баз данных для использования CHECKFILEGROUP, на самом деле не практичны для нас.)
источник
Ответы:
Вы можете запустить
DBCC CHECKTABLE WITH EXTENDED_LOGICAL_CHECKSнепосредственно на индексированных представлениях . Проверка индексированных представлений может быть проблематичной в определенных обстоятельствах , поэтому будьте готовы исследовать любые ложные срабатывания, которые могут быть получены. (Пол Рэндал также упоминает в комментариях к ссылочной статье, что ложные негативы также возможны, но у меня нет прямого опыта в этом.)Нет поддержки для запуска Service Broker или
FILESTREAMчеков отдельно, нет.Не то, чтобы я в курсе.
Вы также можете подумать о беге
DBCC CHECKCONSTRAINTS. Эта проверка не включена вDBCC CHECKDB, независимо от каких - либо параметров , которые вы можете указать. Вы также можете подумать о том, чтобы время от времени бегатьCHECKDB, когда это позволяют обстоятельства.источник
DBCC CHECKDB жизненно важен для баз данных SQL Server, чтобы быть на 100% уверенными в отсутствии коррупции. Однако из-за огромного размера баз данных очень сложно найти окно обслуживания, когда вы заявляете, что работаете 24x7. За прошедшие годы команда SQL Server внедрила различные механизмы, которые будут выявлять наиболее распространенные формы повреждений, особенно связанных с физическим повреждением, вызванным оборудованием.
SQL Server 2005 и выше имеет PAGE_VERIFY = CHECKSUM, что может помочь вам заранее обнаруживать физическое повреждение на страницах базы данных, тем самым добавляя контрольную сумму на каждую страницу, когда она записывается в систему ввода-вывода, и проверяет контрольную сумму, когда она читается с диска.
Кроме того, резервное копирование (полное или дифференциальное) с помощью CHECKSUM гарантирует обнаружение любого повреждения ввода-вывода, вызванного аппаратным обеспечением.
Следовательно, с аппаратной стороны коррупции, SQL Server хорошо обнаруживает и сообщает об этом. (Убедитесь, что вы также установили важные оповещения о коррупции ).
Это, как говорится, все еще логичное повреждение , вызванное ошибками скриблера - когда страницы в памяти повреждены либо сторонним кодом, выполняющимся внутри процесса SQL Server, либо драйверами или другим программным обеспечением с достаточными привилегиями, выполняющимися в режиме ядра Windows и / или SQL Server. Ошибки и т. Д. Не выявляются с помощью вышеуказанных методов, и, следовательно, CHECKDB входит в картину.
DBCC CHECKDB выполняет более тщательные проверки, которые включают проверку заголовков страниц на возможные повреждения, которые не обнаруживаются никакими другими средствами.
Вместо того, чтобы изобретать велосипед, я настоятельно рекомендую вам взглянуть на решение Ola для проверки целостности SQL Server.
Эффективно работает DBCC CHECKDB:
Вам просто нужно проявить творческий подход, когда вы тесно работаете в окне обслуживания, имеющем огромные базы данных или большое количество баз данных для запуска CHECKDB.
После участия в тренинге по SQLSkills я реализовал в своей среде:
DBCC CHECKTABLEвместе с запускомDBCC CHECKALLOCиDBCC CHECKCATALOGDBCC CHECKTABLE,DBCC CHECKALLOCиDBCC CHECKCATALOG. Чтобы вы могли понять, сколько времени обычно уходит на проверку.NOINDEXпараметром, так как он ускорит работу, поскольку он не проверяет некластеризованные индексы в пользовательских таблицах. Это имеет некоторые преимущества, так как не так критично, как повреждение данных, поскольку данные не теряются, и вы можете удалить и заново создать индекс, если это необходимо.Очевидно, что редакция Enterprise может использовать преимущества параллельного выполнения операторов DBCC, но обратите внимание на настройку MAXDOP, так как она может в конечном итоге занять весь ваш ЦП. Это может быть жестко ограничено управляющим ресурсами.
Примечание. Если у вас есть столбец SPARSE, то ваш CHECKDB будет работать очень медленно, как описано здесь .
Наконец, как предотвратить повреждение базы данных, используя весь доступный набор инструментов + вашу веру в аппаратную систему сервера базы данных и, самое главное, ценность ваших данных.
Несколько отличных ссылок:
источник