PRESTAZIONI SQL 2008

Question

Buongiorno a tutti, utilizzo un installazione di Sql Server Standard 2008 su un macchina virtuale Hyper View con processore Intel octacore e 16 gb di ram. Il database che vado a gestire su l'unica istanza presente è di circa 40 Gb. Quando eseguo giornalmente la pianificazione schedulata del piano di manutenzione del db che prevede in successione:

- Check Database Integrity Task

- Shrink Database Task

- Back up Database Task

- Maintenance Cleanup Task

impiega mediamente 8 ore ad eseguire l'operazione. Posso aver sbagliato qualche configurazione o esiste un modo per rendere più rapida l'operazione? Il back up  è eseguito con modalità Full.

Se aggiornassi il motore Sql alla versione 2012/2014 avrei miglioramenti in termini di prestazioni su una macchina con le caratteristiche sopra indicate? In che termini eventualmente migliorerei le prestazioni?

Grazie mille in anticipo a chi mi vorrà aiutare

Answer 1

Ciao,

dura essere sintetici su un argomento cosi' vasto!

Dividerei la mia risposta in due macrotemi:

1)Risoluzione problema performance

Hai modo di capire dallo storico quale dei 4 step porta via piu' tempo?

Gli utenti sono collegati durante la finestra di maintenance?

2)Piano di manutenzione

- Check Database Integrity Task --> è cosa buona e giusta.

- Shrink Database Task --> eviterei di farlo se possibile. Non c'è bisogno di tale operazione (per altro dannosa sotto alcuni aspetti - i.e. frammentazione degli indici) se gestisci lo spazio del db con una strategia che preveda una grandezza fissa dei file, con autogrowth disabilitato o settato con un ragionevole passo (per limitare gli autogrowth). Se vuoi approfondire il perchè non farlo, ecco un link utile:

Paul Randal – “Why You Should Not Shrink Your Data Files”

- Back up Database Task

Di per sè non è un problema fare backup full tutti i giorni, pero' potresti definire una strategia di backup in base al recovery model del tuo database abbattendo i tempi di maintenance, RPO e RTO del tuo servizio.

Backup Under the Simple Recovery Model

Backup Under the Full Recovery Model

Se hai bisogno di consigli sulla strategia da implementare, ti basta postare quali sono i tuoi obiettivi di business per il tuo servizio (ovvero, quanti dati puoi permetterti di perdere in caso di guasto/problema tecnico). Se fai solo full backup di notte - stai implicitamente assumendo che puoi perdere un'intera giornata di lavoro, perchè in caso di un problema serio (tocca ferro), potrai restorare solo il backup della notte precedente...

Non vedo nel piano di manutenzione indici (Rebuild/Reorganize) e ricalcolo delle statistiche, aggiungerei tali task. 

Io mi trovo molto bene con l'eccellente (e famosa) soluzione free di Ola Hallengren. Un paio di configurazioni e ti ritroverai con un set di maintenance jobs che si occuperanno del tuo database, quando lo vorrai tu...

Fammi sapere!

PS

In senso generale aggiornare il db Engine all'ultima versione (intendo l'ultima consolidata) è consigliato per poter utilizzare nuove features e godere degli improvements disponibili, ma io sono un acceso sostenitore delle ottimizzazioni e credo che il problema che ti affligge abbia poco a che fare con la versione di SQL che stai utilizzando. Ho visto macchine Win2003 con SQL 2005 filare come razzi con database ben piu' grandi di 40gb!

Answer 2

ok. Grazie mille. Ora provo a ottimizzare il piano di manutenzione...

Answer 3

Ciao,con il mio maintenance plan, tolto lo shrink, è  il back up full ad impiegare molte ore...

Answer 4

A proposito, se mi potete aiutare, per poter inserire nei post le immagini mi viene chiesta la verifica dell'indirizzo email che ricordo di aver già eseguito. Da dove posso nuovamente verificare l'account???

Grazie mille

 

Answer 5

Quale versione/edizione di SQL hai? 2008 o 2008R2?

Qual'è il Recovery model del tuo database, e quanti dati (in termini di tempo) puoi permetterti di perdere in caso di problemi?

Answer 6

A proposito, se mi potete aiutare, per poter inserire nei post le immagini mi viene chiesta la verifica dell'indirizzo email che ricordo di aver già eseguito. Da dove posso nuovamente verificare l'account???

Grazie mille

 

Quella verifica viene eseguita automaticamente dal sistema dopo un po' di tempo, in alternativa puoi inserire una richiesta qui:

https://social.technet.microsoft.com/Forums/en-US/77ccf860-c2b7-48da-b35a-011d21c6b5cc/verify-your-account-34?forum=reportabug

Answer 7

2008 R2

Sono giusto all'inizio ma essendo dati molto importanti al massimo posso permettermi di perdere 2 ore di lavoro

---

Matteo Riva

Answer 8

Se 2 ore è il tempo massimo che hai definito come RPO, allora procederei come segue:

1)Database Recovery Model è Full? Se si, ignora pure questo passaggio. Altrimenti, convertilo da SIMPLE a FULL (Database, tasto destro, Properties, Options, Recovery Model -> FULL)

2)Ipotizzo uno scenario di questo tipo (adattalo chiaramente alle tue esigenze):

Full Backup : durante la maintenance window piu' grande che puoi avere, i.e. nel week end

Differential Backup : i.e. ogni notte, o 2/3 volte la settimana. Piu' differential avrai, meno log backup dovrai includere nella tua restore sequence. Se hai un guasto in mezzo alla settimana, e fai il diff ogni notte tranne quando hai il full, potrai restorare facendo FULL->ULTIMO DIFF->LOG BACKUPS effettuati dopo il DIFF.

Log Backup : ogni 2 ore

In questo modo, salvando in uno storage sicuro i tuoi backup, avrai al massimo solo 2 ore di dati persi in caso di irreparabile danno al tuo server/database, piu' un notevole incremento di velocita' per le tue operazioni di maintenance.

PS

Ipotizzo tu abbia almeno la standard edition, attiva anche la backup compression (la troverai sotto server properties -> database settings)

Answer 9

Ecco come ho configurato i task sui DB: è corretto?

---

Matteo Riva

Answer 10

Ciao Matteo,

se utilizzi i maintenance plan di SQL, mi sembra che non hai discrezionalita' su quando fare rebuild o reorganize di un index, pertanto nel modo configurato fai solo un doppio lavoro. A questo punto, sceglierei di fare solo rebuild.

Nello specifico, in sequenza, implementerei:

1)Check database integrity (user + system DBs)

2)Rebuild Indexes (user + system DBs)

3)Update statistics (user + system DBs, full scan, column statistics only, perchè le index statistics vengono ricreate gia' al punto 2)

4)Backup (hai deciso di fare sempre full? In caso contrario farei dei job separati per i backups)

5)Cleanup

Answer 11

Grazie, quando parli di (user + system DBs) posso semplicemente impostare selezionando i due DB che mi interessano o devo eseguire due operazioni separate?

---

Matteo Riva

Answer 12

Puoi selezionare "All databases" se intendi creare un singolo piano di manutenzione per tutti i db.

Io di solito tendo a dividere le cose e a costruire un processo per i system databases, e uno per gli user databases (selezionando relativamente "system databases" e "all user database" a seconda del processo che sto impostando).