The Transaction Log (SQL Server) (Română)

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

Jurnalul de tranzacții este o componentă critică a bazei de date. Dacă există o defecțiune a sistemului, veți avea nevoie de acel jurnal pentru a readuce baza de date la o stare consistentă.

pentru informații despre arhitectura jurnalului de tranzacții și interne, consultați SQL Server Transaction Log Architecture and Management Guide.

operațiuni acceptate de Jurnalul de tranzacții

Jurnalul de tranzacții acceptă următoarele operații:

• recuperare individuală a tranzacțiilor.
• recuperarea tuturor tranzacțiilor incomplete atunci când SQL Server este pornit.
• rularea unei baze de date restaurate, fișier, grup de fișiere sau pagină înainte până la punctul de eșec.
• sprijinirea replicării tranzacționale.
• sprijinirea disponibilitate ridicată și soluții de recuperare în caz de dezastru: întotdeauna pe grupuri de disponibilitate, oglindirea bazei de date, și log shipping.,

recuperare tranzacție individuală

dacă o aplicație emite o declarație ROLLBACK sau dacă motorul bazei de date detectează o eroare, cum ar fi pierderea comunicării cu un client, înregistrările jurnal sunt folosite pentru a returna modificările efectuate de o tranzacție incompletă.,

recuperarea tuturor tranzacțiilor incomplete când SQL Server este pornit

dacă un server eșuează, bazele de date pot fi lăsate într-o stare în care unele modificări nu au fost scrise niciodată din memoria cache tampon în fișierele de date și pot exista unele modificări din tranzacțiile incomplete din fișierele de date. Atunci când o instanță de SQL Server este pornit, se execută o recuperare a fiecărei baze de date. Fiecare modificare înregistrată în Jurnalul care poate nu au fost scrise la fișierele de date este rulat înainte., Fiecare tranzacție incompletă Găsită în Jurnalul de tranzacții este apoi derulată înapoi pentru a vă asigura că integritatea bazei de date este păstrată. Pentru mai multe informații, consultați Prezentare generală restaurare și recuperare (SQL Server).

rularea unei baze de date restaurate, fișier, grup de fișiere sau pagină înainte la punctul de eșec

după o pierdere hardware sau eșec disc care afectează fișierele bazei de date, puteți restaura baza de date la punctul de eșec., Primul restore la ultimul backup de date și ultimul diferențial de backup de date, și apoi a restabili ulterioară secvența de tranzacție jurnal de backup la punctul de eșec.

pe măsură ce restaurați fiecare copie de rezervă a jurnalului, motorul bazei de date reaplică toate modificările înregistrate în jurnal pentru a transmite toate tranzacțiile. Când este restabilită ultima copie de rezervă a jurnalului, motorul bazei de date utilizează apoi informațiile de jurnal pentru a returna toate tranzacțiile care nu erau complete în acel moment. Pentru mai multe informații, consultați Prezentare generală restaurare și recuperare (SQL Server).,

suportând replicarea tranzacțională

agentul Log Reader monitorizează Jurnalul de tranzacții al fiecărei baze de date configurate pentru replicarea tranzacțională și copiază tranzacțiile marcate pentru replicare din jurnalul de tranzacții în baza de date de distribuție. Pentru mai multe informații, consultați Cum funcționează replicarea tranzacțională.

sprijinirea disponibilitate ridicată și soluții de recuperare în caz de dezastru

soluțiile standby-server, întotdeauna pe grupuri de disponibilitate, oglindirea bazei de date, și log shipping, se bazează foarte mult pe jurnalul de tranzacții.,

într-un scenariu Always on availability groups, fiecare actualizare a unei baze de date, Replica primară, este reprodusă imediat în copii separate, complete ale bazei de date, replicile secundare. Replica primară trimite fiecare înregistrare jurnal imediat la replicile secundare, care se aplică înregistrările jurnal de intrare la bazele de date de grup disponibilitate, continuu de rulare-l înainte. Pentru mai multe informații, consultați întotdeauna instanțe cluster Failover

într-un scenariu de expediere jurnal, serverul principal trimite jurnalul de tranzacții activ al bazei de date primare la una sau mai multe destinații., Fiecare server secundar restabilește Jurnalul la baza de date secundară locală. Pentru mai multe informații, consultați Despre transportul Jurnalului.

într-un scenariu de oglindire a bazei de date, fiecare actualizare a unei baze de date, Baza de date principală, este reprodusă imediat într-o copie separată, completă a bazei de date, Baza de date oglindă. Instanța principală Server trimite fiecare înregistrare jurnal imediat la instanța server oglindă, care se aplică înregistrările jurnal de intrare la baza de date oglindă, continuu de rulare-l înainte. Pentru mai multe informații, consultați oglindirea bazei de date.,

caracteristicile Jurnalului de tranzacții

caracteristicile Jurnalului de tranzacții al motorului bazei de date SQL Server:

• Jurnalul de tranzacții este implementat ca fișier separat sau set de fișiere în baza de date. Cache-ul Jurnal este gestionat separat de cache-ul tampon pentru paginile de date, ceea ce are ca rezultat un cod simplu, rapid și robust în motorul bazei de date SQL Server. Pentru mai multe informații, consultați arhitectura fizică a Jurnalului de tranzacții.formatul înregistrărilor de jurnal și al paginilor nu este constrâns să urmeze formatul paginilor de date.,Jurnalul de tranzacții poate fi implementat în mai multe fișiere. Fișierele pot fi definite pentru a se extinde automat prin setarea valorii FILEGROWTH pentru jurnal. Acest lucru reduce potențialul de a rămâne fără spațiu în Jurnalul de tranzacții, reducând în același timp cheltuielile administrative. Pentru mai multe informații, consultați opțiunile ALTER DATABASE (Transact-SQL) file și Filegroup.mecanismul de reutilizare a spațiului din fișierele jurnal este rapid și are un efect minim asupra tranzitului tranzacției.,

Pentru informații despre arhitectura jurnalului de tranzacții și interne, consultați SQL Server Transaction Log Architecture and Management Guide.

trunchierea Jurnalului de tranzacții

trunchierea Jurnalului eliberează spațiu în fișierul jurnal pentru reutilizare de către Jurnalul de tranzacții. Trebuie să trunchiați în mod regulat Jurnalul de tranzacții pentru a nu umple spațiul alocat. Mai mulți factori pot întârzia trunchierea jurnalului, astfel încât monitorizarea dimensiunii jurnalului contează. Unele operațiuni pot fi înregistrate minim pentru a reduce impactul lor asupra dimensiunii jurnalului de tranzacții.,

trunchierea Jurnalului șterge fișierele jurnal virtuale inactive (VLFs) din jurnalul de tranzacții logice al unei baze de date SQL Server, eliberând spațiu în Jurnalul logic pentru reutilizare de către Jurnalul de tranzacții fizice. Dacă un jurnal de tranzacții nu este niciodată trunchiat, acesta va umple în cele din urmă tot spațiul de disc alocat fișierelor jurnal fizice.pentru a evita epuizarea spațiului, cu excepția cazului în care trunchierea jurnalului este întârziată din anumite motive, trunchierea are loc automat după următoarele evenimente:

• sub modelul simplu de recuperare, după un checkpoint.,
• sub modelul de recuperare completă sau modelul de recuperare înregistrat în bloc, dacă a apărut un checkpoint de la backupul anterior, trunchierea are loc după o copie de rezervă a jurnalului (cu excepția cazului în care este o copie de rezervă a jurnalului numai pentru copiere).

Pentru mai multe informații, consultați factorii care pot întârzia trunchierea jurnalului, mai târziu în acest subiect.

factori care pot întârzia trunchierea jurnalului

când înregistrările jurnalului rămân active mult timp, trunchierea jurnalului de tranzacții este întârziată, iar jurnalul de tranzacții se poate umple, așa cum am menționat anterior în acest subiect lung.,pentru informații despre cum să răspundeți la un jurnal complet de tranzacții, consultați Depanarea unui jurnal complet de tranzacții (SQL Server Error 9002).într-adevăr, trunchierea jurnalului poate fi întârziată dintr-o varietate de motive. Aflați ce, dacă ceva, împiedică trunchierea jurnalului dvs. prin interogarea coloanelor log_reuse_wait și log_reuse_wait_desc ale sys.vizualizare catalog baze de date. Următorul tabel descrie valorile acestor coloane.,

log_reuse_wait valoare	log_reuse_wait_desc valoare	Descriere
0	NIMIC	în Prezent, există una sau mai multe reutilizabile fișiere jurnal virtuale (VLFs).
1	punct de control	niciun punct de control nu a avut loc de la ultima trunchiere a jurnalului sau capul jurnalului nu a trecut încă dincolo de un fișier jurnal virtual (VLF). (Toate modelele de recuperare) acesta este un motiv de rutină pentru întârzierea trunchierii jurnalului., Pentru mai multe informații, consultați punctele de control ale bazei de date (SQL Server).
2	LOG_BACKUP	este necesară o copie de rezervă a jurnalului înainte ca Jurnalul de tranzacții să poată fi trunchiat. (Numai Modele de recuperare înregistrate integral sau în bloc) când următoarea copie de rezervă a jurnalului este finalizată, un anumit spațiu de jurnal ar putea deveni reutilizabil.
3	ACTIVE_BACKUP_OR_RESTORE	o copie de rezervă de date sau o restaurare este în curs de desfășurare (Toate modelele de recuperare). dacă o copie de rezervă a datelor împiedică trunchierea jurnalului, anularea operației de rezervă ar putea ajuta problema imediată.,
4	ACTIVE_TRANSACTION	O tranzacție este activ (toate de recuperare modele): O tranzacție de lungă durată ar putea exista la începutul jurnal de rezervă. În acest caz, eliberarea spațiului poate necesita o altă copie de rezervă a jurnalului. Rețineți că tranzacțiile pe termen lung împiedică trunchierea jurnalului în toate modelele de recuperare, inclusiv modelul de recuperare simplu, în care Jurnalul de tranzacții este în general trunchiat pe fiecare punct de control automat. O tranzacție este amânată., O tranzacție amânată este efectiv o tranzacție activă a cărei revocare este blocată din cauza unei resurse indisponibile. Pentru informații despre cauzele tranzacțiilor amânate și despre modul de mutare a acestora din starea amânată, consultați tranzacții amânate (SQL Server). tranzacțiile pe termen lung ar putea, de asemenea, să umple jurnalul de tranzacții al tempdb. Tempdb este utilizat implicit de tranzacțiile utilizatorilor pentru obiecte interne, cum ar fi tabele de lucru pentru sortare, fișiere de lucru pentru hashing, tabele de lucru cursor și versiuni de rând., Chiar dacă tranzacția utilizatorului include doar citirea datelor (SELECT interogări), obiectele interne pot fi create și utilizate în cadrul tranzacțiilor utilizatorului. Apoi, Jurnalul de tranzacții tempdb poate fi completat.
5	DATABASE_MIRRORING	oglindirea bazei de date este întreruptă sau în modul de înaltă performanță, baza de date oglindă este semnificativ în spatele bazei de date principale. (Numai modelul de recuperare completă) pentru mai multe informații, consultați oglindirea bazei de date (SQL Server).,
6	replicare	în timpul replicărilor tranzacționale, tranzacțiile relevante pentru publicații sunt încă nelivrate în baza de date de distribuție. (Numai modelul de recuperare completă) Pentru informații despre replicarea tranzacțională, consultați replicarea SQL Server.
7	DATABASE_SNAPSHOT_CREATION	se creează un instantaneu al bazei de date. (Toate modelele de recuperare) aceasta este o rutină și, de obicei, scurtă, cauza trunchierii întârziate a jurnalului.
8	LOG_SCAN	o scanare Jurnal are loc., (Toate modelele de recuperare) aceasta este o rutină și, de obicei, scurtă, cauza trunchierii întârziate a jurnalului.
9	AVAILABILITY_REPLICA	o replică secundară a unui grup de disponibilitate aplică înregistrările jurnalului de tranzacții ale acestei baze de date unei baze de date secundare corespunzătoare. (Modelul de recuperare completă) pentru mai multe informații, consultați Prezentarea generală a grupurilor de disponibilitate întotdeauna (SQL Server).,
10	–	doar Pentru uz intern
11	–	doar Pentru uz intern
12	–	Numai pentru uz intern
13	OLDEST_PAGE	Dacă o bază de date este configurat pentru a utiliza indirecte de control, cea mai veche pagina de pe baza de date ar putea fi mai mare decât punctul de control log număr de secvență (LSN). În acest caz, cea mai veche pagină poate întârzia trunchierea jurnalului. (Toate modelele de recuperare) Pentru informații despre punctele de control indirecte, consultați punctele de control ale bazei de date (SQL Server).,
14	OTHER_TRANSIENT	această valoare nu este utilizată în prezent.
16	XTP_CHECKPOINT	trebuie efectuat un punct de control OLTP în memorie.Pentru tabele optimizate de memorie, un punct de control automat este luată atunci când fișierul jurnal tranzacție devine mai mare decât 1.,5 GB de la ultimul punct de control (include atât pe bază de disc și memorie-optimizat tabele) Pentru mai multe informații, a se vedea punctul de Control de Funcționare pentru Memorie-Optimizat Tabele și (https://blogs.msdn.microsoft.com/sqlcat/2016/05/20/logging-and-checkpoint-process-for-memory-optimized-tables-2/)

Operațiuni care pot fi minim autentificat

Minim exploatarea implică exploatarea numai informațiile care sunt necesare pentru a recupera de tranzacție fără punct de sprijin-în-timp de recuperare., Acest subiect identifică operațiunile care sunt înregistrate minim sub modelul de recuperare înregistrat în bloc (precum și sub modelul de recuperare simplu, cu excepția cazului în care se execută o copie de rezervă).

următoarele operații, care sunt complet înregistrate sub modelul de recuperare completă, sunt înregistrate minim sub modelul de recuperare simplu și în bloc:

• operațiuni de import în vrac (bcp, inserare în bloc și inserare… Selectați)., Pentru mai multe informații despre momentul în care importul în bloc într-un tabel este înregistrat minim, consultați cerințele preliminare pentru înregistrarea minimă în importul în bloc.

când replicarea tranzacțională este activată,BULK INSERT operațiunile sunt complet înregistrate chiar și sub modelul de recuperare înregistrat în bloc.

• selectați în operațiuni.

când replicarea tranzacțională este activată,SELECT INTO operațiunile sunt complet înregistrate chiar și sub modelul de recuperare înregistrat în bloc.,

• actualizări parțiale la tipurile de date cu valoare mare, utilizând clauza .WRITE din Declarația de actualizare la introducerea sau adăugarea de date noi. Rețineți că înregistrarea minimă nu este utilizată atunci când valorile existente sunt actualizate. Pentru mai multe informații despre tipurile de date cu valoare mare, consultați Tipuri de date (Transact-SQL).

• WRITETEXT și UPDATETEXT declarații atunci când inserarea sau adăugarea de date noi în coloanele de tip text, ntext, și imagine de date. Rețineți că înregistrarea minimă nu este utilizată atunci când valorile existente sunt actualizate.,

  Avertisment

  WRITETEXT și UPDATETEXT declarații sunt depreciate; pentru a evita utilizarea lor în aplicații noi.

• dacă baza de date este setată la modelul de recuperare simplu sau înregistrat în bloc, unele operații index DDL sunt înregistrate minim dacă operația este executată offline sau online. Operațiunile de index minim înregistrate sunt următoarele:

  • creați operațiuni de INDEX (inclusiv vizualizări indexate).

  • modifica operațiunile de index reconstrui sau DBCC dbreindex.,

    avertisment

    instrucțiunea DBCC DBREINDEX este învechită; nu o utilizați în aplicații noi.

    Nota

    Index construi operațiunile folosi minimial logare dar poate fi amânată atunci când există o concomitent executarea de backup. Această întârziere este cauzată de cerințele de sincronizare ale paginilor de rezervă tampon minim înregistrate atunci când se utilizează modelul de recuperare simplu sau în vrac.

  • DROP INDEX New heap rebuild (dacă este cazul). Index page deallocation în timpul unei DROP INDEX operație este întotdeauna complet conectat.,n baza de date este deteriorată (SQL Server)

  restaurarea Jurnalului de tranzacții (modelul de recuperare completă)

  • restaurați o copie de rezervă a Jurnalului de tranzacții (SQL Server)

  Vezi și

  arhitectura jurnalului de tranzacții SQL Server și Ghidul de Management
  durabilitatea tranzacției de Control
  cerințe preliminare pentru logarea minimă în importul în vrac
  (SQL Server)
  vizualizați sau modificați proprietățile unei baze de date
  modele de recuperare (SQL Server)
  backup-uri jurnal de tranzacții (SQL Server)
  sys.,dm_db_log_info (Transact-SQL)
  sys.dm_db_log_space_usage (Transact-SQL)