Optimisation des bases de données MS SQL Server – Partie 1

Ma pratique de l’audit, comme les cours que j’écris et enseigne au sujet de l’optimisation SQL Server, m’ont permis de constater à quel point l’ignorance est grande chez les techniciens de l’informatique : le modèle de données, le choix des types, le codage des procédures, la concurrence des transactions… Autant de sujet mal maîtrisés parce que vus uniquement sur le plan scolaire.

Il ne faut jamais oublier que la base de données est le point critique de toute application. Nul ne saurait se passer de données, tel devrait être le premier commandement de la Loi informatique… et pourtant nombreuses sont les entreprises qui n’ont aucune conscience que leur capital, leur patrimoine informatique, réside essentiellement dans leurs données, la qualité de ces données, et les performances que l’on peut exiger d’elles. La plupart des organisations sont obnubilées par l’aspect "sapin de Noël" de leurs merveilleux applicatifs graphiques, mais dans les faits ces logiciels constituent en quelques sortes les maigres arbres qui masquent une forêt : celle des données.

A l’aire du trash logiciel, à l’époque du décisionnel, les entreprises devraient se raccrocher encore plus à leurs données qui sont le seul point commun entre les différentes refontes de leurs programmes et qui leur permettent de piloter le navire entreprise. Or, c’est rarement le cas. Les performances demandées sont loin d’être atteintes du fait de modèles déficients, d’écritures tarabiscotées, d’une piètre qualité de données, quand ce ne sont pas des serveurs mal exploités et des bases peu ou pas administrées… Ce profond décalage entre ce qu’il faudrait faire et la réalité a deux origines distinctes : un manque de formations scolaire et professionnelle et le discours marketing tout azimut.

Sur le manque de formation scolaire, force est de constater que les programmes en matière de bases de données relationnelles – réduits aujourd’hui à peau de chagrin – ont été calés sur la version 1992 du langage SQL et la plupart du temps sur le dialecte abscond et peu normatif du SGBDR Oracle1 . Il en résulte à ce point une méconnaissance de SQL, que, récemment, dans le cadre de tests de recrutement, la plupart des candidats, confrontés à une jointure interne à la norme SQL de 1992, considérait cela comme un élément spécifique du langage propre à un SGBDR particulier ! Or nous sommes passés de la norme de 1992 dite SQL 2 aux normes SQL : 19992 et SQL : 20033, chacune ayant apporté des éléments aujourd’hui traduits dont les plus importants figurent aujourd’hui dans la version 2005 du SGBDR SQL Server.

Comme il suffit la plupart du temps de mettre sur son CV "langage SQL" pour que le recruteur suppose que le candidat maîtrise les technologies des bases de données relationnelles, on en arrive au fait que l’informaticien devient de fait un bon pisseur de requêtes SQL et qu’il acquiert assez rapidement le statut d’architecte des données par le simple fait qu’il sait utiliser l’interface graphique machin pour créer une table.

Du côté du discours mercatique, tous sont coupables… ! A commencer par Microsoft qui fait croire à la simplicité4 d’un SQL Server 2005, alors que même les meilleurs experts s’arrachent les cheveux actuellement pour contrôler une bête dont l’étendue des possibilités nécessite au bas mot une vingtaine de jours de formation pour en absorber la plupart des aspects… Coupables aussi les éditeurs de solutions de développement en tout genre qui vous font croire qu’il n’est plus besoin de mettre les mains dans le cambouis SQL parce que leur atelier, Ô combien intelligent, calcule automatiquement les bonnes structures et écrit les bonnes requêtes… De fil en aiguille, ces outils et ces hommes construisent une base, une application et la livre.

Le tout est alors mis en exploitation. Passé les quelques mois de la garantie où le client peut réclamer – et où, par bonheur, il n’y a presque pas de données dans la base – le système semble donner toute satisfaction. Puis le temps passe et joue en défaveur du client : le volume de données s’accroît et les performances se mettent à chuter, souvent brutalement5, alors qu’aucune alerte ne s’était préalablement produite.

Le client mécontent tance l’auteur du logiciel qui se met à incriminer la plupart du temps le SGBDR mais le plus souvent la machine : "votre serveur n’a pas assez de mémoire…, de disques…, de processeurs… " Il est bien difficile pour une SSII ou un éditeur d’admettre que sa faible compétence l’a conduit à une impasse. C’est difficile parce que reconnaître cela suppose des compétences que l’on n’a pas et que faire appel à un prestataire externe pour auditer la qualité de ce que l’on a fait n’est pas franchement coutume dans notre mauvaise habitude de négliger l’importance du service, la nécessité de la critique, le regard extérieur.