Interni di backup: cosa succede quando è in esecuzione un processo di backup, in termini di blocco e sovraccarico delle prestazioni in SQL Server?

Per MySQL so che nel database viene eseguito il backup tabella per tabella in Istruzioni SQL, questo si traduce in un blocco e se si aggiornano le colonne durante il backup si potrebbero riscontrare problemi di integrità.

Per quanto ne so, questo non si applica a Microsoft SQL Server, ma come lo gestisce SQL Server? C'è qualche blocco interno per mantenere coerente il db?

Ho anche sentito che il backup è a thread singolo, il che significa che utilizza solo un core, supponendo che tu esegua il backup su un singolo file. Supponendo anche che tu abbia una macchina multicore, ad esempio 16 core, o almeno un numero significativamente maggiore di uno.

Dalla mia esperienza personale non ho mai avuto problemi durante l'esecuzione di backup, né problemi di blocco né sovraccarico, ma la mia esperienza è limitata. Ecco perché consiglio sempre di attivare la compressione del backup nelle proprietà del server.

Quindi cosa succede quando è in esecuzione un processo di backup? E ci sono anche differenze significative per le diverse versioni? ad esempio 2008, 2012 e 2014 (non le licenze).

Tutti i tuoi punti sono coperti dai miti del backup - di Paul Randal

30-01) le operazioni di backup causano il blocco

No. Le operazioni di backup non bloccano gli oggetti utente . I backup causano un carico di lettura molto pesante sul sottosistema I / O, quindi potrebbe sembrare che il carico di lavoro sia bloccato, ma in realtà non lo è. Viene solo rallentato. C'è un caso speciale in cui un backup che deve recuperare estensioni registrate in blocco richiederà un blocco di file che potrebbe bloccare un'operazione di checkpoint, ma DML non viene mai bloccato.

Ho anche sentito che il backup è a thread singolo, il che significa che utilizza solo un core, supponendo che tu esegua il backup su un singolo file.

Un backup eseguito su un singolo file o dispositivo utilizzerà 1 thread del writer. Quindi, se si esegue il backup su più file / dispositivi (sia che più file .bak) avranno un thread di scrittura per file / dispositivo.

Il modo più semplice per migliorare le prestazioni di backup è consentire il parallelismo dell'operazione di backup, noto come striping di backup. Per impostazione predefinita, esiste un singolo thread del lettore di dati per ciascuna lettera di unità o punto di montaggio da leggere e un singolo thread del writer di dati per ciascun dispositivo di backup su cui viene scritta.

Dai un'occhiata

1. Video sulla disponibilità di SQL Server 2008 Microsoft Certified Master (MCM), in particolare gli interni di backup.
2. Uno sguardo ai backup interni e come monitorare il throughput di backup e ripristino (parte 1) - A cura di: Jonathan Kehayias
3. Uno sguardo ai backup interni e come monitorare il throughput di backup e ripristino (parte 2) - A cura di: Jonathan Kehayias

L'articolo scritto da Paul riguardante gli interni di backup è eccellente e devi leggerlo. Aggiungendo ciò che altri hanno detto e sottolineando la parte specifica della tua domanda

Ho anche sentito che il backup è a thread singolo, il che significa che utilizza solo un core, supponendo che tu esegua il backup su un singolo file. Supponendo anche che tu abbia una macchina multicore, ad esempio 16 core, o almeno un numero significativamente maggiore di uno.

Operazione di backup, can use parallelismma ricorda che questo non è il parallelismo guidato da Optimizer in SQL Server, è guidato dal numero di dischi coinvolti da cui il backup deve leggere il file di dati e dove il backup scrive il file di dati e la quantità di file di backup creati.

Non è possibile utilizzare il MAXDOPsuggerimento durante l'esecuzione del backup di SQL Server

Non è possibile generare un piano di esecuzione in SSMS per una semplice operazione di backup TSQL.

Il parallelismo guidato da Query Optimizer in SQL Server è fondamentalmente per gli operatori coinvolti (in realtà è più complesso, ma per semplicità puoi prenderlo) dal momento che l'operazione di backup non coinvolge alcun operatore in quanto tale non può utilizzare il parallelismo guidato da Optimizer.

Ho scritto un articolo su Technet Wiki su Backup e parallelismo in cui ho usato semplici esempi per spiegare il parallelismo durante il backup di SQL Server. Di seguito è la conclusione

1. Se i file di database si trovano su più dischi, l'operazione di backup si avvia sul thread per unità del dispositivo per leggere i dati. Allo stesso modo, se il ripristino viene eseguito su più unità / punti di montaggio, l'operazione di backup avvia un thread per unità / punto di montaggio

2. Anche se si stanno scaricando più copie del backup sulla stessa unità, verrebbe scaricato un thread per file di backup.

3. Il parallelismo associato al backup è correlato alle strisce. Ogni striscia ottiene il proprio thread di lavoro e questa è davvero l'unica parte del backup / ripristino che si dovrebbe considerare come operazioni parallele.

4. Il massimo grado di parallelismo non ha alcun effetto sull'operazione di backup.

Ho avuto un parere di esperti su questo da Paul e Bob Dorr.

Quindi cosa succede quando è in esecuzione un processo di backup? E ci sono anche differenze significative per le diverse versioni? ad esempio 2008, 2012 e 2014 (non le licenze).

Ti consiglierei di leggere questo articolo blog.msdn di Bob Dorr. Alcuni punti importanti che ha sottolineato è

1. All'avvio di un backup crea una serie di buffer, allocati dalla memoria all'esterno del pool di buffer. L'obiettivo è generalmente di 4 MB per ciascun buffer, che si traduce in circa 4 a 8 buffer. I dettagli sul calcolo sono disponibili in: http://support.microsoft.com/kb/904804/en-us

2. I buffer vengono trasferiti tra le code gratuite e quelle dei dati. Il lettore estrae un buffer libero, lo riempie di dati e lo inserisce nella coda di dati. I redattori estraggono i buffer di dati riempiti dalla coda di dati, elaborano il buffer e lo restituiscono all'elenco libero.

3. Ottieni un writer per dispositivo di backup, ciascuno recuperando dalla coda dei dati. Quindi un comando di backup con quattro (4) specifiche del disco avrà quattro writer e un lettore. Il lettore utilizza l'I / O asincrono in modo da tenere il passo con gli autori.

È possibile abilitare trace flags 3213 and 3605, entrambi non sono documentati, quindi utilizzarlo nell'ambiente di test e vedere quale messaggio interessante viene scaricato nel log degli errori di SQL Server. Apparirà qualcosa di simile di seguito

Memory limit: 249MB
BufferCount:                7
Sets Of Buffers:            1
MaxTransferSize:            1024 KB
Min MaxTransferSize:        64 KB
Total buffer space:         7 MB
Tabular data device count:  1
Fulltext data device count: 0
Filestream device count:    0
TXF device count:           0
Filesystem i/o alignment:   512
Media Buffer count:            7
Media Buffer size:          1024KB

Non sono a conoscenza di cambiamenti significativi nel codice di backup per varie versioni, tali cose non sono documentate. Conosco solo il miglioramento introdotto nel SQL Server 2012 SP1 Cumulative Update 2,consentire il backup e il ripristino dal servizio di archiviazione BLOB di Windows Azure da SQL Server tramite TSQL o SMO. Leggi qui

Fondamentalmente, SQL Server esegue una copia sporca di tutte le pagine sul disco. Tali pagine sono probabilmente incoerenti in presenza di attività simultanee o se in precedenza vi sono attività senza checkpoint.

Quindi, SQL Server copia anche la parte necessaria del registro delle transazioni necessaria per portare le pagine non aggiornate all'ultima versione e rendere tutto coerente al ripristino.

Non posso parlare con il multi-threadedness dell'operazione di backup. Mi aspetto che sia parallelizzato. In quale altro modo è possibile eseguire il backup di un database da 10 TB su un sottosistema IO da 10 GB / sec?