Internes de sauvegarde - Que se passe-t-il lorsqu'une tâche de sauvegarde est en cours d'exécution - en termes de verrouillage et de surcharge de performances dans SQL Server?

Pour MySQL, je sais que la base de données est sauvegardée table par table dans les instructions SQL, cela entraîne un verrouillage et si vous mettez à jour les colonnes pendant la sauvegarde, vous risquez de vous retrouver avec des problèmes d'intégrité.

À ma connaissance, cela ne s'applique pas à Microsoft SQL Server, mais comment SQL Server gère-t-il cela? Y a-t-il un gel interne pour garder la base de données cohérente?

J'ai également entendu dire que la sauvegarde est monothread, ce qui signifie qu'elle n'utilise qu'un seul noyau, en supposant que vous sauvegardez dans un seul fichier. En supposant également que vous avez une machine multicœur, par exemple 16 cœurs, ou au moins un nombre supérieur à un.

D'après mon expérience personnelle, je n'ai jamais eu de problème lors de la prise de sauvegardes, ni de verrouillage ni de surcharge, mais mon expérience est limitée. C'est pourquoi je recommande toujours d'activer la compression de sauvegarde dans les propriétés du serveur.

Que se passe-t-il donc lorsqu'un travail de sauvegarde est en cours d'exécution? Et y a-t-il également des différences significatives pour les différentes versions? par exemple 2008,2012 et 2014 (pas les licences).

Tous vos points sont couverts dans les mythes de sauvegarde - par Paul Randal

30-01) les opérations de sauvegarde provoquent un blocage

Non. Les opérations de sauvegarde ne prennent pas de verrous sur les objets utilisateur . Les sauvegardes provoquent une charge de lecture très lourde sur le sous-système d'E / S, il peut donc sembler que la charge de travail est bloquée, mais ce n'est pas vraiment le cas. C'est juste en train de ralentir. Il y a un cas spécial où une sauvegarde qui doit récupérer des extensions enregistrées en masse prendra un verrou de fichier qui pourrait bloquer une opération de point de contrôle - mais DML n'est jamais bloqué.

J'ai également entendu dire que la sauvegarde est monothread, ce qui signifie qu'elle n'utilise qu'un seul noyau, en supposant que vous sauvegardez dans un seul fichier.

Une sauvegarde effectuée sur un seul fichier ou périphérique utilisera 1 thread d'écriture. Donc, si vous sauvegardez sur plusieurs fichiers / périphériques (que ce soit plusieurs fichiers .bak), il y aura un thread d'écriture par fichier / périphérique.

Le moyen le plus simple d'améliorer les performances de sauvegarde est de permettre la parallélisation de l'opération de sauvegarde, connue sous le nom de segmentation de sauvegarde. Par défaut, il existe un seul thread de lecteur de données pour chaque lettre de lecteur ou point de montage lu et un seul thread d'écrivain de données pour chaque périphérique de sauvegarde sur lequel écrire.

Vérifier

1. Vidéos de préparation SQL Server 2008 Microsoft Certified Master (MCM), en particulier les sauvegardes internes.
2. Un regard sur les internes de sauvegarde et comment suivre le débit de sauvegarde et de restauration (Partie 1) - Par: Jonathan Kehayias
3. Un regard sur les internes de sauvegarde et comment suivre le débit de sauvegarde et de restauration (Partie 2) - Par: Jonathan Kehayias

L'article écrit par Paul concernant les sauvegardes internes est excellent et vous devez le lire. Ajouter à ce que les autres ont dit et mettre l'accent sur une partie spécifique de votre question

J'ai également entendu dire que la sauvegarde est monothread, ce qui signifie qu'elle n'utilise qu'un seul noyau, en supposant que vous sauvegardez dans un seul fichier. En supposant également que vous avez une machine multicœur, par exemple 16 cœurs, ou au moins un nombre supérieur à un.

L'opération de sauvegarde, can use parallelismmais rappelez-vous que ce n'est pas le parallélisme généré par Optimizer dans SQL Server, il est déterminé par le nombre de disques impliqués d'où la sauvegarde doit lire le fichier de données et où la sauvegarde écrit le fichier de données et la quantité de fichiers de sauvegarde créés.

Vous ne pouvez pas utiliser d' MAXDOPindication lors de la sauvegarde de SQL Server

Vous ne pouvez pas générer de plan d'exécution dans SSMS pour une opération de sauvegarde TSQL simple.

Le parallélisme piloté par l'optimiseur de requêtes dans SQL Server est essentiellement destiné aux opérateurs impliqués (en fait, c'est plus complexe mais pour des raisons de simplicité, vous pouvez le prendre) car l'opération de sauvegarde n'implique aucun opérateur en tant que tel, elle ne peut pas utiliser le parallélisme piloté par l'optimiseur.

J'ai écrit un article sur Technet Wiki sur la sauvegarde et le parallélisme où j'ai utilisé des exemples simples pour expliquer le parallélisme lors de la sauvegarde SQL Server. Voici la conclusion

1. Si les fichiers de base de données se trouvent sur plusieurs disques, une opération de sauvegarde se lance sur le thread par lecteur de périphérique pour lire les données. De la même manière, si la restauration est effectuée sur plusieurs lecteurs / points de montage, une opération de sauvegarde initierait un thread par lecteur / point de montage

2. Même si vous transférez plusieurs copies de sauvegarde sur le même lecteur, nous aurons un thread par fichier de sauvegarde vidé.

3. Le parallélisme associé à la sauvegarde est lié aux rayures. Chaque bande obtient son propre thread de travail et c'est vraiment la seule partie de la sauvegarde / restauration que l'on devrait considérer comme des opérations parallèles.

4. Le degré maximum de parallélisme n'a aucun effet sur l'opération de sauvegarde.

J'ai eu un avis d'expert à ce sujet de Paul et Bob Dorr.

Que se passe-t-il donc lorsqu'un travail de sauvegarde est en cours d'exécution? Et y a-t-il également des différences significatives pour les différentes versions? par exemple 2008,2012 et 2014 (pas les licences).

Je vous suggère de lire cet article blog.msdn de Bob Dorr. Il a souligné certains points importants:

1. Lorsqu'une sauvegarde démarre, elle crée une série de tampons, alloués à partir de la mémoire en dehors du pool de tampons. La cible est généralement de 4 Mo pour chaque tampon, ce qui donne environ 4 à 8 tampons. Les détails sur le calcul se trouvent dans: http://support.microsoft.com/kb/904804/en-us

2. Les tampons sont transférés entre les files d'attente libres et de données. Le lecteur extrait un tampon libre, le remplit de données et le place dans la file d'attente de données. Le ou les rédacteurs extraient les tampons de données remplis de la file d'attente de données, traitent le tampon et le renvoient à la liste libre.

3. Vous obtenez un écrivain par périphérique de sauvegarde, chacun récupérant de la file d'attente de données. Ainsi, une commande de sauvegarde avec quatre (4) spécifications de disque aura quatre enregistreurs et un lecteur. Le lecteur utilise les E / S asynchrones pour suivre les rédacteurs.

Vous pouvez activer trace flags 3213 and 3605, les deux ne sont pas documentés, veuillez donc les utiliser dans un environnement de test et voir quel message intéressant est vidé dans le journal des erreurs de SQL Server. Quelque chose comme ci-dessous apparaîtrait

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

Je ne suis pas au courant de changements importants dans le code de sauvegarde pour différentes versions, de telles choses ne sont pas documentées. Je ne connais que l'amélioration introduite dans l' SQL Server 2012 SP1 Cumulative Update 2,activation de la sauvegarde et de la restauration à partir du service de stockage Windows Azure Blob à partir de SQL Server à l'aide de TSQL ou SMO. Lisez ici

Fondamentalement, SQL Server effectue une copie incorrecte de toutes les pages du disque. Ces pages sont probablement incohérentes s'il y a une activité simultanée ou s'il y a déjà eu une activité sans point de contrôle.

Ensuite, SQL Server copie également la partie nécessaire du journal des transactions qui est nécessaire pour mettre les pages obsolètes à la dernière version et rendre tout cohérent lors de la restauration.

Je ne peux pas parler du multithread de l'opération de sauvegarde. Je m'attends à ce qu'il soit parallélisé. Sinon, comment pourriez-vous sauvegarder une base de données de 10 To sur un sous-système d'E / S de 10 Go / s?