Вопросы Теги

Я должен выполнить DBCC checkdb перед полным резервным копированием? Или после?

не прямой ответ, но если у Вас есть php [или другая сторона сервера, включает сценарии] установленный - можно использовать:

ErrorDocument 403 /404.php

и в 404.php имейте:

<?php
  header("HTTP/1.0 404 Not Found");
  //...
5
задан 5 October 2010 в 23:15
4 ответа

Другая вещь, которую Вы могли бы рассмотреть, состоит в том, если у Вас есть другой сервер (Dev или иначе), что можно использовать для тестирования, восстанавливают файлы резервных копий, Вы могли бы хотеть сделать это на там. Так ВОССТАНАВЛИВАЮТ БАЗУ ДАННЫХ и затем DBCC CHECKDB. Тот путь, мало того, что Вы проверяете это Ваши файлы резервных копий, хорош, но Вы проверяете базы данных, хороши, не влияя на производство.

Мы тестируем, восстанавливают все наши резервные копии еженедельно на другой сервер и затем выполняют CHECKDB на них.

3
ответ дан 3 December 2019 в 01:34
  • 1
    Потрясающая идея и та, которую самостоятельно рекомендует @PaulRandal. В моем случае, тем не менее, не действительно практичном для тысяч баз данных через сотни серверов. –  BradC 6 October 2010 в 01:52
  • 2
    , я предполагаю, что это сделало бы вещи немного более трудными. В этом случае я согласился бы с Simon выше, пока Ваш делают регулярно планируемое обслуживание CHECKDB, необходимо быть в порядке. Если бы все Ваши базы данных являются достаточно маленькими для помещений в в CHECKDB, вовремя мудрый перед РЕЗЕРВНЫМ КОПИРОВАНИЕМ, которое было бы идеально, но на основе того, что Вы описали, это, вероятно, не разумно. –  SQL3D 6 October 2010 в 02:22

Вот мое взятие...

С точки зрения восстанавливаемости не имеет значения точно, когда Вы выполняете CHECKDB, но МОГЛО БЫ помочь Вашей уверенности о том, хорошо ли Ваше резервное копирование или нет.

Скажите, что Ваша база данных становится поврежденной.

Когда Ваш предрезервный DBCC CHECKDB перестал работать, Вы знали бы, что Ваше последующее резервное копирование возможно бесполезно.

Выполняя резервное копирование сначала, CHECKDB после, Вы были бы ОЧЕНЬ немного менее уверены, было ли у Вас хорошее или плохое резервное копирование (существует возможность, повреждение, возможно, произошло между резервным копированием и CHECKDB). Это имеет значение для Вас?

Я сказал бы, пока Вы регулярно выполняете CHECKDB, он не имеет значения точно когда. И поскольку Вы упомянули, что нет никакого substitue для того, чтобы регулярно тестировать восстановления.

2
ответ дан 3 December 2019 в 01:34

Если Вы не можете приспособить полный DBCC CHECKDB в окне обслуживания, можно добавить С КОНТРОЛЬНОЙ СУММОЙ к резервным стандартным программам и сделать полный CHECKDB's в другое время (SQL 2005 и позже).

Обратите внимание, что РЕЗЕРВНОЕ КОПИРОВАНИЕ [...] С КОНТРОЛЬНОЙ СУММОЙ не заменяет DBCC CHECKDB. У Paul Randal есть больше деталей здесь.

1
ответ дан 3 December 2019 в 01:34

Также было бы полезно понять то, чем состоит в том Ваша стратегия восстановления, если/когда Вы решаете, что у Вас есть повреждение данных. Если Вы намереваетесь восстановить к точке отказа, затем работающего checkdb до резервного копирования, может сэкономить Вам время и потерянные данные.

0
ответ дан 3 December 2019 в 01:34
  • 1
    справки я предполагаю, что это зависит от типа проблемы, найденной CheckDB, где угодно от быстрого ВОССТАНОВЛЕНИЯ до восстановления от резервного копирования. Большая часть производства DBS находится В полном ВОССТАНОВЛЕНИИ, таким образом применяя tran резервные копии журнала, находится на таблице также. –  BradC 6 October 2010 в 01:02

Теги

Похожие вопросы