Lorsque l’on exploite et administre une base de données de production, il est essentiel d’obtenir des temps de réponses satisfaisants pour les utilisateurs, ou permettant d’assurer que les traitements de type batch tiennent dans la fenêtre de temps qui leur est impartie.
Il est également nécessaire de garantir une consommation de ressources modérée ou tout au moins en adéquation avec son architecture. Ainsi, CPU, mémoire, réseau, ou IOs seront correctement taillés et sollicités pour ne pas saturer l’environnement hébergeant la base de données.
Chaque acteur de la mise à disposition de l’application (développeur, testeur, responsable d’application, DBA…) porte une attention particulière au comportement des requêtes SQL qui sont écrites et exécutées par l’application car c’est principalement la conception de l’application et le SQL exécuté qui détermineront les performances d’une application.
A titre d’exemple sur Oracle, le comportement des requêtes est notamment dicté par le choix du plan d’exécution, qui est calculé par l’optimiseur en fonction de nombreux éléments : écriture de la requête, présence d’index, statistiques, paramètres d’instance ou de session, utilisation de vues matérialisées…
Cependant, même une fois optimisée, le comportement d’une requête pourra évoluer si un des éléments cités évolue. Par exemple après un nouveau calcul de statistiques, en cas de changement de valeur d’un paramètre, si un index devait être reconstruit ou une table compressée. On peut même observer des changements de plan d’exécution sans qu’aucune modification n’ait été apportée, par exemple parce que Oracle constate une cardinalité réelle très différente de celle qu’il a estimée.
On en vient alors à un sujet au moins aussi important que les performances : la stabilité.
Nombre d’acteurs dans le domaine des performances applicatives préfèrent stabiliser par exemple le temps d’une requête à 3 secondes, plutôt que d’offrir un temps de 2 secondes à l’utilisateur un jour, puis passer à 4 secondes le lendemain, et même revenir à 2 secondes le week-end lorsque la charge est moindre, sans explication pour l’utilisateur.
Depuis plusieurs versions, Oracle s’attache à offrir de nouveaux mécanismes embarqués dans l’optimiseur afin de déterminer des plans d’exécutions les mieux adaptés. On peut citer par exemple les mécanismes suivants : bind variable peeking, adaptive cursor sharing, SQL plan management, adaptive query optimization, SQL plan directives, cardinality feedback ou statistics feedback en version Oracle 12c.
Tous ces mécanismes, aussi puissants et intéressants soient-ils, peuvent parfois apporter des fluctuations dues à des changements de plans d’exécution. Et on constate que tous ne sont pas documentés, ce qui n’en facilite pas la compréhension.
Il est donc désormais plus que jamais nécessaire d’être attentif au comportement de la base de données et de surveiller comment peuvent fluctuer certains plans d’exécution dans le temps.
Les nouvelles versions d’outils de suivi des performances des bases de données Oracle devront intégrer des fonctionnalités offrant à l’utilisateur ou l’administrateur une meilleure lisibilité pour appréhender ces nouveautés. L’objectif étant d’apporter à ses environnements la stabilité attendue, caractéristique primordiale d’une application.