120
Chapitre 5. Analyse des performances
Attention – Le dernier paramètre (mode) doit être indiqué à une valeur différente de LIMITED ou NULL (qui équivaut à LIMITED), sinon toutes les valeurs de la colonne forwarded_record_count seront renvoyées à NULL.
Ne vous inquiétez pas d’un nombre raisonnable de Forwarded Records/sec, cela
peut arriver dans des tables temporaires sur tempdb. Vérifiez alors le nombre de tables
temporaires, et le nombre de transactions dans tempdb. Si la valeur ne correspond pas
à une activité de tempdb, cherchez dans votre base utilisateurs quelles sont les tables
heap qui contiennent des renvois d’enregistrements, à l’aide de la fonction précédente. Pour diminuer le nombre de renvois, vous pouvez soit faire un shrink (DBCC
SHRINKDATABASE ou DBCC SHRINKFILE) de votre base de données, ce qui est une mauvaise solution en soi, sauf si vous faites un shrink sans diminuer la taille physique du
fichier, à l’aide de l’option NOTRUNCATE :
DBCC SHRINKDATABASE (AdventureWorks, NOTRUNCATE);
Cela réorganise les pages sans diminuer la taille des fichiers. La vraie bonne solution reste toutefois de réorganiser la table en créant un index clustered, que vous pouvez supprimer ensuite si vous tenez absolument à conserver une table heap (il n’y
aurait pas de raison, la table clustered est à recommander) 1 .
Attention – Les augmentations et diminutions automatiques des fichiers de données et de journal sont très pénalisantes pour les performances, et génèrent une
fragmentation importante. Elles sont à éviter.
MSSQL:Access Methods\Full Scans/sec
Indique un nombre de scans de table (table heap ou index clustered) par seconde. Le
scan de table n’est pas un problème en soi sur les petites tables, il est par contre très
pénalisant sur les tables à partir d’une taille raisonnable (s’entend en nombre de
pages. Une table contenant beaucoup de lignes contenant des colonnes de petite
taille peut provoquer moins de lectures qu’une table ayant moins de lignes, mais
contenant des colonnes plus grandes). Ce compteur est utile pour détecter un
manque d’index ou des requêtes mal écrites. Un scan provient soit d’un manque
index utile pour résoudre la clause de recherche (qu’il soit absent ou trop peu
sélectif), soit de la présence de requêtes qui ne filtrent pas (ou mal) les données, par
exemple de requêtes sans clause WHERE. Pour plus de détails, reportez-vous au
chapitre 6.
1. Plus d’informations sur les problèmes de performances possibles sur des renvois d’enregistrements dans cette entrée de blog : http://blogs.msdn.com/mssqlisv/archive/2006/12/01/knowingabout-forwarded-records-can-help-diagnose-hard-to-find-performance-issues.aspx
Chapitre 5. Analyse des performances
Attention – Le dernier paramètre (mode) doit être indiqué à une valeur différente de LIMITED ou NULL (qui équivaut à LIMITED), sinon toutes les valeurs de la colonne forwarded_record_count seront renvoyées à NULL.
Ne vous inquiétez pas d’un nombre raisonnable de Forwarded Records/sec, cela
peut arriver dans des tables temporaires sur tempdb. Vérifiez alors le nombre de tables
temporaires, et le nombre de transactions dans tempdb. Si la valeur ne correspond pas
à une activité de tempdb, cherchez dans votre base utilisateurs quelles sont les tables
heap qui contiennent des renvois d’enregistrements, à l’aide de la fonction précédente. Pour diminuer le nombre de renvois, vous pouvez soit faire un shrink (DBCC
SHRINKDATABASE ou DBCC SHRINKFILE) de votre base de données, ce qui est une mauvaise solution en soi, sauf si vous faites un shrink sans diminuer la taille physique du
fichier, à l’aide de l’option NOTRUNCATE :
DBCC SHRINKDATABASE (AdventureWorks, NOTRUNCATE);
Cela réorganise les pages sans diminuer la taille des fichiers. La vraie bonne solution reste toutefois de réorganiser la table en créant un index clustered, que vous pouvez supprimer ensuite si vous tenez absolument à conserver une table heap (il n’y
aurait pas de raison, la table clustered est à recommander) 1 .
Attention – Les augmentations et diminutions automatiques des fichiers de données et de journal sont très pénalisantes pour les performances, et génèrent une
fragmentation importante. Elles sont à éviter.
MSSQL:Access Methods\Full Scans/sec
Indique un nombre de scans de table (table heap ou index clustered) par seconde. Le
scan de table n’est pas un problème en soi sur les petites tables, il est par contre très
pénalisant sur les tables à partir d’une taille raisonnable (s’entend en nombre de
pages. Une table contenant beaucoup de lignes contenant des colonnes de petite
taille peut provoquer moins de lectures qu’une table ayant moins de lignes, mais
contenant des colonnes plus grandes). Ce compteur est utile pour détecter un
manque d’index ou des requêtes mal écrites. Un scan provient soit d’un manque
index utile pour résoudre la clause de recherche (qu’il soit absent ou trop peu
sélectif), soit de la présence de requêtes qui ne filtrent pas (ou mal) les données, par
exemple de requêtes sans clause WHERE. Pour plus de détails, reportez-vous au
chapitre 6.
1. Plus d’informations sur les problèmes de performances possibles sur des renvois d’enregistrements dans cette entrée de blog : http://blogs.msdn.com/mssqlisv/archive/2006/12/01/knowingabout-forwarded-records-can-help-diagnose-hard-to-find-performance-issues.aspx