У нас есть несколько серверов SQL 2000, 2005 и 2008, и мы всегда запускаем DBCC CHECKDB каждую ночь непосредственно перед полным резервным копированием, исходя из теории, что вы хотите убедиться, что БД находится в хорошем состоянии, прежде чем создавать резервную копию. . (Очевидно, что полную проверку резервных копий можно выполнить только с помощью тестового восстановления, но это немного другая тема.)
Предполагая, что я не могу выгрузить DBCC на сервер резервного копирования или что-то в этом роде (что было бы идеально), является ли DBCC CHECKDB, за которым следует FULL BACKUP, лучшей последовательностью?
Единственный документ "передовой практики", который я нашел, обсуждая это, был Лучшие практики обслуживания SQL Server для SAP с 2006 года я нашел в TechNet:
В идеале перед выполнением резервного копирования базы данных в оперативном режиме следует выполнить проверку согласованности с помощью DBCC CHECKDB.
Это правильный совет? Это правильно для всех версий SQL?
(В случае, если это помогает, часть мотивации спросить об этом заключается в том, что среда выполнения DBCC, кажется, довольно сильно варьируется от ночи к ночи, поэтому мы не можем точно рассчитывать, когда будет завершено резервное копирование, что делает планирование нашего ленточного архива задания трудны. Кроме того, если обслуживание длится долго и его нужно отменить по какой-либо причине, я бы предпочел, чтобы резервная копия была надежно завершена, чем DBCC.)
Еще одна вещь, которую вы могли бы рассмотреть, это то, что если у вас есть другой сервер (Dev или другой), который вы можете использовать для тестирования восстановления файлов резервных копий, вы можете сделать это там. Итак, ВОССТАНОВИТЕ БАЗУ ДАННЫХ, а затем DBCC CHECKDB. Таким образом, вы не только проверяете исправность файлов резервных копий, но и проверяете исправность баз данных, не влияя на производство.
Мы еженедельно тестируем восстановление всех наших резервных копий на другой сервер, а затем запускаем на них CHECKDB.
Вот мое мнение ...
С точки зрения возможности восстановления не имеет значения, когда именно вы запускаете CHECKDB, но это МОЖЕТ повысить вашу уверенность в том, является ли ваша резервная копия хорошей или нет.
Скажем, ваша база данных повреждена.
Когда ваша предварительная резервная копия DBCC CHECKDB выйдет из строя, вы поймете, что последующая резервная копия, возможно, не годится.
Запустив сначала резервное копирование, а затем CHECKDB, вы будете ОЧЕНЬ немного менее уверены в том, хорошая или плохая у вас резервная копия (есть вероятность, что повреждение могло произойти между резервным копированием и CHECKDB). Для тебя это важно?
Я бы сказал, что пока вы запускаете CHECKDB регулярно, не имеет значения, когда именно. И, как вы упомянули, нет замены регулярному тестированию восстановления.
Если вы не можете разместить полную DBCC CHECKDB в окне обслуживания, вы можете добавить С контрольной суммой в свои процедуры резервного копирования и выполняйте полные CHECKDB в другое время (SQL 2005 и новее).
Обратите внимание, что BACKUP [...] WITH CHECKSUM не заменяет DBCC CHECKDB. Пол Рэндал имеет более подробную информацию Вот.
Также было бы полезно понять, какова ваша стратегия восстановления, если / когда вы обнаружите, что данные повреждены. Если вы намереваетесь восстановить до точки отказа, то запуск checkdb перед резервным копированием может сэкономить ваше время и сэкономить потерянные данные.