Обслуговування баз даних 24x7 - досить велика тема, з якою можна розглянути багато варіантів. Ця широка тема має багато предметів для розгляду, але ми можемо спробувати доторкнутися до деяких найважливіших моментів.
Перше, що ви хочете визначити, - це те, що багато операцій 24x7, як правило, періоди низької активності. Ви можете використовувати ці часи для забезпечення технічного обслуговування, щоб зменшити перешкоди, що виникнуть у базі даних. По-друге, вам потрібно буде зарезервувати деякий час для повного відключення (для таких речей, як пакети послуг або міграції баз даних), тому вам потрібно буде узгодити вікна повного обслуговування з вашим керівництвом. Для конкретних предметів вам потрібно буде розглянути та спланувати кожен, а також належним чином використовувати свої інструменти. Важливим елементом є те, що ви повинні спланувати кожен із них, будь-які приклади, які я надаю, є дуже великими "ваші милі можуть відрізнятися".
Резервні копії
Резервні копії зазвичай не матимуть величезного впливу на навантаження, але їх потрібно враховувати, оскільки вони можуть споживати багато вводу-виводу. Ви хочете запланувати їх відповідно і відстежувати кількість часу, яке потрібно для його виконання. Найбільша перешкода тут полягає в тому, що під час операції 24x7 ви, ймовірно, не зможете проводити повні нічні резервні копії щовечора тижня. Ви хочете запланувати, коли ви можете приймати цілі, коли ви приймаєте різниці, та періоди утримування обох цих у поєднанні з вашими резервними копіями журналу.
Як приклад, я запускаю повні резервні копії всіх моїх баз даних у ніч на неділю (найнижчий рівень активності), різниці в усі інші ночі (понеділок-субота). Я зберігаю останні два тижні повних і різниться на диску, журналах останні два дні. Це дає мені достатню гнучкість для відновлення, але, можливо, мені доведеться відновити резервні копії зі стрічки.
Підтримка індексу / статистики
Це найпоширеніший вид активного обслуговування, з яким вам доведеться мати справу. Ви не можете цього уникнути, але ви можете пом’якшити вплив. Початкове правило полягає в тому, що ви повинні обслуговувати лише ті об'єкти, які потребують цього. Загальні вказівки полягають у відновленні лише індексів, які мають більше 30% фрагментарно та більше 1000 сторінок . Якщо у вас є автоматичне оновлення статистики , це обробляє більшу частину обслуговування статистики, але щонічна робота з синхронізації речей не є поганою ідеєю.
Якщо у вас є Enterprise Edition, ви також маєте доступ до деяких інших варіантів управління технічним обслуговуванням. Найперше - це відновлення індексів в Інтернеті , що дозволить вам перебудовувати індекси, поки вони все ще використовуються (по суті, він будує індекс поруч, а потім замінює його). Ви також можете використовувати розділення для "великих" таблиць, щоб зменшити необхідний час відновлення.
Найкращий варіант для такого типу обслуговування, якщо у вас немає спеціальних сценаріїв, які б обробляли ці найкращі практики, - це використовувати сценарії технічного обслуговування Ola Hallengren . Вони досить прості в налаштуванні та налаштуванні, і в них вбудовано багато цих керівних принципів.
Перевірки послідовності DBCC
Залежно від вашої загальної завантаженості, ви можете виявити, що перевірки DBCC є руйнівними для вашої роботи. Є два загальних способи мінімізувати вплив DBCC для ваших баз даних:
PHYSICAL_ONLY- Запустивши цю опцію, ви перевірите ваші бази даних на фізичному рівні сторінки та уникнете більш інвазивної повної перевірки. Це стосується виявлення найбільш вірогідних видів корупції.- Перевірка відновленої копії - Якщо у вас є простір, ви можете відновити базу даних в іншому екземплярі та запустити перевірку DBCC на відновлену копію. Це розповість ту саму казку про вашу живу базу даних, але ви явно не будете втручатися в діяльність. Деякі інші альтернативи тут запускають DBCC проти відвантаженої копії журналу або дзеркального ДБ.
Ця публікація в блозі надає більш детальну інформацію про ваші варіанти.
Пакетні завдання / ETL
Це дійсно зводиться до того, як ви проектуєте свої процеси. Ваш ETL завжди може втручатися в живі таблиці OLTP (як і будь-яка інша програма), тому слід враховувати деякі клавіші:
- Сплануйте таку роботу навколо вашого іншого обслуговування та в періоди низької активності.
- Правильно розміріть роботу так, щоб вона була досяжна як для продуктивності, так і для того, щоб партія була не настільки великою, що вона блокує ваш стіл годинами. Приклади кінців спектру: рядок рядок-агонізуючий рядок (RBAR) проти одного мільйона рядків видалення.
- Скористайтеся таблицями етапів та в режимі офлайн для обробки даних, де це доречно. Тільки торкайтеся живих матеріалів, коли це абсолютно необхідно.
Висновок
Знову ж таки тут є багато ґрунту, який слід прикрити. Це не всебічний посібник, а огляд деяких підходів на високому рівні. Я навіть не обговорював варіанти з високою доступністю (наприклад, групи доступності та кластерне відключення). Вам потрібно буде переглянути кожен елемент і скласти план, як з ним поводитися. Багато в чому вам також потрібно буде повторити і вдосконалити роботу, рухаючись вперед.
Додаткові ресурси:
Передовий досвід технічного обслуговування VLDB у галузі навичок SQL