План обслуживания сервера Sql - рекомендации по задачам и планированию

Мне поручено разработать план обслуживания для наших баз данных Sql Server 2005. Я знаю, что для резервного копирования я хочу делать ежедневное полное резервное копирование базы данных и резервное копирование журнала транзакций каждые 15 минут. Моя проблема состоит в том, чтобы выяснить, какие другие задачи я хочу выполнять и как часто я должен их выполнять.

Итак, пока я имею это в виду. Поправь меня, если в моем мышлении есть недостатки или есть лучший способ сделать это.

1. Резервное копирование - все таблицы, полное резервное копирование (ежедневно)
2. Резервное копирование - выбранные таблицы, полное резервное копирование (ежечасно)
3. Резервное копирование - Журналы транзакций (каждые 15 минут)
4. Проверка целостности базы данных (ежедневно)
5. Реорганизовать индекс (ежедневно)
6. Обновлять статистику (ежедневно)
7. Сжатие базы данных (еженедельно)
8. Перестроить индекс (еженедельно)
9. Техническое обслуживание (ежедневно)

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

Джош,

Это очень распространенная задача для всех администраторов баз данных, и правильный ответ НЕ одинаков для всех и для каждого сервера. Как много других вещей, это зависит от того, что вам нужно.

Скорее всего, вы не хотите запускать «Сжатие базы данных», как уже предлагалось. Его ЗЛО на производительность и ниже ссылка покажет вам, почему. Это приводит к фрагментации диска и индекса, а также к проблемам с производительностью. Вам лучше предварительно выделить большой размер для файлов данных и журналов, чтобы автострифт НЕ включался.

Я не поняла твой №2. полная таблица выбранных таблиц. Можете ли вы подробнее рассказать об этом?

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

Когда вы перестраиваете индексы, статистика индексов обновляется с помощью fullscan, но если вы обновите статистику после этого, они будут обновлены снова с образцом по умолчанию (который зависит от нескольких факторов, обычно 5% от таблицы, когда размер таблицы> 8 MB), что может привести к проблемам с производительностью. В зависимости от имеющейся у вас версии, вы можете сделать онлайн перестроение индекса. Правильный способ выполнить это действие - проверить степень фрагментации и, в зависимости от этого, либо перестроить индекс, либо перестроить индекс + обновить статистику. А также вы можете определить, какие таблицы должны обновлять статистику чаще, и пытаться обновлять статистику чаще.

Планы техобслуживания в порядке, но с их помощью сложно извлечь максимальную пользу, если вы не можете войти в SSIS и настроить MP. Вот почему я предпочитаю НЕ использовать их и использовать бесплатные скрипты Олы Хелленгрен , которые более надежны, чем MP. Кроме того, я бы порекомендовал ознакомиться с упомянутой статьей Пола Рэндала на эту тему.

Ссылка: http://technet.microsoft.com/en-us/magazine/2008.08.database.aspx

Это НЕ исчерпывающий ответ на ваш вопрос, а хорошая отправная точка. HTH и дайте нам знать, если у вас есть какие-либо дополнительные вопросы / комментарии.

Я поделюсь своим опытом, даже если вы уже приняли ответ. Может быть, это будет полезно :-).

1. Полное ежедневное резервное копирование (ежедневно) - отлично, но не забудьте проверить место и удалить старые файлы по истечении определенного времени.
2. Резервное копирование выбранных таблиц (ежечасно) - не понимаю, зачем вам это нужно, лучше использовать дифференциальное резервное копирование. Как сделать резервную копию только определенных таблиц: SSIS, скрипты, BCP? Что касается разностных резервных копий, не планируйте это слишком часто, так как вы украдете роль резервных копий журнала.
3. Резервное копирование журнала транзакций (каждые 15 минут) - отлично, вы уверены, что вам нужно для всех баз данных? Все базы данных используют модель полного восстановления или нет?
4. Проверьте целостность БД - да, но вам нужно убедиться, что вы не убиваете свою среду. Операторы проверки DBCC довольно эгоистичны в отношении ресурсов и сканируют полные базы данных, поэтому их нужно планировать в нерабочее время.
5. Реорганизовать индекс (ежедневно) - не форсируйте, делайте это только при необходимости. Проверьте индекс DMV на предмет фрагментации и реорганизуйте только на основе потребностей. Я бы переместил все операции с индексами и статистикой для одной еженедельной задачи.
6. Обновлять статистику (ежедневно) - смотрите мой ответ на предыдущий вопрос. Вместо принудительного обновления всей статистики каждый день лучше проверять, когда статистика последний раз обновлялась, и только в некоторых случаях обновлять ее.
7. Сжатие базы данных (еженедельно) - О, нет. Пожалуйста, прочитайте статью Пола Рэндала, касающуюся сжатия файлов.
8. Перестройте индекс (еженедельно) - см. 5.

9. Техническое обслуживание (ежедневно) - хорошо с этим.

10. Вам также лучше добавить задачу для проверки ваших резервных копий - есть версия команды RESTORE (verifyOnly .. если я правильно помню) - скажем, еженедельно, хотя я предпочитаю ее ежедневно.

Вы упомянули, что хотите защитить себя в случае потери данных, поэтому я бы сказал, что вам нужно добавить системные базы данных в эту процедуру обслуживания. А также позаботьтесь о резервном копировании файлов на другом компьютере, чем сам сервер. Сохраните где-нибудь файл с информацией о том, что делать в случае, если вам нужно перестроить master db, msdb..etc. Удачи в вашей задаче!

Поздний ответ, но может быть полезным для других читателей.

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

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

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

Я предлагаю сначала прочитать эту статью: http://www.sqlshack.com/removing-the-risk-from-important-maintenance-tasks-in-sql-server/

Он описывает, как выполнять важные задачи обслуживания в SQL Server - без риска. Например - вы можете встроить простые проверки в ваши задания по обслуживанию, которые проверяют доступные ресурсы, а также то, что операция потребует до выполнения. Это позволяет вам гарантировать, что ваша среда может справиться с тем, что вы собираетесь делать, и прервать работу со значимой ошибкой, если ресурсы недостаточны.

1. Кажется нормально

2. Вы можете извлечь выгоду из создания дифференциальных резервных копий здесь. Посмотрите на них наверняка

3. Кажется нормально

4. Кажется нормально

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

5, 6 и 8: см. Следующее.

Они действительно идут рука об руку, так как индексы опираются на актуальную статистику, и порядок этих операций довольно важен. Базовый метод, который я использую, который, по общему признанию, может не работать для всех, состоит в том, что я выполняю два цикла обслуживания индекса. Сначала я делаю кластеризованные индексы, а затем некластеризованные индексы. Метод, который я использую для обоих, заключается в следующем. Если индекс достаточно большой и достаточно фрагментированный (sys.dm_db_index_physical_stats), я перестрою индекс (который включает обновление статистики с полным сканированием). Если индекс слишком мал для перестроения или недостаточно фрагментирован для перестроения (менее 100 страниц и от 5% до 15% фрагментации), я сначала выполню реорганизацию индекса. Затем я выполню обновление статистики с полной проверкой.

Теперь это касается статистики индексов, но ничего не делает для статистики столбцов. Еженедельно буду обновлять статистику колонки.

Я надеюсь, что это помогло в некотором роде!

Я отклонил ваш комментарий «потеря данных может иметь юридические последствия здесь».

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

Резервное копирование - это одно. Знание того, как использовать их в чрезвычайной ситуации, является другим.

Не забывайте, что если вы собираетесь восстановить резервную копию после серьезного сбоя, вы, вероятно, уже находитесь в состоянии стресса и стресса. Вам не нужно дополнительное бремя выискивания и безупречной записи оператора RESTORE DATABASE с 12 файлами журнала транзакций ... И молитесь, чтобы это вас не подвело ...

На своем рабочем месте я могу восстановить / восстановить базу данных 350 ГБ в любую точку в течение 5 минут за последнюю неделю, используя DPM. С интерфейсом GUI. Стоит того, в моей книге.

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

Наконец, я добавляю свой голос в группу «не сжимайте ваши файлы автоматически, никогда». Сжатие файлов - это лишь инструмент, который время от времени используется, когда происходит нерегулярное событие, которое переросло ваши журналы или файлы БД (бесконечный цикл или что-то подобное). Это не должно быть инструментом обслуживания. Если у вас есть дисковое пространство, сжатие только отсрочит неизбежное.