Change tracking for Tim Mitchell Server er en fleksibel og nem at bruge teknologi til overvågning af tabeller for indsatser, opdateringer og sletter. I dette indlæg, Jeg vil diskutere at komme i gang med ændring sporing i
ændring af sporing i server
ændring af sporing er en letvægtsmekanisme til sporing af, hvilke rækker der er indsat, opdateret og slettet i tabeller, der overvåges af ændring af sporing. Change tracking dukkede først op i Server 2008 og har været i alle versioner siden. Endnu bedre, change tracking er tilgængelig i hver udgave af
i en nøddeskal, Sådan fungerer det: I tabeller, der har aktiveret ændringssporing, spores nettoændringen til hver række internt og er tilgængelig via ændringssporingsfunktioner. Hver ændring har et version-ID knyttet til det, og der vil være et nyt version-ID for hver række, der indsættes, opdateres eller slettes. Ændringssporingsversionen er et 8-byte heltal (BIGINT), der afspejler det seneste ændrings-ID i databasen. Det er vigtigt at bemærke, at ændringssporingsversionen ikke er tabelspecifik – en DML-handling i en sporet tabel i hver database øger versionsnummeret. Versionsnummeret vil altid være sekventielt, men vil ikke nødvendigvis være sammenhængende i en enkelt tabel, hvis der er mere end en tabel aktiveret til ændringssporing.
Skift sporing er aktiveret på databaseniveau. Derefter skal hver tabel, der overvåges, indrulleres individuelt i ændringssporing. Hver tabel, der skal overvåges af ændringssporing, skal have en primær nøgle, da dette er den rækkeniveauidentifikator, der bruges til at rapportere om DML-operationer inden for ændringssporing. Når du aktiverer ændringssporing på tabelniveau, kan du vælge at spore de(n) kolonne (er), der er ændret i den seneste opdatering, hvilket giver dig større synlighed over, hvad der blev ændret.
når du er konfigureret, er det en relativt enkel proces at bruge ændringssporing. Der er et par funktioner – især CHANGE_TRACKING_CURRENT_VERSION() og CHANGETABLE (), der kan bruges til at kontrollere den aktuelle version stempel I change tracking og hente listen over de seneste ændringer. Jeg vil demonstrere begge disse funktioner om kort tid.
ændringssporing er ikke Revisionslogning
jeg vil være forsigtig med ikke at bruge ordene revision eller logning til at beskrive ændringssporing. Lad mig være klar: Dette er ikke en fuld logning mekanisme. Ændringshistorikken spores slet ikke-ændringssporing rapporterer kun, at der er sket en ændring, men bevarer ikke versionshistorikken. Overvej tilfældet med en række data med et ID på 1234. Denne række indsættes, opdateres derefter 5 gange og slettes derefter. Ændring sporing ville ikke vise historie indsætte, opdatere og slette; det ville snarere kun rapportere nettoændringen, at række ID 1234 blev slettet. Hvis din belastningsproces kræver detaljeret logningshistorik for hver ændring (snarere end blot deltaet for alle ændringer), skal du bruge noget som change data capture.
opsætning af ændringssporing i server
aktivering af sporing af ændring af tabelniveau er en totrinsproces. For det første skal det være aktiveret på databasen. Dette kan gøres via brugergrænsefladen i Databaseegenskaberne under fanen Skift sporing.
som vist er der ikke meget at konfigurere, når du aktiverer ændringssporing i en database. Du skal blot indstille Ændringssporingsværdien til sand for at konfigurere ændringssporing for den pågældende database. Eventuelt kan værdien af opbevaringsperioden også justeres. Standardværdien er 2 dage, som jeg har tilsidesat i dette eksempel for at bruge 14 dage i stedet. Som med de fleste UI-operationer er der en T-HC-kommando til at gøre det samme. Kommandoen til at konfigurere ændringssporing i denne database er nedenfor.
efter dette trin er ændringssporing aktiveret, men det sporer endnu ikke noget. Det skal stadig være aktiveret for hver tabel, der skal spores. Tabellen egenskaber UI gør dette meget nemt.
som vist kan du blot ændre Ændringssporingsværdien til sand aktivere ændringssporing for denne tabel. I dette eksempel valgte jeg også at spore kolonnerne ændret under opdateringer (mere om dette lidt).
det sidste trin ovenfor gentages for hver tabel, der skal spores i ændringssporing. Når ændring sporing er aktiveret, vil eventuelle ændringer (indsætter, opdateringer eller sletter) til denne tabel gemmes i change tracking cache.
opsætning af ændringssporing
i ovenstående eksempel vil jeg indsætte, opdatere og slette nogle data for at demonstrere, hvordan du får adgang til de ændringssporingsdata, der genereres for disse DML-operationer. Til reference er her bordstrukturen.
jeg viste tidligere, hvordan man aktiverer ændringssporing for en enkelt tabel ved hjælp af brugergrænsefladen. Jeg foretrækker at bruge T-CL til denne opgave, da det er lettere at gentage. Aktivering af ændringssporing for den tabel, jeg oprettede ovenfor, kan gøres som vist her:
Husk, at jeg tidligere nævnte, at ændringssporing bruger et version-ID til at spore den aktuelle version af de sporede tabeller. Det version-ID er vores tidslinjemarkør til registrering af ændringer. For at hente denne værdi er der en meget enkel funktion: CHANGE_TRACKING_CURRENT_VERSION(). Det bruges som vist nedenfor.
på mit testsystem er denne værdi 470 (da jeg har kørt flere tests før dette skrives). Dette er udgangspunktet, og eventuelle ændringer fra dette punkt fremad vil udløse et nyt versionsnummer. Jeg vil notere denne værdi og vil nu foretage nogle ændringer i tabellen beskrevet ovenfor. Jeg indsætter en håndfuld rækker for at vise, hvordan ændringssporing viser indsatser.
efter indsættelse af disse seks rækker kontrollerer jeg CHANGE_TRACKING_CURRENT_VERSION () – værdien igen og finder ud af, at værdien nu er 476. Det er blevet øget med 6-en per række indsat, hvilket er hvad jeg ville forvente.
brug af Change Tracking-funktioner
dernæst bruger vi change tracking-funktionen CHANGETABLE() til at vise nettoændringerne på denne tabel.
at bryde dette ned:
- CHANGETABLE er den tabelværdierede systemfunktion, der returnerer listen over ændringer, der er gemt i ændringssporing
- ændringer indikerer, at jeg leder efter ændringerne, da den angivne version
- @ver er den variabel, jeg har konfigureret til at gemme versionsnummeret. CHANGETABLE returnerer alle de resultater, der afspejler ændringer siden denne version. Bemærk at du kan bruge en variabel som jeg gjorde, eller bare passere i et skalært tal (ved hjælp af den bogstavelige 470 her ville have opnået det samme)
når jeg kører koden ovenfor, modtager jeg følgende resultatsæt.
dette fortæller mig versionen af insert og/eller update, handlingen (I, U eller D for insert, update eller delete), kolonnemasken til opdateringsoperationer (mere om dette øjeblik) og den primære nøgle i rækken påvirket af denne ændring. Fordi CHANGETABLE () returnerer en tabel, kunne jeg nemt slutte dette resultat sat tilbage til den oprindelige tabel for at se ændringen operation sammen med de aktuelle data i denne tabel.
dette vil se lidt anderledes ud for en opdateringsoperation. Dernæst udfører jeg en opdateringserklæring, men først vil jeg bemærke den aktuelle version af ændringssporing (som stadig er 476).
nu opdateringserklæringen, som opdaterer to rækker i tabellen:
nu når jeg kører CHANGETABLE () – koden ovenfra ved hjælp af den nyere change tracking-version (476) som udgangspunkt, får jeg et andet resultatsæt:
dette er metadataene for alle ændringerne siden version 476, som kun inkluderer de to rækker, der er opdateret fra OPDATERINGSERKLÆRINGEN ovenfor. Bemærk, at oprettelsesversionen er null, fordi denne ændring var en opdatering, ikke en indsats. Også SYS_CHANGE_COLUMNS-værdien er nu befolket, selvom værdien ikke rigtig viser os, hvad der er ændret (endnu). Dette er et godt tidspunkt at tale om ændringssporingsfunktionen CHANGE_TRACKING_IS_COLUMN_IN_MASK(). Denne funktion kontrollerer, om den angivne kolonne er blevet opdateret siden den seneste version. Dens syntaks er lidt finurlig, men for at kontrollere, om mellemnavnet blev opdateret, ville forespørgslen se sådan ud:
ærligt, Jeg ved ikke, at jeg nogensinde har brugt CHANGE_TRACKING_IS_COLUMN_IN_MASK-funktionen. Det er lidt af en smerte, fordi du skal køre dette for hver kolonne, du vil kontrollere. Det meste af mit arbejde er inden for datalagring, og jeg er løbet ind i få tilfælde, hvor jeg har brug for at vide nøjagtigt, hvilke kolonner der blev opdateret – jeg vil bare vide, om rækken er opdateret. Men for andre scenarier (især i OLTP) kan jeg se behovet for dette.
jeg har vist indlæg og opdateringer. Lad os se på, hvordan en sletning ville se ud. Igen vil jeg notere det aktuelle versionsnummer – 478 – til den næste operation. Jeg sletter nu en række data:
efter at have slettet en række, kører jeg CHANGETABLE() igen for at se, hvilke ændringssporingsrapporter for denne operation.
jeg finder den ene række, jeg slettede i den sidste operation, med SYS_CHANGE_OPERATION indstillet til D (slet):
husk nu, at versionsnummeret gør en forskel her! Versionsnummeret, der overføres til CHANGETABLE (), er udgangspunktet for eventuelle ændringer, der returneres af denne funktion. Gennem denne øvelse har jeg kontrolleret ændringssporingsresultaterne efter hver DML-operation. Jeg kan dog indstille startversionsnummeret til ethvert gyldigt versionsnummer eller blot bruge NULL til at få alle tilgængelige ændringssporingsresultater for den tabel. For at demonstrere sætter jeg værdien tilbage til version 470 – udgangspunktet før opdateringer – for at vise, hvordan den fulde historie ville se ud. Når jeg kører igen CHANGETABLE () ved hjælp af vores oprindelige change tracking version, får jeg følgende:
der er et par forudsigelige nuancer her. Først og fremmest vises rækken, der viser POST-ID på 1 (som var Phoebe Buffay-posten, jeg slettede), simpelthen som en sletningshandling, selvom denne række blev indsat og efterfølgende slettet siden startversionsnummeret. Husk, det er deltaet, der vises – hver operation mod den række bevares ikke i ændringssporing. For ID ‘ er nummereret 2 og 4 – som var de to rækker, som jeg indsatte og efterfølgende opdaterede – viser SYS_CHANGE_OPERATION en indsats, selvom vi opdaterede begge poster efter indsats. Fortællingen er, at SYS_CHANGE_VERSION og SYS_CHANGE_CREATION_VERSION på disse rækker ikke stemmer overens, hvilket indikerer, at den seneste ændring ikke var indsatsen.
konklusion
Change tracking er et simpelt og let middel til at registrere ændringer på serveren. Brug af ændringssporing muliggør nem identifikation af nye, ændrede og slettede data, hvilket eliminerer behovet for brute-force-sammenligninger. I mit næste indlæg vil jeg se på dette fra et ETL-perspektiv og integrere ændringssporing i en ende-til-ende belastningsproces.