SQL Server 2005, план обслуживания - PullRequest
2 голосов
/ 15 апреля 2009

Мне нужен совет по плану обслуживания SQL Server 2005, вот несколько вопросов:

  1. Какие задачи подходят / подходят для ежедневного обслуживания и что для еженедельного / ежемесячного обслуживания
  2. Требуется ли отключение базы данных во время выполнения какой-либо задачи, например: реорганизация / перестроение индекса, сокращение базы данных и т. Д. (Поскольку нам нужно поддерживать 90% времени безотказной работы)
  3. Сколько времени можно проверить целостность базы данных, реорганизовать / перестроить индекс, очистить историю?
  4. Должны ли мы как реорганизовать, так и перестроить индекс?
  5. Нужно ли обновлять статистику после реорганизации индекса? Поскольку перестроить индекс будет автоматически обновлять статистику

В нашем случае данные вводятся каждую 1 минуту (всего 200 записей в минуту) 24 часа, 7 дней в неделю.

Может кто-нибудь посоветовать мне, какой план обслуживания подходит для этой базы данных?

Спасибо
Dels

Ответы [ 3 ]

1 голос
/ 15 апреля 2009

Два слова: восстановление после стихийного бедствия

Лучший план - это тот, который вы проверили.

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

Лучше всего делать это как с восстановлением O / S, так и с восстановлением сервера SQL.

Также несколько советов: Настройте запланированное задание O / S для создания файловой системы копии базы данных master, model, mssqlsystemresource. Это избавит вас от печали и необходимости запускать сервер SQL в однопользовательском режиме, чтобы попытаться восстановить основную базу данных из резервной копии.

Хорошо, когда есть резервные копии, но если вы никогда не тестируете восстановление, тогда ваши резервные копии бесполезны.

1 голос
/ 15 апреля 2009

Планы обслуживания действительно зависят от процессов вашей базы данных. Поскольку данные вводятся каждую минуту, запущены ли у вас какие-либо процессы свертки и etl?

Самый важный процесс, который я могу вам рассказать, - это ежедневное резервное копирование (и ленты, и диска) ваших данных и журналов транзакций.

Проверьте наличие медленных запросов с помощью анализатора плана запросов, и вам может потребоваться переиндексировать некоторые таблицы ежедневно или еженедельно в зависимости от ваших потребностей. Вы можете выполнить реиндексацию в режиме онлайн в SQL Server 2005 Enterprise Edition, что означает, что вам не нужно быть в автономном режиме.

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

0 голосов
/ 22 ноября 2015

Для поддержания производительности и обеспечения согласованности базы данных, Я обычно запускаю следующие задачи каждую ночь:

1) Резервное копирование базы данных (Обычно это ПОЛНАЯ резервная копия. Однако, если база данных очень большая, ПОЛНАЯ резервная копия запускается один раз в неделю {в выходные дни}, а инкрементная или дифференциальная - каждый день недели)

2) Перестроить все индексы (Это также автоматически реорганизует все индексы, поэтому шаг реорганизации не требуется.)

3) Обновление статистики базы данных (Требуется только статистика по столбцам, поскольку другая статистика автоматически обновляется при перестроении индекса, которое выполнялось ранее)

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

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

6) Очистка файлов (В зависимости от места на диске, вам нужно будет удалить старые резервные копии. Я стараюсь сохранять, по крайней мере, несколько недель, если есть место, но по мере роста базы данных нужно будет проверить это и, возможно, уменьшить его до одного или две полные резервные копии.)

7) История очистки (Журнал журнала плана обслуживания не очень большой, поэтому вы можете хранить его длительную историю, не беспокоясь о слишком большом объеме. Иногда полезно, когда вы сталкиваетесь с базой данных, которая долгое время терпела неудачу, чтобы увидеть, когда она начала отказывать и используйте это, чтобы указать людям, которые контролируют его, что он не был должным образом проверен на успех.)

ПРИМЕЧАНИЯ: Обязательно скопируйте резервные копии с основного сервера базы данных и сохраните их вне сайта.

...