Présentation
La conception de SQL Server implique un mappage un-à-plusieurs entre le moteur de base de données (instance) et les bases de données hébergées sur l'instance. Cela signifie que vous pouvez déployer plusieurs bases de données sur une instance du serveur SQL. Selon la documentation Microsoft, vous pouvez avoir jusqu'à 32767 bases de données sur une seule instance de SQL Server. Bien sûr, il y aura des limitations, comme les ressources sur le serveur, la gestion de la simultanéité sur TempDB, le trafic réseau, etc.
Les bases de données déployées sur une instance SQL Server peuvent être des bases de données système ou des bases de données utilisateur. Les bases de données système sont installées avec l'instance. Dans cet article, nous discuterons de l'objectif de chaque base de données système. Nous clarifierons également ce dont vous devez tenir compte lors de la gestion des bases de données système sur SQL Server.
Présentation des bases de données système
Les bases de données système font partie de nombreux processus qui se déroulent lorsque vous installez une instance de SQL Server. Par défaut, ces bases de données sont créées dans les chemins suivants :
%programfiles%\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA
et
%programfiles%\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Log
Le chemin peut être différent. Lors de l'installation de SQL Server, vous pouvez spécifier l'emplacement des fichiers de la base de données système.
Pour répertorier toutes les bases de données système d'une instance, vous pouvez appeler le code du Listing 1. Le Listing 2 peut être utilisé pour déterminer l'emplacement des fichiers de données associés aux bases de données système. Notez que dans les deux scripts, nous utilisons un filtre renvoyant les bases de données avec database_id de 5 ou supérieur à 5.
Les bases de données système "visibles" essentielles ont des database_ids 1,2,3,4 - elles se réfèrent respectivement à master, tempdb, model et msdb. Il existe également une base de données "invisible" appelée les bases de données de ressources et d'autres bases de données système créées lorsque vous activez des fonctionnalités telles que la réplication.
-- Listing 1: System Databases
select
name
,database_id
,create_date
,state_desc
,recovery_model_desc
,log_reuse_wait_desc
,physical_database_name
,is_db_chaining_on
,is_broker_enabled
,is_mixed_page_allocation_on
from sys.databases
where database_id<5;
-- Listing 2: System Database Files
select
name
,database_id
,DB_NAME(database_id)
,name
,physical_name
,type_desc
from sys.master_files
where database_id<5;
Figure 1 :Bases de données système
La base de données principale
La base de données master est la première base de données ouverte au démarrage de SQL Server, contenant les données suivantes :
- Les enregistrements de la structure/configuration de l'instance et de toutes les autres bases de données.
- Les vues de gestion les plus dynamiques nécessaires à la surveillance de l'instance.
Ainsi, il dispose des informations nécessaires pour ouvrir toutes les autres bases de données. C'est pourquoi il doit être le premier à s'ouvrir. La question est de savoir comment le faire.
Les paramètres de démarrage de SQL Server contiennent deux entrées, qui définissent les emplacements des données de la base de données principale et des fichiers journaux. Les paramètres de démarrage par défaut ne comprennent que trois lignes - la troisième est l'emplacement du fichier journal des erreurs. Lorsque SQL Server démarre, il doit pouvoir écrire dans ce fichier journal des erreurs.
La base de données master s'ouvre en premier. Les informations stockées dans la base de données principale, y compris les configurations définies à l'aide de sp_configure, s'appliquent pour ouvrir d'autres bases de données et terminer le processus de démarrage de l'instance.
Figure 3 :Paramètres de démarrage de SQL Server
Il existe plusieurs façons d'en savoir plus sur les objets système SQL Server utiles, tels que les vues et les fonctions de gestion dynamique.
Par exemple, développez les vues ou les nœuds de programmabilité de la base de données principale sur l'explorateur d'objets. Là, passez en revue les noms de ces objets et obtenez plus de détails à partir de la documentation en ligne.
Vous pouvez également migrer les connexions d'une instance à une autre. Pour cela, restaurez une sauvegarde de la base de données master sur l'instance de destination. Nous décrirons la technique spécifique dans un article séparé.
Figure 4 :Navigation dans les objets de la base de données principale
La base de données tempDB
La base de données tempDB est responsable du stockage des données temporaires comme les résultats intermédiaires des opérations lourdes. Il peut contenir des reconstructions d'index, des versions de ligne de bases de données configurées avec des niveaux d'isolement et d'autres fonctionnalités qui dépendent de la gestion des versions de ligne, telles que READ_COMMITTED_SNAPSHOT.
La plupart des gens considéreraient tempDB comme un goulot d'étranglement potentiel des performances, car les fonctions de chaque base de données utilisateur dans une instance dépendent de tempDB.
Le réglage de tempDB devrait être un exercice délibéré. Cependant, à partir de SQL Server 2016, vous pouvez configurer tempDB avec précision lors de l'installation de SQL Server. Un article précédent décrit en détail comment vous devez configurer et surveiller tempDB.
La base de données des modèles
Vous pouvez traiter la base de données model comme un modèle. Chaque base de données utilisateur créée dans une instance SQL Server reprend la configuration de la base de données modèle. Il a les mêmes paramètres de taille et de croissance automatique, les mêmes emplacements de fichiers, etc. Cependant, vous pouvez spécifier délibérément ces paramètres d'une manière différente dans l'instruction CREATE DATABASE.
Essentiellement, si vous avez une application qui crée une base de données par elle-même avec des paramètres par défaut, vous souhaiterez peut-être configurer la base de données model. Cela vous assure d'avoir un certain contrôle sur le résultat de ces bases de données créées automatiquement.
Expérimentons un peu avec cela, en utilisant le code du Listing 3.
-- Listing 3: Using the Model Database
select
name
,database_id
,DB_NAME(database_id) database_name
,name
,physical_name
,type_desc
,size/1024*8 [size (MB)]
,growth/1024*8 [size (MB)]
from sys.master_files
where DB_NAME(database_id)='model' or DB_NAME(database_id) like 'EXP%';
GO
create database EXP_BEFORE;
GO
USE [master]
GO
ALTER DATABASE [model] MODIFY FILE ( NAME = N'modeldev', SIZE = 102400KB , FILEGROWTH = 131072KB )
GO
ALTER DATABASE [model] MODIFY FILE ( NAME = N'modellog', SIZE = 102400KB )
GO
create database EXP_AFTER;
GO
select
name
,database_id
,DB_NAME(database_id) database_name
,name
,physical_name
,type_desc
,size/1024*8 [size (MB)]
,growth/1024*8 [size (MB)]
from sys.master_files
where DB_NAME(database_id)='model' or DB_NAME(database_id) like 'EXP%';
GOLe code effectue les étapes suivantes :
- Interroger les sys.master_files pour déterminer les paramètres utilisés dans la base de données du modèle
- Créer une base de données
- Modifier les paramètres de croissance et de croissance automatique du fichier de base de données de modèles
- Créer une autre base de données
- Requête sys.master_files à nouveau
Faites attention à la phrase unique pour la création de la base de données - "CRÉER UNE BASE DE DONNÉES". De cette façon, il récupère les paramètres appartenant à la base de données du modèle. Les résultats montrent que la deuxième fois que nous avons émis la commande CREATE DATABASE, la base de données EXP_AFTER a acquis une taille de fichier de 96 Go et une croissance automatique de 128 Mo (voir Figure 5).
Figure 5 :Utilisation de la base de données de modèles
Il convient également de mentionner que tous les paramètres de la base de données ne sont pas automatiquement récupérés à partir de la base de données du modèle. Par exemple, MIXED_PAGE_ALLOCATION défini sur OFF lorsque vous créez une nouvelle base de données, même s'il est activé dans le modèle et d'autres bases de données système.
La base de données msdb
Vous pouvez considérer la msdb comme une base de données de l'Agent SQL Server. Il stocke toutes les données liées aux travaux, au courrier de la base de données, aux opérateurs et à l'automatisation. Les données liées à l'envoi des journaux de transactions, à la réplication, etc., s'y trouvent également. Vous pouvez vérifier cela en exécutant des ensembles de requêtes dans la liste 4 dans votre instance. Par exemple, les objets liés à l'automatisation sont présents dans la msdb.
-- Listing 4: Querying msdb Objects
-- Jobs, Alerts, Operators sit in the msdb database ...
select * from msdb..sysjobs
select * from msdb..sysalerts
select * from msdb..sysoperators
select * from msdb..sysmail_allitems
-- ... NOT in the master database
select * from master..sysjobs
select * from master..sysalerts
select * from master..sysoperators
select * from master..sysmail_allitemsVous pouvez en apprendre beaucoup sur les objets dans les bases de données msdb en les extrayant et en les étudiant dans la documentation en ligne de SQL Server. La démarche est la même qu'avec la base de données master.
Vous pouvez migrer des travaux, des opérateurs, etc. d'une instance SQL Server vers une autre. Pour cela, prenez la sauvegarde de la base de données msdb de l'instance source et restaurez-la sur l'instance de destination. Nous en parlerons dans un autre article.
Épilogue
Dans cet article, nous avons fourni un aperçu rapide des bases de données système.
Les bases de données système sont livrées avec une installation SQL Server par défaut. Comprendre les différentes bases de données système et leurs rôles est une excellente aide pour gérer votre instance SQL Server.
Vous pouvez obtenir plus d'informations sur ce qu'ils stockent et comprendre comment les gérer à partir de la documentation en ligne et d'autres articles sur CodingSight.
Références
- Bases de données système
- Bases de données et stockage MS SQL Server
- Chaînage de propriété de bases de données croisées
