Maintenance de la base de données SQL

Ces informations sont fournies à titre indicatif uniquement. Il est recommandé de suivre les meilleures pratiques standard de l'industrie et de rechercher les recommandations d'un administrateur de base de données expérimenté. Ces informations doivent être utilisées en tenant compte de l'impact plus large sur l'environnement global.

Les bases de données suivantes doivent être gérées :

  • InteractDB

  • InteractCacheDB

  • IadaDB

  • AuthenticationServerDB

  • HubDB

  • AuditDB

  • NotificationCenterDB

  • LicenceManagerDB

  • FileServiceDB

  • EmailServiceDB

  • BluePrismDecisionDB

  • ImsDB

  • FileServiceDB

    • CacheDB a été remplacé par FileServiceDB à partir de Hub 4.4.

Recommandations générales pour la maintenance de la base de données

Il est recommandé de faire ce qui suit :

  • Définir la croissance automatique correctement pour toutes les bases de données. Les valeurs recommandées sont 1 024 Mo pour le fichier de données et 2 048 Mo pour le log des transactions.
  • Ré-établir la valeur pour la croissance automatique à mesure que la taille de la base de données augmente pour minimiser la fréquence des événements de croissance automatique.

    • Ne pas utiliser une croissance de fichier à pourcentage, augmenter plutôt d'une quantité fixe de mégaoctets.

  • Supprimer toute fragmentation excessive du fichier log des transactions. Pour plus d'informations, consultez l'aide en ligne de Microsoft.
  • Activer l'initialisation instantanée du fichier. Pour plus d'informations, consultez l'aide en ligne de Microsoft.
  • Désactiver les opérations de rétrécissement automatique, définir la vérification de page pour toutes les bases de données sur somme de contrôle, et activer AUTO_CREATE_STATISTICS et AUTO_UPDATE_STATISTICS. Avoir un processus régulier en place pour mettre à jour les statistiques.

    • Vous pouvez définir le T-SQL suivant pour chacune des bases de données installées par Hub et Interact à cette fin :

    ALTER DATABASE [NomBaseDonnéesIci] SET AUTO_CLOSE OFF;

    ALTER DATABASE [NomBaseDonnéesIci] SET AUTO_SHRINK OFF;

    ALTER DATABASE [NomBaseDonnéesIci] SET AUTO_UPDATE_STATISTICS ON;

    ALTER DATABASE [NomBaseDonnéesIci] SET AUTO_CREATE_STATISTICS ON;

    ALTER DATABASE [NomBaseDonnéesIci] SET PAGE_VERIFY CHECKSUM;

  • Disposer d'un processus régulier pour exécuter DBCC CHECKDB : il est recommandé qu'une tâche SQL Agent soit exécutée au moins une fois par jour pendant les périodes d'utilisation minimale ou inexistante du système. La corruption des résultats doit être vérifiée. Il peut être utile de créer des alertes SQL Agent pour informer un groupe d'opérateurs des erreurs ci-dessous.

    • 823 - Corruption des E/S dures

    • 824 - Corruption des E/S logicielles

    • 825 - Corruption de la lecture/nouvelle tentative

    • 9100 - Corruption des index

    • Erreurs de gravité 19-25

  • Optimiser pour les charges de travail ad hoc = ON

  • Compression de sauvegarde par défaut = ON

  • Somme de contrôle de sauvegarde par défaut = ON

  • Seuil de coût pour le parallélisme ; 50 est un bon point de départ.

  • Degré maximal de parallélisme : dépend de la configuration NUMA de SQL Server, mais pas plus que le nombre de cœurs pour un nœud NUMA unique.

  • Définir la fermeture automatique = ON

  • Mémoire de serveur min. : différente par SQL Server, mais doit être définie.

  • Mémoire de serveur max. : différente par SQL Server, mais doit être définie.

Recommandations de disposition du disque

Il est recommandé d'utiliser des disques distincts pour les fichiers log de données et de transactions, les bases de données temporaires et les sauvegardes.

Créer un plan de maintenance

Assurez-vous d'avoir un plan de maintenance en place pour effectuer régulièrement des sauvegardes. Utilisez le plan de maintenance préféré de votre organisation pour sauvegarder les bases de données SQL. Si votre organisation n'a pas de plan de maintenance, il est recommandé que vous recherchiez les meilleures pratiques du secteur et que vous choisissiez un plan de maintenance qui répond aux besoins de votre organisation.

Faire des sauvegardes

Les sauvegardes doivent être conçues en fonction des objectifs de point de récupération (RPO) et de temps de récupération (RTO) de votre organisation.

  • RPO : le moment où vous pouvez récupérer vos données après une défaillance. Cela détermine la quantité de données perdues.
  • RTO : la durée dont vous disposez pour récupérer vos données après une défaillance. Cela détermine la durée pendant laquelle la plateforme n'est pas disponible.

Lors de la création d'un plan de sauvegarde et de récupération pour les bases de données Blue Prism, il est important d'examiner et d'implémenter les points ci-dessous :

  • Définir à la fois le RPO et le RTO.
  • Utiliser le modèle de récupération FULL pour permettre des sauvegardes complètes, différentielles et de logs de transactions en ligne avec votre RPO et votre RTO.
  • Utiliser les options WITH CHECKSUM et VERIFYONLY sur toutes les sauvegardes pour vérifier que les sauvegardes sont valides et peuvent être restaurées si nécessaire.
  • Utiliser l'option WITH COMPRESSION pour économiser de l'espace disque et réduire le temps nécessaire à la sauvegarde des bases de données et éventuellement à leur restauration.
  • Documenter le processus de sauvegarde et de récupération.
  • Vérifier que vos sauvegardes sont fiables en essayant régulièrement de les restaurer.

La fréquence à laquelle vous effectuez ces sauvegardes dépend de la taille de votre organisation, ainsi que de la quantité et de la valeur du risque lié aux données.

Il est recommandé d'effectuer des sauvegardes complètes pendant les temps d'arrêt absolus. Des sauvegardes incrémentielles peuvent être effectuées sans arrêter les services avec le risque que certaines données soient perdues.

Résoudre la fragmentation de l'index

La fragmentation de l'index de base de données réduit les performances des requêtes au fil du temps. Pour éviter cela, reconstruisez les index aussi souvent que le temps d'arrêt de la base de données le permet. La reconstruction des index après avoir effectué des sauvegardes et/ou la suppression de grandes quantités de données est également conseillée. Il est également recommandé de reconstruire les index avant d'effectuer une sauvegarde complète de la base de données afin de minimiser leur fragmentation en cas d'obligation de restaurer une sauvegarde complète.

Les seuils recommandés pour la reconstruction/réorganisation de la maintenance des index sont : réorganisation < 30 % et reconstruction > 30 %.

La reconstruction des index de base de données peut être planifiée pour s'exécuter en tant que tâche à l'intérieur du serveur de base de données et/ou ajoutée au plan de maintenance de la base de données. Il est recommandé de les exécuter pendant les périodes de faible activité du système et de les programmer pour éviter qu'elles ne se chevauchent avec la sauvegarde et la maintenance DBCC CHECKDB.