> Tech > La procédure cataloguée de début de trace

La procédure cataloguée de début de trace

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Analysons ces deux procédures cataloguées pour voir de quelle manière elles utilisent les procédures cataloguées étendues pour la trace. La procédure cataloguée permettant de démarrer une trace, sp_start_mytrace, possède quatre paramètres optionnels en entrée. Les deux premiers, @spid_filter et @dbid_filter, permettent de limiter le suivi à  des filtres sur le

La procédure cataloguée de début de trace

SPID et l’ID base de données spécifiés. Si on ne
précise pas ces paramètres, la trace capture les événements relatifs à  tous les
SPID et ID base de données. Le paramètre @email_address permet de définir une
adresse e-mail à  laquelle la procédure cataloguée envoie un message détaillé de
suivi lorsqu’elle démarre la trace. Si on ne spécifie pas ce paramètre, sp_start_mytrace
envoie le message uniquement à  l’écran. Si on précise ce paramètre mais que le
profil e-mail défini sur le serveur n’est pas valide, la procédure cataloguée
envoie un message d’erreur et s’arrête. Le dernier paramètre en entrée, @filename,
permet de définir un nom de fichier de destination pour la trace. Si on omet ce
paramètre, la procédure cataloguée génère un nom de fichier de destination, ‘c:\mytraceN.trc’,
où N désigne le numéro de handle de file d’attente. Cette convention de nommage
des noms de fichiers permet d’exécuter plusieurs traces en même temps sans que
l’une ne verrouille le fichier lors de son utilisation.

Pour commencer, la procédure sp_start_mytrace appelle la procédure cataloguée
étendue xp_trace_addnewqueue pour créer la file d’attente d’événements. Les quatre
premiers paramètres de Addnewqueue (parameters-max_items, timeout, thread_boost,
et thread_reduce) sont définis avec leurs valeurs par défaut. (L’article « Comment
suivre un événement à  la trace avec SQL Server Profiler » explique ces paramètres
de gestion des files d’attente d’événements.) Le paramètre required_columns de
la procédure est un bitmask des colonnes de données à  capturer. Pour générer ce
masque, il faut une opération OU logique (|) entre les valeurs entières représentant
chaque colonne de données. Le paramètre de sortie, queue_handle, enregistre le
handle de file d’attente pour un usage ultérieur.

Sp_start_mytrace appelle ensuite la procédure cataloguée étendue xp_trace_seteventclassrequired
pour chaque événement qu’on souhaite capturer dans la trace. Seteventclassrequired
possède trois paramètres. Queue-handle est le handle de file d’attente obtenu
par la procédure cataloguée xp_trace_addnewqueue. Event_class est une valeur entière
représentant l’événement à  capturer (on exécute la procédure cataloguée étendue
xp_trace_geteventnames pour obtenir la liste complète des classes des événements
et leurs noms. Cet exemple utilise les classes d’événements par défaut de Profiler.)
Enfin, Isrequired est une valeur booléenne déterminant si il faut inclure l’événement
dans la trace.

Après avoir sélectionné les événements à  capturer, il faut définir les filtres
d’événements. Par défaut, la définition de suivi filtre les événements générés
par Profiler. Cependant, si on souhaite en savoir plus sur les procédures cataloguées
étendues de suivi de SQL Server 7.0, les procédures utilisées par Profiler pour
réaliser les traces, il peut être intéressant de remplacer le filtre de Profiler
d’exclusion par le filtre d’inclusion. Démarrez la trace, puis démarrez une autre
trace de votre choix pour voir les procédures cataloguées étendues utilisées par
Profiler pour mettre en oeuvre la seconde trace.

Chaque catégorie de filtre présente une procédure cataloguée étendue différente,
mais elles suivent toutes le modèle xp_trace_set*filter. La procédure cataloguée
sp_start_mytrace utilise xp_trace_setappfilter pour exclure les événements générés
par Profiler. Si l’utilisateur demande des filtres sur le SPID ou l’ID base de
données, sp_start_mytrace utilise xp_trace_setspid-filter or xp_trace_setdbidfilter.

Ensuite, sp_start_mytrace indique la destination de sortie de la file d’attente.
Bien que l’on puisse disposer de plusieurs destinations de sortie pour une file
d’attente, on ne peut pas avoir plusieurs destinations pour un type de sortie.
On peut par exemple effectuer une sortie simultanée vers un fichier et une table,
mais on ne peut pas le faire vers deux fichiers. Sp_start_mytrace appelle xp_trace_setqueuedestination
pour spécifier la destination de la sortie. Pour sélectionner plusieurs destinations,
il suffit de répéter l’appel de la procédure cataloguée étendue. Les paramètres
de Setqueuedestination (hormis queue_handle) sont :

· destination : fichier (1), historique de l’application NT (2), table (3), serveur
de transfert (4)
· valeur : destination activée (1), destination désactivée (0)
· ‘server’ : nom du serveur, si on souhaite envoyer la sortie vers un autre serveur
(ce dernier doit être enregistré) ou NULL si vous ne voulez pas transférer les
événements vers un autre serveur
· ‘object’ : nom du fichier ou de la table (si on spécifie un paramètre de destination
de 1 ou 3 respectivement). Si l’objet existe, la procédure y ajoute des événements
; dans le cas contraire, la procédure crée l’objet.

Sp_start_mytrace envoie la sortie de la trace vers un nom de fichier spécifié
dans le paramètre @filename sur le serveur local.

Téléchargez cette ressource

Percer le brouillard des rançongiciels

Percer le brouillard des rançongiciels

Explorez les méandres d’une investigation de ransomware, avec les experts de Palo Alto Networks et Unit 42 pour faire la lumière dans la nébuleuse des rançongiciels. Plongez au cœur de l’enquête pour comprendre les méthodes, les outils et les tactiques utilisés par les acteurs de la menace. Découvrez comment prévenir les attaques, les contrer et minimiser leur impact. Des enseignements indispensables aux équipes cyber.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010

A lire aussi sur le site

Revue Smart DSI

La Revue du Décideur IT