Ecco un esempio di come SQL Catcher per SQL Server è stato applicato con successo, risolvendo una potenziale criticità prima che diventasse bloccante.
La situazione di partenza
Il nostro cliente è un’affermata azienda manifatturiera del vicentino. Lo stabilimento produttivo, dove sono ospitati anche gli uffici amministrativi, è dotato di infrastruttura database SQL Server. Su tale infrastruttura si appoggia il sistema informativo, in particolare il gestionale aziendale per gestione di clienti, ordini, fornitori e spedizioni.
L’infrastruttura, di realizzazione piuttosto recente, non veniva monitorata. Durante l’installazione dell’istanza di SQL Server erano state scelte le impostazioni di default, quindi tutte le componenti (sistema operativo, file dei database e file di log) erano state installate sul medesimo disco.
Il Tansaction Log
In SQL Server il Transaction Log è un file dove vengono registrate tutte le transazioni e tutte le modifiche apportate da ciascuna transazione, ovvero qualsiasi modifica dei dati scritti nel database. Si tratta di una componente fondamentale dell’infrastruttura database in quanto, in caso di errore del sistema, è essenziale per riportare i database ad uno stato di consistenza.
Si intuisce facilmente come il Transaction Log sia soggetto ad una crescita continua se i database vengono utilizzati, ovvero se utilizzano programmi che si appoggiano ai database. Per questo motivo vanno effettuati dei backup periodici, in seguito ai quali si ‘pulisce’ il file di log, evitando che cresca a dismisura. Microsoft consiglia frequenti backup del file di Log sia per ridurre al minimo il rischio di perdita di dati e quindi del lavoro effettuato, che per troncare il file di Log, in modo da evitare appunto che raggiunga dimensioni eccessive.
Come abbiamo visto, il corretto svolgimento dell’operazione di backup del Log fa sì che il file di Log venga svuotato e non continui a crescere in modo indiscriminato. Nel caso in esame, non era stato impostato un backup del Transaction Log nel database di produzione. Di conseguenza, il file di log stava continuando a crescere, senza mai essere controllato o troncato, in quanto non era stata impostata nemmeno una dimensione massima del file.
La segnalazione di SQL Catcher
Quando l’azienda ha deciso di iniziare il monitoraggio con SQL Catcher, ha individuato immediatamente il problema, già con il primo controllo effettuato subito dopo l’avvio dell’applicazione per la prima volta. SQL Catcher ha infatti segnalato subito la mancanza del backup del Transaction Log.
Inoltre, è stato rilevato che questa mancanza aveva provocato la crescita del file di Log fino a dimensioni di svariati gigabyte, rischiando di saturare lo spazio su disco e di impedire il riavvio della macchina su cui era installato Windows Server.
La soluzione applicata in azienda
Una volta individuata la problematica, è stato possibile intervenire in modo mirato per risolverla. Siamo quindi stati chiamati a configurare un corretto backup del Transaction Log, operazione che può essere portata a termine anche in SQL Server Server Management Studio.
In questo modo si può salvaguardare lo spazio su disco, avendo sempre un file di Log aggiornato e pronto da utilizzare in caso di necessità.
di Alice Sella, pubblicato il 13 ottobre 2021
