SQL Server - най-добрият репликационен модел за архивиране

Намирам се в момента, в който трябва да започна да архивирам базата данни на уебсайта, който поддържам. По принцип много транзакционни данни се генерират ежедневно и след приблизително 2 седмици тези данни са почти безполезни - все още са необходими за целите на отчитането, но могат безопасно да бъдат преместени от производствен сървър.

И така, в идеалния случай бих се радвал, ако мога да направя това:

  1. Настройка на изтегляне на репликация - резервният сървър извлича промените от производствения сървър всеки час.
  2. Ежедневно - базата данни на производствения сървър се почиства - записи, по-стари от 2 седмици, се изтриват.

На #1 - любопитен съм дали репликацията на изтегляне е най-ефективният начин за преминаване от гледна точка на производителността? Не искам да натоварвам производствения сървър (или поне не голямо)... Не ми пука много за синхронизирането на базите данни.

На #2 - Как да се уверите, че тези изтривания не се репликират - че данните се съхраняват на архивен сървър?

Производственият сървър работи с SQL Server 2008 Enterprise, Backup сървърът може да изпълнява каквото е необходимо (в момента работи с 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, който може да приеме стойност „няма“. Това ще каже на агента за разпространение да изтрива без операции при абоната. Можете също да извършите изчистването си със съхранена процедура, да настроите изпълнението на съхранената процедура като статия в репликация и след това да имате съхранена процедура при абоната, която не прави нищо. Всеки подход има своите плюсове и минуси.

person Ben Thul    schedule 12.07.2011
comment
#1 Абонаментът за изтегляне създава дистрибутор на машината, която тегли, така че определено е най-добрият, що се отнася до производителността (сървърът с оригинална база данни публикува само промени в база данни за локална репликация и това е)... #2 Полезна информация... ще видим ако мога по някакъв начин да го използвам, въпреки че вероятно ще прибягна до процедури за писане, които ще копират данните, от които се нуждая, в архивна база данни. - 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 за изтриване дори посочвам Изпълнение в сериализирана транзакция на SP за статията (@type = N'serializable proc exec' в sp_addarticle) и когато гледам при това, което се случва на абоната, той все още извиква: exec [dbo].[sp_MSdel_... вместо my delete stored 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