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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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