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

Мы используем SQL Server 2012 Standard Edition. Мне также довелось использовать сценарии Олы Хелленгрен, чтобы обеспечить более простую и гибкую среду для резервного копирования и обслуживания.

Этот вопрос не столько о сценариях Олы, сколько о лучшей практике. Я понимаю, что окончательный ответ «это зависит от требований вашей компании». Но я пытаюсь получить совет сообщества о том, как лучше всего выполнить требования нашей компании, которые я понимаю.

Я хочу настроить резервное копирование журнала транзакций каждые 15 минут. Таким образом, мы надеемся потерять не более 15 минут данных. Должен ли я создать одну работу, которая использует ALL_DATABASES? или лучше настроить одну работу для каждой базы данных и запустить их все параллельно? Я спрашиваю, потому что у меня есть чувство, основанное на том, как я вижу функционирование сценария Олы, что резервные копии запускаются в сериале. Недостатком последовательного интерфейса является то, что каждое последующее резервное копирование ожидает завершения другого. Это может потенциально увеличить количество времени между резервными копиями (то есть, больше чем 15 минут). Кроме того, я обеспокоен тем, что сбой в одной резервной копии не позволяет другим произойти, и я бы не хотел, чтобы это имело место. Я хотел бы, чтобы другие продолжали резервное копирование.

Так правда ли, что скрипты Олы выполняются последовательно, а также сбой останавливает последующие резервные копии?

И лучше ли иметь работу для каждой базы данных? или одна работа, которая делает все? Я склоняюсь к отдельным работам, но я хочу понять, что обычно делают администраторы баз данных SQL Server.

Должен ли я создать одну работу, которая использует ALL_DATABASES? или лучше настроить одну работу для каждой базы данных и запустить их все параллельно?

Я бы предложил настроить одну работу, которая будет создавать резервные копии журналов транзакций (поочередно). Это также гарантирует, что резервное копирование не будет интенсивно использовать ввод-вывод, потому что вы выполняете резервное копирование для базы данных по одному.

Какие могут быть возможные недостатки при параллельной работе

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

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

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

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

Кроме того, я обеспокоен тем, что сбой в одной резервной копии не позволяет другим произойти, и я бы не хотел, чтобы это имело место.

Я бы сказал, просто не беспокойся об этом. Резервные копии журнала транзакций просто не могут завершиться ошибкой, если вы не допустили ошибку. Ошибки могут быть

1. Владелец, выполняющий задание, удален из AD

2. Кто-то изменил модель восстановления базы данных.

3. Недостаточно места на диске

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

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

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

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

  • Только для резервных копий T-log, только файлы журналов должны были бы выполнить это требование.

• Ваши цели резервного копирования для каждой базы данных находятся на отдельных шпинделях.

• Вы не используете совместно используемый SAN HBA или iSCSI или другую полосу пропускания между экземпляром SQL Server и носителем.

• т. е. операции ввода-вывода при чтении базы данных A и записи резервной копии A НЕ используют те же диски, что и при чтении базы данных B и записи резервной копии B.

Если все это верно, то возможно, что некоторая степень параллелизма уменьшит количество общего календарного времени. Если все это не соответствует действительности, скорее всего вы вызовете сбой одного или нескольких наборов дисков, и ваши параллельные резервные копии на самом деле будут занимать больше календарного времени, чем последовательные, но также могут привести к фрагментации файловой системы ОС или уровня хранения, поскольку вы пишете резервные копии A и Backup B одновременно!

Не беспокойтесь о том, что одно резервное копирование завершится с ошибкой, а остальные - успешно. Если произойдет сбой, вам все равно нужно проверить все, и единственные случаи, когда я видел сбой резервного копирования, связаны с:

• Сбой диска

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

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

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

• Сбой сети (если файлы базы данных или, скорее всего, файлы резервных копий находятся в сети)

• права доступа

  • чаще всего встречается с новыми установками

  • или новые резервные копии

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

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

• Ошибки конфигурации

• Сбой питания

• Сбой ОС

Большинство из которых не повлияет ни на одно, ни на другое, если не будут выполнены вышеуказанные условия.

Просто добавим, что Ола разрабатывает свои сценарии, в которых, если по какой-либо причине резервное копирование одной резервной копии базы данных не удается выполнить, предпринимаются следующие попытки. Как указывалось ранее, вы можете настроить оповещение, сообщающее вам о сбое задания, поскольку задание резервного копирования все равно не будет выполнено, даже если из всех пользовательских баз данных произойдет сбой только одной резервной копии базы данных - при условии, что вы выполняете резервное копирование всех баз данных (одного работа для всех).