Di database corrotti ed aziende bloccate

Come nei migliori racconti noir, squilla il telefono, il volto di chi risponde cambia espressione.
Si sente il tono piu animato del solito.

Ecco immaginatevi una scena cosi e trasponetela nel mondo dell'informatica.

Chi risponde al telefono siete voi.
L'interlocutore misterioso un vostro grosso cliente, unico proprietario della megaditta.

Il motivo della discussione è presto detto.
Tutti sono fermi, nessuno riesce a lavorare.
Logistica ferma, fatturazione ferma produzione ferma!

E poi ... e poi siamo nella settimana centrale di agosto quindi anche la megaditta tra un giorno o due chiuderà.

La pressione che aveva già  iniziato a farsi sentite, diventa palpabile!

Ovviamente sono passati solo pochi battiti di ciglia ma siete già collegati sul server del vostro cliente!

Certo il vostro ufficio ė un ambiente fresco ma sulla vostra fronte fanno comunque capolino goccie di sudore: il database si è corrotto!

Ah, ecco perchè nessun riesce più a entrare nel vostro applicativo che gestisce tutti i flussi aziendali.

Calma e sangue freddo!

Torniamo ora nei panni dell'esperto SQL per dare le regole base ...direi addirittura mondiali!

Ogni istallazione di SQL server deve prevedere un piano di manutenzione.
Sempre.

Questo piano di manutenzione dovrà prevedere 3 attività:

1 Manutenzione del database (indici e statistiche)
2 Controllo integrità e Backup del database
3 Invio di una mail in caso di errori.

Sempre! Queste sono le regole basilari.

Mi è stato chiesto: ogni quanto tempo va fatto il backup?
La risposta è: qual è il periodo massimo in cui l'azienda può permettersi di non avere dati aggiornati?
Se non abbiamo gli ordini stamattina, nel pomeriggio dobbiamo fermare la produzione?
Un giorno, 12 ore, 6 ore, meno?

Ecco questa è la frequenza con cui fare il backup.

A corollario: fate il backup su un disco diverso da quello che ospita il database.
Se si dovesse rompere il disco che ospita il database avreste il disco del backup e viceversa.

Fatene una copia e portatela in un luogo diverso e sicuro e sarete al riparo anche da alluvioni ed incendi!

Parliamo anche della regola numero 3.
Il piano di manutenzione effettua un controllo dell'integrità del database e poi esegue il backup.
Domanda:
Se il controllo dell integrità fallisce a causa di un errore ma poi nessuno viene avvisato a cosa serve?
Ovviamente non serve a nulla.


Quindi,

Se il database si è corrotto ma abbiamo seguito tutte le regole di un corretto piano di manutenzione avremo a disposizione un backup integro e ce la caveremo con un semplice restore del database!

Tempo di fermo operativo basso e cliente contento!

Purtroppo vedo spesso che in realtà di dimensioni contenute queste regole vengono spesso disattese.
Tante, troppe volte quando si corrompe il database non viene avvisato, via mail, nessuno ... e qui iniziano i problemi!

Se l'unico backup che avete a disposizione è anch'esso corrotto oppure è troppo datato per essere utilizzato...

bhe, qui inizia a salire la pressione..

Nel prossimo articolo vi farò vedere come controllare se un database SQL Server ha dei problemi e come recuperare i dati, ma per adesso basta...

Come dicevo è la settimana centrale di agosto e vi vorrei immaginare tutti in relax sotto l'ombrellone!
 
Luca Biondi @ SQLServerPerformance blog!












Comments

I Post più popolari

SQL Server, execution plan and the lazy spool (clearly explained)

SQL Server, datetime vs. datetime2

La clausola NOLOCK. Approfondiamo e facciamo chiarezza!