sql server 2005 Сохранение файла журнала транзакций зеркальной базы данных

Question

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

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

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

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

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

Благодаря

Answer 1

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

B. Настройте план обслуживания (или даже лучше, сценарии T-SQL, такие как Ola Hallengren's at http://ola.hallengren.com), чтобы создать резервную копию всех баз данных, но установите флажки только для резервного копирования онлайн-файлов. (Сверху моей головы, не уверен, что это вариант в 2005 году - может быть, только 2008 год.) Таким образом, вы всегда получите все, что произойдет.

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

Answer 2

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

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