DBCC SHRINKDATABASE (Transact-SQL) – SQL Server | Microsoft Docs DBCC SHRINKDATABASE (Transact-SQL)

• 07/17/2017
• 8 minute de citit
• • p
  • M

  .

  • j
  • i
  • K
  • +12

Se aplică la: SQL Server (toate versiunile acceptate) Azure SQL Database Azure Synapse Analytics

Reduce dimensiunea fișierelor de date și de jurnal din baza de date specificată.

Convenții de sintaxă Transact-SQL

Sintaxa

DBCC SHRINKDATABASE ( database_name | database_id | 0 ) 

-- Azure Synapse AnalyticsDBCC SHRINKDATABASE ( database_name ) 

Argumente

database_name | database_id | 0
Este numele sau ID-ul bazei de date care urmează să fie micșorat. 0 specifică faptul că se utilizează baza de date curentă.

target_percent
Este procentul de spațiu liber pe care doriți să rămână în fișierul bazei de date după ce baza de date a fost micșorată.

NOTRUNCATE
Mută paginile atribuite de la sfârșitul fișierului în paginile neatribuite din partea din față a fișierului. Această acțiune compactează datele din cadrul fișierului. target_percent este opțional. Azure Synapse Analytics nu acceptă această opțiune.

Spațiul liber de la sfârșitul fișierului nu este returnat sistemului de operare, iar dimensiunea fizică a fișierului nu se modifică. Ca atare, baza de date pare să nu se micșoreze atunci când specificați NOTRUNCATE.

NOTRUNCATE se aplică numai la fișierele de date. NOTRUNCATE nu afectează fișierul jurnal.

TRUNCATEONLY
Liberează tot spațiul liber de la sfârșitul fișierului către sistemul de operare. Nu mută nicio pagină din interiorul fișierului. Fișierul de date se micșorează numai până la ultima extensie atribuită. Ignoră target_percent dacă este specificat cu TRUNCATEONLY. Azure Synapse Analytics nu acceptă această opțiune.

TRUNCATEONLY afectează fișierul jurnal. Pentru a trunchia numai fișierul de date, utilizați DBCC SHRINKFILE.

WITH NO_INFOMSGS
Suprimă toate mesajele informative care au niveluri de severitate de la 0 la 10.

Seturi de rezultate

Următorul tabel descrie coloanele din setul de rezultate.

Numele coloanei	Descriere
DbId	Numărul de identificare al bazei de date al fișierului pe care Motorul bazei de date a încercat să îl micșoreze.
FileId	Numărul de identificare al fișierului pe care motorul de baze de date a încercat să îl micșoreze.
CurrentSize	Numărul de pagini de 8 KB pe care fișierul le ocupă în prezent.
MinimumSize	Numărul de pagini de 8 KB pe care fișierul le-ar putea ocupa, la minim. Această valoare corespunde dimensiunii minime sau dimensiunii create inițial a unui fișier.
UsedPages	Numărul de pagini de 8-KB utilizate în prezent de fișier.
EstimatedPages	Numărul de pagini de 8-KB la care motorul bazei de date estimează că fișierul ar putea fi micșorat.

Remarks

Pentru a micșora toate fișierele de date și de jurnal pentru o anumită bază de date, executați comanda DBCC SHRINKDATABASE. Pentru a micșora câte un fișier de date sau de jurnal pentru o anumită bază de date, executați comanda DBCC SHRINKFILE.

Pentru a vizualiza cantitatea curentă de spațiu liber (nealocat) din baza de date, rulați sp_spaceused.

Operațiile DBCC SHRINKDATABASE pot fi oprite în orice moment al procesului, iar orice muncă finalizată este păstrată.

Baza de date nu poate fi mai mică decât dimensiunea minimă configurată a bazei de date. Specificați dimensiunea minimă atunci când baza de date este creată inițial. Sau, dimensiunea minimă poate fi ultima dimensiune stabilită în mod explicit prin utilizarea unei operații de modificare a dimensiunii fișierului. Operații precum DBCC SHRINKFILE sau ALTER DATABASE sunt exemple de operații de modificare a dimensiunii fișierelor.

Să spunem că o bază de date este creată inițial cu o dimensiune de 10 MB. Apoi, aceasta crește până la 100 MB. Cea mai mică dimensiune la care poate fi redusă baza de date este de 10 MB, chiar dacă toate datele din baza de date au fost șterse.

Specificați fie opțiunea NOTRUNCATE, fie opțiunea TRUNCATEONLY atunci când executați DBCC SHRINKDATABASE. Dacă nu o faceți, rezultatul este același ca și în cazul în care ați rula o operație DBCC SHRINKDATABASE cu NOTRUNCATE urmată de rularea unei operații DBCC SHRINKDATABASE cu TRUNCATEONLY.

Baza de date micșorată nu trebuie să fie în modul utilizator unic. Alți utilizatori pot lucra în baza de date atunci când aceasta este micșorată, inclusiv bazele de date de sistem.

Nu puteți micșora o bază de date în timp ce baza de date face obiectul unui backup. Invers, nu puteți face o copie de rezervă a unei baze de date în timp ce o operație de micșorare a bazei de date este în curs de desfășurare.

Cum funcționează DBCC SHRINKDATABASE

DBCC SHRINKDATABASE micșorează fișierele de date pentru fiecare fișier în parte, dar micșorează fișierele de jurnal ca și cum toate fișierele de jurnal ar exista într-un singur grup de jurnal contiguu. Fișierele sunt întotdeauna micșorate de la capăt.

Să presupunem că aveți câteva fișiere jurnal, un fișier de date și o bază de date numită mydb. Fișierele de date și de jurnal au câte 10 MB fiecare, iar fișierul de date conține 6 MB de date. Motorul de baze de date calculează o dimensiune țintă pentru fiecare fișier. Această valoare este dimensiunea la care fișierul trebuie micșorat. Atunci când DBCC SHRINKDATABASE este specificat cu target_percent, motorul de baze de date calculează dimensiunea țintă ca fiind valoarea target_percent de spațiu liber în fișier după micșorare.

De exemplu, dacă specificați un target_percent de 25 pentru micșorarea mydb, motorul de baze de date calculează dimensiunea țintă pentru fișierul de date ca fiind de 8 MB (6 MB de date plus 2 MB de spațiu liber). Ca atare, Motorul de baze de date mută orice date din ultimii 2 MB ai fișierului de date în orice spațiu liber din primii 8 MB ai fișierului de date și apoi micșorează fișierul.

Să presupunem că fișierul de date mydb conține 7 MB de date. Specificarea unui target_percent de 30 permite ca acest fișier de date să fie micșorat până la procentul liber de 30. Cu toate acestea, specificarea unui target_percent de 40 nu micșorează fișierul de date, deoarece motorul de baze de date nu va micșora un fișier la o dimensiune mai mică decât cea pe care o ocupă în prezent datele.

Puteți, de asemenea, să vă gândiți la această problemă într-un alt mod: 40 la sută spațiu liber dorit + 70 la sută fișier de date plin (7 MB din 10 MB) înseamnă mai mult de 100 la sută. Orice target_size mai mare de 30 nu va micșora fișierul de date. Nu se va micșora pentru că procentul liber dorit plus procentul actual pe care îl ocupă fișierul de date este mai mare de 100 la sută.

Pentru fișierele jurnal, motorul de baze de date utilizează target_percent pentru a calcula dimensiunea țintă pentru întregul jurnal. Acesta este motivul pentru care target_percent este cantitatea de spațiu liber din jurnal după operația de micșorare. Dimensiunea țintă pentru întregul jurnal este apoi transpusă într-o dimensiune țintă pentru fiecare fișier jurnal.

DBCC SHRINKDATABASE încearcă să micșoreze imediat fiecare fișier jurnal fizic la dimensiunea țintă. Să spunem că nicio parte din jurnalul logic nu rămâne în jurnalele virtuale dincolo de dimensiunea țintă a fișierului jurnal. Atunci fișierul este trunchiat cu succes, iar DBCC SHRINKDATABASE se termină fără niciun mesaj. Cu toate acestea, dacă o parte din jurnalul logic rămâne în jurnalele virtuale dincolo de dimensiunea țintă, motorul de baze de date eliberează cât mai mult spațiu posibil și apoi emite un mesaj informativ. Mesajul descrie ce acțiuni sunt necesare pentru a muta jurnalul logic din jurnalele virtuale la sfârșitul fișierului. După ce acțiunile sunt executate, DBCC SHRINKDATABASE poate fi utilizat pentru a elibera spațiul rămas.

Un fișier jurnal poate fi micșorat numai până la limita unui fișier jurnal virtual. De aceea, este posibil ca micșorarea unui fișier jurnal la o dimensiune mai mică decât dimensiunea unui fișier jurnal virtual să nu fie posibilă. S-ar putea să nu fie posibil chiar dacă nu este utilizat. Dimensiunea fișierului jurnal virtual este aleasă în mod dinamic de către motorul de baze de date atunci când fișierele jurnal sunt create sau extinse.

Bune practici

Considerați următoarele informații atunci când plănuiți să micșorați o bază de date:

• O operațiune de micșorare este mai eficientă după o operațiune care creează spațiu neutilizat, cum ar fi o operațiune de trunchiere a tabelului sau o operațiune de eliminare a tabelului.
• Majoritatea bazelor de date necesită un anumit spațiu liber pentru a fi disponibil pentru operațiunile zilnice obișnuite. Este posibil să micșorați o bază de date în mod repetat și să observați că dimensiunea bazei de date crește din nou. Această creștere indică faptul că spațiul micșorat este necesar pentru operațiunile obișnuite. În aceste cazuri, micșorarea repetată a bazei de date este o operațiune irosită.
• O operațiune de micșorare nu păstrează starea de fragmentare a indexurilor din baza de date și, în general, crește fragmentarea într-o anumită măsură. Acest rezultat este un alt motiv pentru a nu micșora în mod repetat baza de date.
• Dacă nu aveți o cerință specifică, nu setați opțiunea AUTO_SHRINK a bazei de date la ON.

Soluționarea problemelor

Este posibil să se blocheze operațiunile de micșorare de către o tranzacție care se execută sub un nivel de izolare bazat pe versiunea rândurilor. De exemplu, o operațiune mare de ștergere care se execută sub un nivel de izolare bazat pe versiunea rândurilor este în curs de desfășurare atunci când se execută o operațiune DBCC SHRINK DATABASE. Când se întâmplă această situație, operația de micșorare va aștepta finalizarea operației de ștergere înainte de a micșora fișierele. Atunci când operația de micșorare așteaptă, operațiile DBCC SHRINKFILE și DBCC SHRINKDATABASE tipăresc un mesaj informativ (5202 pentru SHRINKDATABASE și 5203 pentru SHRINKFILE). Acest mesaj se tipărește în jurnalul de erori SQL Server la fiecare cinci minute în prima oră și apoi la fiecare oră următoare. De exemplu, dacă jurnalul de erori conține următorul mesaj de eroare:

DBCC SHRINKDATABASE for database ID 9 is waiting for the snapshot transaction with timestamp 15 and other snapshot transactions linked to timestamp 15 or with timestamps older than 109 to finish. 

Această eroare înseamnă că tranzacțiile instantanee care au timestamp-uri mai vechi de 109 vor bloca operațiunea de micșorare. Această tranzacție este ultima tranzacție pe care operațiunea de micșorare a fost finalizată. De asemenea, indică faptul că coloanele transaction_sequence_num sau first_snapshot_sequence_num din vizualizarea de gestionare dinamică sys.dm_tran_active_snapshot_database_transactions (Transact-SQL) conțin o valoare de 15. Este posibil ca coloana transaction_sequence_num sau first_snapshot_sequence_num din vizualizare să conțină un număr care este mai mic decât ultima tranzacție finalizată printr-o operațiune de micșorare (109). Dacă este așa, operația de micșorare va aștepta ca acele tranzacții să se termine.

Pentru a rezolva problema, puteți efectua una dintre următoarele sarcini:

• Încheiați tranzacția care blochează operația de micșorare.
• Încheiați operația de micșorare. Orice lucrare finalizată este păstrată.
• Nu faceți nimic și permiteți operației de micșorare să aștepte până când tranzacția care blochează se finalizează.

Permisiuni

Este necesară apartenența la rolul fix de server sysadmin sau la rolul fix de bază de date db_owner.

Exemple

A. Micșorarea unei baze de date și specificarea unui procent de spațiu liber

Exemplul următor reduce dimensiunea fișierelor de date și de jurnal din baza de date a utilizatorului UserDB pentru a permite un spațiu liber de 10 procente în baza de date.

DBCC SHRINKDATABASE (UserDB, 10); GO 

B. Trunchierea unei baze de date

Exemplul următor reduce fișierele de date și de jurnal din baza de date de probă AdventureWorks până la ultima extensie atribuită.

DBCC SHRINKDATABASE (AdventureWorks2012, TRUNCATEONLY); 

C. Micșorarea unei baze de date Azure Synapse Analytics

DBCC SHRINKDATABASE (database_A);DBCC SHRINKDATABASE (database_B, 10); 

Vezi și

ALTER DATABASE (Transact-SQL)
DBCC (Transact-SQL)
DBCC SHRINKFILE (Transact-SQL)
Micșorarea unei baze de date

.