Catégorie: Architecture

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 modification de la longueur d'une colonne de table est une opération plutôt courante dans la vie d'un administrateur de bases de données mais qu'en est il du stockage interne ? Beaucoup de gens pensent par exemple que diminuer la longueur d'une colonne permet de récupérer de l'espace de stockage ou que d'augmenter la longueur d'une colonne n'a que très peu d'impact. Rien de ceci n'est vrai et nous le verrons dans la suite de ce billet.

» 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!

Les index filtrés ont été introduit à partir de la version SQL Server 2008. Il existe déjà un certain nombre d'exemples qui illustrent leur intérêt et je vous invite à les regarder si cela n'est déjà fait (voir le billet d'Elsuket). Mais qu'en est il du stockage ? En effet la question peut sembler légitime car les index filtrés ne comportent que les lignes de données qui correspondant à sa définition. Nous verrons comment SQL Server gère ces index en interne.

» Lire la suite!

Le dump d'une page de données SQL Server est plutôt indigeste à lire lorsqu'il s'agit de lire les lignes de données présentes dans la page. Je me suis amusé à regarder s'il était possible de pouvoir déchiffrer cet agglomérat de valeurs hexadécimales. Avec de la documentation et un peu d'entrainement on y arrive et on apprend tout un tas de choses surprenantes.

» Lire la suite!