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 :
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 :
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 :
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 :
VIEW PB10G.BP 347 K 27 M 1156
D'où vient ce VIEW ?
Merci d'avance pour vos idées
Partager