Bonjour,
Je travaille depuis quelques mois chez un client.
Le SGBD est "Oracle Database 10g Release 10.1.0.5.0 - Production".
Le modèle des données est un modèle éditeur.
Etant expert sur le logiciel, je maîtrise parfaitement ce modèle des données.
Parmi les dizaines de clients chez qui je suis intervenu, c'est la première fois que j'ai autant de problèmes de performances.
Le client, qui se vexe lorsque je lui fait remarquer ces problèmes me rétorques :
- Que leur base de données est immense
- Qu'il y a énormément de traitements dessus
Ça, c'est vrai, il s'agit d'une base volumineuse, et entre les traitements interactifs et les traitements batch, Oracle ne chôme pas une seconde.
Mais malgré ça, je persiste et signe : le serveur se comporte anormalement.
Il utilise par exemple les index n'importe comment : lors d'une jointure sur une FK, il va par exemple parfois préférer faire des nested loop sur un full table scan plutôt qu'un index scan...
Du coup, d'une requête à l'autre (avec pour ainsi dire aucune modification), on passe de quelques millisecondes d'exécution à plusieurs heures.
Aussi, phénomène que je n'ai pas vu depuis Oracle 7, l'optimiseur est sensible à l'ordre des tables dans la clause FROM :
=> table4 est lu à grands couprs de full table scan
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6 select * from table1 t1 inner join table2 t2 on t2.id = t1.fk inner join table3 t3 on t3.id = t2.fk inner join table4 t4 on t4.id = t1.fk
Alors que :
=> Tout fonctionne à merveille
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6 select * from table1 t1 inner join table4 t4 on t4.id = t1.fk inner join table2 t2 on t2.id = t1.fk inner join table3 t3 on t3.id = t2.fk
Comment expliquez-vous ce phénomène ?
Un DBA vient une fois par mois regarder la base. J'aimerais pouvoir le coincer avec une étude un peu approfondie en lui disant "ben vérifie ceci, parce que visiblement ça va pas du tout"
Parmi les pistes que j'ai il y a le recalcul des index : ils sont calculés tous les dimanches soir... Alors que toute la semaine, il y a des gros traitements qui modifient plus de 50% des lignes des plus grosses table... sans recalcul des index !
Mais ceci n'explique pas le problème d'ordre des table cité ci-dessus...
Partager