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