Améliorations de Log Explorer 3.03

les événements DDL (data
definition language), qu’il reconstruit
en lisant l’activité du journal de transactions
sur des tables système d’une
base de données. La fenêtre View DDL
Commands, que montre la figure 1, révèle
des changements apportés aux
permissions et aux objets système,
comme les tables, vues, fonctions, procédures
stockées, triggers et index.
Vous pouvez aussi filtrer l’affichage
DDL pour ne visualiser que les commandes
qui vous intéressent.

Récupérer les transactions journalisées
contenant des données BLO.
Une autre amélioration est un meilleur support des données BLOB (binary
large object) stockées dans des types
de données text, ntext et image. Log
Explorer prend désormais en charge
tous les changements entièrement
journalisés apportés aux colonnes de
texte et d’image. D’après les Releases
Notes de Log Explorer 3.03, SQL Server
n’enregistre pas toujours les données
BLOB dans le journal des transactions.
Par exemple, SQL Server ne journalise
pas la suppression d’une ligne qui
aboutit à  libérer une page de texte ou
d’image (si la ligne était la seule sur
une page physique), pas plus qu’il ne
journalise la mise à  jour d’une colonne
BLOB. Comme ces opérations ne sont
pas enregistrées dans le journal de
transactions, Log Explorer ne peut pas
créer les scripts permettant de les récupérer.

Recréer le schéma d’une table
abandonnée ou tronquée. Log
Explorer 3.03 peut reconstruire le
schéma pour une table abandonnée et
l’insérer dans le script que l’option
Salvage Dropped/Truncated Table génère.
Dans les releases antérieures, il fallait recréer manuellement la table
avant d’appliquer le script.

Enregistrement du journal de
transactions filtré par index pour
accélérer la navigation. Dans le cas
de grands journaux de transactions,
particulièrement ceux qui recouvrent
de nombreux fichiers, Log Explorer
pourrait être amené à  scanner les données
séquentiellement pour trouver
une certaine transaction. Vous pouvez
diriger Log Explorer pour qu’il
construise un index côté client en mémoire
de votre jeu de résultats filtré sur
le LSN (log sequence number) de la
transaction. Cet index n’existe que
pendant la durée de la session Log
Explorer et seulement dans l’espace
mémoire de l’utilitaire client Log
Explorer.

Journaliser les noms d’utilisateurs
authentifiés par Windows.
Comme SQL Server n’écrit que les
noms de login authentifiés par SQL
Server dans un journal de transactions,
les anciennes releases de Log Explorer
ne pouvaient pas capturer le nom
d’utilisateur authentifié par Windows associé à  une transaction.
Log Explorer affiche désormais
le nom d’utilisateur
Windows NT 4.0 avec les
données d’une transaction
quand vous naviguez dans
un journal. Log Explorer
3.03 communique avec
l’API SQL Trace pour capturer
le nom d’utilitaire NT
d’un SPID (server process
ID), puis le stocke dans
une table appelée LUMIGENT_
PROFILER. Par défaut,
cette table se trouve
dans la base de données
msdb, mais vous pouvez
choisir un autre endroit au
moment de l’installation.
Log Explorer purge automatiquement
de cette
table les lignes qui dépassent
un certain nombre de
jours d’ancienneté (30 jours par défaut).
Vous pouvez configurer cette valeur
avec l’utilitaire Server Manager,
que je décris plus loin.

Utiliser Server Manager pour
contrôler les composants côté serveur.
Malgré son nom, l’utilitaire
Server Manager ne gère pas les serveurs
– simplement les composants
côté serveur de Log Explorer. Le Server
Manager est un utilitaire séparé auquel
on accède par la fenêtre Server
Manager, que montre la figure 2.
Server Manager permet d’inspecter et
de modifier plusieurs paramètres de
registre côté serveur de Log Explorer.
Par exemple, comme le montre la figure
2, vous pouvez contrôler si Log
Explorer capture des noms d’utilisateurs
NT et pendant combien de temps
il conserve les données, en entrant les
paramètres dans la boîte de texte
Session login Information Capture
Mode. Vous pouvez ensuite cliquer sur
Update pour envoyer cette information
au registre pour que le composant
la lise. Dans les anciennes releases
Log Explorer, il fallait utiliser des scripts T-SQL pour définir ces
paramètres.
Server Manager permet
aussi de changer le port que
Log Explorer utilise pour se
connecter à  son composant
de procédure stockée étendue
côté serveur. Tapez le
nouveau
numéro de port dans la boîte
de texte Server Component
Port# et cliquez sur Update
pour écrire le nouveau numéro
de port dans le registre.
La boîte Server Component
en bas de la fenêtre Server
Manager permet de gérer l’information
de registre du composant
serveur de Log
Explorer. L’option Read Registry ordonne
au composant côté serveur de
lire le registre en temps réel (sans vous
obliger à  recharger le composant, ce
qui est bien commode) ; l’option
Reload recharge le composant côté
serveur et l’option Unload décharge le
composant. Si vous déchargez le composant
à  partir d’un serveur, votre utilitaire
Log Explorer ne sera pas capable
de se rattacher aux journaux de transactions
du serveur tant que vous n’aurez
pas rechargé le composant sur un
serveur.

Utiliser Log Explorer avec Datacenter.
Log Explorer 3.03 a la certification
Windows 2000 Datacenter Server,
donc vous pouvez employer l’utilitaire
sur un serveur Datacenter. Cette certification
témoigne que le produit a été
intensivement testé avec Datacenter et
donc qu’il est digne de confiance.

Autres améliorations. Dans Log
Explorer 3.03, vous pouvez restreindre
vos scripts de récupération aux seuls
enregistrements provenant du journal
qui n’ont pas de changements ultérieurs.
Ainsi vous ne gardez que les instructions
DDL les plus courantes. Si
vous possédez Enterprise Edition de
Log Explorer 3.03, l’option d’installation
au niveau entreprise vous permet d’installer le composant côté serveur
sur plusieurs serveurs. La Professional
Edition installe le composant côté serveur
sur un serveur seulement.