Les plans de maintenance dans SQL Server nous offrent un moyen simple d'organiser, de configurer et de planifier des tâches qui garantissent que le moteur de base de données et les bases de données qui y sont hébergées sont maintenus en forme.
Les plans de maintenance offrent à un administrateur de base de données la possibilité de configurer des tâches clés telles que l'indexation, les mises à jour de statistiques, les sauvegardes, les nettoyages de journaux, etc. Dans l'article précédent, nous avons déjà expliqué comment créer un plan de maintenance de base pour effectuer une vérification de la cohérence de la base de données. Dans cet article, nous allons faire une présentation de la création d'un plan de maintenance pour une instance de base de données qui héberge de petites bases de données. Au cours de la procédure pas à pas, j'expliquerai les choix clés effectués à chaque étape dans le contexte d'une instance avec un nombre modérément élevé de petites bases de données. L'idée est de configurer la maintenance de ces bases de données sans avoir à le faire une par une. L'accent mis sur les petites bases de données vise à éviter la surcharge de performances associée aux opérations de maintenance.
Plan de maintenance pour les tâches hebdomadaires
Figure 1 :Lancer l'assistant de plan de maintenance
Nous lançons l'assistant de plan de maintenance à partir de l'Explorateur d'objets> [Nom de l'instance]> Gestion> Plans de maintenance (voir la figure 1). La première page de l'assistant nous donne un aperçu des tâches qui peuvent être configurées. Bien qu'il existe d'autres moyens d'accomplir ces tâches à l'aide du code et de la planification des tâches, l'assistant de plan de maintenance facilite l'exécution lorsqu'il s'agit d'un grand nombre de bases de données hébergées sur une seule instance.
Figure 2 :Assistant de plan de maintenance
Dans la figure 3, nous voyons SQL Server nous exposer des champs pour nommer et décrire le plan de maintenance. La saisie d'une description du plan est logique à des fins de documentation. Imaginez prendre en charge une nouvelle instance SQL Server dans une nouvelle entreprise. Il serait utile que vous trouviez des descriptions d'objets SQL Server dans les objets. Vous devriez faire la même chose pour les autres. Veuillez noter que la description que j'ai donnée vise simplement à illustrer ce point. Une description plus détaillée sera souhaitable dans un environnement de production.
Figure 3 :Nommer le plan de maintenance
Notez que dans la figure 3, nous avons la possibilité de choisir si nous voulons utiliser une seule planification pour toutes les tâches ou une planification distincte pour chaque tâche. J'ai choisi d'utiliser des horaires séparés pour avoir la flexibilité d'échelonner les tâches. Nous ne voudrions pas que trop d'opérations de maintenance s'exécutent simultanément ou dos à dos sur une longue période pour éviter le risque de surcharger les ressources du serveur. La décision que vous prendrez à ce stade peut également dépendre de la capacité des ressources dont vous disposez et de la fenêtre de maintenance disponible. Certaines personnes ont une capacité suffisante et voudraient terminer la tâche rapidement à chaque course. Dans le scénario couvert par cet article, nous supposons que l'instance en question n'est pas utilisée pendant le week-end.
Dans la figure 4, nous choisissons les tâches que nous voulons exécuter. L'un des avantages de SQL Server est que chaque tâche est décrite au bas de la fenêtre. Lorsque vous travaillez en tant que DBA, il est avantageux de comprendre ce que vous faites même lorsque vous travaillez sur "Windows". D'après mon expérience, de nombreux "administrateurs" ont l'habitude de simplement cliquer sur "SUIVANT, SUIVANT, SUIVANT" car ils sont pressés de faire fonctionner la fonctionnalité. Mais prendre le temps de comprendre l'impact du prochain "NEXT" permet de s'assurer que vous faites quelque chose qui ajoutera de la valeur et ne causera pas de nouveaux problèmes.
Figure 4 :Sélection des tâches de maintenance
Les tâches que nous avons sélectionnées sont décrites comme suit :
L'outil Vérifier l'intégrité de la base de données La tâche effectue des vérifications de cohérence interne des données et des pages d'index dans la base de données.
L'index de réorganisation la tâche défragmente et compacte les index clusterisés et non clusterisés sur les tables et les vues. Cela améliorera les performances d'analyse de l'index.
L'indice de reconstruction La tâche réorganise les données sur les pages de données et d'index en reconstruisant les index. Cela améliore les performances des analyses et des recherches d'index. Cette tâche optimise également la distribution des données et de l'espace libre sur les pages d'index, permettant une croissance future plus rapide.
Les statistiques de mise à jour garantit que l'optimiseur de requête dispose d'informations à jour sur la distribution des valeurs de données dans les tables. Cela permet à l'optimiseur de mieux juger les stratégies d'accès aux données.
Le nettoyage de l'historique La tâche supprime les données historiques sur les opérations de sauvegarde et de restauration, de l'Agent SQL Server et du plan de maintenance. Cet assistant vous permet de spécifier le type et l'ancienneté des données à supprimer.
La base de données de sauvegarde (complète) La tâche vous permet de spécifier les bases de données source, les fichiers ou les bandes de destination et d'écraser les options pour une sauvegarde complète.
Le nettoyage de maintenance tâche supprime les fichiers restants de l'exécution d'un plan de maintenance.
La figure 5 montre où nous sélectionnons l'ordre dans lequel ces tâches sont exécutées. Ceci est important pour plusieurs raisons. Par exemple, il n'est pas logique d'effectuer une mise à jour des statistiques d'index après une reconstruction d'index puisqu'une reconstruction d'index effectue également une mise à jour des statistiques d'index dans SQL Server. Nous verrons plus loin dans l'article comment nous gérons cela compte tenu de l'ordre que nous avons choisi. Une autre considération possible est que vous pouvez décider qu'il est plus logique d'effectuer une sauvegarde avant de procéder à certains types de maintenance.
Figure 5 :Ordre des tâches
Dans la figure 6, nous choisissons les bases de données auxquelles nous voulons appliquer la première tâche de maintenance. Nous devons également le faire pour chacune des tâches suivantes. Ceci est important dans le sens où certaines bases de données peuvent devoir être exemptées de telles opérations. Par exemple, lorsque vous avez un mélange de très grandes bases de données (VLDB) et de très petites bases de données dans la même instance (une mauvaise idée en soi), vous devrez peut-être exclure les VLDB des reconstructions d'index aveugles. Dans ce cas, vous devez identifier les tables de clés dans cette VLDB et concentrer les reconstructions et autres opérations de maintenance intensive sur les tables de clés. Dans cet exemple, j'ai exclu les bases de données système car je peux soigneusement planifier leurs maintenances séparément. Je pense qu'il est plus sûr de gérer les bases de données système séparément, étant donné que tout dommage à celles-ci pourrait avoir un impact sur l'ensemble de l'instance.
Figure 6 :Déterminer la portée
Chaque opération de maintenance a son propre ensemble d'options. La figure 7 montre les options que nous devons choisir pour DBCC CHECKDB. J'ai légèrement dévié des paramètres par défaut en augmentant le MAXDOP à 2. Dans la figure 8, nous choisissons d'exécuter cette tâche à 1h00 le samedi et le dimanche soir.
Figure 7 :Options DBCC
Figure 8 :Calendrier DBCC
La tâche Réorganiser l'index comporte également un ensemble spécifique d'options. Il convient de mentionner l'ensemble des conditions qui détermineront si un index doit être réorganisé ou non - 30% de fragmentation, plus de 1000 pages et une dernière utilisation au plus 28 jours à nouveau. Cette fenêtre souligne la nécessité de comprendre les options que nous faisons. Afin de rendre ces options correctes, vous devez comprendre les index et l'indexation dans une mesure raisonnable. Notez que des choix similaires devront être effectués dans la tâche Reconstruire l'index. Notez également que le seuil de fragmentation recommandé pour la réorganisation de l'index est en réalité de 15 % et non de 30 %.
Figure 9 :Réorganiser les options d'index
La tâche de reconstruction de l'index offre quelques autres options que celles de la réorganisation de l'index. (Voir figure 10). Notez que j'ai choisi de trier les résultats dans TempDB. Pour que ce choix soit efficace, il est important d'ajuster TempDB de manière appropriée car le choix implique que le tri pour cette opération dans TOUTES les bases de données se produira dans TempDB. De plus, nous devons configurer le calendrier de reconstruction de l'index. J'ai également défini MAXDOP sur 2 pour cette tâche.
Figure 10 :Options de reconstruction de l'index
Nous avons mentionné précédemment que lorsqu'une reconstruction d'index est appelée dans SQL Server, la mise à jour des statistiques sur les index est également appelée par défaut. Ainsi, lorsque nous configurons la tâche de mise à jour des statistiques, nous choisissons de mettre à jour uniquement les statistiques de colonne (Figure 11). Cette fenêtre nous donne également la possibilité de faire une analyse complète ou un échantillonnage. Puisque le contexte est de petites bases de données, nous choisissons l'option d'analyse complète. Encore une fois, cela nécessite une certaine compréhension des statistiques.
Figure 11 :Tâche de mise à jour des statistiques
Nous choisissons de configurer la tâche de nettoyage pour supprimer toutes les données de plus de 4 semaines, comme illustré à la figure 12.
Figure 12 :Tâche de nettoyage de l'historique
La tâche de sauvegarde expose un certain nombre d'options de configuration dans trois onglets ! La figure 13 montre que nous choisissons de limiter cette tâche de sauvegarde aux bases de données utilisateur. Nous le programmons pour 3h00 le dimanche, et nous allons plus loin pour choisir la destination de sauvegarde comme E:\MSSQL\Backup (voir Figure 14). Dans le troisième onglet (Figure 15), nous faisons des choix pour vérifier la sauvegarde et également effectuer une somme de contrôle, nous sommes donc plus près d'être sûrs que la sauvegarde est fiable.
Figure 13 :Tâche de sauvegarde de la base de données
Figure 14 :Destination de la sauvegarde
Figure 15 :Options de sauvegarde
Enfin, nous configurons une tâche qui gérera la conservation de notre journal de plan de maintenance. (Figure 16). Encore une fois, nous choisissons de supprimer tous les enregistrements de journal de plus de 4 semaines. La figure 17 montre les options que nous sélectionnons pour nous assurer que les activités du plan de maintenance sont consignées et envoyées par courrier au groupe d'administration de la base de données. Bien sûr, pour que cette dernière option fonctionne, nous devons avoir correctement configuré Database Mail et paramétré les opérateurs.
Figure 16 :Tâche de nettoyage du plan de maintenance
Figure 17 :Options de rapport
Les figures 18 et 19 montrent un résumé des tâches que nous avons configurées et des commentaires sur la réussite de l'assistant.
Figure 18 :Récapitulatif des options
Figure 19 :fin de l'assistant
Plan de maintenance pour les tâches quotidiennes
Nous pouvons également mettre en place des plans de maintenance distincts à d'autres fins, comme simplement être organisé. Nous n'avons pas besoin de configurer un plan séparé pour les tâches quotidiennes puisque nous pouvons configurer les horaires séparément pour chaque tâche. L'une des raisons pour lesquelles nous souhaitons mettre en place un plan distinct pourrait être de sélectionner un ensemble différent de tâches ciblées sur un ensemble différent de bases de données (en fait, nous pouvons toujours être en mesure de le faire dans le plan existant également).
Dans l'exemple suivant, supposons que nous ayons un autre ensemble de bases de données volumineuses dans la même instance ayant différents objectifs de point de récupération. Nous devons ensuite utiliser une stratégie de sauvegarde différente - une planification de sauvegarde différentielle quotidienne et une planification horaire de sauvegarde du journal des transactions en plus d'une sauvegarde complète hebdomadaire afin d'assurer un RPO de 1 heure. (Voir Figures 21 et 22).
Figure 20 :Plan de maintenance des tâches quotidiennes
Figure 21 :Tâches de sauvegarde différentielle et Tlog
Figure 22 :Ordre des tâches du plan de maintenance quotidienne
Pour la sauvegarde différentielle, nous choisissons un programme quotidien qui est déclenché à 2h00 du matin tous les jours. (Voir Figure 23). Et choisissez les mêmes options de sauvegarde que pour la sauvegarde hebdomadaire complète configurée précédemment.
Figure 23 :Calendrier du plan de maintenance quotidien
Figure 24 :Emplacement de sauvegarde différentielle
Figure 25 :Options de sauvegarde différentielle
D'autre part, nous choisissons de programmer la sauvegarde différentielle pour qu'elle se produise toutes les heures de chaque jour. Nous nous assurons également que chaque jeu de sauvegarde de base de données est stocké dans un répertoire ayant son propre nom. Le reste de l'assistant est sensiblement le même que la procédure pas à pas précédente.
Figure 26 :Calendrier de sauvegarde du journal des transactions
Figure 27 :Emplacement de sauvegarde du journal des transactions
Figure 28 :Options de sauvegarde du journal des transactions
Conclusion
À la fin de l'assistant de plan de maintenance, nous nous retrouvons avec un plan de maintenance et un ensemble correspondant de tâches d'agent SQL (voir la figure 29). Essentiellement, le plan de maintenance est un ensemble de packages SSIS, et lorsque vous examinez les travaux planifiés, vous constaterez que l'étape de travail exécutée dans chaque travail de sous-plan est un package SSIS (voir la figure 30).
Dans un exemple ultérieur, nous montrerons que nous pouvons exécuter les tâches du sous-plan annuellement. Nous examinerons également les résultats de l'exécution du plan de maintenance et résoudrons les erreurs liées à l'exécution des étapes de travail. Nous examinerons également le journal du plan de maintenance.
Figure 29 :Tâches de l'agent SQL résultantes
Figure 30 :Étape de la tâche du package SSIS
