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/

Si vous n’avez pas pu venir ou si vous souahitez la revoir, suivez ce lien : http://www.microsoft.com/france/vision/mstechdays09/Webcast.aspx?eID=1b96e365-db8a-4339-91b6-c217c9a15423

Le sujet est simple : Présentation générale de SQL Server 2008. 

C’est une session Découverte (Level 100) donc je ne fais que survoler les fonctionnalités de la nouvelle version, ce qui est déjà difficile en 1h. Cette session a été aussi le lieu pour le témoignage client de Christophe Laporte, DBA d’Index Multimédia qui est venu faire un retour sur la migration qu’il a opéré et les gains apportés par la nouvelle version de la base de données.   

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=66ab3dbb-bf3e-4f46-9559-ccc6a4f9dc19

Les habituels frileux des nouvelles versions n’auront plus d’excuse pour passer à SQL Server 2008.

Qu’apporte ce Service Pack :

• Des corrections de bugs évidemment (d’où l’importance de remonter les infos sur Connect) – je ne pense pas avoir le temps de vous en détailler…
• Report Builder 2.0 en mode click-once (je sais que du monde l’attendait )
• La possibilité d’inclure le SP1 dans une installation de base ce qui permet d’installer SQL Server 2008 ET le SP1 en une fois (accélération des migrations sur des environnements de production) – cette fonctionnalité s’appelle Splistream

PS : Je ne suis pas très attentif et assidu ces derniers temps en partie à cause d’une BDC 2009 à préparer, d’un projet de Business Intelligence en cours et d’autres raisons qu’il est prématuré d’annoncer. Je m’en excuse dans ce billet. D’autant plus que j’ai des milliers de sujets dans les cartons…

Aujourd’hui, j’étais au TechDays, l’événement majeur technique de Microsoft en France.

Comme l’année dernière, j’étais Speaker et cette fois sur la session de présentation générale SQL Server 2008. C’était du level 100, donc assez généraliste mais j’ai pu présenter les avantages de la version 2008 pour les entreprises, les administrateurs, les développeurs, les information workers, etc. sur les sujets que sont la fiabilité, la productivité et la (business) intelligence.

J’ai pu interviewer en direct mon ancien collègue et ami Christophe Laporte, DBA d’Index Multimedia, qui traite des Teraoctets de données en environnement haute-disponibilité, sur les apports qu’il a constaté avec SQL Server 2008 en production. Sa fonctionnalité préférée reste la compression (à tous les niveaux) qui lui fait gagner du temps, de la CPU, de l’espace disque (et du stress en moins).

Il y avait environ 200 personnes à cette session et de nombreuses questions. Merci à Lionel et Patrick de Microsoft pour leur assistance. 

Cet article parle d’un problème commun à toute application (de gestion), à savoir la recherche d’éléments dans une base de données avec plusieurs critères (non connus à l’avance – d’où l’aspect dynamique).

Le sujet est traité par les aspects techniques et permet de parler de SQL dynamique, SQL statique, optimisation de jointure, vues, fonctions de table, etc. L’article est touffu et assez pointu mais vous pouvez le lire comme un recueil de Tips. Attention, l’article parle de la version 2005 de SQL Server ! Il y a un update d’Erland sur son site pour les spécificités de la version 2008, mais cet article reste une bonne base pour enrichir sa culture DGD. Un must-have comme on dit

Si vous allez sur le site d’Erland, en Anglais, ne vous fiez pas à sa présentation tout droit ressortie des années 90, filez directement sur le contenu technique qui est une vrai mine d’or pour comprendre le fonctionnement du moteur SQL. J’espère un jour pouvoir tous les traduire pour en faire profiter un public francophone mais l’exercice est long et le temps est une denrée rare.

L’article se trouve comme d’habitude sur le site de Bewise, où vous pouvez retrouver de nombreuses ressources (articles, webcasts news) sur les technologies Microsoft :

http://www.bewise.fr/article/116/Recherche-multi-criteres-avec-SQL-Server.aspx

Avec la version 2008 de Reporting Services c’est désormais possible sans avoir à faire une gymnastique compliquée et contre performante dans la requête. En effet, les nouveaux composants de graphes incorporent cette fonctionnalité. Malheureusement elle n’est disponible que sur les graphes de type camemberts (secteurs).

Cette fonctionnalité est un peu difficile à trouver. Il faut en effet sélectionner la série, afficher les propriétés et modifier les Custom Attributes et changer les attributs CollectedStyle et CollectedThreshold. Dans Visual Studio, on trouve ces propriétés dans la Property Grid. Dans Rebord Builder, il fauda passer par le menu Affichage pour afficher la Property Grid qui n’est pas accessible par défaut.

Dans notre exemple, on consolide tout ce qui est inférieur à 20% dans « Autres »

Si vous trouvez intéressant que cette fonctionnalité soit étendue aux autres types de graphes, n’hésitez pas à voter sur Connect : https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=389944

On peut certes être dérouté par ces annonces que l’on peut qualifier de prématurées. Mais l’un des messages associé à la sortie de SQL Server 2008 fut une cassure dans le rythme des releases avec des fonctionnalités plus autonomes et par l’occasion plus fréquentes.

C’est dans cette lignée que s’inscrivent les annonces faites lors de la dernière BI Conference à Seattle ou à la dernière PDC à Los Angeles.

L’annonce phare est Kilimanjaro, la prochaine version de SQL Server, prévue pour 2010. Cette version considérée comme « mineure » ne verra pas de changement dans les différents moteurs (SQL, OLAP, etc.) mais des améliorations pour l’utilisateur et dans la gestion des serveurs.

Cette release se focalise aussi sur des avancées dans le domaine du décisionnel ; entre autres, 2 projets ont été présentés : Gemini et Madison.

Gemini est un module lié à Excel, qui permet de traiter efficacement, en mémoire, plusieurs millions de lignes de données. Destiné aux utilisateurs finaux, il rapproche la Business Intelligence des clients. En plus d’être un add-in à Excel, Gemini est aussi une formidable opportunité d’introduire la puissance d’Analysis Services dans le monde des utilisateurs d’Excel, estimés à plusieurs centaines de millions, comme a essayé de le faire Performance Point avec ProClarity.

Madison est un projet qui vient de l’acquisition de DATAllegro par Microsoft cet été et qui marque d’une pierre blanche l’ambition de ce dernier à pénétrer le marché des très gros volumes. Madison est la solution pour paralléliser les requêtes sur une batterie de serveurs, permettant une montée en charge plus importante.  Madison devrait se présenter sous la forme d’un module additionnel et est prévu en même temps que Kilimanjaro.

Côté relationnel, c’est plutôt vers Azure que se tourne l’avenir. En deux mots, Azure est la proposition de Microsoft en terme de Cloud Computing. C’est globalement une nouvelle vision du développement d’applications, très orientée services, sur une solution d’hébergement en haute disponibilité avec montée en charge proposée par Microsoft.  Dans cet univers, le stockage de données prend une place importante avec 2 briques : SQL Services et Azure Table Storage.

SQL Services est l’équivalent de SQL Server mais hébergé sur le « Cloud ». Actuellement, seule la brique relationnelle (SQL Data Services) est disponible en beta. Elle permet de stocker des entités relationnelles, accessibles de n’importe où via SOAP ou REST. Pour l’instant, cette brique est très limitée en termes de fonctionnalités mais devrait s’enrichir dans les mois à venir pour devenir une vraie base de données online, incluant même des modules décisionnels de datawarehousing, de reporting et d’analyse.

Rassurons nous, SQL Services n’a pas vocation à remplacer le traditionnel SQL Server (cf. Kilimanjaro) mais complète l’offre de Microsoft et ouvre de nouvelles perspectives comme le paiement à l’utilisation, plus économique pour de nombreux clients.

Azure Table Storage s’appuie techniquement sur les « tables » de SQL Data Services. La différence est sur la richesse fonctionnelle. Azure Table Storage est très limité (pas de jointures par exemple) et répond à des petits besoins en stockage de données. A ne pas en douter, la différence s’en ressentira  sur le prix des licences, qui, soit dit en passant, reste la grande interrogation sur l’univers Azure.

Evidemment, en cette fin d’année 2008, toutes ces informations sont à tempérer car les différentes phases de développement redéfiniront peut-être les modalités de mise en œuvre de ces ambitions. Rendez-vous début 2009 pour la première CTP de Kilimanjaro et les prochaines annonces sur Azure.

J’espère que ce petit article vous apporte des réponses sur la stratégie de Microsoft pour les années à venir. L’équipe de consultant de Bewise son à votre disposition pour compléter ces éclairages et vous présenter plus en détail ces nouvelles technologies.

Cet article présente brièvement les nouvelles fonctionnalités et les améliorations de SQL Server 2008, avec quelques exemples de code.

Son intérêt est qu’il est facile d’accès et quasi exhaustif. Je m’en sers moi même comme pense-bête (oui, j’ai une cervelle de moineau ).

J’ai mise cet article à disposition sur le site de Bewise et donc à la disposition de tous. Comme d’habitude, n’hésitez pas à le commentez, vos retours sont les bienvenus.

http://www.bewise.fr/article/114/Les-nouveautes-de-SQL-Server-2008.aspx

Quelques extraits choisis :

[...]

SPARSE columns : le concept de Sparse columns représente les colonnes à faible densité comme par exemple les attributs d’un contact dans une base de CRM qui peuvent être très nombreux et pourtant très peu renseignés. Le fait d’indiquer à SQL Server que ces attributs doivent être stockés dans des colonnes de type SPARSE permet de gagner l’espace normalement occupé par les valeurs nulles. Ce gain n’est pas temps pour le stockage mais pour la manipulation des données qui s’en trouve améliorée du fait d’avoir moins d’octets à lire.

CREATE TABLE dbo.ClientCRM (
ClientID int NOT NULL IDENTITY (1, 1),
Nom varchar(50) NOT NULL,
Poids int SPARSE NULL,
Yeux varchar(50) SPARSE NULL,
Taille numeric(3, 2) SPARSE NULL)

Les sparses columns s’utilisent aussi avec la notion de Columns Set qui permet de récupérer ou d’insérer plus facilement des jeux de colonnes disposant d’une valeur sans avoir à les manipuler toutes explicitement.

[...]

Compression des données : SQL Server 2008 supporte la compression des données à tous les niveaux. Nous l’avons vu avec les backups mais il est aussi possible de compresser directement les données d’une table, d’une partition ou d’un index.
On a du mal à classer cette fonctionnalité dans la catégorie performance car compression est synonyme de consommation processeur. On attend plus souvent de ce genre de fonctionnalité de gagner de l’espace disque. On en gagne certes mais là où la compression apporte est dans l’exécution des requêtes car on doit lire moins de données sur le disque, ce qui est un des principaux nerfs de la guerre de la performance. A utiliser néanmoins avec discernement…

CREATE TABLE Contact
(id int, fullname nvarchar(50) )
WITH (DATA_COMPRESSION = PAGE); 

Resource Governor : cette fonctionnalité est une des plus attendues dans SQL Server. Le Resource Governor permet de gérer finement l’utilisation du serveur (CPU, mémoire). Fini les requêtes qui monopolisent toutes les ressources. On peut assigner des limitations et des plans de charge aux différentes connexions ou applications. Ainsi, on peut faire en sorte qu’une application critique dispose d’un maximum de puissance de traitement et que des petites applications soient moins prioritaires.

[...]

Nouveautés de Analysis Services

Améliorations des performances globales : dans cette version 2008 de SSAS, Microsoft a cherché à beaucoup optimiser les performances de son moteur multidimensionnel. L’objectif est ambitieux : supporter des DataWarehouse de 100To de données en lieu et place des 25 supportés avec la version 2005. De nombreuses optimisations dans le calcul des agrégats et la gestion des cubes abondent en ce sens.

Notion de bonnes pratiques : une nouvelle fonctionnalité aussi appelée « alertes AMO » apparaît dans Business Intelligence Studio. De la même façon que le correcteur orthographique de Word, elles soulignent les éléments qui ne respectent pas les bonnes pratiques de modélisation et méritent réflexion. Ces avertissements sont débrayables ponctuellement ou définitivement.

[...]

Pourquoi l’article que je recherchais n’est pas remonté, …ce mot là est plus important que celui-ci, …normalement ce truc là aurait du remonter…, etc.

Il faut bien comprendre que la pertinence est très complexe à calculer. Malgré cela, Microsoft nous en livre la formule dans la MSDN (la formule est la même pour les 2 version) : 

• SQL Server 2005 : http://technet.microsoft.com/en-us/library/ms142524(SQL.90).aspx
• SQL Server 2008 : http://technet.microsoft.com/en-us/library/ms142524.aspx

Je vous invite à vous rendre directement à la section Ranking of FreeText qui nous donne la formule OKAPI BM25 servant au calcul du Rank. 

Simplement, retenez que la densité est un critère très important. En effet, si on recherche par exemple  »fût de sherry » et que « fût » est seul mais dans un texte court, il peut passer devant  »fût » et « sherry » noyés dans un long texte. Plus vos textes seront touffus, plus la pertinence sera avérée; par exemple, indexer des titres courts (quelques mots) produira des effets de bord certains.

Voici la formule à titre d’information. Si vous jugez qu’un résultat n’est pas à sa place, vous pouvez le vérifier et porter réclamation auprès de l’éditeur sur Connect. Personnellement, à chaque fois que j’ai constaté de mauvais résultats, c’est qu’il y avait une mauvaise recherche ou bien des données mal renseignées.

Rank = Σ[Terms in Query] w ( ( ( k1 + 1 ) tf ) / ( K + tf ) ) * ( ( k3 + 1 ) qtf / ( k3 + qtf ) ) )
Where:
w is the Robertson-Sparck Jones weight.
In simplified form, w is defined as:
w = log10 ( ( ( r + 0.5 ) * ( N – R + r + 0.5 ) ) / ( ( R – r + 0.5 ) * ( n – r + 0.5 ) )
N is the number of indexed rows for the property being queried.
n is the number of rows containing the word.
K is ( k1 * ( ( 1 – b ) + ( b * dl / avdl ) ) ).
dl is the property length, in word occurrences.
avdl is the average length of the property being queried, in word occurrences.
k1, b, and k3 are the constants 1.2, 0.75, and 8.0, respectively.
tf is the frequency of the word in the queried property in a specific row.
qtf is the frequency of the term in the query.