Discussion :

[debdba]

Bonjour,
Pour bénéficier des améliorations de la 10g, j'ai migrée une instance depuis Oracle 9.2.0.5 vers 10.2.0.1.
Et là: catastrophe!
Une requete qui habituellement met 3mn, affiche sur la console entreprise manager prés de 20h. et avance à trés petits pas de block.

Les plans d'accés sont identiques avec l'instance en 9i qui a la mème volumétrie (~700000 lignes), il s'agit d'un full scan de la table, car les index sont inhibés par la requete.
Que je mette une sga_target à 900M, ou que je modifie le .ora avec 700M de db_cache_size et 200M de shared_pool j'ai la mème situation catastrophique.
Je ne sais quelle direction prendre pour comprendre
Je me connecte directement au niveau du serveur base de données par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
sqlplus user/password
select * from matable where (ol1(varchar2) not like 'X%' or to_date(col1, 'YYYYMMDD') > to_date(20080710', 'YYYYMMDD'))

Avez vous une idée d'orientation de recherches

Par avance merci

[orafrance]

si col1 est un NUMBER tu peux déjà supprimer le TO_DATE et il n'ai pas possible de faire en sorte que la fonction ol1 retourne 1 seul caractère :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM matable WHERE ol1(varchar2) <> 'X' OR col1 > 20080710

Pourquoi 10.2.0.1 et pas 10.2.0.3 ou plus ?

T'as comparé les paramètres des 2 instances comme disk_asynch_io, hash_area_size, hash_join_enabled, optimizer_*, parallélisme, etc ?

C'est la même machine ? La charge CPU ou I/O sur la machine n'est pas excessive ?

[debdba]

Les paramètres non obsolètes en 10g (comme hash_join_enabled) sont strictement identiques à ceux présents en 9i.
Il s'agit de 2 serveurs AIX différents celui en 10g est en 5.3, le serveur de la version 9I est en 4.3.
Lorsque la requete tourne en base 10g il n'y a aucune charge significative sur le serveur ni en cpu ni en IO, comme s'il ne se passait rien de particulier.

Par ailleurs je ne peux pas modifier la requete car il s'agit d'un progiciel livré ainsi.
De plus cette requete étant trés rapide en 9i je ne peux pas justifier une modification d'écriture.

Autre bizarerie, lorsque je regarde la requete au niveau Console Entreprise Manager, le status de la session est "inactive" malgré l'activité évidente bien que lente.

[orafrance]

faut alors la mettre en trace pour savoir ce qu'elle attend ou au moins regarder v$session_wait.

[debdba]

J'ai mis en place statpack et j'obtiens ceci

Cache Sizes Begin End
~~~~~~~~~~~ ---------- ----------
Buffer Cache: 652M Std Block Size: 8K
Shared Pool Size: 152M Log Buffer: 6,023K

Load Profile Per Second Per Transaction
~~~~~~~~~~~~ --------------- ---------------
Redo size: 432,440.26 56,467.91
Logical reads: 16,206.93 2,116.30
Block changes: 2,253.25 294.23
Physical reads: 10,706.55 1,398.06
Physical writes: 117.86 15.39

Instance Efficiency Percentages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 34.04 In-memory Sort %: 99.93
Library Hit %: 93.74 Soft Parse %: 94.11
Execute to Parse %: 81.84 Latch Hit %: 99.98
Parse CPU to Parse Elapsd %: 28.76 % Non-Parse CPU: 99.87

Shared Pool Statistics Begin End
------ ------
Memory Usage %: 91.92 88.34
% SQL with executions>1: 73.72 67.82
% Memory for SQL w/exec>1: 92.78 81.32

Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time
----------------------------------------- ------------ ----------- ------ ------
CPU time 11,657 59.2
db file sequential read 269,075,476 5,896 0 29.9
log file parallel write 79,659 618 8 3.1
db file parallel write 53,275 600 11 3.0
library cache pin 183 536 2930 2.7
-------------------------------------------------------------

Mème si j'augmente la taille de buffer_cache, le buffer hit est meilleur mais ma requete est toujours aussi lente

[orafrance]

c'est complétement inutile... c'est la vue instantanée de la session qu'il faut