16
Chapitre 2. Architecture de SQL Server
les trouvez dans l’explorateur d’objets, sous vues/vues système, et vous pouvez en obtenir la
liste à l’aide des vues de métadonnées, par exemple ainsi :
SELECT *
FROM sys.system_objects
WHERE name LIKE 'dm_%' ORDER BY name;
Vous y trouverez la plupart des vues disponibles. Certaines n’y figurent pas car elles sont non
documentées, ou sont mises en œuvre sous forme de fonctions.
Les données renvoyées par ces vues dynamiques sont maintenues dans un cache spécial de
la mémoire adressée par SQL Server. Elles ne sont pas stockées de façon persistante sur le
disque : les compteurs sont remis à zéro lors du redémarrage du service SQL. Par conséquent, pour que ces vues offrent des informations utiles, vous ne devez les consulter qu’après
un temps significatif d’utilisation du serveur. Nous utiliserons beaucoup les vues de gestion
dynamiques tout au long de cet ouvrage.
Point de contrôle et récupération
Comment garantir la cohérence d’une base de données en cas de panne ou de redémarrage intempestif ? Les techniques appliquées dans SQL Server sont également
standards aux SGBDR. Premièrement, le maintien de toutes les informations de
transaction dans le journal, avec les marqueurs temporels de leur début et fin, assure
qu’elles pourront être reproduites. Lorsque l’instance SQL redémarre, chaque base
de données entre en étape de récupération (recovery) : les transactions du journal
non encore répercutées dans les pages de données sont reproduites. Ce sont soit des
transactions qui n’étaient pas terminées lors du dernier point de contrôle (checkpoint), soit qui ont commencé après celui-ci. Si la transaction n’est pas validée dans
le journal (parce qu’elle a été annulée explicitement, ou parce qu’elle n’a pas pu se
terminer au moment de l’arrêt de l’instance), elle est annulée. Selon le volume des
transactions journalisées et la date du dernier point de contrôle, cette récupération
peut prendre du temps. SQL Server s’assure donc d’émettre un point de contrôle
suffisamment souvent pour maintenir une durée de récupération raisonnable.
Une option de l’instance permet de régler la durée maximum, en minutes, de la
récupération : le recovery interval. Par défaut la valeur est 0, ce qui correspond à une
auto-configuration de SQL Server pour assurer dans la plupart des cas une récupération de moins d’une minute. Changer cette valeur diminue les fréquences de point
de contrôle et augmente le temps de récupération. Vous pouvez le faire dans les propriétés de l’instance dans SSMS, ou via sp_configure :
EXEC sp_configure 'show advanced option', '1';
RECONFIGURE;
EXEC sp_configure 'recovery interval', '3';
RECONFIGURE WITH OVERRIDE;
EXEC sp_configure 'show advanced option', '1';
La procédure stockée système sp_configure est utilisée pour modifier des options
de configuration de l’instance SQL Server. Certaines options sont aussi visibles
dans les boîtes de dialogues de configuration dans SSMS. Par défaut, sp_configure
ne touche que les options courantes. Pour afficher et changer les options avan-
Chapitre 2. Architecture de SQL Server
les trouvez dans l’explorateur d’objets, sous vues/vues système, et vous pouvez en obtenir la
liste à l’aide des vues de métadonnées, par exemple ainsi :
SELECT *
FROM sys.system_objects
WHERE name LIKE 'dm_%' ORDER BY name;
Vous y trouverez la plupart des vues disponibles. Certaines n’y figurent pas car elles sont non
documentées, ou sont mises en œuvre sous forme de fonctions.
Les données renvoyées par ces vues dynamiques sont maintenues dans un cache spécial de
la mémoire adressée par SQL Server. Elles ne sont pas stockées de façon persistante sur le
disque : les compteurs sont remis à zéro lors du redémarrage du service SQL. Par conséquent, pour que ces vues offrent des informations utiles, vous ne devez les consulter qu’après
un temps significatif d’utilisation du serveur. Nous utiliserons beaucoup les vues de gestion
dynamiques tout au long de cet ouvrage.
Point de contrôle et récupération
Comment garantir la cohérence d’une base de données en cas de panne ou de redémarrage intempestif ? Les techniques appliquées dans SQL Server sont également
standards aux SGBDR. Premièrement, le maintien de toutes les informations de
transaction dans le journal, avec les marqueurs temporels de leur début et fin, assure
qu’elles pourront être reproduites. Lorsque l’instance SQL redémarre, chaque base
de données entre en étape de récupération (recovery) : les transactions du journal
non encore répercutées dans les pages de données sont reproduites. Ce sont soit des
transactions qui n’étaient pas terminées lors du dernier point de contrôle (checkpoint), soit qui ont commencé après celui-ci. Si la transaction n’est pas validée dans
le journal (parce qu’elle a été annulée explicitement, ou parce qu’elle n’a pas pu se
terminer au moment de l’arrêt de l’instance), elle est annulée. Selon le volume des
transactions journalisées et la date du dernier point de contrôle, cette récupération
peut prendre du temps. SQL Server s’assure donc d’émettre un point de contrôle
suffisamment souvent pour maintenir une durée de récupération raisonnable.
Une option de l’instance permet de régler la durée maximum, en minutes, de la
récupération : le recovery interval. Par défaut la valeur est 0, ce qui correspond à une
auto-configuration de SQL Server pour assurer dans la plupart des cas une récupération de moins d’une minute. Changer cette valeur diminue les fréquences de point
de contrôle et augmente le temps de récupération. Vous pouvez le faire dans les propriétés de l’instance dans SSMS, ou via sp_configure :
EXEC sp_configure 'show advanced option', '1';
RECONFIGURE;
EXEC sp_configure 'recovery interval', '3';
RECONFIGURE WITH OVERRIDE;
EXEC sp_configure 'show advanced option', '1';
La procédure stockée système sp_configure est utilisée pour modifier des options
de configuration de l’instance SQL Server. Certaines options sont aussi visibles
dans les boîtes de dialogues de configuration dans SSMS. Par défaut, sp_configure
ne touche que les options courantes. Pour afficher et changer les options avan-