Насколько надежна репликация SQL-сервера?

Question

У нас есть база данных на SQL Server 2000, которая должна время от времени усекаться. Похоже, что самым простым решением было бы создать дублированную базу данных и скопировать туда основную базу данных. Тогда первичная база данных может быть безопасно обрезана с помощью специально настроенных хранимых процедур.

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

Мы планируем использовать резервную базу данных для отчетов и первичную для оперативных данных. Первичная база данных будет обрезаться ночью один раз в 2 дня. База данных составляет несколько гигабайт. Только несколько таблиц довольно большие (1-2 млн строк)

Каковы возможные подводные камни? Насколько надежным было бы такое решение? Замедлит ли это первичную базу данных?

Обновление: Вариант с DTS для копирования хорошо звучит, но имеет свои недостатки. Для копирования обновленных строк требуется довольно надежный скрипт, который будет работать около часа. Существует также проблема с ограничениями целостности в первичной базе данных, что делает ее усечение нетривиальной задачей. Из-за этой репликации холод значительно поправляется.

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

Answer 1

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

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

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

Вы упомянули, что целью вторичных данных является сохранение отчета. В этом случае вы можете создать представление, подобное SELECT * FROM Primary.dbo.Table UNION ALL SELECT * FROM SecondaryDBJune2008.dbo.Table UNION ALL SELECT * FROM SecondaryDBOctober2008.dbo.Table. Затем вам нужно будет поддерживать это представление в актуальном состоянии всякий раз, когда вы выполняете усечение.

Другой альтернативой было бы сделать снимок текущих данных перед усечением и вставить их в одну базу данных отчетов. Тогда у вас просто будут базы данных Primary и Historical - нет необходимости изменять представления после их создания.

Сколько данных мы говорим в ГБ?

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

Answer 2

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

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