Pour ceux qui se demandent comment interpréter les noms de statistiques créées automatiquement par l’optimisateur de requêtes ce billet est pour vous . Comme vous le savez sans doute lorsqu’un index créé des statistiques lui sont également associées. Ces dernières servent à l’optimisateur de requêtes afin de déterminer un plan optimal pour retrouver les données initiés par une requête. Autrement dit en fonction des cardinalités ou de la sélectivité des données sous jacentes celui-ci va déterminer quelle(s) méthode(s) il devra pour utiliser pour les retrouver avec un minimum de coût.  Cependant que se passe-t-il lorsqu’une requête composée d’un prédicat ne concerne pas un index ? He bien celui-ci va créer des statistiques sur la ou les colonnes concernées pour pouvoir estimer la cardinalité des données à retourner. Ces statistiques se retrouvent sous la forme _WA_Sys_00000004_0F382DC6 par exemple. Comment interpréter ce nom plutôt abscons à première vue. C’est ce que nous allons voir dans la suite de billet.

Lire la suite →

Il peut arriver parfois de vouloir retrouver un login Windows via son SID (ou Security Identifier) au format Windows sur une instance SQL Server. Le problème est que le SID stocké sur SQL Server est au format varbinary(85). Il nous faut donc formater la valeur de cette colonne pour pouvoir la mettre au format Windows S-X-X-XX-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXX-XXXX.

Lire la suite →

Chez un de mes clients qui utilise SCOM pour monitorer les jobs SQL en erreur voici ce que l’on peut voir comme message lorsqu’un job lié à la récupération des données avec data collector  (extraction ou updload) part en erreur : « Set_{xxxxxxxxxxxxxxxxx}_Master_package_Upload » Failed. Autant dire qu’avec ce type de message cela reste compliqué de savoir quel collection set, quel job SQL ou quel package SSIS est à l’origine de l’alerte. Voici un script SQL qui permet de déterminer rapidement ces informations.

Lire la suite →

Un petit billet sur un compteur que vous connaissez certainement tous et qui permet en autre de détecter une pression mémoire sur une instance SQL Server. Seulement en faisant un audit des compteurs de surveillance d’un de mes clients, je me suis aperçu qu’il n’utilisait que ce dernier pour détecter la présence ou non une pression mémoire sur l’ensemble des instances de son parc. Je lui ai donc expliqué que l’utilisation unique de ce compteur ne permettait pas à tous les coups de détecter un problème d’utilisation mémoire. Je vous propose de voir pourquoi dans ce billet.

Lire la suite →

En discutant avec un de mes clients, il me demandait s’il fallait forcément supprimer une base de données existante avant de la restaurer. La réponse est évidemment non. En effet, il est possible d’utiliser l’option REPLACE avec la commande RESTORE mais celui-ci se demandait alors s’il y avait au final une différence entre faire une suppression de bases de données via la commande DROP DATABASE suivie d’une restauration  et une restauration directe via la commande RESTORE et l’option REPLACE mis à part une simplification du code à écrire. Il y a en effet une voir plusieurs mais nous n’en traiterons qu’une seule dans ce billet et qui peut ne pas être négligeable dans certains cas.

Lire la suite →

Un des collègues (qui se reconnaitra ;-)) a rencontré un souci chez un de nos clients qui était plutôt étrange dirons nous. Le client voulait renommer le nom logique d’un de ces fichiers de bases de données et se retrouvait avec l’erreur « Msg 5041, Level 16, State 1, Line 1 MODIFY FILE ‘FileName’ failed. File does not exist. » alors que le fichier existait bien contrairement à ce que disait SQL Server. La version de SQL Server : 2008 R2 SP1. Nous voila parti à résoudre un problème bien curieux …

Lire la suite →

Scanner le réseau pour y retrouver les instances SQL Server installés peut être tâche ardue selon le contexte où l’on se trouve. Il existe bien la commande sqlcmd -L mais celles-ci comportent bien des défauts. En effet cet utilitaire lance un broadcast sur le réseau sur lequel il se trouve et attend la réponse des instances qu’il a pu atteindre. J’insiste bien sur la dernière partie de cette phrase « a pu atteindre ». Il existe bien des cas où aucune réponse ne sera retournée : l’instance SQL est cachée ou encore le service SQL Browser n’est pas activé et des instances nommées écoutent sur un port différent que le port 1433 ou encore d’autres sous réseaux ne peuvent pas être atteint par la requête broadcast etc … bref autant de raisons qui font que l’utilisation de sqlcmd n’est pas forcément judicieuse dans ce cas. Voici un script powershell qui permet de recenser l’ensemble des instances SQL beaucoup plus précisement que la commande sqlcmd ou autre méthode utilisant ce principe.

Lire la suite →

our ceux qui ont déjà tenté l’expérience, la migration d’un plan de maintenance sous SQL Server réserve quelques surprises. En effet, la connexion locale associée au package n’est pas modifiable et il faut à posteriori  créer une nouvelle connexion et modifier les tâches du plan en conséquence pour qu’elles prennent en compte la nouvelle connexion. Il va sans dire que cela n’est pas forcément pratique et bien souvent on préfère recréer le plan de maintenance sur le nouveau serveur soit "from scratch" soit avec des copier-coller. De la même manière si on veut changer le propriétaire d’un job lié à un plan de maintenance on se retrouve rapidement confronté à quelques difficultés. Le fait de changer le propriétaire d’un job est plutôt facile en soi mais si on modifie et revalide le plan de maintenance par la suite celle-ci écrase notre changement de propriétaire. L’astuce consiste à changer le propriétaire du package SSIS associé au plan de maintenance concerné. Voici une procédure qui vous permettra de changer rapidement ces 2 paramètres après migration.

Lire la suite →