Voici comment créer le raccourci :

Il suffit de créer un nouveau raccourci, et d’y coller la ligne suivante, pour SQL Server 2017 :

Pour les versions antécédantes de SQL Server, il suffit de changer le numéro dans SQLServerManager14.msc par celui de la version qui convient :

• pour SQL Server 2012, c’est SQLServerManager11.msc
• pour SQL Server 2014, c’est SQLServerManager12.msc
• pour SQL Server 2016, c’est SQLServerManager13.msc

Bonne configuration à tous !

ElSüket.

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 !

Pour installer SQL Server Management Studio 2016 v16.5, c’est par ici.
Pour obtenir l’installation dans une autre langue, voyez la section Langues disponibles.

ElSüket

SQL Sentry a annoncé hier que le fabuleux outil qui facilite grandement la lecture de plans de requête, SQL Sentry Plan Explorer, est maintenant gratuit dans son édition Pro.
Jusqu’ici, l’édition Express était déjà un bel outil, qui est maintenant complété par :

• L’ouverture de plusieurs documents de plan de requête (fichiers .sqlplan, .queryanalysis, .pesession)
• L’historique et ses commentaires au fur et à mesure du processus d’optimisation
• L’ouverture des graphes décrivant un deadlock (fichiers de type .xdl)
• La comparaison de l’impact des index pour une même requête
• L’aide à l’analyse de la distribution des valeurs dans un objet de statistique

Bonne analyse de plans !

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 !

Un plan de requête expose la façon dont l’optimiseur de requêtes de SQL Server a calculé la résolution d’une requête que nous lui avons soumis. Ce dernier fait un excellent travail dans la très grande majorité des cas, et pour les autres, il a parfois besoin de l’aide d’un DBA lorsque l’indexation n’est pas l’origine du problème.

SQL Server Management Studio (SSMS) expose les plans de requête estimés et réels.
Le plan de requête estimé expose la suite d’opérateurs logiques et physiques que le moteur a trouvé optimale pour résoudre une requête, c’est à dire celle qui consommera le moins de ressources. Ce plan est basé sur les statistiques de colonnes et d’index. La maintenance et la qualité des statistiques est un un sujet vaste que nous n’aborderons pas ici. On peut obtenir le plan de requête estimé sans exécuter celle-ci en pressant CTRL+L, ou en cliquant sur le bouton ci-dessous, après avoir surligné la requête en question s’il y en a plusieurs dans la fenêtre de requêtes de SSMS.

Le DBA peut se servir du plan de requête estimé pour comprendre un problème de performances, mais il arrive qu’un autre type de plan, dit réel, soit nécessaire. Ce plan peut être généré juste après la fin de l’exécution d’une requête, et permet d’exposer les différences entre le plan estimé et ce qui s’est passé lors de son exécution. De façon similaire au plan de requête estimé, on peut obtenir ce plan de requête en pressant CTRL+M, ou en pressant le bouton suivant dans SSMS avant l’exécution de la requête à étudier.

Visuellement, avec SSMS, aussi bien avec le plan de requête estimé que réel, nous obtenons, pour la requête suivante exécutée sur la base de données exemple AdventureWorks2012 proposée par Microsoft ici (voir les détails de l’installation ici) :

Bien qu’utile, le fait d’avoir à constamment déplacer les curseurs de parcours, surtout lorsque le plan est constitué de nombreux opérateurs, devient vite peu confortable.

Alternativement, SQL Sentry nous offre la possibilité d’utiliser la version gratuite de son outil Plan Explorer, que j’avais exposé ici, et qui continue d’évoluer. On peut télécharger le logiciel ici (en toute fin de page), et il s’intègre automatiquement à SSMS. En effet, il suffit d’effectuer un clic-droit dans une zone vierge du plan et de sélectionner l’option View in SQL Sentry Plan Explorer …

… pour voir l’interface de SQL Sentry Plan Explorer s’ouvrir, et observer une façon différente de disséquer un plan de requête :

Le nombre de lignes échangé entre les opérateurs est exposé directement dans le plan, exposé de façon plus compacte. Par ailleurs, le coût relatif des opérateurs est affiché directement au-dessus de ceux-ci, avec une couleur qui s’assombrit suivant la dépense de ressources qu’ils engendrent. Outre le fait que l’on puisse zoomer sur le plan (utile lorsque le plan de requête est tentaculaire, ou en conférence), les divers onglets présents au bas du panneau du plan d’exécution graphique décrivent des informations souvent utiles, notamment :

• le document XML sous-jacent au plan graphique
• L’arbre du plan, similaire à la sortie que l’on obtient avec SSMS lorsque l’option de session SHOWPLAN_TEXT est positionnée à ON
• Les opérations les plus consommatrices de ressources, comparées à toutes les autres opérations du plan
• Les colonnes spécifiées dans la requête, quel opérateur elles subissent et à travers quel index elles sont accédées
• Le diagramme de jointure, qui permet bien souvent de se rentre compte d’une auto-jointure inopportune
• Les paramètres de la requêtes et leur valeur au moment de la compilation et au moment de l’exécution
• Les expressions (par exemple Expr10NN, où N est un entier, que l’on rencontre parfois dans le plan graphique dans SSMS comme substitut à une expression dans la requête, et que l’on arrive à comprendre seulement en décortiquant le plan XML. Cela permet aussi de détecter les conversions implicites, parfois néfastes aux performances d’exécution d’une requête.)

Les diverses requêtes sont exposées une à une, avec leur coût relatif au coût total du plan : il suffit de cliquer sur l’une des requêtes dans le panneau Results pour les parcourir. Enfin, si l’optimiseur suggère d’ajouter un index (fonctionnalité de suggestion d’index manquants), il suffit de cliquer sur l’opérateur final du plan (le plus en haut et à gauche) pour que l’outil ouvre une fenêtre séparée qui donne, comme dans SSMS, l’instruction de création de l’index.

Passons maintenant au plan d’exécution réel :

Avec la possibilité de montrer l’estimation du nombre de lignes (cardinalité) par rapport au nombre de lignes manipulé par les opérateurs lors de l’exécution de la requête par un simple clic-droit, on détecte très rapidement les problèmes d’estimation de cardinalités : c’est bien souvent à cause de cela que la requête étudiée s’exécute lentement ou consomme beaucoup de ressources. Dans ce cas, l’épaisseur des flèches est largement affectée, et c’est l’effet visuel généré par le passage d’un plan à l’autre qui permet la détection visuelle.

Cerise sur le gâteau : SQL Sentry Plan Explorer permet aussi d’anonymiser un plan de requête, c’est à dire de remplacer le nom réel des tables et autres objets exposés par le plan par un nom générique, et ce en conservant toute la logique du plan. Après un clic sur le bouton suivant, qui se trouve dans la barre d’outils de SQL Sentry Plan Explorer …

… une autre fenêtre s’ouvre, exposant le plan anonymisé : au lieu de trouver le nom des objets réels, on trouve par exemple ObjectN.IndexP, où N et P sont des entiers.

On peut ensuite sauvegarder un tel plan (qu’il soit anonymisé ou non) en vue de le partager sur le forum Développez.com dédié à SQL Server sans exposer d’informations sensibles : un clic sur File > Save As ouvre la fenêtre suivante :

• L’extension .queryplananalysis est le format propriétaire de SQL Sentry. Si vous sauvegardez sous ce type, assurez-vous que la personne avec qui vous partagez le plan de requête dispose aussi de SQL Sentry Plan Explorer.
• L’extension .sqlplan est le format propriétaire de SQL Server Management Studio. Après la sauvegarde, si vous double-cliquez sur un tel document, il s’ouvrira automatiquement avec ce dernier
• L’extension .xml est le format générique de description de documents bien connu. Le document résultant est identique à son homologue .sqlplan. On peut l’utiliser pour automatiser l’extraction de données de plusieurs plans.

Bonne capture de plans !

• 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.

SSDT a été mis en ligne pour la première fois pour Visual Studio 2010, qu’il installait en mode Shell. Cette version n’est maintenant plus disponible, mais on la trouve bien entendu pour Visual Studio 2012 (fr/en) et 2013 (fr/en).

Ce dernier est en fait décliné en deux opus, l’un dédié à la Business Intelligence, abrévié en SSDT-BI, et l’autre SSDT tout court. Les deux versions installent toujours Visual Studio en mode Shell, mais la version BI n’installe pas les composants nécessaires au développement d’un projet d’assembly SQL Server. Et inversement.

J’avais donc installé SSDT-BI 2012 sans noter que le projet de type SQL Server n’était pas présent. J’ai donc installé SSDT 2012 (téléchargeable ici en version 2012 et 2013), et j’ai maintenant ce qui me manquait :

Bon développement SQL Server !

C’est ce que à quoi remédie dbForge SQL Complete, qui remplace allègrement SSMS IntelliSense. Je vous propose ici une revue de l’édition Standard de SQL Complete, mais sachez qu’il en existe une version gratuite pour un usage non-commercial.

L’installation du plugin SSMS se fait comme pour toute application. Elle requiert simplement que SSMS ne soit pas en cours d’exécution. Sachez néanmoins que SQL Complete s’intègre bien sûr à SQL Server Management Studio 2012, mais aussi avec Visual Studio 2012 :

Le plugin vérifie automatiquement si une nouvelle version est disponible au démarrage de SSMS, et vous permet d’effectuer le téléchargement de celle-ci. La progression du téléchargement est affichée à gauche dans la barre d’état. Quand celui-ci est terminé, une popup apparait, indiquant l’emplacement du fichier. Il est alors nécessaire de fermer SSMS pour poursuivre la mise à jour du plugin.

Aide à l’écriture de code

Dès le (re)démarrage de SSMS, on trouve un élément de plus dans la barre de menu, nommé SQL Complete. Avant de développer les options de SQL Complete, voyons ce qu’il peut faire. Nous changeons le contexte de bases de données à l’aide de l’instruction USE AdventureWorks2012 : automatiquement, le cache de SQL Complete charge les métadonnées de la base de données en cours d’utilisation, et affiche une barre de progression à droite, dans la barre d’état. On trouve alors la liste des bases de données hébergées par l’instance SQL Server très simplement :

Le simple fait de taper « S » amène la liste suivante :

Nous avons donc en premier une liste de possibilités T-SQL, suivies par une liste de snippets. Nous verrons plus tard qu’il existe un gestionnaire de snippets fort pratique. Supposons que nous voulions écrire SET TRANSACTION ISOLATION LEVEL REPEATABLE. Avec IntelliSence, il faut tout écrire, caractère par caractère. Mais avec SQL Complete, il suffit seulement de taper les premières lettres de chaque mot-clé; les mots-clé qui suivent sont automatiquement pré-filtrés avant l’affichage dans l’infobulle :

Certes, le gain de temps n’est pas énorme, mais cela rend le travail moins pénible en évitant tout simplement les fautes de frappe !

Voyons maintenant comment appeler une procédure stockée sans se fatiguer : on sait que le nom de la procédure stockée contient le mot employee; on tape donc EXEC employee, et on obtient :

Une fois que l’on a validé par ENTER, on peut suivre suggestion de l’infobulle pour obtenir la liste des paramètres :

Et nous obtenons alors :

Avouons que c’est moins pénible que de filtrer la liste produite par l’Explorateur d’Objets de SSMS.
Si nous passons le curseur sur la procédure stockée, nous obtenons une nouvelle fois la liste de ses paramètres dans une infobulle. Si l’on souhaite spécifier la valeur des paramètres un à un, là aussi le travail nous est facilité : supposons que nous avons spécifié le premier paramètre, et que nous venons de taper une virgule, qui va introduire le second : automatiquement, l’infobulle avec la liste des paramètres apparait, et il n’y a plus qu’à sélectionner le paramètre souhaité :

Que l’on soit en train d’écrire un script ou une procédure stockée, l’accès aux variables locales ou aux paramètres d’entrée se fait là aussi très aisément, par l’affichage automatique de l’infobulle :

Si l’on souhaite consulter la définition de la procédure stockée, il suffit de choisir l’option Go To Definition dans le menu contextuel :

L’explorateur d’objets est immédiatement affecté et a sélectionné la procédure stockée.

Notons que la même option est offerte pour tout objet de base de données.
Voyons d’ailleurs comment obtenir la définition d’une table sans pour autant avoir affaire avec l’Explorateur d’Objets de SSMS :

Bref, SQL Complete nous offre un arsenal d’infobulles qui nous permet de gagner du temps en évitant toute faute de frappe, et dans la recherche d’objets de code ou de base de données. Ceci permet finalement de n’avoir à se concentrer quasiment que sur la logique à implémenter.

Le gestionnaire de snippets

Comme nous l’avons vu plus haut, SQL Complete est livré avec un ensemble de snippets. Il est en plus possible de les éditer et d’en créer de nouveaux, à l’aide du gestionnaire, que l’on obtient en choisissant l’option Snippets Manager du menu SQL Complete, dans la barre de menus. Voici l’interface obtenue :

L’interface est sobre mais bien conçue, puisqu’on peut :

- Consulter la liste des snippets disponibles
– Éditer les snippets existants, de façon à ce qu’ils suivent un formatage particulier
– Utiliser des variables prédéfinies, comme DATE, TIME, USER, SERVER, DB, ce qui permet par exemple de faciliter l’écriture d’en-têtes de modules T-SQL, ou de scripts
– Organiser les snippets par dossier
– Créer ses propres paramètres fictifs, ou en créer de nouveaux, qui sont attachés à un snippet particulier
– Partager un snippet sur Devart

Par ailleurs les snippets fournis par Devart sont très complets, comme l’illustre la capture d’écran ci-dessus pour le snippet nommé CreateDatabase. Enfin, les snippets sont stockés sous la forme de fichiers XML portant l’extension .snippet, dont l’emplacement est affiché en bas de l’interface : ceci rend le partage de snippets entre collaborateurs très facile.

Aide au formatage

Parmi les options que l’on trouve après avoir suivi SQL Complete > Options depuis la barre de menus, on remarque qu’il est possible de créer, éditer et partage des profils de formatage :

Si l’on clique sur le bouton Edit Profile …, on obtient une interface encore une fois sobre mais efficace, et surtout exhaustive :

Tous les aspects de la puissance du langage T-SQL sont abordés, et on peut aller de la place et l’alignement des mots-clé aux lignes d’intervalle ou indentations entre les instructions. On peut donc paramétrer le formateur pour qu’il nous obéisse au doigt et à l’œil. De retour dans une fenêtre, l’application du formatage se fait de façon intuitive, par un simple clic-droit sur l’ensemble de requêtes à formater :

Et l’on obtient immédiatement :

Import et export des paramètres

L’uniformisation de l’utilisation d’un standard de codage parmi toutes les personnes qui doivent écrire du code T-SQL dans l’entreprise est facilité par l’export de cet ensemble de paramètres, qui comprend ceux de l’interface et ceux de formate, mais pas les snippets. Cependant pour ces derniers, comme nous l’avons vu, il est facile de les trouver puisqu’ils sont stockés sous la forme de fichiers XML portant l’extension .snippet : leur emplacement est affiché en bas de l’interface de gestion des snippets.
On accède comme d’habitude à cette option en suivant SQL Complete > Import and Export Settings

L’utilisation de l’interface étant triviale, je passe sur les détails :

Une fonctionnalité intéressante non seulement pour partager les paramètres avec ses collègues, mais aussi pour en réaliser une sauvegarde et faciliter un changement de PC.

Conclusion

Devart dbForce SQL Complete est un outil extrêmement complet qui, dès qu’on commence à l’utiliser, fait rapidement oublier les insuffisances de l’intégration d’IntelliSense à SQL Server Management Studio. En plus de faciliter l’écriture de code, il permet de renforcer les standards de codage d’une équipe de développement par la possibilité de formater automatiquement et avec une précision chirurgicale du code T-SQL, et d’échanger ce formatage de façon aisée par un simple import / export. L’utilité des snippets et indiscutable, et la gestion proposée par ce plugin est supérieure encore une fois à ce qu’offre SQL Server Management Studio 2012.

On ne peut donc que féliciter Devart pour la qualité irréprochable de ce produit, qui est d’ailleurs décliné pour MySQL, Oracle, et bientôt PostGre SQL. Par ailleurs Devart offre d’autres produits, comme des pilotes pour l’accès aux base de données, et des solutions d’aide au développement par ORM ou avec Delphi.

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.

Voyons tout d’abord quelles sont les connexions qui disposent du privilège d’appartenance au rôle sysadmin. La requête suivante liste l’ensemble des connexions inscrites aux rôles d’instance :

La connexion ELSUKET8\Nicolas est celle d’administrateur local de mon PC : je la supprime :

A l’ouverture d’une nouvelle fenêtre de requête, nous obtenons bien l’erreur :

Rendons-nous maintenant dans le gestionnaire de configuration de SQL Server. Si l’instance est sous SQL Server 2012 et que l’on souhaite ouvrir cette console à partir d’une fenêtre de ligne de commandes, il faudra saisir SQLServerManager11.msc. Une fois la console ouverte, on peut double-cliquer sur SQL Server Services dans l’un des deux panneaux, et on obtient la liste des services SQL Server installés :

Un clic-droit sur le service SQL Server nous permet d’accéder, en outre, aux paramètres de démarrage du service. Sous SQL Server 2005 et 2008, ils se trouvent dans l’onglet Avancé, mais sous SQL Server 2012, l’onglet Paramètres de démarrage a fait son apparition :

Nous ajoutons ici le paramètre l’option -m, qui permet de démarrer une instance en mode mono-utilisateur. Sous SQL Server 2005 et 2008, dans l’onglet Avancé, il est nécessaire de placer le curseur à la fin de la chaîne du paramètre Paramètres de démarrage, et d’ajouter ;-m après la fin de cette chaîne. Une fois fait, nous sommes avertis qu’il est évidemment nécessaire de redémarrer le service :

On peut redémarrer le service toujours à partir de la même console, par un clic-droit sur le service. Une fois fait, nous démarrons SQL Server Management Studio (SSMS) en tant qu’administrateur. Cette option est accessible par un simple clic-droit sur le raccourci. Attention : comme nous sommes en mode mono-utilisateur, il n’est pas possible d’ouvrir une connexion pour l’explorateur d’objets. Donc si l’on ne ferme pas la connexion de ce dernier (par clic-droit sur le nom de l’instance dans celui-ci), il est impossible d’ouvrir une fenêtre de requête.

Nous nous octroyons maintenant le droit de connexion et d’appartenance au rôle de serveur sysadmin :

Nous devons maintenant retourner dans la console de configuration des services de SQL Server, retirer le paramètre -m, et redémarrer à nouveau le service, de sorte que l’instance soit de nouveau accessible par plusieurs connexions. Une fois fait, on peut démarrer SSMS normalement (i.e. pas en tant qu’administrateur), et nous pouvons de nouveau accéder à l’instance SQL Server :

Changer le mot de passe de la connexion sa

Cela se fait de la même façon, en suivant les étapes suivantes :

1. Ajouter le paramètre -m aux paramètres de démarrage du service SQL Server, puis redémarrer le service;
2. Se connecter à l’instance SQL Server avec SSMS en tant qu’administrateur;
3. Changer le mot de passe de la connexion sa avec l’instruction suivante :

4. Supprimer le paramètre -m des paramètres de démarrage du service SQL Server, puis redémarrer le service une nouvelle fois;
5. Se connecter normalement avec SSMS, le nom de connexion sa et le nouveau mot de passe.

Effectuer ces mêmes opérations en ligne de commande avec l’utilitaire SQLCMD

Il est pour cela nécessaire d’ouvrir un fenêtre de lignes de commande en tant qu’administrateur. On peut tout simplement créer une raccourci qui pointe sur cmd, puis par clic-droit sur celui-ci, choisir de mode :

Une fois fait, on démarre l’utilitaire en lignes de commande SQLCMD très simplement :

Puis, par exemple, changer le mot de passe de la connexion sa :

Après chaque ligne de code tapée sous SQLCMD, si l’on appuie sur Entrée, la commande n’est pas exécutée : il faut pour cela utiliser la marqueur de fin de lot GO (qui n’est pas une instruction SQL ou T-SQL !). Enfin, pour sortir de l’utilitaire SQLCMD, il suffit de taper exit.

Bonne récupération d’accès à tous !

ElSüket.

– Paramétrage de la casse et de l’indentation
– La coloration syntaxique
– La vérification de la syntaxe : les erreurs trouvées sont soulignées
– La possibilité de formater un fichier de script

Pour me retrouver souvent avec du code qui a été écrit avant que je mette en place un standard de codage, ce type d’outil me fait gagner énormément de temps.

C’est en fait une copie d’une fonctionnalité de SQL Complete. Celui-ci remplace allègrement IntelliSense de SQL Server Management Studio, par le simple fait que les suggestions proposées au fil de l’écriture d’une requête sont basées sur le contexte.
Il est également possible de trouver un objet à partir d’une suite de lettres contenues dans le nom de cet objet.

Il en existe une version gratuite, que j’utilise au quotidien, et une version payante, plus complète et riche en fonctionnalités. Enfin, le site fait cadeau du prix de la licence pour les MVP (voir dans le volet droit de chaque page).

Alors bon codage !

ElSüket

Paul Randal vient donc de mettre à la disposition de la communauté un poster qui détaille les étapes de la reprise d’activité par un diagramme décisionnel.

Ce diagramme contient certaines étapes qui référencent un numéro, et chaque numéro correspond à un article publié par Paul Randal. Ils sont tous référencés sur cette page.

Toujours bon à avoir sous la main !

=> Les plans de maintenance ne sont pas portables : il est impossible de déployer simplement sur plusieurs instances de SQL Server un même plan de maintenance en une seule fois. D’autre part, une fois la copie réalisée, il est nécessaire de mettre à jour la chaîne de connexion qui est dans celui-ci, et qui correspond a l’instance sur laquelle celui-ci a été créé. Enfin, on peut se heurter à des problèmes d’intégrité des données référentielle dans la base de données système msdb, ce que le DBA (trop) prudent que je suis se refuse catégoriquement à réaliser.

=> Lorsqu’on supprime un plan de maintenance, le package SSIS est supprimé, mais pas le travail de l’Agent SQL Server qui lui est attaché

=> A chaque fois que quelqu’un crée ou modifie un plan de maintenance, il est nécessaire de changer de nouveau le propriétaire de celui-ci et/ou du travail de l’Agent SQL Server qui est attaché à ce plan, car celui-ci est écrasé automatiquement par le nom de connexion de l’utilisateur qui réalise l’édition du plan de maintenance

=> Dans les éditions Enterprise de SQL Server 2005, il est impossible d’obtenir l’option CHECKSUM lorsqu’on souhaite réaliser une sauvegarde de base de données. Sous SQL Server 2008, ce n’est pas possible non plus, mais le CHECKSUM est calculé lorsqu’on active la compression des sauvegardes de base de données.

=> En ce qui concerne la maintenance des statistiques, il est impossible d’indiquer le niveau d’échantillonnage par défaut. D’autre part, l’échantillonnage est soit annulé (FULL), soit il est identique pour toutes les tables, ce qui n’est pas optimal

=> Quand on connaît les dégâts que peuvent causer un rétrécissement de base de données, on comprend qu’une telle tâche ne devrait tout simplement pas exister

=> Les tâches de défragmentation et de reconstruction des index ne permettent pas de spécifier des valeurs seuil pour lesquelles il est préférable de défragmenter plutôt que de reconstruire un index, et inversement.

=> La vérification de l’intégrité des bases de données ne permet malheureusement pas de spécifier le niveau de vérification avec lequel on souhaite l’effectuer.

En revanche les tâches de nettoyage des fichiers, d’envoi de notification à un opérateur, d’exécution d’un travail de l’Agent SQL Server, d’exécution de script T-SQL ou de l’historique sont plutôt bien conçues, même si pour la dernière j’aurai préféré pouvoir spécifier une durée de rétention par type d’historique.

Pour toutes ces raisons, je proscris pour le moment l’utilisation des plans de maintenance sur les serveurs de production, pour lesquels j’ai développé un ensemble de procédures stockées qui me permet de réaliser juste le minimum.

Je pense que les plans de maintenance sont un très bon moyen d’assurer un niveau minimal de qualité d’une base de données avec un minimum d’effort, et sont appropriés pour des serveurs de développement ou des test peu importants, mais pas (encore ?) pour des instances de SQL Server qui supportent la production.

Attention donc à ne pas utiliser les plans de maintenance à tors et à travers

ElSüket.

Rappelons que les DTS (Data Transformation Services) est un outil d’ETL (Extraction / Transformation / Load) introuduit avec SQL Server 7 et remplacé dès SQL Server 2005 par SSIS (SQL Server Integration Services)

Sur le serveur source, replongeons nous dans la console d’administration de SQL Server 2000 qu’est Enterprise Manager pour retrouver nos lots DTS:

Nous allons maintenant choisir d’exporter le DTS dans un fichier structuré, en choisissant l’option « Enregistrer sous » du menu « Lot » :

Une boîte de dialogue apparaît alors, nous permettant de spécifier le type de sauvegarde à effectuer

On voit que l’on peut effectuer une sauvegarde d’un DTS directement sur un autre serveur hébergeant aussi un instance SQL Server 2000, mais il est possible que la machine de développement soit dans l’entreprise alors que la machine de production est chez le client.

On peut aussi spécifier un nom de fichier :

Après le transfert du fichier sur le serveur cible, ouvrons Enterprise Manager pour enregistrer le lot :

On obtient la boîte de dialogue classique de spécification d’un emplacement de fichier :

De retour dans Enterprise Manager, nous devons choisir le lot à ouvrir (comme on peut en enregistrer plusieurs dans le même fichier d’export) :

Il suffit maintenant d’enregistrer le lot …

… en spécifiant qu’il s’agit d’un instance SQL Server :

Et l’opération est terminée; la console Enterprise Manager affiche :

ElSuket

ElSuket

On sait tout de suite quel filtres ont été utilisés à l’aide des deux premières colonnes.
La dernière colonne contient l’instruction qui permet d’arrêter la trace : le développeur a donc toujours ses résultats.

Pour savoir comment créer une trace côté serveur, c’est par ici

Bon traçage !

ElSüket

Pour convertir un fichier blg au format CSV, il suffit d’utiliser l’instruction relog en ligne de commandes :

>relog perfmon_log.blg -f CSV -o perfmon_log.csv

En quelques secondes un gros fichier blg peut être converti, retournant le nombre de lignes que contient le fichier CSV.

A partir de là, on peut procéder à son intégration en faisant un clic-droit sur la base de données dans laquelle on souhaite charger les données :

La fenêtre suivante s’ouvre alors :

Il suffit simplement de sélectionner Flat file source dans la liste déroulante Data source, puis de cliquer sur Browse :

Attention à filtrer sur l’extension csv, sinon le fichier n’apparaîtra pas

Une fois le fichier sélectionné, faites attention à la page de codes : elle doit correspondre à la collation utilisée par votre base de données.
Dans la plupart des cas, la page de codes par défaut fonctionnera.
Dans mon cas, comme la collation de la base de données est Thai_CI_AS, j’ai choisi la page de codes 874.

Enfin, comme la première ligne de notre fichier de log PerfMon contient le nom des compteurs, il faut également cocher la case Colmun names in the first data row.

On peut maintenant cliquer sur le bouton Next :

Ici il s’agit de spécifier l’instance SQL Server (Server name) et la base de données dans laquelle on souhaite importer les données (Database).

La table prend alors le même nom que le fichier, par défaut.
Néanmoins on peut tout à fait parcourir et choisir une table de la base de données.

Une fois cela fait, on peut cliquer sur Next : la fenêtre suivante apparaît :

On peut alors choisir d’exécuter le package SSIS immédiatement, auquel cas il ne sera pas sauvegardé, ou bien choisir de l’enregistrer :

1. dans SQL Server (en fait dans la base de données système MSDB)
2. ou dans un fichier

C’est pratique puisque :

– Dans le premier cas, si nous devons réaliser un nouvel import, on n’aura plus qu’à se connecter avec SQL Server Management Studio à l’instance SSIS pour exécuter le package une nouvelle fois,

– Dans le second cas, il suffit simplement de double-cliquer sur le fichier (que l’on peut échanger avec ses collègues) pour exécuter le package

Dans mon cas, comme je n’aurai très probablement jamais plus besoin de réimporter des fichiers de log PerfMon ayant une liste de compteurs strictement identique, j’ai choisi Run Immediately seulement.

Dans tous les cas, on cliquera sur le bouton Next :

Le package s’exécute alors … quand l’opération est terminée, on obtient la fenêtre suivante :

Il suffit alors de cliquer sur Close pour voir la fenêtre se fermer, puis de faire un SELECT * FROM dbo.perfmon_log

Dans le cas où il s’agit d’une opération qui devra être effectuée à répétition, on peut également sauvegarder le package, et le faire exécuter par un job de l’Agent SQL Server.
En plus de cela, on peut construire un rapport SQL Server Reporting Services (SSRS) sur la table recevant les lignes du fichier CSV.

Bon chargement de données PerfMon

ElSüket

Lorsque le plan comporte de nombreuses icônes, dans SSMS, on est obligé de jouer énormément avec les curseurs pour voir où se situe le problème.
Ce n’est pas le cas avec Plan Explorer, qui utilise un format plus compact.
Pour le même plan, voici ce que l’on voit dans SSMS :

Et dans Plan Explorer :

Je suppose qu’avec cette première capture d’écran vous aurez remarqué d’autre différences :

– Les cardinalités sont affichées sur les flèches
– Les opérations les plus coûteuses sont mises en évidence. On peut notamment les visualiser par coût E/S et par coût CPU :

Vous le voyez, il est également très simple de comparer les cardinalités estimées et réelles, ce qui permet rapidement de savoir s’il s’agit d’un problème d’estimation de ces dernières.
L’option Full object names affiche le nom complet de l’objet et de l’index, ce qui permet de ne pas avoir à passer le curseur sur les icônes pour savoir quel index a été utilisé.

Enfin les infobulles sont toujours présentes, mais mieux présentées parce qu’ordonnées.
Voici donc ce que l’on voit sans SSMS pour une icône de plan d’exécution graphique :

On aurait apprécié de voir par exemple le nombre de lignes estimé précéder directement le nombre de lignes réel, comme c’est le cas dans Plan Explorer :

Les onglets situés au-dessus du plan sont assez pratiques également.
Le Plan Tree est similaire au plan d’exécution textuel proposé par SSMS, mais présenté beaucoup plus clairement :

Je passe sur Top Operations et Query Columns, dont leurs noms parlent d’eux-mêmes, pour passer à Expressions :

Désormais les Expr10XX sont décryptables sans avoir à se plonger dans le document XML qu’interprètent ces deux outils

Autre implémentation intéressante : lorsqu’on obtient le plan d’exécution d’une procédure stockée ou d’un lot de requêtes, le plan est affiché requête par requête dans Plan Explorer, au lieu d’avoir tous les plans affichés dans l’onglet Plan d’exécution de SSMS :

Enfin on peut choisir les colonnes à afficher dans l’onglet Statements Tree :

Il est donc simple d’ajouter ou supprimer des colonnes.

Alors bonne lecture de plans d’exécution !

ElSüket

L’exemple qui suit est basé sur l’attachement de la base de données exemple AdventureWorks2012, que l’on peut télécharger sur le site CodePlex :

Une fois le fichier téléchargé, il suffit de le placer dans le dossier où l’on souhaite que la base de données réside.
Dans mon cas, il s’agit de D:\SQLServer :

Passons sous SQL Server Management Studio, où l’on peut attacher une base de données à une instance SQL Server après un clic-droit sur le nœud Databases > Attach … :

Il suffit de cliquer sur le bouton Add … dans le dialogue qui s’ouvre …

… et de référencer le fichier de données :

Une fois que l’on a cliqué sur OK, le dialogue est mis à jour de la façon suivante :

Il suffit alors de sélectionner le fichier du journal de transaction (qui n’existe pas), et de cliquer sur le bouton Remove, puis sur OK :

Le fichier du journal des transactions est automatiquement recréé, et la base de données est maintenant attachée.

Cela peut aussi se faire par un script, avec l’option ATTACH_REBUILD_LOG de l’instruction CREATE DATABASE :

Bon attachement de bases de données !

ElSüket

Il suffit ensuite d’exécuter EXEC sp__processes_locks dans n’importe quel contexte de base de données, et le tour est joué

Bon monitoring !

ElSüket

Je tiens à remercier Mikedavem pour ses encouragements, la relecture et l’aide à la publication.

Je remercie également toute l’équipe de Développez.com pour la mise à disposition de la plateforme de publication.

Voici le menu :

I. Architecture logique des XE, où sont décrits ce que sont les packages, les événements, les cibles, les actions, les prédicats, les « maps », et enfin les types

II. Gestion des sessions d’XE avec les vues et fonctions de gestion dynamique, qui donne le détail et les requêtes pour gérer les sessions XE

III. Quelques exemples guidés (3 au total)

IV. Le futur avec SQL Server 2012 : une brève section sur les améliorations apportées par SQL Server 2012 concernant les XE

V. Avantages et inconvénients de l’utilisation des XE : une liste de ce qu’apportent les XE, et de leurs (rares à mon avis) freins à leur adoption

Bonne Lecture à tous et merci de vos commentaires

Cette vue accumule les statistiques tant que le service SQL Server est démarré; un redémarrage du service ou du serveur purge les statistiques exposées par cette DMV.
Si elle permet de détecter les index non-utilisés et donc à supprimer, vérifiez depuis combien de temps le service SQL Server est actif

Bonne utilisation de vos index !

ElSüket

– pour toute l’instance SQL Server,
– par base de données
– par table (ou vue indexée) dans une base de données en particulier

=> Au niveau de l’instance SQL Server

Cette requête donne l’espace alloué au cache de données pour toutes les bases de données d’une instance SQL Server.
Elle montre également l’espace vide dans les pages, qui quand elle est élevée, est due soit à une fragmentation des index élevée, soit à un modèle de données incorrect qui conduit à ne pouvoir stocker que peu de lignes par page de données.
En effet le taille d’une page de données est de 8192 octets, desquels 8060 octets sont dédiés aux données utilisateur.
Si donc la taille d’une ligne est de 4031 octets (cas extrême) ou plus, on ne peut stocker qu’une seule ligne de données par page, et on gaspille 4029 octets.

=> Décomposition par base de données

Même chose ici, mais pour chaque objet de base de données.

Cette requête nécessite de changer le contexte de base de données à la base de données que l’on souhaite étudier.
En effet, elle retourne la liste des tables (et vues indexées) qui sont présentes dans le cache de données, ainsi que la taille qu’elles y occupent, avec les index.

En exécutant cette dernière requête à intervalles de temps réguliers à l’aide d’un job de l’Agent SQL Server, et en enregistrant le résultat dans une table, on peut étudier la taille du cache allouée aux objets, de façon à faire une projection sur la quantité de RAM nécessaire au bon fonctionnement de la base de données.

=> Page d’accueil des documentation de SQL Server sur Internet

SQL Server 2000
SQL Server 2005
SQL Server 2008
SQL Server 2008 R2
SQL Server 2012

=> Télécharger la documentation de SQL Server pour installation locale

SQL Server 2000
SQL Server 2005
SQL Server 2008
SQL Server 2008 R2
SQL Server 2012

Bonne documentation à tous !

ElSüket

=> sys.dm_os_volume_stats permet d’obtenir quelques informations sur les volumes sur lesquels sont stockés les fichiers des bases de données hébergées par le serveur. On obtient la liste des volumes avec leurs caractéristiques avec la requête suivante :

Et un requête avec la carte des fichiers, pour toutes les bases de données :

La documentation de cette DMV pour SQL Server 2008 R2 et SQL Server 2012

=> sys.dm_os_windows_info

Cette DMV retourne quelques informations intéressantes à propos de l’installation de Windows qui héberge SQL Server.
En l’interrogeant sur mon PC sous Windows 7 SP1 en Français, j’obtiens :

La documentation de cette DMV pour SQL Server 2008 R2 et SQL Server 2012

=> sys.dm_server_registry

Cette DMV retourne toutes les valeurs stockées dans le registre pour SQL Server, en ce qui concerne les options de démarrage du service, et la configuration des protocoles de connexion à l’instance interrogée :

La documentation de cette DMV pour SQL Server 2008 R2 et SQL Server 2012

=> sys.dm_server_services

Comme son nom l’indique, cette DMV retourne quelques informations sur les services installés pour l’instance SQL Server interrogée :

On notera que sont exposés la date de dernier démarrage du service et l’instance est en cluster.

La documentation de cette DMV pour SQL Server 2008 R2 et SQL Server 2012

=> sys.dm_server_memory_dumps

Cette DMV retourne l’ensemble des vidages mémoire avec le chemin des fichiers, c’est-à-dire à chaque fois que SQL Server a rencontré un gros problème.
Malheureusement (ou pas) sur mon installation de SQL Server 2012, l’interrogation de cette DMV ne retourne rien

La documentation de cette DMV pour SQL Server 2008 R2 et SQL Server 2012

On le voit donc, Microsoft continue d’exposer les données système à travers les fonctions et vues de gestion dynamique (respectivement DMF et DMV dans la littérature, et plus généralement DMO pour Dynamic Management Object).
Elles ont été introduites avec SQL Server 2005, et facilitent grandement les travail des administrateurs de bases de données et des consultants.

Ces 5 nouvelles DMVs permettent notamment de démarrer une discussion avec les administrateurs système.
En effet en exécutant de telles requêtes sur un ensemble de serveurs hébergeant une instance de SQL Server à travers les possibilités de Central Management Server, elles permettent en outre de comparer et détecter très simplement les différences de configuration entre plusieurs serveurs, et elles sont donc fort bienvenues.

ElSüket.

Cette fonctionnalité est livrée avec 50 stratégies par défaut, qualifiées de « meilleures pratiques », mais qui ne sont pas préinstallées directement. Voici comment les importer …

Lorsqu’on ouvre l’Explorateur d’Objets de SQL Server Management Studio (SSMS), que l’on obtient par F8, et que l’on développe le nœud Gestion, on obtient :

La gestion basée basée sur les stratégies propose une liste assez conséquente de propriétés que l’on peut vérifier, et qui sont groupées dans ce qui est appelé une facette.
Ainsi on peut vérifier, par exemple :

– que la densité de grille de niveau 1 d’un index spatial est à MEDIUM
– que l’option de serveur « max degree of parallelism » est à 1
– que la dernière sauvegarde complète d’une base de données n’est pas plus vieille que 7 jours
– que toute statistique est automatiquement maintenue par SQL Server
– que le nom de toutes les procédures stockées commence par « usp_ »

Ceci n’est qu’une très courte liste d’exemples de ce qu’il est possible de vérifier à l’aide de la gestion basée sur les stratégies.
Chacun de ces exemples constitue une condition, qui est évaluée par une stratégie, que l’on peut soit créer :

– Manuellement à l’aide de SSMS
– Soit automatique en écrivant les scripts ou modules T-SQL nécessaires
– Soit importer à partir d’un fichier XML

Je passerai dans ce billet sur les deux premiers éléments de cette liste, qui méritent à eux seuls un billet, pour détailler l’import, et plus particulièrement l’import des stratégies de « meilleures pratiques ».

L’import se fait très simplement : il suffit de cliquer-droit sur le noeud Stratégies :

Un dialogue s’ouvre alors pour la sélection de stratégies à importer :

Au clic sur le bouton de recherche (…), une fenêtre classique de sélection de fichiers s’ouvre, et on remarque que celle-ci est paramétrée pour s’ouvrir sur un dossier contenant un raccourci nommé Meilleures pratiques pour SQL Server:

En double cliquant sur le raccourci, on est pointé vers C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Policies, où l’on s’aperçoit qu’il existe des stratégies pour SQL Server Analysis Services et SQL Server Reporting Services.
Ici nous nous intéresserons seulement aux stratégies pour le moteur de bases de données relationnelles, donc nous sélectionnons le répertoire DatabaseEngine, puis le répertoire 1036 (qui est l’identifiant de langue pour le Français) :

Pour importer toutes les stratégies, il suffit de toutes les sélectionner (CTRL + A) et de cliquer sur Ouvrir :

En cliquant sur OK, on procède à l’import :

De retour dans SSMS, on trouve toutes les stratégies importées :

Pour évaluer une stratégie, il suffit de choisir Évaluer dans le menu contextuel de l’une d’entre-elles :

En quelques secondes, on obtient :

Et en cliquant sur le lien Afficher, on obtient tous les détails, avec la description de ce que vérifie la stratégie :

Dans l’exemple de ce billet, le lien pointe vers une page de la documentation de SQL Server qui décrit ce que vérifie la stratégie, et comment y remédier si elle n’était pas vérifiée.

Bonne gestion d’instances SQL Server !

ElSüket

Comme beaucoup de choses effectuées à l’aide des interfaces graphiques proposées par SQL Server Management Studio, les effets produits par l’exécution d’une tâche ne sont pas toujours détaillés. Le propriétaire d’un plan de maintenance n’y échappe pas et est écrasé à chaque modification du plan.
Voici donc comment le trouver, et le changer.

Voici la requête qui permet de trouver le propriétaire de tous les plans de maintenance, avec quelques détails :

En dé-commentant la clause WHERE de cette requête, on peut trouver le propriétaire d’un plan de maintenance particulier.

Dès lors on peut changer le propriétaire d’un plan de maintenance particulier à l’aide de la requête suivante :

Ceci fonctionne sous réserve que nomDeLoginDuNouveauPropriétaire et monPlanDeMaintenance existent

Et c’est malheureusement à effectuer après chaque modification du plan de maintenance si le login qui le modifie n’est pas celui qui l’exécute !

Bons plans de maintenance

ElSüket

Vous remarquerez que je me place dans le contexte de la base de données système master, qui est la seule dans laquelle vous pouvez marquer des procédures stockées comme objet système.

Un autre requis pour pouvoir utiliser une procédure stockée marquée comme objet système dans n’importe quel contexte de base de données de l’instance en cours, est de faire commencer le nom de la procédure stockée par « sp ».
Rien ne vous empêche de marquer la procédure stockée comme objet système, mais lorsque vous exécuterez une telle procédure stockée (dont le nom ne commence donc pas par « sp »), SQL Server « feindra » de ne pas trouver celle-ci.

Le marquage se fait de façon extrêmement simple, mais n’est pas documenté :

EXEC sp_MS_marksystemobject 'sp__generate_INSERT'

Et le tour est joué : vous pouvez générer le script d’INSERT en exécutant tout simplement :

Bonne génération !

ElSüket

Elle permet de lister l’ensemble des requêtes actuellement en cours d’exécution dans une instance SQL Server, avec quelques statistiques et caractéristiques :

– le n° de session (SPID),
– le nombre de threads mis en place pour résoudre la requête,
– le nom du serveur,
– le nom du login,
– le pourcentage d’avancement d’une instruction,
– le nom de la base de données,
– le statut de la session,
– le temps écoulé depuis le début de l’exécution,
– le temps CPU consommé,
– le nombre de lectures et d’écritures,
– le type d’instruction,
– le nombre de transactions ouvertes par la session,
– le nombre de resultsets,
– le type d’attente,
– le temps d’attente pour ce type,
– le type d’attente précédent,
– la ressource attendue,
– le nom du programme / job qui exécute la requête,
– l’instruction SQL en cours d’exécution dans le lot,
– le lot SQL complet,
– le plan de requête,
– les hashs de requête et de plan,
– le nombre d’exécutions du plan,
– la date de génération du plan,
– l’adresse IP de la machine exécutant la requête.

Toute suggestion est la bienvenue !

Mise à jour du 13/05/2011

ElSüket

Lorsque j’ai trouvé une requête dont je sais que l’activité disque est importante, je cherche à savoir pourquoi c’est le cas.
Je dois parfois ré-exécuter la requête sur le système pour comprendre ce que fait le moteur de base de données, et analyser quelles sont les tables qui subissent le plus de lectures.

Si l’on s’en tient à ce que propose SQL Server Management Studio, on obtient :

Il se peut que la requête contient un grand nombre de tables, et dans ce cas la lecture ce ce résultat peut être longue, surtout si l’on fait du tuning à longueur de journée
J’ai donc créé la feuille Excel que vous trouverez compressée.

Il suffit de copier le résultat affiché dans la console dans cette feuille, et d’exécuter la macro.
Dans le ruban d’Office 2007 ou 2010, après avoir sélectionné View, on peut voir les macros en cliquant sur le bouton du même nom :

La fenêtre suivante s’affiche :

Et il suffit de cliquer sur « Run ». Le résultat obtenu pour la même requête est alors :

Bon tuning !

ElSüket

Voyons comment retrouver ces événements :

De nombreux grossissements automatiques des fichiers de la base de données peuvent indiquer :

– que les fichiers de la base de données ont été mal taillés lors de la création de la base de données
– que l’incrément choisi pour le grossissement automatique est trop faible (par défaut c’est 1MB pour un fichier de données !)
– que des transactions (comme des recréations d’index), ou un changement d’un module SQL ou dans l’application supportée par la base de données génèrent beaucoup de données, et envisager des corrections.

On peut trouver la liste des événements et leur identifiant dans la documentation de la procédure stockée sp_trace_setevent.

J’ai utilisé cette procédure dans le tutoriel Création de fichiers de trace SQL Server Profiler côté serveur

On pourra trouver l’espace disque occupé par les fichiers, et l’espace libre dans ceux-ci.

Bonne gestion de fichiers !

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.