Come posso eseguire il backup di un database SQL Server di grandi dimensioni senza influire sulle prestazioni?

Abbiamo ricevuto segnalazioni di query eseguite lentamente o scadute la mattina presto e l'unico lavoro che vedo in esecuzione che penso possa influire su questo è il nostro processo di backup del database.

Il database stesso è di circa 300 GB e il processo di backup inizia alle 4:30 del mattino e non termina fino a poco dopo le 7:00 del mattino. La sintassi corrente del nostro processo di backup è:

BACKUP DATABASE [DatabaseName]
TO DISK = N'E:\Database Backups\DatabaseName.Bak'
WITH INIT, NOUNLOAD, NAME = N'DatabaseName.Bak',
NOSKIP, STATS = 10, NOFORMAT

E:\ è una partizione sul server che contiene sia i database che i backup del database.

Va anche probabilmente notato che si tratta di un server virtuale, non di un server autonomo dedicato. Abbiamo iniziato a ricevere lamentele sui rallentamenti durante il processo di backup subito dopo il passaggio a un server virtuale, quindi penso che potrebbe essere correlato.

Esiste un modo per eseguire questo processo di backup in modo che non influisca sulle prestazioni della query mentre è in esecuzione?

Stiamo usando SQL Server 2005

1. Isolare l'I / O di backup dal resto dell'I / O sul sistema. Mentre potrebbe richiedere più tempo ed essere più incline al singhiozzo, il backup sulla rete anziché su un disco locale può aiutare ad alleviare l'impatto diretto sull'istanza. Anche in una macchina virtuale dovresti essere in grado di esporre altra memoria in modo che SQL Server possa scrivere su un sottosistema I / O diverso.
2. È improbabile che faccia alcuna differenza ma, se questo viene eseguito da un lavoro, perché è necessario utilizzare l' STATSopzione? Sei certo bisogno di altre opzioni ( NOUNLOAD, NOSKIP, NOFORMAT)? Non ho eseguito test approfonditi sulle prestazioni sull'intera matrice di opzioni, ma IMHO dovresti usare solo le opzioni di cui sai di aver bisogno.
3. Esegui i tuoi backup completi in un momento diverso che non interferisca con la normale attività dell'utente. Questo non è sempre possibile, ma anche nelle operazioni 24 ore su 24, 7 giorni su 7, ci sono tempi di punta e di riposo.
4. Se passi a 2008+ puoi sfruttare la compressione del backup (Enterprise nel 2008, Standard o Enterprise nel 2008 R2 +). Se non riesci a passare al 2008 o non hai l'edizione adeguata, ci sono strumenti di backup di terze parti che faranno la compressione per te e sono tutti abbastanza bravi. Dal 2008 sono stato in grado di utilizzare la compressione nativa e sono stato abbastanza soddisfatto della velocità e della compressione% lì senza la necessità di investire ulteriormente in terze parti. Ma con il 2005 ricordo di aver avuto un buon successo con Red-Gate SQL Backup ; Anche Quest LiteSpeed è abbastanza buono, ma non ho idea di quale tipo di sforzo venga fatto dopo l'acquisizione della Dell.
5. Se i tuoi database sono in pieno recupero, potresti andare più a lungo tra i backup completi, scambiandoli per la consapevolezza che se devi ripristinare in un determinato momento, avrai potenzialmente più registri da ripristinare. Potresti combinare questa opzione con il suggerimento di Ali di seguito di prendere diff durante la settimana - se dovessi recuperare giovedì, dovrai ripristinare 1 pieno, 1 diff e i log dal diff.
6. Se si dispone di molti dati non aggiornati e invariati, è possibile considerare di ospitarli in un database diverso con un piano di ripristino diverso, o almeno in filegroup diversi, e suddividere le operazioni di backup in quel modo. Se si dispone di dati di riferimento o di archiviazione che possono essere resi di sola lettura e in caso di semplice ripristino, è possibile spostarli nel proprio filegroup di sola lettura, eseguirne il backup una volta e non è necessario includerli nei backup notturni mai più. Vedi questi argomenti MSDN:

Esecuzione di ripristini frammentari

Esempio: ripristino a fasi di solo alcuni filegroup (modello di recupero semplice)

Questo è un problema comune, ci sono più soluzioni e dipende davvero dal tuo ambiente. Analizziamoli:

1- Compressione di backup al volo

Nel 2008 R1 Backup Compression divenne disponibile in Enterprise, nel 2008 R2 divenne disponibile in Standard. Questo è ENORME. Ti farà risparmiare MOLTO tempo. Se riesci a eseguire l'aggiornamento, cercalo. Se non ci riesci, controlla l' utility HyperBak di RedGate o Quest LiteSpeed . Entrambi hanno una prova gratuita.

2- Backup completi e diff

Ho ereditato un database di prodotti da 2 TB causando un sacco di timeout per una grande azienda Internet 24/7 che ho elaborato. Abbiamo abilitato backup completi e differenziali che ci hanno permesso di risparmiare molto tempo. Farei un backup completo domenica alle 12:00 quando l'attività era bassa e prendevo le differenze durante la settimana. Questo ha risparmiato molto spazio. Il lavoro di Diff è diverso dai registri delle transazioni in quanto funzionano su quali pagine del database sono state modificate. Viene eseguito il backup di tutte le pagine modificate. Quindi esegui un ripristino completo, quindi il ripristino diff per aggiungere le pagine modificate.

3- Qual è il tuo collo di bottiglia?

L'analisi del collo di bottiglia è importante da diagnosticare. Esegui il backup sullo stesso array di dischi dei tuoi file di dati? I tuoi file di dati sono stati ancorati? Che cos'è DISK SEC / READ e DISK SEC / WRITE per i dischi di dati durante i backup? Ho modificato i backup per creare 4 file. Ogni file ha il proprio thread writer e nella nostra SAN che ha funzionato alla grande. Provalo, mi sono rasato 45 minuti creando solo 4 file di backup. Assicurati solo che le metriche del disco sopra elencate siano basse. Ottieni una baseline.

4- Replica a un altro server e backup

Questo è leggermente avanzato. È necessario assicurarsi che il database replicato sia aggiornato e che sia necessario un monitoraggio adeguato. In tal caso, è possibile eseguire il backup del database replicato.

È possibile utilizzare questi parametri:

BLOCKSIZE - Scegli le dimensioni 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536. (in KB)

BUFFERCOUNT : specifica il numero totale di buffer I / O da utilizzare per l'operazione di backup. È possibile specificare qualsiasi numero intero positivo; tuttavia, un numero elevato di buffer potrebbe causare errori di "memoria insufficiente" a causa di spazio di indirizzi virtuali inadeguato nel processo Sqlservr.exe. - da MSDN

MAXTRNASFERSIZE : da 65536 byte (64 KB) a 4194304 byte (4 MB)

Provalo. risolto il timeout scaduto problema mentre db di grandi dimensioni.

Private Sub Command1_Click()
On Error Resume Next
Dim con As New Connection
Dim tm As String
con.CommandTimeout = 500'''Command timeout should be 500


 With con
    .ConnectionString = "Provider=SQLOLEDB.1;Persist Security Info=False;User ID=sa;Initial Catalog=dbiBMS;Data Source=192.168.103.4"
    .Open
 End With
 tm = CStr(Time)

con.Execute " backup database dbiBMS to disk='E:\Database_Backup\Test1.bak' with format "

con.Close
MsgBox tm
Exit Sub
x:
MsgBox Err.Description

End Sub