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

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

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

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

Спасибо,
Dels

2
Dels 15 Апр 2009 в 07:38

3 ответа

Лучший ответ

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

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

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

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

1
Srikar Doddi 15 Апр 2009 в 17:42
Надеюсь, вы ответите по пунктам, но спасибо, что указали на важные вещи. кстати, я скорее путаю с вашим утверждением: «В SQL Server 2005 Enterprise Edition можно выполнять повторную индексацию в режиме онлайн, что означает, что вам действительно нужно быть в автономном режиме», он может быть в сети, но мне нужно быть в автономном режиме?
 – 
Dels
15 Апр 2009 в 08:37
Привет, Дельс, я внес поправку. "вам не нужно, чтобы ваша система была оффлайн"
 – 
Srikar Doddi
15 Апр 2009 в 17:43

Два слова: аварийное восстановление

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

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

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

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

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

1
Wayne 15 Апр 2009 в 10:13
Да, у меня есть аварийное восстановление, я использую реплицированные транзакции с двумя целевыми базами данных и регулярное полное резервное копирование каждую полночь (ежедневно), я тестировал, как я могу восстановиться после ошибки данных, мне нужно знать об обслуживании базы данных
 – 
Dels
15 Апр 2009 в 12:12

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

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

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

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

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

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

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

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

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

0
Don 22 Ноя 2015 в 20:49