Архивирование данных с общедоступного производственного сервера на внутренний архив

Question

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

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

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

На общедоступном производственном сервере мы используем SQL Server 2008 Standard Edition, во внутренней системе архивации мы хотимиспользуйте SQL Server 2008 R2 Enterprise Edition, чтобы воспользоваться преимуществами разделения и сжатия для архива.

В настоящий момент я рассматриваю следующие подходы:

1. Ежедневная репликация данных изпроизводство в архивную систему.Когда старые данные о производстве удаляются, они не должны копироваться в систему архивирования.Я нашел возможность игнорировать операции удаления на цели репликации.

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

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

Как вы думаете?Есть ли у вас какие-либо рекомендации или вы знаете некоторые передовые практики в отношении таких проблем?Рассматривается ли эта тема где-либо еще (например, книги)?

Заранее большое спасибо.

PS: Я не уверен, стоит ли задавать этот вопрос здесь или на сервере.Пожалуйста, переместите его, если мое решение опубликовать его здесь было неверным.Спасибо.

Answer 1

О скольких таблицах мы говорим, которые нужно заархивировать?

Если это только одна или несколько таблиц, вы можете просто регулярно запускать SQL-запросы с помощью агента SQL Server.

Примерно так (очень упрощенно):

-- copy to archive database
insert into ArchiveServer.dbo.ArchiveTable (Column1, Column2, ...)
select Column1, Column2, ...
from ProductionTableOnThisServer
where DateColumn < dateadd(m, -3, getdate())

-- delete in production database
delete from ProductionTableOnThisServer
where DateColumn < dateadd(m, -3, getdate())

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

Конечно, этот маленький пример далек от совершенства (или даже готов к производству!).
Это было просто, чтобы выразить основную идею.

В реальном мире вы, вероятно, также хотите:

• объединяет оба запроса в транзакции, чтобы реальные данные не удалялись, если архивация по какой-то причине не работала
• вставлять только действительно новые строки и обновлять те, которые изменились
• и так далее ...

Answer 2

Одна вещь, которую вы могли бы сделать, это вставить ваше веб-приложение в обе БД одновременно.Таким образом, архив не зависит от prod db.совсем.

Вы также можете рассмотреть возможность разделения продукта.БД, так что удаление данных из БД прод проще.(Но поскольку ваша prod DB является стандартной версией, это не вариант.) В этом случае вам, возможно, придется удалить строки из prod DB.Чтобы удалить, не делайте полное удаление за одну транзакцию.Возможно, вы захотите разбить его на партии.

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