Резервні копії журналу транзакцій послідовні чи паралельні?

Ми, звичайно, використовуємо SQL Server 2012 Standard Edition. Мені трапляється також використовувати сценарії Ola Hallengren, щоб забезпечити просту, більш гнучку рамку для створення резервних копій та обслуговування.

Це питання не стільки стосується сценаріїв Оли, скільки про кращу практику. Я усвідомлюю, що остаточна відповідь - це "залежить від вимог вашої компанії". Але я намагаюся шукати поради громади, як найкраще виконати те, що я розумію, щодо вимог нашої компанії.

Я хочу налаштувати резервні копії журналу транзакцій кожні 15 хвилин. Таким чином ми сподіваємось втратити не більше 15 хвилин даних. Чи слід налаштувати одну роботу, яка використовує ALL_DATABASES? або краще налаштувати по одній роботі для кожної бази даних і паралельно розпочати їх? Я запитую, бо у мене є відчуття, що базується на тому, як я бачу функціонування сценарію Оли, що резервні копії починаються серійно. Мінусом серіалу було б те, що кожна послідовна резервна копія чекає, поки інша завершиться. Це може потенційно збільшити кількість часу між резервними копіями (тобто більше 15 хвилин). Плюс моє занепокоєння полягатиме в тому, що збій в одній резервній копії зупиняє інші дії, і я не хотів би, щоб це було так. Я хотів би, щоб інші продовжували створювати резервні копії.

Так це правда, що сценарії Ola виконуються послідовно, а також помилка зупиняє послідовні резервні копії?

І чи краще мати роботу для кожної бази даних? або єдина робота, яка робить все? Моя схильність спрямована до окремих завдань, але я хочу зрозуміти, до чого схильні DBA SQL Server взагалі.

Чи слід налаштувати одну роботу, яка використовує ALL_DATABASES? або краще налаштувати по одній роботі для кожної бази даних і паралельно розпочати їх?

Я б запропонував налаштувати одну роботу, яка б створювала резервну копію журналів транзакцій (послідовно). Це також переконається, що резервне копіювання не сильно використовує введення / виведення, оскільки ви запускаєте резервну копію для бази даних одна за одною.

Які можливі недоліки при паралельному бігу

1. Припустимо, у вас є 50 баз даних, і ви плануєте резервне копіювання журналу транзакцій усіх баз даних, і всі вони починають працювати паралельно. Це, безумовно, буде використовувати багато вводу-виводу. І якщо на диску, на якому він створює резервні копії файлів, трапляються інші файли даних, ви побачите повільність. Я бачив, що резервне копіювання стає повільним, коли поганий запит, що вимагає багато вводу-виводу, працює разом із завданням резервного копіювання.

2. Припустімо, що у вас є 50 баз даних, було б не важко керувати 50 завданнями в агенті SQL Server, і що було б умовою, якщо у вас є 100-200 баз даних, мені просто не сподобається, коли ви відкриєте агент SQL Server і побачите багато роботи, просто так просто. Я впевнений, що з вами був би той самий випадок.

Мінусом серіалу було б те, що кожна послідовна резервна копія чекає, поки інша завершиться. Це може потенційно збільшити кількість часу між резервними копіями (тобто більше 15 хвилин).

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

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

Я б сказав, що не хвилюйся. Резервне копіювання журналу транзакцій просто не може вийти з ладу, якщо ви не помилилися. Помилки можуть бути

1. Власник, який виконує завдання, видаляється з AD

2. Хтось змінив модель відновлення бази даних.

3. Недостатнє місце на диску

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

Взагалі завжди виконуйте резервні копії T-log послідовно; у багатьох моїх примірниках є кілька десятків баз даних і кілька дуже активних, а резервне копіювання журналу транзакцій займає всього кілька секунд; до півхвилини або близько того, коли це особливо зайнято.

Запуск резервного копіювання паралельно тільки справді було б корисно, якщо виконано всі наступні умови:

• Ваші бази даних та файли журналів знаходяться на унікальних незалежних шпинделях (або на твердотільних дисках у будь-якій комбінації)

  • Для резервного копіювання T-журналу для виконання цієї вимоги потрібно було б лише файли журналів.

• Цілі резервного копіювання для кожної бази даних знаходяться на окремих шпинделях.

• Ви не використовуєте спільний SAN HBA або iSCSI або іншу пропускну здатність між екземпляром SQL Server і медіа.

• тобто IOPS для читання бази даних A і створення резервної копії A НЕ використовуйте ті ж диски, що і для читання бази даних B і для створення резервної копії B.

Якщо все це вірно, то можливо, деяка ступінь паралелізму зменшить кількість загального календарного часу. Якщо все це не відповідає дійсності, швидше за все ви змусите один або декілька наборів дисків, і ваші паралельні резервні копії фактично займуть більше календарного часу, ніж серійні, але також можуть спричинити фрагментацію файлової системи ОС або рівня зберігання, оскільки Ви одночасно пишете резервну копію A та резервну копію B!

Не турбуйтеся про те, що одна резервна копія не вдалася, а решта - це успішно - якщо все вийшло з ладу, вам потрібно все-таки перевірити, і єдиний раз, коли я бачив резервні копії, виходив з ладу:

• Поломка диска

• Помилка програмного забезпечення для стиснення Hyperbac / Litespeed / сторонньої сторони (якщо у вас є програмне забезпечення між SQL та диском, який виходить з ладу)

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

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

• Помилка в мережі (якщо файли бази даних або, швидше за все, файли резервної копії, знаходяться в мережі)

• Дозволи

  • найпоширеніший з абсолютно новими встановленнями

  • або абсолютно нові резервні місця

  • зміна користувача сервісу SQL Server (для чого потрібні дозволи для нормальних резервних копій)

  • блокування користувача сервісу SQL Server, оскільки ним використовується більше ніж один екземпляр SQL Server

• Помилки конфігурації

• Відключення живлення

• Збій ОС

Більшість з яких не стосуватиметься одних, а не інших, якщо також не будуть виконані вищезазначені умови.

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