Impostazione di BUFFERCOUNT, BLOCKSIZE e MAXTRANSFERSIZE per il comando BACKUP

Sto cercando pratico orientamento per definire i valori per il BUFFERCOUNT, BLOCKSIZEe MAXTRANSFERSIZEdel BACKUPcomando. Ho fatto un po 'di ricerche (vedi sotto), ho fatto un po' di test e sono pienamente consapevole che qualsiasi risposta veramente preziosa inizierà con "Beh, dipende ...". La mia preoccupazione per i test che ho effettuato e i test mostrati in una qualsiasi delle risorse che ho trovato (vedi modo sotto) è che i test vengono eseguiti nel vuoto, molto probabilmente su un sistema senza altri carichi.

Sono curioso di ricevere una guida / buone pratiche adeguate per quanto riguarda queste tre opzioni che si basano sull'esperienza a lungo termine: molti punti dati nell'arco di settimane o mesi. E non cerco valori specifici poiché è principalmente una funzione dell'hardware disponibile, ma vorrei sapere:

• In che modo vari fattori hardware / di carico influenzano ciò che dovrebbe essere fatto.
• Ci sono circostanze in cui nessuno di questi valori deve essere ignorato?
• Ci sono insidie ​​per scavalcare qualcuno di questi che non sono immediatamente evidenti? Stai utilizzando troppa memoria e / o I / O su disco? Operazioni di ripristino complicate?
• Se ho un server con più istanze di SQL Server in esecuzione (un'istanza predefinita e due istanze denominate) e se eseguo i backup di tutte e 3 le istanze contemporaneamente, ciò influisce sul modo in cui imposto questi valori oltre a verificare che il collettivo ( BUFFERCOUNT* MAXTRANSFERSIZE) non supera la RAM disponibile? Possibile contesa I / O?
• Nello stesso scenario di avere le tre istanze su un server e di eseguire nuovamente i backup su tutti e tre contemporaneamente, in che modo l'esecuzione di backup per più database contemporaneamente all'interno di ogni istanza influirebbe sull'impostazione di questi valori? Ciò significa che se ciascuna delle tre istanze ha 100 database ciascuna, eseguendo contemporaneamente 2 o 3 backup per ogni istanza in modo tale che vi siano tra 6 e 9 backup in esecuzione contemporaneamente. (In questa situazione, ho molti database di dimensioni medio-piccole anziché poche.)

Quello che ho raccolto finora:

• BLOCKSIZE:

  • Le dimensioni supportate sono 512, 1024, 2048, 4096, 8192, 16384, 32768 e 65536 (64 KB) byte. ^[1]
  • L'impostazione predefinita è 65536 per i dispositivi a nastro e 512 altrimenti ^[1]
  • Se si sta eseguendo un backup che si prevede di copiare e ripristinare da un CD-ROM, specificare BLOCKSIZE = 2048 ^[1]
  • Quando si scrive su singoli dischi, il valore predefinito di 512 è perfetto; se si utilizzano array RAID o SAN, è necessario verificare se l'impostazione predefinita o 65536 è migliore. ^{[13 (pagina 18)]}

  • Se si imposta manualmente, il valore deve essere> = la dimensione del blocco utilizzata per creare i file di dati, altrimenti si otterrà il seguente errore:

    Messaggio 3272, livello 16, stato 0, riga 3
    Il dispositivo "C: \ Programmi \ Microsoft SQL Server \ MSSQL11.MSSQLSERVER \ MSSQL \ Backup \ BackupTest.bak" ha una dimensione del settore hardware di 4096, ma il parametro della dimensione del blocco specifica un valore di sostituzione incompatibile di 512. Emettere nuovamente l'istruzione utilizzando una dimensione di blocco compatibile.

• BUFFERCOUNT:

  • Predefinito ^{[2], [8]} :

    SQL Server 2005 e versioni successive:
    (NumberofBackupDevices * [mystery_multiplier]) + NumberofBackupDevices + (2 * NumberofVolumesInvolved)

  • [mystery_multiplier]: c'è qualche incoerenza riguardo questo valore. L'ho visto espresso in 3 forme:

    • 3 ^[2]
    • GetSuggestedIoDepth ^[8]
    • GetSuggestedIoDepth + 1 ^[8]

    
    Il test che mostra il moltiplicatore da eseguire è 3stato eseguito su SQL Server 2005 SP2 ^[9] .

    I miei test su SQL Server 2008 R2 e 2012 e un commento utente su SQL Server 2014 ^[8] mostrano che il moltiplicatore è 4. Significato, dato il valore riportato per GetSuggestedIoDepth(direttamente sotto), sia:

    • GetSuggestedIoDepthè ora 4o
    • il moltiplicatore è ora GetSuggestedIoDepth + 1
  • GetSuggestedIoDepthritorni 3per dispositivi DISK ^[9]
  • Nessun valore massimo impostato, ma dato che la memoria richiesta = ( BUFFERCOUNT* MAXTRANSFERSIZE), sembrerebbe che un valore massimo pratico sia: BUFFERCOUNT <= (available_memory / MAXTRANSFERSIZE)
• MAXTRANSFERSIZE:
  • I valori possibili sono multipli di 65536 byte (64 KB) che vanno fino a 4194304 byte (4 MB). ^[1]
  • Valori predefiniti: se il dispositivo è in modalità lettura (ripristino) o si tratta di una versione desktop o Express Edition, utilizzare 64 KB, altrimenti utilizzare 1 MB. ^[9]
• Generale / Varie:
  • La dimensione massima che può essere utilizzata è ( Buffer Pool's To Physical Memory / 16 ). Come restituito dalla chiamata API GlobalMemoryStatusEx (ullTotalPhys). ^[9]
  • Trace Flag 3213restituisce i parametri di configurazione di backup / ripristino durante l'esecuzione di operazioni di backup / ripristino e 3605scarica l'output nel file ERRORLOG :DBCC TRACEON (3213, 3605, -1);
  • È possibile utilizzare DISK = N'NUL:'(equivalente DOS / Windows di /dev/nullin UNIX) per testare più facilmente alcune metriche (ma non avrà un buon senso del tempo totale del processo poiché salta l'I / O di scrittura)

risorse

1. Pagina MSDN per il comando T-SQL BACKUP
2. KB904804: si verificano prestazioni lente quando si esegue il backup del database in SQL Server 2000
3. Opzioni per migliorare le prestazioni di backup di SQL Server
4. Backup e ripristino
5. Ottimizzazione del backup e del ripristino di SQL Server
6. Ottimizzazione delle prestazioni di backup
7. Come aumentare la velocità di backup completo del database SQL utilizzando la compressione e i dischi a stato solido
8. L'opzione di trasferimento dati BufferCount errata può portare alla condizione OOM
9. Come funziona: come fa SQL Server Backup and Restore a selezionare le dimensioni di trasferimento
10. Come funziona: scambio di buffer di backup di SQL Server (focus VDI)
11. Backup SQL ottimizzazione di database di grandi dimensioni
12. Memoria di SQL Server per il buffer di backup
13. Un caso di studio: backup e ripristino rapidi e affidabili di un VLDB sulla rete (file .docx)
14. Quanti dispositivi di backup sono consigliati per migliorare le prestazioni di backup?

Ho provato con:

--DBCC TRACEON (3213, 3605, -1);

BACKUP DATABASE [Test] TO
      DISK =  'NUL:'
     --,DISK = 'NUL:'
     -- DISK =  'BackupTest1.bak'
     -- ,DISK =  'BackupTest2.bak'
WITH
    STATS = 5,
    FORMAT,
    CHECKSUM,
    NO_COMPRESSION,
    COPY_ONLY
    --,BUFFERCOUNT = 40
    --,MAXTRANSFERSIZE = 4194304--2097152,
    --,BLOCKSIZE = 16384 

--DBCC TRACEOFF (3213, 3605, -1);

AGGIORNARE

Sembra che a volte mi dimentichi di aggiungere alcune delle informazioni che chiedo sempre agli altri di fornire quando rispondo a una domanda ;-). Ho fornito alcune informazioni sopra riguardanti la mia situazione attuale, ma posso fornire maggiori dettagli:

Sto lavorando per un client che fornisce un'applicazione SaaS 24/7 / 365,25. Quindi c'è il potenziale per gli utenti di essere attivi in ​​qualsiasi momento, ma realisticamente, gli utenti sono tutti con sede negli Stati Uniti (per ora) e tendono a lavorare per lo più ore "standard": dalle 7:00 del Pacifico (vale a dire 10:00 orientali) alle 19:00 del Pacifico (ad es. 10 PM est), ma 7 giorni a settimana, non solo dal lunedì al venerdì, anche se il carico del fine settimana è leggermente più leggero.

Sono impostati in modo tale che ogni client abbia il proprio DB. È un settore di nicchia, quindi non ci sono decine di migliaia (o più) di potenziali clienti. Il numero di DB client varia in base all'istanza, con l'istanza più grande con 206 client. Il DB più grande è di ca. 8 GB, ma solo circa 30 DB superano 1 GB. Quindi, non sto specificamente cercando di massimizzare le prestazioni di un VLDB.

Quando ho iniziato con questo client, i loro backup erano sempre PIENI, una volta al giorno e nessun backup LOG. Avevano anche impostato MAXTRANSFERSIZE su 4 MB e BUFFERCOUNT su 50. Ho sostituito quella configurazione con una versione leggermente personalizzata dello script di backup del database di Ola Hallengren . La parte leggermente personalizzata è che viene eseguito da uno strumento multi-thread (che ho scritto e che spero inizierò presto a vendere) che scopre dinamicamente i DB mentre si collega a ciascuna istanza e consente la limitazione per istanza (quindi sto attualmente eseguendo il tre istanze contemporaneamente, ma i DB per ogni istanza in sequenza poiché non ero sicuro delle ramificazioni di eseguirli contemporaneamente).

L'installazione prevede ora l'esecuzione di un backup COMPLETO un giorno alla settimana e di DIFF negli altri giorni; I backup del LOG vengono eseguiti ogni 10 minuti. Sto usando i valori predefiniti per le 3 opzioni di cui sto indagando qui. Ma, sapendo come erano stati impostati, volevo assicurarmi di non annullare un'ottimizzazione (solo perché c'erano alcuni difetti importanti nel vecchio sistema non significa che tuttoera sbagliata). Attualmente, per i 206 database, sono necessari circa 62 minuti per i backup FULL (una volta alla settimana) e tra 7 e 20 minuti per i backup DIFF nei giorni rimanenti (7 il primo giorno dopo il FULL e 20 nell'ultimo giorno prima il prossimo COMPLETO). E questo li sta eseguendo in sequenza (thread singolo). Il processo di backup del LOG, in totale (tutti i DB su tutte e 3 le istanze), richiede dai 50 ai 90 secondi ogni volta (di nuovo, ogni 10 minuti).

Mi rendo conto di poter eseguire più file per DB, ma a) Non sono sicuro di quanto sarà meglio il multithreading e le dimensioni medio-piccole dei DB, e b) Non voglio complicare il processo di ripristino ( ci sono vari motivi per cui si preferisce gestire un singolo file).

Mi rendo anche conto che potrei abilitare la compressione (la mia query di test lo ha intenzionalmente disabilitato), e l'avevo raccomandato al team, ma mi è stato portato alla mia attenzione che la compressione integrata è un po 'schifosa. Parte del vecchio processo consisteva nel comprimere ogni file in una RAR, e ho fatto i miei test e ho scoperto che sì, la versione RAR è almeno del 50% più piccola della versione compressa nativamente. Ho provato a usare prima la compressione nativa per accelerare le cose e poi RAR i file, ma quei file, sebbene più piccoli di quelli semplicemente compressi in modo nativo, erano ancora un po 'più grandi della versione compressa solo RAR e con una differenza sufficiente per giustificare non usando la compressione nativa. Il processo per comprimere i backup è asincrono e viene eseguito ogni X minuti. Se trova un .bako.trnfile, lo comprime. In questo modo, il processo di backup non viene rallentato dal tempo necessario per comprimere ciascun file.

Hai indirizzato un carico di oggetti nella tua domanda. Grazie per essere così completo!

Solo un paio di cose che noto fuori mano:

• In che modo vari fattori hardware / di carico influenzano ciò che dovrebbe essere fatto.

Stai eseguendo un'istanza 24x7? Qual è il carico tutto il giorno? Ho notato che la compressione del backup è disabilitata; è progettato per il test o è desiderabile per qualche motivo spegnerlo quando lo si mette in produzione? Se si dispone di tonnellate di headroom hardware (CPU / RAM) e il completamento del backup nel più breve tempo è di fondamentale importanza, si consiglia di ottimizzare questi parametri per l'hardware specifico che si ha con quell'obiettivo in mente. Se vuoi assicurarti che i carichi di lavoro OLTP siano gestiti 24 ore su 24 e non desideri che il backup influisca su questo, probabilmente dovrai ottimizzare questi parametri al contrario. Non hai identificato i tuoi obiettivi di progettazione da quando stai chiedendo una guida generale, tuttavia affermi così saggiamente che "dipende ™".

• Ci sono circostanze in cui nessuno di questi valori deve essere ignorato?

Vorresti conservare le impostazioni predefinite se eri preoccupato per il supporto lungo la strada dopo che non hai più mantenuto l'istanza e non sei sicuro delle capacità del tuo sostituto. Probabilmente vorrai lasciare le impostazioni predefinite a meno che tu non abbia una necessità specifica di ottimizzarle. Lascia che i cani che dormono mentano, come si suol dire.

• Ci sono insidie ​​per scavalcare qualcuno di questi che non sono immediatamente evidenti? Stai utilizzando troppa memoria e / o I / O su disco? Operazioni di ripristino complicate?

Come indicano chiaramente i documenti a cui si fa riferimento, un aumento eccessivo di questi parametri può certamente avere un impatto negativo sui tempi di attività. Come per tutte le cose basate sulla produzione, è necessario testarlo accuratamente prima di distribuirlo e lasciare le impostazioni da sole a meno che non sia assolutamente necessario.

• Se ho un server con più istanze di SQL Server in esecuzione (un'istanza predefinita e due istanze denominate) e se eseguo i backup di tutte e 3 le istanze contemporaneamente, ciò influisce sul modo in cui imposto questi valori oltre a verificare che il collettivo (BUFFERCOUNT * MAXTRANSFERSIZE) non supera la RAM disponibile? Possibile contesa I / O?

Ti consigliamo di lasciare molta RAM per circostanze impreviste. Sarei sicuramente preoccupato di utilizzare più del 60% o del 70% della RAM disponibile per le operazioni di backup, a meno che non sapessi con certezza al 100% che non sarebbe mai accaduto nient'altro durante la finestra di backup.

Ho scritto un post sul blog con del codice che mostra come eseguo il test delle prestazioni di backup su SQLServerScience.com

^{questa potrebbe non essere la migliore risposta che abbia mai scritto, ma come ha detto una volta The Great One ™, "ti manca il 100% degli scatti che non fai"}