Database
 sql >> Database >  >> RDS >> Database

Panoramica del comando DBCC SHRINKFILE

L'esecuzione dei comandi DBCC Shrink è una questione piuttosto controversa nella comunità di SQL Server. In questo articolo, esamineremo i dettagli su questo comando e forniremo una breve panoramica del suo utilizzo e ti avviseremo anche sui rischi dell'esecuzione di questo comando. In qualità di DBA, un certo numero di database sono stati ceduti da altri team o fornitori e non sempre riusciamo a gestire i database che abbiamo creato. In qualità di DBA, ogni volta che siamo coinvolti in migrazioni o nuovi progetti, dobbiamo assicurarci di pianificare attentamente una transizione graduale del database alla produzione e all'uso regolare. È in questa fase che dobbiamo tenere conto delle dimensioni del database. Riesci a immaginare di configurare un'applicazione di database senza considerare la previsione di crescita per il primo anno circa. Che ne dici di creare un database SQL Server con dimensioni così ridotte da dover crescere a giorni alterni aumentando gli avvisi di capacità del disco nel cuore della notte? Può sembrare sciocco, ma in realtà la verità è che questo accade e a volte potrebbe non essere sotto il tuo controllo.

Pochi punti da considerare per il DBA proattivo

Prima di assumere il supporto dei database di produzione, assicurati di verificare con il tuo predecessore quali sono le previsioni in termini di crescita del database. La dimensione iniziale dei database che gestirai è dimensionata adeguatamente? Non preoccuparti troppo se la dimensione attuale del database è molto più grande dei dati che ha attualmente. Ricorda, non vuoi quelle chiamate di capacità del disco alle 3:00 del mattino quando avresti potuto evitarlo completamente avendo un database di dimensioni corrette. È una tendenza generale per gli amministratori di database di tutto il settore sacrificare la propria vita a tarda notte per problemi banali che in primo luogo non avrebbero dovuto verificarsi. Inoltre, oltre alle dimensioni del database, tieni presente la capacità del disco del server. Non vuoi che la dimensione del disco sia troppo piccola rispetto a quella che può ospitare un database. Queste sono tutte cose semplici che tornano utili al momento della pianificazione. Tuttavia, come sapete, non è sempre un professionista del database che installa o configura i database in primo luogo. Il punto importante da notare è avere le basi giuste con il tuo database in termini di dimensionamento e potresti non aver mai bisogno di eseguire questo comando. Tuttavia, come sempre, come DBA, ci sono momenti in cui le cose potrebbero non essere sotto il tuo controllo e durante questo periodo puoi utilizzare i comandi DBCC Shrink file per un uso efficiente.

Quando posso utilizzare DBCC ShrinkFile?

Hai appena ricevuto un avviso di spazio su disco nel bel mezzo del sonno e devi rispettare SLA rigorosi. Il livello di priorità è un P2 e lo SLA potrebbe violare molto presto. E ti rendi conto che l'espansione del disco non avverrà presto, beh, in tal caso, tieni a portata di mano i comandi DBCC ShrinkFile in modo da poterli utilizzare per recuperare lo spazio. Come suggerisce il nome, riduce il file dei dati o il file di registro del database. Ma prima di iniziare a eseguire i comandi DBCC ShrinkFile, prova innanzitutto a verificare perché il file di database sta crescendo.

  • Il file è cresciuto a causa di una transazione di lunga durata?
  • C'è qualche tipo di blocco sul server?
  • C'è qualche rilascio importante dell'applicazione di cui non sei stato informato? (Questo accade la maggior parte delle volte)
  • C'è qualche tipo di problema di replica o mirroring del database che causa la crescita del database?

È importante ottenere risposte a queste domande il più rapidamente possibile. In generale, c'è una risposta a tutte queste domande ed è un ottimo strumento gratuito chiamato sp_whoisactive. Non ci sono parole per descrivere l'enorme uso di questo strumento e l'ho usato in più occasioni per risolvere numerosi problemi relativi alla produzione. Puoi scaricare il codice più recente da questo link:http://whoisactive.com/ . È facile e semplice da usare e restituisce l'output in pochissimo tempo. Se sei un DBA esperto, avrai già questo a tua disposizione.

File DBCC ShrinkFile con esempi

La sintassi per il DBCC ShrinkFile è semplice e diretta, fare riferimento a questo esempio di seguito.

use YOURDATABASE
go
DBCC Shrinkfile(FileName,1024)

L'esempio precedente riduce FileName appartenente a YOURDATABASE a 1024 MB. È possibile eseguire la stessa operazione utilizzando SQL Server Management Studio (SSMS). Fai clic con il pulsante destro del mouse sul database, vai su Attività , seleziona Riduci , quindi File .

Dopo aver fatto clic su File , otterrai questa finestra.

Qui hai la possibilità di selezionare il tipo di file:Dati, Registro o Dati del flusso di file ed eseguire l'azione "Riduci azione" come richiesto. È più facile utilizzare il comando DBCC stesso per scopi di riduzione.

Utilizzo di DBCC ShrinkFile con opzioni aggiuntive

Puoi eseguire il comando DBCC ShrinkFile con opzioni aggiuntive:emptyfile, notruncate o truncateonly.

File vuoto

Puoi usare il comando emptyfile come di seguito.

use YOURDATABASE
go
dbcc shrinkfile(FileName,emptyfile)

Ciò consentirà di spostare i dati in altri file all'interno dello stesso gruppo di file. Una volta terminato, sarai in grado di eliminare un file di database se non è più necessario. Tuttavia, ci sono alcune cose da notare con questa opzione emptyfile poiché non saresti in grado di fare molto per svuotare il contenuto del file di dati primario con ID file 1. Per ottenere il numero ID del file, esegui questo script.

select file_id, name,physical_name from sys.database_files

Qui, in questo esempio, il nome del file è "mo" e file_id è 1. Quando provi a svuotare il file mo che ha file_id 1, incontrerai questo messaggio di errore.

Questo perché ci sono informazioni di sistema all'interno del file originale, che non possono essere svuotate. Ma, se provi lo stesso comando sull'altro file di dati "mo2data", il comando del file vuoto avrà esito positivo.

Non eseguire

Come suggerisce il nome, non c'è spazio rilasciato per il sistema operativo. È più simile a un'operazione interna all'interno del file in cui le pagine vengono ridistribuite all'interno del file stesso senza modificare la dimensione complessiva del file di database. Per questo motivo, esiste un'enorme possibilità di introduzione della frammentazione. Vedi l'esempio qui sotto.

-- Example only  
Use YourDatabase		
go
DBCC SHRINKFILE (filename,notruncate);  
GO  

Solo troncare

Come suggerisce il nome, lo spazio libero verrà rilasciato al sistema operativo dalla fine del file. Questa è di gran lunga l'operazione più sicura che puoi eseguire utilizzando DBCC ShrinkFile. Vedi l'esempio qui sotto.

-- Example only  
Use YourDatabase		
go
DBCC SHRINKFILE (filename,truncateonly);  
GO  

Cosa fare quando DBCC ShrinkFile nel registro delle transazioni non funziona come previsto? Fare riferimento a questo metodo sicuro per risolvere il problema

Ci sono momenti in cui questo comando potrebbe non funzionare come previsto. Supponendo che tu abbia una situazione in cui stai cercando di ridurre il file di registro di un database e non sembra funzionare. Di seguito sono riportati alcuni dei passaggi che potresti eseguire per capire perché la riduzione non funziona come previsto. Noterai che il file di compattazione verrà visualizzato come riuscito, tuttavia, non vi è alcuna riduzione delle dimensioni del file di registro. In tal caso, esegui questo comando per verificare alcune cose sull'utilizzo del file di registro.

select name,log_reuse_wait_desc,* from sys.databases

Dallo screenshot, puoi vedere che la colonna log_reuse_wait_desc è in attesa del backup del registro.

Qui puoi vedere che il backup del registro per il database deve essere eseguito prima di poter davvero ridurre il file di registro. Se si trova su un database di produzione, provare a eseguire il backup del registro su un'altra unità in cui è disponibile spazio. Per eseguire il backup del registro, utilizzare il comando di esempio riportato di seguito.

backup log DBName to disk='C:\Program Files\Microsoft SQL Server\MSSQL15.A1\MSSQL\Backup\DBName.trn'
with init,stats,compression

Dopo aver eseguito il comando di backup, esegui nuovamente il comando seguente per vedere lo stato della colonna log_reuse_wait_desc.

select name,log_reuse_wait_desc,* from sys.databases

Dallo screenshot, puoi vedere che lo stato della colonna log_reuse_wait_desc è cambiato in "Niente".

Qui puoi vedere che lo stato della colonna "log_reuse_wait_desc" è cambiato in "Niente". Nel tuo caso, potrebbe ancora essere visualizzato come "LOG_BACKUP". Continuare a eseguire i backup dei log per il database finché lo stato non cambia in "Niente". Il motivo per cui potresti ancora visualizzare lo stato "LOG_BACKUP" anche dopo aver eseguito i backup del registro delle transazioni è perché nessun VLF potrebbe essere stato cancellato dopo aver eseguito il backup del registro delle transazioni. VLF sta per Virtual log files e fa parte dell'architettura interna del log delle transazioni. I file di registro delle transazioni sono costituiti da questi VLF. Puoi ottenere informazioni sui VLF eseguendo questo comando.

select * from sys.dm_db_log_info(5)

Qui 5 rappresenta il database_id. Viene visualizzata la schermata dell'output. Il numero di righe restituite rappresenta il numero effettivo di file di registro virtuali (VLF) nel database. È possibile controllare la colonna "vlf_status" per verificare lo stato del file di registro virtuale. Il valore 2 significa che è attivo. Con questo comando, puoi controllare i flag interni all'interno del file di registro delle transazioni per capire perché il registro delle transazioni non viene liberato anche dopo aver eseguito i backup del registro.

In precedenza, il comando utilizzato era DBCC LOGINFO che forniva informazioni simili.

Cosa fare quando DBCC ShrinkFile nel registro delle transazioni non funziona come previsto? Qualcosa che puoi eseguire in un ambiente non di produzione. Tuttavia, non consigliato in ambiente di produzione

Ti saresti imbattuto in più siti Web di persone che consigliavano di cambiare il modello di ripristino in uno semplice e quindi di eseguire un file di riduzione per liberare spazio nel sistema operativo. Tieni presente che la modifica del modello di ripristino in uno semplice influirà sul ripristino del database poiché non saresti in grado di eseguire il ripristino in un momento specifico. Anche questo dipende dal tuo SLA aziendale. Puoi modificare il modello di ripristino utilizzando T-SQL (sotto) o utilizzando la GUI.

alter database DB_NAME set recovery simple

Utilizzando la GUI, modificare il modello di ripristino come mostrato. Fare clic con il pulsante destro del database, andare su "Proprietà", fare clic su "Opzioni". In "Opzioni", seleziona il "Modello di ripristino".

Noterai che la semplice modifica del modello di ripristino in Semplice non rilascerà lo spazio sul sistema operativo. Dovresti eseguire in modo esplicito il comando DBCC ShrinkFile per ridurre il file e recuperare lo spazio. Vedere lo script di esempio di seguito. Questo comando ridurrà il tuo NomeFile a 1024 MB.

use YOURDATABASE
go
DBCC Shrinkfile(FileName,1024)

Opzione Riduci automaticamente database

Noterai che esiste un'opzione nota come "Riduci automaticamente" all'interno delle proprietà del database. Basta fare clic con il pulsante destro del database per visualizzare la proprietà del database. Nella sezione delle opzioni, vedrai questa opzione come mostrato. Dall'impostazione del database del modello, puoi vedere che l'opzione "Riduci automaticamente" è disabilitata per impostazione predefinita. Quindi, ogni volta che viene creato un nuovo database, anche questa opzione è disabilitata. Potrebbero esserci alcuni casi in cui i professionisti del database potrebbero inconsapevolmente lasciare questa opzione abilitata senza essere consapevoli delle conseguenze negative di lasciarla attiva.

Esegui questo comando per verificare lo stato di questa opzione per i database sul server.

select name,is_auto_shrink_on,* from sys.databases

Vedrai questo output.

Se per caso vedi che è abilitato, puoi disabilitarlo utilizzando la GUI oppure puoi eseguire il comando seguente sul database.

ALTER DATABASE YOUR_DATABASE set AUTO_SHRINK OFF

Altri suggerimenti per la manutenzione

Fare riferimento a questi pochi suggerimenti aggiuntivi per evitare il problema della crescita del database, a causa della quale è necessario eseguire i comandi DBCC ShrinkFile.

  • Assicurati che il modello di ripristino dei tuoi database sia allineato agli SLA aziendali. Se la tua azienda non richiede un ripristino point-in-time per i database di test, lasciali in un modello di ripristino semplice. Ho visto diverse occasioni in cui il modello di ripristino dei database era completo quando le cose andavano bene con il ripristino utilizzando l'ultimo backup completo
  • Garantire un monitoraggio adeguato, in particolare con la crescita del database. Dovresti essere avvisato quando l'utilizzo del file di registro raggiunge l'85%. Questo ti darà un po' di tempo per risolvere il problema dello spazio
  • Assicurati che vengano eseguiti backup dei log regolari se il database è nel modello di ripristino completo e dovresti essere avvisato se uno qualsiasi dei backup dei log non riesce
  • Assicurati che ci sia spazio sufficiente sulle unità del database per evitare problemi di spazio insufficiente
  • Per i database che possono essere archiviati, sviluppare alcune strategie di archiviazione in modo da poter spostare i dati meno recenti in un altro database per creare report e renderlo di sola lettura. Questo ti darà un maggiore controllo in termini di dimensionamento del database
  • Assicurati di eseguire regolarmente controlli di integrità sul tuo database utilizzando DBCC CheckDB. Per ulteriori informazioni, fare riferimento a questo articolo:https://codingsight.com/dbcc-checkdb-overview/

Conclusione

  • Da questo articolo, hai una buona conoscenza dell'utilizzo del comando DBCC ShrinkFile
  • Hai appreso dei rischi dell'esecuzione dei comandi DBCC ShrinkFile
  • Hai appreso le diverse opzioni che possiamo fornire utilizzando i comandi DBCC ShrinkFile
  • Hai visto le opzioni che possiamo provare se il registro delle transazioni non si riduce utilizzando i comandi DBCC ShrinkFile
  • Hai appreso dell'impostazione di riduzione automatica predefinita all'interno della proprietà del database
  • Hai anche appreso altri suggerimenti per la manutenzione dei database per mantenerli in salute
  • Infine, assicurati di essere comunque pronto per quei giorni OFF che potrebbero non essere sotto il tuo controllo