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

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

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

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

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

38 голосов | спросил Captain Cosmodrome 12 Maypm11 2011, 19:52:18

5 ответов


24

Джош

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

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

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

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

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

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

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

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

ответил Sankar Reddy 12 Maypm11 2011, 20:56:36
18

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

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

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

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

ответил Marian 13 Mayam11 2011, 00:47:39
8

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

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

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

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

Я предлагаю сначала прочитать эту статью:

ответил Alex Kirilov 10 FebruaryEurope/MoscowbWed, 10 Feb 2016 12:35:02 +0300000000pmWed, 10 Feb 2016 12:35:02 +030016 2016, 12:35:02
5
  1. Кажется прекрасным

  2. Здесь вы можете воспользоваться Дифференциальным резервным копированием. Посмотрите на них наверняка.

  3. Кажется прекрасным

  4. Кажется прекрасным

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

5, 6 и 8: см. ниже.

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

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

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

ответил Matt M 12 Maypm11 2011, 22:17:11
1

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

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

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

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

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

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

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

ответил Philippe 21 +04002014-10-21T23:51:47+04:00312014bEurope/MoscowTue, 21 Oct 2014 23:51:47 +0400 2014, 23:51:47

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

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132