Atunci când efectuează o tranzacție, SGBD-ul își înregistrează acțiunile într-un fișier jurnal, astfel încât, în cazul unei erori, acesta va reveni la starea initiala. Și, uneori, acest fișier crește la o dimensiune FOARTE mare, iar dimensiunea nu depinde de dimensiunea bazei de date în sine.
De exemplu, acum mă confrunt cu problema de a rămâne fără spațiu pe hard disk. Am început să-mi dau seama: Base 1C Salary and Personnel Management 3.0 are o dimensiune de 500 MB, în care 2 computere funcționează de 2 ori pe lună, are un fișier jurnal de 398 GB (tocmai a rămas fără spațiu pe hard disk).
Ei bine, trebuie să reducem acest fișier. Cel mai bine este să faceți acest lucru în mod regulat prin „Planuri de service”, dar acum vă voi arăta cum să o faceți manual.
SQL vă permite să eliberați spațiu pentru sistemul de operare doar acela pentru care s-a făcut backup anterior, așa că mai întâi trebuie să faceți o copie de rezervă a jurnalului de tranzacții.
1. Selectați o bază. Click dreapta. Accesați secțiunea de activități -> creați o copie de rezervă.
2. Alegeți un tip copie de rezervă"Jurnal de tranzacții". indicați unde să salvați și faceți clic pe ok.
Același lucru se poate face folosind un script:
BACKUP LOG [Numele bazei de date] TO DISK = N"calea către fișierul de rezervă" WITH NOFORMAT, NOINIT, NAME = N"numele bazei de date-Jurnal de tranzacții Backup", SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO
După finalizarea procesului, puteți trece direct la compresie.
1. Accesați elementul meniului sarcini -> comprimare -> fișiere
2. Selectați tipul de fișier „Jurnal”. Acordați atenție câmpului „Disponibil”. loc liber" - ar trebui să fie aproape de 100% din fișierul jurnal.
3. Faceți clic pe ok
Același lucru cu un scenariu
USE [numele bazei de date] GO DBCC SHRINKFILE (N"nume fișier jurnal", 0, TRUNCATEONLY) GO
Cu toții vedem că fișierul jurnal a scăzut la valoarea sa minimă.
Totul ar fi bine, dar această eroare apare periodic
Fișierul jurnal 2() nu a putut fi comprimat deoarece toate fișierele jurnal logice situate la sfârșitul fișierului sunt în uz.
Am încercat diverse opțiuni, dar în cele din urmă acest script m-a ajutat:
USE numele bazei de date; GO -- Trunchiați jurnalul schimbând modelul de recuperare a bazei de date în SIMPLE. ALTER DATABASE numele bazei de date SET RECOVERY SIMPLE; GO -- Reduceți fișierul jurnal trunchiat la 1 MB. DBCC SHRINKFILE (nume fișier jurnal, 1); GO -- Resetați modelul de recuperare a bazei de date. ALTER DATABASE numele bazei de date SET RECOVERY FULL; MERGE
Orice softwareîndeplinește anumite funcții. Indiferent de modul în care face acest lucru, în mod implicit este creat un fișier jurnal în folderul cu utilitarul. Acest fișier este document text, care afișează toate acțiunile programului.
Vei avea nevoie
- Software:
- - orice editor de text;
- - Arhivator 7Zip.
Instrucțiuni
După anumite manipulări cu baza de date, apar situații când dimensiunea fișierelor acesteia depășește limite rezonabile (sau, ca și mine, de două ori 103 GB necesari în loc de 65 GB, iar acesta este doar fișierul bazei de date). Această situație poate fi rezolvată cu o simplă micșorare.
Opțiunile de cod de mai jos sunt destul de simple:
- DBCC shrinkdatabase(N’nume_base de date’, TRUNCATE_ONLY); - trunchierea întregii baze de date
- utilizați [nume_base de date] DBCC SHRINKFILE (N'nume_bază de date', 101);— trunchierea numai a fișierului de date la o dimensiune de 101 MB
- utilizați [nume_bază de date] DBCC SHRINKFILE (N'nume_bază_date_Log', 0);— trunchierea fișierului tranzacției numai la 0 MB în dimensiune
Dar pot apărea probleme la efectuarea acestei operațiuni. Ele apar în principal pe acele baze de date pentru care este instalat modelul de arhivare completă (pentru modelul Simplu problemele, de regulă, nu apar; vom explica de ce mai târziu). Mesajele de eroare spun că fișierul jurnal este în uz, deci operațiunea nu poate fi efectuată - acest lucru este mai mult decât surprinzător, deoarece, de obicei, procesul de micșorare este efectuat când utilizatorii au terminat de lucrat (nimeni nu accesează baza de date). Monitorul conexiunii arată și absența oricărei activități.
Înainte de a efectua o micșorare a bazei de date, trebuie să arhivezi, dar nu întreaga bază de date, și anume fișierul tranzacției. Numai după finalizarea acestei proceduri puteți executa în siguranță comanda de micșorare, iar rezultatul va fi atins. Trebuie spus că procedura de arhivare este necesară doar dacă modelul de arhivare completă este instalat pentru baza de date. În modelul Simplu, fișierul jurnal este marcat automat ca liber pentru utilizare și comanda shrink funcționează fără probleme; în modelul Full, fișierul devine liber pentru utilizare numai după o copie de rezervă a fișierului corespunzător.
Total, pentru a trunchia dimensiunea fișierelor bazei de date SQL 2005 are urmatorul cod:
Utilizați DatabaseName
BACKUP Jurnal[DatabaseName] WITH TRUNCATE_ONLY
DBCC SHRINKFILE(„FileNameBoolean”)
Aceeași operațiune pentru SQL 2008 va arata diferit. Deoarece nu există o cheie precum TRUNCATE_ONLY pentru comanda BACKUP, puteți utiliza un transfer temporar al bazei de date în modul de rezervă SIMPLE, puteți trunchia fișierul și puteți reveni la modul COMPLET. Desigur, dacă inițial a fost așa:
USE BaseName
ALTER DATABASEDatabaseName SETARE RECOVERY SIMPLE
DBCC SHRINKFILE("FileNameLogical", 10);
ALTER DATABASEBaseName SETARE RECOVERY FULL
De asemenea, după ce manipulările au fost efectuate, nu strica niciodată să verifici baza de date. Ca de obicei, transferăm baza de date în modul exclusiv ( Dacă trebuie să utilizați argumente REPAIR, rulați DBCC CHECKDB fără opțiunea de reparare pentru a afla nivelul de reparație necesar înainte de restaurare)
Când apar erori la conectarea la baza de date MS SQL:
Eroare DBMS:
Furnizor Microsoft OLE DB SQL Server: Jurnalul de tranzacții pentru baza de date „ReportServer” este plin. Pentru a descoperi motivul pentru care spațiul de jurnal nu poate fi reutilizat, priviți coloana log_reuse_wait_desc a tabelului
sys. baze de date HRESULT=80040E14, SQLStvr: Stare eroare=2, Severitate=11, nativ=9002, linie=1
sau
Eroare DBMS:
Furnizor Microsoft OLE pentru SQL Server: Jurnalul de tranzacții pentru baza de date „ReportServer” este plin. Pentru a afla de ce spațiul din jurnal nu poate fi reutilizat, consultați coloana log_reuse_wait_desc este sys.database
HRESULT=80040E14, SQLSTATE=4 2000, nativ=9002
aceasta înseamnă că discul pe care se află jurnalul de tranzacții a rămas fără spațiu și acum DBMS nu are unde să scrie date despre tranzacțiile noi. Cel mai adesea, acest lucru se întâmplă atunci când nu există restricții privind dimensiunea jurnalului și nu au fost create planuri de întreținere corespunzătoare în MS SQL.
În acest caz, trebuie să reduceți dimensiunea fișierului tranzacției în sine (*.ldf), cu alte cuvinte, să micșorați (comprimați) jurnalul. Pentru a face acest lucru, puteți utiliza fie o interogare, fie comprimarea manuală a jurnalului.
Să luăm în considerare comprimarea manuală a jurnalului de tranzacții:
Pasul 1. Setați modelul de recuperare la Simplu. Faceți clic dreapta pe bază - Proprietăți
Următorul: Opțiuni - al 4-lea articol din partea de sus Model de recuperare - Simplu - OK.
Reduceți jurnalul de tranzacții. Faceți clic dreapta pe bază - Sarcini - Reducere - Fișiere
Instalare Tip de fișier - Autentificare - Acțiune de micșorare - selectați Reorganizare pagini înainte de a elibera spațiul nefolosit - Reduceți fișierul la
indicați o dimensiune acceptabilă a jurnalului.
