Вы правы. Вы не должны определять какие-либо другие резервные копии журнала транзакций за пределами конфигурации доставки журналов, чтобы обеспечить сохранение естественной последовательности журналов.
Если, однако, вы захотите выполнить резервное копирование журнала для транзакций Ad-Hoc, не дай бог, например, если вы выполняете какое-либо оперативное обслуживание рабочей базы данных, то вы можете вызвать задание SQL Server, которое использует доставка журналов, чтобы выполнить журнал транзакций. резервное копирование. Обычно это называется LS_Backup. Это будет поддерживать LSN.
Насколько я понимаю, ни одна из функциональных возможностей базы данных, поставляемой в журнале, не ограничена с помощью этой технологии доступности.
Некоторые вещи, которые могут вызвать осложнения:
Шифрование
Если вы отправляете журнал на другой сервер и используете встроенное шифрование SQL Server, то вы не сможете получить доступ к зашифрованным данным в базе данных, поставляемой журналом, если SQL Server не использует тот же главный ключ службы.
Сборки
Вы можете столкнуться с трудностями при доступе к подписанным сборкам в базе данных с доставкой журналов, так как вы не можете включить доверенное свойство.
Права доступа
Если вы намереваетесь предоставить доступ для чтения к базе данных Log Shipped, то для входа в систему SQL Server должен быть тот же SID, что и для исходного сервера, чтобы имена входа автоматически отображались правильно.
Надеюсь, это поможет. Приветствия.