Pourquoi cette table indépendante est-elle analysée?

Question

J'ai une requête qui traverse deux tables

select count(*) from ingenium.empevt, ingenium.evt where empevt_evtfk = evt_pk 

il faut un temps assez long pour courir et essayer de comprendre pourquoi je regardais le plan

Operation Object Name Rows Bytes Cost Object Node In/Out PStart PStop 

SELECT STATEMENT Optimizer Mode=CHOOSE  634 K  75981         
    HASH JOIN  634 K 180 M 75981         
    HASH JOIN  845 K 234 M 8930         
     HASH JOIN  465 K 53 M 3118         
     NESTED LOOPS  620 K 15 M 1618         
      NESTED LOOPS  1 20  2         
      TABLE ACCESS BY INDEX ROWID INGENIUM.USR 1 10  1         
       INDEX UNIQUE SCAN INGENIUM.XAK1USR 1           
      TABLE ACCESS BY INDEX ROWID INGENIUM.USR 1 10  1         
       INDEX UNIQUE SCAN INGENIUM.XAK1USR 1           
      INDEX RANGE SCAN INGENIUM.SECUSREMP_USREMP 89 M 600 M 1616         
     TABLE ACCESS FULL INGENIUM.TBLEMP 620 K 55 M 1150         
     TABLE ACCESS FULL INGENIUM.TBLEMPEVT 1 M 182 M 4000         
    TABLE ACCESS FULL INGENIUM.SECUSREMP 89 M 600 M 27013 

Ce que je ne Tout comme l'accès à la table sur INGENIUM.SECUSREMP_USREMP qui a un grand nombre de lignes. Je ne sais pas pourquoi il scanne cette table car elle n'était pas dans la requête. INGENIUM.SECUSREMP_USREMP a une clé étrangère qui fait référence à ingenium.emp.emp_pk, mais je ne vois pas pourquoi cela aurait de l'importance.

Existe-t-il un moyen de réécrire cette requête afin qu'elle n'analyse pas une table apparemment sans rapport? Pourquoi numérise-t-il cette table en premier lieu?

Answer 1

Vraisemblablement à la fois empevt et evt sont des vues, pas des tables? Vos émissions de plan de requête (uniquement) ces tables étant accessibles:

• USR
• TBLEMP
• TBLEMPEVT
• SECUSREMP

Quelles sont les définitions de ces points de vue? Sauf si vous regardez le mauvais plan!