Maintenance planifiée de la base de données IS 24h/24 et 7j/7 dans MS SQL Server

Présentation

Cet article est une brève revue des principales maintenances planifiées avec une base de données du système d'information 24h/24 et 7j/7 qui n'a pas de temps d'arrêt, ainsi que des approches de leur exécution dans MS SQL Server.

Tous les commentaires et mises à jour de l'article sont très appréciés.

Maintenance planifiée

Il y a la maintenance planifiée suivante que je voudrais signaler :

Sauvegardes planifiées avec vérification supplémentaire sans restauration
Restauration planifiée des sauvegardes pour vérifier leurs performances
Analyse du dispositif de stockage de données contenant le système et toutes les bases de données nécessaires
Tests planifiés des services requis
Optimisation planifiée des performances d'un système
Maintenance planifiée de l'intégrité des données
Maintenance planifiée de la validation des données

Les trois premiers points sont les plus importants, car ils permettent de restaurer le système après diverses pannes. Cependant, je recommanderais également d'exécuter les trois points au moins, afin que les utilisateurs puissent travailler à l'aise (ainsi, toutes les requêtes doivent être exécutées rapidement) et pour que les données soient validées dans tous les systèmes de reporting.

Pour automatiser la maintenance planifiée, il est possible d'organiser ses parties dans l'Agent ou le Planificateur Windows.

Le sixième point est basé sur la commande CHECKDB.

Le septième point est implémenté vers le domaine utilisé dans le système d'information.

Je vais parler en détail des cinq premiers points.

Sauvegardes planifiées avec vérification supplémentaire sans restauration

Comme il existe de nombreux articles sur ce sujet, il convient de noter qu'il est nécessaire d'exécuter régulièrement cette maintenance planifiée sur un serveur de secours, plutôt que sur le serveur principal. Ce serveur de sauvegarde doit contenir des données à jour (par exemple, celle qui a été obtenue avec la réplication). De plus, vous devez sauvegarder toutes les bases de données système (à l'exception de tempdb) sur chaque instance de MS SQL Server.

Lorsque la sauvegarde échoue ou qu'une analyse de sauvegarde identifie un problème, il est nécessaire de signaler cette information aux administrateurs. Par exemple, vous pouvez leur envoyer un e-mail.

Il est important de déterminer une stratégie de sauvegarde, qui répondra aux questions suivantes :

À quelle fréquence et quand devons-nous sauvegarder les données (complète, différentielle et journal des transactions) ?
Combien de temps et quand devons-nous supprimer les sauvegardes ?

Restauration planifiée des sauvegardes pour vérifier leurs performances

Je recommande d'exécuter cette procédure sur un serveur de sauvegarde avec des utilitaires tiers ou le RESTORE commande.

Lorsque la restauration de la sauvegarde échoue, il est nécessaire de signaler ces informations aux administrateurs. Par exemple, vous pouvez leur envoyer un e-mail.

De plus, il est nécessaire de restaurer les sauvegardes des bases de données système. Pour ce faire, vous devez les restaurer en tant que base de données utilisateur habituelle avec un nom différent des noms des bases de données système.

Analyse des périphériques de stockage de données contenant le système et toutes les bases de données nécessaires

Vous devez analyser l'espace occupé par chaque base de données, l'évolution de la taille des fichiers et l'évolution de la taille de l'espace libre sur l'ensemble du périphérique de stockage. Par exemple, vous pouvez effectuer cette tâche partiellement avec la collecte automatique de données sur les fichiers de bases de données et les lecteurs logiques du système d'exploitation dans MS SQL Server.

Vous pouvez effectuer cette vérification tous les jours, puis envoyer les résultats. Comme d'habitude, vous pouvez les envoyer par e-mail.

Il est également nécessaire de surveiller les bases de données du système afin de vous assurer que tout fonctionne correctement.

De plus, il est important de tester les périphériques de stockage pour vérifier s'il y a une dépréciation ou des secteurs défectueux.

Notez que pendant le test, un appareil doit être hors service et toutes les données doivent être copiées sur un autre appareil car le test charge considérablement l'appareil.

Cette tâche est strictement liée aux tâches de l'administrateur système, nous la gardons donc de côté. Pour prendre le contrôle total du cas, vous devez automatiser la livraison du rapport par e-mail.

Je recommanderais d'exécuter ce test deux fois par an.

Tests planifiés des services requis

Les interruptions de service sont une mauvaise pratique. Par conséquent, un serveur de sauvegarde entrera en action en cas de panne. Néanmoins, il est nécessaire de vérifier les journaux de temps en temps. De plus, vous pouvez également penser à une collecte automatique de données avec une notification supplémentaire à un administrateur en envoyant un e-mail.

Il est nécessaire de vérifier les tâches de l'agent SQL Server ou du planificateur Windows avec une collecte automatique de données sur les tâches terminées dans MS SQL Server.

Optimisation planifiée des performances d'un système

Il comprend les aspects suivants :

Automatisation de la défragmentation des index dans les bases de données MS SQL Server
Automatisation de la collecte de données sur les modifications des schémas de base de données dans MS SQL Server. Vous pouvez restaurer une sauvegarde et comparer les modifications, par exemple à l'aide de dbForge
Automatisation du nettoyage des processus bloqués dans MS SQL Server
Nettoyage du cache de procédure. Ici, vous devez déterminer quand et quoi nettoyer
Mise en place d'un indicateur de performance
Développer et modifier des index clusterisés

De plus, je recommande de désactiver la AUTO_CLOSE fonctionnalité.

Parfois, pour différentes raisons, un optimiseur parallélise une requête, ce qui n'est pas toujours optimal.

Ainsi, il y a quelques recommandations que vous devriez garder à l'esprit :

Si vous obtenez beaucoup de données, laissez le parallélisme.
Si vous obtenez quelques données, n'utilisez pas le parallélisme.

Deux paramètres dans les paramètres de l'instance SQL Server sont responsables du parallélisme :

degré maximal de parallélisme. Pour désactiver le parallélisme, définissez "1" comme valeur, ce qui signifie qu'un seul processeur exécutera un code.
seuil de coût pour le parallélisme. Il doit être défini par défaut.

Il existe deux files d'attente principales :

une file d'attente pour le temps CPU (queue QCPU). Il a lieu lorsqu'une requête a été activée et attend qu'un processeur l'exécute.
une file d'attente pour les ressources (file d'attente QR). Il a lieu lorsqu'une requête attend que les ressources soient dissociées pour exécuter le processus.

La formule suivante décrit l'exécution de la requête (T) :

T=TP+TQR+TCPU+TQCPU, où :

TP compile le temps pour un plan
TQR est le temps d'attente pour les ressources (file d'attente QR)
TQCPU est le temps d'attente pour que les ressources soient dissociées (file d'attente QCPU)
TCPU est le temps d'exécuter une requête

Dans la vue système sys.dm_exec_query_stats :

total_worket_time =TP+TCPU+TQCPU
total_elapsed_time =TQR+TCPU

Les outils intégrés ne permettent pas d'évaluer précisément le temps d'exécution des requêtes.

Dans la plupart des cas, total_elapsed_time vous fournit l'heure proche de l'heure d'exécution de la requête.

Vous pouvez déterminer le temps d'exécution de la requête avec plus de précision à l'aide de trace. Vous pouvez également enregistrer l'heure de début et de fin de la requête. Soyez prudent avec les traces car elles chargent considérablement le système. Ainsi, il est préférable de l'exécuter sur un serveur de sauvegarde et de récupérer les données du serveur principal. Dans ce cas, seul le réseau sera chargé.

Lors de la parallélisation, SQL Server alloue N processus à une requête (dans l'édition Standart n<=4). Chaque processus nécessite du temps CPU pour exécuter une requête (un processus ne doit pas toujours être exécuté sur chaque cœur).

Plus vous avez de processus, plus il y a de chances que certains soient remplacés par d'autres, ce qui entraînera une augmentation du TQCPU.

L'exécution d'une requête en parallélisation peut prendre beaucoup plus de temps, dans les cas suivants :

Débit de sous-système de disque faible. Dans ce cas, la décomposition de la requête prend beaucoup plus de temps.
Les données peuvent être bloquées pour le processus.
Il n'y a pas d'index pour le prédicat, ce qui conduit à une analyse de table.
Remarques :
Vous devez désactiver la mise en parallèle des requêtes sur les serveurs où il n'est pas nécessaire d'effectuer une sélection énorme (total_worket_time doit être réduit en raison d'une diminution possible de TCPU et TQCPU). Pour ce faire, vous devez définir le degré maximal de fonctionnalité de parallélisme sur "1" pour qu'un seul processeur fonctionne.
De plus, vous pouvez utiliser d'autres frameworks pour créer un système qui détermine les performances à haute vitesse des bases de données . Il est important de comprendre comment ces cadres fonctionnent et comment interpréter les chiffres récupérés.

En ce qui concerne le développement et la modification des index, à savoir les index clusterisés, l'essentiel est de comprendre comment la logique des index est définie et comment elle fonctionne.

Gardez à l'esprit que les clés primaires et en cluster ne signifient pas la même chose :

Une clé primaire est une colonne ou un ensemble de colonnes, qui rendent un enregistrement unique dans la table. Pour la clé primaire, vous pouvez soit créer un index clusterisé ou non clusterisé unique. La clé primaire est utilisée dans d'autres tables comme clé étrangère pour assurer l'intégrité des données.

Un index cluster est un arbre B ou sa modification. Les feuilles contiennent les données elles-mêmes tandis que les nœuds contiennent des informations d'index. De plus, un index clusterisé peut également être non unique. Pourtant, je le recommande pour être unique.

Je voudrais rappeler qu'un B-tree est une structure qui stocke les données dans l'ordre filtré par un index clusterisé. Ainsi, il est important de regrouper les champs sélectionnés en tant qu'index groupé dans un ordre décroissant ou croissant. Pour un index clusterisé, vous pouvez utiliser des colonnes d'entier (identité), ainsi que des données et de l'heure. Néanmoins, les colonnes telles que l'identifiant unique ne conviennent pas car ces dernières entraîneront une restructuration régulière d'un arbre B, ce qui augmentera le nombre de lectures et d'enregistrements sur un périphérique de stockage où se trouve la base de données.

De plus, vous devez vous assurer que l'index est utilisé avec la vue système sys.dm_db_index_usage_stats.

PS Il est nécessaire de vérifier si les données sont à jour sur un serveur de sauvegarde, ainsi que de vérifier un système qui synchronise ces données (par exemple, les réplications).

Maintenance planifiée de la base de données IS 24h/24 et 7j/7 dans MS SQL Server

Présentation