Sqlserver
 sql >> Base de données >  >> RDS >> Sqlserver

Maintenance des bases de données du système SQL Server

L'installation de SQL Server crée par défaut plusieurs bases de données système par instance pour maintenir et administrer cette instance. Dans cet article, nous examinerons ces bases de données système et comprendrons leurs responsabilités.

Bases de données système SQL Server

Dans SQL Server, les bases de données système sont créées au cours du processus d'installation pour stocker les détails de configuration spécifiques à l'instance SQL Server afin qu'ils fonctionnent normalement. Chaque installation de SQL Server crée un minimum de 5 bases de données système et 1 base de données système liée à la réplication nommée base de données de distribution qui sera créé par les utilisateurs si la réplication est configurée dans cette instance. Chaque base de données système a son objectif et nous étudierons cela en détail plus loin dans cet article.

Les bases de données du système sont :

  • Maître – Installé par défaut
  • Msdb – Installé par défaut
  • Modèle :Installé par défaut
  • Tempdb – Installé par défaut
  • Ressource :Installée par défaut . Introduit dans SQL Server 2005 et disponible dans les versions ultérieures de SQL Server et donc non disponible dans SQL Server 2000 et les versions antérieures.
  • Répartition – Créé par l'action de l'utilisateur . Les utilisateurs peuvent créer la base de données de distribution pour configurer la réplication.

Pour afficher la base de données système installée dans SQL Server, nous pouvons utiliser SSMS.

Connectez-vous à votre instance SQL Server, développez Bases de données > Bases de données système :

Avez-vous remarqué que la ressource la base de données manque dans la liste ci-dessus ? Le fait est que la base de données de ressources est une base de données système spéciale qui n'est pas répertoriée dans l'explorateur d'objets SSMS. Cependant, nous pouvons interroger les détails de la base de données de ressources à partir d'un système DMV nommé sys.sysaltfiles et exécutez la requête :

SELECT dbid, db_name(dbid) database_name, fileid, name, filename
FROM sys.sysaltfiles
WHERE dbid NOT BETWEEN 5 AND 11

Dans les résultats, nous pouvons voir les bases de données système dans l'ordre :master, tempdb, model, msdb, distribution , et, enfin, le dbid 32767 qui est une base de données de ressources. Cependant, cette base de données de ressources n'affiche aucun nom de base de données car elle n'a pas d'entrée dans sys.databases . J'ai exclu quelques bases de données d'utilisateurs entre dbid 5 et 11 et inclus AdventureWorks_REPL comme exemple pour montrer que DMV peut également afficher les bases de données utilisateur. Nous reviendrons plus en détail sur la base de données de ressources et d'autres bases de données système plus tard.

Restrictions relatives aux bases de données du système SQL

Étant donné que les bases de données système contiennent des détails critiques sur la configuration du système, des mesures de sécurité appropriées doivent être mises en place pour éviter la suppression accidentelle de données. Par conséquent, les bases de données système ont les restrictions ci-dessous par rapport aux bases de données utilisateur :

Les bases de données système ne peuvent pas être mises hors ligne

Nous pouvons mettre une base de données d'utilisateurs hors ligne à l'aide de la commande ALTER DATABASE comme indiqué ci-dessous :

ALTER DATABASE AdventureWorks SET OFFLINE WITH ROLLBACK IMMEDIATE
GO

Cependant, si nous essayons de mettre l'une des bases de données système HORS LIGNE à l'aide de la commande ci-dessus, nous recevrons une erreur comme indiqué ci-dessous :

Les bases de données système ne peuvent pas être supprimées

Bien que nous puissions supprimer les bases de données utilisateur en exécutant la commande DROP DATABASE

DROP DATABASE AdventureWorks

Si nous essayons de supprimer l'une des bases de données système, nous recevrons l'erreur comme indiqué ci-dessous :

Le propriétaire des bases de données système ne peut pas être modifié

Le propriétaire de la base de données système est sa par défaut. Il ne peut pas être modifié. Les tentatives de renommer le propriétaire de la base de données système provoqueront des erreurs.

Cependant, il existe une exception. Il est possible de modifier le propriétaire du msdb base de données.

use [master];
GO
ALTER AUTHORIZATION ON DATABASE::[master] TO [RRJ\RRJ]
GO

Le nom de la base de données des bases de données système ne peut pas être modifié

Si nous essayons de renommer les bases de données système, nous recevrons le message d'erreur comme indiqué ci-dessous :

ALTER DATABASE master MODIFY NAME = RRJ_master;
GO

Le classement des bases de données système ne peut pas être modifié

Les bases de données système sont créées avec le nom de classement choisi lors de l'installation de SQL Server. Une fois installé, le classement des bases de données système ne peut pas être modifié. La seule façon de modifier le classement des bases de données système consiste à réinstaller l'instance SQL Server avec le classement correct.

Le groupe de fichiers principal des bases de données système ne peut pas être défini sur le mode READ_ONLY

Étant donné que la base de données système capture des informations critiques liées aux instances SQL Server, SQL Server n'autorise pas les fichiers de données primaires résidant dans le groupe de fichiers primaire à être définis en tant que lecture seule .

La fonctionnalité de capture de données modifiées ne peut pas être activée sur les bases de données système

Cette fonctionnalité est utilisée pour suivre chaque modification DML qui se produit sur une base de données sur les tables suivies. Si nous essayons d'activer la fonctionnalité Change Data Capture sur n'importe quelle base de données système, l'erreur se produira :

use master
GO
exec sys.sp_cdc_enable_db

Maintenant que nous connaissons clairement la différence entre les bases de données système et les bases de données utilisateur, nous pouvons examiner plus en détail les objectifs de chaque base de données système.

Base de données principale dans SQL Server

La base de données du système maître contient les détails de configuration clés liés à l'instance SQL Server . SQL Server s'appuie sur eux lorsqu'il démarre une instance particulière. S'il est impossible de démarrer la base de données master pour une raison quelconque, l'instance SQL Server ne peut pas démarrer non plus.

Ces détails clés stockés dans la base de données principale incluent les comptes de connexion, les détails du serveur lié, les points de terminaison, les paramètres de configuration du système et les détails sur toutes les bases de données utilisateur.

Vient maintenant la question. Comment le service SQL Server sait-il où les données et les fichiers journaux de la base de données master sont disponibles ? La réponse réside dans les paramètres de configuration de démarrage du service SQL Server.

Pour afficher les paramètres de configuration de démarrage d'une instance SQL Server, nous devons d'abord connaître l'outil intégré nommé SQL Server Configuration Manager . Il aide à gérer tous les services liés à SQL Server de toutes les instances disponibles sur le serveur particulier. Pour afficher ces données, ouvrez le gestionnaire de configuration SQL Server et il affichera la liste comme indiqué ci-dessous :

Cliquez sur Services SQL Server pour afficher la liste des Services disponibles sur ce Serveur ou PC :

Attendez une seconde ! Il semble familier à services.msc répertoriant tous les services disponibles sur le serveur, mais affichant uniquement les services liés à SQL Server.

Ouvrons services.msc pour voir à quoi il ressemble et vérifier les différences entre le gestionnaire de configuration SQL Server et services.msc pour comparer lequel est le meilleur.

Le gestionnaire de configuration SQL Server affiche l'ID de processus des services en cours d'exécution. Nous n'avons pas trouvé cela dans services.msc . Bien sûr, nous pouvons obtenir ces informations à partir du Gestionnaire des tâches de Windows, mais le gestionnaire de configuration SQL Server nous a aidés à les visualiser en un seul endroit.

Maintenant, prenons une vue détaillée. Faites un clic droit sur le service SQL Server à partir de services.msc . Vous verrez les menus ci-dessous :Général , Connexion , Récupération , et Dépendances .

Depuis SQL Server Configuration Manager, cliquez avec le bouton droit sur SQL Server(MSSQLSERVER) service > Propriétés . Il répertorie les menus ci-dessous - Connexion, Service. FileStream, Avancé, Alwayson OnHaute disponibilité , et Paramètres de démarrage .

Les paramètres de démarrage du service qui stocke l'emplacement des données de la base de données principale et des fichiers journaux n'était disponible que dans le gestionnaire de configuration SQL Server .

Cliquez sur Paramètres de démarrage pour afficher les détails - pour Existant Paramètres . Vous verrez les informations suivantes :

  • L'emplacement physique de la base de données principale Fichier de données
  • L'emplacement physique de la base de données principale Fichier journal des transactions
  • L'emplacement physique du dossier ErrorLog où se trouvent les erreurs liées au service SQL Server.

Nous pouvons ajouter plus de paramètres de démarrage comme Mode mono-utilisateur (-m) , etc. Pour cela, nous devons spécifier les valeurs nécessaires dans Spécifier un paramètre de démarrage et cliquez sur Ajouter .

Nous avons remarqué que SQL Server Configuration Manager n'affiche pas seulement des détails avancés, mais nous permet également de faire de nombreuses configurations avancées liées au service SQL Server. Par conséquent, je recommanderais personnellement d'utiliser le gestionnaire de configuration SQL Server pour arrêter/démarrer les services liés à SQL Server par rapport à l'option Services.msc par défaut.

Pratiques recommandées pour la base de données principale

Étant donné que la base de données principale stocke des détails critiques sur l'instance SQL Server, il est recommandé de suivre les meilleures pratiques lors de la gestion de cette base de données.

  • Chaque modification de configuration sur une instance de SQL Server sera stockée dans la base de données principale. Ainsi, vous devez toujours effectuer une sauvegarde complète de la base de données principale pour restaurer le dernier état au cas où nous restaurons la base de données principale à partir de la sauvegarde complète, selon les besoins.
  • Même si SQL Server permet aux utilisateurs de créer des tables utilisateur ou d'autres objets dans la base de données principale, il n'est pas recommandé de le faire. La base de données maîtresse doit rester simple et propre. Si vous devez créer des objets utilisateur dans la base de données master, vous devez effectuer des sauvegardes complètes de la base de données master plus fréquemment.
  • SQL Server prend en charge l'option de procédure de démarrage pour exécuter certaines procédures stockées lors du démarrage d'une instance SQL Server. Il utilise l'sp_procoption procédure. Soyez prudent lorsque vous utilisez cette option, car un code non optimal ou une logique récursive peut avoir un impact sur le temps de démarrage de l'instance SQL Server.

Si SQL Server n'a pas pu démarrer en raison de problèmes avec la base de données principale, nous devons restaurer la base de données principale à partir de la dernière bonne sauvegarde connue.

Base de données modèle dans SQL Server

Comme son nom l'indique, la base de données du système de modèles agit comme un modèle ou un modèle pour toute création de base de données utilisateur en termes de chemin de fichier, de taille initiale, de paramètres de croissance automatique, de modèle de récupération et d'autres options de configuration .

Tous les objets utilisateur tels que les tables, les procédures, etc., qui sont créés dans les bases de données modèles seront également créés automatiquement dans les nouvelles bases de données utilisateur de cette instance SQL Server.

Vérifions cela en créant une nouvelle table dans la base de données du modèle :

Vérifions si cette table est présente dans la base de données du modèle :

La base de données modèle stocke également le chemin de fichier par défaut des bases de données utilisateur, comme indiqué ci-dessous dans les Propriétés de la base de données du msdb base de données.

Selon la configuration actuelle, la taille initiale du fichier des deux Données et fichiers journaux est défini sur 8 Mo avec une croissance automatique pour les deux définis sur 64 Mo.

Si vous devez créer une base de données utilisateur dans un chemin de fichier différent au lieu de l'emplacement du fichier de base de données modèle, nous pouvons le modifier dans les Propriétés du serveur de cette instance SQL Server.

Dans SSMS, faites un clic droit sur Serveur > Propriétés > Paramètres de la base de données . Afficher les emplacements par défaut de la base de données :

Remplacez le chemin du fichier par le chemin souhaité et cliquez sur OK . La base de données des utilisateurs Données et Journal les fichiers seront créés dans le nouveau chemin que vous avez fourni.

Créons une nouvelle base de données nommée model_test et vérifiez les nouveaux chemins d'accès aux fichiers de données et de journaux de la base de données, ainsi que les propriétés des fichiers Initial et Autogrowth et le model_verify table sur la nouvelle base de données.

Vérifions le model_test Chemins d'accès aux données et aux fichiers journaux. Faites un clic droit sur le model_test base de données> Propriétés > Fichiers :

Comme nous pouvons le voir, les Données et Journal fichiers du model_test base de données sont créés en fonction du chemin disponible dans la base de données modèle. La valeur de taille de fichier initiale des fichiers de données et journaux est de 8 Mo. La valeur de croissance automatique est de 64 Mo. Ces valeurs correspondent à la configuration de la base de données du modèle.

Maintenant, nous allons vérifier si le model_verify la table est créée dans le model_test base de données. Nous pouvons voir cette nouvelle base de données.

Outre les tables, cela s'applique aux vues, aux procédures stockées, aux fonctions et à tous les objets créés dans les bases de données modèles.

Pratiques recommandées pour la base de données modèle

Étant donné que la base de données modèle sert de modèle pour toute nouvelle création de base de données utilisateur, nous devons mettre en œuvre les pratiques ci-dessous lorsque nous la traitons :

  • Chaque fois que vous souhaitez implémenter des modifications dans la configuration de la base de données modèle (par exemple, la taille initiale du fichier, la taille de la croissance automatique, la création, la modification ou la suppression d'objets utilisateur), effectuez immédiatement une sauvegarde complète de la base de données modèle.
  • Étant donné que tous les objets utilisateur créés dans les bases de données modèles sont créés sur n'importe quelle base de données utilisateur, veillez à n'ajouter que les objets requis. Sinon, de nombreux objets inutiles seront créés sur toutes les bases de données utilisateur, et vous passerez beaucoup de temps à les trier et à nettoyer vos bases de données.
  • Configurez les paramètres Taille initiale du fichier et Croissance automatique pour les fichiers de données et journaux. Cela permet de mieux gérer la taille des fichiers de données et de journaux dans les bases de données utilisateur et d'améliorer les performances.

Base de données MSDB

La base de données système msdb stocke les informations critiques ci-dessous dans les tables système :

  • Éléments liés à l'Agent SQL Server, tels que les tâches, les historiques de tâches, les alertes, les opérateurs, les proxys, etc.
  • Fonctionnalités SQL Server telles que Service Broker et Database Mail avec les détails de configuration et d'historique.
  • Les détails de la sauvegarde et de la restauration de SQL Server sont stockés dans les tables de la base de données msdb.
  • Configurations d'envoi de journaux, profils d'agent de réplication et configurations de collecteur de données.
  • Plans de maintenance, packages SSIS et quelques autres détails.

En d'autres termes, la base de données système msdb stocke toutes les informations critiques liées aux services de l'agent SQL Server et à certains autres services connexes.

Pratiques recommandées pour la base de données msdb

La base de données msdb stocke de nombreuses informations de configuration critiques liées aux agents SQL Server, aux travaux et à la messagerie de base de données. Il stocke également des détails historiques. Par conséquent, nous devons mettre en œuvre les pratiques ci-dessous lorsque nous traitons avec la base de données msdb :

  • Dans une instance SQL Server avec de nombreuses bases de données ou tâches configurées, la taille de la base de données msdb augmentera continuellement au fil du temps. Par conséquent, des sauvegardes complètes doivent être implémentées quotidiennement pour les bases de données msdb avec d'autres bases de données utilisateur. Si msdb reçoit beaucoup d'informations critiques, nous pouvons modifier le modèle de récupération de la base de données msdb sur Complet, puis implémenter également la sauvegarde du journal des transactions.
  • Même si SQL Server permet aux utilisateurs de créer des objets utilisateur sur la base de données msdb, il est recommandé de ne pas créer de tables ou d'objets utilisateur dans la base de données msdb et d'augmenter davantage la taille de la base de données msdb.
  • Effectuez un nettoyage régulier des tables système msdb pour garder la taille de la base de données msdb sous contrôle et éviter les impacts sur les performances d'avoir des données volumineuses sur plusieurs tables.

Base de données Tempdb

La base de données système tempdb peut être considéré comme une zone de travail globale disponible pour tous les utilisateurs connectés à l'instance SQL Server pour effectuer leur SELECT ou d'autres opérations .

La base de données Tempdb contiendra les types d'objets ci-dessous pendant que les utilisateurs effectuent leurs opérations :

  • Les objets temporaires créés explicitement par les utilisateurs peuvent être des tables et des index temporaires locaux ou globaux, des variables de table, des tables utilisées dans les fonctions de table et des curseurs.
  • Objets internes créés par le moteur de base de données, tels que :
    • Tables de travail utilisées pour les résultats intermédiaires pour les spools, les curseurs, les tris et les grands objets temporaires (LOB)
    • Fichiers de travail pour les opérations de jointure par hachage ou d'agrégation par hachage
    • Trier les résultats intermédiaires lors de la création ou de la reconstruction d'index si SORT_IN_TEMPDB est défini sur ON et d'autres opérations telles que les requêtes GROUP BY, ORDER BY ou UNION
  • Magasins de versions prenant en charge la fonctionnalité de gestion des versions de ligne, soit le magasin de versions commun, soit le magasin de versions de construction d'index en ligne.

Chaque fois que le service SQL Server démarre ou redémarre, la base de données tempdb sera créée à nouveau à l'aide de la base de données modèle. Ainsi, tempdb est la seule base de données système qui ne peut pas être sauvegardée .

Si nous essayons de le sauvegarder, nous recevrons des erreurs :

Étant donné que nous utilisons tempdb dans presque toutes les opérations utilisateur, cette base de données pose un goulot d'étranglement important en termes de performances sur plusieurs versions de SQL Server. À partir de SQL Server 2016, plusieurs techniques d'optimisation ont été mises en œuvre par Microsoft - nous en discuterons plus tard.

Avant d'aborder les pratiques recommandées pour la base de données tempdb, examinons rapidement ses fichiers de données dans la configuration par défaut, comme indiqué ci-dessous :

Pour mon instance SQL Server actuelle, nous avons 4 fichiers de données et un fichier journal pour la base de données tempdb.

À partir de SQL Server 2016, nous avons le programme d'installation de SQL Server qui nous permet d'ajouter plusieurs fichiers à tempdb. Les 4 fichiers ci-dessus avec une taille initiale de 8 Mo et une taille de croissance automatique de 64 Mo ont été créés à l'aide des options par défaut indiquées ci-dessous.

Si nous avons un seul fichier de données dans la base de données tempdb, tous les cœurs logiques disponibles sur le serveur tentent d'accéder au même fichier de données de tempdb, ce qui entraîne un goulot d'étranglement des performances.

Avoir plusieurs fichiers de données associera logiquement certains cœurs à un seul fichier. Ainsi, nous avons moins de conflits sur les fichiers de données tempdb. Cela améliorera l'impact sur les performances des fichiers de données tempdb.

Pratiques recommandées pour la base de données tempdb

Étant donné que la base de données tempdb est comme une zone de travail globale pour toutes les activités des utilisateurs, la taille de tempdb augmente en fonction des activités des utilisateurs. Cela peut être un goulot d'étranglement des performances pour l'ensemble de l'instance SQL Server.

Par conséquent, nous devons mettre en œuvre les pratiques suivantes :

  1. Placez les fichiers de données et journaux tempdb sur un stockage hautes performances pour obtenir des IOPS plus élevées pour de meilleures performances.
  2. Assurez-vous que la base de données tempdb est divisée en plusieurs fichiers de données pour réduire les conflits et éviter les goulots d'étranglement des performances sur la base de données tempdb.
    • Si le nombre de cœurs logiques est inférieur à 8, nous pouvons avoir un fichier de données tempdb par cœur logique. Dans notre instance de test, nous avions 4 cœurs logiques. Par conséquent, 4 fichiers de données sur tempdb devraient suffire.
    • Si le nombre de cœurs logiques est supérieur à 8, commencez avec 8 fichiers de données et augmentez de 4 fichiers de données si des problèmes de contention et de performances sont observés sur la base de données tempdb.
    • Si le nombre de cœurs logiques dans un serveur est de 32 ou 64, nous pouvons commencer avec 8 fichiers de données. Cela signifie que 4 cœurs ou 8 cœurs sont associés logiquement pour un même fichier de données.

      Pour plus de clarté sur les multiples fichiers de données tempdb, je vous recommande l'excellent article de Paul Randal.
  3. Assurez-vous que les fichiers de données tempdb sont configurés avec une taille de fichier initiale optimale. Idéalement, cela devrait être réalisé via une approche par essais et erreurs. Tempdb avec une taille de fichier initiale optimale a tendance à augmenter moins de fois que tempdb configuré avec une taille de fichier initiale inférieure qui a tendance à augmenter plusieurs fois, ce qui entraîne une fragmentation. Par exemple, dans la configuration actuelle, tous les fichiers sont configurés avec une taille de fichier initiale de 8 Mo, ce qui est trop petit pour gérer les charges de travail SQL. Ainsi, appliquez l'approche par essais et erreurs et définissez la taille initiale du fichier sur 512 Mo ou 1 Go, ou sur une autre valeur.
  4. Assurez-vous que tous les fichiers de données tempdb ont la même taille de fichier. Les propriétés de croissance automatique doivent être définies de la même manière. Dans notre scénario, tous les fichiers sont définis sur une croissance automatique de 64 Mo. La définition de la taille de la croissance automatique sur 512 Mo ou 1 Go, ou toute autre valeur appropriée, permet de réduire la croissance automatique fréquente sur les fichiers de données tempdb.
  5. Assurez-vous que la taille de fichier initiale et la croissance automatique du fichier journal tempdb sont configurées sur une valeur optimale similaire à celle des fichiers de données tempdb. Étant donné que le modèle de récupération de tempdb est défini sur Simple par défaut et ne peut pas être modifié, la configuration de la taille de fichier initiale et de la propriété de croissance automatique du fichier journal tempdb devrait suffire.

Tempdb est vital pour les performances de l'instance SQL Server. Nous examinerons en détail les problèmes fréquents rencontrés sur tempdb et comment les réduire de manière optimale dans nos prochains articles.

Base de données de ressources dans SQL Server

La base de données du système de ressources est la seule base de données système en lecture seule qui n'est pas répertoriée sous les bases de données système dans SSMS, comme indiqué précédemment.

L'ID de base de données (dbid) de bases de données de ressources sur toutes les instances sera de 32 767, ce qui correspond également au nombre maximal de bases de données prises en charge dans une instance SQL Server. Il peut être interrogé à partir des sys.sysaltfiles système DMV. Exécution de la requête SELECT ci-dessous sur sys.sysaltfiles renverra le resultset indiquant où se trouvent les fichiers Data et Log de la base de données des ressources :

Nous pouvons voir les fichiers physiques de la base de données de ressources disponibles dans le chemin mentionné ci-dessus. La date de modification indique l'heure d'installation de l'instance SQL Server ou la dernière fois que les Service Packs (SP) ou la mise à jour cumulative (CU) sont appliqués sur cette instance.

La base de données des ressources contient tous les objets système, tels que sys.objects , sys.databases , sys.sysaltfiles , etc. physiquement à l'intérieur. Cette base de données répertorie logiquement tous ces objets sous le schéma sys dans toutes les bases de données disponibles dans l'instance . Étant donné que la base de données des ressources est en lecture seule, aucun objet ou donnée utilisateur ne peut y être créé.

La base de données du système de ressources a été introduite à partir de SQL Server 2005 pour accélérer la mise à niveau de SQL Server vers une nouvelle version de SP ou CU. Avant d'introduire cette option, toutes ces mises à niveau et mises à jour signifiaient que les modifications s'appliqueraient à toutes les bases de données, ce qui rendait le processus de mise à niveau plus compliqué et plus long. Désormais, toute mise à niveau de version de SQL Server ou mise à jour SP ou CU ne fait que mettre à niveau ou remplacer la base de données de ressources.

Comme la base de données des ressources est en lecture seule et non visible pour les utilisateurs, elle ne nécessite aucune intervention de l'utilisateur. Si vous souhaitez inclure la sauvegarde de la base de données des ressources dans votre planification de haute disponibilité ou de reprise après sinistre, effectuez simplement une sauvegarde de fichier des fichiers mssqlsystemresource.mdf et mssqlsystemresource.ldf après l'arrêt des services SQL Server (le service SQL Server ne permet pas de copier les fichiers pendant Le service SQL Server est opérationnel) et enregistrez-le dans un emplacement sécurisé. Veillez à ne pas le mettre à jour sur une instance de SQL Server exécutée avec une version différente des niveaux SP ou CU, car cela pourrait entraîner des problèmes inattendus.

Base de données de distribution dans SQL Server

La base de données du système de distribution est le cœur de la réplication. Les utilisateurs peuvent créer ou configurer une base de données de distribution dans le cadre de la configuration de la réplication à l'aide de l'assistant de configuration de distribution ou de l'assistant de création de publication. Nous avons décrit en détail les étapes de création de la base de données de distribution dans le cadre de mon article précédent sur les composants internes de la réplication transactionnelle SQL Server.

Pratiques recommandées pour la base de données de distribution

Étant donné que la base de données de distribution est essentielle pour la fonctionnalité de réplication, nous devons implémenter les pratiques suivantes :

  • Déplacez les fichiers de données et journaux de la base de données de distribution vers le lecteur avec un bon IOPS pour éviter les problèmes de performances de distribution.
  • Configurez les propriétés Taille initiale du fichier et Croissance automatique de la base de données de distribution sur une meilleure valeur pour éviter les problèmes de fragmentation.
  • Inclure la base de données de distribution aux tâches de maintenance de sauvegarde complète de la base de données.
  • Incluez les bases de données de distribution aux tâches de maintenance d'index pour éviter les problèmes de fragmentation et de performances.

Dans mon article sur les composants internes de la réplication transactionnelle SQL Server, vous trouverez également des recommandations sur d'autres pratiques efficaces.

Conclusion

Merci d'avoir parcouru un autre article puissant !

J'espère que cela vous a aidé à clarifier l'essence et les objectifs des bases de données du système SQL Server et à apprendre les meilleures pratiques pour éviter les problèmes de performances sur ces bases de données.