Définition de BUFFERCOUNT, BLOCKSIZE et MAXTRANSFERSIZE pour la commande BACKUP

Je cherche pratique des orientations pour définir les valeurs pour la BUFFERCOUNT, BLOCKSIZEet MAXTRANSFERSIZEde la BACKUPcommande. J'ai fait un peu de recherche (voir ci-dessous), j'ai fait quelques essais et je suis tout à fait conscient que toute réponse vraiment utile commencera par "Eh bien, ça dépend ...". Ce qui me préoccupe au sujet des tests que j'ai effectués et des tests présentés dans l'une des ressources que j'ai trouvées (voir ci-dessous) est que les tests sont effectués en vase clos, le plus souvent sur un système sans autre charge.

Je suis curieux de savoir quelles sont les orientations / meilleures pratiques appropriées concernant ces trois options basées sur une expérience à long terme: de nombreux points de données sur des semaines ou des mois. Et je ne cherche pas de valeurs spécifiques, car celles-ci dépendent principalement du matériel disponible, mais j'aimerais savoir:

• Comment divers facteurs de matériel / charge influencent ce qui doit être fait.
• Existe-t-il des circonstances dans lesquelles aucune de ces valeurs ne doit être remplacée?
• Existe-t-il des pièges à éviter qui ne soient pas immédiatement évidents? Vous utilisez trop de mémoire et / ou d'E / S disque? Compliquer les opérations de restauration?
• Si j’ai un serveur avec plusieurs instances de SQL Server en cours d’exécution (une instance par défaut et deux instances nommées), et si j’exécute les sauvegardes simultanément des 3 instances, cela affecte-t-il la façon dont je définis ces valeurs au-delà de la vérification du caractère collectif ( BUFFERCOUNT*)? MAXTRANSFERSIZE) ne dépasse pas la RAM disponible? Conflit possible d'E / S?
• Dans le même scénario consistant à avoir les trois instances sur un serveur et à exécuter à nouveau les sauvegardes simultanément, comment l'exécution des sauvegardes simultanément pour plusieurs bases de données au sein de chaque instance affecterait-elle le paramétrage de ces valeurs? Cela signifie que si chacune des trois instances a 100 bases de données chacune, en exécutant simultanément 2 ou 3 sauvegardes pour chaque instance, de sorte qu'il y ait entre 6 et 9 sauvegardes exécutées simultanément. (Dans cette situation, j'ai beaucoup de bases de données petites à moyennes plutôt que quelques grandes.)

Ce que j'ai rassemblé jusqu'ici:

• BLOCKSIZE:

  • Les tailles prises en charge sont 512, 1024, 2048, 4096, 8192, 16384, 32768 et 65536 (64 Ko) octets. ^[1]
  • La valeur par défaut est 65 536 pour les unités de bande et 512 sinon ^[1]
  • Si vous effectuez une sauvegarde sur laquelle vous prévoyez de copier et de restaurer à partir d'un CD-ROM, spécifiez BLOCKSIZE = 2048 ^[1].
  • Lorsque vous écrivez sur des disques simples, la valeur par défaut de 512 convient parfaitement; Si vous utilisez des baies RAID ou SAN, vous devez vérifier si la valeur par défaut ou 65536 est meilleure. ^{[13 (page 18)]}

  • Si vous configurez manuellement, la valeur doit être> = la taille de bloc utilisée pour créer le ou les fichiers de données, sinon vous obtiendrez l'erreur suivante:

    Msg 3272, niveau 16, état 0, ligne 3
    Le périphérique 'C: \ Program Files \ Microsoft SQL Server \ MSSQL11.MSSQLSERVER \ MSSQL \ Backup \ BackupTest.bak' a une taille de secteur matériel de 4096, mais le paramètre de taille de bloc spécifie une valeur de remplacement incompatible de 512. Relancez l'instruction en utilisant une taille de bloc compatible.

• BUFFERCOUNT:

  • Par défaut ^{[2], [8]} :

    SQL Server 2005 et versions ultérieures:
    (NumberofBackupDevices * [mystery_multiplier]) + NumberofBackupDevices + (2 * NumberofVolumesInvolved)

  • [mystery_multiplier]: Il existe certaines incohérences concernant cette valeur. Je l'ai vu exprimé sous 3 formes:

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

    
    Les tests montrant que le multiplicateur à être a 3été effectué sur SQL Server 2005 SP2 ^[9] .

    Mes tests sur SQL Server 2008 R2 et 2012, ainsi qu'un commentaire d'utilisateur concernant SQL Server 2014 ^[8] , indiquent que le multiplicateur est 4. Signification, étant donné la valeur indiquée pour GetSuggestedIoDepth(directement ci-dessous), soit:

    • GetSuggestedIoDepthest maintenant 4, ou
    • le multiplicateur est maintenant GetSuggestedIoDepth + 1
  • GetSuggestedIoDepthretourne 3pour les périphériques DISK ^[9]
  • Aucune valeur maximale définie, mais étant donné que la mémoire est requise = ( BUFFERCOUNT* MAXTRANSFERSIZE), il semblerait qu'une valeur maximale pratique serait: BUFFERCOUNT <= (available_memory / MAXTRANSFERSIZE)
• MAXTRANSFERSIZE:
  • Les valeurs possibles sont des multiples de 65 536 octets (64 Ko) allant jusqu'à 4194304 octets (4 Mo). ^[1]
  • Valeurs par défaut: Si le périphérique est en mode lecture (restauration) ou s'il s'agit d'un ordinateur de bureau ou Express Edition, utilisez 64 Ko, sinon utilisez 1 Mo. ^[9]
• Général / Divers:
  • La taille maximale pouvant être utilisée est la suivante: ( mémoire physique / 16 du pool de mémoire tampon ). En retour de l' GlobalMemoryStatusEx appel API (ullTotalPhys). ^[9]
  • L' indicateur de trace génère les 3213paramètres de configuration de sauvegarde / restauration lors des opérations de sauvegarde / restauration et 3605dump la sortie dans le fichier ERRORLOG :DBCC TRACEON (3213, 3605, -1);
  • Vous pouvez utiliser DISK = N'NUL:'(équivalent DOS / Windows ou sous /dev/nullUNIX) pour tester plus facilement certaines métriques (mais vous n'aurez pas une bonne idée du temps total du processus car il ignore les E / S en écriture).

Ressources

1. Page MSDN T-SQL BACKUP commande
2. KB904804: Les performances sont ralenties lorsque vous sauvegardez la base de données dans SQL Server 2000
3. Options pour améliorer les performances de sauvegarde SQL Server
4. Sauvegarde et restauration
5. Optimisation de la sauvegarde et de la restauration de SQL Server
6. Optimiser les performances de sauvegarde
7. Comment augmenter la vitesse de sauvegarde complète de la base de données SQL à l'aide de la compression et des disques SSD
8. Une option de transfert de données BufferCount incorrecte peut conduire à une condition de MOO
9. Comment ça marche: Comment la sauvegarde et la restauration SQL Server sélectionnent-elles les tailles de transfert
10. Comment ça marche: Echange de tampon de sauvegarde SQL Server (un focus VDI)
11. Sauvegarde SQL optimisant les bases de données volumineuses
12. Mémoire SQL Server pour le tampon de sauvegarde
13. Étude de cas: Sauvegarde et restauration rapides et fiables d'un VLDB sur le réseau (fichier .docx)
14. Combien de périphériques de sauvegarde est recommandé pour améliorer les performances de sauvegarde?

J'ai testé avec:

--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);

MISE À JOUR

Il semble que j’oublie parfois d’ajouter certaines des informations que je demande toujours aux autres de fournir lorsque je réponds à une question ;-). J'ai donné quelques informations ci-dessus concernant ma situation actuelle, mais je peux fournir plus de détails:

Je travaille pour un client qui fournit une application SaaS 24/7 / 365.25. Il est donc possible que les utilisateurs soient connectés à tout moment, mais de manière réaliste, ils sont tous basés aux États-Unis (pour le moment) et ont tendance à travailler en général (c'est-à-dire 22 h, heure de l'Est), mais 7 jours par semaine, pas seulement du lundi au vendredi, bien que la charge de week-end soit un peu plus légère.

Ils sont configurés de manière à ce que chaque client possède son propre DB. Il s’agit d’un secteur de niche, de sorte qu’il n’ya pas des dizaines de milliers (ou plus) de clients potentiels. Le nombre de bases de données client varie selon les instances, l'instance la plus grande contenant 206 clients. Le plus grand DB est d'env. 8 Go, mais seulement environ 30 bases de données dépassent 1 Go. Par conséquent, je ne cherche pas spécifiquement à optimiser les performances d'un VLDB.

Lorsque j'ai commencé avec ce client, leurs sauvegardes étaient toujours PLEINES, une fois par jour, et pas de sauvegardes LOG. Ils avaient également défini MAXTRANSFERSIZE sur 4 Mo et BUFFERCOUNT sur 50. J'ai remplacé cette installation par une version légèrement personnalisée du script de sauvegarde de base de données d' Ola Hallengren . La partie légèrement personnalisée est qu’il est exécuté à partir d’un outil multi-thread (que j’ai écrit et que nous espérons vendre prochainement) qui détecte de manière dynamique les bases de données lorsqu’il se connecte à chaque instance et permet une limitation par instance (d’où le trois instances simultanément, mais les bases de données de chaque instance se suivent de manière séquentielle, car je n’étais pas sûr des conséquences de leur exécution simultanée).

La configuration consiste maintenant à effectuer une sauvegarde COMPLETE un jour par semaine et des sauvegardes DIFF les autres jours; Les sauvegardes du journal sont effectuées toutes les 10 minutes. J'utilise les valeurs par défaut pour les 3 options que je cherche ici. Mais, sachant comment elles avaient été définies, je voulais m'assurer que je n'annulerais pas une optimisation (ce n'est pas parce que l'ancien système présentait des failles majeures que toutétait faux). Actuellement, pour les 206 bases de données, il faut environ 62 minutes pour les sauvegardes FULL (une fois par semaine) et entre 7 et 20 minutes pour les sauvegardes DIFF les jours restants (7 le premier jour suivant le FULL, et 20 le dernier jour précédent). le prochain complet). Et cela les exécute de manière séquentielle (thread unique). Le processus de sauvegarde LOG, au total (tous les DB sur les 3 instances), prend entre 50 et 90 secondes à chaque fois (toutes les 10 minutes).

Je me rends compte que je peux exécuter plusieurs fichiers par base de données, mais a) je ne suis pas certain de l’amélioration du multithreading et de la taille petite à moyenne des bases de données; b) je ne veux pas compliquer le processus de restauration ( il est préférable de traiter avec un seul fichier).

Je me suis aussi rendu compte que je pouvais activer la compression (ma requête de test l'a volontairement désactivée), et je l'avais recommandée à l'équipe, mais on m'a signalé que la compression intégrée était un peu nulle. Une partie de l'ancien processus consistait à compresser chaque fichier dans un fichier RAR. J'ai effectué mes propres tests et constaté qu'oui, la version du fichier RAR est au moins 50% plus petite que la version compressée en mode natif. J’ai tout d’abord essayé d’utiliser la compression native pour accélérer les choses, puis RAR, mais ces fichiers, bien que plus petits que ceux compressés nativement, étaient toujours un peu plus volumineux que la version compressée uniquement avec RAR, et suffisamment différents pour justifier ne pas utiliser la compression native. Le processus de compression des sauvegardes est asynchrone et s'exécute toutes les X minutes. S'il trouve un .bakou.trnfichier, il le compresse. De cette façon, le processus de sauvegarde n'est pas ralenti par le temps nécessaire pour compresser chaque fichier.

Vous avez abordé de nombreux problèmes dans votre question. Merci d'être si complet!

Je remarque juste quelques petites choses:

• Comment divers facteurs de matériel / charge influencent ce qui doit être fait.

Exécutez-vous une instance 24x7? Quelle est la charge autour de l'horloge? Je remarque que la compression de sauvegarde est désactivée. est-ce que cela est voulu pour le test ou est-il souhaitable pour une raison quelconque de le désactiver lorsque vous mettez cela en production? Si vous disposez de beaucoup de marge matérielle (CPU / RAM) et qu'il est primordial d'effectuer la sauvegarde dans les plus brefs délais, vous voudrez alors adapter ces paramètres au matériel dont vous disposez. Si vous voulez vous assurer que les charges de travail OLTP sont traitées 24 heures sur 24 et que vous ne voulez pas que la sauvegarde influe sur cela, vous devrez probablement ajuster ces paramètres dans l'autre sens. Vous n’avez pas défini vos objectifs de conception depuis que vous demandez des directives générales, mais vous déclarez si judicieusement que «cela dépend».

• Existe-t-il des circonstances dans lesquelles aucune de ces valeurs ne doit être remplacée?

Vous voudriez conserver les paramètres par défaut si vous vous inquiétiez de la prise en charge ultérieure lorsque vous ne gérez plus l'instance et si vous ne connaissez pas les capacités de votre remplaçant. Vous voudrez probablement laisser les valeurs par défaut, sauf si vous avez un besoin spécifique de les régler. Laissez les chiens endormis, comme on dit.

• Existe-t-il des pièges à éviter qui ne soient pas immédiatement évidents? Vous utilisez trop de mémoire et / ou d'E / S disque? Compliquer les opérations de restauration?

Comme l'indiquent clairement les documents que vous citez, augmenter trop ces paramètres peut certainement avoir des effets négatifs sur la disponibilité. Comme pour tout ce qui concerne la production, vous devez tester cela minutieusement avant de le déployer et laisser les paramètres de côté, sauf en cas d'absolue nécessité.

• Si j’ai un serveur avec plusieurs instances de SQL Server en cours d’exécution (une instance par défaut et deux instances nommées), et si j’exécute les sauvegardes simultanément des 3 instances, cela affecte-t-il la façon dont je définis ces valeurs au-delà de la vérification du regroupement (BUFFERCOUNT)? * MAXTRANSFERSIZE) ne dépasse-t-il pas la RAM disponible? Conflit possible d'E / S?

Vous voudrez vous assurer de laisser beaucoup de RAM pour des circonstances imprévues. Je serais certainement préoccupé par l’utilisation de plus de 60% ou 70% de la mémoire vive disponible pour les opérations de sauvegarde, à moins que je sache avec une certitude à 100% que rien ne se passera jamais pendant la fenêtre de sauvegarde.

J'ai écrit un article de blog avec du code qui montre comment tester les performances de sauvegarde sur SQLServerScience.com.

^{ce n'est peut-être pas la meilleure réponse que j'ai jamais écrite, mais comme l'a déjà dit The Great One ™, "vous ratez 100% des photos que vous ne prenez pas"}