Pour ceux qui utilisent la DMV sys.dm_db_index_physical_stats depuis la version 2005 de SQL Server ont certainement vu une colonne nommée fragment_count. La documentation Microsoft nous donne la description suivante : Nombre de fragments dans le niveau feuille d’une unité d’allocation IN_ROW_DATA. J’ai déjà eu pas mal de questions à ce sujet car même avec la description fournie nous pouvons avoir du mal à visualiser ce que cette colonne représente exactement et quelle peut être la relation avec la fragmentation des indexes.

Lire la suite →

Vous avez identifié une table candidate à la compression ? mais vous voulez savoir quelle sera la meilleure méthode de compression ROW ou PAGE. SQL Server met à disposition une procédure stockée sp_estimate_data_compression_savings. Cependant  l’exécution de cette dernière permet seulement de savoir le taux de compression pour l’une ou pour l’autre méthode pour une seule partition d’une table à la fois. Le script suivant permet de connaître pour une table donnée quelle est la meilleure méthode de compression à utiliser pour l’ensemble des partitions d’une table sachant qu’une table non partitionnée possède une seule partition.

Lire la suite →

La création d’une trace profiler est un passage quasi obligatoire lorsqu’il s’agit d’auditer les performances et les ressources monopolisées  des requêtes, lots de requêtes ou des procédures stockées qui s’exécutent sur le serveur de bases de données lors d’un audit. Bien qu’il existe les DMV depuis la version 2005, celles-ci ne peuvent être réellement utilisées qu’après une période significative de fonctionnement du serveur. Par conséquent il est plus intéressant de les utiliser dans un contexte de production que dans celui d’un audit ponctuel.

De plus, il peut exister plusieurs exécutions d’une même requête ou procédure dans une trace profiler mais avec des paramètres différents. Une question peut alors se poser : comment connaître les durées et consommations globales des différents modèles de requêtes (indépendamment de la valeur des paramètres utilisés) et pouvoir ainsi mettre l’accent sur l’optimisation de certains modèles de requêtes ?

Lors de mon dernier audit, j’ai également dû répondre à la problématique suivante : le serveur de bases de données comportait plusieurs instances SQL Server. Dans un tel cas, comment connaitre le ratio entre la consommation d’une requête exécutée sur une instance et celle de l’ensemble des instances présentes sur ce même serveur ? Cela peut être utile pour cibler les requêtes ou procédures les plus consommatrices à l’échelle du serveur et pour lesquelles il est utile de revoir la conception.

Le script suivant permet de répondre aux deux problématiques décrites ci-dessus.

Lire la suite →

Dans la plupart des cas, une base de données comporte un seul fichier journal. Il peut arriver qu’il soit nécessaire de rajouter un ou plusieurs fichiers au journal des transactions à cause d’un manque d’espace libre sur une partition par exemple. Comment se remplit le journal dans ce cas ? Comment s’effectue l’allocation de nouveaux VLF dans plusieurs fichiers ? C’est ce que nous verrons dans ce billet.

Lire la suite →

Il est parfois nécessaire de déplacer certains fichiers journaux d’une base de données. Les causes peuvent être multiples : changement dans l’architecture du sous-système disque, espace disque insuffisant . Cette opération est, dans un cas classique, relativement simple mais lorsqu’il s’agit d’une topologie log-shipping cela peut compliquer un peu les choses. Nous verrons dans ce billet comment déplacer les fichiers journaux d’une base de données selon si l’on se trouve sur le primaire ou le secondaire.

Lire la suite →

Un collègue m’a demandé il y a quelques temps, quelle était la différence entre un index non cluster classique et un index non cluster avec colonnes incluses ? Cette question est venue suite à la création de ce type d’index (avec colonnes incluses) pour couvrir certaines colonnes demandées par une requête et éviter ainsi une recherche par pointeur sur l’index cluster qui pouvait être contre performant dans ce cas car elle concernait une table très volumineuse. Dans ce billet, on verra quelle est la différence entre ces deux types d’index et comment SQL Server stocke en interne les index avec colonnes incluses.

Lire la suite →