Co je zachytávání dat změn (CDC)?
platí pro:
SQL Serverazure SQL Managed Instance
V tomto článku se dozvíte o zachytávání dat změn (CDC), které zaznamenává aktivitu v databázi, když byly změněny tabulky a řádky.
Tento článek vysvětluje, jak CDC funguje s SQL Serverem a službou Azure SQL Managed Instance. Informace o službě Azure SQL Database najdete v tématu CDC se službou Azure SQL Database.
Přehled
Zachytávání dat změn využívá agenta SQL Serveru k protokolování vkládání, aktualizací a odstraňování, ke kterým dochází v tabulce. Díky tomu jsou tyto změny dat snadno přístupné k použití v relačním formátu. K datům sloupců a základním metadatům, která jsou potřeba k aplikaci těchto dat změn v cílovém prostředí, je přistupováno tak, že změněné řádky jsou zachyceny a uloženy v tabulkách změn, které zrcadlí strukturu sloupců sledovaných zdrojových tabulek. Kromě toho jsou tabulkové funkce k dispozici pro systematický přístup ke změnovým datům ze strany spotřebitelů.
Dobrým příkladem příjemce dat, kterého tato technologie cílí, je aplikace pro extrakci, transformaci a načítání (ETL). Aplikace ETL přírůstkově načítá data změn ze zdrojových tabulek SQL Serveru do datového skladu nebo datového tržiště. I když reprezentace zdrojových tabulek v datovém skladu musí odrážet změny ve zdrojových tabulkách, není vhodná kompletní technologie, která aktualizuje repliku zdroje. Místo toho potřebujete spolehlivý datový proud změn, který je strukturovaný, aby je uživatelé mohli použít na odlišné cílové reprezentace dat. Funkce snímání změn dat na SQL Serveru poskytuje tuto technologii.
Tok dat
Následující obrázek znázorňuje hlavní tok dat pro zachytávání dat změn.
Zdrojem dat změn pro zachytávání dat změn je transakční protokol SQL Serveru. Při vkládání, aktualizaci a mazání sledovaných zdrojových tabulek se do protokolu přidávají položky popisující tyto změny. Protokol slouží jako vstup pro proces zachycení. Potom načte protokol a přidá informace o změnách do tabulky změn přidružené ke sledované tabulce. Funkce jsou k dispozici k zobrazení výčtu změn, které se zobrazí v tabulkách změn v zadané oblasti a vrací informace ve formě filtrované sady výsledků. Filtrovaná sada výsledků je obvykle používána procesem aplikace k aktualizaci reprezentace zdroje v některém externím prostředí.
Zachycení instance
Aby bylo možné sledovat změny jednotlivých tabulek v databázi, musí být pro databázi explicitně povolené zachytávání dat změn. To se provádí pomocí uložené procedury sys.sp_cdc_enable_db. Pokud je databáze povolená, lze zdrojové tabulky identifikovat jako sledované tabulky pomocí uložené procedury sys.sp_cdc_enable_table. Pokud je povolena tabulka pro zachytávání dat změn, vytvoří se přidružená instance zachycení, která podporuje šíření dat změn ve zdrojové tabulce. Instance zachycení se skládá z tabulky změn a až dvou funkcí dotazu. Metadata, která popisuje podrobnosti konfigurace instance zachytávání, se uchovávají v metadatových tabulkách pro zachytávání změn cdc.change_tables, cdc.index_columnsa cdc.captured_columns. Tyto informace lze načíst pomocí uložené procedury sys.sp_cdc_help_change_data_capture.
Všechny objekty přidružené k instanci zachycení jsou vytvořeny ve schématu zachycení dat změn povolené databáze. Požadavky na název instance zachycení jsou, že se jedná o platný název objektu a že je jedinečný v instancích zachycení databáze. Ve výchozím nastavení je název <název schématu_název tabulky> zdrojové tabulky. Přidružená tabulka změn je pojmenována připojením _CT k názvu instance zachycení. Funkce, která se používá k dotazování na všechny změny, má název vytvořený připojením fn_cdc_get_all_changes_ k názvu instance zachycení. Pokud je zachytávající instance nakonfigurovaná tak, aby podporovala čisté změny , vytvoří se také funkce dotazu net_changes, která je pojmenována tak, že se před název zachytávající instance připojí fn_cdc_get_net_changes_.
Důležitý
Maximální počet instancí zachycení, které lze souběžně přidružit k jedné zdrojové tabulce, je dva.
Změna tabulky
Prvních pět sloupců tabulky pro zachycení změn dat jsou sloupce metadata. Poskytují další informace, které jsou relevantní pro zaznamenanou změnu. Zbývající sloupce odpovídají zachyceným sloupcům ze zdrojové tabulky v názvu a obvykle v typu. Tyto sloupce obsahují zachycená data sloupců shromážděná ze zdrojové tabulky.
Každá operace vložení nebo odstranění použitá u zdrojové tabulky se zobrazí jako jeden řádek v tabulce změn. Datové sloupce řádku, které jsou výsledkem operace vložení, obsahují hodnoty sloupců za vložením. Datové sloupce řádku, které jsou výsledkem operace odstranění, obsahují hodnoty sloupců před odstraněním. Operace aktualizace vyžaduje, aby jedna položka řádku identifikovala hodnoty sloupců před aktualizací a druhá položka řádku k identifikaci hodnot sloupců po aktualizaci.
Každý řádek v tabulce změn obsahuje také další metadata, která umožňují interpretaci aktivity změn. Sloupec __$start_lsn identifikuje pořadové číslo protokolu potvrzení (LSN), které bylo přiřazeno ke změně. Commit LSN identifikuje změny, které byly potvrzeny ve stejné transakci, a seřadí tyto transakce. Sloupec __$seqval lze použít k seřazení dalších změn, ke kterým dochází ve stejné transakci. Sloupec __$operation zaznamenává operaci přidruženou ke změně: 1 = delete, 2 = insert, 3 = update (před obrázkem) a 4 = update (after image). Sloupec __$update_mask je proměnná bitová maska s jedním definovaným bitem pro každý zachycený sloupec. Pro vložení a odstranění položek má maska aktualizace všechny bity nastavené. Řádky, které budou aktualizovány, však budou mít tyto bity nastavené, které odpovídají změněným sloupcům.
Interval platnosti
Interval platnosti zachytávání dat změn pro databázi je doba, během které jsou data změn k dispozici pro instance zachycení. Interval platnosti začíná při vytvoření první instance zachycení pro tabulku databáze a pokračuje v současné době.
Databáze
Data, která jsou uložena v tabulkách změn, rostou nekontrolovaně, pokud data pravidelně a systematicky nevyřazujete. Proces čištění pro zachycení změn dat je zodpovědný za vynucování politiky čištění založené na uchovávání. Nejprve přesune nízký koncový bod intervalu platnosti, aby splnilo omezení času. Potom odebere položky tabulky, jejichž platnost vypršela. Ve výchozím nastavení se uchovávají tři dny dat.
Na vyšší úrovni, když proces zachycení potvrdí každou novou dávku dat změn, přidají se nové položky do cdc.lsn_time_mapping pro každou transakci, která má položky v tabulce změn. V tabulce mapování se zachovají jak pořadové číslo protokolu potvrzení (LSN), tak čas potvrzení transakce (sloupce start_lsn a tran_end_time). Maximální hodnota LSN, která se nachází v cdc.lsn_time_mapping představuje horní značku platnosti okna databáze. Čas odpovídajícího commitu se používá jako základ, ze kterého čisticí proces podle retence vypočítá novou dolní mez.
Vzhledem k tomu, že proces zachycení extrahuje data změn z transakčního protokolu, existuje integrovaná latence mezi časem, kdy se změna potvrdí do zdrojové tabulky, a časem, kdy se tato změna zobrazí v přidružené tabulce změn. I když je tato latence obvykle malá, je nicméně důležité si uvědomit, že data změn nejsou k dispozici, dokud proces zachycení nezpracuje související položky protokolu.
Zachytávání instance
I když je běžné, že se interval platnosti databáze a interval platnosti jednotlivých instancí zachycení shodují, neplatí to vždy. Interval platnosti instance zachycení začíná, když proces zachycení rozpozná tuto instanci a začne logovat přidružené změny do její tabulky změn. V důsledku toho, pokud jsou instance zachycení vytvářeny v různých časech, každá bude mít jiný nízký koncový bod. Sloupec start_lsn v sadě výsledků vrácené funkcí sys.sp_cdc_help_change_data_capture zobrazuje aktuální nízkou mez pro každou definovanou instanci zachycení. Když proces čištění vyčistí položky tabulky změn, upraví hodnoty start_lsn pro všechny instance zachycení tak, aby odrážely novou spodní hranici pro dostupná data změn. Pouze instance, které zachytávají, které mají start_lsn hodnoty, jež jsou aktuálně menší než nová dolní mez, jsou upraveny. Pokud se v průběhu času nevytvořily žádné nové instance zachycení, intervaly platnosti pro všechny jednotlivé instance se budou shodovat s intervalem platnosti databáze.
Interval platnosti je pro uživatele dat změn důležitý, protože interval extrakce žádosti musí být plně pokryt aktuálním intervalem platnosti zachytávání dat změn pro instanci zachycení. Pokud je koncový bod intervalu extrakce nalevo od nízkého koncového bodu intervalu platnosti, může chybět data o změnách kvůli agresivnímu vyčištění. Pokud je vysoký koncový bod intervalu extrakce napravo od koncového bodu doby platnosti, znamená to, že proces zachycení ještě nebyl zpracován v době představované intervalem extrakce a může také chybět data o změnách.
Funkce sys.fn_cdc_get_min_lsn slouží k načtení aktuálního minimálního LSN pro instanci zachycení, zatímco sys.fn_cdc_get_max_lsn slouží k načtení aktuální maximální hodnoty LSN. Pokud zadáte dotaz na data změn, pokud zadaný rozsah LSN neleží v těchto dvou hodnotách LSN, funkce dotazu pro zachytávání dat změn selžou.
Zpracování změn ve zdrojové tabulce
Přizpůsobení změn sloupců ve zdrojových tabulkách, které se sledují, je pro podřízené uživatele obtížné. I když povolení zachytávání dat změn ve zdrojové tabulce nezabrání vzniku takových změn DDL, zachycení dat změn snižuje dopad na uživatele zachováním doručovaných sad výsledků vrácených prostřednictvím rozhraní API, i když se změní struktura sloupců podkladové zdrojové tabulky. Tato pevná struktura sloupců se také odráží v podkladové tabulce změn, ke které mají definované funkce dotazu přístup.
Proces zachycení zodpovědný za naplnění tabulky změn se přizpůsobí tabulce změn s pevnou strukturou sloupců tím, že ignoruje všechny nové sloupce, které nebyly identifikovány pro zachycení, když byla zdrojová tabulka povolena pro zachytávání dat změn. Pokud je sledovaný sloupec zrušen, v následných položkách změn se pro tento sloupec zadají nulové hodnoty. Pokud ale existující sloupec prochází změnou datového typu, tato změna se rozšíří do tabulky změn, aby se zajistilo, že mechanismus zachycení nezavádí ztrátu dat do sledovaných sloupců. Proces zachycení také publikuje všechny zjištěné změny struktury sloupců sledovaných tabulek do tabulky cdc.ddl_history. Spotřebitelé, kteří chtějí být upozorněni na úpravy, které mohou být provedeny v podřízených aplikacích, používají uloženou proceduru sys.sp_cdc_get_ddl_history.
Obvykle i při použití změn DDL na přidruženou zdrojovou tabulku aktuální instance zachycení nadále zachovává svůj tvar. Pro tabulku ale můžete vytvořit druhou instanci zachycení, která odráží novou strukturu sloupců. Tato možnost umožňuje procesu zachytávání provádět změny stejné zdrojové tabulky do dvou různých tabulek změn se dvěma různými strukturami sloupců. Zatímco jedna tabulka změn může pokračovat v podávání aktuálních provozních programů, druhý může řídit vývojové prostředí, které se pokouší začlenit data nového sloupce. Povolení mechanismu zachycení, aby současně naplňoval obě tabulky změn, znamená, že přechod z jedné na druhou lze dosáhnout bez ztráty dat změn. K tomu může dojít, kdykoli se tyto dvě časové osy dat změn překrývají. Při ovlivnění přechodu je možné odebrat zastaralou instanci zachycení.
Důležitý
Maximální počet instancí zachycení, které lze souběžně přidružit k jedné zdrojové tabulce, je dva.
Vztah s agentem čtenáře protokolů
Logika procesu zachytávání dat změn je vložena do uložené procedury sp_replcmds, interní serverová funkce vytvořená jako součást sqlservr.exe a používá se také transakční replikací ke sběru změn z transakčního protokolu. Pokud je u databáze povoleno zachytávání dat změn ve SQL Serveru a v Azure SQL Managed Instance, vytvoříte úlohu zachytávání dat změn agenta SQL Serveru jako prostředek pro vyvolání sp_replcmds. Pokud je k dispozici také replikace, použije se samotná čtečka transakčního protokolu k uspokojení potřeb dat změn pro oba tyto příjemce. Tato strategie výrazně snižuje kolize protokolů, pokud je povolená replikace i zachytávání dat změn pro stejnou databázi.
Přepínání mezi těmito dvěma provozními režimy pro zachytávání dat změn probíhá automaticky, kdykoli dojde ke změně stavu replikace databáze s povoleným zachytáváním dat změn.
Poznámka
V SQL Serveru a ve službě Azure SQL Managed Instance vyžadují obě instance logiky zachytávání spuštěného agenta SQL Serveru, aby se proces spustil.
Hlavní úlohou procesu zachycení je prohledání protokolu a zápis dat sloupců a informací souvisejících s transakcemi do tabulek zachytávání změn dat. Aby se zajistilo transakčně konzistentní hranice napříč všemi tabulkami změn, které proces zachycuje, proces zachycení otevře a potvrdí svou vlastní transakci v každém skenovacím cyklu. Zjistí, kdy jsou nově povolené tabulky pro zachytávání dat změn, a automaticky je zahrne do sady tabulek, které jsou aktivně sledovány pro položky změn v protokolu. Podobně se zjistí také zakázání zachytávání dat změn, což způsobí odebrání zdrojové tabulky ze sady tabulek, které aktivně monitorují data změn. Po dokončení zpracování části protokolu proces zachycení signalizuje logiku zkrácení protokolu serveru, která tyto informace používá k identifikaci položek protokolu způsobilých ke zkrácení.
Důležitý
Pokud má databáze povolenou funkci sledování změn dat, i když je režim obnovení nastaven na jednoduchý, bod zkracování protokolu nepokročí, dokud proces zachycení neshromáždí všechny změny, které jsou označeny pro zachycení. Pokud proces zachycení není spuštěn a existují změny, které je třeba shromáždit, vykonání CHECKPOINT neomezí protokol.
Proces zachycení slouží také k udržování historie změn DDL ve sledovaných tabulkách. Příkazy DDL přidružené k zachytávání dat změn zaznamenávají záznamy do protokolu transakcí databáze vždy, když je vyřazena databáze s povoleným zachytáváním dat změn nebo tabulka, nebo když jsou do tabulky s povoleným zachytáváním dat změn přidány, upraveny či odebrány sloupce. Tyto položky protokolu se zpracovávají procesem zachycení, který pak publikuje přidružené události DDL do tabulky cdc.ddl_history. Informace o událostech DDL, které ovlivňují sledované tabulky, můžete získat pomocí uložené procedury sys.sp_cdc_get_ddl_history.
Varování
- maxCmdsInTran nebyl navržen tak, aby byl vždy zapnutý. Existuje pro řešení případů, kdy někdo omylem provedl velký počet operací DML v jedné transakci (což způsobuje zpoždění v distribuci příkazů, dokud celá transakce není v distribuční databázi, zámky, které se uchovávají atd.). Pokud do této situace běžně spadáte, projděte si logiku aplikace a vyhledejte způsoby, jak zmenšit velikost transakce.
- MaxCmdsInTran se nepodporuje, pokud má daná publikační databáze povolené CDC i replikaci. Použití MaxCmdsInTran v této konfiguraci může vést ke ztrátě dat v tabulkách změn CDC. Může také způsobit chyby PK, pokud MaxCmdsInTran parametr je přidán a odebrán při replikaci velké transakce.
Úlohy agenta
Dvě úlohy agenta SQL Serveru jsou obvykle přidružené k databázi s povoleným zachytáváním dat změn: druhou, která se používá k naplnění tabulek změn databáze a jedna, která je zodpovědná za vyčištění tabulky změn. Obě úlohy se skládají z jednoho kroku, který spouští příkaz Transact-SQL. Transact-SQL příkaz, který je vyvolán, je uložená procedura definující záznam změn dat, která implementuje logiku úlohy. Úlohy se vytvoří, když je povolená první tabulka databáze pro zachytávání dat změn. Úloha vyčištění je vždy vytvořena. Úloha zachycení bude vytvořena pouze v případě, že pro databázi nejsou definovány žádné transakční publikace. Úloha zachytávání se také vytvoří, když je pro databázi povolená zachytávání dat změn i transakční replikace a úloha čtečky transakčních protokolů se odebere, protože databáze už nedefinovala publikace.
Úlohy zachytávání a čištění se vytvářejí pomocí výchozích parametrů. Úloha zachycení se spustí okamžitě. Běží nepřetržitě a zpracovává maximálně 1 000 transakcí na cyklus skenování s čekáním 5 sekund mezi cykly. Úloha vyčištění se spouští každý den v 2:00. Uchovává položky tabulky po dobu 4320 minut nebo 3 dny a odebere maximálně 5 000 položek pomocí jediného příkazu delete.
Úlohy agenta pro zachytávání dat změn se odeberou, když je pro databázi zakázaná zachytávání dat změn. Úlohu zachytávání je možné odebrat, když je přidána první publikace do databáze a jsou povoleny zachytávání změn dat i transakční replikace.
Interně se úlohy agenta zachytávání dat změn vytvářejí a ruší pomocí uložených procedur sys.sp_cdc_add_job a sys.sp_cdc_drop_job. Tyto uložené procedury jsou také zpřístupněny, aby správci mohli řídit vytváření a odebírání těchto úloh.
Správce nemá žádnou explicitní kontrolu nad výchozí konfigurací úloh agenta pro zachytávání dat změn. Uložená procedura sys.sp_cdc_change_job je k dispozici, aby bylo možné upravit výchozí konfigurační parametry. Kromě toho uložená procedura sys.sp_cdc_help_jobs umožňuje zobrazit aktuální konfigurační parametry. Úloha zachycení i úloha vyčištění extrahuje parametry konfigurace z tabulky msdb.dbo.cdc_jobs při spuštění. Všechny změny těchto hodnot pomocí sys.sp_cdc_change_job se neprojeví, dokud se úloha nezastaví a restartuje.
K dispozici jsou dvě další uložené procedury, které umožňují spuštění a zastavení úloh agenta zachycení dat změn: sys.sp_cdc_start_job a sys.sp_cdc_stop_job.
Poznámka
Spuštění a zastavení úlohy zachytávání nemá za následek ztrátu dat změn. Brání jen procesu zachycení, aby aktivně neprohledával protokol pro položky změn, které se mají uložit do tabulek změn. Rozumnou strategií, jak zabránit kontrole protokolů v přidávání zatížení během období špičky poptávky, je zastavit úlohu zachycení a restartovat ji, když se poptávka sníží.
Obě úlohy agenta SQL Serveru byly navrženy tak, aby byly dostatečně flexibilní a dostatečně konfigurovatelné tak, aby splňovaly základní potřeby prostředí pro zachytávání dat změn. V obou případech však byly zpřístupněny základní uložené procedury, které poskytují základní funkce, aby bylo možné další přizpůsobení.
Záznam dat změn nemůže správně fungovat, pokud je služba databázového stroje nebo služba agenta SQL Serveru spuštěná pod účtem NETWORK SERVICE. Výsledkem může být chyba 22832.
Interoperabilita s dalšími funkcemi
Zachytávání dat změn má určitá omezení při práci s jinými funkcemi SQL Serveru. Prostudujte Interoperabilita, abyste se dozvěděli více.
Známé problémy
V případě známých problémů a chyb souvisejících se zachytáváním dat změn si projděte známé problémy sCDC .