Які плюси та мінуси сценаріїв Ola та використання плану обслуговування?

9

Чи допоможете мені, будь ласка, зрозуміти плюси та мінуси використання рішення Ola щодо плану технічного обслуговування? Я підготував презентацію на основі SQL Pass ( http://www.pass.org/DownloadFile.aspx?File=ebae1b31 ), яку я презентую.

Я також готую декілька сценаріїв, у яких рішення Ola та рішення плану технічного обслуговування не відповідають. Чи можете ви всі допомогти мені пояснити це технічно?

До речі, ми управляємо майже 150+ серверами (суміш 2008/2012/2014/2016) з рішенням Ola принаймні 75% з них. Мені сподобалась ця стаття Брента Озара. Але в одному з коментарів, Brent рекомендував використовувати рішення на основі скриптів для кількості серверів, які ми маємо. https://www.brentozar.com/archive/2012/04/maintenance-plans-roombas-suck-good-way/

sql-server ola-hallengren

— Пат
джерело

Ми говоримо про резервне копіювання, обслуговування індексів / статистичних даних, перевірку корупції чи все вищезазначене?

— nkdbajoe

Усі. Весь сценарій рішення технічного обслуговування від Ola. Я вирішив проблеми непотрібних перебудов індексів та оновлень статистики в плані технічного обслуговування, використовуючи сценарії Ola. Я просто хотів ще трохи технічного патрона від інших DBA. Дякую.

— Пт

2

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

— цзяо

Чи є у вас дані, які свідчать про те, що вони кращі чи ви просто йдете з тим, що вважаєте, що краще? Найкращий спосіб вирішити проблему - це отримати деякі дані про ефективність, щоб показати, чому метод кращий

— Jo W

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

— Ален

13

Я тут написав

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

Щоб додати більше,

Рішення з технічного обслуговування Ola широко прийнято в громаді та великих організаціях .
Його відкриті джерела та проблеми можуть бути порушені на github / проблемах, ймовірно, що це буде дуже швидко виправлено.
Його гнучка та масштабована (навіть якщо ви хочете розгорнути її на 100 серверах, просто використовуйте Install-DbaMainnanceSolution від dbatools.)
Microsoft потребувала майже десятиліття, щоб виправити графічний інтерфейс плану технічного обслуговування, який сам баггі :-)
має велику документацію та поширені запитання та постійно оновлюється, щоб вмістити новіші версії сервера sql.
у попередній версії ви навіть можете паралельно запускати резервні копії.
для рішення технічного обслуговування індексу ви навіть можете провести час, наприклад, якщо він працює більше X часу, перервіть його.

— Кін Шах
джерело

5

Однією з головних переваг рішення на основі скрипту є простота розгортання - те, що явно актуально у вашому випадку, оскільки у вас є 150+ серверів. Спроба розгорнути кілька планів технічного обслуговування (тобто як мінімум 2, один для системних баз даних і один для баз даних користувачів) на 150 серверах було б кошмаром. Підтримати їх один раз на місці - це стільки ж клопоту.

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

У нашому випадку у нас у середовищі DEV є близько 40 екземплярів SQL, і ми використовуємо модифіковані сценарії Ola з функцією багаторазового підключення SSMS, щоб мати змогу в один клік розгортати зміни в режимі обслуговування всіх 40 екземплярів. Будь-які спеціальні випадки обробляються нашими модифікаціями.

— Майк
джерело

3

Я не на 100% впевнений у його сценаріях, але спеціальні сценарії набагато кращі, ніж плани обслуговування. Вбудовані плани планують відновити кожен індекс на столі, незалежно від того, наскільки мало фрагментації. Якщо у вас завжди буде, це створить бурю трафіку.

Спеціальні сценарії ви можете відновити що-небудь понад 20% або будь-який ваш поріг. Менше індексів, перебудованих за один раз. Менш завжди на даних для надсилання у вторинники. Швидше відбудуйте, оскільки ви відновлюєте менше індексів. Потрібно коротше вікно обслуговування.

Минулого разу, коли я використовував плани технічного обслуговування, у мене була таблиця рядків на 300 мільйонів, і Always On буде відставати на години, коли розпочалося відновлення індексу та проблеми із журналом транзакцій. Повернувся до сценаріїв, і все пішло.

— Ален
джерело

1

Спочатку я писав власну для SQL 2005 ще близько 2007 року. Я використав те, що книги в мережі були основою, і трохи змінив її. Тоді здавалося, що більшість людей користуються планами, а зараз, здається, вона змінилася. І до того, як я почав займатися DBA, попередній DBA до мене мав спеціальні сценарії для SQL 2000. Єдине, що я по-іншому, це було, що я відновлював все. Швидше було відновити що-небудь понад 20% чи 30%, ніж реорганізувати також. Для резервного копіювання ми завжди використовували сторонні продукти

— Ален

1

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

— SQLDBAWithABeard
джерело

0

Плани технічного обслуговування будуть справляти чудово більшу частину часу. Сценарії Оли Галленгрена будуть справляти чудово більшу частину часу.

У дуже рідкісних випадках, можливо, вам доведеться виростити свій власний.

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

Якщо він проводив базу даних протягом 20 років, він вже написав власні сценарії обслуговування. Приблизно в той час, коли ви навчилися їздити, мабуть, був якийсь молодий панк у вантажних шортах та нальотах, який прийшов, і все було на кшталт "ей, ти, старий синдром, плани на технічне обслуговування краще - і натягни штани, ти виглядаєш смішно! ".

Тоді, мабуть, відбувся 4-річний бій, коли підліток з роздвоєними силами ковзав у плані технічного обслуговування, коли тільки міг. Тепер цей інший молодий панк із худими джинсами та чудовиськом бабочки говорить про те, щоб повернутися до сценаріїв. Досить посивити волосся.

Три речі, які слід врахувати:

Чи реально застосовані ці приклади переваги галангренітів у вашому оточенні?

Чи це створить у вас справжню проблему, якщо він використовує плани технічного обслуговування?

Якщо ви переконаєте його у використанні сценаріїв Галленгрена, і виникла проблема, чи зможе він сам це вирішити чи доведеться зателефонувати вам?

— Джеймс
джерело

Відповідь на перші два питання Так. Ми вже бачили проблеми з Планами технічного обслуговування, і я вирішив проблеми з рішенням Ola. На виробничому сервері була задача скорочення журналу (??), яку я негайно відключив. Третє питання, я не знаю. Я не впевнений, чи зможе він вирішити проблеми, створені самим планом технічного обслуговування. Коли я запитав його, якщо ми бачимо проблеми з ним, що нам робити? Його відповідь полягала в тому, щоб викликати службу підтримки Microsoft. (??)

— Пат

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

— Джеймс