Обслуживание файла журнала транзакций зеркальной базы данных SQL Server 2005

Question

Хорошо, поэтому для стандартных баз данных без зеркального отображения журнал транзакций контролируется либо с помощью простой базы данных, либо путем регулярного резервного копирования.Мы сохраняем нашу простоту, поскольку у нас есть резервные копии моментальных снимков SAN, и нет необходимости в резервных копиях SQL.

Теперь мы перейдем к зеркалированию.У меня явно больше нет выбора простого режима и я должен использовать полный режим.это, очевидно, приводит к большим файлам журнала и необходимости резервного копирования журнала.Хорошо, я могу с этим справиться;план обслуживания, который берет резервную копию журнала и удаляет все предыдущие.Я понимаю, что это резервное копирование по существу бесполезно без его предшественников, но снимки SAN делают резервные копии.

Мой вопрос ...

a) Есть ли способ обрезать файл журналавсе обработанные строки без создания резервной копии?(поскольку я все равно не могу их использовать ...)

b) План обслуживания является локальным для сервера и не реплицируется по зеркальной паре.Как это сделать на зеркальной установке?такой, что при сбое базы данных план начинает работать с новым принципалом, но не расстраивается, когда это зеркало?

Спасибо

Answer 1

A. Если ваш сервер достаточно важен для его зеркалирования, почему он недостаточно важен для резервного копирования журнала транзакций? Снимки SAN представляют собой изображения на определенный момент времени только одного момента времени, но они не дают вам возможности останавливаться в разные моменты времени по пути. Когда ваши разработчики усекают таблицу, вы хотите воспроизвести все журналы вплоть до этого оператора и на этом остановиться. Вот для чего хороши резервные копии журналов транзакций.

B. Установите план обслуживания (или, что еще лучше, сценарии T-SQL, такие как сценарий Олы Хелленгрен на http://ola.hallengren.com), для резервного копирования всех баз данных, но установите флажки только для резервного копирования онлайн. голова, не уверен, что это вариант в 2005 году - может быть, только в 2008 году. Таким образом, вы всегда будете получать все, что произойдет при сбое.

Конечно, имейте в виду, что вам нужно быть осторожным с такими вещами, как сценарии очистки и копирование этих файлов резервных копий. Если у вас есть половина резервных копий t-log на одном ресурсе, а половина на другом, восстановить сложнее.

Answer 2

а) нет, вы не можете обрезать журнал, который является частью зеркальной базы данных.резервное копирование журналов является вашим лучшим вариантом.У меня есть несколько баз данных, которые настроены с зеркалированием просто на основе потребностей HA, но DR не требуется по разным причинам.Это похоже на твою ситуацию?Я действительно рекомендую хранить резервные копии журналов в течение некоторого времени.Нет причин убивать совершенно хороший план восстановления, добавленный вашей стратегией высокой доступности.:)

b) Мои собственные решения для этого состоят в том, чтобы иметь задание дополнительного агента, которое отслеживает на основе состояния зеркала.Если обнаружено, что зеркало изменяется, вторичное задание на экземпляре зеркала включено и, если возможно, старый участник отключается.если основной абонент не работает и он возвращается, задание все еще отключено.единственный способ, которым сами задания будут переключены обратно, - это случай повторного аварийного переключения.