Bonjour,

Je teste depuis quelque temps le fonctionnement de notre application maison sur Oracle 10g, en vue d'une prochaine migration.

Le schéma de cette application comprend 4 tables protégées à l'aide du Fine Grained Access Control et d'un contexte utilisateur (ce système a été mis en place sous 8i).

Lors de la migration 9i, aucun problème de performances au niveau de ces tables. En revanche, sous 10g, je constate que les plans d'exécution des requêtes impliquant ces tables sont totalement modifiés, et les coûts explosent !
Si je désactive le système de protection, les plans d'exécution et les coûts redeviennent similaires à la 9i avec protection.

Voici un example de requête, bp étant une table protégée :

Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
SELECT *
  FROM bp bp, bp bp1, ro ro, baitclng baitclng, bp_uses_bo bpusesbo
 WHERE (baitclng.ID = bp.ID)
   AND (bp.id_bp_sup = bp1.ID(+))
   AND (bp.id_ro = ro.ID(+))
   AND ((bpusesbo.id_bo = :"SYS_B_0") AND (bpusesbo.id_bp = baitclng.ID))
Plan d'exécution sous 9i :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Operation	Object Name	Rows	Bytes	Cost	Object Node	In/Out	PStart	PStop
 
SELECT STATEMENT Optimizer Mode=CHOOSE		5  	 	5  	 	      	             	 
  NESTED LOOPS OUTER		5  	1 K	5  	 	      	             	 
    NESTED LOOPS OUTER		5  	670  	4  	 	      	             	 
      NESTED LOOPS		5  	540  	3  	 	      	             	 
        NESTED LOOPS		5  	125  	2  	 	      	             	 
          TABLE ACCESS BY INDEX ROWID	PBEXP.BP_USES_BO	5  	60  	1  	 	      	             	 
            INDEX RANGE SCAN	PBEXP.LIEN_3922_FK	5  	 	3  	 	      	             	 
          TABLE ACCESS BY INDEX ROWID	PBEXP.BAITCLNG	1  	13  	1  	 	      	             	 
            INDEX UNIQUE SCAN	PBEXP.PK_BAITCLNG	1  	 	 	 	      	             	 
        TABLE ACCESS BY INDEX ROWID	PBEXP.BP	1  	83  	1  	 	      	             	 
          INDEX UNIQUE SCAN	PBEXP.PK_BP	1  	 	1  	 	      	             	 
      TABLE ACCESS BY INDEX ROWID	PBEXP.RO	1  	26  	1  	 	      	             	 
        INDEX UNIQUE SCAN	PBEXP.PK_RO	1  	 	 	 	      	             	 
    TABLE ACCESS BY INDEX ROWID	PBEXP.BP	1  	83  	1  	 	      	             	 
      INDEX UNIQUE SCAN	PBEXP.PK_BP	1  	 	1
Plan d'exécution sous 10g :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Operation	Object Name	Rows	Bytes	Cost	Object Node	In/Out	PStart	PStop
 
SELECT STATEMENT Optimizer Mode=CHOOSE		5  	 	1165  	 	      	             	 
  NESTED LOOPS OUTER		5  	1 K	1165  	 	      	             	 
    NESTED LOOPS OUTER		5  	670  	1164  	 	      	             	 
      HASH JOIN		5  	540  	1163  	 	      	             	 
        NESTED LOOPS		5  	125  	2  	 	      	             	 
          TABLE ACCESS BY INDEX ROWID	PB10G.BP_USES_BO	5  	60  	1  	 	      	             	 
            INDEX RANGE SCAN	PB10G.LIEN_3922_FK	5  	 	1  	 	      	             	 
          TABLE ACCESS BY INDEX ROWID	PB10G.BAITCLNG	1  	13  	1  	 	      	             	 
            INDEX UNIQUE SCAN	PB10G.PK_BAITCLNG	1  	 	1  	 	      	             	 
        VIEW	PB10G.BP	347 K	27 M	1156  	 	      	             	 
          TABLE ACCESS FULL	PB10G.BP	347 K	27 M	1156  	 	      	             	 
      TABLE ACCESS BY INDEX ROWID	PB10G.RO	1  	26  	1  	 	      	             	 
        INDEX UNIQUE SCAN	PB10G.PK_RO	1  	 	1  	 	      	             	 
    TABLE ACCESS BY INDEX ROWID	PB10G.BP	1  	83  	1  	 	      	             	 
      INDEX UNIQUE SCAN	PB10G.PK_BP	1  	 	1
Désolée, ce n'est pas très lisible, mais le problème réside vraisemblablement dans cette ligne du plan :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
        VIEW	PB10G.BP	347 K	27 M	1156
D'où vient ce VIEW ?

Merci d'avance pour vos idées