Un article msdn expliquant le mappage utilisé par LINQ entre les types SQL et CLR.

La partie la plus intéressant reste la matrice montrant quels types SQL est compatible avec quels type CLR. Le mappage n'est évidement pas de type 1:1.

Récement, j'ai experimenté quelqeus soucis avec un POC Merge Replication :

80004005 : Failure to connect to SQL Server

Le Merge Replication n’abouti pas. L’erreur ‘OpenDB failed getting pub version 28627’ est loguée dans le fichier SQLCESA30.LOG.

Liste des contrôles à effectuer :

• S’assurer que le serveur de réplication fonctionne correctement :
  http://nomduserveur/ssce/sqlcesa30.dll?diag
• Contrôler dans le fichier log (C:\Program Files\Microsoft SQL Server 2005 Mobile Edition\Server\SSCE\SQLCESA30.LOG) que l’entrée ‘Hr=00000000 SQLCESA30.DLL loaded 0’

Vérifier le transport en effectuant des ‘ping’ entre Publisher, Distributor &Replication.

• Si un des serveur ne répond pas, vérifier que le firewall est à off.

Vérifier que les différents serveurs (Publisher, Distributor & Replication) communiquent correctement :

• depuis le serveur de réplication :
  o osql –S PUBLISHER –E
  o osql –S DISTRIBUTOR –E
• etc sur les autres serveurs ...

Si la communication ne fonctionne pas, vérifier dans ‘SQL Server Surface Area Configuration’ que les connections locales et distantes sont autorisées.

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.textFROM sys.dm_exec_query_stats
T1 CROSS APPLY
sys.dm_exec_sql_text(T1.plan_handle) T2     GROUPBY         T1.plan_handle,
        T2.textORDERBY     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.textFROM sys.dm_exec_query_stats
T1 CROSS APPLY
sys.dm_exec_sql_text(T1.plan_handle) T2     GROUPBY         T1.plan_handle,
        T2.textORDERBY     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.textFROM sys.dm_exec_query_stats
T1 CROSS APPLY
sys.dm_exec_sql_text(T1.plan_handle) T2     GROUPBY         T1.plan_handle,
        T2.textORDERBY         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.textFROM sys.dm_exec_query_stats
T1 CROSS APPLY
sys.dm_exec_sql_text(T1.plan_handle) T2     GROUPBY         T1.plan_handle,
        T2.textORDERBY         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 INNERJOIN sys.dm_db_missing_index_groups
T2     ON T2.index_group_handle
= T1.group_handle INNERJOIN 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 ORDERBY     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 INNERJOIN sys.indexes
T2     ON T1.OBJECT_ID =
T2.OBJECT_ID     AND T1.INDEX_ID
= T2.INDEX_ID INNERJOIN sys.tables
T3     ON T3.OBJECT_ID =
T2.OBJECT_IDWHERE     T1.avg_fragmentation_in_percent
> 5     AND T2.Name ISNOTNULLORDERBY     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)