Pb requete oracle longue en 10G, rapide en 8i Fermé

Question

Bonjour,
La requete suivante est quasi instantané en Oracle 8i et prend plusieurs secondes en Oracle1OG.
Pour un volume identique.

Quelqu'un sait-il pourquoi ?

Merci

select c.num_cmde,
       c.cod_cmde_edi,
       c.cod_ficl,
       c.datheu_cre,
       f.nom_ficl,
       c.etat_cmde,
       'N' as cs_rev,
       c.cmde_attente,
       a.cod_cren,
       c.cod_soci
  from commande c,
       filclient f,
       canal a,
       fichepvte p
 where f.cod_ficl = c.cod_ficl
   and p.cod_canl = a.cod_canl
   and c.etat_cmde in ( 9, 90)
   and p.cod_clie = f.cod_clie_pvte
   and p.cod_fich_pvte = f.cod_fich_pvte
   and p.cod_clie = c.cod_clie_pvte
   and p.cod_fich_pvte = c.cod_fich_pvte
   and c.cod_tcde <> 'CG'
   and not exists ( select 1
                      from commandel
                     where commandel.num_cmde = c.num_cmde
                       and commandel.etat_lcde = 15)
   and not exists ( select 1
                      from pcs_commandel
                     where pcs_commandel.num_cmde = c.num_cmde
                       and pcs_commandel.etat_lcde_pcs > 9)



explain plan 10G

SELECT STATEMENT, GOAL = ALL_ROWS			5774	1	95
 PX COORDINATOR					
  PX SEND QC (RANDOM)	SYS	:TQ10004	5774	1	95
   NESTED LOOPS ANTI			5774	1	95
    NESTED LOOPS ANTI			5771	1	88
     NESTED LOOPS			5768	1	81
      HASH JOIN			5767	1	78
       PX RECEIVE			433	38704	270928
        PX SEND HASH	SYS	:TQ10003	433	38704	270928
         VIEW	SYSACL	index$_join$_004	433	38704	270928
          HASH JOIN BUFFERED					
           BUFFER SORT					
            PX RECEIVE			181	38704	270928
             PX SEND HASH	SYS	:TQ10000	181	38704	270928
              INDEX FAST FULL SCAN	SYSACL	FICHEPVTE_COD_CANL_FK	181	38704	270928
           PX RECEIVE			250	38704	270928
            PX SEND HASH	SYS	:TQ10002	250	38704	270928
             PX BLOCK ITERATOR			250	38704	270928
              INDEX FAST FULL SCAN	SYSACL	FICHEPVTE_PK	250	38704	270928
       BUFFER SORT					
        PX RECEIVE			5332	101812	7228652
         PX SEND HASH	SYS	:TQ10001	5332	101812	7228652
          HASH JOIN			5332	101812	7228652
           TABLE ACCESS FULL	SYSACL	FILCLIENT	255	37883	1250139
           TABLE ACCESS FULL	SYSACL	COMMANDE	4723	101812	3868856
      TABLE ACCESS BY INDEX ROWID	SYSACL	CANAL	1	1	3
       INDEX UNIQUE SCAN	SYSACL	CANAL_PK	0	1	
     TABLE ACCESS BY INDEX ROWID	SYSACL	COMMANDEL	3	303669	2125683
      INDEX RANGE SCAN	SYSACL	COMMANDEL_ETAT_LCDE	2	4	
    TABLE ACCESS BY INDEX ROWID	SYSACL	PCS_COMMANDEL	3	498202	3487414
     INDEX RANGE SCAN	SYSACL	PCS_COMMANDEL_PK	2	1	


explain plan 8i
SELECT STATEMENT, GOAL = CHOOSE			3265	1	100
 FILTER					
  NESTED LOOPS			3265	1	100
   NESTED LOOPS			3264	1	95
    NESTED LOOPS			3258	6	348
     TABLE ACCESS FULL	SYSACL	COMMANDE	3027	231	11088
     TABLE ACCESS BY INDEX ROWID	SYSACL	FICHEPVTE	1	38305	383050
      INDEX UNIQUE SCAN	SYSACL	FICHEPVTE_PK		38305	
    TABLE ACCESS BY INDEX ROWID	SYSACL	FILCLIENT	1	38045	1407665
     INDEX UNIQUE SCAN	SYSACL	FILCLIENT_PK		38045	
   TABLE ACCESS BY INDEX ROWID	SYSACL	CANAL	1	21	105
    INDEX UNIQUE SCAN	SYSACL	CANAL_PK		21	
  TABLE ACCESS BY INDEX ROWID	SYSACL	COMMANDEL	5	2	18
   INDEX RANGE SCAN	SYSACL	COMMANDEL_PK	3	2	
  TABLE ACCESS BY INDEX ROWID	SYSACL	PCS_COMMANDEL	7	5	45
   INDEX RANGE SCAN	SYSACL	PCS_COMMANDEL_PK	3	5

LoloBary · Accepted Answer

Désactive le PARALLEL QUERY sur ton instance, au niveau des tables ou à l'aide d'un hint dans ta requête (NOPARALLEL)
Explications : le parallel query a tendance à privilégier les Full Table Scan.
En supposant bien sûr que tu as re-calculé les stats après la migration (DBMS_STATS.GATHER_DATABASE_STATS).

Fanouille · Answer

Bonjour,

Je cherche une solution à ce même problème présentement. Le passage de 9i vers 10g a été néfaste pour cette requête:
CURSOR C1 IS
   SELECT G3_NOID.NOID FROM G3_NOID
   WHERE G3_NOID.NO_USAG in 
   (select distinct G3_USAG.NO_USAG from G3_USAG
   WHERE G3_USAG.NO_PARTI = v_no_parti)
   ORDER BY NVL(DH_FIN_USAGE,'3000-01-01') DESC, 
            DH_DEB_USAGE DESC;
On se donne des nouvelles!
Toi, as-tu trouvé pourquoi c'est devenu si lent?

rasta_dba · Answer

bonjour,
Jettes un coup d'oeil à tes stats ;oracle 10 les prend avec l'option for all columns size auto différent de la maniére dont oracle 8i les prenez
as tu passez les stats systemes apres la migration????
verifies la presence histogrammes sur tes colonnes et n'hesites pas à faire une comparaison avec ta base en 8i

MLAB · Answer

Si vous êtes connecté en ODBC, il s'agit sans doute d'un problème de driver Oracle.

Voir sur metalink.oracle.com le Doc ID: Note:373129.1 intitulé Slow Performance Exhibited by Oracle ODBC Against 10.2 Oracle Database

Voir aussi https://www.experts-exchange.com/questions/22803543/Oracle-ODBC-10-2-0-1-is-very-slow-in-connection-MS-Access-to-Oracle-DB-compared-to-ODBC-8-1-7.html

On peut utiliser le driver 9 sur une base 10 ou patcher le driver 10 (ce que je n'ai pas encor essayé)

Pb requete oracle longue en 10G, rapide en 8i

4 réponses

Discussions similaires