Requêtes ayant été les plus exécutées

Les DMV sys.dm_exec_query_stats, en association avec sys.dm_exec_sql_text, permet de connaître les requêtes ayant été les plus exécutées.

SELECT TOP 50    
        SUM(T1.execution_count),
        T2.text
FROM  
    sys.dm_exec_query_stats T1 
CROSS APPLY sys.dm_exec_sql_text(T1.plan_handle) T2    
GROUP BY 
        T1.plan_handle,
        T2.text
ORDER BY 
    SUM(T1.execution_count) 
DESC

Requêtes ayant consommées le plus de cycle I/O

Les DMV sys.dm_exec_query_stats, en association avec sys.dm_exec_sql_text, permet de connaître les requêtes ayant consommées le plus de cycle I/O.

SELECT TOP 50    
        SUM(T1.total_physical_reads + T1.total_logical_reads + T1.total_logical_writes),
        T2.text
FROM  
    sys.dm_exec_query_stats T1 
CROSS APPLY sys.dm_exec_sql_text(T1.plan_handle) T2    
GROUP BY 
        T1.plan_handle,
        T2.text
ORDER BY 
    SUM(T1.total_physical_reads + T1.total_logical_reads + T1.total_logical_writes ) 
DESC

Requêtes ayant consommées le plus de cycle CPU

Les DMV sys.dm_exec_query_stats, en association avec sys.dm_exec_sql_text, permet de connaître les requêtes ayant consommées le plus de cycle CPU.

SELECT TOP 50
    SUM(T1.total_worker_time), 
    T2.text
FROM  
    sys.dm_exec_query_stats T1 
CROSS APPLY sys.dm_exec_sql_text(T1.plan_handle) T2    
GROUP BY 
        T1.plan_handle,
        T2.text
ORDER BY 
        SUM(T1.total_worker_time) 
DESC

Requêtes ayant souffert de blocages

Les DMV sys.dm_exec_query_stats, en association avec sys.dm_exec_sql_text, permet de connaître les requêtes ayant le plus souffert de blocages (le temps d’exécution est supérieur au temps ‘travaillé’, signifiant que la requête à été victime temporairement d’un blocage).

SELECT TOP 50    
        SUM(T1.total_elapsed_time - T1.total_worker_time),
    T2.text
FROM  
    sys.dm_exec_query_stats T1 
CROSS APPLY sys.dm_exec_sql_text(T1.plan_handle) T2    
GROUP BY 
        T1.plan_handle,
        T2.text
ORDER BY 
        SUM(T1.total_elapsed_time - T1.total_worker_time ) 
DESC

Les DMV dm_db_missing_index_* permettent de déterminer les indexes manquants. Ces informations sont basées sur l’analyse de l’exécution des requêtes depuis le démarrage de SQL-Server 2005.

Quatre DMV permettent d’obtenir des informations, d’un point de vue générale  jusqu’au détail (détail de colonnes à indexer).

La hiérarchie est la suivante :
dm_db_missing_index_group_stats          Information générale
-> dm_db_missing_index_groups             Information sur un groupe d’indexes
     -> dm_db_missing_index_details        Information sur un index
          -> dm_db_missing_index_columns Information des colonnes d’un index

Le calcul de la priorité (l’importance) de création d’un index est basé sur trois paramètres :
1. Le coût
2. l’impacte
3. le nombre de lecture

En effet, créer un index sur une table n’ayant qu’un index primaire aura un grand impact sur la performance. Par contre, si cette table n’est accédée qu’un fois pas année, la création de cet index ne devrait pas être un priorité. Mieux vaut alors insérer un index sur une table accédée de miliers de fois par minutes, même si l’impacte par requête est faible.

La requête suivante indique les indexes manquant a créer, par ordre de priorité (selon le calcule ci-dessus) :

SELECT 
    T1.avg_total_user_cost * T1.avg_user_impact * (T1.user_seeks + T1.user_scans) AS 'Priorite', 
        T3.*
FROM 
    sys.dm_db_missing_index_group_stats T1
INNER JOIN sys.dm_db_missing_index_groups T2 
    ON T2.index_group_handle = T1.group_handle
INNER JOIN sys.dm_db_missing_index_details T3 
        ON T3.index_handle = T2.index_handle
WHERE
        T3.database_id = 8 – A remplacer par l’ID de la base désirée
ORDER BY 
    avg_total_user_cost * avg_user_impact * (user_seeks + user_scans)
DESC;

Note :
Le résultat des DMV est le reflet de la base lors de l’execution des DMV. Lors de la création d’indexes basé sur ces vues, prendre soins de sauvegarder les informations. En effet, suite à la création d’un index, les DMV vont réévaluer les informations.

Un index est fragmenté lorsque l’ordre logique des informations stockées dans les pages (basée sur les clés de l’index) ne correspondent plus à l’ordre physique des informations stockées dans les fichiers de données.

SQL-Server 2005 offre deux possibilités :
- La réorganisation de l’index
   S’applique lorsque le taux de fragmentation de l’index se situe entre 5% et 30%.
- La reconstruction de l’index
   S’applique lorsque le taux de fragmentation de l’index est supérieur à  30%.

La DMV sys.dm_db_index_physical_stats nous renseigne sur le taux de fragmentation. La requête suivante liste tous les indexes d’un serveur (pour lister uniquement une base, changer le premier paramètre de la DMV), dont le taux de fragmentation est supérieur à 5%.

SELECT 
    T3.Name AS Table_Name, 
    T2.Name AS Index_Name,
    T1.avg_fragmentation_in_percent
FROM 
    sys.dm_db_index_physical_stats(null,null,null,null,null) AS T1 
INNER JOIN  sys.indexes T2 
    ON  T1.OBJECT_ID = T2.OBJECT_ID 
    AND T1.INDEX_ID = T2.INDEX_ID 
INNER JOIN  sys.tables T3 
    ON T3.OBJECT_ID = T2.OBJECT_ID 
WHERE 
    T1.avg_fragmentation_in_percent > 5 
    AND T2.Name IS NOT NULL 
ORDER BY 
    T1.avg_fragmentation_in_percent 
DESC

Un index devient inutiles lorsque le nombre de mise à jour de l’index (update) est supérieur au nombre fois que cet index est utilisé pour une lecture (seeks, scans & lookup). Le moteur passe donc plus de temps à le maintenir à jour qu’il n’est réellement utilisé … C’est comme maintenir un annuaire téléphonique à jour alors que les abonnées utilisent d’autre moyen (carnet d’adresse local, …) pour se contacter.

La DMV sys.dm_db_index_usage_stats nous donne ces informations :

SELECT
     user_updates AS '#ECRITURE', 
    user_seeks + user_scans + user_lookups AS '#LECTURE'
FROM 
        sys.dm_db_index_usage_stats
WHERE
        user_updates > (user_seeks + user_scans + user_lookups)

J’ai cherché comment rendre une méthode obsolète en .NET. En effet, j’ai crée une nouvelle méthode lors de l’évolution d’un projet, mais ne pouvais pas supprimer (ou remplacer) l’ancienne méthode.

La solution est simple : il suffit d’ajouter l’attribut [Obsolete]

Trois signature s’offrent à nous :

[Obsolete]

void Methode() {}

Qui indiquera simplement, via intellisense, que la méthode est obsolète

[Obsolete(« Cette méthode à été remplacée par XXX » )]

void Methode() {}

Qui indiquera simplement, via intellisense, que la méthode est obsolète en indiquant la raison.

[Obsolete(« Cette méthode à été remplacée par XXX », true )]

void Methode() {}

Générera en plus une erreur lors de la compilation.

Disponible sous Wikipedia ici.

Scott Guthrie, General Manager de la division Developer chez Microsoft, vient de larguer une petite bombe sur son blog …

Le code source de l’implémentation de Framework .NET 3.5 sera disponible en lecture (pas de modification).  De plus, ces sources seront intégrées directement dans Visual Studio 2008. Cela veux dire qu’en mode debug, il sera possible de faire du pas à pas dans son propre code. Si la méthode appelée est une méthode du Framework, VS fera alors du pas à pas dans le code du Framework …

La seule initiative de ce type que je connaisse chez MS était le projet Rotor, qui proposait en 2002 de partager une partie des sources code utilisées pour la CLR. C’était les prémices du Framework .NET et permettait de comprendre en partie la plomberie interne de la CLR.

Le post de Scott Guthrie (avec quelques copies d’écans).

Le post sur le même sujet de Shawn Burke, chef de ce projet chez MS.