Le billet du jour est lié aux plans de maintenance “automatique”. En effet, je vois souvent des SI dans lesquels l’administrateur ou l’équipe de développement sont fiers de m’annoncer qu’ils ont mis des plans de maintenance en place pour gérer la fragmentation.

C’est bien sauf que, si la base est conséquente, ces maintenances automatiques peuvent faire plus de tort que de bien.

En effet, le composant Rebuild Index Task, dans sa configuration par défaut reconstruit TOUS les index de TOUTES les tables.

Le problème est que si vous avez des tables importantes (plusieurs millions de lignes et plusieurs Go de données), reconstruire l’index CLUSTERED peut être une opération lourde :

• Remplissage du LOG (si vous êtes en RECOVERY FULL)
• Lock de la table (si vous êtes en Standard Edition)
• Opération longue

D’autant plus que la tâche génère un script SQL par ordre alphabetique des index et non dans un ordre logique. On reconstruirait normalement les CLUSTERED puis les NON-CLUSTERED.

Bref, j’ai été confronté à des situations où cette tâche engendrait plus de problèmes qu’elle n’en résolvait. Par exemple, la tâche qui dure jusqu’au petit matin, se superposant à un autre plan de maintenance (le backup), dégradant les performances d’un job de synchro, etc.

La solution

La solution consiste à faire un job un peu plus complexe. L’idée est de se baser sur la vue système nous donnant les infos de fragmentation : sys.dm_db_index_physical_stats. Déjà, on peut filtrer sur les index les plus fragmentés (> 25/30% pour moi).

On croise ensuite avec les infos de l’index (type CLUSTERED ou non) et les infos de volumétrie (nombre de lignes) que l’on trouve respectivement dans sys.indexes et sys.partitions.

A partir de ces informations, je peux donc obtenir dynamiquement les instructions à jouer.

SELECT
    Schema_Name(o.schema_id) as SchemaName,
    OBJECT_NAME(stat.object_id) as TableName,
    ix.name, stat.index_id,
    avg_fragmentation_in_percent, ix.fill_factor, rows,
    'Alter Index ['+ ix.name
        + '] on [' + Schema_Name(o.schema_id)
        + '].[' + OBJECT_NAME(stat.object_id)
        + '] Rebuild' as Statement
FROM sys.dm_db_index_physical_stats(
    DB_ID('AdventureWorks'),
    NULL,
    NULL, NULL, NULL) stat
  inner join sys.indexes ix
    on ix.index_id = stat.index_id
    and ix.object_id = stat.object_id
  inner join sys.partitions p
    on ix.index_id = p.index_id
    and ix.object_id = p.object_id
  inner join sys.objects o on stat.object_id = o.object_id
where avg_fragmentation_in_percent > 25
order by index_id, avg_fragmentation_in_percent desc

Je prends toutefois ces informations avec précaution. En effet, j’essaie d’avoir une idée de la durée de chaque reconstruction en fonction de la volumétrie. Ceci pour faire ma planification au mieux. Par exemple si en testant (eh oui, le test reste primordial) je m’aperçois que la reconstruction de tel index prends 35 minutes, je l’isole et le planifie à part, à un moment où cela ne va pas gêner les autres tâches.

Pour cela, il suffit de bien connaître sa base et ce qui s’y passe.

Epilogue

Malgré toute la pédagogie que nous pouvons faire lors de formation, consulting, projets, etc., les développeurs ne sont pas encore assez vigilants aux problématiques de base de données et pensent qu’un produit comme SQL Server se maintient tout seul à un haut niveau de performance. Je prends souvent la métophore avec l’automobile. Cela fait quelques siècles que ça existe et pourtant vous allez toujours au garage régulièrement .

Evidemment, loin de moi l’idée d’entretenir le clivage DBA/développeurs. Mon métier de consultant me place bien souvent au milieu et je privilégie la pédagogie.

Donc la règle à retenir : SQL Server est un produit puissant mais complexe, faites-vous aider par des spécialiste.

Réponse :

Revenons un peu sur le Soundex. Le Soudex est une méthode qui permet de savoir si 2 mots sont ressemblants, phonétiquement parlant. Pour cela, on traite le mots en rapprochant les sons, en supprimant les éléments inutiles (doubles lettres, etc.) et on obtient une sorte de Hash du mot le représentant. On peut ensuite les comparer avec une fonction de distance.

Le Soundex est sympa à la base mais contrairement à la recherche FullText, Microsoft n’a jamais fait d’effort pour le promouvoir. Il existe de nombreux algorithmes de Soundex, Microsoft utilise le sien, mais forcément qui ne fonctionne pas dans tous les cas, notamment en multilingue.

Pour contourner cela, te faut soit acheter un composant tout prêt qui corresponde mieux au besoin ou à la langue. Soit l’implémenter soi-même avec une fonction CLR par exemple.

Frédéric Brouard a fait un super article sur le Soundex et propose des algos :

http://sqlpro.developpez.com/cours/soundex/