Même query, même user, client différent, plan d'exécution différent

Hello,

Depuis peu je commence à m'aventurer dans le monde Oracle et je me heurte ici à un problème (de session d'après moi) de performance/choix de plan d'exécution.

Sur une base 10.2, une même query, exécutée via un rapport BO ou via TOAD utilise un plan d'exécution différent.

Via BO, je remarque dans GRID un parsing schema étant MDBREAD et du parralélisme.
La requête/le rapport plante avec le message d'erreur suivant:

Citation:

---

ORA-12801: error signaled in parallel query server P015.
ORA-01652: unabale to extend temp segment by 256 in table space TEMP.

---

L'espace TEMP ayant déjà été doublé, on pense que le soucis est ailleurs.

Via TOAD, la même requête s'exécute quasi instantanément.
Le plan d'exécution est sans parrallélisme.
Le "parsing schéma" est MDBADM.


Est ce que quelqu'un à une idée de ce qui se passe ?
Que représente le "parsing schéma" que l'on peut voir dans GRID ?
Comment le "parsing schema" est-il choisi ?
Comment un user, pour une même query, peut prendre 2 chemins différents ? Est ce relatif à une session ? Au client ?
De quel coté devrais-je aller regarder ?

Merci d'avance :)

Je pense que dans votre cas c’est simple : vous avez les mêmes objets dans des schémas différents.

Pour être réutilisable une requête doit être strictement identique à la requête qui existe dans le shared_pool et de plus son environnement de compilation doit être aussi identique. Pour exemple la même requête exécutée avec la trace SQL activée est recompilée, donc c'est une autre requête.

Confronté à un problème de manque d’espace dans le TEMP pour des requêtes BO je commence toujours par regardées les jointures (semi)cartésiennes, après m’avoir assuré que les préconisations en termes d’espace temporaire sont respectés.

TOAD part quasi systématiquement en mode first rows et interdit le bind peeking ... ce n'est un outil de test.

Les variables NLS peuvent aussi jouer dans votre dos.

Pour trouver la raison il est intéressant de lancer une trace 10053 sur les deux parsings (TOAD et SQLPLUS depuis votre serveur BO) et de comparer les environnements entre les deux exécutions

Pour la partie "systématiquement en first_rows" il devrait faire soit un alter session soit ajouter le hint ce qui est plutôt moche. Je doute qu’il le fait.

Pour la partie « interdit le bind peeking » je me rappelle qu’il y avait un problème avec le thin driver version 9.

C'est bien ce que je reproche à 'l'outil' de faire des alter session à la pelle sans prévenir ;)

Ça doit bien être quelque part dans les options, mais j'avoue que ça m'a déjà joué des tours également.

Concernant la trace 10053 ca à l'air assez hardcore comme approche de ce que j'ai pu lire. C'est vraiment plongé dans les choix l'optimiseur.
Ca peut-être intéressant néanmoins comme exercice.
Je testerai.

J'essaierai aussi de faire les tests depuis TOAD et depuis SQLPLUS et de comparer les résultats.

Ce qui m'a vraiment frappé, c'est la différence de parsing_schéma utilisé.
Si ma mémoire ne me joue pas de tours, les 2 plans étaient en mode CHOOSE -> à priori pas de first_row (à vérifier).

Merci en tout cas pour le feedback !

Citation:

---

Envoyé par Ptit_Dje

...Ce qui m'a vraiment frappé, c'est la différence de parsing_schéma utilisé.
...

---

C'est assez simple à réproduire

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 Connected as mni   SQL> select count(*) from emp look_at_me;   COUNT(*) ---------- 14   SQL> alter session set current_schema=scott;   Session altered   SQL> select count(*) from emp look_at_me;   COUNT(*) ---------- 14   SQL> SQL> Select t.SQL_ID, t.CHILD_NUMBER, t.EXECUTIONS, t.PARSE_CALLS, t.PARSING_USER_ID, t.PARSING_SCHEMA_ID 2 from v$sql t 3 Where sql_text like '%look_at_me%' 4 and sql_text not like '%v$sql%' 5 /   SQL_ID CHILD_NUMBER EXECUTIONS PARSE_CALLS PARSING_USER_ID PARSING_SCHEMA_ID ------------- ------------ ---------- ----------- --------------- ----------------- 69amg80kkjvcs 0 1 1 67 67 69amg80kkjvcs 1 1 1 67 100   SQL>

---

@Ptit_Dej:
Huhu, on regarde pas la trace avec ses petits yeux. :lol:
On utilises tkprof pour la formater un petit peu. (dans $ORACLE_HOME/bin)

Tkprof ne sait pas faire grand chose pour la trace 10053. Et pour la trace SQL si, parfois on peut regarder le fichier de trace par ses petits yeux.

Bonjour,

Citation:

---

De quel coté devrais-je aller regarder ?

---

Il y a des tas de raisons qui peuvent faire que le plan d'exécution est différent, mais ici si le problème est qu'il y a du parallel query sans le vouloir, alors il faut regarder le degré des tables et des index. S'il y en a un différent de 1 alors on autorise le parallel query.

Citation:

---

Que représente le "parsing schéma" que l'on peut voir dans GRID ? Comment le "parsing schema" est-il choisi ?

---

Parsing schema, c'est le user qui a parsé la requête (le premier à l'avoir exécuté probablement).

Citation:

---

Comment un user, pour une même query, peut prendre 2 chemins différents ? Est ce relatif à une session ? Au client ?

---

A la session oui si des paramètres influençant l'optimiseur sont différents. Au client oui s'il change des paramètres de session. Mais aussi à la charge du système (un parallel query peut être dégradé en serial), mais aussi dans la même session il peut y avoir cardinality feedback qui change un plan au bout de plusieurs exécutions, ... bref plus l'optimiseur est intelligent et moins les plans seront stables.

Cordialement,
Franck.