Sauvegardes des journaux de transactions en série ou en parallèle?

Il se trouve que nous utilisons SQL Server 2012 Standard Edition. Il se trouve que j'utilise également les scripts d'Ola Hallengren pour fournir un cadre simple et plus flexible pour les sauvegardes et la maintenance.

Cette question ne concerne pas tant les scripts d'Ola que les meilleures pratiques. Je réalise que la réponse ultime est "cela dépend des exigences de votre entreprise". Mais j'essaie de demander l'avis de la communauté sur la meilleure façon de répondre à ce que je comprends des exigences de notre entreprise.

Je souhaite configurer des sauvegardes du journal des transactions toutes les 15 minutes. De cette façon, nous espérons ne pas perdre plus de 15 minutes de données. Dois-je configurer un travail qui utilise ALL_DATABASES? ou est-il préférable de configurer un travail pour chaque base de données et de les lancer tous en parallèle? Je demande, parce que j'ai l'impression, d'après la façon dont je vois le script d'Ola, que les sauvegardes sont lancées en série. L'inconvénient de la série serait que chaque sauvegarde successive attend la fin de l'autre. Cela pourrait potentiellement augmenter la durée entre les sauvegardes (c.-à-d. Supérieure à 15 minutes). De plus, mon inquiétude serait qu'un échec dans une sauvegarde empêche les autres de se produire, et je ne voudrais pas que ce soit le cas. Je voudrais que les autres continuent de sauvegarder.

Est-il vrai que les scripts d'Ola s'exécutent en série et qu'un échec arrête les sauvegardes successives?

Et est-il préférable d'avoir un travail pour chaque base de données? ou un seul travail qui fait tout? Mon inclination est vers des emplois séparés, mais je souhaite comprendre ce que les DBA SQL Server en général ont tendance à faire.

Dois-je configurer un travail qui utilise ALL_DATABASES? ou est-il préférable de configurer un travail pour chaque base de données et de les lancer tous en parallèle?

Je suggérerais de configurer un travail qui sauvegarderait les journaux de transactions (en série). Cela garantirait également que la sauvegarde n'utilise pas fortement les E / S car vous exécutez la sauvegarde de la base de données une par une.

Quels pourraient être les inconvénients possibles avec un fonctionnement en parallèle

1. Supposons que vous ayez 50 bases de données et que vous planifiez une sauvegarde du journal des transactions de toutes les bases de données et qu'elles commencent toutes à fonctionner en parallèle, cela va certainement utiliser beaucoup d'E / S. Et si le disque sur lequel il sauvegarde des fichiers contient d'autres fichiers de données, vous constaterez une lenteur. J'ai vu la sauvegarde devenir lente lorsqu'une requête médiocre demandant beaucoup d'E / S s'exécute avec le travail de sauvegarde.

2. Supposons à nouveau que vous ayez 50 bases de données, il ne serait pas difficile de gérer 50 tâches dans l'agent SQL Server et quelle serait la condition si vous avez 100 à 200 bases de données, je ne voudrais tout simplement pas que vous ouvriez l'agent SQL Server et voyiez beaucoup de tâches, restez simple. Je suis sûr que le même cas serait avec vous.

L'inconvénient de la série serait que chaque sauvegarde successive attend la fin de l'autre. Cela pourrait potentiellement augmenter la durée entre les sauvegardes (c.-à-d. Supérieure à 15 minutes).

Les sauvegardes du journal des transactions sont généralement de petite taille et si vous avez une base de données occupée produisant beaucoup d'enregistrements de journal, vous devrez peut-être modifier la fréquence de sauvegarde. La plupart du temps, j'ai vu la sauvegarde du journal des transactions se terminer correctement lorsque la fréquence est de 15 minutes. Je ne pense pas que cela devrait vous préoccuper.

De plus, je crains qu'un échec dans une sauvegarde empêche les autres de se produire, et je ne voudrais pas que ce soit le cas

Je dirais juste ne t'en fais pas. Les sauvegardes du journal des transactions ne peuvent tout simplement pas échouer, sauf si vous avez fait une erreur. Les erreurs peuvent être

1. Le propriétaire exécutant le travail est supprimé d'AD.

2. Quelqu'un a changé le modèle de récupération de la base de données.

3. Espace disque insuffisant

En dehors de ce qui précède, je n'ai vu aucune raison d'échec de la sauvegarde du journal des transactions. Son très robuste, vous pouvez vous y fier.

En général, exécutez toujours vos sauvegardes T-log en série; plusieurs de mes instances ont une douzaine de bases de données, et plusieurs sont très actives, et les sauvegardes du journal des transactions ne prennent que quelques secondes au total; jusqu'à une demi-minute environ quand il est particulièrement occupé.

Exécuter des sauvegardes en parallèle uniquement serait vraiment bénéfique si toutes les conditions suivantes sont remplies:

• Vos bases de données et fichiers journaux sont tous sur des broches indépendantes uniques (ou sur des disques SSD dans n'importe quelle combinaison)

  • Pour les sauvegardes T-log uniquement, seuls les fichiers journaux devraient répondre à cette exigence.

• Vos cibles de sauvegarde pour chaque base de données se trouvent sur des broches distinctes.

• Vous n'utilisez pas HBA SAN partagé ou iSCSI ou toute autre bande passante entre l'instance SQL Server et le support.

• c'est-à-dire que les IOPS de lecture de la base de données A et d'écriture de la sauvegarde A NE PAS utiliser les mêmes disques que la lecture de la base de données B et l'écriture de la sauvegarde B.

Si tout cela est vrai, il est possible qu'un certain degré de parallélisme diminue la durée totale du calendrier. Si toutes ces informations ne sont pas vraies, il est plus que probable que vous provoquerez le blocage d'un ou de plusieurs ensembles de disques, et vos sauvegardes parallèles prendront en fait plus de temps calendaire que série, mais peuvent également provoquer une fragmentation du système de fichiers du système d'exploitation ou du niveau de stockage, car vous écrivez la sauvegarde A et la sauvegarde B en même temps!

Ne vous inquiétez pas de l'échec d'une sauvegarde et de la réussite du reste - en cas d'échec, vous devez tout vérifier de toute façon, et les seules fois où j'ai vu des sauvegardes échouer sont dues à:

• Échec du disque

• Échec du logiciel de compression Hyperbac / Litespeed / tiers (si vous avez un logiciel entre SQL et le disque qui échoue)

  • À titre d'avertissement, l'échec peut prendre la forme d'un travail de sauvegarde qui ne se termine jamais, il est donc utile de vérifier les «travaux qui s'exécutent plus longtemps que prévu» qui envoient des alertes.

• Échec du produit de chiffrement (si vous avez un logiciel entre SQL et le disque qui échoue)

• Échec du réseau (si les fichiers de base de données, ou plus probablement les fichiers de sauvegarde, sont sur le réseau)

• Autorisations

  • le plus courant avec les nouvelles installations

  • ou de nouveaux emplacements de sauvegarde

  • changer l'utilisateur du service SQL Server (qui a besoin des autorisations pour les sauvegardes normales)

  • verrouillage de l'utilisateur du service SQL Server car il est utilisé par plusieurs instances SQL Server

• Erreurs de configuration

• Panne électrique

• Plantage du système d'exploitation

La plupart d'entre eux n'affecteront pas l'un et pas les autres, sauf si les conditions ci-dessus sont également remplies.

Juste pour ajouter, Ola conçoit ses scripts où si une sauvegarde de base de données ne parvient pas à sauvegarder pour une raison quelconque, les prochaines sont tentées. Comme indiqué précédemment, vous pouvez configurer une alerte pour vous informer de l'échec du travail car le travail de sauvegarde échouera toujours, même si une seule sauvegarde de base de données a échoué sur toutes les bases de données utilisateur - en supposant que vous sauvegardez toutes les bases de données (un travail pour tous).