19
2.2 Structures de stockage
SQL Server 2008 – En SQL Server 2005, nous pouvons aussi lancer la commande BACKUP
LOG AdventureWorks WITH TRUNCATE_ONLY; pour vider manuellement le journal. Cette
commande n’est plus prise en charge dans SQL Server 2008.
En exécutant la fonction fn_dblog(), nous constatons que le journal est pratiquement vide. Effectuons une modification simple dans la table Sales.Currency, qui
contient les références de devises :
UPDATE Sales.Currency
SET Name = Name
WHERE CurrencyCode = 'ALL'
La modification demandée ne réalise aucun changement. SQL Server va-t-il tout
de même faire un UPDATE ? Grâce à fn_dblog() nous constatons que non. Une seule
opération est journalisée, de type LOP_SET_BITS, une mise à jour des informations
d’une page, pas de son contenu.
Essayons maintenant de réellement changer quelque chose :
UPDATE Sales.Currency
SET Name = 'Lek2'
WHERE CurrencyCode = 'ALL'
Les opérations du tableau 2.1 sont inscrites dans le journal.
Tableau 2.1 — Opérations inscrites dans le journal
Ici les opérations sont claires : modification de la ligne (LOP_MODIFY_ROW sur
l’index clustered, donc sur la table), et ensuite opération de suppression puis d’insertion dans l’index AK_Currency_Name, qui contient la colonne modifiée dans sa clé.
Vous verrez parfois l’UPDATE journalisé non comme un LOP_MODIFY_ROW, mais
comme un couple de LOP_DELETE_ROWS et LOP_INSERT_ROWS, car SQL Server gère deux
Operation
Context
AllocUnitName
LOP_BEGIN_XACT
LCX_NULL
NULL
LOP_MODIFY_ROW
LCX_CLUSTERED
Sales.Currency.PK_
Currency_CurrencyCode
LOP_SET_BITS
LCX_DIFF_MAP
Unknown Alloc Unit
LOP_DELETE_ROWS
LCX_MARK_AS_GHOST
Sales.Currency.AK_
Currency_Name
LOP_SET_BITS
LCX_PFS
Sales.Currency.AK_
Currency_Name
LOP_INSERT_ROWS
LCX_INDEX_LEAF
Sales.Currency.AK_
Currency_Name
LOP_COMMIT_XACT
LCX_NULL
NULL
2.2 Structures de stockage
SQL Server 2008 – En SQL Server 2005, nous pouvons aussi lancer la commande BACKUP
LOG AdventureWorks WITH TRUNCATE_ONLY; pour vider manuellement le journal. Cette
commande n’est plus prise en charge dans SQL Server 2008.
En exécutant la fonction fn_dblog(), nous constatons que le journal est pratiquement vide. Effectuons une modification simple dans la table Sales.Currency, qui
contient les références de devises :
UPDATE Sales.Currency
SET Name = Name
WHERE CurrencyCode = 'ALL'
La modification demandée ne réalise aucun changement. SQL Server va-t-il tout
de même faire un UPDATE ? Grâce à fn_dblog() nous constatons que non. Une seule
opération est journalisée, de type LOP_SET_BITS, une mise à jour des informations
d’une page, pas de son contenu.
Essayons maintenant de réellement changer quelque chose :
UPDATE Sales.Currency
SET Name = 'Lek2'
WHERE CurrencyCode = 'ALL'
Les opérations du tableau 2.1 sont inscrites dans le journal.
Tableau 2.1 — Opérations inscrites dans le journal
Ici les opérations sont claires : modification de la ligne (LOP_MODIFY_ROW sur
l’index clustered, donc sur la table), et ensuite opération de suppression puis d’insertion dans l’index AK_Currency_Name, qui contient la colonne modifiée dans sa clé.
Vous verrez parfois l’UPDATE journalisé non comme un LOP_MODIFY_ROW, mais
comme un couple de LOP_DELETE_ROWS et LOP_INSERT_ROWS, car SQL Server gère deux
Operation
Context
AllocUnitName
LOP_BEGIN_XACT
LCX_NULL
NULL
LOP_MODIFY_ROW
LCX_CLUSTERED
Sales.Currency.PK_
Currency_CurrencyCode
LOP_SET_BITS
LCX_DIFF_MAP
Unknown Alloc Unit
LOP_DELETE_ROWS
LCX_MARK_AS_GHOST
Sales.Currency.AK_
Currency_Name
LOP_SET_BITS
LCX_PFS
Sales.Currency.AK_
Currency_Name
LOP_INSERT_ROWS
LCX_INDEX_LEAF
Sales.Currency.AK_
Currency_Name
LOP_COMMIT_XACT
LCX_NULL
NULL
