2010-07-14 6 views
1

TABLE_A = 7022536 lignescount() prendre plus de 20 secondes

Table_b (GTT) = 5601 lignes

Requête:

SELECT COUNT (a.ssn_head) 
    FROM table_a a, table_b b 
    WHERE b.hoh = a.head AND a.flag = 'Y'; 

prend plus de 20 secondes pour faire 17214 enregistrements.

Expliquer plan est:

Plan hash value: 1901401324 
-------------------------------------------------------------------------------- 
| Id | Operation   | Name       | Rows | Bytes | C 
-------------------------------------------------------------------------------- 
| 0 | SELECT STATEMENT |        |  1 | 25 | 1 
| 1 | SORT AGGREGATE  |        |  1 | 25 | 
|* 2 | HASH JOIN   |        | 114K| 2801K| 1 
| 3 | TABLE ACCESS FULL| table_b      | 49188 | 528K| 
| 4 | REMOTE   | table_a      | 7022K| 93M| 1 
-------------------------------------------------------------------------------- 

table_b (GTT) n'a pas d'indices à ce sujet ... Je pense que depuis la requête passe par tous table_b il fera toujours une scan..right complète de la table?

table_a a index sur head

Quelle autre façon est là pour faire de cette requête exécutée plus rapidement?

+1

Déplacer table_a sur le même serveur que table_b? –

+0

souhaité était une option> _ < –

+0

Considérons un index et une contrainte NOT NULL sur b.hoh. Voir http://stackoverflow.com/questions/721556/oracle-10g-optimize-where-is-not-null – PenFold

Répondre

5

Est-ce que hoh dans table_b est unique? Si oui, alors

SELECT COUNT (a.ssn_head) 
FROM table_a a, table_b b 
WHERE b.hoh = a.head AND a.flag = 'Y'; 

est logiquement équivalent à

SELECT COUNT (a.ssn_head) 
FROM table_a a 
WHERE a.flag = 'Y' 
and a.head in (select hoh FROM table_b); 

Étant donné que le volume de données plus important est sur le serveur distant, je vous suggère de pousser la requête là-bas avec l'indice de DRIVING_SITE.

SELECT /*+DRIVING_SITE (r) */ COUNT (r.col_a) 
FROM [email protected] r 
WHERE r.col_b in (select l.col_c FROM local l); 

Ceci devrait fonctionner avec un synonyme plutôt que table @ dblink. Mais cela ne fonctionnera probablement pas avec une vue.

3

Effectuez une vue matérialisée de table_a sur le serveur local et exécutez-la.

Il pourrait aussi aider (modérément) à mettre un index sur a.flag, mais cela sera mineur comparé au fonctionnement local.

+0

Vous aurez besoin d'ajouter des journaux d'affichage matérialisés sur le système distant sinon vous ne pourrez pas faire un "FAST REFRESH" de votre MV "localisé". – PenFold

Questions connexes