Voici deux guides de migration en Anglais vers SQLServer 2005 et 2008 publiés par Microsoft. Ils sont extrêmement complets (350 et 490 pages) et couvrent des sujets allant de la planification de la migration aux procédures à suivre dans le cas de migration de configurations à haute disponibilité en passant par les changements d’outils de management.

On lit souvent qu’un index a des effets néfastes sur les performances des requêtes en Update. J’ai réalisé un micro-benchmark sur une de nos tables internes afin de déterminer cet impact de manière un peu plus précise.

La table utilisée est une table de production de 8 555 648 lignes, pesant 550 Mo et ayant 8 colonnes. Une de ces colonnes est un champ Email unique et une autre est la date d’intégration dans la base au format datetime.

La requête que j’utilise est :

Update R_Temp.dbo.Email
set Date_In='04/09/2008'
where Email in ('test@gmail.com')
and Date_In is null

Voici le plan d’exécution estimé sur la table sans index :

Comme il n’y a pas d’index, SQLServer doit procéder à un Table Scan, c’est-à-dire parcourir entièrement la table afin de trouver les lignes correspondant à la requête. Voici les coûts de ce Scan :

Estimated I/O Cost : 52,1454
Estimated CPU Cost : 4,70565
Estimated Operator Cost : 56,8511
Estimated Subtree Cost : 56,8511

Continuer à lire "Influence du type d’index sur un Update"

Pour améliorer les performances des requêtes SQL la solution la plus souvent avancée est de « créer un index ». Cela n’est malheureusement pas aussi simple, les index n’optimisant pas certains types de requêtes, sans compter qu’il existe deux types majeurs d’index dont les avantages et les inconvénients varient. Il faut donc toujours procéder à une réflexion complète sur l’intérêt même de ces index par rapport aux problèmes qu’ils peuvent poser, mais aussi effectuer une série de tests afin de vérifier que les index ont bien une influence positive sur les performances des requêtes utilisées. Même une simple requête Select peut ne pas bénéficier d’un index.

Pour illustrer cela j ‘ai effectué un micro-benchmark sur SQLServer 2005 pour comparer les performances d’une table sans index (heap), d’un index ordonné (clustered) et d’un index non ordonné (nonclustered) sur la requête suivante :

Select count(*) from R_Temp.dbo.EMAIL where Email like ('frederic%')

La table compte 8 555 648 lignes, pèse 550 Mo et est constituée de 8 colonnes. Le champ Email est unique.

Voici le plan d’exécution estimé de cette requête sur la table sans index :

SQLServer doit ici parcourir toute la table (Table Scan) pour trouver les lignes correspondant à la requête et le coût est donc très élevé : elle s’exécute en 2,5 s sur mon serveur. 

Continuer à lire "Influence du type d’index sur un Select"

Afin de déterminer quels sont les utilisateurs qui monopolisent un serveur SQL Server il suffit d’utiliser la requête suivante :

SELECT
TOP 20
SPID, Blocked,
convert(varchar(10),db_name(dbid)) as Base,
CPU,
datediff(second,login_time, getdate())/60 as Minutes,
convert(float, cpu / datediff(second,login_time, getdate())) as PScore,
convert(varchar(16), hostname) as Hôte,
convert(varchar(20), loginame) as Login,
convert(varchar(50), program_name) as Programme
FROM master..sysprocesses
WHERE datediff(second,login_time, getdate()) > 0 and SPID > 50
ORDER BY PScore desc

Plus le PScore est élevé plus l’utilisation de la base est intensive.

De la même manière on peut déterminer les programmes les plus gourmands en observant la colonne BFactor lors de l’exécution de la requête suivante :

SELECT
convert(varchar(50), program_name) as Programme,
count(*) as CliCount,
sum(cpu) as CPUSum,
sum(datediff(second, login_time, getdate())) as SecSum,
convert(float, sum(cpu)) / convert(float, sum(datediff(second, login_time, getdate()))) as Score,
convert(float, sum(cpu)) / convert(float, sum(datediff(second, login_time, getdate()))) / count(*) as BFactor
FROM master..sysprocesses
WHERE spid > 50
GROUP BY
convert(varchar(50), program_name)
ORDER BY score DESC