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


43

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).


7
Non vuoi ridurre il database, può causare la frammentazione dei file
Endy Tjahjono,

L'attuale database è di oltre 30 GB, quindi ho pensato che una riduzione avrebbe aiutato. Grazie per il tuo contributo, Endy.
Josh,

Crea un lavoro settimanale separato e aggiorna le statistiche una volta alla settimana.
Michael Riley - AKA Gunny,

1
Quindi dovrei cambiare gli aggiornamenti statistici giornalieri in settimanali?
Josh,

1
Un ebook gratuito sull'argomento che ho trovato molto utile: la guida sicura di Brad ai piani di manutenzione di SQL Server .

Risposte:


29

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.


Sankar, grazie per il tuo contributo. Avevo pensato che fare un backup orario di alcune tabelle (tralasciando tabelle che non cambiano così spesso) potrebbe essere un approccio migliore per risparmiare un po 'di tempo sui backup orari. Il grosso problema qui è che voglio davvero backup del registro delle transazioni di 15 minuti perché la perdita di dati nella nostra situazione potrebbe avere conseguenze legali. Per quanto riguarda la frequenza di backup completa, ogni ora sarebbe la cosa migliore, ma ho paura di tassare troppo il sistema. Ho guardato quello script prima di pubblicare, ma non ho avuto la possibilità di provarlo.
Josh,

22

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!


Gli indici frammentati sono considerati una "cosa negativa" su SQL Server? Dove vivo deframmentare gli indici può uccidere le prestazioni ed è comunque piuttosto inutile
Jack Douglas,

@Jack - ovviamente gli indici frammentati sono una cosa negativa :-). Vedi l' articolo di Brent Ozar sugli indici frammentati, inclusi esempi. Una sola citazione di un white paper sulla SM usato nel suo articolo: "La frammentazione dell'indice ha rallentato i loro sistemi dal 13% al 460%. Ahi.". E tieni presente che l'articolo di Tom risale a quando utilizzava l'ottimizzatore basato su regole, non l'ottimizzatore basato sui costi in seguito.
Marian,

Il CBO non ha nulla a che fare con ciò e ciò che ha detto allora si applica ancora oggi su Oracle, te lo assicuro. Nessuna idea su SQL Server però - ho letto l'articolo e non sono rimasto abbastanza convinto: perché nessuna considerazione che la deframmentazione può rallentare orribilmente gli aggiornamenti (pensa a tutti quei blocchi foglia che si dividono di nuovo perché continui a incollarli di nuovo insieme). Potrei iniziare una nuova domanda su questo ...
Jack Douglas,

@Jack - Non volevo dire nulla sull'ottimizzatore, ma l'ora esatta (che era di 10 anni fa). E stavo pensando che le cose sottostanti dei nostri server cambiano ed evolvono con ogni versione. Comunque, per quanto riguarda la deframmentazione degli aggiornamenti che rallentano, è un compromesso che farò in qualsiasi momento, perché il mio sistema ha il peso principale sulla lettura, non sulla scrittura dei dati. Quindi ognuno deve fare le proprie misurazioni.
Marian,

10

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.


7
  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!


3

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.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.