Nul ne conteste que toute entreprise moderne s'appuie sur de bonnes bases de données, véritable élément fédérateur. De plus en plus nombreuses, complexes et puissantes, elles fournissent toutes les informations. Cette prédominance a aussi son corollaire ; ou cette médaille, son revers : en cas de difficultés d'accès aux données, les soupçons se portent aussitôt sur la base de données. En effet, au fil des ans, celle-ci est passée d'un simple moyen de stockage et d'accès aux données à une sorte de créature complexe et multifonctionnelle. L'accent a été mis bien plus sur la sophistication que sur la simplicité.

Pour Marcus Collins, senior analyst au Burton Group, c'est cette inversion de priorité qui est responsable de la plupart des problèmes. "Il ne faut jamais oublier que les bases de données sont vraiment complexes. Plate-forme de gestion des données et de développement : les choix peuvent être bons ou mauvais." Pour Collins, il faut prendre quelques décisions fondamentales. Selon lui, tout le processus commence par des questions élémentaires. "Où mettez-vous le code : dans la base de données elle-même ou au niveau intermédiaire ? Il y a beaucoup d'excellents endroits pour optimiser, mais le plus difficile est de décider du point de départ." Dans leur ouvrage The Data Access Handbook, John Goodson et Rob Steward considèrent que, souvent, la difficulté ne vient pas de la base de données elle-même mais de son mode d'accès. Ils soulignent que les entreprises dépensent des milliers ou des millions de dollars chaque année pour résoudre des problèmes de réglage avant de s'apercevoir que la capacité est en cause. Selon eux, il en est ainsi parce que toute l'attention s'est portée sur la résolution des problèmes de capacité de la base de données, tandis que peu de temps était consacré à écrire des applications articulées autour des données et à optimiser le code d'accès aux données.

Collins, Goodson et Stewards touchent du doigt le point sensible des bases de données. Résoudre des problèmes de performance de bases de données n'a rien à voir avec une panne de voiture. Pour cette dernière, le diagnostic isole facilement deux ou trois facteurs. Rien à voir non plus avec la résolution d'un problème réseau, où l'administrateur suit une procédure bien définie. Pour les systèmes de base de données moderne, le problème réside dans l'interconnectivité elle-même. Ronan Miles, chairman de l'Oracle UK User Group, appelle cela l'effet domino. "Faire un changement ou ajouter un index dans une partie de la base de données pour améliorer un temps de réponse, risque d'affecter négativement une autre partie, voire de la ralentir : le contraire de ce que l'on voulait faire." Et c'est bien là le coeur des problèmes de bases de données et pourquoi il est si difficile de régler finement le logiciel pour optimiser la performance. Au départ, le logiciel peut fonctionner en parfaite harmonie avec son entourage, mais un simple changement peut détraquer cette belle mécanique.

Cette situation est parfaitement décrite dans Troilus et Cressida, de Shakespeare. La description que fait Ulysse de la société pourrait aussi bien s'appliquer aux bases de données. "Les paradis eux-mêmes, les planètes, et ce centre, Observez … cours, proportion, saison, forme, bureau (office) et personnalisation (custom), dans n'importe quel ordre." Mais si la base de données ne fonctionne pas correctement, ou, au moins, avec son efficacité optimale, il faut examiner ses éléments constitutifs : le logiciel dans son ensemble, sa plate-forme d'exécution, ou la façon dont les éléments sont connectés entre eux. C'est plus facile à dire qu'à faire. Identifier les problèmes d'un système de base de données d'entreprise n'est pas une sinécure, ni un sujet que l'on peut traiter en détail dans un seul article. En fait, on pourrait écrire plusieurs tomes sur le réglage fin, l'optimisation et le calibrage des bases de données pour améliorer leur performance.

Face à des bases de données trop lentes, l'une des réactions classiques a été d'étoffer le serveur ou de doper le réseau. Or, même si la puissance de la CPU et la largeur de la bande passante sont de moins en moins chères, c'est rarement le meilleur remède. Une telle politique ne coûte pas aussi cher qu'il y a 10 ou 15 ans, mais, de nos jours, les DSI ont deux autres préoccupations : mieux utiliser la puissance de traitement et réduire les coûts. On peut bien sûr se tourner vers des serveurs virtuels, mais cette solution peut engendrer ses propres problèmes. Par exemple, une société qui héberge sa base de données sur des serveurs virtuels ne doit pas croire forcément qu'il suffit d'ajouter de la puissance au système. En effet, si trop de CPU sont fournies à une machine virtuelle, il y a un risque de ralentissement du fait que le système passe du temps à allouer du travail aux processeurs. Quand il s'agit d'apporter des correctifs et des ajustements à des bases de données, il faut avoir quelques fortes règles présentes à l'esprit. D'après Miles, la première d'entre elles est d'avoir le résultat final en ligne de mire et de ne jamais finasser et bricoler sans avoir un but précis à l'esprit. "Il faut savoir quand s'arrêter," déclare-t-il. Il est facile de poursuivre le bricolage mais à condition de s'arrêter à un certain point. Comme au casino, il ne faut jamais perdre de vue la somme que l'on peut se permettre de perdre. Et Miles va même plus loin : "C'est plutôt comme avec la cocaïne, c'est difficile de cesser d'en prendre."

Il dit aussi l'importance de ne changer qu'une chose à la fois. "Surtout pas de changements tous azimuts. Comportez-vous en ingénieur : faites un changement et voyez sa conséquence. Et … ne perdez pas de vue le bouton UNDO." Pour Collins, l'optimisation de la base de données passe d'abord par l'examen de l'architecture sous-jacente. Et le premier point est de choisir l'architecture elle-même, un long et difficile débat dans l'entreprise", déclare-t-il. "Le problème vient de l'abondance des choix : quelle base de données ? Fonctionnera-t-elle sur une seule machine ou sur plusieurs ? Retiendra-t-on Exadata pour l'entreposage des données ? Le même produit fonctionnera-t-il dans différentes configurations ? Le débat est d'autant plus vif dans l'entreprise qu'une fois le choix effectué, elle en sera prisonnière."

C'est pourquoi Collins considère que la planification est un élément majeur de l'optimisation des bases de données. "Tâchez d'imaginer où vous en serez dans deux ou trois ans et pas dans six mois". Par exemple, poursuit-il, il est important de diviser les données : par région ou par magasin pour une société de vente au détail. Puis quelque chose se passe, l'activité change de nature et il faut diviser autrement – hélas il est alors trop tard. Ou, en étant plus optimiste, supposons que le nombre d'utilisateurs ait doublé : comment faire face ? Pour développer une architecture évolutive, il s'en tient à une règle empirique très simple. "RAMPS – reliable, available, manageable, perform well and be scalable (fiable, disponible, gérable, performant et évolutif)." Pour ce qui est de la performance de la base de données elle-même, l'une des méthodes les plus simples pour améliorer la performance des requêtes consiste à créer des index efficaces pour s'épargner de scanner toute une table de base de données. Quand un index est créé, la base de données stocke l'information statistique pertinente dans la colonne indexée. Cette information sert ensuite à déterminer la meilleure stratégie face à une requête. Au final, le temps de recherche et considérablement raccourci car l'utilisateur n'explore qu'une petite sous-section de toute la base de données.

Pour des bases de données lourdes et encombrantes, il est certain que les index accélèrent les recherches. Mais ils n'ont pas que des avantages. Si l'on en croit David Cartwright, gestionnaire du réseau des télécoms et de l'hébergement chez CPA Global, une société financière, tout n'est pas si rose. "Ils occupent de l'espace disque (ce qui a son importance, même aujourd'hui). Mais, plus important, chaque index d'une table doit être mis à jour après un INSERT, UPDATE ou DELETE. Une indexation excessive peut freiner considérablement une base de données qui fait autre chose que de l'accès en lecture seule." Et il ajoute un autre facteur à prendre en compte. "Certaines fonctions d'optimisation (comme la défragmentation d'index) peuvent bloquer des tables pendant très longtemps." Certains administrateurs de bases de données l'oublient parfois et décident de les reconstruire. Le remède est pire que le mal : la base de données se bloque et l'application se plante encore plus, parfois pendant des heures. Toujours selon Cartwright, en matière de performance de base de données, il ne faut pas chercher les problèmes trop loin. Le rasoir d'Occam prend ici toute sa valeur : la réponse la plus simple est la meilleure. "Si la base de données ne se comporte pas comme prévu, cherchez toujours la réponse évidente. Avant de vous livrer à des mesures de performance savantes et compliquées et avant de procéder à des tests approfondis, faites donc beaucoup plus simple : vérifiez les paramètres d'I/O disque, la charge de la CPU, l'état de la mémoire, si votre logiciel antivirus a été mis sur "scan on access", et ainsi de suite," suggère-t-il. Les outils d'analyse sont importants pour toutes les entreprises. Collins affirme que les outils de modélisation sont parfaits pour aider aux changements de planification. "Les fournisseurs de bases de données proposent plusieurs outils excellents, IBM en a un puissant pour DB2, Oracle en a un légèrement inférieur, mais les deux sont bons. Si vous voulez aller voir ailleurs, il y a Embarcadero – et quelques autres." Cartwright de CPA ne comprend pas la réticence des entreprises envers de tels outils. Il affirme que les outils d'analyse permettent un large diagnostic. "Pourtant de nombreuses organisations ne jugent pas utile de s'en servir (ou, plus couramment, ne connaissent pas leur existence et/ou ne savent pas comment les utiliser) et pratiquent l'optimisation à tâtons."

La normalisation est un autre aspect important. La théorie classique veut que les base de données soient le plus normalisées possible. C'est-à-dire que leur contenu soit présenté du mieux possible, sans aucune redondance, et qu'une table ne contienne que des données de même nature. Mais Cartwright ajoute aussitôt que la normalisation, pour excellente qu'elle soit en théorie, ne doit pas aller trop loin – "un peu de dénormalisation améliorera la performance en évitant dans vos requêtes des JOIN ridiculement larges. Donc, normalisation ne signifie pas toujours performance."

Cartwright ajoute que beaucoup de problèmes de bases de données n'ont rien de technique mais sont plutôt dûs à la politique et à la stratégie de l'entreprise. En particulier, il fustige les sociétés qui économisent en employant des administrateurs de bases de données non professionnels et qui ont tendance à "juste mettre un produit en service précipitamment, car il est jugé moins important que d'autres projets dans la course au budget." Collins souligne aussi un aspect d'organisation souvent ignoré. "Le plus souvent, l'administration des bases de données se fait de manière traditionnelle : en deux parties, ou plutôt deux bras, le premier pour le développement applicatif et le second pour la production. L'équipe de développement écrit le logiciel puis le lance par-dessus une sorte de muraille de Chine, aux bons soins du bras opérationnel chargé de l'exploitation. Et donc, des fonctions telles que la conception d'index n'interviennent qu'au moment de l'exploitation. Pour lui, "C'est une démarcation artificielle à bannir. Dès le début, l'équipe d'exploitation doit être impliquée et travailler main dans la main avec l'équipe de développement." Et une fois que la base de données a été optimisée, l'histoire ne s'arrête pas là. Il y a toujours une marge d'amélioration. Ronan Miles donne un bon conseil aux techniciens : "Actualisez en permanence vos connaissances, assistez aux événements animés par des experts, et apprenez sans cesse".

En résumé, pour tirer le maximum d'une base de données, il faut créer la bonne infrastructure dès le début. Tout réside dans la planification : choisir la bonne architecture, prévoir la croissance et s'entourer de gens compétents qui ne cessent d'apprendre. La normalisation et l'indexation sont des techniques utiles, mais attention aux pièges et aux écueils qu'elles recèlent. C'est la collaboration de nombreux éléments qui produit l'optimisation de la base de données. Faute de ce travail en commun, comme le souligne Ulysse de Shakespeare (qui, soit dit en passant, aurait été de nos jours un excellent développeur de base de données) : "L'entreprise est malade". Et il faut guérir cette maladie avant qu'elle ne s'étende : l'optimisation de la base de données est à ce prix.

ENCADRE : les 10 erreurs les plus importantes à ne pas commettre

1) Absence de plan à long terme
Il ne suffit pas de planifier une base de données pour le moment présent. Le bon développeur doit réfléchir aux besoins de l'entreprise dans trois ou quatre ans. Comme il ne sera pas facile de changer l'architecture de la base de données, une réflexion poussée doit précéder la mise en oeuvre générale.

2) Indexation excessive
Ne pas savoir quand arrêter l'indexation et fignoler et bricoler sans cesse. Les développeurs doivent savoir clairement ce qu'ils attendent de l'indexation et ne pas aller au-delà.

3) Attention à l'effet domino
Cela prolonge le point précédent. Tel ou tel changement peut abîmer une autre partie du logiciel, et il est alors difficile de trouver la source d'un problème particulier

4) Ne pas penser comme un ingénieur
Faites les réglages et les retouches un à un. Essayez de prévoir ce qui se passera et, au passage, jugez de votre talent dans ce genre d'exercice.

5) Se passer d'experts.
Le développement et l'administration des bases de données sont des spécialités de pointe. Et il y a pénurie de ce genre de spécialistes. Même s'il est difficile de trouver du bon personnel et de le conserver, il ne faut pas lésiner dans ce domaine. Et surtout, il faut actualiser sans cesse ce genre de connaissances en assistant à des conférences techniques et en lisant ce qu'écrivent des experts reconnus.

6) Négliger les outils d'analyse.
Il existe un large choix d'outils d'optimisation des bases de données : certains sont offerts par les fournisseurs de bases de données eux-mêmes, d'autres par des sociétés tierces. Utilisez-les car ils seront précieux pour vous aider à résoudre certains des problèmes les plus évidents. 7) Attention à la normalisation.
La conception de bases de données fait bon usage de la normalisation. Mais il faut quand même l'utiliser avec prudence. Un peu de 'dénormalisation' peut être bénéfique, mais sans excès.

8) Pas de coopération étroite entre l'équipe de développement et celle d'exploitation

Généralement, il y a démarcation entre l'équipe de développement et celle d'exploitation. À beaucoup d'égards, c'est une fausse distinction et certaines sociétés ne pratiquent pas cette division. Si une seule entité n'est pas possible, il faut au minimum instaurer une coopération étroite entre les deux groupes.

9) Documentation mediocre
C'est un reproche aussi vieux que la programmation. Mais il est vrai que les développeurs ne savent pas bien indiquer ce qui a été fait, par qui, quand et pourquoi. Leurs successeurs ont souvent bien du mal à retrouver et à annuler certains des changements. D'où l'intérêt de bien faire les choses dès la première fois.

10) Puissance de traitement insuffisante
C'est vrai, ce facteur est souvent jugé important et on a facilement tendance à lui imputer les problèmes de base de données … parfois à juste titre. Si tout le reste échoue, regardez donc du côté du serveur, voire du réseau.