nume_bază | database_id | 0
Numele sau identificatorul bazei de date care trebuie comprimat. Dacă este specificat 0, este utilizată baza de date curentă.
Procentul de spațiu liber care ar trebui să rămână în baza de date după comprimare.
Comprimă datele în fișiere prin mutarea paginilor distribuite de la sfârșitul fișierului la locul paginilor nealocate la începutul fișierului. Argumentul target_percent este opțional.
Spațiul liber de la sfârșitul fișierului nu este returnat sistemului de operare și dimensiunea fizică a fișierului nu se modifică. Prin urmare, dacă este specificat argumentul NOTRUNCATE, comprimarea fișierelor de date este neglijabilă.
Argumentul NOTRUNCATE se aplică numai fișierelor de date. Fișierul jurnal nu este afectat.
Eliberă tot spațiul liber de la sfârșitul fișierului către sistemul de operare, dar nu muta paginile din fișier. Fișierul de date este redus numai în ultima măsură selectată. Argumentul target_percent nu este procesat dacă este specificat argumentul TRUNCATEONLY.
Argumentul TRUNCATEONLY afectează fișierul jurnal. Pentru a trunchia numai fișierul de date, utilizați instrucțiunea DBCC SHRINKFILE.
Suprimă toate mesajele de informație cu grade de severitate de la 0 la 10.
Pentru a comprima toate fișierele de date și fișierele din baza de date specificată, emiteți comanda DBCC SHRINKDATABASE. Pentru a comprima un singur fișier de date sau un fișier jurnal în baza de date specificată, emiteți comanda DBCC SHRINKFILE.
Operațiile DBCC SHRINKDATABASE pot fi oprite în orice etapă a procesului și toate lucrările efectuate sunt salvate.
Dimensiunea bazei de date nu poate fi făcută mai mică decât dimensiunea minimă a bazei de date. Dimensiunea minimă - este dimensiunea specificată atunci când baza de date a fost creată sau ultima dimensiune stabilită în mod explicit dimensiunea schimbare de operare a fișierului, cum ar fi o DBCC SHRINKFILE sau ALTER DATABASE. De exemplu, dacă a fost creată o bază de date cu o dimensiune de 10 MB și apoi a crescut la 100 MB, aceasta poate fi comprimată numai la 10 MB, chiar dacă toate datele sunt șterse din baza de date.
Operațiunea DBCC SHRINKDATABASE fără a specifica parametrul NOTRUNCATE sau TRUNCATEONLY este echivalent cu operarea DBCC SHRINKDATABASE cu NOTRUNCATE parametru după efectuarea DBCC SHRINKDATABASE cu parametrul TRUNCATEONLY.
O bază de date comprimabilă nu trebuie să fie în modul pentru un singur utilizator. Alți utilizatori pot lucra cu baza de date atunci când este comprimată. Acest lucru se aplică și în bazele de date ale sistemului.
Nu este posibilă comprimarea bazei de date în timp ce este făcută o copie de rezervă. În schimb, nu puteți crea o copie de rezervă a unei baze de date în timpul unei operații de compresie.
Comanda DBCC SHRINKDATABASE
Instrucțiunea DBCC SHRINKDATABASE comprimă fișierele de date una câte una, iar fișierele jurnal ca și cum ar reprezenta toate un fond de jurnal contiguu. Comprimarea fișierelor se face întotdeauna de la sfârșit.
Să presupunem că există o bază de date numită mydb. care are un fișier de date și două fișiere log. Fiecare fișier de date și fișier log are o dimensiune de 10 MB, iar fișierul de date conține 6 MB de date.
Componenta Motorul bazei de date calculează dimensiunea țintă a fiecărui fișier. Aceasta este mărimea la care fișierul de date trebuie comprimat. Dacă instrucțiunea DBCC SHRINKDATABASE este specificată cu argumentul target_percent. apoi Component Database Engine calculează dimensiunea țintă astfel încât în fișier după comprimare, procentul țintă_percent al spațiului liber a fost creat. De exemplu, dacă specificați argumentul target_percent cu o valoare de 25 pentru a comprima baza de date mydb. componentă Motorul bazei de date va calcula dimensiunea țintă pentru fișierul de 8 MB (6 MB de date și 2 MB de spațiu liber). Prin urmare, motorul de bază de date Component muta toate datele din ultimele 2 MB din fișierul de date în orice spațiu liber din primele 8 MB din fișierul de date și apoi comprimă fișierul.
Să presupunem că fișierul de date mydb conține 7 MB de date. Când specificați o valoare de 30 pentru target_percent, puteți comprima acest fișier de date la 30%. Cu toate acestea, setarea unei valori de 40 pentru target_percent nu va permite comprimarea fișierului de date, deoarece motorul de baze de date nu poate reduce fișierul la o dimensiune mai mică decât cea pe care datele o ocupă în prezent. Această situație poate fi reprezentată într-un alt mod: 40% din spațiul liber dorit + 70% din fișierul de date complet (7 MB de 10 MB) este mai mult de 100%. Deoarece procentajul dorit de eliberat și procentul curent ocupat de fișierul de date depășește 100 (cu 10%), orice valoare a sumei target_size. O valoare mai mare de 30 nu va comprima fișierul de date.
Pentru fișierele jurnal, componenta Engine Engine utilizează argumentul target_percent pentru a calcula dimensiunea țintă a întregului jurnal. Prin urmare, argumentul target_percent este cantitatea de spațiu liber din jurnal după operația de comprimare. Dimensiunea țintă a întregului jurnal este apoi recalculată în mărimea țintă a fiecărui fișier jurnal.
Instruciunea DBCC SHRINKDATABASE încearcă să comprime imediat fiecare fișier jurnal fizic la dimensiunea țintă. În cazul în care nici o parte a jurnalului logic nu este plasat în fișierele jurnal virtuale a căror dimensiune depășește dimensiunea țintă a fișierului jurnal, fișierul este trunchiat cu succes și declarația DBCC SHRINKDATABASE se termină fără nici un mesaj. Cu toate acestea, în cazul în care o parte din jurnalul logic este stocat în jurnalele virtuale dincolo de dimensiunea specificată, Database Engine eliberează cât mai mult spațiu posibil, apoi generează un mesaj informativ. Mesajul descrie pașii care trebuie întreprinși pentru a muta jurnalul logic de la jurnalele virtuale la sfârșitul fișierului. După ce toată acțiunea declarație DBCC SHRINKDATABASE poate fi folosit pentru a elibera spațiul rămas.
Deoarece fișierul jurnal poate fi comprimat numai la limita fișierului jurnal virtual, nu este posibilă comprimarea fișierului jurnal la o dimensiune mai mică decât dimensiunea fișierului jurnal virtual, chiar dacă acesta nu este utilizat. Dimensiunea fișierului jurnal virtual este selectată dinamic de către motorul de bază de date atunci când se creează sau se extind fișierele jurnal.
recomandări
Rețineți următoarele informații atunci când planificați comprimarea bazei de date.
Cel mai mare efect al operației de comprimare este realizat atunci când este aplicat după o operație care creează o mulțime de spațiu neutilizat, de exemplu după trunchierea unui tabel sau ștergerea unei mese.
Cele mai multe baze de date necesită un spațiu liber pentru a efectua operații zilnice normale. Dacă compresia bazei de date se face în mod regulat, dar din nou crește dimensiunea, aceasta înseamnă că spațiul eliberat în timpul comprimării este necesar pentru funcționarea normală. În astfel de cazuri, re-comprimarea bazei de date nu are sens.
Operația de comprimare nu elimină fragmentarea indexurilor din baza de date și duce, de obicei, la o fragmentare mai puternică. Acesta este un alt motiv pentru care nu ar trebui să efectuați compresia obișnuită a bazei de date.
Nu setați parametrul de bază de date AUTO_SHRINK la ON fără motiv suficient.
Remediați problemele
Operațiile de comprimare pot fi blocate de o tranzacție care rulează cu un nivel de izolare bazat pe controlul versiunilor rândurilor. De exemplu, atunci când se efectuează o operație de îndepărtare nivel de izolare pe scară largă bazate pe versionare rând, realizați manual DBCC SHRINK DATABASE, apoi, înainte de a trece la un fișier comprimat, acesta va aștepta finalizarea operației de ștergere. În acest caz, operațiunea DBCC SHRINKFILE și DBCC SHRINKDATABASE mesajul de informații de ieșire (5202 și 5203 pentru SHRINKDATABASE pentru SHRINKFILE) în jurnalul de erori SQL Server la fiecare 5 minute în timpul primei ore, iar apoi un mesaj la fiecare oră. De exemplu, jurnalul de erori conține următorul mesaj de eroare:
Acest lucru înseamnă că operațiunea de contracție este blocată de instantaneu tranzacție care au marcajele de timp mai mari decât marca 109 reprezentând ultima tranzacție, încheie operația de compresie. Acest lucru arată, de asemenea, că coloanele transaction_sequence_num first_snapshot_sequence_num sau sys.dm_tran_active_snapshot_database_transactions reprezentare dinamice de management (Transact-SQL) conține valoarea 15. În cazul în care coloanele sau transaction_sequence_num first_snapshot_sequence_num introducerea conțin mai puțin de ultima tranzacție etapa executată de compresie (109), operațiunea de comprimare va aștepta finalizarea acestor tranzacții.
Puteți rezolva această problemă într-unul din următoarele moduri:
Opriți executarea tranzacției blocând operația de comprimare.
Terminați operația de comprimare. Toate lucrările finalizate vor fi salvate.
În timp ce operația de compresie așteaptă finalizarea tranzacției de blocare, nu trebuie făcut nimic.
Trimiteți-le prietenilor: