В предишната статия, Настройка и конфигуриране на репликация на SQL Server, обсъдихме задълбочено концепцията за репликация на SQL Server, нейните компоненти, типове и как да конфигурирате SQL транзакционната репликация стъпка по стъпка. Силно препоръчително е да преминете през предишната статия и да разберете концепцията за репликация и нейните компоненти, преди да прочетете тази статия. В тази статия ще видим как да отстраним неизправности в съществуващ сайт за репликация на SQL Server.
Общ преглед на отстраняването на неизправности
Основната цел на репликацията на SQL Server е синхронизирането на данните в издателя и абоната. В щастливия сценарий, ако транзакция бъде извършена и ангажирана в базата данни за публикации, тя ще бъде копирана в базата данни за разпространение, след което ще бъде синхронизирана и приложена към всички абонати, свързани към този издател. Ако възникне проблем на която и да е стъпка от този процес, промените на издателя няма да бъдат налични от страната на абоната. В този случай трябва да отстраним и коригираме този проблем възможно най-скоро, преди да завършим с изтекъл сайт за репликация на SQL, който трябва да бъде синхронизиран отново от нулата или база данни с нейния регистрационен файл на транзакциите изчерпва свободно място, поставяйки на пауза всички транзакции на база данни .
Идентифицирането на коя стъпка е неуспешна синхронизацията на репликацията и разпределянето на индикативно съобщение за грешка, което води до отстраняване на проблема, е най-предизвикателната част от процеса за отстраняване на неизправности при репликация на SQL Server. Също така, проверката на последното време на синхронизиране и промените, извършени в/след това време, които могат да причинят тази неуспех, също може да помогне при отстраняване на неизправност при неуспех при синхронизиране на репликация.
Разбирането на ролята на агента за репликация на SQL Server ще помогне за идентифициране на коя стъпка е неуспешна синхронизацията. Припомнете си, че има три агента за репликация, които са общи за повечето типове репликация на SQL Server. Агентът за моментни снимки е отговорен за създаването на първоначалната моментна снимка за синхронизация. Агентът за четене на журнали отговаря за четенето на промените от регистрационния файл на транзакциите на базата данни и копирането му в базата данни за разпространение и накрая, Разпространението агент, който е отговорен за синхронизирането на промените на абонатите.
В тази статия ще се възползваме от Монитора за репликация и Монитор на работната активност прозорци при наблюдение на състоянието на репликация на SQL Server и получаване на информация за всяка грешка при неуспешно синхронизиране.
Сценарии за отстраняване на неизправности
Най-добрият и ясен начин да разберете как да отстраните проблемите с репликацията на SQL Server е чрез предоставяне на практически сценарии и показване как да коригирате този конкретен проблем. Нека започнем да обсъждаме сценариите един по един.
Проблем с услугата на агента на SQL Server
Услугата SQL Server Agent играе жизненоважна роля в процеса на синхронизиране на репликация на SQL Server. Това се дължи на факта, че всеки агент за репликация ще работи под задача на SQL агент.
Като проактивен администратор на база данни, трябва да проверявате състоянието на сайта за репликация на SQL ежедневно. За да проверите състоянието на сайта за репликация, щракнете с десния бутон върху публикацията под възела Репликация -> Локални публикации и изберете Стартиране на монитор за репликация опция, както е показано по-долу:
От прозореца Монитор на репликацията можете да видите предупредително съобщение, показващо, че репликацията скоро ще изтече или вече е изтекла, без да виждате индикативно съобщение за грешка, както е по-долу:
Ако прозорецът Монитор на репликацията ни предоставя никаква полезна информация за това защо сайтът за репликация изтича скоро, следващата стъпка е да проверите Монитора на Job Activity Monitor под възела на SQL Server Agent. Посещавайки възела на SQL Server Agent, ще видите директно, че услугата SQL Server Agent не работи (от червения кръг до нея). Ако услугата за агент на SQL Server не работи, това означава, че всички задания, създадени под този екземпляр, не работят, включително заданията на агента за репликация. В резултат на това общият сайт за репликация не работи.
За да коригираме този проблем, трябва да стартираме услугата SQL Server Agent директно от SQL Server Management Studio или използвайки SQL Server Configuration Manager (препоръчително), както е показано по-долу:
След като стартирате услугата SQL Server Agent, проверете отново монитора за репликация и се уверете, че състоянието на абоната е Running и всички чакащи транзакции се синхронизират успешно с абоната. Можете да проверите тези стъпки една по една, като проверите дали записите са копирани от секцията Издател към Дистрибутор:
След това се синхронизира успешно от дистрибутора към абоната, както следва:
И накрая се уверете, че няма неразпределена транзакция от последния раздел, както е показано по-долу:
След това трябва да се уверим, че задачите на агентите за репликация работят и работят без проблем. Задачите на SQL Agent могат да бъдат проверени чрез разширяване на възела на SQL Server Agent под SSMS Object Explorer и преглед на монитора на Job Activity, след което проверете дали агентът за четене на журнали и агентът на дистрибутора работят, като се има предвид, че агентът за моментна снимка ще работи само по време на процес на създаване на моментна снимка, както е показано по-долу:
Можете също да прегледате историята на заданията на агентите за репликация и да проверите предишната причина за неуспех, като щракнете с десния бутон върху това задание и изберете Преглед на историята опция, както е по-долу:
Къде може да намерите индикативно съобщение за грешка, което помага за преодоляването на този проблем в бъдеще, както е посочено по-долу:
За да се преодолее предишния проблем, режимът на стартиране на услугата SQL Server Agent трябва да бъде променен от ръчен на автоматичен, като по този начин ще се уверите, че услугата ще стартира автоматично при рестартиране на хостинг сървъра.
Проблем с разрешението на агента за моментна снимка
Да приемем, че докато проверявате състоянието на репликация на SQL Server, като използвате монитора за репликация, сте забелязали, че има грешка при репликацията, от знака X вътре в червения кръг. И мониторът за репликация показва, че грешката е от един от агентите за репликация, от знака X в червения кръг в горната част на раздела Агенти.
За да идентифицираме тази грешка при репликация, трябва да прегледаме раздела Агенти и да проверим кой агент не работи. От страницата Агенти ще видите, че агентът за моментна снимка е неуспешният. Щракнете двукратно върху агента за моментна снимка и прегледайте съобщението за грешка по-долу:
Агентът за репликация не е регистрирал съобщение за напредък в рамките на 10 минути. Това може да показва неотговарящ агент или висока системна активност. Уверете се, че записите се репликират до местоназначението и че връзките към абоната, издателя и дистрибутора все още са активни.
За съжаление, това съобщение за грешка е общо и показва само, че Snapshot Agent не работи, без да се посочва причината, както следва:
След това трябва да потърсим полезна информация на друго място, което е работата на Snapshot Agent. От прозореца Монитор на активността на заданията, под възела на SQL Server Agent, можете да видите, че заданието на агента за моментни снимки е неуспешно. И от тази история на заданията можете да видите, че наскоро се провали поради проблема с удостоверяването на прокси сървъра. С други думи, идентификационните данни за акаунта, под който работи Snapshot Agent, не са правилни, както е показано по-долу:
За да коригирате проблема с идентификационните данни на Snapshot Agent, щракнете с десния бутон върху публикацията под възела Репликация -> Локална публикация и изберете Свойства опция. От прозореца Свойства на публикацията прегледайте Сигурност на агента страница и поставете отново идентификационните данни за акаунта, под който ще работи Snapshot Agent.
След като обновите идентификационните данни на акаунта на Snapshot Agent, стартирайте отново заданието на Snapshot Agent от прозореца Job Activity Monitor и се уверете, че работата работи добре, както е посочено по-долу:
Също така проверете дали Snapshot Agent работи добре сега и съобщението за грешка не се показва повече под монитора за репликация, както е показано по-долу:
Проблем с разрешението за папка за моментни снимки
Да приемем, че когато се опитвате да синхронизирате издателя и абоната с помощта на първоначалната моментна снимка или повторно синхронизирате сайта за репликация на моментна снимка с нова моментна снимка, процесът на създаване на моментна снимка е неуспешен със съобщението за грешка при достъп по-долу:
Това съобщение за грешка показва, че акаунтът, под който се изпълнява Snapshot Agent, няма разрешение за достъп до папката за моментни снимки, посочена в съобщението за грешка.
За да коригираме този проблем, трябва да проверим акаунта, под който се изпълнява Snapshot Agent, от страницата Защита на агента на прозореца Свойства на публикацията, както е показано по-долу:
След това прегледайте папката за моментни снимки, посочена в съобщението за грешка, и се уверете, че този акаунт за моментна снимка има минимално разрешение за четене и запис в тази папка, след това стартирайте отново агента за моментни снимки и вижте, че проблемът е отстранен сега и моментната снимка за синхронизиране е създадена успешно, т.к. по-долу:
Проблем с разрешението за абонати
Да приемем, че докато проверявате състоянието на сайта за репликация на SQL Server, като използвате монитора за репликация, виждате, че има грешка с абоната, както е показано по-долу:
Ако щракнете върху иконата за грешка, ще видите, че е възникнала грешка при опит за синхронизиране на транзакциите от дистрибутора към абоната. И от съобщението за грешка става ясно, че дистрибуторът не може да се свърже с абонатния екземпляр на SQL Server поради проблем с разрешение, както е показано по-долу:
За да коригираме този проблем, трябва да проверим и обновим идентификационните данни, използвани за свързване с екземпляра на абоната. За да проверите идентификационните данни, щракнете с десния бутон върху абонамента под възела Репликация -> Локални публикации -> текущото име на публикация и изберете опцията Свойства. От Връзката на абоната поле под прозореца Свойства на абоната, опреснете идентификационните данни за акаунта, който ще се използва за свързване с екземпляра на абоната, както е показано по-долу:
След това проверете отново състоянието на репликация от монитора за репликация и ще видите, че проблемът с връзката на абоната вече не е наличен и сайтът за репликация работи нормално, както е показано по-долу:
Абонатът не е достъпен
Друг проблем с неуспешната репликация на SQL Server, с който може да се сблъскате от страната на абоната, е, че дистрибуторът не може да се свърже с абоната, показвайки под страницата на дистрибутора към абоната, че не може да отвори връзка с абоната поради „Мрежа Свързано… ” грешка при свързване, показана в прозореца Монитор на репликация по-долу:
Това съобщение за грешка показва, че има проблем с връзката между екземпляра на дистрибутора и екземпляра на абоната. Първият и ясен начин да проверите този проблем със свързаността е да се уверите, че екземплярът на SQL Server на абоната е онлайн. Това може да се провери от SQL Server Configuration Manager от страната на абоната. В нашата ситуация можем да видим, че услугата SQL Server от страната на абоната е спряна. За да отстраните този проблем, стартирайте услугата SQL Server и проверете от монитора за репликация дали сайтът за репликация е синхронизиран отново, както е показано по-долу. За по-разширен проблем с SQL свързаността проверете документа MS за отстраняване на неизправности при свързване:
Проблем с разрешението на базата данни за абонати
Да приемем, че проверявате състоянието на синхронизиране на репликацията на SQL Server, като използвате монитора за репликация и е установено, че репликацията е неуспешна, докато се опитвате да репликирате промените от дистрибутора към абоната. Щраквайки върху грешката на абоната, ще видите, че Дистрибуторът може да достигне до абоната и да се свърже с него, но не може да се свърже с базата данни за абонамент поради липса на проблем с разрешение, както е показано по-долу:
За да коригирате този проблем, свържете се с абоната и се уверете, че акаунтът, който се използва за свързване към базата данни на абонатите, е член на фиксираната роля на базата данни db_Owner, както е показано по-долу:
След това проверете отново монитора за репликация и се уверете, че дистрибуторът може да достигне до базата данни за абонаменти и да репликира промените, както е посочено по-долу:
Проблем с разликата в данните
Да приемем, че един от екипите за разработка на база данни твърди, че има някои промени, които се извършват в таблицата Shifts на издателя (SQL1), не са отразени в ежедневните отчети, които се изпълняват на екземпляра на абоната (SQL2), и той предостави моментната снимка по-долу което показва, че промените не се репликират:
Първата стъпка в проверката на проблема със синхронизирането на репликацията е отварянето на монитора за репликация и намирането на коя стъпка е неуспешна. От монитора за репликация можете да видите, че агентът за четене на журнали не работи, тъй като промените не се репликират от дистрибутора към абоната, но от този агент не се връща ясно съобщение, както е показано по-долу:
Тъй като не можем да намерим смислено съобщение за грешка от монитора за репликация, ще проверим историята на заданието на агент за четене на журнали, като използваме монитора на активността на заданията, който показва, че идентификационните данни за акаунта, под който се изпълнява агентът за четене на журнали, са неправилни , както е показано по-долу:
За да коригирате проблема с идентификационните данни на агента за четене на журнали, прегледайте страницата за защита на агента в прозореца със свойства на публикацията и опреснете идентификационните данни на агент за четене на журнали с валидни, както е посочено по-долу:
Проверявайки отново монитора за репликация, ще видите, че промените са репликирани успешно и че данните се актуализират с новите промени в смените, както е показано по-долу:
Редът не е намерен при абонат
Нека разгледаме проблема от друга страна. Да кажем, че има промяна, извършена в таблицата за смени, както е показано по-долу:
Но тази промяна не се репликира на абоната и цялостният сайт за репликация на SQL Server е неуспешен. От монитора за репликация можете да видите, че се проваля, докато се опитва да направи промяната от дистрибутора към абоната и не успя поради факта, че не може да актуализира този конкретен запис с идентификатор, равен на 3, тъй като този запис не е наличен в таблицата на базата данни за абонати, както е показано по-долу:
Проверявайки този запис от страната на абоната (SQL2), ще видите, че записът не е наличен, както е посочено по-долу:
За да преодолеем този проблем, трябва да вмъкнем този запис отново в таблицата на базата данни на абонатите и да оставим дистрибутора да се опита да го актуализира отново, коригирайки проблема с неуспешната синхронизация на репликация, както е показано по-долу:
SQL Server ни предоставя опция да оставим сайта за репликация да продължи да работи, въпреки че е открит проблем с несъответствието на данните, където можете ръчно да коригирате този проблем по-късно. За да направите това, от монитора за репликация щракнете с десния бутон върху абоната и изберете Профил на агент опция, както е показано по-долу:
От показания прозорец можете да актуализирате профила на агент за четене на журнали и да му позволите да продължи да репликира промените в данните в случай, че има проблем с несъответствие на данните, както е показано по-долу:
Проблем с неинициализиран абонамент
Ако сайтът за репликация е оставен без наблюдение за дълго време и е възникнала грешка без никакво поправяне за повече от три дни, сайтът за репликация ще бъде изтекъл и абонаментът ще бъде маркиран като неинициализиран, чакайки да бъде повторно инициализиран отново с помощта на нова моментна снимка . Същият сценарий може да се сблъскате, когато създавате нов абонамент, без да го инициализирате, както е показано по-долу:
За да коригираме този проблем, трябва да инициализираме повторно този абонамент, като щракнете с десния бутон върху абонамента под възела за репликация -> Локални публикации и разгънете публикацията, след което изберете опцията Reinitialize и маркирайте този абонамент за инициализация и го подготвите за получаване на нов моментна снимка, както е показано по-долу:
Ако състоянието на абонамента остане неинициализирано след повторното му инициализиране, проверете заданието на Snapshot Agent, като използвате прозореца Job Activity Monitor, и вижте защо е неуспешно. От историята на заданията на агента за моментна снимка ще видите, че заданието е неуспешно поради проблем, определящ собственика на това задание на агент, както е показано по-долу:
За да преодолеете този проблем, отворете заданието на Snapshot Agent и променете собственика на заданието на SA или всеки валиден администратор на потребител и задачата ще се изпълнява успешно, както е по-долу:
Сега ще видите, че състоянието на абонамента е променено на Running, което означава, че изчаква първоначалната моментна снимка, за да започне процеса на синхронизиране, както е показано по-долу:
За да генерирате нова моментна снимка, щракнете с десния бутон върху публикацията, под възела Репликация-> Локални публикации и изберете Преглед на състоянието на агента за моментна снимка опция.
От отворения прозорец щракнете върху бутона Старт, за да започнете процеса на създаване на моментна снимка. Когато моментната снимка, която съдържа всички статии на издателя, е създадена успешно, отворете отново монитора за репликация и проверете състоянието на абонамента, където ще видите, че моментната снимка е приложена към абоната и е синхронизирана с издателя, както е показано по-долу:
Проблем със собственика на базата данни на издателя
Да приемем също, че при проверка на състоянието на сайта за репликация на SQL Server, използвайки монитора за репликация, сайтът за репликация е неуспешен и грешката е открита в агента за четене на журнали. При проверка на съобщението за грешка, върнато от този агент, се установява, че има проблем при определянето на текущия собственик на базата данни за публикации, както е показано по-долу:
За да коригираме този проблем, трябва да актуализираме текущия собственик на базата данни за публикации, като я заменим с валиден потребител на база данни, като използваме SP_changedbowner системна съхранена процедура или просто от прозореца със свойства на базата данни. След това стартирайте отново задачата на агент за четене на журнали, като използвате прозореца Монитор на активността на заданията, след което проверете дали проблемът с агента вече не е наличен, като използвате монитора за репликация, както е показано по-долу:
Заключение
В тази статия демонстрирахме различни проблеми, с които може да се сблъскате, докато използвате функцията за репликация на SQL Server за копиране на данни между различни сайтове и как да коригирате тези проблеми.
Силно се препоръчва да поддържате SQL Server Engine актуален с най-новите SP и CU, така че всички грешки, свързани с функциите за репликация на SQL Server, ще бъдат коригирани автоматично. И накрая, като проактивен администратор на база данни на SQL Server, следете сайта си за репликация, за да коригирате всеки проблем от самото начало, преди да стане по-голям и по-труден за отстраняване.
