SQL Server — лучшая модель репликации для архивирования

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

Итак, в идеале мне бы понравилось, если бы я мог сделать это:

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

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

На № 2 - Как убедиться, что эти удаления не реплицируются - что данные хранятся на сервере архивации?

Рабочий сервер работает под управлением SQL Server 2008 Enterprise, сервер резервного копирования может запускать все необходимое (в настоящее время он работает под управлением SQL Server 2008 Express).


archive sql-server backup sql-server-2008 replication
person nikib3ro    schedule 11.07.2011    source источник
comment
Для № 2 вы не захотите использовать репликацию или зеркалирование, потому что удаление будет происходить и на реплике. В общем, я бы предложил разбиение на разделы или ручное архивирование в отдельную базу данных, но вы забыли сообщить нам, какую версию и редакцию SQL Server вы используете — это важные детали.   -  person Aaron Bertrand    schedule 11.07.2011
comment
Я добавил детали ... также изучал разбиение на разделы, возможно, это + репликация по запросу для резервного копирования / отчетов - это путь ...   -  person nikib3ro    schedule 12.07.2011
comment
Вы не сможете использовать репликацию для резервного копирования/отчетов, так как это приведет к удалению старых данных при удалении их из источника.   -  person Aaron Bertrand    schedule 12.07.2011
comment
Если вы используете репликацию, вы не сможете использовать SQL Express в качестве подписчика (или издателя, или распространителя).   -  person mattmc3    schedule 12.07.2011

Ответы (2)


arrow_upward
2
arrow_downward

Что касается № 1, я бы сказал, протестируйте и посмотрите. У MS обычно есть несколько технических документов, в которых говорится, что подписка по запросу более эффективна, но я не помню, чтобы они говорили, сколько это стоит с точки зрения ресурсов. Если вас это беспокоит, настройте удаленный распространитель (удаленный = не тот же сервер, что и издатель)

Для № 2 есть несколько способов сделать это. Когда вы настраиваете статью с помощью sp_addarticle, есть параметр @del_cmd, который может принимать значение «none». Это сообщит агенту распространителя о неоперабельных удалениях на подписчике. Вы также можете выполнить очистку с помощью хранимой процедуры, настроить выполнение хранимой процедуры как статьи в репликации, а затем иметь хранимую процедуру на подписчике, которая ничего не делает. Каждый подход имеет свои плюсы и минусы.

person Ben Thul    schedule 12.07.2011
comment
# 1 Подписка на вытягивание порождает дистрибьютора на машине, которая вытягивает, поэтому она определенно лучшая, когда дело доходит до производительности (сервер с исходной базой данных публикует только изменения в локальной базе данных репликации и все) ... # 2 Полезная информация ... посмотрю если я смогу как-то использовать это, хотя я, вероятно, прибегну к написанию процедур, которые будут копировать нужные мне данные в Archive DB. - person nikib3ro; 17.07.2011
comment
Для № 2 Решение, которое вы описали с использованием хранимой процедуры, которая будет выполнять удаления, а затем иметь ту же хранимую процедуру, которая ничего не делает с подписчиком, звучало так, как будто это было бы отличным решением для нас, однако я настроил и протестировал его и похоже данные удаляются и у абонента. Возможно, я сделал что-то не так? - person Matt Palmerlee; 17.03.2012
comment
На самом деле я только что заметил, что создание хранимой процедуры как статьи в репликации разбило мою фиктивную процедуру в подписчике, поэтому я предполагаю, что она скопировала sp, которая выполняла удаление, а затем выполнила ее на подписчике? - person Matt Palmerlee; 17.03.2012
comment
По-прежнему не удалось заставить работать фиктивный метод хранимой процедуры, я пойду дальше и выберу опцию «Не реплицировать операторы удаления». - person Matt Palmerlee; 20.03.2012
comment
Извините, я не видел ваших ответов от 16 марта. Проблема, с которой вы столкнулись при инициализации статьи, приводившая к перезаписи хранимой процедуры на подписчике, должна контролироваться опцией @schema_option в вызове sp_addarticle. В частности, если установлен бит 0x01, он будет вести себя так, как вы описываете. Если нет, то он не должен реплицировать схему sproc. - person Ben Thul; 20.03.2012
comment
Хорошо, спасибо за это. Я думаю, что у меня проблемы, потому что я не понимаю, как ведет себя SqlServer при репликации удалений подписчику. По умолчанию кажется, что он вызывает sp_MSdel_dbo‹tablename› для репликации удалений подписчику, для таблиц, которые мне интересны, вы можете использовать @del_cmd = N'NONE', как вы описываете в своем ответе, но вы предлагаете установить del_cmd = N'CALL [dbo].[your_dummy_stored_proc]' вместо этого? Или тот факт, что хранимая процедура для удаления является статьей, не будет использовать sp_MSdel_dbo‹tablename› по умолчанию для этих таблиц для репликации изменений? Спасибо. - person Matt Palmerlee; 20.03.2012
comment
Ах... нет. Я предлагаю создать хранимую процедуру на издателе, которая в общем случае обрабатывает удаления. Назовем его dbo.DeleteRecords. Вы собираетесь создать статью о выполнении хранимой процедуры. Теперь, когда вы выполните dbo.DeleteRecords, он удалит записи на издателе, а затем выполнит sproc на подписчике. Волшебство происходит, когда этот sproc на подписчике закодирован так, чтобы ничего не делать. Репликация достаточно умна, чтобы знать, что удаленные записи на издателе были результатом выполнения sproc, и поэтому не будет реплицировать удаления. - person Ben Thul; 21.03.2012
comment
Хорошо, спасибо за дополнительное объяснение, я попробую еще раз. - person Matt Palmerlee; 21.03.2012
comment
Я попробовал это снова, используя хранимую процедуру для удаления, для удаления SP я даже указываю Execution в сериализованной транзакции SP для статьи (@type = N'serializable proc exec' в sp_addarticle) и когда я смотрю при том, что происходит на подписчике, он все еще вызывает: exec [dbo].[sp_MSdel_... вместо моего удаления сохраненного pro. Спасибо за вашу помощь, но, возможно, мне следует просто задать отдельный вопрос по этому поводу в Stack Overflow. - person Matt Palmerlee; 21.03.2012
comment
Я с нетерпением жду возможности помочь вам, когда вы получите отдельный вопрос. Следует отметить, что сериализуемый proc exec будет реплицировать proc как отдельные команды строк при определенных обстоятельствах. См. msdn.microsoft.com/en-us/library/ms152754.aspx для получения дополнительной информации. - person Ben Thul; 22.03.2012
comment
Спасибо, Бен, я жду, чтобы создать новый вопрос, потому что я переосмысливаю модель архивирования посредством репликации. Меня беспокоит то, что даже если я настрою его правильно, метод подвержен человеческим ошибкам. Скажем, если по какой-то причине кто-то создаст новый снимок и подписчик обновится до него, внезапно мы потеряем все наши архивные данные. - person Matt Palmerlee; 27.03.2012

arrow_upward
0
arrow_downward

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

person toanda    schedule 10.12.2013