Les lecteurs francophones peuvent trouver, ci-dessous, une traduction de presque toutes les philosophies de Jonathan Lewis.
Philosophie 1
Il existe certains concepts Oracle très importants si bien qu’ils doivent être gravés dans votre mémoire voltigeant autour de vos yeux à chaque fois que vous voulez investiguer un problème de performance en SQL. Voici un de ces concepts :
Les histogrammes et les variables de liaison existent pour des raisons diamétralement opposées ; ils ne vont pas fonctionner ensemble sans aide.
Vous utilisez les variables de liaison parce que vous voulez que tout le monde partage le même curseur enfant (child cursor) d’une instruction SQL ; cette instruction SQL, allant être utilisée très fréquemment, tout le monde va accomplir la même petite charge de travail en l’exécutant. Le même plan d’exécution devrait être idéal pour tous, et vous ne voulez pas ré-optimiser cette instruction SQL à chaque réutilisation parce que le coût de son optimisation va être probablement plus élevé que ne le serait celui des ressources nécessaires pour son exécution. Typiquement, on souhaite une large (mais pas exclusive) utilisation des variables de liaison dans des systèmes OLTP.
Vous créez des histogrammes parce que des instructions SQL, qui sont virtuellement identiques, génèrent des charges de travail qui diffèrent énormément, nécessitent des plans d’exécutions différents, le travail fait lors de leur optimisation est négligeable lorsqu’il est comparé à celui fait lors de leur exécution, et, si elles utilisent un mauvais plan d’exécution, elles conduiraient à une énorme perte de ressources. Typiquement, on a besoin de générer des histogrammes dans des systèmes DataWareHouse ou d’aide à la décision où les requêtes peuvent être brutales et très coûteuses.
Notez bien la contradiction : une technologie est supposée vous donner un plan d’exécution unique utilisable par tout le monde alors que l’autre technologie est supposée donner à chacun son meilleur plan d’exécution
Garder bien cela en mémoire et vous allez être rappelé à être vigilant quant à la création des histogrammes dans des systèmes OLTP. Ainsi, vous n’allez pas être tenté de transformer absolument chaque valeur littérale en une variable de liaison.
Philosophie 2
Voici une autre idée parmi celles qui sont tellement fondamentales que vous devez toujours les avoir à l’esprit lorsque vous travaillez avec une base de données Oracle
La stratégie fondamentale incorporée dans l’Optimisateur est basée uniquement sur deux points clés:
- Combien de données vous voulez rapatrier ?
- Où les avez-vous stockées ?
Si vous tentez d’améliorer la performance d’une requête SQL en jouant avec son contenu jusqu’à ce qu’elle s’exécute assez rapidement, alors vous n’êtes pas sur la bonne voie et vous perdez du temps inutilement.
Si, par contre, vous débutez votre tâche de ’’Tuning’’ en pensant à la taille du volume de données que vous êtes supposé rapatrier et à la nature de la dispersion aléatoire de ces données, alors vous allez réduire le temps nécessaire à trouver la meilleure manière d’acquérir efficacement ces données.
Philosophie 3
La performance d’une requête SQL devrait être liée à la taille du volume de données qui vous intéresse et non à la taille de la base de données.
Si ceci n’est pas votre cas alors vous avez fait une erreur dans l’implémentation physique de votre base de données. Typiquement ceci peut être lié à une pauvre indexation, mais cela peut être aussi dû à des erreurs dans le choix d’autres structures telles que le partitionnement, le clustering, IOT’s ou les vues matérialisées.
Le premier symptôme de cette erreur est la plainte suivante: “au fur et à mesure que le temps avance la base de données devient lente’’
Philosophie 4
Il existe deux aspects critiques dans l’extensibilité des applications informatiques :
- Dans un mode mono-utilisateur : est-ce que le temps de réponse de cette année sera le même que celui de l’année prochaine (voir Philosophie – 3) ?
- Dans un mode multiutilisateurs: est-ce que le temps de réponse va être le même lorsque le nombre d’utilisateurs double, triple, quadruple …. ?
Si vous voulez tourner cela en une informelle et compréhensible phrase, Cary Millsap en inventa une bonne au Collaborate2009 : ’’Rapide Maintenant, Rapide plus tard’’
Philosophie 5
Résolution de problème avec Statspack / AWR
Quelque chose doit être en premier dans le ‘’Top 5 Timed Waits’’…. même lorsqu’il n’y a pas de problème de performance.
Philosophie 6
Tests de conformité :
- Avez-vous testé en utilisant des données de qualité et en utilisant toutes les différentes possibilités de données foireuses ?
- Est-ce que le code fait ce qu’il doit faire… et rien de plus ?
Philosophie 7
Il n’y a pas de secrets :
Au moins, il n’existe pas de secrets impliqués dans le bon fonctionnement d’une base de données. Occasionnellement, une information nouvelle et utile est découverte ; si elle est importante, cette information va être documentée, discutée et validée en publique. (Elle ne sera pas nécessairement documentée sur Metalink, OTN ou tahiti.oracle.com mais ceci ne fait pas d’elle un secret).
A chaque fois que je vois des personnes faire des présentations sur les ‘’secrets’’, il s’avère qu’elles ont généralement partagé leur temps entre citer la documentation, énoncer des évidences, faire des erreurs et offrir des généralités qui nécessitent de prudentes justifications.
J’ai une règle générale simple pour les présentations : plus leur titre est glamour, branché et excitant, moins elles ont de chances d’être utiles (mais ceci ne va pas m’empêcher de lire le résumé – juste au cas où).
Philosophie 8
Indexes B-tree vs. Indexes Bitmap: la différence la plus critique
- Un seul index B-tree vous permet d’accéder précisément à un petit volume de données
- C’est la combinaison de la présence d’un ensemble d’indexes Bitmap qui offre le même degré de précision.
Vous ne devrez pas comparer l’efficacité d’un index bitmap avec l’efficacité d’un index B-tree.
(Inévitablement c’est un peu plus subtile que ça ; vous pouvez créer quelques indexes B-tree peu précis pour éviter les problèmes de verrous liés aux contraintes du type clé étrangère, l’optimisateur peut combiner des indexes B-tree etc… ; mais si vous commencez sur cette base vous allez avoir une vue rationnelle sur comment utiliser les indexes bitmap).
Note : rappelez vous aussi, que les indexes bitmap introduisent des problèmes massifs de concurrence et d’autres surplus de maintenance ; si vous les trouvez dans des systèmes OLTP il y a alors de fortes chances qu’ils y soient en train de causer des problèmes.
Mis à jour 23 déc. 2009 : J’ai écrit un article complémentaire à cette note puisque le sujet que j’ai traité ici semble avoir causé quelques confusions.
Philosophie 9
Il existe une vieille blague concernant un ingénieur, un mathématicien et un philosophe voyageant ensemble dans un train de Londres (Angleterre) à Cardiff (Pays de Galles)***
Lorsque le train traversa la frontière, l’ingénieur jeta un coup d’œil par la fenêtre et s’exclama : ‘’Oh, regardez ! Les moutons Gallois sont noirs ‘’.
Le mathématicien répondit :’’Non ; tout ce que vous pouvez prétendre c’est qu’il y a au moins un mouton au pays de Galles qui est de couleur noir’’
Le philosophe les corrigea tous les deux : ‘’Messieurs, tout ce que vous pouvez dire c’est qu’il parait qu’au Pays de Galles, existe un mouton qui semble être noir sur un côté.’’
(Croyez-moi, en 1970, ceci était assez drôle)
La morale de cette histoire est : le meilleur point de vue à considérer lors de la résolution des problèmes d’une base de données est celui du mathématicien ; n’allez pas, comme l’a fait l’ingénieur, vers des conclusions extrêmes basées uniquement sur une observation ; mais ne soyez pas, comme l’a fait le philosophe, coincé sur d’aussi petits détails de conformité théorique si bien que des hypothèses raisonnables soient mises de côté.
*** Note: Pour ceux qui ne sont pas familiers avec la géographie du royaume uni (UK) : ‘’Le Royaume uni de la Grande-Bretagne et de l’Irlande du Nord ‘’ représente l’union de l’Angleterre, de l’Ecosse (la grande partie de la moitié haute de l’ile) et du Pays de Galles (le morceau de terre à gauche en excluant la petite et fine partie du bas).
Philosophie 10
La question la plus significative à vous poser lorsque vous êtes en train de réfléchir à l’ajout d’un nouvel index est :
‘’Est-ce que cet index va éliminer significativement plus de travail que ce qu’il va introduire (au moment où cela importe vraiment) ? ‘’
Quelques exemples de ‘’moments qui importent’’
- Insertion/suppression/mise à jour en vrac
- Système OLTP avec une activité hautement concurrente
- Des rapports fréquents nécessitant une très grande précision
- Test d’acceptation pour les effets collatéraux.
Philosophie 12
Voici une description utile que j’ai récemment entendue du philosophe Daniel Dennett:
Les critères d’une bonne propagande
- Elle n’est pas un simple mensonge sans masque
- Vous devez être capable de l’énoncer très sérieusement
- Elle doit enlever le scepticisme sans exciter la curiosité
- Elle doit apparaitre comme profonde
Il semble qu’elle décrit beaucoup de choses que notre industrie publie sur internet.
Philosophie 13
Si vous lisez un commentaire du genre “ X est une mauvaise idée’’ ceci ne veut pas dire ’’ un mécanisme qui, vaguement, n’est pas ‘X’ est une bonne idée’’.
Si, par exemple, je dis
’’Les histogrammes ne vont pas bien fonctionner sur des chaines de caractères ayant plus de 32 octets (bytes) de longueur et généralement identiques dans leurs premiers 32 octets ’’
Ceci n’est absolument pas équivalent à :
’’ C’est une bonne idée de créer des histogrammes sur des chaines de caractères ayant moins de 32 octets (bytes) de longueur’’
Si on était dans un monde purement mathématique on aurait invoqué une logique symbolique en montrant ceci:
(A => B) <=> (¬B => ¬A)
Qui signifie que mon énoncé est équivalant à :
’’ si vous avez des histogrammes qui fonctionnent bien, alors les données ne sont pas du type chaine de caractères de plus de 32 octets dont, généralement, les 32 premiers octets possèdent des valeurs identiques’’
Evidement, sous Oracle, vous allez peut-être rencontrer certaines personnes, quelque part, ayant exactement le même type d’histogramme qui semble brillamment fonctionner pour elles. Cependant, ceci n’aurait été possible que parce que l’optimisateur aurait complètement raté son arithmétique si bien qu’il leur a fourni un plan d’exécution optimal pour une raison complètement erronée. Ces personnes doivent faire attention lors d’une prochaine migration ou prochaine application d’un nouveau patch dans le cas où l’optimisateur y est amélioré.
Philosophie 14
Paraphrasant Yogi Berra:
‘’Ce n’est pas comité jusqu’à ce que ça soit comité”
Si vous vous demandez pourquoi c’est important de rappeler cet inhabituel commentaire –il répond à la question suivante communément posée:
‘’Est-ce que les redo logs contiennent aussi bien les données non comitées que celles déjà comitées ?’’
La réponse est : oui
Lorsqu’une session est en train de créer un redo change vector elle ne sait pas si elle va finir par faire un commit ou par annuler ce qu’elle a fait (un rollback). Par contre, une session doit être capable de stocker une large liste arbitraire de vecteurs de changements (change vectors) quelque part ; cette liste doit apparaître dans le redo log (idéalement d’une manière instantanée) si la session fait un commit – ainsi Oracle évite des retards lors du commit en déposant les vecteurs de changements dans le redo log au moment de leur création***.
*** Pas strictement correct à partir de 10g et plus où Oracle a introduit un effet retardataire dont le but est de réduire la compétition (la demande) pour l’allocation des redo et lors des copies de redo latches pour de ‘’petites’’ transactions
Philosophie 15
Si vous exécutez une requête qui est supposée retourner un seul enregistrement à partir d’une très large table, et, vous disposez d’un index approprié sur cette table, vous vous attendrez probablement à ce que l’optimisateur d’Oracle identifie l’index et qu’il l’utilise. Si vous changez votre requête de telle sorte qu’elle renvoie tous les enregistrements de cette table (sans tri) vous vous attendrez probablement à ce que l’optimisateur d’Oracle choisisse un full table scan.
Ceci conduit à la très simple idée qui est souvent ignorée
“Quelques fois il suffit juste d’un enregistrement supplémentaire pour passer d’un plan d’exécution utilisant un index scan à un plan utilisant un full table scan”
Il existe un point où l’optimisateur change d’un accès indexé à un seul enregistrement vers un accès à toute la table pour tous les enregistrements.
Si vous êtes assez chanceux et le modèle de l’optimisateur est parfait il n’y aura aucun effet significatif sur la performance, bien sûr. Mais, nous ne sommes pas aussi chanceux que ça, et c’est pour cette raison que certaines personnes finissent par poser la question : ‘Comment le plan d’exécution est devenu subitement non performant, il n’y a eu aucun changement …. sauf pour un petit supplément de données?”. Tout ce qu’il faut c’est un seul enregistrement (que l’optimisateur reconnait) pour changer d’un plan d’exécution à un autre- et parfois l’optimisateur trouve le mauvais moment pour opérer ce changement.
Philosophie 17
Vous devez comprendre l’application ainsi que ses données
Une récente question dans OTN demandant des conseils pour faire en sorte que la partie SQL suivante s’exécute rapidement :
delete from toc_node_rel rel
where not exists (
select *
from toc_rel_meta meta
where rel.rel_id = meta.rel_id
);
Voici une très petite liste de questions sur lesquelles il faut se concentrer lors de la recherche des solutions possibles. Il existe une colonne nommée rel_id dans les deux tables ; les colonnes ayant un “id” dans leur nom tendent à être un tout petit peu spéciales, donc est-ce que ces colonnes sont :
a) la clé primaire d’une table et la clé étrangère de l’autre (si c’est oui dans quel sens) ?
b) les clés primaires des deux tables ?
c) deux clés étrangères d’une clé primaire partagée d’une autre table ?
Jusqu’à ce que vous connaissiez la réponse à ces questions vous ne pouvez pas réellement progresser dans votre cheminement vers la bonne manière d’implémenter le besoin. Et, même lorsque vous aurez eu les réponses, ceci n’est encore qu’une seule étape vers la bonne direction et un précurseur pour le prochain lot de questions – comme “est ce que les contraintes ont été déclarées et activées ? est-ce que certaines contraintes du type clés étrangères permettent la présence de nulls ? est-ce que certaines contraintes du type clés primaires ont été validées par des indexes non uniques ?’’ . Et nous ne sommes pas encore arrivés aux volumes absolus des données, à leurs types de regroupements et au volume de données candidat à la suppression.
Note:
Vous pouvez argumenter sur l’existence ou pas des possibilités citées dans un système proprement conçu. Soyez libre de le faire ; ce n’est pas parce qu’un concept est faux en théorie qu’il ne va se produire en pratique.
Note 2:
Pour une impression beaucoup plus concrète c sur la petite liste de questions :
Pour l’option (a) PK/FK – imaginez un cas très simple d’un modèle de commande, sommes nous en train d’essayer de supprimer les produits pour lesquels il n’y a pas de commandes, ou les commandes pour lesquelles on ne stocke pas de produits (qui n’auraient pas du être introduites dans le système si nous l’avions implémenté correctement) ?
Pour l’option(b) PK/PK – imaginez que notre simple modèle de processus de commande possède une table séparée de livraison qui clone la PK de la table de commande, allons-nous essayer de supprimer les livraisons qui n’ont pas de commande (encore une fois elles ne devraient pas exister, mais qui a dit que ce système a été bien conçus et bien implémenté voir (a)) ?
Pour l’option (c) de la FK partagée – imaginez un processus de commande différent qui permet plusieurs lignes de commandes par commande et qui clone la PK des lignes de commande pour produire un enregistrement dans la table de livraison, allons nous essayer de supprimer les livraisons qui n’ont pas de lignes de commande (encore une autre possibilité provenant d’un système mal conçu et mal implémenté – mais je suis sûr que je ne suis pas la seule personne à avoir vu de pareils systèmes et un tel code ) ?
Philosophie 18
Une question que je me suis posé récemment est celle-ci:
Quelle est le plus mauvais tort que peut engendrer la publication d’un article autour d’une technique (caractéristique) d’Oracle
- Dire qu’un concept fonctionne alors qu’il ne fonctionne pas.
- Dire qu’un concept ne fonctionne pas alors qu’il fonctionne.
- Dire qu’un concept fonctionne alors que dans certains cas il ne fonctionne pas.
- Dire que qu’un concept ne fonctionne pas alors que dans certains cas il fonctionne.
Je ne pense pas que c’est une question à laquelle il est facile de répondre et, évidement, ce n’est pas plus facile lorsqu’on commence à considérer le nombre de cas pour lesquels une caractéristique fonctionne ou ne fonctionne pas (combien de cas représentent “quelques cas“), et la fréquence à laquelle les différents cas peuvent apparaître.
Je ne suis pas sûr qu’il existe une réponse correcte à cette question, par contre, en terme d’impact (temps perdu) j’ai tendance à condamner les affirmations qui stipulent que quelque chose fonctionne alors qu’elle ne fonctionne pas – imaginez les deux extrêmes scénarios suivants :
- Quelqu’un est en train d’essayer de résoudre un problème et trouve une publication qui offre une solution qui est supposée bien fonctionner – combien de temps va-t-il perdre en essayant de faire en sorte que cette solution fonctionne parce qu’il ‘’sait’’ qu’elle doit fonctionner.
- Quelqu’un est tombé par hasard sur une publication qui dit que le mécanisme qu’ils ont déjà implémenté avec succès ne fonctionne pas (ils ne vont pas rechercher l’article, bien évidement, parce qu’ils ont déjà résolu le problème). Ils ne vont perdre aucun temps – sauf s’ils décident de trouver l’erreur dans l’article.
Il existe, inévitablement, un contre argument. Quelqu’un serait peut-être en train de chercher une idée stratégique sur comment approcher un stade majeur de leur implémentation, et écarte une ligne d’attaque très utile parce qu’une publication stipule qu’elle (ligne d’attaque) ne va pas fonctionner. Si cela devait arriver les conséquences auraient eu un impact majeur sur la qualité et sur l’extensibilité du produit final. Par contre, je préfère penser que quelqu’un qui est en train de réfléchir stratégiquement sur des options de conception ne serait pas enclin à négliger une idée sur la base d’un seul article sauf si celui-ci contient quelques très bons arguments et bonnes démonstrations.
Peut-être que le problème n’est pas tellement ce que dit l’article mais plutôt comment il le dit. Ce n’est pas grave de vous tromper ou (comme cela arrive plus fréquemment) de vous tromper partiellement à condition que vous disposiez d’une démonstration claire du travail que vous avez fait pour arriver à votre conclusion. Si vous avez fourni des évidences (et vous êtes arrivé à le présenter proprement) ceci va fournir aux lecteurs l’opportunité de faire des observations comme ‘’ l’exemple stocke des entiers dans des colonne du type varchar2()’’, ‘’ l’exemple utilise un index à deux colonnes, mais il va avoir une seule colonne’’, ‘’l’exemple utilise le tablespsace petitfichier, mais pas grandfichier’’ et, peut-être le plus important ‘’l’exemple tourne sur 8.1.7.4 et pas sur 11.2.0.3’’
0.000000
0.000000
