План обслуговування сервера Sql - кращі практики щодо завдань та планування

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

Отже, поки що я це маю на увазі. Виправте мене, якщо є якісь недоліки в моєму мисленні або кращий спосіб зробити це.

1. Резервне копіювання - усі таблиці, повне резервне копіювання (щодня)
2. Резервне копіювання - Вибрані таблиці, Повне резервне копіювання (щогодини)
3. Резервне копіювання - журнали транзакцій (кожні 15 хвилин)
4. Перевірка цілісності бази даних (щодня)
5. Реорганізувати індекс (щодня)
6. Оновлення статистики (щодня)
7. Зменшення бази даних (щотижня)
8. Індекс відновлення (щотижня)
9. Прибирання з обслуговування (щодня)

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

Джош,

Це дуже поширене завдання для всіх DBA, і правильна відповідь НЕ однакова для кожного та кожного сервера. Як і багато іншого, це залежить від того, що вам потрібно.

Напевно, ви не хочете запускати "Зменшувати базу даних", як уже було запропоновано. Його ЗЛИВ для продуктивності та нижче наведений перелік покаже вам, чому. Це спричиняє фрагментацію диска, а також індексу, і це може призвести до проблем з продуктивністю. Вам краще заздалегідь виділити великий розмір для файлів даних і журналів, щоб автоматичний ріст НЕ почався.

Я не зрозумів вашого №2. повна резервна копія вибраних таблиць. Чи можете ви детальніше зупинитися на цьому?

Приступаючи до реорганізації індексу, оновлення статистики та відновлення індексу, вам слід бути обережними, як це зробити, інакше ви все ще використаєте більше ресурсів, а також виникнете проблеми з продуктивністю.

Після відновлення індексів статистика індексів оновлюється за допомогою повного скану, але якщо ви оновлюєте статистику після цього, то вони знову оновлюватимуться зразком за замовчуванням (що залежить від декількох факторів, як правило, 5% таблиці, коли розмір таблиці> 8 МБ), що може призвести до проблем з продуктивністю. Залежно від видання, яке ви маєте, ви можете зробити перебудову в Інтернеті через Інтернет. Правильний спосіб здійснення цієї діяльності - перевірити кількість фрагментації та залежно від того, чи потрібно відбудовувати індекс, чи реорганізувати індекс + оновити статистику. А також ви можете визначити, які таблиці потрібно частіше оновлювати статистику та намагатися частіше оновлювати статистику.

Плани технічного обслуговування в порядку, але важко отримати найкраще з них, роблячи ці налаштування, якщо ви не зможете увійти в SSIS і налаштувати MP. тому я вважаю за краще НЕ використовувати їх і використовувати безкоштовні сценарії Ola Hallengren, які є більш надійними, ніж представники MP. Також я б рекомендував перейняти посилання на цю тему в статті Пола Рандала.

Довідка: http://technet.microsoft.com/en-us/magazine/2008.08.database.aspx

Це НЕ вичерпна відповідь на ваше запитання, а хороша відправна точка. HTH та повідомте нас, якщо у вас є додаткові запитання / коментарі.

Я поділюсь своїм досвідом, навіть якщо ви вже прийняли відповідь. Можливо, це буде корисно :-).

1. Повне щоденне резервне копіювання (щодня) - чудово, але не забудьте перевірити місце та видалити старі файли через деякий заздалегідь визначений час.
2. Резервне копіювання вибраних таблиць (щогодини) - не розумієте, для чого вам це знадобиться, краще перейдіть до диференціальних резервних копій. Як робити резервну копію лише певних таблиць: SSIS, скриптів, bcp? Щодо різних резервних копій, не плануйте це занадто часто, оскільки ви вкрадете роль резервного копіювання журналу.
3. Резервне копіювання журналу транзакцій (кожні 15 хвилин) - чудово, ви впевнені, що вам потрібно для всіх баз даних? Чи всі бази даних використовують повну модель відновлення чи ні?
4. Перевірте цілісність db - так, але вам потрібно переконатися, що ви не вб'єте оточення. Виписки перевірки DBCC є досить корисливими щодо ресурсів і сканують повний dbs, тому їх потрібно планувати в неробочий час.
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 файлами журналу транзакцій ... І молитися, щоб він не підвів вас ...

На своєму робочому місці я можу відновити / відновити базу даних 350Gb до будь-якої точки протягом 5 хвилин протягом останнього тижня за допомогою DPM. З інтерфейсом GUI. Варто, в моїй книзі.

Для решти обов’язково загляньте в індексний сценарій Ола Галленгрена та налаштуйте параметри під свої потреби. Персонально я поєднав його із запланованим завданням, яке змушує його працювати щогодини на годину без сканування, тому він обробляє найгірші індекси кожного разу і примушує повний перегляд фрагментації кожну суботу або коли всі індекси у списку були дефрагментовані.

Нарешті, я додаю свій голос до групи "не скорочуй свої файли автоматично, ніколи". Зменшення файлів - це лише інструмент для спорадичного використання, коли трапляються нерегулярні події, які переростають ваші журнали чи файли БД (нескінченний цикл чи подібний). Це не повинен бути інструментом технічного обслуговування. Якщо у вас є тиск у просторі на диску, скорочення лише затримає неминуче.