I controlli di SQL Catcher: database

Tramite questa sezione SQL Catcher porta evidenza all’utente una serie di informazioni significative relative allo stato dei file dei database e alcune configurazioni dei database stessi.

Ricordiamo che un database è solitamente composto da file di dati con estensione .mdf (possono esistere anche file di dati secondari con estensione .ndf) e da uno o più file di log con estensione .ldf.

I file di dati contengono i dati memorizzati nel database e tutta una serie di oggetti del database, come tabelle, indici, store procedures e views.

I file di log invece registrano tutte le transazioni e le modifiche al database fatte dalle transazioni stesse.

Se non esplicitamente impostato in fase di creazione del database, i file di dati e i file di log vengono salvati da SQL Server su un percorso fisico su disco di default. Tale percorso di default è specificato a livello di configurazione di istanza.

Vediamo nel dettaglio i vari controlli.

Controlliamo per tutti i file di log lo spazio allocato su disco e l’effettivo spazio utilizzato nel file di log. Come abbiamo accennato in precedenza il file di log può crescere molto nel tempo. 

Al crescere delle dimensioni del file di log, a seconda delle impostazioni, SQL Server può allocare ulteriore spazio su disco per il file. Se successivamente avviene un’operazione di truncate del file (come per esempio quando viene effettuato un transaction log backup), questa operazione svuota il file di log per permettere successive registrazioni ma non va a toccare la dimensione del file precedentemente allocata.

Questo può portare alla presenza di file di log con dimensioni allocate eccessivamente grandi rispetto all’effettivo utilizzo (riempimento) del file di log. In questi casi potrebbe essere consigliata un’operazione di shrink del file in modo da deallocare spazio su disco non utilizzato.

È evidente la necessità di avere sempre costantemente monitorata la situazione appena descritta, onde evitare saturazioni dei dischi e capire se le impostazioni iniziali per il file di log siano state scelte correttamente.

Si tratta di un controllo molto legato, come finalità, al controllo precedente.

Controlliamo infatti per tutti i file di log le relative dimensioni e le confrontiamo con i rispettivi file di dati. Segnaliamo all’utente se esistono file di log con dimensioni maggiori rispetto al file di dati. Tale evento non deve per forza avere una valenza negativa. 

Tuttavia tale fenomeno può essere sintomo di un transaction log backup che non viene effettuato da tempo (operazione che se fatta con la giusta frequenza evita che al file di log venga allocato spazio eccessivo) oppure la necessità di effettuare un’operazione di shrink in quanto il file ha assunto dimensioni troppo elevate.

Per ogni database verifichiamo, sia per i file di dati che per i file di log, se vi è stata una crescita maggiore del 5% rispetto all’ultimo controllo effettuato con SQL Catcher.

Nel caso positivo avvisiamo l’utente con una segnalazione. Anche questo controllo ha finalità di tenere monitorata la crescita giornaliera dei database e di portare all’attenzione dell’utente delle crescite che, se ripetute nel tempo, possono essere anomale o dovute a cattive configurazioni oppure portare a saturazione dello spazio su disco in modo inaspettato.

• Per tutti i database presenti nell’istanza monitorata, verifichiamo ad ogni controllo se vi sono stati dei cambi di configurazione rispetto al controllo precedente.

  Nello specifico segnaliamo all’utente se sono cambiati i seguenti parametri che riteniamo importanti:

  • Stato del database: se il database è stato messo offline/online.
  • AutoClose: quando è abilitata, tale impostazione  può provocare una riduzione delle prestazione nei database cui si accede di frequente a causa dell'aumento di overhead dovuto all'apertura e alla chiusura del database dopo ogni connessione.
  • AutoShrink: quando è abilitata, il database diventa oggetto, attraverso un task in background, dell'operazione di compattazione. Il task valuta periodicamente tutti i database che hanno questa opzione attivata ed esegue l'operazione di compattazione dei rispettivi file dati e/o dei transaction log (nel caso dei log, la compattazione avviene solo se il recovery model del database è impostato a SIMPLE oppure se è stato fatto un backup del log). Lo shrink avviene solo se lo spazio inutilizzato all'interno del file è superiore al 25%. La dimensione viene conseguentemente ridotta del 25% senza superare il limite definito dalla dimensione del file al momento della sua creazione.
  • PageVerify: quando l’opzione è impostata in CHECKSUM, SQL Server calcola un checksum sul contenuto dell'intera pagina e archivia il valore nell'intestazione di pagina stessa quando questa viene scritta sul disco. Quando si esegue la lettura della pagina dal disco, il checksum viene ricalcolato e confrontato con il valore di checksum archiviato nell'intestazione della pagina. In questo modo viene garantito un livello elevato di integrità dei file di dati. 
    
    

Ad ogni controllo, verifichiamo se ci sono nuovi database o se sono stati rimossi dei database rispetto al controllo precedente e avvisiamo di conseguenza l’utente.

In caso di presenza di nuovi database, solo per la prima volte che li segnaliamo, aggiungiamo una serie di informazioni di configurazione che riteniamo importanti. Nello specifico segnaliamo:

• Stato del database, AutoClose, AutoShrink e PageVerify: l’importanza di queste informazioni è già stata evidenziata nel controllo precedente.
• AutoGrowth: è un’impostazione utilizzata da SQL Server per aumentare la dimensione dei file di dati e dei file di log nel momento in cui lo spazio su tali file si è esaurito. Si tratta di un’operazione bloccante e quindi, quando avviene, tutte le transazioni sul database vengono momentaneamente fermate e riprese solamente ad operazione ultimata. Non vi è un’impostazione univoca per tutti i database, va studiata in base al singolo caso (in base alla quantità e tipologie di operazioni che avvengono sul database) ma è evidente che va configurata nel modo corretto onde evitare eccessive operazioni di aumento dello spazio dei file e quindi di rallentamenti nell’operatività. L’aumento di spazio può essere configurato in base percentuale (es. applicare un aumento del 10% della dimensione del file quando si sta per saturare lo spazio) oppure esplicitando la dimensione in MB (es. aumentare di 200MB lo spazio su file quando si sta per saturare lo spazio).
• Percorso su disco dei file di dati e dei file di log: ci sembra corretto evidenziare il percorso su disco dove sono stati memorizzati i file di dati e i file di log. Come accennato in fase introduttiva di questa sezione, se non diversamente esplicitato, i file di dati e i file di log vengono salvati da SQL Server su un percorso di default impostato a livello di configurazione di istanza. Tuttavia un singolo database può essere configurato con dei percorsi specifici, in base alle necessità o alle scelte architetturali.
• Dimensione dei file di dati e dei file di log: riportiamo le dimensioni dei file di dati e dei file di log nel momento in cui troviamo un nuovo database. Serve a dare contezza immediata all’utente della quantità di dati (e spesso dell’importanza) memorizzata sul database.
• Compatibility Level del database: per tutte le installazioni di SQL Server, il livello di compatibilità predefinito è associato alla versione di SQL Server. Per i nuovi database viene impostato questo livello, a meno che per il database model non sia impostato un livello di compatibilità inferiore. Per i database collegati o ripristinati da una qualsiasi versione precedente di SQL Server, il database mantiene il livello di compatibilità esistente, se questo è almeno il livello minimo consentito per quell'istanza di SQL Server. Se si sposta un database con un livello di compatibilità inferiore a quello consentito da SQL Server, il database viene automaticamente impostato sul livello di compatibilità più basso consentito. Questo comportamento si applica sia ai database di sistema che ai database utente. Risulta quindi importante evidenziare in prima battuta il livello di compatibilità del database preso in esame, al fine di capire se è allineato o meno al livello di compatibilità dell’istanza SQL Server. di Matteo Dal Bianco, pubblicato il 7 aprile 2021
• Stato del database, AutoClose, AutoShrink e PageVerify: l’importanza di queste informazioni è già stata evidenziata nel controllo precedente.
• AutoGrowth: è un’impostazione utilizzata da SQL Server per aumentare la dimensione dei file di dati e dei file di log nel momento in cui lo spazio su tali file si è esaurito. Si tratta di un’operazione bloccante e quindi, quando avviene, tutte le transazioni sul database vengono momentaneamente fermate e riprese solamente ad operazione ultimata. Non vi è un’impostazione univoca per tutti i database, va studiata in base al singolo caso (in base alla quantità e tipologie di operazioni che avvengono sul database) ma è evidente che va configurata nel modo corretto onde evitare eccessive operazioni di aumento dello spazio dei file e quindi di rallentamenti nell’operatività. L’aumento di spazio può essere configurato in base percentuale (es. applicare un aumento del 10% della dimensione del file quando si sta per saturare lo spazio) oppure esplicitando la dimensione in MB (es. aumentare di 200MB lo spazio su file quando si sta per saturare lo spazio).
• Percorso su disco dei file di dati e dei file di log: ci sembra corretto evidenziare il percorso su disco dove sono stati memorizzati i file di dati e i file di log. Come accennato in fase introduttiva di questa sezione, se non diversamente esplicitato, i file di dati e i file di log vengono salvati da SQL Server su un percorso di default impostato a livello di configurazione di istanza. Tuttavia un singolo database può essere configurato con dei percorsi specifici, in base alle necessità o alle scelte architetturali.
• Dimensione dei file di dati e dei file di log: riportiamo le dimensioni dei file di dati e dei file di log nel momento in cui troviamo un nuovo database. Serve a dare contezza immediata all’utente della quantità di dati (e spesso dell’importanza) memorizzata sul database.
• Compatibility Level del database: per tutte le installazioni di SQL Server, il livello di compatibilità predefinito è associato alla versione di SQL Server. Per i nuovi database viene impostato questo livello, a meno che per il database model non sia impostato un livello di compatibilità inferiore. Per i database collegati o ripristinati da una qualsiasi versione precedente di SQL Server, il database mantiene il livello di compatibilità esistente, se questo è almeno il livello minimo consentito per quell'istanza di SQL Server. Se si sposta un database con un livello di compatibilità inferiore a quello consentito da SQL Server, il database viene automaticamente impostato sul livello di compatibilità più basso consentito. Questo comportamento si applica sia ai database di sistema che ai database utente. Risulta quindi importante evidenziare in prima battuta il livello di compatibilità del database preso in esame, al fine di capire se è allineato o meno al livello di compatibilità dell’istanza SQL Server. di Matteo Dal Bianco, pubblicato il 7 aprile 2021
• Stato del database, AutoClose, AutoShrink e PageVerify: l’importanza di queste informazioni è già stata evidenziata nel controllo precedente.
• AutoGrowth: è un’impostazione utilizzata da SQL Server per aumentare la dimensione dei file di dati e dei file di log nel momento in cui lo spazio su tali file si è esaurito. Si tratta di un’operazione bloccante e quindi, quando avviene, tutte le transazioni sul database vengono momentaneamente fermate e riprese solamente ad operazione ultimata. Non vi è un’impostazione univoca per tutti i database, va studiata in base al singolo caso (in base alla quantità e tipologie di operazioni che avvengono sul database) ma è evidente che va configurata nel modo corretto onde evitare eccessive operazioni di aumento dello spazio dei file e quindi di rallentamenti nell’operatività. L’aumento di spazio può essere configurato in base percentuale (es. applicare un aumento del 10% della dimensione del file quando si sta per saturare lo spazio) oppure esplicitando la dimensione in MB (es. aumentare di 200MB lo spazio su file quando si sta per saturare lo spazio).
• Percorso su disco dei file di dati e dei file di log: ci sembra corretto evidenziare il percorso su disco dove sono stati memorizzati i file di dati e i file di log. Come accennato in fase introduttiva di questa sezione, se non diversamente esplicitato, i file di dati e i file di log vengono salvati da SQL Server su un percorso di default impostato a livello di configurazione di istanza. Tuttavia un singolo database può essere configurato con dei percorsi specifici, in base alle necessità o alle scelte architetturali.
• Dimensione dei file di dati e dei file di log: riportiamo le dimensioni dei file di dati e dei file di log nel momento in cui troviamo un nuovo database. Serve a dare contezza immediata all’utente della quantità di dati (e spesso dell’importanza) memorizzata sul database.
• Compatibility Level del database: per tutte le installazioni di SQL Server, il livello di compatibilità predefinito è associato alla versione di SQL Server. Per i nuovi database viene impostato questo livello, a meno che per il database model non sia impostato un livello di compatibilità inferiore. Per i database collegati o ripristinati da una qualsiasi versione precedente di SQL Server, il database mantiene il livello di compatibilità esistente, se questo è almeno il livello minimo consentito per quell'istanza di SQL Server. Se si sposta un database con un livello di compatibilità inferiore a quello consentito da SQL Server, il database viene automaticamente impostato sul livello di compatibilità più basso consentito. Questo comportamento si applica sia ai database di sistema che ai database utente. Risulta quindi importante evidenziare in prima battuta il livello di compatibilità del database preso in esame, al fine di capire se è allineato o meno al livello di compatibilità dell’istanza SQL Server. di Matteo Dal Bianco, pubblicato il 7 aprile 2021
• Stato del database, AutoClose, AutoShrink e PageVerify: l’importanza di queste informazioni è già stata evidenziata nel controllo precedente.
• AutoGrowth: è un’impostazione utilizzata da SQL Server per aumentare la dimensione dei file di dati e dei file di log nel momento in cui lo spazio su tali file si è esaurito. Si tratta di un’operazione bloccante e quindi, quando avviene, tutte le transazioni sul database vengono momentaneamente fermate e riprese solamente ad operazione ultimata. Non vi è un’impostazione univoca per tutti i database, va studiata in base al singolo caso (in base alla quantità e tipologie di operazioni che avvengono sul database) ma è evidente che va configurata nel modo corretto onde evitare eccessive operazioni di aumento dello spazio dei file e quindi di rallentamenti nell’operatività. L’aumento di spazio può essere configurato in base percentuale (es. applicare un aumento del 10% della dimensione del file quando si sta per saturare lo spazio) oppure esplicitando la dimensione in MB (es. aumentare di 200MB lo spazio su file quando si sta per saturare lo spazio).
• Percorso su disco dei file di dati e dei file di log: ci sembra corretto evidenziare il percorso su disco dove sono stati memorizzati i file di dati e i file di log. Come accennato in fase introduttiva di questa sezione, se non diversamente esplicitato, i file di dati e i file di log vengono salvati da SQL Server su un percorso di default impostato a livello di configurazione di istanza. Tuttavia un singolo database può essere configurato con dei percorsi specifici, in base alle necessità o alle scelte architetturali.
• Dimensione dei file di dati e dei file di log: riportiamo le dimensioni dei file di dati e dei file di log nel momento in cui troviamo un nuovo database. Serve a dare contezza immediata all’utente della quantità di dati (e spesso dell’importanza) memorizzata sul database.

Compatibility Level del database: per tutte le installazioni di SQL Server, il livello di compatibilità predefinito è associato alla versione di SQL Server. Per i nuovi database viene impostato questo livello, a meno che per il database model non sia impostato un livello di compatibilità inferiore. Per i database collegati o ripristinati da una qualsiasi versione precedente di SQL Server, il database mantiene il livello di compatibilità esistente, se questo è almeno il livello minimo consentito per quell'istanza di SQL Server. Se si sposta un database con un livello di compatibilità inferiore a quello consentito da SQL Server, il database viene automaticamente impostato sul livello di compatibilità più basso consentito. Questo comportamento si applica sia ai database di sistema che ai database utente. Risulta quindi importante evidenziare in prima battuta il livello di compatibilità del database preso in esame, al fine di capire se è allineato o meno al livello di compatibilità dell’istanza SQL Server. 

Prova subito SQL Catcher

I controlli sui backup

I controlli sulle attività schedulate

I controlli generali

di Matteo Dal Bianco, pubblicato il 7 aprile 2021