Megosztás a következőn keresztül:

Mi az a változásadat-rögzítés (CDC)?

A következőkre vonatkozik:SQL ServerFelügyelt Azure SQL-példány

Ebben a cikkben megismerheti a változásadat-rögzítést (CDC), amely táblák és sorok módosításakor rögzíti az adatbázis tevékenységeit.

Ez a cikk bemutatja, hogyan működik a CDC az SQL Serverrel és az Azure SQL Managed Instance szolgáltatással. Az Azure SQL Database esetén lásd: CDC az Azure SQL Database-el.

Áttekintés

Az adatrögzítés az SQL Server-ügynök használatával naplózza a táblákban előforduló beszúrásokat, frissítéseket és törléseket. Így ezek az adatmódosítások könnyen hozzáférhetővé válnak, hogy relációs formátumban könnyen felhasználhatók legyenek. Az oszlopadatoknak és az alapvető metaadatoknak ezeket a módosítási adatokat egy célkörnyezetre kell alkalmazniuk, a rendszer rögzíti a módosított sorokat, és olyan változástáblákban tárolja őket, amelyek tükrözik a követett forrástáblák oszlopszerkezetét. Emellett táblaértékű függvények is rendelkezésre állnak, amelyek rendszeres hozzáférést biztosítanak ezekhez a változásadatokhoz a fogyasztók számára.

Jó példa arra, hogy egy adatfogyasztó ezt a technológiát egy kinyerési, átalakítási és betöltési (ETL) alkalmazásnak szánja. Az ETL-alkalmazások növekményesen töltik be a változásokat az SQL Server-forrástáblákból egy adattárházba vagy adatpiacra. Bár a forrástábláknak az adattárházban való megjelenítésének tükröznie kell a forrástáblák változásait, nem megfelelő egy olyan teljes körű technológia, amely frissíti a forrás replikáját. Ehelyett megbízható változási adatokra van szüksége, amelyek strukturáltak, így a felhasználók alkalmazhatják őket az adatok célmegjelenítéseinek eltérő megjelenítésére. Az SQL Server változásadat-rögzítése biztosítja ezt a technológiát.

Adatfolyam

Az alábbi ábra a változásadat-rögzítés fő adatfolyamát mutatja be.

Adatrögzítési adatfolyam-diagram módosítása.

A változásadatok rögzítésének forrása az SQL Server tranzakciónaplója. Amikor beszúrásokat, frissítéseket és törléseket alkalmaznak a követett forrástáblákra, az ezeket a módosításokat leíró bejegyzések hozzáadódnak a naplóhoz. A napló a rögzítési folyamat bemeneteként szolgál. Ezután beolvassa a naplót, és információkat ad hozzá a nyomon követett táblához társított változástáblához. A függvények a változástáblákban egy megadott tartományon belül megjelenő változások számbavételére szolgálnak, és szűrt eredményhalmaz formájában adják vissza az információkat. A szűrt eredményhalmazt általában egy alkalmazásfolyamat használja a forrás egy külső környezetben való megjelenítésének frissítéséhez.

Példány rögzítése

Ahhoz, hogy az adatbázis egyes tábláinak változásai nyomon követhetők legyenek, a módosítási adatrögzítést explicit módon engedélyezni kell az adatbázis számára. Ez a tárolt eljárás sys.sp_cdc_enable_db használatával történik. Ha az adatbázis engedélyezve van, a forrástáblák nyomon követett táblákként azonosíthatók a tárolt eljárás sys.sp_cdc_enable_table használatával. Ha egy tábla engedélyezve van a változásadat-rögzítéshez, létrejön egy társított rögzítési példány, amely támogatja a változásadatok terjesztését a forrástáblában. A rögzítési példány egy változástáblából és legfeljebb két lekérdezési függvényből áll. A rögzítési példány konfigurációs adatait leíró metaadatok megmaradnak a módosítási adatrögzítés metaadattábláiban cdc.change_tables, cdc.index_columns és cdc.captured_columns. Ezek az információk a tárolt eljárás sys.sp_cdc_help_change_data_capture használatával kérhetők le.

A rögzítési példányhoz társított összes objektum az engedélyezett adatbázis változásadat-rögzítési sémájában jön létre. A rögzítési példány nevének követelményei az, hogy érvényes objektumnév, és egyedi az adatbázis-rögzítési példányok között. Alapértelmezés szerint a név a < forrástábla sémanév_táblaneve>. A hozzá tartozó változástáblát úgy nevezik el, hogy hozzáfűzi a _CT a rögzítési példány nevéhez. Az összes módosítás lekérdezéséhez használt függvényt úgy nevezzük el, hogy a rögzítési példány neve elé illesztjük a fn_cdc_get_all_changes_ előtagot. Ha a rögzítési példány úgy van konfigurálva, hogy támogassa a nettó módosításokat, a net_changes lekérdezési függvény is létrejön és el lesz nevezve a fn_cdc_get_net_changes_ a rögzítési példány nevére való előerősítésével.

Fontos

Az egyetlen forrástáblához egyidejűleg társítható rögzítési példányok maximális száma kettő.

Tábla módosítása

A változásadat-rögzítés változástáblájának első öt oszlopa metaadatoszlop. Ezek a rögzített változás szempontjából releváns további információkat nyújtanak. A fennmaradó oszlopok a forrástábla azonosított rögzített oszlopait tükrözik névben és általában típusban. Ezek az oszlopok a forrástáblából összegyűjtött rögzített oszlopadatokat tartalmazzák.

A forrástáblára alkalmazott minden beszúrási vagy törlési művelet egyetlen sorként jelenik meg a változástáblában. A beszúrási műveletből származó sor adatoszlopai tartalmazzák a beszúrás utáni oszlopértékeket. A törlési műveletből származó sor adatoszlopai tartalmazzák a törlés előtti oszlopértékeket. A frissítési művelethez egysoros bejegyzés szükséges a frissítés előtti oszlopértékek azonosításához, egy második sorbejegyzés pedig a frissítés utáni oszlopértékek azonosításához.

A változástáblák minden sora más metaadatokat is tartalmaz, amelyek lehetővé teszik a változási tevékenység értelmezését. A __$start_lsn oszlop azonosítja a módosításhoz rendelt véglegesítési napló sorszámát (LSN). A véglegesítési LSN azonosítja, és sorrendbe állítja az ugyanazon a tranzakción belül véglegesített módosításokat. A __$seqval oszlop további, ugyanabban a tranzakcióban előforduló módosítások megrendelésére használható. A __$művelet oszlop rögzíti a módosításhoz társított műveletet: 1 = törlés, 2 = beszúrás, 3 = frissítés (kép előtt) és 4 = frissítés (kép után). A __$update_mask oszlop egy változó bitmaszk, amely minden rögzített oszlophoz egy meghatározott bitet biztosít. A beszúráshoz és a bejegyzések törléséhez a frissítési maszkban minden bit be van állítva. A sorok frissítéséhez azonban a módosított oszlopoknak megfelelő bitek lesznek beállítva.

Érvényességi időköz

Az adatbázis adatrögzítési érvényességi időtartama az az idő, amely alatt a változásadatok elérhetők a rögzítési példányokhoz. Az érvényességi időköz akkor kezdődik, amikor az első rögzítési példány létrejön egy adatbázistáblához, és a jelenlegi időpontig tart.

Adatbázis

A változástáblákban elhelyezett adatok kezelhetetlenül megsokasodnak, ha nem rendszeresen és szisztematikusan ritkítja az adatokat. A módosítási adatrögzítési tisztítási folyamat felelős a megőrzési alapú törlési szabályzat kikényszerítéséért. Először áthelyezi az érvényességi időtartam alacsony végpontját az időkorlátozás teljesítéséhez. Ezután eltávolítja a lejárt változástábla-bejegyzéseket. Alapértelmezés szerint három napnyi adat marad meg.

A felső végén, mivel a rögzítési folyamat véglegesíti a módosítási adatok minden új kötegét, a rendszer új bejegyzéseket ad hozzá a cdc.lsn_time_mapping minden olyan tranzakcióhoz, amelynek változástáblázat-bejegyzései vannak. A leképezési táblában a véglegesítési napló sorszáma (LSN) és a tranzakció véglegesítési ideje (start_lsn és tran_end_time oszlop) is megmarad. A cdc.lsn_time_mapping található maximális LSN-érték az adatbázis érvényességi időszakának magas vízjelét jelöli. A megfelelő kötelezettségvállalási időt használják alapként, amelyből a megőrzésen alapuló tisztítás új alacsony határértéket számít ki.

Mivel a rögzítési folyamat a tranzakciónaplóból nyeri ki a változásadatokat, a változás forrástáblában való véglegesítésének időpontja és a módosítás a társított változástáblában való megjelenésének időpontja között beépített késéssel jár. Bár ez a késés általában kicsi, fontos megjegyezni, hogy az adatok módosítása csak akkor érhető el, ha a rögzítési folyamat feldolgozta a kapcsolódó naplóbejegyzéseket.

Példány rögzítése

Bár gyakran előfordul, hogy az adatbázis érvényességi időköze és az egyes rögzítési példányok érvényességi időköze egybeesik, nem mindig igaz. A rögzítési példány érvényességi időköze akkor kezdődik, amikor a rögzítési folyamat felismeri a rögzítési példányt, és elkezdi naplózni a változástáblához kapcsolódó módosításokat. Ennek eredményeképpen, ha a rögzítési példányok különböző időpontokban jönnek létre, mindegyiknek eltérő alacsony végpontja lesz. A sys.sp_cdc_help_change_data_capture által visszaadott eredményhalmaz start_lsn oszlopa az egyes meghatározott rögzítési példányok aktuális alacsony végpontját jeleníti meg. Amikor a törlési folyamat megtisztítja a változástáblák bejegyzéseit, az összes rögzítési példány start_lsn értékeit úgy módosítja, hogy az tükrözze az új alacsony vízjelet az elérhető változásadatokhoz. Csak azok a rögzítési példányok módosulnak, amelyek start_lsn értékekkel rendelkeznek, amelyek jelenleg kisebbek az új alacsony vízjelnél. Idővel, ha nem jönnek létre új rögzítési példányok, az egyes példányok érvényességi időközei általában egybeesnek az adatbázis érvényességi időközével.

Az érvényességi időköz fontos a változásadatok felhasználói számára, mivel a kérések kinyerési időközét teljes mértékben ki kell fednie a rögzítési példány aktuális változásadat-rögzítési érvényességi időközével. Ha a kinyerési időköz alacsony végpontja az érvényességi intervallum alacsony végpontjának bal oldalán található, előfordulhat, hogy az agresszív törlés miatt hiányoznak a változásadatok. Ha a kinyerési időköz magas végpontja az érvényességi időköz magas végpontjának jobb oldalán található, az azt jelzi, hogy a rögzítési folyamatot még nem dolgozták fel a kinyerési időköz által képviselt idő alatt, és előfordulhat, hogy a változásadatok is hiányoznak.

A sys.fn_cdc_get_min_lsn függvény a rögzítési példány aktuális minimális LSN-jének lekérésére szolgál, míg a sys.fn_cdc_get_max_lsn az aktuális maximális LSN-érték lekérésére szolgál. A változásadatok lekérdezésekor, ha a megadott LSN-tartomány nem tartozik a két LSN-érték közé, a változásadat-rögzítési lekérdezési függvények nem működnek.

A forrástábla módosításainak kezelése

A nyomon követett forrástáblák oszlopváltozásainak elhelyezése nehéz problémát jelent az alsóbb rétegbeli felhasználók számára. Bár a változásadat-rögzítés engedélyezése a forrástáblán nem akadályozza meg az ilyen DDL-változások bekövetkezését, a változásadat-rögzítés az API-n keresztül visszaadott eredményhalmazok megőrzésével csökkenti a fogyasztókra gyakorolt hatást, még akkor is, ha a mögöttes forrástábla oszlopszerkezete megváltozik. Ez a rögzített oszlopstruktúra az alapul szolgáló változástáblában is tükröződik, amelyhez a definiált lekérdezési függvények hozzáférnek.

A változástábla feltöltéséért felelős rögzítési folyamat egy rögzített oszlopszerkezet-változástáblát tartalmaz, figyelmen kívül hagyva a rögzítéshez nem azonosított új oszlopokat, amikor a forrástábla engedélyezve lett a változásadatok rögzítéséhez. Ha egy követett oszlopot törölnek, null értékek lesznek megadva az oszlop számára a későbbi módosítási bejegyzésekben. Ha azonban egy meglévő oszlop adattípusa megváltozik, a rendszer a módosítást a változástáblába propagálja annak biztosítása érdekében, hogy a rögzítési mechanizmus ne okozzon adatvesztést a követett oszlopokban. A rögzítési folyamat a nyomon követett táblák oszlopszerkezetének észlelt módosításait is közzéteszi a cdc.ddl_history táblában. Azok a fogyasztók, akik értesítést szeretnének adni az alsóbb rétegbeli alkalmazásokban esetleg szükséges kiigazításokról, alkalmazzák a tárolt eljárást sys.sp_cdc_get_ddl_history.

Az aktuális rögzítési példány általában továbbra is megőrzi az alakját, amikor a DDL-módosításokat alkalmazza a társított forrástáblára. Létrehozhat azonban egy második rögzítési példányt a táblához, amely az új oszlopstruktúrát tükrözi. Ez a beállítás lehetővé teszi, hogy a rögzítési folyamat ugyanazon a forrástáblán két különböző, különböző oszlopstruktúrával rendelkező változástáblát módosítson. Így bár az egyik változástábla továbbra is táplálhatja az aktuális operatív programokat, a második egy olyan fejlesztési környezetet hozhat létre, amely megpróbálja beépíteni az új oszlopadatokat. Ha lehetővé teszi a rögzítési mechanizmus számára, hogy mindkét változástáblát tandemben töltse fel, az azt jelenti, hogy az egyikről a másikra való áttérés a változásadatok elvesztése nélkül is elvégezhető. Ez akkor fordulhat elő, ha a két változásadat-rögzítési idővonal átfedésben van. Amikor a váltás megtörténik, az elavult rögzítési objektum eltávolítható.

Fontos

Az egyetlen forrástáblához egyidejűleg társítható rögzítési példányok maximális száma kettő.

Kapcsolat a naplóolvasó ügynökkel

Az adatrögzítési folyamat logikája beágyazva van a tárolt eljárásba sp_replcmds, amely egy belső kiszolgálói függvény, amely a sqlservr.exe részeként épül fel, és a tranzakciós replikáció is használja a tranzakciós napló módosításainak kinyerésére. Az SQL Serverben és a felügyelt Azure SQL-példányban, ha a módosítási adatrögzítés önállóan engedélyezve van egy adatbázisban, a változásadat-rögzítési SQL Server-ügynök rögzítési feladatát a sp_replcmds meghívásának eszközeként hozza létre. Ha a replikáció is jelen van, a tranzakciós naplóolvasó önmagában a két felhasználó változási adatigényének kielégítésére szolgál. Ez a stratégia jelentősen csökkenti a naplók versengését, ha a replikáció és a módosítási adatrögzítés is engedélyezve van ugyanahhoz az adatbázishoz.

A változásadatok rögzítésére szolgáló két működési mód közötti váltás automatikusan megtörténik, amikor változás történik egy változásadat-rögzítést engedélyező adatbázis replikációs állapotában.

Jegyzet

Az SQL Serverben és a felügyelt Azure SQL-példányban a rögzítési logika mindkét példánya megköveteli az SQL Server Agent futtatását a folyamat végrehajtásához.

A rögzítési folyamat fő feladata a napló beolvasása, valamint az oszlopadatok és a tranzakcióval kapcsolatos információk rögzítése a változásrögzítés tábláiban. Annak érdekében, hogy a tranzakciósan konzisztens határ az általa feltöltött összes változásadat-rögzítési változástáblán keresztül biztosítható legyen, a rögzítési folyamat megnyílik, és minden vizsgálati ciklusban véglegesíti a saját tranzakcióját. Észleli, mikor engedélyezik a táblákat újonnan a változásadatok rögzítésére, és automatikusan belefoglalja őket azok közé a táblák közé, amelyek aktívan vannak figyelve a napló változásbejegyzéseire. Hasonlóképpen, a módosítási adatrögzítés letiltása is észlelhető, így a forrástábla el lesz távolítva a változásadatok aktívan figyelt tábláiból. Ha a napló egy szakaszának feldolgozása befejeződött, a rögzítési folyamat jelzi a kiszolgálói napló csonkítási logikáját, amely ezen információk alapján azonosítja a csonkolásra jogosult naplóbejegyzéseket.

Fontos

Ha egy adatbázis engedélyezve van a változásadat-rögzítéshez, még akkor sem, ha a helyreállítási mód egyszerű helyreállításra van beállítva, a napló csonkolási pontja addig nem halad, amíg a rögzítési folyamat össze nem gyűjti a rögzítésre megjelölt összes módosítást. Ha a rögzítési folyamat nem fut, és módosításokat kell gyűjteni, a CHECKPOINT végrehajtása nem fogja csonkítani a naplót.

A rögzítési folyamat a nyomon követett táblák DDL-módosításainak előzményeit is megőrzi. A módosítási adatrögzítéshez társított DDL-utasítások bejegyzéseket tesznek az adatbázis tranzakciónaplójába, amikor egy módosítási adatrögzítést engedélyező adatbázist vagy táblát elvetnek, vagy egy módosítási adatrögzítéssel kompatibilis tábla oszlopait hozzáadják, módosítják vagy elvetik. Ezeket a naplóbejegyzéseket a rögzítési folyamat dolgozza fel, majd közzéteszi a kapcsolódó DDL-eseményeket a cdc.ddl_history táblában. A nyomon követett táblákat érintő DDL-eseményekről a tárolt eljárás sys.sp_cdc_get_ddl_history segítségével szerezhet be információkat.

Figyelmeztetés

  • A MaxCmdsInTran nem úgy lett kialakítva, hogy mindig be legyen kapcsolva. Létezik olyan esetekre, amikor valaki véletlenül nagy számú DML-műveletet hajtott végre egyetlen tranzakcióban (ami késlelteti a parancsok terjesztését, amíg a teljes tranzakció a terjesztési adatbázisban nem található, zárolások vannak tárolva stb.). Ha rutinszerűen beleesik ebbe a helyzetbe, tekintse át az alkalmazás logikáját, hogy megtalálja a tranzakció méretének csökkentésének módjait.
  • A MaxCmdsInTran nem támogatott, ha az adott közzétételi adatbázis CDC-vel és replikációval is rendelkezik. A MaxCmdsInTran használata ebben a konfigurációban adatvesztéshez vezethet a CDC változástábláiban. PK-hibákat is okozhat, ha a MaxCmdsInTran paramétert hozzáadja és eltávolítja egy nagy tranzakció replikálása közben.

Ügynöki feladatok

Két SQL Server Agent-feladat általában egy változásadat-rögzítést engedélyező adatbázishoz van társítva: az egyik az adatbázis-változástáblák feltöltésére szolgál, a másik pedig a változástáblák törléséért felelős. Mindkét feladat egyetlen lépésből áll, amely egy Transact-SQL parancsot futtat. A meghívandó Transact-SQL parancs a feladat logikáját megvalósító, módosítási adatrögzítéssel definiált tárolt eljárás. A feladatok akkor jönnek létre, ha az adatbázis első táblája engedélyezve van a változásadatok rögzítéséhez. A tisztítás feladata mindig létrejön. A rögzítési feladat csak akkor jön létre, ha nincs definiált tranzakciós kiadvány az adatbázishoz. A rögzítési feladat akkor is létrejön, ha a módosítási adatrögzítés és a tranzakciós replikáció is engedélyezve van egy adatbázisban, és a tranzakciónapló-olvasó feladat törlődik, mert az adatbázis már nem rendelkezik meghatározott kiadványokkal.

A rögzítési és a törlési feladatok is alapértelmezett paraméterekkel jönnek létre. A rögzítési feladat azonnal elindul. Folyamatosan fut, a ciklusok közötti 5 másodperces várakozással legfeljebb 1000 tranzakciót dolgoz fel vizsgálati ciklusonként. A tisztítási feladat naponta 14:00-kor fut. A módosítási tábla bejegyzéseit 4320 percig vagy 3 napig őrzi meg, és legfeljebb 5000 bejegyzést távolít el egyetlen törlési utasítással.

A módosítási adatrögzítési ügynök feladatai törlődnek, ha a változásadat-rögzítés le van tiltva egy adatbázis esetében. A rögzítési feladat akkor is eltávolítható, ha az első kiadványt hozzáadják egy adatbázishoz, és mind a változási adatok rögzítése, mind a tranzakciós replikáció engedélyezve van.

Belsőleg az adatrögzítési ügynöki feladatok létrehozása és elvetése a tárolt eljárások sys.sp_cdc_add_job és sys.sp_cdc_drop_job használatával történik. Ezek a tárolt eljárások is elérhetők, így a rendszergazdák szabályozhatják ezeknek a feladatoknak a létrehozását és eltávolítását.

A rendszergazda nem szabályozhatja explicit módon a módosítási adatrögzítési ügynöki feladatok alapértelmezett konfigurációját. A tárolt eljárás sys.sp_cdc_change_job az alapértelmezett konfigurációs paraméterek módosításának engedélyezéséhez van megadva. Emellett a tárolt eljárás sys.sp_cdc_help_jobs lehetővé teszi az aktuális konfigurációs paraméterek megtekintését. A rögzítési feladat és a törlési feladat is kinyeri a konfigurációs paramétereket az indításkor msdb.dbo.cdc_jobs táblából. A sys.sp_cdc_change_job használatával végrehajtott módosítások csak a feladat leállítása és újraindítása után lépnek érvénybe.

Két másik tárolt eljárás is rendelkezésre áll a változásadat-rögzítési ügynök feladatainak elindításához és leállításához: sys.sp_cdc_start_job és sys.sp_cdc_stop_job.

Jegyzet

A rögzítési feladat indítása és leállítása nem eredményezi a változásadatok elvesztését. Csak megakadályozza, hogy a rögzítési folyamat aktívan beolvassa a naplót a változásbejegyzések változástáblákban való elhelyezéséhez. Ésszerű stratégia annak megakadályozására, hogy a naplóvizsgálat terhelést adjon a csúcsidőszakokban, ha leállítja a rögzítési feladatot, és újraindítja azt, amikor az igény csökken.

Mindkét SQL Server Agent-feladatot úgy tervezték, hogy elég rugalmas és megfelelően konfigurálható legyen a változásadat-rögzítési környezetek alapvető igényeinek megfelelően. Mindkét esetben azonban a mögöttes tárolt eljárások, amelyek biztosítják az alapvető funkciókat, elérhetővé lettek téve, hogy a további testreszabás lehetséges legyen.

Az adatrögzítés nem működik megfelelően, ha az Adatbázismotor szolgáltatás vagy az SQL Server Agent szolgáltatás a NETWORK SERVICE-fiók alatt fut. Ez a 22832-s hibát eredményezheti.

Együttműködés más funkciókkal

Az adatrögzítés módosítása bizonyos korlátozásokkal rendelkezik más SQL Server-funkciók használatakor. További információért tekintse át az együttműködési képességet .

Ismert problémák

A változásadat-rögzítéssel kapcsolatos ismert problémákért és hibákért tekintse át a CDC ismert problémáit.

Lásd még:

  • Last updated on