Optimisation Oracle
Lorsqu’il n’y a plus d’espoir…
Chez le client où je suis actuellement, une reqûete toute bête explosait le tablespace temporaire ( qui fait 35 Go quand même ).
En regardant la requête sur laquelle il y avait un problème, on s’est aperçu qu’Oracle créait une table temporaire en essayant de jointurer deux tables de la requêtes qui n’avaient aucune jointure entre elles, d’où un produit cartésien -> l’explain plan prévoyait 93 Go de données temporaires, pour quelques milliers d’enreg, c’est beaucoup.
La solution vient du type de plan d’exécution utilisé par Oracle. Pour cette requete en particullier, c’est le _b_tree_bitmap_plans qui servait alors qu’il n’était pas le plus adapté.
Pour revenir à un plan d’exécution normal, il a suffit de faire : alter session set “_b_tree_bitmap_plans”=FALSE;
Et pour ne plus avoir de problème du tout, de positionner cette option à false au niveau de l’instance elle-même.
1 Comment so far
Leave a reply
Ouhaaa. Merci pour l’info. Je crois que je n’aura pas investigué tout de suite dans ce sens.
Et sous Teradata, tu fais comment ?