The Transaction Log (SQL Server) (Norsk)

  • 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.,

transaksjonen logg er en avgjørende del av databasen. Hvis det er en systemfeil, vil du trenger som logg for å bringe databasen tilbake til en konsistent tilstand.

For mer informasjon om transaksjonen logg arkitektur og innvendige, se SQL Server Transaksjonen Logg Arkitektur og Ledelse Guide.

Advarsel

Aldri sletter eller flytter denne loggen med mindre du fullt ut forstår betydningen av å gjøre det.

Tips

kun Kjente godt poeng fra å begynne å anvende transaksjonen logger seg i løpet av database utvinning er opprettet av sjekkpunkter., For mer informasjon, se Database Sjekkpunkter (SQL Server).

Operasjoner støttes av transaksjonen logg på

transaksjonen logg støtter følgende operasjoner:

  • Enkelte transaksjon recovery.
  • Gjenoppretting av alle ufullstendig transaksjoner når SQL-Serveren er i gang.
  • for å Rulle i en restaurert database, fil, filegroup, eller bla frem til point of failure.
  • Støtte transaksjons-replikasjon.
  • Støtte for høy tilgjengelighet og gjenoppretting etter katastrofe løsninger: Alltid På grupper av tilgjengelighet, database speiling, og logg frakt.,

Enkelte transaksjon recovery

Hvis et program sender en ROLLBACK erklæringen, eller hvis Database Engine oppdager en feil, for eksempel tap av kommunikasjon med en kunde, logg registrerer brukes til å rulle tilbake endringer som har blitt gjort av en ufullstendig transaksjonen.,

Gjenoppretting av alle ufullstendig transaksjoner når SQL-Serveren er i gang

Hvis en server mislykkes, databaser kan være igjen i en tilstand hvor noen modifikasjoner som aldri ble skrevet fra buffer cache for data-filer, og det kan bli noen endringer fra ufullstendig transaksjoner i data-filer. Når en forekomst av SQL Server er i gang, går det som en gjenoppretting av hver database. Alle modifisering registrert i loggen som kanskje ikke har blitt skrevet til datafiler som er rullet fremover., Hver ufullstendig transaksjon som finnes i transaksjonen logg deretter rullet tilbake for å sørge for integriteten av databasen er bevart. For mer informasjon, se Gjenopprette og Oversikt over Gjenoppretting (SQL Server).

Rolling en restaurert database, fil, filegroup, eller bla frem til det punktet av feil

Etter en hardware tap eller disk feil som påvirker database filer, kan du gjenopprette databasen til punktet av hjertesvikt., Du først gjenopprette den siste hele database backup og siste differensial database backup, og deretter gjenopprette den påfølgende sekvensen av transaksjonen logg sikkerhetskopier til point of failure.

Som du gjenopprette hver logg sikkerhetskopiering, databasemotoren reapplies alle endringer registrert i loggen skal rulle frem alle transaksjoner. Når den siste logg backup er gjenopprettet, Database Engine deretter bruker den informasjonen til å rulle tilbake alle transaksjoner som ikke var ferdigstilt på det tidspunktet. For mer informasjon, se Gjenopprette og Oversikt over Gjenoppretting (SQL Server).,

Støtte transaksjonsbaserte replikering

Logg Leser Agent overvåker transaksjonen logg for hver database er konfigurert for transaksjons-replikasjon og kopier de transaksjoner som er merket for replikering fra transaksjonen logg inn distribusjon database. For mer informasjon, se Hvordan Transaksjonsbaserte Replikering Fungerer.

Støtte for høy tilgjengelighet og gjenoppretting etter katastrofe løsninger

standby-server-løsninger, Alltid På grupper av tilgjengelighet, database speiling, og logg levering, stole tungt på transaksjonen logg.,

I et Alltid På grupper av tilgjengelighet scenario, alle oppdateringene til en database, er den primære kopi, er umiddelbart gjengitt i separat, full kopier av databasen, er den sekundære kopier. Den primære kopi sender hver log-posten umiddelbart til videregående kopier, som gjelder innkommende log-poster til tilgjengelighet gruppe databaser, stadig ruller den frem. For mer informasjon, se Alltid På Failover-Klynge Tilfeller

I en logg frakt scenario, er den primære serveren sender den aktive transaksjonen logg av den primære database til en eller flere destinasjoner., Hvert sekundære server gjenoppretter logge seg til sin lokale databaser. For mer informasjon, se Om Log Frakt.

I en database speiling scenario, alle oppdateringene til en database, rektor database, er umiddelbart gjengitt i en egen, full kopi av databasen, speilet database. Rektor server eksempel sender hver log-posten umiddelbart til speilet server-instans, som gjelder innkommende logg poster til speilet database, stadig ruller den frem. For mer informasjon, se Database Speiling.,

Transaksjonen logg egenskaper

Egenskaper av SQL Server-Database Engine transaksjonen logg:

  • transaksjonen logg er implementert som en separat fil eller et sett med filer i databasen. Logg cache håndteres separat fra buffer cache for data-sider, noe som resulterer i en enkelt, raskt og robust kode i SQL Server-Database Motor. For mer informasjon, se Transaksjonen Logg Fysiske Arkitektur.

  • format logg poster og sider er ikke tvunget til å følge formatet for data-sider.,

  • transaksjonen logg kan være implementert i flere filer. Filene kan være definert for å utvide automatisk ved å sette FILEGROWTH verdi for loggen. Dette reduserer potensialet for å gå tom for plass i transaksjonen logg, mens på samme tid redusere administrativ overhead. For mer informasjon, se ENDRE DATABASE (Ta-SQL) – Fil og Filegroup Valg.

  • mekanisme for å bruke plass i logg-filer er rask og har minimal effekt på transaksjonen gjennomstrømning.,

For mer informasjon om transaksjonen logg arkitektur og innvendige, se SQL Server Transaksjonen Logg Arkitektur og Ledelse Guide.

Transaksjonen logg trunkering

Logg trunkering frigjør plass i loggfilen for gjenbruk av transaksjonen logg. Du må regelmessig avkorte transaksjonen logg for å holde den fra å fylle den tildelte plassen. Er det flere faktorer som kan forsinke logg avbrudd, slik overvåking logg størrelsen teller. Enkelte operasjoner kan være minimalt logget inn for å redusere deres innvirkning på transaksjonen logg størrelse.,

Logg trunkering sletter inaktive virtuelle loggfiler (VLFs) fra den logiske transaksjonen logg av en SQL Server-database, for å frigjøre plass i den logiske logg for gjenbruk av Fysiske transaksjonen logg. Hvis en transaksjonslogg er aldri avkortet, det vil etter hvert fylle hele plassen avsatt til fysisk loggfiler.

for Å unngå å gå tom for plass, med mindre logg trunkering er forsinket for noen grunn, avbrudd skjer automatisk etter følgende hendelser:

  • Under enkle recovery-modellen, etter en kontrollpost.,
  • Under full recovery modell eller bulk-logget recovery-modell, hvis du har en checkpoint har skjedd siden forrige sikkerhetskopiering, avbrudd oppstår etter en logg backup (med mindre det er en kopi-bare logg sikkerhetskopiering).

For mer informasjon, se Faktorer som kan forsinke logg trunkering, senere i dette emnet.

Merk

Logg trunkering ikke redusere størrelsen på den fysiske loggfil. For å redusere den fysiske størrelsen på en fysisk logg-fil, må du krympe loggfilen. For informasjon om å krympe størrelsen på den fysiske logg-fil, kan du se Administrere Størrelsen av Transaksjonen Logg-Fil.,
Men, husk Faktorer som kan forsinke logg avbrudd. Hvis lagringsplass som er nødvendig igjen etter en logg krympe, den transaksjonslogg vil vokse igjen, og ved å gjøre det, innføre ytelse overhead under logg vokse operasjoner.

Faktorer som kan forsinke logg trunkering

Når du logger poster forblir aktivt for en lang tid, transaksjonslogg trunkering er forsinket, og transaksjonen logg kan fylle opp, som vi har nevnt tidligere i denne lange emne.,

Viktig

For informasjon om hvordan du skal reagere på en full transaksjonen logg, kan du se Feilsøke en Full transaksjonslogg (SQL Server Feil 9002).

Virkelig, Logg trunkering kan bli forsinket av en rekke årsaker. Lære hva, hvis noe, er det å hindre logg trunkering ved å sende en spørring til log_reuse_wait og log_reuse_wait_desc kolonner av sys.databaser catalog view. Følgende tabell beskriver de verdier av disse kolonnene.,

log_reuse_wait verdi log_reuse_wait_desc verdi Beskrivelse
0 INGENTING det er for Tiden en eller flere gjenbrukbare virtuelle loggfiler (VLFs).
1 CHECKPOINT Nei checkpoint har skjedd siden siste logg avbrudd, eller hodet av loggen har ennå ikke gått utover et virtuelt logg-fil (VLF). (Alle recovery-modeller)
Dette er en vanlig grunn for å utsette logg avbrudd., For mer informasjon, se Database Sjekkpunkter (SQL Server).
2 LOG_BACKUP En logg backup er nødvendig før transaksjonen logg kan bli avkortet. (Full eller bulk-logget recovery-modeller)
Når neste logg backup er fullført, noen logg plass kan bli gjenbrukbare.
3 ACTIVE_BACKUP_OR_RESTORE sikkerhetskopiering eller gjenoppretting er i gang (alle recovery-modeller).
Hvis en data backup er å hindre logg trunkering, avbryte sikkerhetskopieringen kan hjelpe den umiddelbare problemet.,
4 ACTIVE_TRANSACTION En transaksjon, som ikke er aktive (alle recovery modeller):
lang-du kjører transaksjonen kan finnes ved starten av loggen backup. I dette tilfellet, frigjøre plass kan kreve en annen logg backup. Vær oppmerksom på at langvarige transaksjoner hindre logg avbrudd under alle recovery-modeller, inkludert enkle recovery-modell, under hvilke transaksjonslogg er generelt avkortet på hver automatisk sjekkpunkt.
En transaksjon er utsatt., En utsatt transaksjonen er effektivt en aktiv transaksjonen hvis tilbakerulling er blokkert på grunn av noen utilgjengelig ressurs. For informasjon om årsakene til utsatt transaksjoner og hvordan å flytte dem ut av utsatt staten, se Utsatt Transaksjoner (SQL Server).
langvarige transaksjoner kan også fylle opp tempdb er transaksjonslogg. Tempdb brukes implisitt av brukeren transaksjoner for interne objekter, for eksempel arbeid tabeller for sortering, arbeid-filer for nummerering markøren arbeid tabeller og rad versjonskontroll., Selv om brukeren transaksjonen omfatter bare leser data (SELECT søk), interne objekter kan opprettes og brukes under brukeren transaksjoner. Deretter tempdb transaksjonen logg kan være fylt.
5 DATABASE_MIRRORING databasespeiling er satt på pause, eller under high-performance-modus, speilet database ligger betydelig bak de viktigste databasen. (Full recovery-modellen)
For mer informasjon, se Database Speiling (SQL Server).,
6 REPLIKERING Under transaksjonsbaserte gjennomkjøringer, transaksjoner relevante publikasjoner er fortsatt ikke levert til distribusjon database. (Full recovery-modellen)
For mer informasjon om transaksjonsbaserte replikering, se SQL Server-Replikasjon.
7 DATABASE_SNAPSHOT_CREATION En database snapshot blir opprettet. (Alle recovery-modeller)
Dette er en rutine, og vanligvis kort, årsak til forsinket logg avbrudd.
8 LOG_SCAN En logg scan er oppstått., (Alle recovery-modeller)
Dette er en rutine, og vanligvis kort, årsak til forsinket logg avbrudd.
9 AVAILABILITY_REPLICA En ekstra kopi av et tilgjengelighet gruppe søker transaksjonen logg poster av denne databasen til en tilsvarende databaser. (Full gjenoppretting modell)
For mer informasjon, se Oversikt over Alltid På Tilgjengelighet Grupper (SQL Server).,
10 bare For intern bruk
11 bare For intern bruk
12 Bare For intern bruk
13 OLDEST_PAGE Hvis en database er konfigurert til å bruke indirekte sjekkpunkter, den eldste side på databasen kan være eldre enn checkpoint log sequence number (LSN). I dette tilfellet, den eldste side kan forsinke logg avbrudd. (Alle recovery-modeller)
For mer informasjon om indirekte sjekkpunkter, se Database Sjekkpunkter (SQL Server).,
14 OTHER_TRANSIENT Denne verdien er for øyeblikket ikke brukes.
16 XTP_CHECKPOINT En In-Memory OLTP checkpoint trenger å bli utført.For minne-optimalisert tabeller, en automatisk sjekkpunkt er tatt når transaksjonen logg-filen blir større enn 1.,5 GB siden siste sjekkpunkt (inkluderer både disk-basert og minne-optimalisert tabeller)
For mer informasjon se Checkpoint Drift for Minne-Optimalisert Tabeller og (https://blogs.msdn.microsoft.com/sqlcat/2016/05/20/logging-and-checkpoint-process-for-memory-optimized-tables-2/)

Operasjoner som kan være minimalt logget

Minimal logging innebærer å logge kun den informasjon som er nødvendig for å gjenopprette kjøpet uten støtte point-in-time recovery., Dette emnet identifiserer hvilke operasjoner som er minimalt logget under bulk-logget recovery modell (så vel som under den enkle recovery-modellen, bortsett fra når en backup er i gang).

Merk

Minimal logging er ikke støtte for minnekort-optimalisert bord.

Merk

Under full recovery-modell, alle bulk operasjoner er fullt logget. Men du kan minimere logging for et sett av bulk operasjoner ved å bytte database til bulk-logget recovery modell midlertidig for automatisering.,Minimal logging er mer effektiv enn full logging, og det reduserer muligheten for en storstilt bulk drift fylle den tilgjengelige transaksjonen logg plass under en bulk transaksjonen. Imidlertid, hvis databasen er skadet eller gå tapt når minimal logging er aktivert, kan du ikke gjenopprette databasen til punktet av hjertesvikt.

følgende operasjoner, som er fullt logget under full recovery-modell, er minimalt logget under det enkle og bulk-logget recovery modell:

  • Bulk import operasjoner (bcp, BULK SETT, og SETT inn… VELGE)., For mer informasjon om når bulk import inn i en tabell er minimalt logget, se Forutsetninger for Minimal Logging i Bulk Import.

Når transaksjonsbaserte replikering er aktivert, BULK INSERT operasjoner er fullt logget selv under Bulk Logget recovery modell.

  • VELG I driften.

Når transaksjonsbaserte replikering er aktivert, SELECT INTO operasjoner er fullt logget selv under Bulk Logget recovery modell.,

  • Delvis oppdateringer til stor verdi typer data, bruk av .WRITE klausulen i OPPDATERINGEN uttalelse når du setter det inn eller legge til nye data. Vær oppmerksom på at minimal logging er ikke benyttes når eksisterende verdier er oppdatert. For mer informasjon om store verdien data-typer, se Datatyper (Ta-SQL).

  • WRITETEXT og UPDATETEXT uttalelser når du setter det inn eller legge til nye data i tekst, ntext, og image data type-kolonnen. Vær oppmerksom på at minimal logging er ikke benyttes når eksisterende verdier er oppdatert.,

    Advarsel

    WRITETEXT og UPDATETEXT uttalelser er utdatert; unngå å bruke dem i nye programmer.

  • Hvis databasen er satt til enkle eller bulk-logget recovery-modell, noen indeks DDL operasjoner er minimalt logget om operasjon utføres i frakoblet eller tilkoblet. Det minimalt logget indeks operasjoner er som følger:

    • CREATE INDEX operasjoner (inkludert indeksert utsikt).

    • ENDRE INDEKS BYGGE eller DBCC DBREINDEX-operasjoner.,

      Advarsel

      DBCC DBREINDEX uttalelse er ugyldige, Må du ikke bruke det i nye programmer.

      Merk

      Index bygge bruk minimial logging, men kan bli forsinket når det er en samtidig gjennomføre backup. Denne forsinkelsen er forårsaket av synkronisering krav av minimalt logget buffer basseng sider når du bruker enkel eller bulk-logget recovery modell.

    • DROP INDEX nye haugen gjenoppbygge (hvis aktuelt). Indeks side deallocation under en DROP INDEX operasjon er alltid fullt logget.,n Databasen Er Skadet (SQL Server)

    Gjenopprette transaksjonslogg (Full Gjenoppretting Modell)

    • Gjenopprett en transaksjonslogg Backup (SQL Server)

    Se også:

    SQL Server Transaksjonen Logg Arkitektur og Ledelse Guide
    Kontroll Transaksjonen Holdbarhet
    Forutsetninger for Minimal Logging i Bulk Import
    sikkerhetskopiering og Gjenoppretting av SQL Server Databaser
    Gjenopprett og Oversikt over Gjenoppretting (SQL Server)
    Database Sjekkpunkter (SQL Server)
    Vise eller Endre Egenskapene til en Database
    – Recovery-Modeller (SQL Server)
    Transaksjonen Logg Backup (SQL Server)
    sys.,dm_db_log_info (Ta-SQL)
    sys.dm_db_log_space_usage (Ta-SQL)

Leave a Comment