Elle capture, entre autres, les événements d’échec d’authentification, la création d’objets dans TempDB, les warnings sur Hash et Sort, les grossissements de fichiers, et de nombreux autres événements. Ceux-ci peuvent aider à comprendre, a posteriori, ce qui a causé une grande consommation de CPU, des latences disque, …

Comme cette trace est écrite sur disque, il peut malencontreusement arriver que ce dernier devienne plein, provoquant alors l’arrêt automatique et forcé de la trace. Ce léger incident (l’arrêt de la trace, pas l’absence d’espace disque libre !) n’empêche aucunement l’instance de fonctionner, ou au moins d’être accessible. Cependant, comment peut-on redémarrer cette trace sans redémarrer l’instance SQL Server ?

En effet, la documentation nous indique que la trace par défaut n’est démarrée que lorsque l’instance démarre aussi … nous allons voir que c’est incomplet. Une fois le disque supportant la trace disposant à nouveau d’espace disque libre, on constate que la trace par défaut est arrêtée à l’aide de l’instruction suivante :

Lorsque la trace par défaut est active, cette requête retourne une ligne, dont la colonne id est à 1. On peut vérifier que c’est la trace par défaut à l’aide de la valeur de la colonne is_default : 1 si c’est le cas, 0 à l’inverse :

Dans la situation de l’incident que nous évoquons, cette même requête ne retournera pas de ligne (ou tout du moins aucune dont la colonne is_default est à 1). Pour démarrer la trace par défaut, il suffit de s’en remettre à l’option de configuration d’instance default trace enabled :

On voit que c’est une option avancée et dynamique, ce qui signifie qu’un redémarrage de l’instance SQL Server n’est pas nécessaire. Dès lors, pour réactiver la trace par défaut, il suffit de positionner cette option à 0, puis immédiatement ensuite à 1, ce qui est sa valeur par défaut :

Sur exécution de ce lot, l’onglet Messages du panneau de résultats de SQL Server Management Studio affiche :

Configuration option ‘show advanced options’ changed from 0 to 1. Run the RECONFIGURE statement to install.
Configuration option ‘default trace enabled’ changed from 1 to 0. Run the RECONFIGURE statement to install.
Configuration option ‘default trace enabled’ changed from 0 to 1. Run the RECONFIGURE statement to install.
Configuration option ‘show advanced options’ changed from 1 to 0. Run the RECONFIGURE statement to install.

Et l’on voit alors que la trace a été démarrée, en interrogeant une nouvelle fois la vue sys.traces.
On trouvera aussi dans les journal de SQL Server les lignes suivantes :

Ici on voit bien que la trace par défaut a été démarré par le système (le SPID est inférieur à 50), quelques millisecondes après le démarrage de celui-ci. Elle a ensuite été redémarrée par nos soins un peu plus tard.

Petite note finale : les fonctionnalités SQL Trace et SQL Profiler sont obsolètes, et remplacées par la fonctionnalité d'événements étendus, plus puissante et performante. Vous pouvez voir comment les utiliser dans cette vidéo, en gardant bien à l’esprit que dès SQL Server 2012, une interface graphique intégrée à SQL Server Management Studio permet de créer une session sans écrire de code, et de visualiser les événements capturés à la façon de ce que permet SQL Profiler.

Enfin, pour interroger un fichier de trace SQL Profiler, il suffit d’utiliser la fonction sys.fn_trace_gettable(). Donc pour en faire l’analyse, on peut utiliser le lot suivant :

Alors bon traçage à tous !

Introduite avec SQL Server 2014, la vue de gestion dynamique sys.dm_exec_query_profiles nous permet de voir quel(s) nœud(s) d’un plan d’exécution réel consomme le plus de ressources et /ou de temps. C’est donc un formidable outil qui peut faire largement diminuer la recherche des points noueux d’une requête à l’étude.

La documentation de cette DMV montre qu’elle expose de nombreuses colonnes, qui nous renseignent de façon très précise sur la consommation de ressources physiques de chaque opérateur du plan de requête, notamment avec le nombre de millisecondes après lequel un opérateur s’est exécuté pour la première et la dernière fois. Pour simplifier l’analyse des requêtes, on peut s’en tenir à quelques unes d’entre-elles, comme dans la requête suivante :

La colonne node_id nous donne le numéro de l’opérateur dans le plan de requête. Il faut noter que l’opérateur racine de l’arbre de résolution qu’est le plan de requête, et qui se situe en haut et à gauche dans le plan d’exécution graphique, est le seul dans tout plan à ne pas porter de NodeID. L’opérateur qui le précède porte le NodeID 0, et celui qui précède ce dernier le NodeID 1, et ainsi de suite. Le plus grand numéro de NodeID est à l’opérateur qui est le plus à droite et en bas du plan d’exécution graphique.

La colonne session_id va nous permettre de spécifier sur quelle session porte notre étude : pour que cette vue expose des lignes, il est nécessaire que l’option de session SET STATISTICS XML soit positionnée à ON pour la requête à étudier. Ceci équivaut à l’activation de l’option d’inclusion du plan d’exécution réel dans la barre d’outil de SQL Server Management Studio (SSMS) avant l’exécution d’une requête. Ceci est normal, puisque comme pour toutes les tâches de monitoring, elle viennent avec un coût : celui-ci pourrait devenir trop élevé si toutes les requêtes étaient auditées à ce niveau de détail, d’autant que ce type d’information est utilisé par les DBAs, et pas par les applications qui interagissent avec la base de données.

Supposons que la requête (très simple) que l’on souhaite étudier est la suivante :

On peut récupérer le session_id de plusieurs manières :

• Il est indiqué dans la barre d’état de toute fenêtre de requête sous SSMS, en bas à droite;
• Si l’on a conservé les options par défaut de SSMS, il est aussi indiqué sur l’onglet de la fenêtre de requête;
• On peut exécuter SELECT @@SPID dans la même fenêtre de requête que celle à étudier.

Ne soyez pas perturbé par l’option de session SET STATISTICS IO, TIME ON positionné juste avant la requête : je l’utilise toujours pour diagnostiquer une requête, car cela expose le temps CPU, la durée totale, et surtout, le nombre d’IOs produit par la requête pour chaque table participant à celle-ci. On peut adjoindre l’option XML à la liste IO, TIME si on le souhaite.

Les lecteurs aux yeux affûtés auront remarqué que dans la capture d’écran ci-dessus, il y a un deuxième onglet ouvert : en effet, on doit utiliser une fenêtre de requête pour celle à étudier, et une autre pour lire la sortie de la vue sys.dm_exec_query_profiles pour cette session. Pour cet exemple, on peut reprendre la première requête, et rajouter la clause WHERE adéquate : la session qui va exécuter la requête à l’étude porte le session_id 51 :

L’exercice consiste donc à démarrer l’exécution de la requête à l’étude, puis à basculer vers la fenêtre de requête qui spécifie la vue sys.dm_exec_query_profiles avant la fin de l’exécution de la requête à l’étude. Pour la requête de cet exemple, cela nous donne :

On constate ainsi des écarts importants entre le nombre de lignes estimé et réel pour les opérateurs dont le NodeID est 0 et 4, mais il y a un problème : alors que la somme des valeurs de la colonne elapsed_time_ms nous donne 15, la sortie dans l’onglet Messages est la suivante (légèrement écourtée, notamment les IOs physiques et de LOBs, pour les besoins de l’article) :

(29382 row(s) affected)
Table ‘Workfile’. Scan count 0, logical reads 0
Table ‘Worktable’. Scan count 0, logical reads 0
Table ‘SalesOrderDetail’. Scan count 1, logical reads 1246
Table ‘Product’. Scan count 1, logical reads 15

SQL Server Execution Times:
CPU time = 156 ms, elapsed time = 1225 ms.

Il y a bien sûr le temps de consommation du jeu de lignes de résultat par SSMS. On peut le confirmer en éliminant le résultat une fois la requête exécutée : pour ce faire, il suffit de faire un clic-droit dans un zone vierge de la requête > Query options … > Results / Grid > et de cocher la case Discard results after execution.

La question qui vient maintenant est : comment faire pour les requêtes dont l’exécution est bien plus longue ? Et dans tous les cas, la durée d’exécution des requêtes n’étant pas précisément prédictible même après une ou deux exécutions, comment capturer les valeurs qu’expose cette DMV en s’approchant le plus possible de la fin de la requête ? On peut pour cela écrire une boucle qui va stocker le contenu de la DMV à intervalles réguliers et fréquents, et qui vérifie à chaque tour que la requête est toujours en cours d’exécution :

Ici on stocke le contenu de la DMV toutes les 10 ms. Le délai entre chaque boucle peut être adapté : si l’on sait que la requête dure environ quart d’heure, une récupération du contenu de la vue toutes les secondes est suffisante. Cette valeur peut donc être adaptée suivant la durée d’exécution globale de la requête. Il faut aussi veiller à exécuter ce lot de requêtes dans le même contexte de base de données que celui sous lequel on exécute la requête à étudier. En effet, cela permet d’obtenir le nom de l’objet de base de données accédé :

On constate dans la sortie du lot de requêtes interrogeant la DMV que, par exemple, l’opérateur de NodeID 4 est l’accès à l’index cluster de la table SalesOrderDetail, et qu’il a traité 121317 lignes. Voyons si cela est reflété par le plan d’exécution réel graphique de la requête :

Le numéro de NodeID 4 est bien l’opérateur exposé par la DMV, et si l’on lit la ligne de la bulle dont le libellé est Actual number of rows, on a bien 121317.

Pour l’étude des requêtes plus lourdes, la DMV sys.dm_exec_query_profiles nous permettra de repérer immédiatement les opérateurs les plus consommateurs de ressources, et donc de travailler directement sur ceux-ci en se reportant au plan de requête, puis à la requête elle-même pour en revoir l’écriture et éventuellement l’indexation.

Bonne optimisation !

Cet identifiant numérique est constitué de 14 chiffres, et est articulé en trois parties :

• le SIREN
• le Numéro Interne de Classement, à quatre chiffres : c’est l’ordre de création de l’établissement par l’entreprise Française
• une clé de contrôle, constituée d’un seul chiffre

Ce dernier est calculé à l’aide de l’algorithme de Luhn. Cet algorithme est aussi utilisé pour valider les numéros de carte bleue, et de nombreux identifiants distribués par les administrations de beaucoup de pays. Nous allons nous en servir pour vérifier la validité de SIRETs en l’implémentant spécifiquement pour ce type d’identifiant.

L’algorithme est descriptible comme suit :

1. Pour chaque chiffre dont l’index dans la chaîne est impair, on le multiplie par 2; si le résultat est supérieur à 9, on additionne les chiffes qui constituent ce résultat. Ceci revient à multiplier par 2 le chiffre, diviser le résultat par 10, puis ajouter la multiplication par 2 de ce même chiffre modulo 10.
2. On additionne ensuite les chiffres du résultat un à un, avec les chiffres de l’identifiant qui n’ont pas été traités, c’est à dire ceux dont l’index dans la chaîne est pair. Ceci inclut le chiffre de l’identifiant qui est clé.
3. Si le résultat obtenu est un multiple de 10, alors l’identifiant est valide. Ceci revient à vérifier que le résultat modulo 10 vaut zéro.

La traduction en SQL donne :

On peut l'utiliser directement dans une vue, comme dans le pseudo code suivant :

Si l'on souhaite l'utiliser en colonne calculée, on peut utiliser ce CASE directement dans la définition de ladite colonne, ou bien définir une fonction scalaire comme suit :

Et en ce qui concerne la création de la colonne calculée, on peut l'ajouter à l'aide du pseudo-T-SQL suivant :

Enfin, si l'on souhaite exécuter cette vérification au sein d'une requête, on peut s'en remettre à une fonction de table en ligne. Ce type de fonction n'étant appelé qu'une seule fois, il s'avérera plus performant à l'exécution sur un grand nombre de lignes que l'appel à une fonction scalaire : ces dernières sont appelées autant de fois qu'il y a de lignes de résultat. Ce qui donne :

On peut alors l'utiliser à l'aide de l'opérateur APPLY, comme dans l'exemple suivant :

Bonne validation de SIRETs !

• On ne dispose pas de l’Agent SQL Server
• On ne peut pas utiliser des plans de maintenance pour gérer les sauvegardes
• On ne peut pas envoyer d’emails
• La compression des fichiers de backup, introduite avec SQL Server 2008, n’est pas prise en charge

Si donc on souhaite planifier les sauvegardes de base de données, et envoyer un email en cas d’échec, on peut :

• Remplacer un job de l’Agent SQL Server par une tâche du Planificateur de Tâches de Windows
• Écrire une procédure stockée d’assembly pour envoyer des emails

Cet article détaille les étapes à suivre pour ce faire.

Une procédure stockée d’assembly pour envoyer des emails

Si l’Agent SQL Server n’est pas disponible, l’intégration CLR l’est. Ainsi en quelques lignes de code C#, on peut envoyer des e-mails de façon assez similaire à ce qu’on peut faire sous les éditions non-Express de SQL Server avec la procédure stockée système msdb.dbo.sp_send_dbmail.

Pour créer une procédure stockée d’assembly sous Visual Studio 2012 ou ultérieur, il faut tout d’abord installer SQL Server Data Tools. Pour ce faire, vous pouvez lire ce billet. Notez qu’il n’est pas nécessaire d’avoir Visual Studio déjà installé.

Une fois Visual Studio démarré, il suffit de créer un nouveau projet à partir de la page de démarrage, ou bien de suivre File > New > Project, et de choisir un projet SQL Server :

Il faut faire attention à la version du framework .NET. Par exemple, si l’on souhaite que l’assembly soit exécutable par SQL Server 2008, il faut spécifier la version 3.5. Une fois que l’on a validé le tout par OK, nous pouvons ajouter une procédure stockée :

Comme je préfère C# à VB.NET, j’ai choisi une procédure stockée C#, mais si vous préférez VB.NET, rien ne s’y oppose. Notons que par défaut, le langage de la procédure stockée n’est pas pré-sélectionné.

Une fois que l’on a validé le tout par un clic sur Add, on peut écrire :

Ce qui, même pour l’ultra-débutant C# que je suis, est loin d’être complexe. Avant de builder le projet, il nous faut configurer l’assembly pour lui permettre d’accéder à des ressources externes, ce qui se fait après un clic-droit sur le projet, et choisi Properties (ou pour les aficionados du raccourci clavier, ALT + Entrée). Dans la page SQLCLR, nous commutons donc la liste déroulante Permission Level sur EXTERNAL_ACCESS. De la même façon, dans la page SQLCLR Build, nous commutons la liste déroulante Configuration sur Release, ce qui permet un léger gain de performances. Ce n’est pas très important dans notre cas, mais si l’assembly est plus complexe, cela peut le devenir.

Après un clic sur Build > Build Solution, nous pouvons aller chercher le fichier dll dans le dossier de la solution. Dans cet exemple, il s’agit de D:\SQLServer\Assemblies\SQLServerExpressDatabaseMail\SQLServerExpressDatabaseMail\bin\Debug, et le fichier est nommé SQLServerExpressDatabaseMail.dll.

De retour dans SQL Server Management Studio, une fois connecté à l’instance SQL Server Express, il est tout d’abord nécessaire d’activer la prise en charge de la CLR par cette dernière. Cela se fait sans redémarrage de l’instance, en quelques instruction :

Il est maintenant requis de déclarer la base de données dans laquelle nous allons enregistrer la procédure stockée d’assembly comme « digne de confiance ». Ceci nous permet d’emprunter l’identité de SQL Server pour exécuter cette procédure qui va accéder à des ressources en dehors de la base de données : en l’occurrence, un serveur de mails (mais ce peut être le système de fichiers, un webservice, …). Là encore, une simple commande suffit :

Nous devons maintenant enregistrer l’assembly dans la base de données, ce que l’on peut faire une fois que l’on a copié l’assembly dans un dossier de notre choix, sur le serveur hébergeant l’instance SQL Server Express / WSUS. Dans cet exemple, nous utilisons le dossier C:\SQLServer\.

On peut vérifier l’enregistrement de l’assembly en interrogeant la vue système sys.assemblies. En ce point, on n’a plus besoin du fichier dll : le binaire de celle-ci est maintenant enregistré dans la base de données (de nom DBA dans cet exemple).
Créons maintenant la procédure stockée :

Et testons enfin :

Une procédure stockée pour gérer les sauvegardes

Voici une procédure stockée générique qui permet de sauvegarder une base de données en particulier, ou toutes les bases de données hébergées par une instance SQL Server. Dans le second cas, les sauvegardes du fichier du journal des transactions n’est pas supportée. En revanche, on peut exécuter cette procédure stockée sur toutes les versions de SQL Server, à partir de 2005. Enfin, le cryptage des sauvegardes, introduit avec SQL Server 2014 n’est pas supporté non plus. Cela exige que quelques prérequis soient en place, et ceux-là sortent du cadre de cet article.

La procédure stockée d’assembly est référencée dans le bloc CATCH final : pour toute erreur, on envoie un email.

Remplacer l’Agent SQL Server par le Planificateur de Tâches de Windows

Nous voilà à l’étape finale : prendre des sauvegardes de base de données régulièrement. Pour ce faire, on peut tout à fait utiliser le Planificateur de Tâches de Windows : en effet, on peut appeler l’utilitaire en ligne de commandes SQLCMD (la documentation, l’utilisation, et un exemple), qui permet d’interagir avec une instance SQL Server. Cet outil permet de passer en paramètre un script, d’exécuter une requête, mais surtout d’enregistrer la sortie dans un fichier. Cette dernière fonctionnalité facilite la tâche d’investigation sur l’échec d’exécution de code.

Une fois l’application Planificateur de Tâches démarrée, on créé une tâche assez simplement :

Une fois passé la première page ou nous nommons la tâche, un clic sur Next nous amène à la planification. Pour Windows Server Update Services, on peut estimer qu’une sauvegarde complète par jour est suffisante. Évidemment, cela varie avec la criticité de l’application. Nous spécifions donc une exécution quotidienne :

Nous planifions l’exécution à minuit et une minute :

Et nous choisissons de démarrer une application :

Dans la saisie texte Program / Script, nous spécifions l’invite de commandes. En ce qui concerne les arguments, nous écrivons :

• Pour SQL Server 2008 :
  "C:\Program Files\Microsoft SQL Server\100\Tools\Binn\SQLCMD.EXE"
• Pour SQL Server 2012 :
  "C:\Program Files\Microsoft SQL Server\110\Tools\Binn\SQLCMD.EXE"
• Pour SQL Server 2014 :
  "C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn\SQLCMD.EXE"

En ce qui concerne les arguments, nous passons :

sqlcmd -E -S WSUS -i "C:\SQLServer\WSUSBackup.sql" -o "C:\SQLServerBackup\FullBackupLog.txt"

Attention, la casse des options est importante.

• -E pour spécifier une connexion approuvée
• -S : l’instance SQL Server à laquelle on souhaite se connecter
• -i : le chemin et le nom du fichier de script T-SQL
• -o : le fichier qui capturera les libellés des messages d’information, d’avertissement ou d’erreurs, le cas échéant

Ce qui donne :

Un clic sur Next nous offre une fenêtre de résumé, et on peut valider le tout. Si l’on souhaite ajouter des planifications ou modifier d’autres options pour cette tâche, il suffit de cocher la case Open the Properties dialog for this task when I click Finish.

Nous créons ensuite un fichier WSUSBackup.sql dans un répertoire C:\SQLServer\ sur la machine qui héberge l’application WSUS. Ce fichier appelle la procédure stockée DBA.dbo.databaseBackup_manage comme suit :

EXEC DBA.dbo.databaseBackup_manage 'FULL', NULL, '\\monPartageDeBackup\', 0

Et voilà nos sauvegardes de base de données en place.

Utiliser PowerShell pour supprimer les fichiers de sauvegardes trop anciens

Dans la liste des actions de la tâche que nous venons de créer, nous pouvons en ajouter une qui aura :

• Pour programme : powershell
• Pour arguments : -file "C:\SQLServer\DeleteOldBackupFiles.ps1"

Le fichier DeleteOldBackupFiles.ps1 contient la commande suivante, qui supprime tous les fichiers créés il y a plus de 7 jours, y compris dans les sous-dossiers du partage de backup (-Recurse) :

Get-ChildItem '\\monPartageDeBackup\' -Recurse | Where {$_.CreationTime -lt (Get-Date).AddDays(-7)} | Remove-Item -Force

Par défaut, PowerShell ne permet pas l’exécution de scripts. Pour l’autoriser, il faut démarrer l’interface PowerShell, et exécuter Set-ExecutionPolicy RemoteSigned (en accord avec votre Administrateur Systèmes !).

Retenons également que les statistiques de colonne et d’index de la base de données supportant WSUS ne sont pas maintenues. Ce sera probablement suffisant pour générer une lenteur après quelques mois d’exploitation, dont votre Administrateur Systèmes vous demandera l’origine

ElSüket.

Dans cet article, je vous propose de voir comment paramétrer SQL Server pour capturer cet évènement, puis de vous aider à interpréter le document XML qui décrit la situation de blocage.

Toute exécution de requête résulte en l’acquisition de verrous, dont la granularité (ligne, page, clé, partition, table, base de données, ou encore et plus rarement compilation) et le mode (partagé, exclusif, de mise à jour, ou d’intention) varient. Le verrouillage de ressources est une opération de base pour le moteur de stockage de tout moteur de bases de données SQL, qui garantit l’intégrité de la base de données à travers toutes les opérations de manipulation de données que celle-ci supporte. Cependant, il arrive que lorsqu’un processus a posé un verrou sur une ressource, d’autres processus doivent simultanément accéder à cette même ressource : ces processus sont alors bloqués. Comme il est possible que le processus bloquant ne libère ledit verrou qu’après une durée relativement longue, les effets possibles d’une telle situation sur nos applications peuvent aller de requêtes dont la durée d’exécution est élevée jusqu’à l’expiration du délai d’attente d’une réponse pour l’exécution d’un requête : le fameux timeout.

Il est néanmoins possible, à l’aide d’une trace SQL Profiler ou des Évènements Étendus, de capturer ces situations, qui sont décrites par un document XML.

Configurer l’instance SQL Server

Le seuil de durée de blocage à partir de laquelle on souhaite capturer un tel évènement est configurable à l’aide de l’option d’instance blocked process threshold. On accède à ce paramètre :

– soit à l’aide de SQL Server Management Studio (SSMS), après un clic-droit sur l’instance dans l’Explorateur d’Objets (F8), et avoir choisi l’option Propriétés :

– soit à l’aide de la procédure stockée système sp_configure :

La console de SSMS affiche, à l’exécution de ce lot de requêtes :

Veillez à ne pas mettre un seuil trop bas : sans cela, on aurait le processus d’arrière plan LOCK MONITOR qui s’exécuterait constamment. Or ce dernier, qui est aussi en charge de détecter les deadlocks, est gourmand en ressources CPU. En s’exécutant fréquemment, il pourrait donc impacter négativement les performances générales de l’instance SQL Server. D’un autre côté, 5 secondes est une durée très longue sur une base de données qui supporte une charge de travail OLTP conséquente. On trouve ce processus avec la requête suivante :

Si l’on exécute maintenant cette requête de façon répétée, on voit que la valeur de la colonne wait_time croit jusqu’à atteindre 5000, mais ne dépasse jamais cette valeur : cette colonne affiche sa valeur en millisecondes, et montre bien que le processus cherche les processus bloqués toutes les 5 secondes.

Il faut aussi noter qu’avec cette configuration, si un processus reste bloqué 15 secondes, l’évènement sera généré 3 fois pour la même situation de blocage.

Capture avec SQL Profiler

Une fois cela fait, nous démarrons SQL Profiler, et dans l’onglet de sélection des évènements, dans la catégorie Errors and Warnings (et non pas dans la catégorie Locks), nous trouvons l’évènement Blocked process report :

Nous configurons l’évènement comme suit, où le champ TextData contiendra le document XML décrivant la situation de blocage :

N.B. : N’oubliez pas le champ Mode, qui procure le type de verrou acquis.

Capture avec les Évènements Étendus (XE)

Pour les lecteurs qui n’ont pas encore eu le temps de se familiariser avec cette fonctionnalité, qui est vouée au remplacement futur de SQL Profiler, et dont la puissance en fait mon outil de diagnostic favori, vous pouvez vous aider de l’article que j’ai publié sur le sujet.

Si l’on souhaite capturer en permanence toute situation de blocage, l’avantage revient à XE, puisqu’on peut stocker ces évènements dans une cible dite anneau de mémoire (ring buffer). Cette structure consomme très peu de mémoire et fonctionne à l’image d’un FIFO : lorsqu’il est plein, la capture d’un nouvel évènement donne lieu à l’éviction du plus vieil évènement pour le stockage de celui-ci. Avec SQL Profiler, il est nécessaire de mettre en place une trace côté serveur et de gérer le fichier de trace et l’espace disque. En revanche, une fois que l’on a démarré la session XE, on peut « l’oublier ».

Pour les lecteurs familiers de XE et de Profiler, sachez que le document XML produit par ces deux fonctionnalités pour un même évènement de blocage est identique, ce qui n’est pas le cas avec les deadlocks (XE produit un document XML mal formé, qui rend impossible son enregistrement en document de type .xdl en vue de son interprétation graphique dans SSMS).

La définition d’une telle session est simple :

Le test

Pour l’exemple, nous avons la trace SQL Profiler et la session XE ci-dessus actifs.
Nous créons la table suivante :

Puis, dans une première fenêtre de requête (A) sous SSMS, nous ajoutons la ligne suivante, sans valider la transaction :

Dans une seconde fenêtre de requête (B), nous exécutons :

Ceci fait que la requête B doit attendre que la requête A soit terminée pour réaliser l’UPDATE, ce qui ne peut se faire que si l’on valide (COMMIT) ou annule (ROLLBACK) la transaction : nous ne le faisons pas ici, pour l’exemple. Nous laissons aussi la requête B s’exécuter 10 secondes, de façon à bien voir que l’évènement est capturé deux fois pour la même situation de blocage.

Ce que capture SQL Profiler

L’interface affiche bien deux captures de l’évènement :

Notez que les valeurs pour la colonne Duration sont données ici en microsecondes : on voit donc qu’il y a un léger décalage entre la détection du blocage et sa capture. Toutes les informations dont nous avons besoin sont donc sous nos yeux: la ressource à la source de la situation de blocage, ainsi que les requêtes impliquées dans celle-ci.

Il est possible de charger le fichier de trace dans une table à l’aide de la fonction sys.fn_trace_gettable(). Cela permet l’écriture d’une requête utilisant les méthodes SQLXML, qui extrait directement les informations intéressantes de chaque document XML. La requête est similaire à celle que je donne dans la section suivante.

Ce que capture la session XE

Ici il nous est nécessaire d’écrire une requête faisant appel aux fonctions SQLXML pour dépouiller le document XML sans se fatiguer :

La capture d’écran du résultat a été coupée en deux pour faciliter un peu la lecture :

Interprétation du résultat

Notre intérêt dans l’interprétation de ce document se portera sur la propriété waitresource, que l’on peut décrypter à l’aide de la documentation (Voir la section Waitresource).

Ici, waitresource est : KEY: 5:72057594039107584 (2158b2b5a6d5), ce qui signifie :

– Database ID : 5
– Partition ID : 72057594039107584
– (2158b2b5a6d5) : le hash de la clé d’index

Sur ce dernier point, il faut savoir que SQL Server utilise le hash, stocké sur 6 octets, de la clé de l’index qui supporte la requête. Ceci conduit SQL Server à générer des valeurs de hash identiques pour des valeurs de clé différentes, ce qui peut causer d’autre problèmes de concurrence d’accès. C’est une raison de plus pour choisir des clés d’index les plus « étroites » possible, de façon à éviter ce type de collisions.

Voyons comment retrouver la ressource qui a été verrouillée :

Voyons maintenant comment retrouver la clé qui a été utilisée :

La fonction %%lockres%% n’est pas documentée : il est donc recommandé de l’utiliser avec parcimonie. La même méthodologie est utilisable dans le diagnostic des deadlocks.

Bon déblocage à tous !

ElSüket.

A ce sujet, la documentation indique :

Indique que l’opération de sauvegarde vérifie dans chaque page les informations de somme de contrôle et de page endommagée, si elles sont activées et disponibles, et génère une somme de contrôle pour l’ensemble de la sauvegarde. Ceci est le comportement par défaut pour une sauvegarde compressée.

Vérifions donc si cela est vrai : nous allons créer une base de données de test, et nous allons corrompre une de ses pages afin de vérifier le comportement de la sauvegarde. En effet, l’option CHECKSUM permet de détecter la corruption de données au moment de la sauvegarde. Cela permet en plus de ne pas se retrouver dans l’inconfortable situation de devoir restaurer une base de données à partir d’un fichier de sauvegarde corrompu.

La vérification de l’intégrité des pages au niveau de la base de données

Par défaut, lorsqu’on crée une nouvelle base de données sous SQL Server 2005 et suivants, la vérification de l’intégrité des pages lues à partir du disque se fait à l’aide d’une somme de contrôle. Celle-ci est calculée à partir du contenu de la page, puis écrite dans l’en-tête de celle-ci au moment de l’écriture sur disque. Lorsque la page est ensuite lue à partir du disque, la somme de contrôle est recalculée, puis comparée à celle qui est dans l’en-tête de la page : si les valeurs sont identiques, alors la page est intègre; à l’inverse, on obtient l’erreur 824, qui est écrite à la fois dans les journaux de SQL Server et dans le journal d’événements de Windows.
Enfin lorsqu’on restaure une base de données qui a été créée sous une version antérieure à 2005, il est important de changer cette option de TORN_PAGE_DETECTION à PAGE_VERIFY, car la première est conservée par défaut. L’option TORN_PAGE_DETECTION stocke deux bits pour chaque secteur de 512 octets de toute page, dont la taille est 8192 octets. De la même façon, ces 16 * 2 bits sont stockés dans l’en-tête de la page, et comparés à la relecture de la page. Comme cette option est moins stricte que CHECKSUM, il est donc recommandé d’utiliser cette dernière option.

Le test

Nous créons donc la base de données sous SQL Server 2012, puis nous vérifions l’option du contrôle de l’intégrité des pages :

Nous créons ensuite une table dans cette base de données, à laquelle nous ajoutons une ligne :

Nous forçons ensuite l’écriture des pages sur disque, à l’aide de l’instruction CHECKPOINT, puis nous vidons le cache de données, de sorte que la prochaine fois que nous exécuterons une requête sur cette table, ses pages seront lues à partir du disque, à l’aide de l’instruction DBCC DROPCLEANBUFFERS.

N.B. : N’exécutez JAMAIS une instruction non-documentée sur une base de données qui sert une charge de production. Si tel devait être le cas, je ne peux en aucun cas être tenu pour responsable des conséquences. Vous devez limiter strictement l’usage de cette instruction aux environnements de test.

L’instruction DBCC IND, ou la DMF sys.dm_db_database_page_allocations

Encore deux options d’exploration de la mécanique interne de SQL Server, qui permettent de lister les pages d’une table ou d’un index, et qui ne sont pas documentées. Voici le prototype d’utilisation de ces deux alternatives :

On remarque tout de suite que la DMF produit bien plus d’informations que l’instruction DBCC (nous ne donnons pas ici toutes les colonnes), et que ses arguments sont similaires à la DMF sys.dm_db_index_physical_stats.

Voyons donc ce que contient la page 272, puisque c’est elle qui contient les données (page_type_desc = DATA_PAGE) :

Nous obtenons :

PAGE: (1:272)

BUFFER:

BUF @0x000000027407BB80

bpage = 0x00000002649F4000 bhash = 0x0000000000000000 bpageno = (1:272)
bdbid = 8 breferences = 0 bcputicks = 0
bsampleCount = 0 bUse1 = 33295 bstat = 0x9
blog = 0x2121215a bnext = 0x0000000000000000

PAGE HEADER:

Page @0x00000002649F4000

m_pageId = (1:272) m_headerVersion = 1 m_type = 1
m_typeFlagBits = 0x0 m_level = 0 m_flagBits = 0x8200
m_objId (AllocUnitId.idObj) = 84 m_indexId (AllocUnitId.idInd) = 256
Metadata: AllocUnitId = 72057594043432960
Metadata: PartitionId = 72057594039042048 Metadata: IndexId = 0
Metadata: ObjectId = 245575913 m_prevPage = (0:0) m_nextPage = (0:0)
pminlen = 5 m_slotCnt = 1 m_freeCnt = 8069
m_freeData = 121 m_reservedCnt = 0 m_lsn = (30:345:30)
m_xactReserved = 0 m_xdesId = (0:0) m_ghostRecCnt = 0
m_tornBits = 1209479828 DB Frag ID = 1

Si nous nous en référons à la documentation donnée par Paul Randal, nous avons bien :

– m_flagBits = 0x8200, qui indique que l’intégrité de la page est vérifiée par somme de contrôle
– m_tornBits est la somme de contrôle de cette page

Nous allons maintenant mettre la base de données hors-ligne, puis éditer le fichier de données avec un éditeur hexadécimal, de façon à vérifier si SQL Server vérifie bien la somme à la lecture de la page :

En ce qui concerne la lecture en hexadécimal, j’utilise le logiciel Hex Editor XVI32. Une fois l’outil ouvert en tant qu’administrateur, il suffit de chercher la chaîne que nous avons ajouté comme ligne dans la table, en suivant le menu Search / Find :

Un clic sur le bouton OK nous amène directement à l’emplacement, où l’on est alors libre de changer la chaîne, où j’ai changé le « k » en « d », puis sauvé le fichier :

Nous remettons la base de données en ligne :

Aucun problème. Exécutons un SELECT * FROM dbo.test_backup_checksum. Nous obtenons le message suivant :

Msg 824, Level 24, State 2, Line 1
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xf9ec3284; actual: 0xfe6c3284). It occurred during a read of page (1:228) in database ID 7 at offset 0x000000001c8000 in file ‘C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\TEST_CHECKSUM.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

Prenons maintenant une sauvegarde de cette base de données, avec COMPRESSION, mais sans spécifier l’option CHECKSUM :

Aucun problème : nous obtenons :

Processed 280 pages for database ‘TEST_CHECKSUM’, file ‘TEST_CHECKSUM’ on file 1.
Processed 3 pages for database ‘TEST_CHECKSUM’, file ‘TEST_CHECKSUM_log’ on file 1.
BACKUP DATABASE successfully processed 283 pages in 0.468 seconds (4.709 MB/sec).

Voyons ce que contient la table d’historique des sauvegardes :

On obtient un résultat similaire avec l’instruction RESTORE HEADERONLY (colonnes HasBackupChecksums et IsDamaged toutes deux à zéro) :

Le fichier de sauvegarde ne dispose pas de la somme de contrôle, et n’est pas marqué comme endommagé. Pourtant nous avons bien corrompu le fichier de données, et nous ne pouvons pas lire la table que nous avons peuplé auparavant !

Voyons ce que produit la même instruction, avec l’option CHECKSUM :

Msg 3043, Level 16, State 1, Line 1
BACKUP ‘TEST_CHECKSUM’ detected an error on page (1:228) in file ‘C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\TEST_CHECKSUM.mdf’.
Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.

Voyons maintenant la même instruction, seulement avec l’option CHECKSUM :

Nous obtenons la même erreur. Si nous interrogeons de nouveau la table d’historique des sauvegardes pour cette base de données, nous ne trouvons que le premier backup, dont on sait qu’il est corrompu. Pourtant nous n’avons (presque) aucun moyen de le savoir, car ni cette table, ni l’instruction RESTORE HEADERONLY ne permettent de vérifier que le fichier est bien intègre. On peut cependant vérifier les journaux de SQL Server à l’aide de la procédure stockée étendue xp_readerrorlog, où l’on trouve :

Détecter la corruption le plus tôt possible

Une des premières choses à faire après avoir réalisé une installation fraîche de SQL Server est d’ajouter une liste d’alertes de l’Agent SQL Server, qui enverront un mail dès la détection d’un problème de corruption. Ceci nécessite le paramétrage de Database Mail, et la mise en place d’un opérateur SQL Agent. Voici le code qui permet d’ajouter l’alerte :

L’erreur qui nous intéresse est la 824, mais les erreurs 823 et 825 sont importantes aussi. Pour trouver leur signification, il suffit d’interroger la vue système sys.messages :

On peut faire de même avec l’erreur n° 3043, qui est celle que l’on obtient lors de la sauvegarde.

Activer CHECKSUM pour toutes les sauvegardes

Cela devrait aussi faire partie de la checklist d’installation de SQL Server, d’autant que c’est d’une simplicité enfantine : il suffit d’activer le drapeau de trace n° 3023 :

Après avoir exécuté cette instruction, si nous ré-exécutons maintenant la commande suivante :

Nous obtenons l’erreur que nous avions obtenue lorsque nous avions ajouté l’option CHECKSUM :

Msg 3043, Level 16, State 1, Line 1
BACKUP ‘TEST_CHECKSUM’ detected an error on page (1:228) in file ‘C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\TEST_CHECKSUM.mdf’.
Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.

Ceci est très pratique :

– Si l’on prend les sauvegardes de base de données à l’aide de plans de maintenance, il est impossible de spécifier que l’on souhaite avoir la somme de contrôle;
– Si l’on code une procédure stockée qui s’en charge, cela évite d’avoir à l’ajouter dans le code.

D’autre part si la compression des sauvegardes est activée au niveau de l’instance, on n’a plus qu’a se soucier de la sauvegarde elle-même !

Bonnes sauvegardes et intégrité de pages à tous !

ElSüket.

Il suffit pour cela de rafraîchir les métadonnées, avec la procédure stockée système sp_refreshsqlmodule, disponible sous SQL Server 2005 (SP2) et ultérieurs.
On peut faire cela pour un module SQL bien particulier, mais a y être, autant le faire pour tous les modules de la base de données en cours :

Dès lors vous constaterez que les données contenues dans la vue système sys.sql_dependencies sous SQL Server 2005, ou dans sys.sysdepends dans SQL Server 2000, sont toutes fraîches !

=> Sous SQL Server 2000

=> Sous SQL Server 2005, 2008 et suivants :

Bonne gestion des sauvegardes !

@++

Bonne gestion de l’intégrité référentielle !

ElSüket

ElSuket

ElSüket

Ces calculs se font souvent à base d’extractions de sous-chaînes après avoir converti une date en varchar(n), et on aboutit donc à des choses abominables.

Voici donc une série de calculs de valeurs, uniquement à base de fonctions de date …
Oui, les dates se manipulent avec des fonctions de date, et non pas avec des fonctions de chaîne !

J’en profite au passage pour rappeler mon billet sur le choix des types de données …

La majorité des valeurs calculées ci-dessous repose sur la différence en semaines, mois, trimestres, …, entre la date courante et le 1er Janvier 1900.
En effet, on peut introduire directement cette date par un zéro dans les fonctions de date, que SQL Server caste automatiquement, et qui donne cette date.

J’ai eu un peu la flemme sur le siècle, et j’ai trouvé comme prétexte pour m’arrêter que cela ne doit pas présenter grand intérêt

Bon calculs sur les dates !

ElSüket

– la liste de ses colonnes clé
– la liste de ses colonnes incluses
– la définition de son filtre
– le script de création de cet index

Voici une première requête qui retourne la définition de tous les index d’une base de données.
On peut bien sûr ajouter des filtres afin de voir la définition des index sur une table, ou la définition d’un index en particulier.

Et une autre donnant le script de définition de l’index :

Les tables système de la base de données MSDB nous permettent de spécifier une requête nous permettant de retrouver tous les informations dont nous avons besoin à propos des jobs :

– msdb.dbo.sysjobs stocke la liste de tous les jobs présents sur l’instance, qu’ils soient activés ou non
– msdb.dbo.sysjobhistory stocke la liste de toutes les exécutions des jobs et de leurs étapes
– msdb.dbo.sysjobsteps stocke la description de toutes les étapes de tous les jobs de l’instance

Voici donc, par exemple, comment retrouver tous les échecs pour le job nommé ‘TEST’, avec leur date :

Et si l’on veut être relativement complet :

ElSuket

ElSuket

L’avantage présenté par l’intégration de ce type est l’ensemble des méthodes standard « livrées » avec ce type, qui permettent d’extraire très simplement une latitude (attribut Lat), une longitude (attribut Long), ou encore de connaître la distance entre deux points géographiques avec la méthode STDistance.

Mais il devient alors plus complexe de garantir l’unicité de positions dans une table où l’on stocke la celle de plusieurs villes.
En effet, si une colonne de ce type est spécifiée comme clé d’une contrainte d’unicité, le moteur de base de données SQL Server lève une exception.

Est-il possible de contourner ce problème ?

Si nous tentons de créer la table suivante :