Backup di SQL Server: un paio di domande

Il venerdì eseguiamo il nostro backup settimanale alle 21:00 e riscontriamo un paio di problemi relativi allo spazio su disco (che a volte diventa pericolosamente basso) e alle prestazioni. Stiamo cercando di ottimizzare / ottimizzare ciò che accade e apprezzeremmo i tuoi commenti.

In particolare:

1. Il processo di backup impiega circa 4 ore per aggiornare le statistiche durante il backup. Possiamo disabilitare in modo sicuro questo processo per risparmiare tempo?

2. Stiamo esaurendo lo spazio su disco molto regolarmente e ci chiediamo se dovremmo ripetere il processo. Attualmente crea il backup e quindi elimina il backup precedente e questo è lo spazio su disco di hogging. Possiamo tranquillamente eliminare quella precedente prima e poi fare il backup?

Qualsiasi altro commento o osservazione sarebbe molto gradito EDIT: la dimensione totale dei file SQL sul server è di circa 35 GB. Un db ha una dimensione di circa 25 GB, mentre gli altri sei condividono gli altri 10 GB circa.

(1) Sì, di solito ho il processo di backup da solo. Non potrei fare molto durante il mio tempo di backup, se posso. Potrebbe essere necessario eseguire il backup e quindi eseguire l'aggiornamento sulle statistiche. Sembra che tu stia eseguendo due lavori (1 per il backup, 1 per le statistiche di aggiornamento) contemporaneamente?

(2) Copi il backup su nastro o su altra memoria su disco? In tal caso, di solito pulisco i file prima di creare nuovi backup localmente. In caso contrario, se sto raschiando lo spazio di archiviazione, prenderei in considerazione la compressione del file di backup prima della creazione di quello nuovo. (Cioè se non puoi abilitare la compressione sui backup, come suggerito da @Simon , anche questo risparmierebbe un po 'di spazio.)

Posso solo rispondere alla domanda 2 qui. Ti consiglio di dare un'occhiata ai backup compressi.

• SQL Server può farlo, se si dispone dell'edizione 2008 dell'impresa. In caso contrario, guarda i due seguenti.
• Quest Litespeed
• RedGate SQL backup

1) Non vedo una relazione diretta tra il compito di fare un backup e il compito di aggiornare le statistiche. Quindi puoi dividerli senza alcun problema. Vorrei che la parte delle statistiche di aggiornamento fosse più correlata a un lavoro che avrebbe deframmentato / ricostruito gli indici.

2) Anche se è per poco tempo, non vuoi stare senza un backup. Quindi ti consigliamo di rimuovere l'ultimo backup solo se lo hai già salvato da qualche altra parte.

Nota a margine qui: se si eseguono backup nella stessa casella di archiviazione in cui si trova il database, i backup non saranno sicuri quando si avrà un problema hardware con la casella di archiviazione. Quindi è necessario assicurarsi di disporre di spazio sufficiente per i backup altrove, non sullo stesso computer.

Nota a margine 2: come già specificato da Simon, investi tempo / denaro in backup compressi se hai problemi di spazio. Puoi vedere molte idee in questa domanda: Il backup più piccolo possibile ... con SQL Server .

L'attività delle statistiche di aggiornamento non dovrebbe richiedere 4 ore per un database di 3-4 GB. Molto probabilmente hai problemi di I / O o hai un database fortemente frammentato che sta creando problemi di I / O. Esegui una deframmentazione o una ricostruzione dell'indice sul database e verifica se ciò migliora le prestazioni. In caso contrario, accendi Perfmon e controlla dove si trova il collo di bottiglia delle prestazioni.

Non consiglierei di eliminare il tuo unico backup prima di eseguirne uno nuovo. Non sarebbe la prima volta che un backup fallisce o l'istanza si interrompe e non è consigliabile avere un intervallo di tempo senza possibilità di recupero.

Questa non è la soluzione al tuo problema. Capire come avere più spazio per alloggiare entrambi sarebbe il modo giusto per farlo.