Зависание базы данных MSSQL2005 при обслуживании
Наш сервер баз данных имеет план обслуживания, который выполняется каждую ночь:
- Резервное копирование баз данных и журналов (максимум 10-20 ГБ)
- Check Database Integrity
- Восстановить индексы
- Обновить статистику
Обычно все это выполняется менее чем за минуту для каждой базы данных. Однако за последний месяц было два случая, когда база данных просто замораживалась на 3 часа. Выполнение инструкции DBCC заняло 2 часа, но завершилось без ошибок. Все это время наша база данных отклоняла соединения.
Помимо этих двух отдельных инцидентов, эта база данных никогда не давала ни одной проблемы.
Кто-нибудь может подсказать, что может вызвать такую проблему?
3 ответа
Отвечая на мой собственный вопрос:
После запуска автономного chkdsk, чтобы через неделю он снова повторился, мы диагностировали это как аппаратный сбой или проблему с ОС низкого уровня и запросили новый сервер у нашего интернет-провайдера.
После того, как мы восстановили ту же самую базу данных на нашем новом сервере, она теперь работает безупречно в течение 4 месяцев, с той лишь разницей, что установка оборудования и ОС. Дело закрыто.
Николас прав в том, что вам обычно (всегда есть исключения) не нужно перестраивать индексы каждую ночь (особенно если у вас есть стандартная версия, которая не позволяет вам перестраивать онлайн).
Возможно, вы захотите отказаться от планов обслуживания, особенно в отношении дефрагментации индекса и перестроения статистики. Я хотел бы пойти со сценарием, который смотрит на уровень фрагментации ваших индексов и решает, должен ли он быть перестроен или нет. Мишель Аффорд (@SQLFool) имеет отличный сценарий, который позволяет вам выполнять ночные задания, проверяющие уровни фрагментации, и перестраивать только те индексы, которые соответствуют определенному уровню фрагментации (установленному вами). Вы можете найти сценарий здесь: http://sqlfool.com/2010/04/index-defrag-script-v4-0/. Этот скрипт также обновит статистику при необходимости. Есть много других подобных сценариев.
HTH, Дэн
Похоже, это может быть внезапное увеличение роста файлов базы данных? Вы проверили SQL Server Error_Log и просто задаетесь вопросом, можете ли вы каждый вечер сокращать журналы перед окном обслуживания?