Discussion :

[tropiko]

Bonjour,

J'ai un traitement « T » qui prend 8 heures en temps normal en 10g.
Ce traitement exécute plusieurs procédures PL/SQL.
En migrant la production de 10g vers 11g le risque de voir partir quelques requêtes en vrille n'est pas écarté malgré les tests de perfs 11g déjà effectués dans une base de test.

Si après 3h/8h de traitement une requête part en vrille (un plan d’exécution non optimal en 11g) , je serais obligé d’arrêter le traitement "T" (kill session) et tout relancer après avoir apporté l’optimisation de la requête en question.

Est-il possible au moment où la requête part en vrille de l’optimiser « en live » comme si je force l’optimiseur 11g à abandonner le plan d’exécution courant(non optimal) et opter pour un autre plan (hint ?) sans arrêter la requête(le traitement T poursuit donc son exécution) ?
L’objectif est de ne pas bloquer la production car si par exemple je rencontre 5 requêtes / 3000 qui partent en vrille, je serais contraint de relancer le traitement lourd au moins 5 fois en espérant que l’optimisation fonctionne du premier coup !!!
Désolé d’avoir utilisé le mot « partir en vrille » plusieurs fois…
Merci pour vos idées.

[mnitu]

Optimisez vos traitements avant la mise en production.

[tropiko]

Optimisez vos traitements avant la mise en production.

désolé ce n'est pas la question !

[ojo77]

La réponse est non, vous ne pouvez pas changer un plan d'exécution pendant l'exécution en 11g (ni dans les versions inférieure).

La bonne marche à suivre est d'optimiser le traitement avant de passer en production comme vous l'a indiqué mnitu

[Arkhena]

Bonjour,

Votre projet de migration ne comporte pas une phase pilote pendant laquelle au moins les batchs sont joués sur une restore de la prod ?

Vous pouvez aussi utiliser database replay (payant) pour enregistrer votre activité sur 1 semaine par exemple et la rejouer sur la version 11g pour avoir une idée de ce que ça va donner...

Cordialement,

Arkhena

[tropiko]

Comme vous le savez tous nous ne sommes pas à l'abri d'une requête qui change de plan d’exécution suite à la migration 11g de la prod malgré les tests effectués dans des environnements de test "similaires" avant la mise en prod.

Ma question était comment optimiser "en live" en production tout en évitant de RELANCER des gros traitements après avoir effectué l'optimisation de la requête en question.

Je l'avait compris ...c'est tout simplement impossible.
merci.

[fatiharry]

bonjour je vous conseille de lire ce document(pièce jointe ) sur l'optimisation des requêtes oracle , c'est intéressant .

[Rams7s]

Salut,

Est-ce que Sql plan mangement (DBMS_SPM) ne pourrait pas vous aider?
Mode capture all avant le batch de 8h sur la 10g, vous enregistrez le tout, et vous fixez les plans sur la 11g.
Ca permettrait d'éviter des débordements le temps que le CBO ne vous propose de nouveaux plans à valider par les DBAs.