База данных MSSQL2005, зависающая во время обслуживания

В зависимости от того, как создаются Ваши изображения Acronis, я не уверен, что любой вид rsync сохранил бы Вас пропускная способность. Изображения acronis являются единственным файлом (файлами), таким образом, rsync не смог бы читать в них, чтобы только создать резервную копию того, что изменилось. Также не уверенный, какой сервер отображает, Вы создаете, но так как Вы сказали, что 100 ГБ я собираюсь принять полный? Возрастающее изображение сократило бы ночной размер изображения значительно, таким образом сохранив пропускную способность. Вы могли также рассмотреть сохранение образов к альтернативному местоположению, чем S3, таких как ленточный носитель и хранилище что удаленный.

0
задан 13 October 2010 в 18:28
3 ответа

Ответ на мой собственный вопрос:

После выполнения офлайнового chkdsk, только чтобы иметь его повторяются снова неделю спустя, мы диагностировали это как отказ оборудования или низкий уровень проблема ОС, и запросили новый сервер от нашего ISP.

После того, как мы восстановили ту же самую базу данных к нашему новому серверу, она теперь работала безупречно в течение 4 месяцев с единственной разницей, являющейся установка ОС и аппаратные средства. Случай закрывается.

1
ответ дан 4 December 2019 в 12:07

Nicholas обычно прав в этом Вы (всегда существуют исключения), не должны делать, индекс восстанавливает каждую ночь (особенно, если у Вас есть Стандартный выпуск, который не позволит, Вы, чтобы сделать онлайн восстанавливаете).

Вы могли бы хотеть угробить планы технического обслуживания, особенно в отношении индексной дефрагментации, и статистика восстанавливает. Я пошел бы со сценарием, который смотрит на уровень фрагментации Ваших индексов и решает, должен ли он быть восстановлен или нет. У Michelle Ufford (@SQLFool) есть превосходный сценарий, который позволяет Вам иметь ночные задания, которые проверяют уровни фрагментации, и только восстанавливает индекс, которые встречают определенный уровень фрагментации (установленный Вами). Можно найти сценарий здесь: http://sqlfool.com/2010/04/index-defrag-script-v4-0/. Этот сценарий также обновит статистику в случае необходимости. Существует много других сценариев как это там.

HTH, Dan

2
ответ дан 4 December 2019 в 12:07

Это кажется, что могло быть внезапное увеличение роста файлов базы данных? Вы проверили SQL Server Error_Log и просто удивление, можно ли уменьшить журналы до окна обслуживания каждую ночь?

1
ответ дан 4 December 2019 в 12:07
  • 1
    Файл базы данных является 90%-м свободным пространством, и файл журнала уменьшается каждый раз, когда это сохранено (который каждый час является.) +1, потому что автовыращивание действительно вызывало эту проблему однажды. –  realworldcoder 13 October 2010 в 18:41
  • 2
    По-видимому, Вы теперь предварительно выделяете свое пространство на не, полагаются, авторастут. спасибо –  jl. 13 October 2010 в 20:50

Теги

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