Миф: Несколько зеркал и задержка применения журналов при доставке журналов

Автор: Paul Randal, A SQL Server DBA myth a day: (7/30) multiple mirrors and log shipping load delays

У базы данных может быть несколько зеркал

ЛОЖЬ

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

Ещё одна классная особенность доставки журналов заключается в том, что для одного из вторичных серверов можно установить задержку применения, скажем, в 8 часов. Это означает, что резервные копии журналов, сделанные на основном сервере (не правда ли забавно, что в разных технологиях используется разная терминология:

• зеркалирование баз данных: основной — зеркальный
• доставка журналов: основной — вторичный
• репликация: издатель — подписчик

Ладно… эта вводная часть как-то сама по себе развилась…) не будут восстановлены на вторичном сервере доставки журналов, пока не пройдёт 8 часов. Если кто-то удалит таблицу в рабочей среде, она почти сразу же исчезнет и в зеркале (с какой-то задержкой, зависящей от состояния очередей SEND и WAIT в тот момент — но вы не можете остановить этот процесс), а вот на вторичном сервере доставки журналов с задержкой применения таблица останется нетронутой.

Кстати, команда SQLCAT написала очень хорошую статью, разоблачающую миф (который происходит из документации Books Online) о том, что можно зеркалировать только 10 баз данных на один экземпляр — см. Mirroring a Large Number of Databases in a Single SQL Server Instance. Также взгляните на статью базы знаний, которую я написал для CSS, где обсуждается то же самое: KB 2001270 Предварительные условия, ограничения и рекомендации по зеркальному отображению базы данных.