Започнахме да говорим за проблеми с репликацията на транзакции на SQL Server по-рано. Сега ще продължим с още няколко практически демонстрации, за да разберем често срещаните проблеми с производителността на репликацията и как да ги отстраним правилно.
Вече обсъдихме такива проблеми като проблеми с конфигурацията, проблеми с разрешенията, проблеми със свързаността и проблеми с целостта на данните, заедно с отстраняването и отстраняването им. Сега ще се съсредоточим върху различни проблеми с производителността и проблеми с корупцията, засягащи репликацията на SQL Server.
Тъй като проблемите с корупцията са огромна тема, ще обсъдим как тяхното въздействие ще бъде само в тази статия и няма да навлизаме в подробности. Избрах няколко сценария, които могат да попаднат в проблеми с производителността и корупцията въз основа на моя опит:
- Проблеми с производителността
- Дългосрочни активни транзакции в базата данни на издателя
- Групови операции INSERT/UPDATE/DELETE върху статии
- Огромни промени в данните в рамките на една транзакция
- Блокиране в базата данни за разпространение
- Проблеми, свързани с корупцията
- Повреда в базата данни на издателя
- Повреда на базата данни за разпространение
- Повреда в базата данни на абонатите
- Повреда на базата данни MSDB
Проблеми с производителността
Транзакционната репликация на SQL Server е сложна архитектура, която включва няколко параметъра като базата данни на издателя, базата данни на дистрибутора (разпространението), базата данни на абонатите и няколко агента за репликация, изпълняващи се като задачи на SQL Server Agent.
Тъй като обсъдихме всички тези елементи подробно в предишните ни статии, ние знаем значението на всеки от тях за функционалността за репликация. Всичко, което засяга тези компоненти, може да повлияе на производителността на репликацията на SQL Server.
Например, екземплярът на базата данни Publisher държи критична база данни с много транзакции в секунда. Ресурсите на сървъра обаче имат затруднено място като постоянното използване на процесора над 90% или използване на паметта над 90%. Това определено ще окаже влияние върху производителността на заданието на агент за четене на журнали, което чете данните за промените от транзакционните регистрационни файлове на базата данни на издателя.
По същия начин всички подобни сценарии в екземпляри на база данни на дистрибутор или абонат могат да повлияят на агента за моментни снимки или агента за разпространение. Така че, като DBA, трябва да се уверите, че ресурсите на сървъра като процесор, физическа памет и мрежова честотна лента са ефективно конфигурирани за екземплярите на базата данни издател, дистрибутор и абонат.
Ако приемем, че сървърите на базата данни на издател, абонат и дистрибутор са конфигурирани правилно, все още можем да имаме проблеми с производителността на репликацията, когато се сблъскаме със сценариите по-долу.
Дългосрочни активни транзакции в базата данни на издателя
Както показва името, дългосрочните активни транзакции показват, че има извикване на приложение или потребителска операция в рамките на обхвата на транзакцията, която се изпълнява за дълго време.
Намирането на дълготрайна активна транзакция означава, че транзакцията все още не е ангажирана и може да бъде отменена или ангажирана от приложението. Това ще предотврати съкращаването на регистрационния файл на транзакциите, което ще доведе до непрекъснато увеличаване на размера на файла на регистрационния файл на транзакциите.
Агентът за четене на журнали сканира за всички записани записи, които са маркирани за репликация от транзакционни регистрационни файлове в сериализиран ред въз основа на поредния номер на журнала (LSN), като пропуска всички други промени, случващи се за статии, които не са репликирани. Ако дългосрочните активни транзакции все още не са ангажирани, тогава репликацията ще пропусне изпращането на тези команди и ще изпрати всички други ангажирани транзакции към базата данни за разпространение. След като продължително действащата активна транзакция бъде ангажирана, записите ще бъдат изпратени до базата данни за разпространение и дотогава неактивната част от регистрационния файл на транзакциите на Publisher DB няма да бъде изчистена, което ще доведе до увеличаване на размера на регистрационния файл на транзакциите на базата данни на издателя.
Можем да тестваме сценария за продължителна активна транзакция, като изпълним следните стъпки:
По подразбиране Агентът за разпространение изчиства всички извършени промени в базата данни на абонатите, като запазва последния запис, за да наблюдава новите промени въз основа на поредния номер на журнала (LSN).
Можем да изпълним заявките по-долу, за да проверим състоянието на записите, налични в MSRepl_Commands таблици или с помощта на sp_browsereplcmds процедура в базата данни за разпространение:
exec sp_browsereplcmds
GO
SELECT * FROM MSrepl_commands
Сега отворете нов прозорец за заявка и изпълнете скрипта по-долу, за да създадете продължителна активна транзакция в AdventureWorks база данни. Обърнете внимание, че скриптът по-долу не включва никакви команди ROLLBACK или COMMIT TRANSACTION. Ето защо ви съветваме да не изпълнявате тези видове команди в производствената база данни.
BEGIN TRANSACTION
SET IDENTITY_INSERT Person.ContactType ON;
insert into person.ContactType (ContactTypeId, Name, ModifiedDate) values ( 22, 'Test New Position', GETDATE());
SET IDENTITY_INSERT Person.ContactType OFF;
Можем да потвърдим, че този нов запис не е репликиран в базата данни на абонатите. За това ще изпълним оператора SELECT на Person.ContactType таблица в базата данни за абонати:
Нека проверим дали горната команда INSERT е прочетена от агента за четене на журнали и записана в базата данни за разпространение.
Изпълнете скриптовете от частта на Стъпка 1 отново. Резултатите все още показват същото старо състояние, което потвърждава, че записът не е прочетен от регистрационните файлове на транзакциите на базата данни на издателя.
Сега отворете Нова заявка прозорец и изпълнете долния скрипт UPDATE, за да видите дали агентът за четене на журнали е успял да пропусне продължителната активна транзакция и да прочете промените, извършени от този оператор UPDATE.
UPDATE AdventureWorks.dbo.AWBuildVersion
SET ModifiedDate = GETDATE()
Проверете базата данни за разпространение дали агентът за четене на журнали може да улови тази промяна. Изпълнете скрипта като част от Стъпка 1:
Тъй като горният оператор UPDATE е зает в базата данни на издателя, агентът за четене на журнали може да сканира тази промяна и да я вмъкне в базата данни за разпространение. Впоследствие той приложи тази промяна към базата данни за абонати, както е показано по-долу:
INSERT на Person.ContactType ще бъде репликиран в базата данни на абонатите само след като транзакцията INSERT бъде записана в базата данни на издателя. Преди да се ангажираме, можем бързо да проверим как да идентифицираме дългосрочна активна транзакция, да я разберем и да я обработваме ефективно.
Определете продължителна активна транзакция
За да проверите за продължителни активни транзакции в която и да е база данни, отворете нов Прозорец за заявка и се свържем със съответната база данни, която трябва да проверим. Изпълнете DBCC OPENTRAN конзолна команда – това е конзолна команда на базата данни за преглед на транзакциите, отворени в базата данни в момента на изпълнение.
USE AdventureWorks
GO
DBCC OPENTRAN
Сега знаем, че е имало SPID (идентификатор на сървърен процес ) 69 работи за дълго време. Нека проверим коя команда е била изпълнена за тази транзакция с помощта на DBCC INPUTBUFFER конзолна команда (Команда на конзолата на базата данни, използвана за идентифициране на командата или операцията, която се случва на избрания сървърен идентификатор на процес).
За четливост копирам EventInfo стойност на полето и го форматирайте, за да покаже командата, която сме изпълнили по-рано.
Ако в избраната база данни няма дълготрайни активни транзакции, ще получим следното съобщение:
Подобно на DBCC OPENTRAN конзолна команда, можем да ИЗБЕРЕМ отDMV с име sys.dm_tran_database_transactions за да получите по-подробни резултати (вижте статията на MSDN за повече данни).
Сега знаем как да идентифицираме дългосрочната транзакция. Можем да извършим транзакцията и да видим как се репликира операторът INSERT.
Отидете до прозореца, където сме вмъкнали записа в Person.ContactType таблица в обхвата на транзакцията и изпълнете COMMIT TRANSACTION, както е показано по-долу:
Изпълнението на COMMIT TRANSACTION записва записа в базата данни на издателя. Следователно, той трябва да се вижда в базата данни за разпространение и базата данни за абонати:
Ако сте забелязали, по-старите записи от базата данни за разпространение са почистени от задачата за почистване на агента за разпространение. Новият запис за INSERT на Person.ContactType таблицата беше видима в MSRepl_cmds таблица.
От нашето тестване научихме следните неща:
- Заданието агент за четене на журнали на транзакционната репликация на SQL Server ще сканира за записани записи само от транзакционните регистрационни файлове на базата данни на издателя и ВМЕСТЕ в базата данни на абонатите.
- Редът на променените данни в базата данни на издателя, изпратен до абоната, ще се основава на състоянието и времето на ангажимент в базата данни на издателя, въпреки че репликираните данни ще имат същото време като базата данни на издателя.
- Идентифицирането на дългосрочни активни транзакции може да помогне за разрешаване на растежа на регистрационните файлове на транзакциите на издател, дистрибутор, абонат или всякакви бази данни.
Групови SQL операции INSERT/UPDATE/DELETE върху статии
С огромни данни, намиращи се в базата данни на Publisher, ние често се оказваме с изисквания за ВМЪКВАНЕ, АКТУАЛИЗИРАНЕ или ИЗТРИВАНЕ на огромни записи в репликирани таблици.
Ако операциите INSERT, или UPDATE, или DELETE се извършват в една транзакция, тя определено ще се окаже в репликацията, блокирана за дълго време.
Да кажем, че трябва да ВМЕСТИм 10 милиона записа в репликирана таблица. Вмъкването на тези записи в един кадър ще доведе до проблеми с производителността.
INSERT INTO REplicated_table
SELECT * FROM Source_table
Вместо това можем да ВМЕСВАМЕ записи в партиди от 0,1 или 0,5 милиона записа за ВРЕМЕ примка или цикл CURSOR , и това ще осигури по-бързо репликация. Може да не получим големи проблеми за операторите INSERT, освен ако иначе включената таблица има много индекси. Това обаче ще има огромен удар в производителността за операторите UPDATE или DELETE.
Да приемем, че сме добавили нова колона към таблицата Replicated, която има около 10 милиона записа. Искаме да актуализираме тази нова колона със стойност по подразбиране.
В идеалния случай командата по-долу ще работи добре за АКТУАЛИЗИРАНЕ на всички 10 милиона записа със стойност по подразбиране като Abc :
-- UPDATE 10 Million records on Replicated Table with some DEFAULT values
UPDATE Replicated_table
SET new_column = 'Abc'
Въпреки това, за да избегнем въздействията върху репликацията, трябва да изпълним горната операция UPDATE в партиди от 0,1 или 0,5 милиона записи, за да избегнем проблеми с производителността.
-- UPDATE in batches to avoid performance impacts on Replication
WHILE 1 = 1
BEGIN
UPDATE TOP(100000) Replicated_Table
SET new_Column = 'Abc'
WHERE new_column is NULL
IF @@ROWCOUNT = 0
BREAK
END
По същия начин, ако трябва да ИЗТРИМЕ около 10 милиона записа от репликирана таблица, можем да го направим на партиди:
-- DELETE 10 Million records on Replicated Table with some DEFAULT values
DELETE FROM Replicated_table
-- UPDATE in batches to avoid performance impacts on Replication
WHILE 1 = 1
BEGIN
DELETE TOP(100000) Replicated_Table
IF @@ROWCOUNT = 0
BREAK
END
Ефективното боравене с ОБЯВНОТО ВМЕСВАНЕ, АКТУАЛИЗИРАНЕ или ИЗТРИВАНЕ може да помогне за разрешаването на проблемите с репликацията.
Професионален съвет :За да INSERT огромни данни в репликирана таблица в базата данни на издателя, използвайте съветника IMPORT/EXPORT в SSMS, тъй като той ще вмъква записи в партиди от 10000 или въз основа на размера на записа, изчислен по-бързо от SQL Server.
Огромни промени в данните в рамките на една транзакция
За да се поддържа целостта на данните от гледна точка на приложението или разработката, много приложения имат изрични транзакции, дефинирани за критични операции. Въпреки това, ако много операции (INSERT, UPDATE или DELETE) се изпълняват в рамките на един обхват на транзакция, агентът за четене на журнали първо ще изчака транзакцията да завърши, както видяхме по-рано.
След като транзакцията бъде ангажирана от приложението, агентът за четене на журнали трябва да сканира онези огромни промени в данните, извършени в регистрационните файлове на транзакциите на базата данни на Publisher. По време на това сканиране можем да видим предупрежденията или информационните съобщения в агента за четене на журнали като
Агентът за четене на журнали сканира регистъра на транзакциите за команди, които да бъдат репликирани. Приблизително xxxxxx регистрационните записи са сканирани в проход # xxxx, от които са маркирани за репликация, изминало време xxxxxxxxx (ms)
Преди да идентифицираме решението за този сценарий, трябва да разберем как агентът за четене на журнали сканира записи от регистрационните файлове на транзакциите и вмъква записи в базата данни за разпространение MSrepl_transactions и MSrepl_cmds таблици.
SQL Server вътрешно има регистрационен номер (LSN) в регистрационните файлове на транзакциите. Агентът за четене на журнали използва LSN стойностите, за да сканира промените, маркирани за репликация на SQL Server, по ред.
Агентът за четене на журнали изпълнява sp_replcmds разширена съхранена процедура за извличане на командите, маркирани за репликация, от транзакционните регистрационни файлове на базата данни на издателя.
Sp_replcmds приема входен параметър с име @maxtrans за да получите максимален брой транзакции. Стойността по подразбиране би била 1, което означава, че ще сканира какъвто и да е брой налични транзакции от регистрационните файлове, които да бъдат изпратени до базата данни за разпространение. Ако има 10 операции INSERT, извършени чрез една транзакция и записани в базата данни на издателя, една партида може да съдържа 1 транзакция с 10 команди.
Ако бъдат идентифицирани много транзакции с по-малки команди, агентът за четене на журнали ще комбинира множество транзакции или XACT пореден номер към една партида за репликация. Но се съхранява като различен XACT Последователност номер в MSRepl_transactions маса. Отделни команди, принадлежащи към тази транзакция, ще бъдат уловени в MSRepl_commands таблица.
За да потвърдя нещата, които обсъдихме по-горе, актуализирам ModifiedDate колона на dbo.AWBuildVersion таблица към днешната дата и вижте какво ще се случи:
UPDATE AdventureWorks.dbo.AWBuildVersion
SET ModifiedDate = GETDATE()
Преди да изпълним UPDATE, ние проверяваме записите, присъстващи в MSrepl_commands и MSrepl_transactions таблици:
Сега изпълнете горния скрипт UPDATE и проверете записите, присъстващи в тези 2 таблици:
В MSrepl_transactions беше вмъкнат нов запис с времето UPDATE таблица с близкия entry_time . Проверка на командата на това xact_seqno ще покаже списъка с логически групирани команди с помощта на sp_browsereplcmds процедура.
В монитора за репликация можем да видим един израз UPDATE, заловен под 1 транзакция(и) с 1 команда(и) от издателя към дистрибутора.
И можем да видим, че същата команда се доставя от дистрибутора до абоната за част от секундата разлика. Това показва, че репликацията се случва правилно.
Сега, ако има огромен брой транзакции, комбинирани в едно xact_seqno , можем да видим съобщения като 10 транзакции с 5000 команди са доставени .
Нека проверим това, като изпълним UPDATE на 2 различни таблици едновременно:
Можем да видим два записа за транзакции в MSrepl_transactions таблица, съответстваща на двете операции UPDATE и след това на номер. на записи в тази таблица, съответстващи на бр. на записите, актуализирани.
Резултатът от MSrepl_transactions таблица:
Резултатът от MSrepl_commands таблица:
Забелязахме обаче, че тези 2 транзакции са логически групирани от агента за четене на журнали и се комбинират в една партида като 2 транзакции с 109225 команди.
Но преди това може да видим съобщения като Доставка на репликирани транзакции, точен брой:1, брой на командите 46601 .
Това ще се случи, докато агентът за четене на журнали сканира пълния набор от промени и идентифицира, че 2 транзакции UPDATE са били напълно прочетени от регистрационните файлове на транзакциите.
След като командите бъдат напълно прочетени от регистрационните файлове на транзакциите, виждаме, че 2 транзакции с 109225 команди са доставени от агента Log Reader:
Тъй като агентът за разпространение чака огромна транзакция да бъде репликирана, може да видим съобщение като Delivering Replicated Transactions което показва, че е имало огромна транзакция, която се репликира и трябва да изчакаме да се репликира напълно.
След като се репликира, можем да видим и следното съобщение в Агента за разпространение:
Няколко начина са полезни за разрешаване на тези проблеми.
Начин 1:СЪЗДАЙТЕ нова SQL съхранена процедура
Трябва да създадете нова съхранена процедура и да капсулирате логиката на приложението в нея под обхвата на транзакцията.
След като бъде създадена, добавете тази статия от Съхранената процедура към Репликация и променете свойството на статията Replicate на Изпълнение на съхранената процедура опция.
Това ще помогне да се изпълни статията Съхранена процедура на абоната, вместо да се репликират всички индивидуални промени в данните, които се случват.
Нека прегледаме как Изпълнението на съхранената процедура опцията за репликация намалява натоварването на репликацията. За да направим това, можем да създадем тестова Съхранена процедура, както е показано по-долу:
CREATE procedure test_proc
AS
BEGIN
UPDATE AdventureWorks.dbo.AWBuildVersion
SET ModifiedDate = GETDATE()
UPDATE TOP(10) Production.TransactionHistoryArchive
SET ModifiedDate = GETDATE()
UPDATE TOP(10) Person.Person
SET ModifiedDate = GETDATE()
END
Горната процедура ще АКТУАЛИЗИРА един запис на AWBuildVersion таблица и по 10 записа всеки в Production.TransactionHistoryArchive иЛице.Лице таблици с общо до 21 промени в записа.
След като създадете тази нова процедура както за издателя, така и за абоната, добавете я към репликация. За това щракнете с десния бутон върху Публикация и изберете статията на процедурата за репликация със стандартната Само дефиниция на съхранената процедура опция.
След като приключим, можем да проверим наличните записи в MSrepl_transactions и MSrepl_commands таблици.
Сега нека изпълним процедурата в базата данни на издателя, за да видим колко записа са проследени.
Можем да видим следното в таблиците за разпространение MSrepl_transactions и MSrepl_commands :
Триxact_seqno бяха създадени за три операции UPDATE в MSrepl_transactions таблица и 21 команди бяха вмъкнати в MSrepl_commands таблица.
Отворете Replication Monitor и вижте дали те се изпращат като 3 различни партиди за репликация или една партида с 3 транзакции заедно.
Можем да видим, че триxact_seqno беше консолидиран като единична партида за репликация. Следователно можем да видим, че 3 транзакции с 21 команди са доставени успешно.
Нека премахнем процедурата от репликация и да я добавим обратно с второто Изпълнение на съхранената процедура опция. Сега изпълнете процедурата и вижте как записите се репликират.
Проверката на записи от таблици за разпространение показва следните подробности:
Сега изпълнете процедурата в базата данни на издателя и вижте колко записа се регистрират в таблиците за разпространение. Изпълнението на процедура актуализира 21 записа (1 запис, 10 записа и 10 записа) както по-рано.
Проверката на таблиците за разпространение показва следните данни:
Нека да разгледаме бързо sp_browsereplcmds, за да видим действително получената команда:
Командата е “{call “dbo”.”test_proc” }” който ще се изпълни в базата данни на абонатите.
В монитора за репликация можем да видим, че само 1 транзакция(и) с 1 команда(и) е била доставена чрез репликация:
В нашия тестов случай използвахме процедура само с 21 промени в данните. Ако обаче направим това за сложна процедура, включваща милиони промени, тогава подходът на съхранената процедура с Изпълнение на съхранената процедура опцията ще бъде ефективна за намаляване на натоварването на репликацията.
Трябва да потвърдим този подход, като проверим дали процедурата има логиката да актуализира само един и същ набор от записи в базите данни Publisher и Subscriber. В противен случай това ще създаде проблеми с несъответствието на данните между издателя и абоната.
Начин 2:Конфигуриране на параметри на агент за четене на журнали MaxCmdsInTran, ReadBatchSize и ReadBatchThreshold
MaxCmdsInTran – указва максималния брой команди, които могат да бъдат логически групирани в рамките на транзакция, докато се четат данни от базата данни на транзакциите на издателя и се записват в базата данни за разпространение.
В нашите по-ранни тестове забелязахме, че около 109 225 команди са натрупани в една точна последователност на репликация, което води до лека бавност или латентност. Ако зададем MaxCmdsInTran параметър до 10000, единичнаточна последователност числото ще бъде разделено на 11 точни последователности, водещи до по-бърза доставка на команди от издателя до дистрибутора . Въпреки че тази опция помага да се намали спорът на базата данни за разпространение и да се репликират данните по-бързо от издателя към базата данни на абоната, бъдете внимателни, докато използвате тази опция. В крайна сметка може да достави данните до базата данни на абонатите и да получи достъп до тях от таблиците на базата данни за абонати преди края на първоначалния обхват на транзакцията.
ReadBatchSize – Този параметър може да не е полезен за един сценарий с огромна транзакция. Помага обаче, когато има много и много по-малки транзакции, които се случват в базата данни на издателя.
Ако броят на командите на транзакция е по-малък, агентът за четене на журнали ще комбинира множество промени в един обхват на транзакция на команда за репликация. Размерът на пакета за четене показва колко транзакции могат да бъдат прочетени в дневника на транзакциите, преди да бъдат изпратени промени в базата данни за разпространение. Стойностите могат да бъдат между 500 и 10 000.
ReadBatchThreshold – показва броя на командите, които трябва да бъдат прочетени от регистрационния файл на транзакциите на базата данни на издателя, преди да бъдат изпратени на абоната със стойност по подразбиране 0 за сканиране на пълния регистрационен файл. Въпреки това можем да намалим тази стойност, за да изпращаме данни по-бързо, като я ограничим до 10000 или 100000 команди като това.
Начин 3:Конфигуриране на най-добрите стойности за параметъра SubscriptionStreams
Абонаментни потоци – показва броя на връзките, които агентът за разпространение може да изпълни паралелно, за да извлече данни от базата данни за разпространение и да ги разпространи в базата данни на абонатите. Стойността по подразбиране е 1, което предполага само един поток или връзка от дистрибуцията към базата данни на абонатите. Стойностите могат да бъдат между 1 и 64. Ако се добавят още абонаментни потоци, това може да се окаже в претоварване на CXPACKET (с други думи, паралелизъм). Следователно трябва да внимавате, докато конфигурирате тази опция в Производството.
За да обобщим, опитайте се да избегнете огромното INSERT, UPDATE или DELETE в една транзакция. Ако е невъзможно да се премахнат тези операции, най-добрият вариант би бил да тествате горните начини и да изберете този, който най-добре отговаря на вашите специфични условия.
Блокиране в базата данни за разпространение
Базата данни за разпространение е сърцето на транзакционната репликация на SQL Server и ако не се поддържа правилно, ще има много проблеми с производителността.
За да обобщим всички препоръчани практики за конфигурация на базата данни за разпространение, трябва да гарантираме, че следните конфигурации са направени правилно:
- Файловете с данни на базите данни за разпространение трябва да се поставят на устройства с високи IOPS. Ако базата данни на Publisher ще има много промени в данните, трябва да гарантираме, че базата данни за разпространение е поставена на устройство с високи IOPS. Той непрекъснато ще получава данни от агента Log Reader, изпращайки данни към базата данни на абонатите чрез агента за разпространение. Всички репликирани данни ще се изчистват от базата данни за разпространение на всеки 10 минути чрез задачата за почистване на разпространението.
- Конфигурирайте свойствата на началния размер на файла и Autogrowth на базата данни за разпространение с препоръчителните стойности въз основа на нивата на активност на базата данни на издателя. В противен случай това ще доведе до фрагментиране на данни и регистрационни файлове, което ще доведе до проблеми с производителността.
- Включете бази данни за разпространение в редовните задачи за поддръжка на индекса, конфигурирани на сървърите, където се намира базата данни за разпространение.
- Включете базите данни за разпространение в графика на задачи за пълно архивиране, за да отстраните конкретни проблеми.
- Уверете се, че Почистване на разпространението:разпространение заданието се изпълнява на всеки 10 минути според графика по подразбиране. В противен случай размерът на базата данни за разпространение продължава да се увеличава и води до проблеми с производителността.
Както забелязахме досега, в базата данни за разпространение ключовите таблици са MSrepl_transactions и MSrepl_commands . Записите се вмъкват там от заданието агент за четене на журнали, избрано от заданието на агента за разпространение, приложено към базата данни на абонатите и след това изтрити или изчистени от заданието на агента за почистване на разпространение.
Ако базата данни за разпространение не е конфигурирана правилно, можем да срещнем блокиране на сесии в тези 2 таблици, което ще доведе до проблеми с производителността на репликацията на SQL Server.
Можем да изпълним заявката по-долу във всяка база данни, за да видим блокиращите сесии, налични в текущия екземпляр на SQL Server:
SELECT *
FROM sys.sysprocesses
where blocked > 0
order by waittime desc
Ако горната заявка върне някакви резултати, можем да идентифицираме команди за тези блокирани сесии, като изпълним DBCC INPUTBUFFER(spid) конзолна команда и предприемете съответните действия.
Проблеми, свързани с корупцията
Базата данни на SQL Server използва своя алгоритъм или логика, за да съхранява данни в таблици и да ги съхранява в екстенти или страници. Повреждането на базата данни е процес, при който физическото състояние на свързаните с базата данни файлове/екстенти/страници се променя от нормално в нестабилно състояние или състояние без извличане, което прави извличането на данни по-трудно или невъзможно.
Всички бази данни на SQL Server са предразположени към повреда на базата данни. Причините могат да бъдат:
- Хардуерни повреди като проблеми с диск, съхранение или контролер;
- Неуспехи на ОС на сървъра, като проблеми с корекцията;
- Аварии на захранването, водещи до внезапно изключване на сървърите или неправилно изключване на базата данни.
Ако можем да възстановим или поправим бази данни без загуба на данни, репликацията на SQL Server няма да бъде засегната. Въпреки това, ако има някакви загуби на данни по време на възстановяване или поправка на повредени бази данни, ще започнем да получаваме много проблеми с целостта на данните, които обсъдихме в предишната ни статия.
Повредата може да се случи в различни компоненти, като:
- Повреда на данните/регистрационния файл на издателя
- Повреда на абонатните данни/регистрационния файл
- Повреда на базата данни за разпространение/регистрационния файл
- Msdb Database Data/Log File повреди
Ако получим много проблеми с целостта на данните след отстраняване на проблеми с корупцията, се препоръчва да премахнете напълно репликацията, да коригирате всички проблеми с корупцията в базата данни на издател, абонат или дистрибутор и след това да конфигурирате повторно репликацията, за да я коригирате. Otherwise, data integrity issues will persist and lead to data inconsistency across the Publisher and Subscriber. The time required to fix the Data integrity issues in case of Corrupted databases will be much more compared to configuring Replication from scratch. Hence identify the level of Corruption encountered and take optimal decisions to resolve the Replication issues faster.
Wondering why msdb database corruption can harm Replication? Since msdb database hold all details related to SQL Server Agent Jobs including Replication Agent jobs, any corruption on msdb database will harm Replication. To recover quickly from msdb database corruptions, it is recommended to restore msdb database from the last Full Backup of msdb database. This also signifies the importance of taking Full Backups of all system databases including msdb database.
Заключение
Thanks for successfully going through the final power-packed article about the Performance issues in the SQL Server Transactional Replication. If you have gone through all articles carefully, you should be able to troubleshoot almost any Transactional Replication-based issues and fix them out efficiently.
If you need any further guidance or have any Transactional Replication-related issues in your environment, you can reach out to me for consultation. And if I missed anything essential in this article, you are welcome to point to that in the Comments section.
