15
2.2 Structures de stockage
Sparse columns
SQL Server 2008 introduit une méthode de stockage optimisée pour les tables qui comportent beaucoup de colonnes pouvant contenir des valeurs NULL, permettant de limiter
l’espace occupé par les marqueurs NULL. Pour cela, vous disposez du nouveau mot-clé SPARSE
à la création de vos colonnes. Vous pouvez aussi créer une colonne virtuelle appelée
COLUMN_SET, qui permet de retourner rapidement les colonnes sparse non null. Cette voie
ouverte à la dénormalisation est à manier avec prudence, et seulement si nécessaire.
2.2.2 Journal de transactions
Le journal de transactions (transaction log) est un mécanisme courant dans le monde
des SGBD, qui permet de garantir la cohérence transactionnelle des opérations de
modification de données, et la reprise après incident. Vous pouvez vous reporter à la
section 7.5 pour une description détaillée des transactions. En un mot, toute écriture
de données est enrôlée dans une transaction, soit de la durée de l’instruction, soit
englobant plusieurs instructions dans le cas d’une transaction utilisateur déclarée à
l’aide de la commande BEGIN TRANSACTION. Chaque transaction est préalablement
enregistrée dans le journal de transactions, afin de pouvoir être annulée ou validée
en un seul bloc (propriété d’atomicité de la transaction) à son terme, soit au moment
où l’instruction se termine, soit dans le cas d’une transaction utilisateur, au moment
d’un ROLLBACK TRANSACTION ou d’un COMMIT TRANSACTION. Toute transaction est ainsi
complètement inscrite dans le journal avant même d’être répercutée dans les fichiers
de données. Le journal contient toutes les informations nécessaires pour annuler la
transaction en cas de rollback (ce qui équivaut à défaire pas à pas toutes les modifications), ou pour la rejouer en cas de relance du serveur (ce qui permet de respecter
l’exigence de durabilité de la transaction).
Le mécanisme permettant de respecter toutes les contraintes transactionnelles est le
suivant : lors d’une modification de données (INSERT ou UPDATE), les nouvelles valeurs
sont inscrites dans les pages du cache de données, c’est-à-dire dans la RAM. Seule la
page en cache est modifiée, la page stockée sur le disque restant intacte. La page de cache
est donc marquée « sale » (dirty), pour indiquer qu’elle ne correspond plus à la page originelle. Cette information est consultable à l’aide de la colonne is_modified de la vue de
gestion dynamique (DMV) sys.dm_os_buffer_descriptors :
SELECT * FROM sys.dm_os_buffer_descriptors WHERE is_modified = 1
La transaction validée est également maintenue dans le journal. À intervalle
régulier, un point de contrôle (checkpoint) aussi appelé point de reprise, est inscrit
dans le journal, et les pages modifiées par des transactions validées avant ce checkpoint sont écrites sur le disque.
Les vues de gestion dynamique
À partir de la version 2005 de SQL Server, vous avez à votre disposition, dans le schéma sys,
un certain nombre de vues systèmes qui portent non pas sur les métadonnées de la base en
cours, mais sur l’état actuel du SGBD. Ces vues sont nommées « vues de gestion
dynamique » (dynamic management views, DMV). Elles sont toutes préfixées par dm_. Vous
2.2 Structures de stockage
Sparse columns
SQL Server 2008 introduit une méthode de stockage optimisée pour les tables qui comportent beaucoup de colonnes pouvant contenir des valeurs NULL, permettant de limiter
l’espace occupé par les marqueurs NULL. Pour cela, vous disposez du nouveau mot-clé SPARSE
à la création de vos colonnes. Vous pouvez aussi créer une colonne virtuelle appelée
COLUMN_SET, qui permet de retourner rapidement les colonnes sparse non null. Cette voie
ouverte à la dénormalisation est à manier avec prudence, et seulement si nécessaire.
2.2.2 Journal de transactions
Le journal de transactions (transaction log) est un mécanisme courant dans le monde
des SGBD, qui permet de garantir la cohérence transactionnelle des opérations de
modification de données, et la reprise après incident. Vous pouvez vous reporter à la
section 7.5 pour une description détaillée des transactions. En un mot, toute écriture
de données est enrôlée dans une transaction, soit de la durée de l’instruction, soit
englobant plusieurs instructions dans le cas d’une transaction utilisateur déclarée à
l’aide de la commande BEGIN TRANSACTION. Chaque transaction est préalablement
enregistrée dans le journal de transactions, afin de pouvoir être annulée ou validée
en un seul bloc (propriété d’atomicité de la transaction) à son terme, soit au moment
où l’instruction se termine, soit dans le cas d’une transaction utilisateur, au moment
d’un ROLLBACK TRANSACTION ou d’un COMMIT TRANSACTION. Toute transaction est ainsi
complètement inscrite dans le journal avant même d’être répercutée dans les fichiers
de données. Le journal contient toutes les informations nécessaires pour annuler la
transaction en cas de rollback (ce qui équivaut à défaire pas à pas toutes les modifications), ou pour la rejouer en cas de relance du serveur (ce qui permet de respecter
l’exigence de durabilité de la transaction).
Le mécanisme permettant de respecter toutes les contraintes transactionnelles est le
suivant : lors d’une modification de données (INSERT ou UPDATE), les nouvelles valeurs
sont inscrites dans les pages du cache de données, c’est-à-dire dans la RAM. Seule la
page en cache est modifiée, la page stockée sur le disque restant intacte. La page de cache
est donc marquée « sale » (dirty), pour indiquer qu’elle ne correspond plus à la page originelle. Cette information est consultable à l’aide de la colonne is_modified de la vue de
gestion dynamique (DMV) sys.dm_os_buffer_descriptors :
SELECT * FROM sys.dm_os_buffer_descriptors WHERE is_modified = 1
La transaction validée est également maintenue dans le journal. À intervalle
régulier, un point de contrôle (checkpoint) aussi appelé point de reprise, est inscrit
dans le journal, et les pages modifiées par des transactions validées avant ce checkpoint sont écrites sur le disque.
Les vues de gestion dynamique
À partir de la version 2005 de SQL Server, vous avez à votre disposition, dans le schéma sys,
un certain nombre de vues systèmes qui portent non pas sur les métadonnées de la base en
cours, mais sur l’état actuel du SGBD. Ces vues sont nommées « vues de gestion
dynamique » (dynamic management views, DMV). Elles sont toutes préfixées par dm_. Vous