The Transaction Log (SQL Server) (Dansk)

• 10/23/2019
• 11 minutes to read
• • M
  • D
  • f
  • M
  • s
  • +8

Applies to: SQL Server (all supported versions)

Every SQL Server database has a transaction log that records all transactions and the database modifications made by each transaction.,

transaktionsloggen er en kritisk komponent i databasen. Hvis der er en systemfejl, skal du bruge denne log for at bringe din database tilbage til en konsistent tilstand.

for oplysninger om transaktionslogarkitekturen og internals, se s .l Server Transaction Log Architecture and Management Guide.

operationer understøttet af transaktionsloggen

transaktionsloggen understøtter følgende operationer:

• individuel transaktionsgenopretning.Gendannelse af alle ufuldstændige transaktioner, når S .l Server startes.
• rullende en restaureret database, fil, filgruppe, eller side frem til det punkt af fiasko.
• støtte transaktionsreplikation.
• Støtte til høj tilgængelighed og disaster recovery-løsninger: Altid På tilgængelighed grupper, database spejling, og log forsendelse.,

Enkelte transaktion recovery

Hvis en ansøgning emner ROLLBACK erklæring, eller hvis Databasen Motoren opdager en fejl, såsom tab af kommunikation med en klient, log records bruges til at rulle tilbage ændringer, foretaget af en ufuldstændig transaktion.,

Gendannelse af alle ufuldstændige transaktioner når S .l Server startes

Hvis en server fejler, kan databaserne være i en tilstand, hvor nogle ændringer aldrig blev skrevet fra buffercachen til datafilerne, og der kan være nogle ændringer fra ufuldstændige transaktioner i datafilerne. Når en forekomst af S .l Server startes, kører den en gendannelse af hver database. Hver ændring, der er optaget i loggen, som muligvis ikke er skrevet til datafilerne, rulles frem., Hver ufuldstændig transaktion, der findes i transaktionsloggen, rulles derefter tilbage for at sikre, at databasens integritet bevares. For mere information, se oversigt over gendannelse og gendannelse (s .l Server).

rullende en gendannet database, fil, filgruppe eller side frem til fejlpunktet

efter et hard .aretab eller diskfejl, der påvirker databasefilerne, kan du gendanne databasen til fejlpunktet., Du gendanner først den sidste fulde databasebackup og den sidste differentielle databasebackup, og gendanner derefter den efterfølgende sekvens af transaktionslog-sikkerhedskopierne til fejlpunktet.

Når du gendanner hver log-sikkerhedskopi, genanvender databasemotoren alle de ændringer, der er optaget i loggen, for at rulle alle transaktioner fremad. Når den sidste log backup er genoprettet, databasemotoren bruger derefter logoplysningerne til at rulle tilbage alle transaktioner, der ikke var komplette på det tidspunkt. For mere information, se oversigt over gendannelse og gendannelse (s .l Server).,

Støtte-transaktionsreplikering

Log Læser Agent overvåger transaktioner log af hver database, der er konfigureret til transaktionsreplikering og kopier de transaktioner, der er markeret til replikering fra transaction log ind fordelingen database. For mere information, se hvordan Transaktionsreplikation fungerer.

understøttelse af løsninger med høj tilgængelighed og gendannelse af katastrofer

standby-serverløsningerne, altid på tilgængelighedsgrupper, databasespejling og logforsendelse, er stærkt afhængige af transaktionsloggen.,

i et al .ays On availability groups-scenarie gengives hver opdatering til en database, den primære kopi, straks i separate, fulde kopier af databasen, de sekundære kopier. Den primære replika sender hver log record straks til de sekundære replikaer, der anvender de indgående log records til tilgængelighed gruppe databaser, løbende rullende det fremad. For mere information, se Al .ays On Failover Cluster Instances

i et logforsendelsesscenarie sender den primære server den aktive transaktionslog for den primære database til en eller flere destinationer., Hver sekundær server gendanner loggen til sin lokale sekundære database. For mere information, se om Log forsendelse.

i et databasespejlingsscenarie gengives hver opdatering til en database, den primære database, straks i en separat, fuld kopi af databasen, spejldatabasen. Den vigtigste server instans sender hver log rekord straks til spejlet server instans, som anvender de indgående log poster til spejlet database, løbende rullende det fremad. For mere information, se Databasespejling.,

transaktionsjournal egenskaber

Egenskaber af SQL Server-databaseprogrammet transaktionsjournal:

• transaktionsjournal er gennemført som en separat fil eller et sæt filer i databasen. Logcachen administreres separat fra buffercachen for datasider, hvilket resulterer i enkel, hurtig og robust kode i S .l Server-databasemotoren. For mere information, se transaktionslog fysisk arkitektur.

• formatet på logoptegnelser og sider er ikke begrænset til at følge formatet på datasider.,

• transaktionsloggen kan implementeres i flere filer. Filerne kan defineres til at udvide automatisk ved at indstille FILEGROWTH værdi for loggen. Dette reducerer potentialet for at løbe tør for plads i transaktionsloggen, samtidig med at den administrative omkostning reduceres. For mere information, se ALTER DATABASE (Transact-s .l) fil og Filegroup muligheder.

• mekanismen til at genbruge pladsen i logfilerne er hurtig og har minimal effekt på transaktionsgennemstrømningen.,

For oplysninger om transaktionslogarkitekturen og internals, se s .l Server Transaction Log Architecture and Management Guide.

transaktionslog trunkering

Log trunkering frigør plads i logfilen til genbrug af transaktionsloggen. Du skal regelmæssigt afkorte din transaktionslog for at forhindre, at den fylder den tildelte plads. Flere faktorer kan forsinke log trunkering, så overvågning log størrelse spørgsmål. Nogle operationer kan logges minimalt for at reducere deres indflydelse på transaktionslogstørrelsen.,

Log trunkering sletter inaktive virtuelle logfiler (VLFs) fra den logiske transaktionslog i en s .l Server-database, hvilket frigør plads i den logiske log til genbrug af den fysiske transaktionslog. Hvis en transaktionslog aldrig afkortes, vil den til sidst udfylde al den diskplads, der er tildelt fysiske logfiler.

for at undgå at løbe tør for plads, medmindre log trunkering er forsinket af en eller anden grund, sker trunkering automatisk efter følgende begivenheder:

• Under den enkle gendannelsesmodel efter et kontrolpunkt.,
• under den fulde gendannelsesmodel eller bulklogget gendannelsesmodel, hvis der er opstået et kontrolpunkt siden den forrige sikkerhedskopi, forekommer trunkering efter en log-sikkerhedskopi (medmindre det kun er en kopi-log-sikkerhedskopi).for mere information, se faktorer, der kan forsinke log trunkering, senere i dette emne.

  Bemærk

  Log trunkering reducerer ikke størrelsen af den fysiske logfil. For at reducere den fysiske størrelse af en fysisk logfil, skal du krympe logfilen. Du kan finde oplysninger om, hvordan størrelsen på den fysiske logfil skrumpes ned, i Administrer størrelsen på transaktionslogfilen.,
  Husk dog faktorer, der kan forsinke log trunkering. Hvis lagerpladsen er påkrævet igen efter en log shrink, transaktionsloggen vil vokse igen og ved at gøre det, indføre ydeevne overhead under log vokse operationer.

  faktorer, der kan forsinke log-trunkering

  Når logposter forbliver aktive i lang tid, forsinkes transaktionslog-trunkering, og transaktionsloggen kan udfyldes, som vi nævnte tidligere i dette lange emne.,

  vigtigt

  Du kan finde oplysninger om, hvordan du reagerer på en fuld transaktionsjournal, i fejlfinding af en fuld transaktionsjournal (s .l Server Error 9002).

  virkelig, Log trunkering kan forsinkes af forskellige årsager. Lær hvad, hvis noget, forhindrer din log trunkering ved at forespørge log_reuse_ .ait og log_reuse_ .ait_desc kolonner af sys.databaser katalog visning. Følgende tabel beskriver værdierne for disse kolonner.,

  log_reuse_wait værdi	log_reuse_wait_desc værdi	Beskrivelse
  0	INTET	i Øjeblikket er der en eller flere genanvendelige virtuelle log-filer (VLFs).
  1	CHECKPOINT	der er ikke sket noget checkpoint siden den sidste log-trunkering, eller lederen af loggen er endnu ikke flyttet ud over en virtuel logfil (VLF). (Alle recovery modeller) dette er en rutinemæssig grund til at forsinke log trunkering., For mere information, se Database Checkpoints (s .l Server).
  2	LOG_BACKUP	en log backup er påkrævet, før transaktionsloggen kan afkortes. (Kun fuld eller bulk-logget gendannelsesmodeller) når den næste log backup er afsluttet, kan nogle log plads blive genanvendelig.
  3	ACTIVE_BACKUP_OR_RESTORE	En data-backup eller restore er i gang (alle recovery-modeller). hvis en data backup forhindrer log trunkering, annullering af backup operation kan hjælpe det umiddelbare problem.,
  4	ACTIVE_TRANSACTION	En transaktion er aktiv (alle recovery-modeller): En langvarig transaktion kan findes i starten af log backup. I dette tilfælde kan frigørelse af pladsen kræve en anden log backup. Bemærk, at langvarige transaktioner forhindrer logafkortning under alle gendannelsesmodeller, inklusive den enkle gendannelsesmodel, hvorunder transaktionsloggen generelt afkortes på hvert automatisk kontrolpunkt. En transaktion udskydes., En udskudt transaktion er faktisk en aktiv transaktion, hvis tilbagekaldelse er blokeret på grund af en utilgængelig ressource. For information om årsagerne til udskudte transaktioner, og hvordan du flytter dem ud af den udskudte tilstand, se udskudte transaktioner (s .l Server).langvarige transaktioner kan også udfylde tempdb ‘ s transaktionslog. Tempdb bruges implicit af brugertransaktioner til interne objekter såsom arbejdstabeller til sortering, arbejdsfiler til hashing, markørarbejdstabeller og rækkeversion., Selv hvis brugertransaktionen kun inkluderer læsedata (SELECT forespørgsler), kan interne objekter oprettes og bruges under brugertransaktioner. Derefter kan tempdb-transaktionsloggen udfyldes.
  5	DATABASE_MIRRORING	Databasespejling er sat på pause, eller under højtydende tilstand ligger spejldatabasen betydeligt bag den primære database. (Kun fuld gendannelsesmodel) For mere information, se Databasespejling (s .l Server).,
  6	REPLIKATION	Under transaktionsrelaterede replikationer, transaktioner, der er relevante for at publikationerne er stadig ikke leverede til distribution database. (Kun fuld gendannelsesmodel) For oplysninger om transaktionsreplikation, se s .l Server Replication.
  7	DATABASE_SNAPSHOT_CREATION	der oprettes et øjebliksbillede af databasen. (Alle recovery modeller) dette er en rutine, og typisk kort, årsag til forsinket log trunkering.
  8	LOG_SCAN	der er en logscanning., (Alle recovery modeller) dette er en rutine, og typisk kort, årsag til forsinket log trunkering.
  9	AVAILABILITY_REPLICA	En sekundær kopi af tilgængelighed gruppe er at anvende transaction log registreringer af denne database, til en tilsvarende sekundær database. (Fuld gendannelsesmodel) For mere information, se oversigt over altid på Tilgængelighedsgrupper (s .l Server).,
  10	–	kun Til intern brug
  11	–	kun Til intern brug
  12	–	Kun til intern brug
  13	OLDEST_PAGE	Hvis en database er konfigureret til at bruge indirekte checkpoints, den ældste side på databasen kan være ældre end checkpoint log sekvens nummer (LSN). I dette tilfælde kan den ældste side forsinke log trunkering. (Alle recovery-modeller) for oplysninger om indirekte checkpoints, se Database Checkpoints (s .l Server).,
  14	OTHER_TRANSIENT	denne værdi anvendes i øjeblikket ikke.
  16	16tp_checkpoint	der skal udføres et OLTP-kontrolpunkt i hukommelsen.For hukommelsesoptimerede tabeller tages et automatisk kontrolpunkt, når transaktionslogfilen bliver større end 1.,5 GB, da den sidste checkpoint (omfatter både disk-baseret og hukommelse-optimeret tabeller) For mere information, se Checkpoint Operation for Hukommelse-Optimeret Tabeller og (https://blogs.msdn.microsoft.com/sqlcat/2016/05/20/logging-and-checkpoint-process-for-memory-optimized-tables-2/)

  Operationer, der kan være minimalt logget

  Minimal logge indebærer logning kun de oplysninger, der er krævet for at gendanne den transaktion, uden at støtte point-in-time recovery., Dette emne identificerer de operationer, der er minimalt logget under bulk-logget recovery model (samt under den simple recovery model, undtagen når en backup kører).

  Bemærk

  Minimal logning understøttes ikke for hukommelsesoptimerede tabeller.

  Bemærk

  under fuld gendannelsesmodellen er alle bulkoperationer fuldt logget. Du kan dog minimere logning for et sæt bulkoperationer ved at skifte databasen til den bulk-loggede gendannelsesmodel midlertidigt til bulkoperationer.,Minimal logning er mere effektiv end fuld logning, og det reducerer muligheden for en storstilet bulkoperation udfylde den tilgængelige transaktion log plads under en bulk transaktion. Men hvis databasen er beskadiget eller tabt, når minimal logning er i kraft, kan du ikke gendanne databasen til fejlpunktet.

  følgende operationer, som er fuldt logget under full recovery-modellen, logges minimalt under den enkle og bulk-loggede recovery-model:

  • Bulk import operations (bcp, BULK INSERT og INSERT… VÆLGE)., For mere information om, hvornår bulk import i en tabel er minimalt logget, se forudsætninger for Minimal Logning i Bulk Import.

  Når transaktionsreplikering er aktiveret, BULK INSERT aktiviteter er fuldt logget selv under Bulk Logget recovery-model.

  • vælg i operationer.

  Når transaktionsreplikering er aktiveret, SELECT INTO aktiviteter er fuldt logget selv under Bulk Logget recovery-model.,

  • delvise opdateringer af datatyper med stor værdi ved hjælp af.WRITE klausul i OPDATERINGSOPGØRELSEN, når du indsætter eller tilføjer nye data. Bemærk, at minimal logning ikke bruges, når eksisterende værdier opdateres. For mere information om datatyper med stor værdi, se datatyper (Transact-s .l).

  • statementsritete .t og UPDATETE .t udsagn, når du indsætter eller tilføjer nye data i kolonnerne tekst, nte .t og billede datatype. Bemærk, at minimal logning ikke bruges, når eksisterende værdier opdateres.,

    Advarsel

    WRITETEXT og UPDATETEXT udsagn er deprecated; undgå at bruge dem i nye applikationer.

  • Hvis databasen er indstillet til den enkle eller bulkloggede gendannelsesmodel, logges nogle inde.DDL-operationer minimalt, uanset om handlingen udføres offline eller online. De minimalt loggede indeksoperationer er som følger:

    • Opret INDEKSOPERATIONER (inklusive indekserede visninger).

    • ALTER inde.REBUILD eller DBCC dbreinde. operationer.,

      advarsel

      DBCC DBREINDEX erklæring er forældet; brug det ikke i nye applikationer.

      Bemærk

      Indeksbygningsoperationer bruger minimial logning, men kan blive forsinket, når der er en samtidig udførelse af backup. Denne forsinkelse skyldes synkroniseringskravene til minimalt loggede bufferpoolsider, når du bruger den enkle eller bulkloggede gendannelsesmodel.

    • DROP inde.ny heapgenbygning (hvis relevant). Indeks side deallocation under enDROP INDEX operation er altid fuldt logget.,n Databasen Er Beskadiget (SQL Server)

    Gendannelse af Transaction Log (Fuld Recovery Model)

    • Gendan en Transaktion Log Backup (SQL Server)

    Se også

    SQL Server Transaktion Log Arkitektur og Management Guide
    Kontrol Transaktion Holdbarhed
    Forudsætninger for Minimal Logføring i Bulk Import
    sikkerhedskopiering og Gendannelse af en SQL Server-Databaser
    Restore og Recovery Oversigt (SQL Server)
    Database Checkpoints (SQL Server)
    få Vist eller Ændre Egenskaberne for en Database
    Recovery Modeller (SQL Server)
    transaktionsjournal Backups (SQL Server)
    sys.,dm_db_log_info (Transact-SQL)
    sys.dm_db_log_space_usage (Transact-SQL)