Même XPLAN mais temps très différent !

[tropiko]

Soit une requête R donnée ayant un plan d'exécution X qui tourne sans problème sur base A 10g sur un serveur S.

Est-il possible que cette même requête R ayant un plan d'exécution X IDENTIQUE subit une régression sur une base B 11g sur le même serveur S.

Les 2 base ont :

- même volumétrie
- même stats sur les objets.
-Paramètrage 10g proche de 11g

D’ailleurs la base B est un clonne de A + upgrade 10g/11g.

NB: LE PLAN D'EXECUTION EST IDENTIQIE 10g et 11g !

[ojo77]

bonjour,
J'ai plein de questions qui peuvent déboucher sur plein d'explications différentes :

Comment obtenez vous les plans ( dbms_xplan.display ou dbms_xplan.display_cursor )

Quelle est votre configuration IO ?

Comment avez-vous répliqué les données de la base 10g vers la base 11g ?

Avez vous les mêmes nombres de processeurs ?

Etes vous dans des environnements physiques ou virtualisés ?

[Mohamed.Houri]

Envoyé par tropiko

Soit une requête R donnée ayant un plan d'exécution X qui tourne sans problème sur base A 10g sur un serveur S.

Est-il possible que cette même requête R ayant un plan d'exécution X IDENTIQUE subit une régression sur une base B 11g sur le même serveur S.

Les 2 base ont :

- même volumétrie
- même stats sur les objets.
-Paramètrage 10g proche de 11g

D’ailleurs la base B est un clonne de A + upgrade 10g/11g.

NB: LE PLAN D'EXECUTION EST IDENTIQIE 10g et 11g !

Dans le cas où les deux plans d'exécutions sont les mêmes (vous auriez dû les poster) et qu'ils contiennent des opérations "FULL TABLE SCAN" une explication à votre problème pourrait être que dans la 11g l'opération "FULL TABLE SCAN" se fait via "direct path read" alors que dans la 10g la même opération se fait via "db file scattered read".

[mnitu]

@Mohamed,
En 11g l’accès en mode FULL ne se fait pas toujours via direct_path_read.
En principe « direct path read » est plus rapide que « db file scattered read » donc il est difficile d’expliquer la lenteur par ce changement.

[pachot]

Bonjour,

Beaucoup de chose peuvent faire que les temps de réponses soient différents. Mais déjà avoir les mêmes plans, c'est une bonne chose.

Ce serait interessant de comparer les statistiques d'exécution (dbms_xplan.display_cursor('','','ALLSTATS LAST') après execution avec statistics_level=all)

Envoyé par mnitu

En principe « direct path read » est plus rapide que « db file scattered read » donc il est difficile d’expliquer la lenteur par ce changement.

Oui, mais seulement une fois que le checkpoint est fait... Mohamed a raison: c'est une des différence importante qu'on peut voir apparaître en 11g.

Cordialement,
Franck.

[mnitu]

Envoyé par pachot

...Mohamed a raison: c'est une des différence importante qu'on peut voir apparaître en 11g.

Je n’en doute pas ! Mais est-vous en train de dire qu’il faut s’attendre à une dégradation du temps de réponse à cause de ce changement ?

[ora_home]

Envoyé par tropiko

Les 2 base ont :

- même volumétrie
- même stats sur les objets.
-Paramètrage 10g proche de 11g

D’ailleurs la base B est un clonne de A + upgrade 10g/11g.

NB: LE PLAN D'EXECUTION EST IDENTIQIE 10g et 11g !

Avoir deux plans identiques ne signifie pas forcément que le temps de réponse est le même. Donc il y a surement des valeurs qui sont différentes, on aura besoin d'avoir les deux fichiers TKPROF des deux requêtes pour pouvoir identifier la différence. Sinon c'est difficile de deviner comme ça.