Registrul de tranzacții (sql server)

Fiecare bază de date SQL Server are un jurnal de tranzacții, care înregistrează toate modificările făcute în fiecare tranzacție. Registrul de tranzacții ar trebui să fie trunchia în mod regulat, pentru a evita overflow. Dar, în același timp, pentru o serie de motive pentru trunchierea sale poate fi întârziată, de aceea este foarte important să se monitorizeze dimensiunea revistei. Unele operații pot fi efectuate cu minim de logare pentru a reduce contribuția la dimensiunea jurnalului de tranzacții.

Registrul de tranzacții este o componentă esențială a bazei de date și în cazul defectării sistemului poate fi necesară pentru a aduce baza de date într-o stare consistentă. Jurnalul de tranzacții nu pot fi șterse sau modificate, dacă nu știi consecințele.

punct de operare cunoscut pentru a începe utilizarea buștenilor tranzacției, atunci când restaurarea bazei de date, de a crea puncte de control. Pentru mai multe informații, consultați. Secțiunea Punctul de control al bazelor de date (SQL Server).

recuperarea tranzacțiilor individuale;

recuperarea tuturor tranzacțiilor restante la pornire SQL Server;

tambur restaurat bazei de date, fișier, filegroup sau pagina la punctul de eșec;

suport pentru replicare tranzacțional;

Suport pentru soluții de înaltă disponibilitate și de recuperare în caz de dezastru: Disponibilitate Grupuri AlwaysOn, baze de date oglindire, și jurnal de transport maritim.

Procesul de jurnal trunchiere eliberează spațiu în fișierul jurnal pentru log reutilizare tranzacție. Log trunchierea este necesară pentru a preveni revărsarea revistei. Când log trunchiere șterge fișierele jurnal virtuale inactive în logica de tranzacție de baze de date SQL Server jurnal, ceea ce duce la eliberarea de spațiu în jurnalul logic pentru reutilizare jurnal de tranzacții fizice. În cazul în care trunchierea jurnal de tranzacții nu este mulțumit de momentul în care umple tot spațiul disponibil pe disc alocat pentru fișierele jurnal fizice.

Pentru a preveni această problemă, log trunchiere se face automat după următoarele evenimente, cu excepția cazului când este pentru un motiv oarecare întârziere.

În modelul de recuperare simplu - după atingerea punctului de control.

Pentru modelul de recuperare completă și modelul de recuperare logat în vrac, în cazul în care un punct de control a fost creat după copia anterioară, trunchierea are loc după backup log (dacă nu este o copie de rezervă jurnal pentru a copia numai).

log trunchiere nu reduce dimensiunea fișierului jurnal fizic. Pentru a reduce dimensiunea reală a fișierului jurnal fizic, trebuie să efectuați compresia. Informații despre comprimarea fișierului jurnal fizic, a se vedea. Cum de a gestiona dimensiunea fișierului jurnal de tranzacții.

De la ultima trunchierea log nu a avut nici noi puncte de control sau din titlu jurnal nu este mutat dincolo de un fișier jurnal virtual. (Toate modelele de recuperare)

Acesta este un motiv comun pentru trunchiere jurnal de întârziere. Pentru mai multe informații, consultați. Secțiunea Punctul de control al bazelor de date (SQL Server).

După finalizarea următoarei backup-jurnal spațiu jurnal poate fi eliberat pentru reutilizare.

una activă a tranzacțiilor (toate modelele de recuperare).

- În timpul unei tranzacții lung poate fi ora de începere a jurnalului de rezervă. În acest caz, pentru a spațiu liber poate fi necesar pentru a crea o altă copie de rezervă jurnal. Notă: tranzacțiile pe termen lung se preveni trunchiere log în toate modelele de recuperare, inclusiv modelul simplu de recuperare, în care jurnalul de tranzacții este, în general, trunchiat pe fiecare punct de control automat.
- Otlozhena.Otlozhennaya tranzacție tranzacție - este o tranzacție activă, revocați, care a fost suspendat din cauza indisponibilității unor resurse. Pentru mai multe informații despre motivele pentru care cauzează apariția tranzacțiilor amânate și modul în care acestea pot fi derivate de la o astfel de stare. A se vedea tranzacția Amânat secțiunea (SQL Server).

Baza de date oglindire este oprită temporar sau în modul de înaltă performanță, baza de date oglinda este cu mult în spatele principal. (Pentru modelul de recuperare integrală)

In timpul replicarii tranzacțională, baza de date de distribuție nu este livrat la tranzacție referitoare la publicațiile. (Pentru modelul de recuperare integrală)

Pentru mai multe informații despre replicarea tranzacționale, a se vedea. A se vedea SQL Server de replicare.

Se creează o bază de date instantaneu. (Toate modelele de recuperare)

Acest lucru este foarte frecvente (și, de obicei, pe termen scurt), motiv pentru întârzierea trunchiere a jurnalului de tranzacții.

replica secundară DAG utilizează înregistrări ale datelor de jurnal de tranzacții de baze de date la baza de date secundară corespunzătoare. (Modelul de recuperare completă)

În modelul de recuperare completă, toate operațiunile în vrac pe deplin autentificat. Cu toate acestea, pentru un set de operațiuni în vrac Puteți utiliza logare minimă, comutați temporar pe modelul de recuperare a bazei de date pentru a-vrac înregistrate în timpul operațiunilor de masă. logare minimă este mai eficientă decât completă, și reduce probabilitatea ca în timpul funcționării o cantitate mare de masă care urmează să fie umplut tot spațiul disponibil al jurnalului de tranzacții. Cu toate acestea, în cazul în care minimul când baza de date de logare este deteriorat sau pierdut, aceasta nu poate fi readus la punctul de eșec.

În continuare, operațiuni pe deplin autentificat modelul de recuperare completă, a făcut minim autentificat în modelul simplu de recuperare și modelul de recuperare pentru a-vrac Conectat:

Dacă activați reproducerea tranzacțională, operarea BULK INSERT este pe deplin conectat, chiar și în modelele cu vrac s-au conectat.

Dacă activați reproducerea tranzacțională, SELECT în operațiunile pe deplin înregistrate, chiar și în modelul de recuperare în vrac s-au conectat.

actualizare parțială a tipurilor de date cu valori mari, folosind sugestiile .WRITE instrucțiuni UPDATE la inserarea sau adăugarea de noi date. Rețineți că înregistrarea minimă nu este utilizat pentru a actualiza valorile existente. Pentru mai multe informații despre tipurile de valori mari, a se vedea. Tipuri de date (Transact-SQL).

Instrucțiuni WRITETEXT și UPDATETEXT la inserarea sau adăugarea de noi coloane de date cu tipul de date de text. ntext și imagine. Rețineți că înregistrarea minimă nu este utilizat pentru a actualiza valorile existente.

Instrucțiuni WRITETEXT și UPDATETEXT sunt depășite, așa că ar trebui să evite utilizarea lor în aplicații noi.

În cazul în care baza de date utilizează un model simplu de recuperare sau model de recuperare a autentificat-vrac, unele DDL-operare cu indexul sunt înregistrate în volumul minim atunci când acestea sunt executate ca modul „offline“, precum și în „rețea“. Minimally înregistrate în urma operațiunilor de index.

CREATE INDEX operațiuni (inclusiv vizualizări indexate).

Operațiuni ALTER INDEX REBUILD sau DBCC DBREINDEX.