Un'altra tabella persa? SQL DBA in soccorso

Chiunque impegnato in un ruolo IT ha due tipi di giornate lavorative. I giorni “sì” sono contraddistinti da nassuno che ha bisogno di supporto, in questi giorni puoi  dedicarti alla iniziative di business strategiche che ti sono state assegnate per migliorare e rendere più efficiente il funzionamento del business stesso. I giorni “no” sono invece afflitti da una lunga serie di interruzioni sotto forma di “ticket” o di richieste provenienti da differenti dipartimenti che hanno urgentemente bisogno del tuo aiuto per tornare ad essere operativi. Qualsiasi buon Database Administrator (DBA) ha più giorni “no” che “sì” poichè il restore di tabelle/righe SQL è un impegno settimanale, se non addirittura giornaliero.

Perchè succede? Le ragioni sono innumerevoli... Il team finance a un certo punto di un report ha iniziato ad utilizzate una valuta errata o un tasso di cambio sbagliato e ora ha bisogno di apportare delle correzioni. Uno sviluppatore ha cancellato una tabella. Durante una routine di update del sistema un admin ha eliminato delle righe che si pensava non essere importanti e invece si scopre che tali righe sono utilizzate da molte altre tabelle e che hanno causato un fail del sistema. La lista potrebbe essere molto più lunga.

Una volta che il problema è stato identificato, sei chiamato a risolverlo. Scommetto che il tuo approccio segue in generale questo schema... Per prima cosa, cerchi di determinare l’ultima volta nella quale i dati erano corretti. Poi, trovi un backup che contiene il dabase con la tabella (tabelle) con i dati “buoni”. Sarà necessario il restore dell’intero database. Questo processo richiede di trovare un server SQL e sufficiente spazio di storage. Il restore di un database può richiedere molti minuti, ma sai fin troppo bene che generalmente sono richieste ore o addirittura molte ore, dipende dalla dimensione del database.

Il processo richiede inoltre un monitoraggio frequente e tu hai un costo per ora! Al termine del restore del database, verifichi se la tabella desiderata è presente. Altrimenti, continui nel restore dei database fino a trovare la tabella voluta, corretto? E una volta trovata, la copi nell’ambiente di produzione utilizzando degli script. Se poi ad essere inutilizzabile è un’applicazione critica per il fatturato dell’organizzazione, tutto quanto sopra descritto si svolge con il CIO che osserva appena dietro alle tue spalle.

Articolo di Tom McCaffrey - Come Product Director, Enterprise Solutions presso Kroll Ontrack, Tom McCaffrey è responsabile della linea di prodotti software per il restore granulare da SQL, Exchange e SharePoint. Tom è impegnato con il suo team ad aiutare i clienti nel risparmiare tempo e denaro rispetto ai metodi convenzionali di restore. Nei precedenti ruoli in Kroll Ontrack, Tom è stato responsabile di partnership strategiche e di prodotti enterprise per l'archiviazione e l'ediscovery. Prima di entrare in Kroll Ontrack nel 2009, Tom ha trascorso 10 anni nella gestione e nel lancio di nuovi prodotti nei settori data storage e telecomunicazioni.