Il mantenimento di database 24x7 è un argomento piuttosto ampio con molte opzioni da considerare. Questo ampio argomento ha molti elementi da considerare, ma possiamo provare a toccare la base su alcuni dei punti più alti.
Quello che prima vorresti identificare è, mentre molte operazioni sono 24x7, di solito ci sono periodi di bassa attività. È possibile sfruttare questi tempi per l'esecuzione della manutenzione in modo da ridurre l'interferenza che si avrà sul database. Il secondo è che dovrai riservare del tempo per interruzioni complete (per cose come service pack o migrazioni di database), quindi dovrai negoziare le finestre di manutenzione completa con la tua direzione. Per elementi specifici dovrai considerare e pianificare ognuno di essi, oltre a sfruttare gli strumenti in modo appropriato. Il pezzo importante è che devi PIANIFICARE ciascuno di questi, tutti gli esempi che fornisco sono molto "le tue miglia possono variare".
I backup
I backup in genere non avranno un impatto enorme sui carichi di lavoro, ma devono essere considerati in quanto possono consumare molto I / O. Ti consigliamo di pianificare questi in modo appropriato e monitorare il tempo necessario per il completamento. Il più grande ostacolo qui è che in un'operazione 24x7, probabilmente non sarai in grado di eseguire backup notturni completi ogni notte della settimana. Ti consigliamo di pianificare quando puoi prendere il pieno, quando stai prendendo i differenziali e i periodi di conservazione per entrambi in combinazione con i tuoi backup del registro.
Ad esempio, eseguo backup completi di tutti i miei database la domenica sera (attività più bassa), i differenziali in tutte le altre notti (dal lunedì al sabato). Tengo le ultime due settimane di full e diff su disco, registri per gli ultimi due giorni. Questo mi dà abbastanza flessibilità per il recupero, ma potrei dover recuperare i backup dal nastro, se necessario.
Manutenzione indice / statistiche
Questo è il tipo più comune di manutenzione attiva che dovrai affrontare. Non puoi evitarlo, ma puoi mitigare l'impatto. La regola empirica iniziale è che si dovrebbe fare solo manutenzione sugli oggetti che ne hanno bisogno. Le linee guida generali sono solo per ricostruire gli indici che sono frammentati più del 30% e più grandi di 1000 pagine . Se disponi di statistiche di aggiornamento automatico , questo gestirà la maggior parte della manutenzione delle statistiche, ma un lavoro notturno per mantenere le cose sincronizzate non è una cattiva idea.
Se hai Enterprise Edition, hai anche accesso ad alcune altre opzioni per la gestione della manutenzione. Il più importante è Ricostruzioni di indici online , che ti permetteranno di ricostruire gli indici mentre sono ancora in uso (essenzialmente, costruisce l'indice fianco a fianco, quindi lo scambia). È inoltre possibile sfruttare il partizionamento per tabelle "di grandi dimensioni" per ridurre il tempo necessario per la ricostruzione.
La soluzione migliore per questo tipo di manutenzione, se non si dispone di script personalizzati che gestiscono queste best practice, è utilizzare gli script di manutenzione di Ola Hallengren . Questi sono abbastanza facili da installare e configurare e hanno molte di queste linee guida integrate.
Controlli di coerenza DBCC
A seconda del carico di lavoro complessivo, è possibile che i controlli DBCC siano dannosi per l'operazione. Esistono due modi comuni per ridurre al minimo l'impatto di DBCC per i database:
PHYSICAL_ONLY- L'esecuzione di questa opzione controllerà i database a livello di pagina fisica ed eviterà il controllo completo più invasivo. Ciò riguarderà l'identificazione dei tipi più probabili di corruzione.- Verifica di una copia ripristinata: se si dispone dello spazio, è possibile ripristinare il database in un'altra istanza ed eseguire un controllo DBCC sulla copia ripristinata. Questo racconterà la stessa storia sul tuo database live, ma ovviamente non interferirai con l'attività. Alcune altre alternative qui eseguono DBCC su una copia di log o su un db con mirroring.
Questo post sul blog fornisce maggiori dettagli sulle tue opzioni.
Lavori in lotti / ETL
Questo dipende davvero da come progetti i tuoi processi. Il tuo ETL può sempre interferire con le tabelle OLTP live (proprio come qualsiasi altra applicazione), quindi alcune chiavi da tenere a mente:
- Pianifica tale lavoro intorno ad altri interventi di manutenzione e in periodi di bassa attività.
- Ridimensiona il lavoro in modo che sia batch per entrambe le prestazioni e in modo che il batch non sia così grande da bloccare il tavolo per ore. Esempi delle estremità dello spettro: riga per riga agonizzante (RBAR) rispetto a un singolo milione di righe eliminate.
- Utilizzare le tabelle degli stage e offline l'elaborazione dei dati, ove appropriato. Tocca le cose dal vivo solo quando assolutamente necessario.
Conclusione
Ancora una volta, c'è un sacco di terreno da coprire qui. Questa non è una guida completa, ma una panoramica di alto livello di alcuni approcci. Non ho nemmeno discusso delle opzioni di disponibilità elevata (come gruppi di disponibilità e clustering di failover). Dovrai rivedere ogni articolo e costruire un piano su come gestirlo. In molti modi, dovrai anche iterare e perfezionare il tuo lavoro mentre avanzi.
Risorse addizionali:
Best practice per la manutenzione di SQL Skills VLDB