web-dev-qa-db-fra.com

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

Je recherche pratique des conseils pour définir les valeurs des BUFFERCOUNT, BLOCKSIZE et MAXTRANSFERSIZE des BACKUP commander. J'ai fait un peu de recherche (voir ci-dessous), j'ai fait un peu de test, et je suis pleinement conscient que toute réponse vraiment valable commencera par "Eh bien, cela dépend ...". Mes préoccupations concernant les tests que j'ai effectués et les tests indiqués dans l'une des ressources que j'ai trouvées (voir ci-dessous) sont que les tests sont effectués dans le vide, très probablement sur un système sans autre charge.

Je suis curieux de connaître les bonnes orientations/meilleures pratiques 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 recherche pas de valeurs spécifiques car c'est principalement une fonction du matériel disponible, mais je voudrais savoir:

  • Comment divers facteurs matériels/de charge influencent ce qui doit être fait.
  • Existe-t-il des circonstances dans lesquelles aucune de ces valeurs ne doit être remplacée?
  • Y a-t-il des écueils pour passer outre à ceux qui ne sont pas immédiatement évidents? Vous utilisez trop de mémoire et/ou d'E/S disque? Vous compliquez 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 des 3 instances simultanément, cela affecte-t-il la façon dont je définis ces valeurs au-delà de m'assurer que le collectif (BUFFERCOUNT * MAXTRANSFERSIZE) ne dépasse pas la RAM disponible? Contention d'E/S possible?
  • Dans ce même scénario où les trois instances se trouvent sur un seul serveur et qui exécutent à nouveau les sauvegardes sur les trois simultanément, comment l'exécution simultanée des sauvegardes de plusieurs bases de données dans chaque instance affecterait-elle le réglage de ces valeurs? Autrement dit, si chacune des trois instances a 100 bases de données chacune, l'exécution simultanée de 2 ou 3 sauvegardes pour chaque instance de sorte qu'il y a entre 6 et 9 sauvegardes exécutées simultanément. (Dans cette situation, j'ai de nombreuses bases de données petites à moyennes plutôt que quelques grandes.)

Ce que j'ai rassemblé jusqu'à présent:

  • 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 65536 pour les unités de bande et 512 sinon [1]
    • Si vous effectuez une sauvegarde que 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 est très bien; si vous utilisez des matrices RAID ou SAN, vous devez tester pour voir si la valeur par défaut ou 65536 est meilleure. [13 (page 18)]

    • Si vous définissez manuellement, la valeur doit être> = la taille de bloc utilisée pour créer le (s) fichier (s) 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 à l'aide d'une taille de bloc compatible.

  • BUFFERCOUNT:

    • Défaut [2], [8]:

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

    • [mystery_multiplier]: Il existe une certaine incohérence concernant cette valeur. Je l'ai vu s'exprimer sous 3 formes:

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


      Le test qui montre que le multiplicateur doit être 3 A été effectué sur SQL Server 2005 SP2 [9].

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

      • GetSuggestedIoDepth est maintenant 4, ou
      • le multiplicateur est maintenant GetSuggestedIoDepth + 1
    • GetSuggestedIoDepth renvoie 3 pour les périphériques DISK [9]
    • Pas de valeur max définie, mais étant donné que la mémoire requise = (BUFFERCOUNT * MAXTRANSFERSIZE), il semblerait qu'une valeur max pratique soit: BUFFERCOUNT <= (available_memory / MAXTRANSFERSIZE)
  • MAXTRANSFERSIZE:
    • Les valeurs possibles sont des multiples de 65536 octets (64 Ko) allant jusqu'à 4194304 octets (4 Mo). [1]
    • Valeurs par défaut: si l'appareil est en mode lecture (restauration) ou s'il s'agit d'un bureau ou d'une édition Express, utilisez 64 Ko, sinon utilisez 1 Mo. [9]
  • Général/Divers:
    • La taille maximale qui peut être utilisée est la ( mémoire tampon du pool de mémoire physique/16 ). Tel que renvoyé par l'appel de l'API GlobalMemoryStatusEx (ullTotalPhys). [9]
    • L'indicateur de trace 3213 Affiche les paramètres de configuration de sauvegarde/restauration lors des opérations de sauvegarde/restauration, et 3605 Exporte la sortie vers le [~ # ~] journal des erreurs [~ # ~] fichier: DBCC TRACEON (3213, 3605, -1);
    • Vous pouvez utiliser DISK = N'NUL:' (Équivalent DOS/Windows de /dev/null Sous UNIX) pour tester plus facilement certaines mesures (mais vous n'aurez pas une bonne idée du temps total du processus car il ignore l'écriture que je/O)

Ressources

  1. Page MSDN pour T-SQL SAUVEGARDE commande
  2. KB904804: vous rencontrez des performances lentes lorsque vous sauvegardez la base de données dans SQL Server 20
  3. Options pour améliorer les performances de sauvegarde de SQL Server
  4. Sauvegarde et restauration
  5. Optimisation de la sauvegarde et de la restauration de SQL Server
  6. Optimisation des 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. ne option de transfert de données BufferCount incorrecte peut conduire à une condition de MOO
  9. Fonctionnement: comment la sauvegarde et la restauration de SQL Server sélectionnent-elles les tailles de transfert
  10. Fonctionnement: échange de tampons de sauvegarde SQL Server (un focus VDI)
  11. SQL Backup optimisation de grandes bases de données
  12. Mémoire SQL Server pour tampon de sauvegarde
  13. ne étude de cas: sauvegarde et restauration rapides et fiables d'un VLDB sur le résea (fichier .docx)
  14. Combien d'appareils 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 informations que je demande toujours aux autres 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 24/7/365,25 SaaS. Il est donc possible que les utilisateurs soient activés à tout moment, mais en réalité, les utilisateurs sont tous basés aux États-Unis ( pour l'instant) et ont tendance à travailler principalement des heures "standard": 7 h du Pacifique (soit 10 h 00 de l'Est) à 7 PM Pacifique (c.-à-d. 10 PM de l'Est) , mais 7 jours sur 7, pas seulement du lundi au vendredi, bien que la charge du week-end soit un peu plus légère.

Ils sont configurés de telle sorte que chaque client possède sa propre base de données. C'est une industrie de niche, il n'y a donc pas des dizaines de milliers (ou plus) de clients potentiels. Le nombre de bases de données client varie selon l'instance, la plus grande instance contenant 206 clients. La plus grande DB est d'env. 8 Go, mais seulement environ 30 bases de données dépassent 1 Go. Par conséquent, je n'essaie pas spécifiquement de maximiser les performances d'un VLDB.

Quand j'ai commencé avec ce client, leurs sauvegardes étaient toujours PLEINES, une fois par jour, et aucune sauvegarde LOG. Ils avaient également défini MAXTRANSFERSIZE sur 4 Mo et BUFFERCOUNT sur 50. J'ai remplacé cette configuration par une version légèrement personnalisée du script de sauvegarde de la base de données Ola Hallengren . La partie légèrement personnalisée est qu'elle est exécutée à partir d'un outil multithread (que j'ai écrit et que j'espère commencer à vendre bientôt) qui découvre dynamiquement les bases de données lors de sa connexion à chaque instance et permet la limitation par instance (par conséquent, j'exécute actuellement le trois instances simultanément, mais les bases de données pour chaque instance séquentiellement, car je n'étais pas sûr des ramifications de leur exécution simultanée).

La configuration consiste maintenant à effectuer une sauvegarde COMPLÈTE un jour par semaine et des sauvegardes DIFF les autres jours; Les sauvegardes LOG sont effectuées toutes les 10 minutes. J'utilise les valeurs par défaut pour les 3 options que je recherche ici. Mais, sachant comment ils avaient été définis, je voulais m'assurer que je n'annulais pas une optimisation (simplement parce qu'il y avait des défauts majeurs dans l'ancien système ne veut pas dire que tout était faux ). Actuellement, pour les 206 bases de données, il faut environ 62 minutes pour les sauvegardes COMPLÈTES (une fois par semaine) et entre 7 et 20 minutes pour les sauvegardes DIFF les jours restants (7 le premier jour après la PLEINE et 20 le dernier jour avant le prochain COMPLET). Et cela les exécute séquentiellement (un seul thread). Le processus de sauvegarde LOG, au total (toutes les bases de données sur les 3 instances), prend de 50 à 90 secondes à chaque fois (encore une 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 sais pas à quel point cela sera amélioré grâce au multithreading et à la taille petite à moyenne des bases de données, et b) je ne veux pas compliquer le processus de restauration ( il existe plusieurs raisons pour lesquelles il est préférable de traiter un seul fichier).

Je me rends également compte que je pouvais activer la compression (ma requête de test l'a intentionnellement désactivée), et je l'avais recommandé à l'équipe, mais il a été porté à mon attention que la compression intégrée est un peu excitante. Une partie de l'ancien processus consistait à compresser chaque fichier en un fichier RAR, et j'ai fait mes propres tests et j'ai constaté que oui, la version RAR est au moins 50% plus petite que la version compressée en mode natif. J'ai essayé d'utiliser la compression native d'abord pour accélérer les choses, puis RAR les fichiers, mais ces fichiers, bien que plus petits que ceux compressés nativement, étaient toujours un peu plus grands que la version compressée RAR uniquement, et par suffisamment de différence pour justifier n'utilise pas la compression native. Le processus de compression des sauvegardes est asynchrone et s'exécute toutes les X minutes. S'il trouve un fichier .bak Ou .trn, 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-serverbackupbest-practicesmaintenance
34
Solomon Rutzky

Vous avez abordé une cargaison d'articles dans votre question. Merci d'être si complet!

Juste deux ou trois choses que je remarque de loin:

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

Exécutez-vous une instance 24x7? Quelle est la charge 24h/24? Je remarque que la compression de sauvegarde est désactivée; est-ce par conception pour le test, ou est-il souhaitable pour une raison quelconque de le désactiver lorsque vous le mettez en production? Si vous avez des tonnes de marge de sécurité matérielle (CPU/RAM), et que terminer la sauvegarde dans les plus brefs délais est d'une importance capitale, alors vous voudrez régler ces paramètres pour le matériel particulier que vous avez avec cet objectif en tête. Si vous voulez vous assurer que les charges de travail OLTP sont entretenues 24 heures sur 24 et que vous ne voulez pas que la sauvegarde ait un impact, vous devrez probablement régler ces paramètres dans l'autre sens. Vous n'avez pas identifié vos objectifs de conception puisque vous demandez des conseils généraux cependant, comme vous le dites si sagement "ça 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 étiez préoccupé par la prise en charge sur la route après que vous ne mainteniez plus l'instance et que vous ne soyez pas sûr des capacités de votre remplaçant. Vous voudrez probablement laisser les valeurs par défaut en place, sauf si vous avez un besoin spécifique de les régler. Laissez les chiens endormis mentir, comme on dit.

  • Y a-t-il des écueils pour passer outre à ceux qui ne sont pas immédiatement évidents? Vous utilisez trop de mémoire et/ou d'E/S disque? Vous compliquez les opérations de restauration?

Comme l'indiquent clairement les documents auxquels vous faites référence, une augmentation excessive de ces paramètres peut certainement avoir des impacts négatifs sur la disponibilité. Comme pour tout ce qui est basé sur la production, vous devez le tester soigneusement avant de le déployer et laisser les paramètres seuls, sauf si cela est absolument nécessaire.

  • 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 simultanément les sauvegardes des 3 instances, cela affecte-t-il la façon dont je définit ces valeurs au-delà de m'assurer que le collectif (BUFFERCOUNT * MAXTRANSFERSIZE) ne dépasse pas la RAM disponible? Contention d'E/S possible?

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% du bélier disponible pour les opérations de sauvegarde sauf si je savais avec 100% de certitude que rien d'autre ne se produirait pendant la fenêtre de sauvegarde.

J'ai écrit un article de blog avec du code qui montre comment je fais des tests de performances de sauvegarde, sur SQLServerScience.com

ce n'est peut-être pas la meilleure réponse que j'aie jamais écrite, mais comme le disait The Great One ™, "vous manquez 100% des photos que vous ne prenez pas"

12
Max Vernon