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

Question

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

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

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

Кто-нибудь может предложить лучшее решение для этого? Или доставка журналов - единственный оставленный мне вариант?

Это SQL Server 2008 R2 64-разрядная версия DataCenter Edition.

Answer 1

Ваши другие варианты:

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

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

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