O problémech s transakční replikací SQL Serveru jsme začali mluvit dříve. Nyní budeme pokračovat s několika dalšími praktickými ukázkami, abychom porozuměli často se vyskytujícím problémům s výkonem replikace a jak je správně odstraňovat.
Již jsme diskutovali o problémech, jako jsou problémy s konfigurací, problémy s oprávněními, problémy s připojením a problémy s integritou dat spolu s jejich odstraňováním a opravou. Nyní se zaměříme na různé problémy s výkonem a korupcí ovlivňující replikaci serveru SQL.
Vzhledem k tomu, že problematika korupce je obrovským tématem, budeme diskutovat o jejich dopadech pouze v tomto článku a nebudeme zabíhat do podrobností. Na základě mých zkušeností jsem vybral několik scénářů, které mohou spadat pod problémy s výkonem a korupcí:
- Problémy s výkonem
- Dlouhotrvající aktivní transakce v databázi vydavatele
- Hromadné operace INSERT/UPDATE/DELETE s články
- Velké změny dat v rámci jedné transakce
- Blokování v distribuční databázi
- Problémy související s korupcí
- Poškození databáze vydavatelů
- Poškození distribuční databáze
- Poškození databáze předplatitelů
- Poškození databáze MSDB
Problémy s výkonem
SQL Server Transakční replikace je komplikovaná architektura, která zahrnuje několik parametrů, jako je databáze vydavatele, databáze distributora (distribuce), databáze předplatitelů a několik agentů replikace vykonávaných jako úlohy SQL Server Agent.
Protože jsme všechny tyto položky podrobně probrali v našich předchozích článcích, víme, jak je pro funkci replikace důležitá každá z nich. Cokoli, co má vliv na tyto součásti, může ovlivnit výkon replikace SQL Server.
Například instance databáze Publisher uchovává kritickou databázi se spoustou transakcí za sekundu. Prostředky serveru však mají úzké hrdlo, jako je konzistentní využití CPU nad 90 % nebo využití paměti nad 90 %. Určitě to bude mít dopad na výkon úlohy agenta Log Reader, který čte data změn z transakčních protokolů databáze vydavatele.
Podobně všechny takové scénáře napříč instancemi databáze distributora nebo předplatitele mohou ovlivnit agenta snímku nebo agenta distribuce. Jako správce databází tedy musíte zajistit, aby prostředky serveru, jako je CPU, fyzická paměť a šířka pásma sítě, byly efektivně nakonfigurovány pro instance databáze Publisher, Distributor a Subscriber.
Za předpokladu, že databázové servery Publisher, Subscriber a Distributor jsou správně nakonfigurovány, můžeme mít stále problémy s výkonem replikace, když se setkáme s níže uvedenými scénáři.
Dlouhotrvající aktivní transakce v databázi vydavatelů
Jak název napovídá, dlouhotrvající aktivní transakce ukazují, že existuje volání aplikace nebo uživatelská operace v rámci transakčního rozsahu, která se provádí po dlouhou dobu.
Nalezení dlouhotrvající aktivní transakce znamená, že transakce ještě není potvrzena a může být buď odvolána, nebo potvrzena aplikací. Tím zabráníte oříznutí protokolu transakcí, což povede k tomu, že velikost souboru protokolu transakcí bude neustále narůstat.
Log Reader Agent prohledává všechny potvrzené záznamy, které jsou označeny pro replikaci z transakčních protokolů, v serializovaném pořadí na základě sekvenčního čísla protokolu (LSN), přičemž vynechává všechny ostatní změny, ke kterým dochází u článků, které nejsou replikovány. Pokud příkazy dlouhotrvající aktivní transakce ještě nejsou potvrzeny, replikace přeskočí odesílání těchto příkazů a odešle všechny ostatní potvrzené transakce do distribuční databáze. Jakmile je dlouhotrvající aktivní transakce potvrzena, záznamy budou odeslány do distribuční databáze a do té doby nebude neaktivní část souboru protokolu transakcí databáze Publisher DB vymazána, což způsobí zvětšení velikosti souboru protokolu transakcí aplikace Publisher.
Scénář dlouhotrvající aktivní transakce můžeme otestovat provedením následujících kroků:
Ve výchozím nastavení agent distribuce vyčistí všechny potvrzené změny v databázi odběratelů a zachová poslední záznam pro sledování nových změn na základě sekvenčního čísla protokolu (LSN).
Můžeme provést níže uvedené dotazy a zkontrolovat stav záznamů dostupných v MSRepl_Commands tabulky nebo pomocí sp_browsereplcmds postup v distribuční databázi:
exec sp_browsereplcmds
GO
SELECT * FROM MSrepl_commands
Nyní otevřete nové okno dotazu a spusťte níže uvedený skript, abyste vytvořili dlouhotrvající aktivní transakci na AdventureWorks databáze. Všimněte si, že níže uvedený skript neobsahuje žádné příkazy ROLLBACK nebo COMMIT TRANSACTION. Proto doporučujeme nespouštět tyto druhy příkazů v produkční databázi.
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;
Můžeme ověřit, že tento nový záznam nebyl replikován do databáze odběratelů. Za tímto účelem provedeme příkaz SELECT na Person.ContactType tabulka v databázi odběratelů:
Pojďme ověřit, zda byl výše uvedený příkaz INSERT přečten agentem Log Reader Agent a zapsán do distribuční databáze.
Znovu spusťte skripty z části Krok 1. Výsledky stále ukazují stejný starý stav, což potvrzuje, že záznam nebyl načten z protokolů transakcí databáze vydavatele.
Nyní otevřete Nový dotaz a spusťte níže uvedený skript UPDATE, abyste zjistili, zda agent Log Reader Agent dokázal přeskočit dlouhotrvající aktivní transakci a přečíst změny provedené tímto příkazem UPDATE.
UPDATE AdventureWorks.dbo.AWBuildVersion
SET ModifiedDate = GETDATE()
Zkontrolujte distribuční databázi, zda by agent Log Reader Agent mohl zachytit tuto změnu. Spusťte skript jako součást kroku 1:
Vzhledem k tomu, že výše uvedený příkaz UPDATE byl potvrzen v databázi Publisher, agent Log Reader mohl tuto změnu naskenovat a vložit do databáze distribuce. Následně tuto změnu aplikoval na databázi předplatitelů, jak je uvedeno níže:
INSERT na Person.ContactType budou replikovány do databáze odběratelů pouze po potvrzení transakce INSERT v databázi vydavatele. Než se zavážeme, můžeme rychle zkontrolovat, jak identifikovat dlouhotrvající aktivní transakci, porozumět jí a efektivně ji zpracovat.
Identifikujte dlouhotrvající aktivní transakci
Chcete-li zkontrolovat, zda v jakékoli databázi nejsou dlouhodobě aktivní transakce, otevřete nové okno dotazu a připojte se k příslušné databázi, kterou potřebujeme zkontrolovat. Spusťte DBCC OPENTRAN konzolový příkaz – jedná se o příkaz Database Console pro zobrazení transakcí otevřených v databázi v době provádění.
USE AdventureWorks
GO
DBCC OPENTRAN
Nyní víme, že došlo k SPID (ID procesu serveru ) 69 běží po dlouhou dobu. Ověřte, který příkaz byl u této transakce proveden, pomocí DBCC INPUTBUFFER konzolový příkaz (příkaz Database Console používaný k identifikaci příkazu nebo operace, která probíhá na vybraném ID procesu serveru).
Pro čitelnost zkopíruji EventInfo hodnotu pole a jeho formátování tak, aby zobrazovalo příkaz, který jsme provedli dříve.
Pokud ve vybrané databázi nejsou žádné dlouhodobě aktivní transakce, dostaneme následující zprávu:
Podobně jako u DBCC OPENTRAN konzole, můžeme VYBRAT z DMV s názvem sys.dm_tran_database_transactions získáte podrobnější výsledky (další údaje naleznete v článku MSDN).
Nyní víme, jak identifikovat dlouhodobou transakci. Můžeme potvrdit transakci a podívat se, jak se replikuje příkaz INSERT.
Přejděte do okna, kam jsme vložili záznam do Person.ContactType tabulky v rámci rozsahu transakce a proveďte COMMIT TRANSACTION, jak je uvedeno níže:
Provedení COMMIT TRANSACTION potvrdilo záznam do databáze Publisher. Proto by měl být viditelný v distribuční databázi a databázi předplatitelů:
Pokud jste si všimli, starší záznamy z databáze distribuce byly vyčištěny úlohou Vyčištění agenta distribuce. Nový rekord pro INSERT na Person.ContactType tabulka byla viditelná v MSRepl_cmds tabulka.
Z našeho testování jsme se naučili následující věci:
- Úloha Log Reader Agent SQL Server Transakční replikace bude vyhledávat Committed záznamy pouze z databáze Transakční protokoly vydavatele a INSERT do databáze odběratelů.
- Pořadí změněných dat v databázi vydavatelů zaslaných odběrateli bude založeno na stavu a času v databázi vydavatelů, i když replikovaná data budou mít stejný čas jako v databázi vydavatelů.
- Identifikace dlouhotrvajících aktivních transakcí může pomoci vyřešit nárůst souboru protokolu transakcí vydavatele, distributora nebo předplatitele nebo jakýchkoli databází.
Hromadné operace SQL INSERT/UPDATE/DELETE s články
S obrovskými daty uloženými v databázi Publisher často skončíme s požadavky na INSERT nebo UPDATE nebo DELETE velké záznamy do replikovaných tabulek.
Pokud jsou operace INSERT, UPDATE nebo DELETE provedeny v jedné transakci, určitě skončí na dlouhou dobu uvíznutím replikace.
Řekněme, že potřebujeme VLOŽIT 10 milionů záznamů do replikované tabulky. Vložení těchto záznamů na jeden snímek způsobí problémy s výkonem.
INSERT INTO REplicated_table
SELECT * FROM Source_table
Místo toho můžeme VLOŽIT záznamy v dávkách po 0,1 nebo 0,5 milionu záznamů za WHILE smyčka nebo smyčka CURSOR a zajistí rychlejší replikaci. U příkazů INSERT se nemusí objevit závažné problémy, pokud jinak daná tabulka nemá mnoho indexů. To však bude mít velký zásah do výkonu pro příkazy UPDATE nebo DELETE.
Předpokládejme, že jsme do replikované tabulky přidali nový sloupec, který má přibližně 10 milionů záznamů. Chceme tento nový sloupec aktualizovat na výchozí hodnotu.
V ideálním případě bude níže uvedený příkaz fungovat správně a AKTUALIZUJE všech 10 milionů záznamů s výchozí hodnotou Abc :
-- UPDATE 10 Million records on Replicated Table with some DEFAULT values
UPDATE Replicated_table
SET new_column = 'Abc'
Abychom se však vyhnuli dopadům na replikaci, měli bychom provést výše uvedenou operaci UPDATE v dávkách po 0,1 nebo 0,5 milionu záznamů, abychom se vyhnuli problémům s výkonem.
-- 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
Podobně, pokud potřebujeme ODSTRANIT přibližně 10 milionů záznamů z replikované tabulky, můžeme to udělat v dávkách:
-- 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
Efektivní manipulace s BULK INSERT, UPDATE nebo DELETE může pomoci vyřešit problémy s replikací.
Tip pro profesionály :Chcete-li VLOŽIT velká data do replikované tabulky v databázi Publisher, použijte průvodce IMPORT/EXPORT v SSMS, protože vloží záznamy v dávkách po 10 000 nebo na základě velikosti záznamu rychleji vypočítané SQL Serverem.
Velké změny dat v rámci jedné transakce
Aby byla zachována integrita dat z pohledu aplikace nebo vývoje, mnoho aplikací má pro kritické operace definované explicitní transakce. Pokud se však v rámci jednoho rozsahu transakce provádí mnoho operací (INSERT, UPDATE nebo DELETE), agent Log Reader nejprve počká na dokončení transakce, jak jsme viděli dříve.
Jakmile je transakce potvrzena aplikací, musí agent Log Reader naskenovat ty obrovské změny dat provedené v transakčních protokolech databáze Publisher. Během tohoto skenování můžeme vidět varování nebo informační zprávy v Log Reader Agent jako
Agent Log Reader prohledává transakční protokol a hledá příkazy, které mají být replikovány. V průchodu č. xxxx bylo naskenováno přibližně xxxxxx záznamů protokolu, z nichž xxxx bylo označeno pro replikaci, uplynulý čas xxxxxxxxx (ms)
Než určíme řešení pro tento scénář, musíme porozumět tomu, jak agent Log Reader skenuje záznamy z protokolů transakcí a vkládá záznamy do distribuční databáze MSrepl_transactions a MSrepl_cmds tabulky.
SQL Server má interně Log Sequence Number (LSN) uvnitř Transakční protokoly. Agent Log Reader využívá hodnoty LSN ke skenování změn označených pro replikaci SQL Server v pořadí.
Log Reader Agent spustí sp_replcmds rozšířená uložená procedura pro načtení příkazů označených pro replikaci z databáze Transakční protokoly vydavatele.
Sp_replcmds přijímá vstupní parametr s názvem @maxtrans k načtení maximálního počtu transakcí. Výchozí hodnota by byla 1, což znamená, že bude skenovat jakýkoli počet transakcí dostupných z protokolů, které mají být odeslány do distribuční databáze. Pokud je v databázi vydavatele provedeno 10 operací INSERT provedených prostřednictvím jedné transakce a potvrzených, jedna dávka může obsahovat 1 transakci s 10 příkazy.
Pokud je identifikováno mnoho transakcí s menšími příkazy, agent Log Reader Agent zkombinuje více transakcí nebo XACT pořadové číslo do jedné replikační dávky. Ale ukládá se jako jiný XACT Sekvence číslo v MSRepl_transactions stůl. Jednotlivé příkazy patřící k dané transakci budou zachyceny v MSRepl_commands tabulka.
Abych ověřil, co jsme probrali výše, aktualizuji Datum změny sloupec dbo.AWBuildVersion tabulky k dnešnímu datu a uvidíte, co se stane:
UPDATE AdventureWorks.dbo.AWBuildVersion
SET ModifiedDate = GETDATE()
Před provedením UPDATE ověříme záznamy v MSrepl_commands a MSrepl_transactions tabulky:
Nyní spusťte výše uvedený skript UPDATE a ověřte záznamy v těchto 2 tabulkách:
Do MSrepl_transactions byl vložen nový záznam s časem UPDATE tabulka s blízkým entry_time . Kontrola příkazu na tomto xact_seqno zobrazí seznam logicky seskupených příkazů pomocí sp_browsereplcmds postup.
V Monitoru replikace můžeme vidět jeden příkaz UPDATE zachycený pod 1 transakcí s 1 příkazem od vydavatele k distributorovi.
A vidíme, že stejný příkaz je doručen od distributora k předplatiteli ve zlomku sekundy. Označuje, že replikace probíhá správně.
Nyní, pokud je v jednom xact_seqno spojeno velké množství transakcí , můžeme vidět zprávy jako Bylo doručeno 10 transakcí s 5000 příkazy .
Zkontrolujeme to spuštěním UPDATE na 2 různých stolech současně:
V MSrepl_transactions můžeme vidět dva záznamy transakcí tabulka odpovídající dvěma operacím UPDATE a pak ne. záznamů v této tabulce odpovídajících č. záznamů aktualizováno.
Výsledek zMSrepl_transactions tabulka:
Výsledek z MSrepl_commands tabulka:
Všimli jsme si však, že tyto 2 transakce jsou logicky seskupeny agentem Log Reader Agent a sloučeny do jedné dávky jako 2 transakce s 109225 příkazy.
Předtím však můžeme vidět zprávy jako Doručování replikovaných transakcí, počet xact:1, počet příkazů 46601 .
To se bude dít, dokud agent čtečky protokolů neprohledá kompletní sadu změn a nezjistí, že 2 transakce UPDATE byly plně přečteny z protokolů transakcí.
Jakmile jsou příkazy plně přečteny z transakčních protokolů, vidíme, že 2 transakce s 109225 příkazy byly doručeny agentem Log Reader:
Protože agent distribuce čeká na replikaci velké transakce, můžeme vidět zprávu jako Doručování replikovaných transakcí což naznačuje, že došlo k replikaci obrovské transakce a musíme počkat, až se replikuje úplně.
Po replikaci můžeme vidět níže uvedenou zprávu také v Distribučním agentovi:
Tyto problémy lze vyřešit několika způsoby.
Způsob 1:VYTVOŘTE novou uloženou proceduru SQL
Musíte vytvořit novou uloženou proceduru a zapouzdřit do ní aplikační logiku v rámci Transaction.
Po vytvoření přidejte tento článek uložené procedury do replikace a změňte vlastnost článku replikovat na Provedení uložené procedury možnost.
Pomůže spustit článek Uložená procedura na odběrateli namísto replikace všech jednotlivých změn dat, ke kterým došlo.
Podívejme se, jak provádění uložené procedury volba pro Replikovat snižuje zatížení replikace. K tomu můžeme vytvořit testovací uloženou proceduru, jak je ukázáno níže:
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
Výše uvedený postup AKTUALIZUJE jeden záznam na AWBuildVersion tabulka a 10 záznamů každý v Production.TransactionHistoryArchive a Person.Person tabulky s celkem až 21 změnami záznamů.
Po vytvoření tohoto nového postupu napříč vydavatelem i odběratelem jej přidejte do replikace. Chcete-li to provést, klikněte pravým tlačítkem na Publikace a vyberte článek procedury Replikace s výchozí pouze definicí uložené procedury možnost.
Po dokončení můžeme ověřit záznamy dostupné v MSrepl_transactions a MSrepl_commands tabulky.
Nyní provedeme proceduru v databázi Publisher, abychom viděli, kolik záznamů je vysledováno.
Na distribučních tabulkách MSrepl_transactions můžeme vidět následující a MSrepl_commands :
Tři xact_seqno byly vytvořeny pro tři operace UPDATE v MSrepl_transactions tabulky a 21 příkazů bylo vloženo do MSrepl_commands tabulka.
Otevřete Replication Monitor a zjistěte, zda jsou odesílány jako 3 různé dávky replikace nebo jedna dávka se 3 transakcemi dohromady.
Vidíme, že tři xact_seqno byla konsolidována jako jedna dávka replikace. Můžeme tedy vidět, že byly úspěšně doručeny 3 transakce s 21 příkazy.
Odebereme proceduru z replikace a přidáme ji zpět s druhým provedením uložené procedury volba. Nyní spusťte postup a podívejte se, jak se záznamy replikují.
Kontrola záznamů z distribučních tabulek ukazuje níže uvedené podrobnosti:
Nyní spusťte postup v databázi aplikace Publisher a zjistěte, kolik záznamů se zaznamenává do distribučních tabulek. Provedení procedury aktualizovalo 21 záznamů (1 záznam, 10 záznamů a 10 záznamů) jako dříve.
Ověření distribučních tabulek zobrazuje níže uvedená data:
Pojďme se rychle podívat na sp_browsereplcmds, abychom viděli skutečný přijatý příkaz:
Příkaz je “{call “dbo”.”test_proc” }” který bude spuštěn v databázi předplatitelů.
V Monitoru replikace můžeme vidět, že prostřednictvím replikace byla doručena pouze 1 transakce s 1 příkazem:
V našem testovacím případě jsme použili postup s pouze 21 změnami dat. Pokud to však uděláme pro komplikovanou proceduru zahrnující miliony změn, pak přístup uložená procedura s provedením uložené procedury bude efektivní při snižování zatížení replikace.
Tento přístup musíme ověřit kontrolou, zda má postup logiku k aktualizaci pouze stejné sady záznamů v databázích Publisher a Subscriber. V opačném případě to povede k problémům s nekonzistencí dat mezi vydavatelem a odběratelem.
Způsob 2:Konfigurace parametrů agenta čtečky protokolu MaxCmdsInTran, ReadBatchSize a ReadBatchThreshold Log
MaxCmdsInTran – označuje maximální počet příkazů, které lze logicky seskupit v rámci transakce při čtení dat z databáze Transakční protokoly vydavatele a zapisování do distribuční databáze.
V našich dřívějších testech jsme si všimli, že v jedné přesné sekvenci replikace se nashromáždilo přibližně 109 225 příkazů, což má za následek mírné zpomalení nebo latenci. Pokud nastavíme MaxCmdsInTran parametr na 10000, jedinou sekvenci xact číslo bude rozděleno na 11 xact sekvence vedoucí k rychlejšímu doručování příkazů od vydavatele k distributorovi . I když tato možnost pomáhá snížit spory o distribuční databázi a replikovat data rychleji z vydavatele do databáze odběratelů, buďte při používání této možnosti opatrní. Může to skončit doručením dat do databáze předplatitelů a přístupem k nim z tabulek databáze předplatitelů před koncem původního rozsahu transakce.
ReadBatchSize – Tento parametr nemusí být užitečný pro scénář jedné velké transakce. Pomáhá však, když se v databázi Publisheru odehrává mnoho a mnoho menších transakcí.
Pokud je počet příkazů na transakci menší, agent Log Reader zkombinuje více změn do jednoho rozsahu transakce příkazu Replikace. Velikost dávky čtení udává, kolik transakcí lze přečíst v protokolu transakcí před odesláním změn do distribuční databáze. Hodnoty mohou být mezi 500 a 10 000.
ReadBatchThreshold – označuje počet příkazů, které mají být přečteny z transakčního protokolu databáze vydavatele před odesláním odběrateli, s výchozí hodnotou 0 pro skenování celého souboru protokolu. Tuto hodnotu však můžeme snížit pro rychlejší odesílání dat omezením na 10 000 nebo 100 000 podobných příkazů.
Způsob 3:Konfigurace nejlepších hodnot pro parametr SubscriptionStreams
SubscriptionStreams – označuje počet připojení, která může agent distribuce provést paralelně, aby načetl data z databáze distribuce a rozšířil je do databáze předplatitelů. Výchozí hodnota je 1, což naznačuje pouze jeden datový proud nebo připojení z distribuce k databázi odběratelů. Hodnoty mohou být mezi 1 až 64. Pokud se přidá více streamů odběru, může to skončit zahlcením CXPACKET (jinými slovy paralelismus). Proto byste měli být opatrní při konfiguraci této možnosti v produkci.
Abychom to shrnuli, zkuste se vyhnout obrovskému INSERT, UPDATE nebo DELETE v jedné transakci. Pokud není možné tyto operace odstranit, nejlepší možností by bylo otestovat výše uvedené způsoby a vybrat ten, který nejlépe vyhovuje vašim konkrétním podmínkám.
Blokování v distribuční databázi
Distribuční databáze je srdcem SQL Server Transakční replikace a pokud nebude správně udržována, bude docházet k mnoha problémům s výkonem.
Abychom shrnuli všechny doporučené postupy pro konfiguraci distribuční databáze, musíme se ujistit, že níže uvedené konfigurace jsou provedeny správně:
- Datové soubory distribučních databází by měly být umístěny na disky s vysokým IOPS. Pokud bude databáze Publisher obsahovat mnoho změn dat, musíme zajistit, aby byla distribuční databáze umístěna na jednotce s vysokým IOPS. Průběžně bude přijímat data od agenta Log Reader a odesílat data do databáze předplatitelů prostřednictvím agenta Distribuce. Všechna replikovaná data budou z distribuční databáze vyčištěna každých 10 minut prostřednictvím úlohy čištění distribuce.
- Nakonfigurujte vlastnosti Initial File size a Autogrowth distribuční databáze s doporučenými hodnotami na základě úrovní aktivity databáze Publisher. V opačném případě to povede k fragmentaci dat a souborů protokolu, která způsobí problémy s výkonem.
- Zahrňte distribuční databáze do běžných úloh údržby indexu konfigurovaných na serverech, kde se distribuční databáze nachází.
- Zahrňte distribuční databáze do plánu úloh úplného zálohování, abyste mohli vyřešit jakékoli konkrétní problémy.
- Ujistěte se, že Čištění distribuce:distribuce úloha se spouští každých 10 minut podle výchozího plánu. Jinak se velikost distribuční databáze neustále zvětšuje a vede k problémům s výkonem.
Jak jsme si dosud všimli, v distribuční databázi jsou klíčové tabulky MSrepl_transactions a MSrepl_commands . Záznamy jsou tam vloženy úlohou Log Reader Agent, vybrány úlohou agenta distribuce, aplikovány v databázi odběratelů a poté odstraněny nebo vyčištěny úlohou agenta Distribution Clean-up.
Pokud distribuční databáze není správně nakonfigurována, můžeme se setkat s blokováním relací v těchto 2 tabulkách, což povede k problémům s výkonem replikace SQL Server.
Můžeme provést níže uvedený dotaz v jakékoli databázi a zobrazit blokující relace dostupné v aktuální instanci SQL Server:
SELECT *
FROM sys.sysprocesses
where blocked > 0
order by waittime desc
Pokud výše uvedený dotaz vrátí nějaké výsledky, můžeme identifikovat příkazy na těchto blokovaných relacích provedením DBCC INPUTBUFFER(spid) konzole a podle toho provádějte akce.
Problémy související s korupcí
Databáze SQL Server používá svůj algoritmus nebo logiku k ukládání dat do tabulek a jejich uchovávání v oblastech nebo stránkách. Poškození databáze je proces, při kterém se fyzický stav souborů/rozsahů/stránek souvisejících s databází mění z normálního na nestabilní nebo stav bez obnovení, což ztěžuje nebo znemožňuje získávání dat.
Všechny databáze SQL Server jsou náchylné k poškození databáze. Příčiny mohou být:
- Selhání hardwaru, jako jsou problémy s diskem, úložištěm nebo řadičem;
- Selhání operačního systému serveru, jako jsou problémy s opravami;
- Výpadky napájení vedoucí k náhlému vypnutí serverů nebo nesprávnému vypnutí databáze.
Pokud dokážeme obnovit nebo opravit databáze bez ztráty dat, replikace SQL Server nebude ovlivněna. Pokud však při obnově nebo opravě poškozených databází dojde ke ztrátě dat, začneme dostávat mnoho problémů s integritou dat, o kterých jsme hovořili v našem dřívějším článku.
Korupce se může vyskytovat na různých součástech, například:
- Poškození dat vydavatele/souboru protokolu
- Poškození dat předplatitele/souboru protokolu
- Poškození dat distribuční databáze/souboru protokolu
- Poškození dat/souboru protokolu databáze Msdb
If we receive a lot of data integrity issues after fixing up Corruption issues, it is recommended to remove the Replication completely, fix all Corruption issues in the Publisher, Subscriber, or Distributor database and then reconfigure Replication to fix it. 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.
Závěr
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.