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

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.

sql-server backup best-practices maintenance Salomon Rutzky
la source

Juste curieux, essayez-vous de résoudre un problème de sauvegarde lente? Normalement, les valeurs par défaut fonctionnent correctement dans la plupart des environnements. En outre, l'option d'alimentation est définie sur hautes performances, car la sauvegarde utilise des cycles de processeur.

Kin Shah

@Kin Non, les sauvegardes ne sont pas particulièrement lentes. Mais, si faire un changement mineur les rendrait / pourrait les rendre 20% (ou plus) plus rapide, alors je le prendrais certainement. Pour 206 bases de données, cela prend environ 62 minutes pour les sauvegardes complètes (une fois par semaine) et entre 7 et 20 minutes pour les sauvegardes DIFF les autres jours. Et cela les exécute de manière séquentielle (thread unique). Lorsque j'ai démarré avec ce client, la configuration précédente consistait à utiliser 4 Mo pour MaxTransfer et 50 pour BufferCount. À l’heure actuelle, j’utilise simplement les paramètres par défaut. Je ne sais donc pas si j’ai annulé un gain de performance. Je voulais donc en savoir plus avant d’apporter des modifications.

Solomon Rutzky

@srutzky juste un petit point par rapport à votre dernier commentaire, j’ai gagné un temps considérable à décomposer mes sauvegardes en plusieurs fichiers allant sur le même volume. Je voulais juste partager cela avec vous au cas où vous ne l'auriez pas encore essayé. Si vos 206 bases de données exécutent une sauvegarde en parallèle sur plusieurs bases, vous risquez de ne pas bénéficier des avantages du multi-threading.

Ali Razeghi

@MaxVernon "Les sauvegardes d'interface de périphérique virtuel (VDI) permettent aux solutions de sauvegarde tierces de s'intégrer à SQL Server", tiré de la ressource n ° 10 de ma question :). Je ne voulais pas faire autant d'efforts ;-)

Solomon Rutzky

@srutzky au cas où vous voudriez vous amuser un peu: lisez MSSQL Backups - vérifiez la taille de transfert maximale du HBA - le gars est brillant et très complet dans ses tests. Et quelque chose qui correspond probablement à vos tests: le réglage automatique des sauvegardes de SirSQL .

Marian

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

Réponses: