Ограничения для базы данных Log Shipped

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

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

Я также понял, что с Truncate Table все в порядке с доставкой журналов (начиная с Sql 2000).

Есть ли другие действия / команды, которых следует избегать?

редактировать: например, база данных сокращается или журнал сокращается нормально?

7.05.2009 10:53:23
2 ОТВЕТА
РЕШЕНИЕ

Ты прав. Вы не должны определять какие-либо другие резервные копии журнала транзакций за пределами конфигурации доставки журналов, чтобы обеспечить поддержание естественной последовательности журналов.

Однако, если вы захотите выполнить резервное копирование журнала для транзакций Ad-Hoc, не дай бог, например, если вы выполняете некоторое оперативное обслуживание рабочей базы данных, то вы можете вызвать задание SQL Server, которое использует доставка журналов для выполнения резервного копирования журнала транзакций. Обычно он называется LS_Backup. Это будет поддерживать LSN.

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

Некоторые вещи, которые могут вызвать осложнения:

шифрование

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

сборки

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

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

Если вы намереваетесь предоставить доступ для чтения к базе данных Log Shipped, то имена входа SQL Server должны иметь тот же SID, что и идентификаторы с исходного сервера, чтобы имена входа автоматически отображались правильно.

Надеюсь это поможет. Приветствия.

6
7.05.2009 11:34:15

Рост / сжатие базы данных / журналов в порядке, они будут отправлены, а резерв будет также расти / уменьшаться. Единственное, что я знаю о том, что сломает вещи:

РЕЗЕРВНЫЙ ЛОГ С TRUNCATE_ONLY

Смена режима восстановления

Перевод основной базы данных в автономный режим (не уверен в этом, никогда не пробовал)

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

2
19.05.2009 17:58:53
Хорошо, вы правы, слава богу, что усечение журнала больше не разрешено на SQL 2008.
Gabriel Guimarães 9.11.2010 16:10:07