I controlli di SQL Catcher: backup

Datamaze
10.03.21 02:28 PM Comment(s)

I controlli che esegue SQL Catcher per SQL Server

Inauguriamo una nuova serie di articoli in cui passeremo in rassegna tutti i controlli che vengono eseguiti da SQL Catcher, in modo tale da capire l’importanza che certe verifiche assumono nel garantire l’efficienza della nostra istanza SQL Server e la sicurezza dei dati in essa memorizzati.


Inoltre questa rassegna vuole mettere in luce l’importanza che uno strumento come SQL Catcher può avere nell’attività quotidiana di un database administrator o, in mancanza di una figura dedicata, di un responsabile IT di un’azienda.


Tutti i controlli che vengono fatti sono, per nostra esperienza, estremamente importanti e andrebbero fatti su una base giornaliera. Questo comporta tuttavia un discreto dispendio di tempo da parte della risorsa dedicata, con il rischio che alcuni controlli vengano dimenticati o non eseguiti in modo corretto.


Le segnalazioni che vengono fornite da SQL Catcher nella versione giornaliera, per comodità e per coerenza di argomento, vengono suddivise in quattro macrocategorie:

  • Backup
  • Database
  • Attività schedulate
  • Avvisi e notifiche importanti


Vediamo in dettaglio i controlli della categoria backup.


Backup

E’ facilmente comprensibile a tutti che l’integrità e la sicurezza dei dati passano per un piano di esecuzione dei backup dei database SQL Server che sia ben schedulato e funzionante, al fine di garantire la continuità operativa dell’azienda. 


SQL Catcher esegue i seguenti controlli in merito a questo argomento.


Controllo presenza Full Backup

Ogni giorno verifichiamo che vi siano dei backup di tipo Full eseguiti per ogni database. Verrà comunicato all’utente se esistono dei database a cui non è mai stato fatto un full backup oppure dei database con full backup più vecchi di 24 ore.


Ricordiamo che il backup di tipo Full effettua il backup di tutti i dati e di tutti gli oggetti (indici, tabelle, store procedures, views, etc etc) presenti all’interno del database.


Per i database impostati in Full Recovery Model, il Full Backup rappresenta la base su cui impostare tutta la catena dei backup del transaction log.


Controllo Transaction Log Backup

Per tutti i database impostati in Full Recovery Model (gli unici per cui ha senso l’esistenza di un transaction log da preservare e gestire) verifichiamo l’esistenza di un Transaction Log Backup.


Avvisiamo quindi se non esiste tale backup oppure se tale backup è più vecchio di 24 ore rispetto al corrispondente Full Backup.


Di norma ci si aspetta che il backup del transaction log venga effettuato più volte nel corso di una giornata, sia per garantire la possibilità di ripristinare lo stato del database ad un preciso momento, sia per mantenere contenute le dimensioni del file di log.


Ricordiamo che eseguire frequenti backup del log delle transazioni permette un ripristino dei dati quanto più vicino al momento precedente un possibile disastro.


Inoltre i file di log tendono a crescere in alcuni casi in modo molto veloce (dipende dalla quantità e dalla tipologia di operazioni che vengono eseguite sul database), portando tali file a dimensioni molte volte considerevoli, soprattutto se lasciati nel dimenticatoio.


L’operazione di backup del log fa sì che il file di log venga svuotato e non continui a crescere in modo indiscriminato. Non di rado ci è capitato di trovare da clienti file di log che hanno raggiunto la dimensione massima impostata in fase di configurazione (generando quindi un errore di saturazione del file di log) oppure di dimensioni di svariati gigabyte (quando in fase di configurazione iniziale non si è impostato un valore massimo di dimensione del file), saturando lo spazio su disco.


Controllo cambio recovery model

Ogni volta che SQL Catcher viene eseguito, viene verificato se vi sono dei database a cui è stato cambiato il recovery model rispetto al controllo precedente. Anche questo controllo riveste una sua importanza. Non di rado ci è capitato di notare cambiamenti accidentali o non consapevoli del recovery model, mettendo a rischio l’integrità di database che rivestono un ruolo determinante nell’economia dell’azienda. Ci sembra quindi corretto evidenziare all’utente questa variazione, in modo tale da renderlo consapevole delle scelte fatte da lui o da terzi.


Prova subito SQL Catcher


I controlli dei database


I controlli delle attività schedulate


I controlli generali


di Matteo Dal Bianco, pubblicato il 10 marzo 2021

SQL Server al top con SQL Catcher