18
Chapitre 2. Architecture de SQL Server
mations exploitables. Il est également impossible de récupérer ou annuler une transaction validée à partir du journal. Il est par contre possible de faire des sauvegardes
de journal et de les restaurer à un point dans le temps, annulant ainsi toutes les transactions validées à cet instant.
Le journal de transactions est donc une chaîne séquentielle d’enregistrements de
transactions, comportant toutes les informations nécessaires à une réexécution de la
transaction par le système lors d’une phase de restauration ou de récupération, ainsi
qu’un numéro de séquence d’enregistrement, le log sequence number, ou LSN. Une
restauration de journal peut également être effectuée jusqu’à un LSN. Encore faut-il
savoir quel est le LSN d’une opération recherchée. Nous l’avons dit, le format du
journal n’est pas connu. Il n’y a que deux manières de lire ce journal de transactions :
acheter un logiciel tiers, ou utiliser des instructions SQL Server non documentées.
Affichage du contenu du journal de transactions
Quelques éditeurs, dont le plus connu est Lumigent avec son outil nommé « Log
Explorer », ont déchiffré, avec des méthodes d’ingénierie inverse (reverse engineering), le format du journal, et proposent des outils plus ou moins puissants pour voir
et utiliser le contenu du journal et le détail des opérations effectuées par chaque
transaction.
SQL Server comporte également quelques commandes non documentées – c’està-dire cachées, et susceptibles d’être modifiées ou retirées sans préavis dans des versions suivantes du produit – qui affichent des informations sur le journal. La plus
complète est une fonction système, sys.fn_dblog (ou ::fn_dblog), que vous pouvez
appeler ainsi dans le contexte de la base de données désirée :
SELECT * FROM sys.fn_dblog(DB_ID(),NULL)
Cette vue vous retourne les informations de LSN, le type d’opération effectuée,
l’identifiant de transaction, et plusieurs éléments intéressants comme le nom de
l’unité d’allocation (la table ou l’index affecté), le nombre de verrous posés, etc. Il ne
manque que le détail des modifications, qui pourrait servir à savoir précisément ce
qui s’est produit. Chaque ligne comporte une colonne nommée « Previous LSN »,
qui permet de suivre l’ordre des instructions d’une même transaction. Le type d’instruction est assez clair, comme par exemple LOP_BEGIN_XACT, LOP_MODIFY_ROW et
LOP_COMMIT_XACT.
Cette fonction peut être utile pour obtenir le détail transactionnel d’une opération. Prenons un exemple. Nous chercherons d’abord à obtenir un journal aussi vide
que possible. Nous mettons donc la base de données en mode simple, et nous provoquons manuellement un CHECKPOINT.
ALTER DATABASE AdventureWorks SET RECOVERY SIMPLE;
GO
CHECKPOINT;
Chapitre 2. Architecture de SQL Server
mations exploitables. Il est également impossible de récupérer ou annuler une transaction validée à partir du journal. Il est par contre possible de faire des sauvegardes
de journal et de les restaurer à un point dans le temps, annulant ainsi toutes les transactions validées à cet instant.
Le journal de transactions est donc une chaîne séquentielle d’enregistrements de
transactions, comportant toutes les informations nécessaires à une réexécution de la
transaction par le système lors d’une phase de restauration ou de récupération, ainsi
qu’un numéro de séquence d’enregistrement, le log sequence number, ou LSN. Une
restauration de journal peut également être effectuée jusqu’à un LSN. Encore faut-il
savoir quel est le LSN d’une opération recherchée. Nous l’avons dit, le format du
journal n’est pas connu. Il n’y a que deux manières de lire ce journal de transactions :
acheter un logiciel tiers, ou utiliser des instructions SQL Server non documentées.
Affichage du contenu du journal de transactions
Quelques éditeurs, dont le plus connu est Lumigent avec son outil nommé « Log
Explorer », ont déchiffré, avec des méthodes d’ingénierie inverse (reverse engineering), le format du journal, et proposent des outils plus ou moins puissants pour voir
et utiliser le contenu du journal et le détail des opérations effectuées par chaque
transaction.
SQL Server comporte également quelques commandes non documentées – c’està-dire cachées, et susceptibles d’être modifiées ou retirées sans préavis dans des versions suivantes du produit – qui affichent des informations sur le journal. La plus
complète est une fonction système, sys.fn_dblog (ou ::fn_dblog), que vous pouvez
appeler ainsi dans le contexte de la base de données désirée :
SELECT * FROM sys.fn_dblog(DB_ID(),NULL)
Cette vue vous retourne les informations de LSN, le type d’opération effectuée,
l’identifiant de transaction, et plusieurs éléments intéressants comme le nom de
l’unité d’allocation (la table ou l’index affecté), le nombre de verrous posés, etc. Il ne
manque que le détail des modifications, qui pourrait servir à savoir précisément ce
qui s’est produit. Chaque ligne comporte une colonne nommée « Previous LSN »,
qui permet de suivre l’ordre des instructions d’une même transaction. Le type d’instruction est assez clair, comme par exemple LOP_BEGIN_XACT, LOP_MODIFY_ROW et
LOP_COMMIT_XACT.
Cette fonction peut être utile pour obtenir le détail transactionnel d’une opération. Prenons un exemple. Nous chercherons d’abord à obtenir un journal aussi vide
que possible. Nous mettons donc la base de données en mode simple, et nous provoquons manuellement un CHECKPOINT.
ALTER DATABASE AdventureWorks SET RECOVERY SIMPLE;
GO
CHECKPOINT;