Piano di manutenzione del server SQL - Best practice su attività e pianificazione

Ho il compito di elaborare un piano di manutenzione per i nostri database SQL Server 2005. So che per i backup voglio fare un backup completo giornaliero del database e backup del log transazionale ogni 15 minuti. Il mio problema arriva a capire quali altri compiti voglio svolgere e con quale frequenza dovrei svolgerli.

Quindi, finora ho questo in mente. Correggimi se ci sono difetti nel mio pensiero o un modo migliore per farlo.

1. Backup: tutte le tabelle, backup completo (giornaliero)
2. Backup: tabelle selezionate, backup completo (orario)
3. Backup: registri delle transazioni (ogni 15 minuti)
4. Verifica integrità del database (ogni giorno)
5. Riorganizza indice (ogni giorno)
6. Aggiorna statistiche (ogni giorno)
7. Riduci database (settimanale)
8. Ricostruisci indice (settimanale)
9. Pulizia di manutenzione (giornaliera)

Mi sono ricordato di aver letto qualche tempo fa (quando ho impostato un piano simile in un altro lavoro) che alcune di queste attività non devono essere eseguite su base giornaliera o non devono essere eseguite quotidianamente. Quanto a quelli, mi sfugge. Potrei usare una piccola guida per creare un miglior piano di manutenzione che ridurrà la perdita di dati in caso di disastro, ma non tasserà il sistema durante le ore di punta (e aumenterà anche le prestazioni).

Josh,

Questo è un compito molto comune per tutti i DBA e la risposta giusta NON è la stessa per tutti e per ogni server. Come molte altre cose, dipende da ciò di cui hai bisogno.

Sicuramente non vuoi eseguire "Shrink Database" come già suggerito. Il suo MALE alle prestazioni e il riferimento sottostante ti mostreranno il perché. Causa la frammentazione del disco e dell'indice e questo può portare a problemi di prestazioni. Stai meglio pre-allocando una grande dimensione per i dati e i file di registro in modo che la crescita automatica NON inizi.

Non ho capito il tuo numero 2. tabelle selezionate backup completo. Puoi approfondire di più su questo?

Venendo a Index riorganizzare, aggiornare le statistiche e ricostruire gli indici, è necessario fare attenzione a come si fa altrimenti si finirà per utilizzare più risorse e anche per finire con problemi di prestazioni.

Quando si ricostruiscono gli indici, le statistiche degli indici vengono aggiornate con fullscan, ma se si aggiornano successivamente le statistiche, queste verranno nuovamente aggiornate con un campione predefinito (che dipende da diversi fattori, in genere il 5% della tabella quando le dimensioni della tabella> 8 MB) che possono causare problemi di prestazioni. A seconda dell'edizione che hai, potresti essere in grado di fare ricostruzioni di indici online. Il modo giusto di fare questa attività è controllare la quantità di frammentazione e, a seconda di ciò, fare la ricostruzione dell'indice o riorganizzare l'indice + aggiornare le statistiche. Inoltre, potresti voler identificare quali tabelle devono aggiornare le statistiche più frequentemente e provare ad aggiornare le statistiche più spesso.

I piani di manutenzione sono OK, ma è difficile ottenere il meglio da loro facendo queste personalizzazioni a meno che non sia possibile accedere a SSIS e modificare i MP. ecco perché preferisco NON usarli e usare gli script gratuiti di Ola Hallengren che sono più robusti di quelli di MP. Inoltre, consiglierei di recuperare l'articolo di riferimento di Paul Randal su questo argomento.

Rif: http://technet.microsoft.com/en-us/magazine/2008.08.database.aspx

Questa NON è una risposta completa alla tua domanda, ma un buon punto di partenza. HTH e facci sapere se hai ulteriori domande / commenti.

Condividerò la mia esperienza, anche se hai già accettato una risposta. Forse sarà utile :-).

1. Backup giornaliero completo (giornaliero): eccezionale, ma non dimenticare di controllare lo spazio e rimuovere i vecchi file dopo un periodo di tempo predefinito.
2. Esegui il backup delle tabelle selezionate (ogni ora): non capisci perché ne avresti bisogno, ti conviene fare backup differenziali. Come si esegue il backup solo di determinate tabelle: SSIS, script, bcp? Per quanto riguarda i backup diff, non pianificarli troppo spesso, poiché ruberai il ruolo dei backup dei log.
3. Backup del registro delle transazioni (ogni 15 minuti): fantastico, sei sicuro di aver bisogno di tutti i database? Tutti i database utilizzano il modello di recupero completo o no?
4. Controlla l'integrità di db: sì, ma devi assicurarti di non uccidere il tuo ambiente. Le dichiarazioni di controllo DBCC sono piuttosto egoistiche sulle risorse e scansionano dbs completi, quindi devono essere programmate durante le ore non lavorative.
5. Riorganizza l'indice (quotidianamente): non forzarlo, fallo solo se necessario. Controlla l'indice DMV per quanto riguarda la frammentazione e riorganizza solo in base alle esigenze. Sposterei tutte le operazioni di indice e statistiche su una singola attività settimanale.
6. Aggiorna statistiche (quotidianamente): consulta la mia risposta a una domanda precedente. Invece di forzare l'aggiornamento di tutte le statistiche, ogni giorno, è meglio controllare quando le statistiche sono state aggiornate e solo in alcuni casi aggiornarle.
7. Riduci database (settimanale) - Oh, no. Si prega di leggere l' articolo di Paul Randal in merito alla riduzione dei file.
8. Ricostruisci indice (settimanale) - vedi 5.

9. Pulizia di manutenzione (giornaliera) - ok con quello.

10. Faresti anche meglio ad aggiungere un'attività per verificare i tuoi backup - c'è una versione del comando RESTORE (verificaSolo ... se ricordo bene) - diciamo settimanalmente, anche se preferisco ogni giorno.

Dici che vuoi essere protetto in caso di perdita di dati, quindi direi che devi aggiungere i database di sistema in questa procedura di manutenzione. E fai anche attenzione a eseguire il backup dei file su una macchina diversa rispetto al server stesso. Conservare da qualche parte un file con cosa fare nel caso in cui sia necessario ricostruire master db, msdb..etc. Buona fortuna con il tuo compito!

Risposta in ritardo ma potrebbe essere utile per altri lettori.

Tieni presente che è possibile creare molte attività di manutenzione o di reporting che comportano rischi invisibili ad esse associati.

Cosa accadrebbe quando un'unità si riempie durante i backup differenziali eseguiti quotidianamente? E se un processo di ricostruzione dell'indice viene eseguito in modo insolitamente lungo? Che ne dite se un processo di caricamento dei dati causi un'esauriente contesa di risorse, mettendo in ginocchio le normali operazioni? Tutti questi sono eventi pianificati, ma possono causare notevoli interruzioni ai processi stessi che stiamo cercando di salvaguardare.

Considerare sempre come diversi lavori interagiscono e temporizzarli in modo tale che non vi siano sovrapposizioni in attività sensibili o che richiedono risorse.

Suggerisco di leggere prima questo articolo: http://www.sqlshack.com/removing-the-risk-from-important-maintenance-tasks-in-sql-server/

Descrive come eseguire importanti attività di manutenzione in SQL Server, senza rischi. Ad esempio: è possibile creare semplici controlli nei lavori di manutenzione che verificano le risorse disponibili e quali operazioni saranno necessarie prima dell'esecuzione. Ciò consente di garantire che il proprio ambiente sia in grado di gestire ciò che si sta per fare e di interrompere con un errore significativo se le risorse sono inadeguate.

1. Sembra a posto

2. Puoi trarre vantaggio dal fare backup differenziali qui. Guardali di sicuro

3. Sembra a posto

4. Sembra a posto

5. Come affermato in precedenza, le riduzioni del database sono dannose perché creano la frammentazione fisica dei dati e dei file di registro, causando così letture I / O più casuali.

5, 6 e 8: vedere di seguito.

Questi vanno davvero di pari passo, poiché gli indici si basano su statistiche aggiornate e l'ordine di queste operazioni è abbastanza importante. Il metodo di base che utilizzo, che è vero che potrebbe non funzionare per tutti, è che eseguo due cicli di manutenzione dell'indice. Innanzitutto, eseguo gli indici cluster e quindi gli indici non cluster. Il metodo che utilizzo per entrambi è il seguente. Se un indice è abbastanza grande e abbastanza frammentato (sys.dm_db_index_physical_stats), ricostruirò l'indice (che include un aggiornamento delle statistiche con la scansione completa). Se un indice è troppo piccolo per una ricostruzione o non abbastanza frammentato per una ricostruzione (meno di 100 pagine e una frammentazione compresa tra il 5% e il 15%), eseguirò prima una riorganizzazione dell'indice. Eseguirò quindi un aggiornamento delle statistiche con la scansione completa.

Ora, questo copre le statistiche degli indici, ma trascura di fare qualsiasi cosa per le statistiche delle colonne. Ogni settimana aggiornerò le statistiche delle colonne.

Spero che questo abbia aiutato in qualche modo!

Mi sono appoggiato al tuo commento "la perdita di dati potrebbe avere conseguenze legali qui".

Quindi, vuoi sicuramente ottenere un potente strumento di terze parti (come DPM) in grado di gestire i backup (e recuperare da eventi catastrofici in un lampo e agitarsi minimamente) molto più velocemente e molto meglio di qualsiasi script che puoi estrarre da Internet.

Avere backup è una cosa. Saper usarli in caso di emergenza è un altro.

Non dimenticare che se stai per ripristinare un backup dopo un grave errore, probabilmente sei già sotto un carico di stress e pressione. Non hai bisogno dell'onere aggiuntivo di scavare e scrivere in modo impeccabile l'istruzione RESTORE DATABASE con 12 file di registro delle transazioni ... E pregare che non ti manchi ...

Nel mio posto di lavoro, posso ripristinare / ripristinare un database da 350 Gb in qualsiasi punto in un periodo di 5 minuti per l'ultima settimana utilizzando DPM. Con un'interfaccia grafica. Ne vale la pena, nel mio libro.

Per il resto, guarda sicuramente lo script indice di Ola Hallengren e regola i parametri in base alle tue esigenze. Personalmente, l'ho accoppiato con un'attività pianificata che lo fa funzionare per un'ora ogni notte senza nuova scansione, quindi gestisce gli indici peggiori ogni volta e impone una completa scansione della frammentazione ogni sabato o quando tutti gli indici nell'elenco sono stati deframmentati.

Infine, aggiungo la mia voce al gruppo "non ridurre i tuoi file automaticamente, mai". File Shrink è solo uno strumento da utilizzare sporadicamente quando si verifica un evento irregolare che ha invaso i tuoi registri o file DB (loop infinito o simili). Non dovrebbe essere uno strumento di manutenzione. Se si dispone di una pressione dello spazio su disco, la riduzione ritarderà comunque l'inevitabile.