[oracle_br] Re: Performance de Query

2006-08-24 Por tôpico jorgedonato2001
Marcio,

segue o Tkprof:


###

SELECT BOP_RG_FONEMA.ID_RG,
 BOP_RG_FONEMA.FONEMA,
 BOP_RG.NM_NOME,
 BOP_RG.NM_MAE,
 BOP_RG.DT_NASCIMENTO
FROM BOP_RG_FONEMA,
BOP_RG
  WHERE BOP_RG_FONEMA.FONEMA LIKE '%'||:b2 ||'%'
 AND BOP_RG.ID_RG = BOP_RG_FONEMA.ID_RG

call count   cpuelapsed   disk  querycurrent 
  rows
--- --   -- -- -- -- 
--
Parse1  0.00   0.00  0  0  0 
 0
Execute  1  0.00   0.00  0  0  0 
 0
Fetch38519 29.74 181.03 122399  72271  0 
577757
--- --   -- -- -- -- 
--
total38521 29.74 181.03 122399  72271  0 
577757

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 5  (SYSTEM)

Rows Row Source Operation
---  ---
 577757  HASH JOIN
 577757   INDEX RANGE SCAN IDX2_BOP_RG_FONEMA (object id 48230)
2249333   INDEX FAST FULL SCAN IDX5_BOP_RG (object id 48158)


Rows Execution Plan
---  ---
  0  SELECT STATEMENT   GOAL: CHOOSE
 577757   HASH JOIN
 577757INDEX   GOAL: ANALYZED (RANGE SCAN) OF 'IDX2_BOP_RG_FONEMA'
   (NON-UNIQUE)
2249333INDEX   GOAL: ANALYZED (FAST FULL SCAN) OF 'IDX5_BOP_RG'
   (NON-UNIQUE)

##

Att,
Jorge Donato

--- Em oracle_br@yahoogrupos.com.br, Marcio Portes
[EMAIL PROTECTED] escreveu

 Queria ver o tkprof dessa query.
 bom, 3 sugestões.
 
 Atualiza as estatísticas com histogramas nas colunas indexadas.
 
 select fonema.id_rg,
fonema.fonema,
rg.nm_nome,
rg.nm_mae,
rg.dt_nascimento
   from (
 select id_rg,
fonema,
   from bop_rg_fonema
  where fonema like '%'||:b2 ||'%'
) fonema,
bop_rg rg
  where rg.id_rg = fonema.id_rg
 /
 
 e criar um índice em bop_rg(id_rg), para tentar conter o range scan de 2
 milhões de linhas na bop_rg.
 
 
 On 8/23/06, jorgedonato2001 [EMAIL PROTECTED] wrote:
 
  Tenho a seguinte situacão:
 
  SQL VARIABLE b1 number;
  SQL VARIABLE b2 varchar2(85);
  SQL VARIABLE b3 number;
  SQL VARIABLE b4 number;
  SQL
  SQL EXECUTE :b1 := 9;
 
  PL/SQL procedure successfully completed.
 
  Elapsed: 00:00:00.01
  SQL EXECUTE :b2 := 'MR';
 
  PL/SQL procedure successfully completed.
 
  Elapsed: 00:00:00.00
  SQL EXECUTE :b3 := 999;
 
  PL/SQL procedure successfully completed.
 
  Elapsed: 00:00:00.00
  SQL EXECUTE :b4 := 1;
 
  PL/SQL procedure successfully completed.
 
  Elapsed: 00:00:00.01
  SQL
  SQL SELECT BOP_RG_FONEMA.ID_RG,
2   BOP_RG_FONEMA.FONEMA,
3   BOP_RG.NM_NOME,
4   BOP_RG.NM_MAE,
5   BOP_RG.DT_NASCIMENTO
6  FROM BOP_RG_FONEMA,
7  BOP_RG
8WHERE BOP_RG_FONEMA.FONEMA LIKE '%'||:b2 ||'%'
9   AND BOP_RG.ID_RG = BOP_RG_FONEMA.ID_RG;
 
  577757 rows selected.
 
  Elapsed: 00:05:19.83
 
  Execution Plan
  --
 0  SELECT STATEMENT Optimizer=CHOOSE (Cost=12848 Card=112467 By
tes=22718334)
 
 10   HASH JOIN (Cost=12848 Card=112467 Bytes=22718334)
 21 INDEX (RANGE SCAN) OF 'IDX2_BOP_RG_FONEMA' (NON-UNIQUE)
(Cost=88 Card=112467 Bytes=2024406)
 
 31 INDEX (FAST FULL SCAN) OF 'IDX5_BOP_RG' (NON-UNIQUE) (Co
st=6010 Card=2249333 Bytes=413877272)
 
 
 
 
 
  Statistics
  --
0  recursive calls
0  db block gets
72271  consistent gets
98716  physical reads
0  redo size
118090042  bytes sent via SQL*Net to client
   269853  bytes received via SQL*Net from client
38519  SQL*Net roundtrips to/from client
0  sorts (memory)
0  sorts (disk)
   577757  rows processed
 
 
  Tenho os seguintes índices
 
  CREATE INDEX EBOP.IDX5_BOP_RG ON EBOP.BOP_RG
  (NM_NOME, ID_RG, NM_MAE, DT_NASCIMENTO)
  Distinct Keys:2249329
 
  CREATE INDEX EBOP.IDX2_BOP_RG_FONEMA ON EBOP.BOP_RG_FONEMA
  (FONEMA, ID_RG)
  Distinct Keys:2249330
 
  Tabela BOP_RG:
  2249333 Linhas
 
  Tabela BOP_RG_FONEMA:
  2249330 Linhas
 
 
  O tempo esta muito alto, alguma ídeia para melhorar essa query?
 
  Att,
  Jorge Donato
 
 
 
 
 
 
  
 
 
 
 
 -- 
 Marcio Portes
 Material Tecnico em Portugues - http://mportes.blogspot.com
 Practical Learning Oracle -
 http://mportes.blogspot.com/2006/02/practical-learning-oracle.html
 
 
 [As partes desta mensagem que não continham texto foram removidas]







--
Atenção! As 

[oracle_br] Re: Performance de Query

2006-08-24 Por tôpico jorgedonato2001
Valeu Chiappa, vou estudar e estar as suas sugestões.

Obrigado,
Jorge Donato

--- Em oracle_br@yahoogrupos.com.br, jlchiappa [EMAIL PROTECTED] escreveu

 pesquisa com %nnn% o melhor que vc pode obter normalmente é um range 
 scan mesmo, não tem muito jeito , e o range vai ser BEM largo, vc TEM 
 que procurar praticamente no índice todo , já que o % inicial 
 significa qquer coisa antes do argumento... Será que REALMENTE não dá 
 pra especificar sem o % inicial ?? Se realmente tiver que, pra um 
 caso desses ou vc usa o CONTAINS num índice text, ou tem um índice de 
 função que indexa só os caras que contém a chave de pesquisa, como 
 mostrado em http://asktom.oracle.com/pls/ask/f?
 p=4950:8:F4950_P8_DISPLAYID:37336026927381 . Uma outra opção, se 
 a pesquisa tiver que ser repetida várias vezes na mesma sessão, pode 
 ser ao invés de se ter o sub-conjunto menor dos regs que atendem à 
 chave de pesquisa indexados num índice de função, talvez possa ser te-
 los numa GTT populada pelo programa, se o custo pra resolver 
 BOP_RG.ID_RG = BOP_RG_FONEMA.ID_RG não for tão alto...
 
 []s
 
  Chiappa
 --- Em oracle_br@yahoogrupos.com.br, jorgedonato2001 [EMAIL PROTECTED] 
 escreveu
 
  Tenho a seguinte situacão:
  
  SQL VARIABLE b1 number;
  SQL VARIABLE b2 varchar2(85);
  SQL VARIABLE b3 number;
  SQL VARIABLE b4 number;
  SQL 
  SQL EXECUTE :b1 := 9;
  
  PL/SQL procedure successfully completed.
  
  Elapsed: 00:00:00.01
  SQL EXECUTE :b2 := 'MR';
  
  PL/SQL procedure successfully completed.
  
  Elapsed: 00:00:00.00
  SQL EXECUTE :b3 := 999;
  
  PL/SQL procedure successfully completed.
  
  Elapsed: 00:00:00.00
  SQL EXECUTE :b4 := 1;
  
  PL/SQL procedure successfully completed.
  
  Elapsed: 00:00:00.01
  SQL 
  SQL SELECT BOP_RG_FONEMA.ID_RG,
2   BOP_RG_FONEMA.FONEMA,
3   BOP_RG.NM_NOME,
4   BOP_RG.NM_MAE,
5   BOP_RG.DT_NASCIMENTO
6  FROM BOP_RG_FONEMA,
7  BOP_RG
8WHERE BOP_RG_FONEMA.FONEMA LIKE '%'||:b2 ||'%'
9   AND BOP_RG.ID_RG = BOP_RG_FONEMA.ID_RG;
  
  577757 rows selected.
  
  Elapsed: 00:05:19.83
  
  Execution Plan
  --
 0  SELECT STATEMENT Optimizer=CHOOSE (Cost=12848 Card=112467 
 By
tes=22718334)
  
 10   HASH JOIN (Cost=12848 Card=112467 Bytes=22718334)
 21 INDEX (RANGE SCAN) OF 'IDX2_BOP_RG_FONEMA' (NON-
 UNIQUE)
(Cost=88 Card=112467 Bytes=2024406)
  
 31 INDEX (FAST FULL SCAN) OF 'IDX5_BOP_RG' (NON-UNIQUE) 
 (Co
st=6010 Card=2249333 Bytes=413877272)
  
  
  
  
  
  Statistics
  --
0  recursive calls
0  db block gets
72271  consistent gets
98716  physical reads
0  redo size
118090042  bytes sent via SQL*Net to client
   269853  bytes received via SQL*Net from client
38519  SQL*Net roundtrips to/from client
0  sorts (memory)
0  sorts (disk)
   577757  rows processed
  
  
  Tenho os seguintes índices
  
  CREATE INDEX EBOP.IDX5_BOP_RG ON EBOP.BOP_RG
  (NM_NOME, ID_RG, NM_MAE, DT_NASCIMENTO)
  Distinct Keys:2249329
  
  CREATE INDEX EBOP.IDX2_BOP_RG_FONEMA ON EBOP.BOP_RG_FONEMA
  (FONEMA, ID_RG)
  Distinct Keys:2249330
  
  Tabela BOP_RG:
  2249333 Linhas
  
  Tabela BOP_RG_FONEMA:
  2249330 Linhas
  
  
  O tempo esta muito alto, alguma ídeia para melhorar essa query?
  
  Att,
  Jorge Donato
 







--
Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--__

OPORTUNIDADES DE TRABALHO, VAGAS, EMPREGOS PARA PROFISSIONAIS ORACLE VISITE: 
http://www.oraclebr.com.br/
__
Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine  
Links do Yahoo! Grupos

* Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/oracle_br/

* Para sair deste grupo, envie um e-mail para:
[EMAIL PROTECTED]

* O uso que você faz do Yahoo! Grupos está sujeito aos:
http://br.yahoo.com/info/utos.html

 





[oracle_br] Re: Performance de Query

2006-08-24 Por tôpico jorgedonato2001
Gabriel, 

estão sim.

Att,
Jorge Donato

--- Em oracle_br@yahoogrupos.com.br, Teixeira, Gabriel (WMI, Brazil -
Sao Paulo) [EMAIL PROTECTED] escreveu

 As estatísticas estão atualizadas?
 
   _  
 
 From: jorgedonato2001 [mailto:[EMAIL PROTECTED] 
 Sent: quarta-feira, 23 de agosto de 2006 15:01
 To: oracle_br@yahoogrupos.com.br
 Subject: [oracle_br] Performance de Query
 
 
 Tenho a seguinte situacão:
 
 SQL VARIABLE b1 number;
 SQL VARIABLE b2 varchar2(85);
 SQL VARIABLE b3 number;
 SQL VARIABLE b4 number;
 SQL 
 SQL EXECUTE :b1 := 9;
 
 PL/SQL procedure successfully completed.
 
 Elapsed: 00:00:00.01
 SQL EXECUTE :b2 := 'MR';
 
 PL/SQL procedure successfully completed.
 
 Elapsed: 00:00:00.00
 SQL EXECUTE :b3 := 999;
 
 PL/SQL procedure successfully completed.
 
 Elapsed: 00:00:00.00
 SQL EXECUTE :b4 := 1;
 
 PL/SQL procedure successfully completed.
 
 Elapsed: 00:00:00.01
 SQL 
 SQL SELECT BOP_RG_FONEMA.ID_RG,
   2   BOP_RG_FONEMA.FONEMA,
   3   BOP_RG.NM_NOME,
   4   BOP_RG.NM_MAE,
   5   BOP_RG.DT_NASCIMENTO
   6  FROM BOP_RG_FONEMA,
   7  BOP_RG
   8WHERE BOP_RG_FONEMA.FONEMA LIKE '%'||:b2 ||'%'
   9   AND BOP_RG.ID_RG = BOP_RG_FONEMA.ID_RG;
 
 577757 rows selected.
 
 Elapsed: 00:05:19.83
 
 Execution Plan
 --
0  SELECT STATEMENT Optimizer=CHOOSE (Cost=12848 Card=112467 By
   tes=22718334)
 
10   HASH JOIN (Cost=12848 Card=112467 Bytes=22718334)
21 INDEX (RANGE SCAN) OF 'IDX2_BOP_RG_FONEMA' (NON-UNIQUE)
   (Cost=88 Card=112467 Bytes=2024406)
 
31 INDEX (FAST FULL SCAN) OF 'IDX5_BOP_RG' (NON-UNIQUE) (Co
   st=6010 Card=2249333 Bytes=413877272)
 
 
 
 
 
 Statistics
 --
   0  recursive calls
   0  db block gets
   72271  consistent gets
   98716  physical reads
   0  redo size
   118090042  bytes sent via SQL*Net to client
  269853  bytes received via SQL*Net from client
   38519  SQL*Net roundtrips to/from client
   0  sorts (memory)
   0  sorts (disk)
  577757  rows processed
 
 
 Tenho os seguintes índices
 
 CREATE INDEX EBOP.IDX5_BOP_RG ON EBOP.BOP_RG
 (NM_NOME, ID_RG, NM_MAE, DT_NASCIMENTO)
 Distinct Keys:2249329
 
 CREATE INDEX EBOP.IDX2_BOP_RG_FONEMA ON EBOP.BOP_RG_FONEMA
 (FONEMA, ID_RG)
 Distinct Keys:2249330
 
 Tabela BOP_RG:
 2249333 Linhas
 
 Tabela BOP_RG_FONEMA:
 2249330 Linhas
 
 
 O tempo esta muito alto, alguma ídeia para melhorar essa query?
 
 Att,
 Jorge Donato
 
 
 
 
 
 
  
 
 
 [As partes desta mensagem que não continham texto foram removidas]







--
Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--__

OPORTUNIDADES DE TRABALHO, VAGAS, EMPREGOS PARA PROFISSIONAIS ORACLE VISITE: 
http://www.oraclebr.com.br/
__
Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine  
Links do Yahoo! Grupos

* Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/oracle_br/

* Para sair deste grupo, envie um e-mail para:
[EMAIL PROTECTED]

* O uso que você faz do Yahoo! Grupos está sujeito aos:
http://br.yahoo.com/info/utos.html

 




Re: [oracle_br] Re: Performance de Query

2006-08-24 Por tôpico Marcio Portes
Voce tentou as dicas que eu passei? Rodar a query com a subquery, a criacao
do indice e a coleta do histograma?

On 8/24/06, jorgedonato2001 [EMAIL PROTECTED] wrote:

 Valeu Chiappa, vou estudar e estar as suas sugestões.

 Obrigado,
 Jorge Donato

 --- Em oracle_br@yahoogrupos.com.br, jlchiappa [EMAIL PROTECTED] escreveu

 
  pesquisa com %nnn% o melhor que vc pode obter normalmente é um range
  scan mesmo, não tem muito jeito , e o range vai ser BEM largo, vc TEM
  que procurar praticamente no índice todo , já que o % inicial
  significa qquer coisa antes do argumento... Será que REALMENTE não dá
  pra especificar sem o % inicial ?? Se realmente tiver que, pra um
  caso desses ou vc usa o CONTAINS num índice text, ou tem um índice de
  função que indexa só os caras que contém a chave de pesquisa, como
  mostrado em http://asktom.oracle.com/pls/ask/f?
  p=4950:8:F4950_P8_DISPLAYID:37336026927381 . Uma outra opção, se
  a pesquisa tiver que ser repetida várias vezes na mesma sessão, pode
  ser ao invés de se ter o sub-conjunto menor dos regs que atendem à
  chave de pesquisa indexados num índice de função, talvez possa ser te-
  los numa GTT populada pelo programa, se o custo pra resolver
  BOP_RG.ID_RG = BOP_RG_FONEMA.ID_RG não for tão alto...
 
  []s
 
   Chiappa
  --- Em oracle_br@yahoogrupos.com.br, jorgedonato2001 [EMAIL PROTECTED]
  escreveu
  
   Tenho a seguinte situacão:
  
   SQL VARIABLE b1 number;
   SQL VARIABLE b2 varchar2(85);
   SQL VARIABLE b3 number;
   SQL VARIABLE b4 number;
   SQL
   SQL EXECUTE :b1 := 9;
  
   PL/SQL procedure successfully completed.
  
   Elapsed: 00:00:00.01
   SQL EXECUTE :b2 := 'MR';
  
   PL/SQL procedure successfully completed.
  
   Elapsed: 00:00:00.00
   SQL EXECUTE :b3 := 999;
  
   PL/SQL procedure successfully completed.
  
   Elapsed: 00:00:00.00
   SQL EXECUTE :b4 := 1;
  
   PL/SQL procedure successfully completed.
  
   Elapsed: 00:00:00.01
   SQL
   SQL SELECT BOP_RG_FONEMA.ID_RG,
 2   BOP_RG_FONEMA.FONEMA,
 3   BOP_RG.NM_NOME,
 4   BOP_RG.NM_MAE,
 5   BOP_RG.DT_NASCIMENTO
 6  FROM BOP_RG_FONEMA,
 7  BOP_RG
 8WHERE BOP_RG_FONEMA.FONEMA LIKE '%'||:b2 ||'%'
 9   AND BOP_RG.ID_RG = BOP_RG_FONEMA.ID_RG;
  
   577757 rows selected.
  
   Elapsed: 00:05:19.83
  
   Execution Plan
   --
  0  SELECT STATEMENT Optimizer=CHOOSE (Cost=12848 Card=112467
  By
 tes=22718334)
  
  10   HASH JOIN (Cost=12848 Card=112467 Bytes=22718334)
  21 INDEX (RANGE SCAN) OF 'IDX2_BOP_RG_FONEMA' (NON-
  UNIQUE)
 (Cost=88 Card=112467 Bytes=2024406)
  
  31 INDEX (FAST FULL SCAN) OF 'IDX5_BOP_RG' (NON-UNIQUE)
  (Co
 st=6010 Card=2249333 Bytes=413877272)
  
  
  
  
  
   Statistics
   --
 0  recursive calls
 0  db block gets
 72271  consistent gets
 98716  physical reads
 0  redo size
 118090042  bytes sent via SQL*Net to client
269853  bytes received via SQL*Net from client
 38519  SQL*Net roundtrips to/from client
 0  sorts (memory)
 0  sorts (disk)
577757  rows processed
  
  
   Tenho os seguintes índices
  
   CREATE INDEX EBOP.IDX5_BOP_RG ON EBOP.BOP_RG
   (NM_NOME, ID_RG, NM_MAE, DT_NASCIMENTO)
   Distinct Keys:2249329
  
   CREATE INDEX EBOP.IDX2_BOP_RG_FONEMA ON EBOP.BOP_RG_FONEMA
   (FONEMA, ID_RG)
   Distinct Keys:2249330
  
   Tabela BOP_RG:
   2249333 Linhas
  
   Tabela BOP_RG_FONEMA:
   2249330 Linhas
  
  
   O tempo esta muito alto, alguma ídeia para melhorar essa query?
  
   Att,
   Jorge Donato
  
 




 




-- 
Marcio Portes
Material Tecnico em Portugues - http://mportes.blogspot.com
Practical Learning Oracle -
http://mportes.blogspot.com/2006/02/practical-learning-oracle.html


[As partes desta mensagem que não continham texto foram removidas]



--
Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--__

OPORTUNIDADES DE TRABALHO, VAGAS, EMPREGOS PARA PROFISSIONAIS ORACLE VISITE: 
http://www.oraclebr.com.br/
__
Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine  
Links do Yahoo! Grupos

* Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/oracle_br/

* Para sair deste grupo, envie um e-mail para:
[EMAIL PROTECTED]

* O uso que você faz do Yahoo! Grupos está sujeito aos:
  

[oracle_br] Re: Performance de Query

2006-08-23 Por tôpico jlchiappa
pesquisa com %nnn% o melhor que vc pode obter normalmente é um range 
scan mesmo, não tem muito jeito , e o range vai ser BEM largo, vc TEM 
que procurar praticamente no índice todo , já que o % inicial 
significa qquer coisa antes do argumento... Será que REALMENTE não dá 
pra especificar sem o % inicial ?? Se realmente tiver que, pra um 
caso desses ou vc usa o CONTAINS num índice text, ou tem um índice de 
função que indexa só os caras que contém a chave de pesquisa, como 
mostrado em http://asktom.oracle.com/pls/ask/f?
p=4950:8:F4950_P8_DISPLAYID:37336026927381 . Uma outra opção, se 
a pesquisa tiver que ser repetida várias vezes na mesma sessão, pode 
ser ao invés de se ter o sub-conjunto menor dos regs que atendem à 
chave de pesquisa indexados num índice de função, talvez possa ser te-
los numa GTT populada pelo programa, se o custo pra resolver 
BOP_RG.ID_RG = BOP_RG_FONEMA.ID_RG não for tão alto...

[]s

 Chiappa
--- Em oracle_br@yahoogrupos.com.br, jorgedonato2001 [EMAIL PROTECTED] 
escreveu

 Tenho a seguinte situacão:
 
 SQL VARIABLE b1 number;
 SQL VARIABLE b2 varchar2(85);
 SQL VARIABLE b3 number;
 SQL VARIABLE b4 number;
 SQL 
 SQL EXECUTE :b1 := 9;
 
 PL/SQL procedure successfully completed.
 
 Elapsed: 00:00:00.01
 SQL EXECUTE :b2 := 'MR';
 
 PL/SQL procedure successfully completed.
 
 Elapsed: 00:00:00.00
 SQL EXECUTE :b3 := 999;
 
 PL/SQL procedure successfully completed.
 
 Elapsed: 00:00:00.00
 SQL EXECUTE :b4 := 1;
 
 PL/SQL procedure successfully completed.
 
 Elapsed: 00:00:00.01
 SQL 
 SQL SELECT BOP_RG_FONEMA.ID_RG,
   2   BOP_RG_FONEMA.FONEMA,
   3   BOP_RG.NM_NOME,
   4   BOP_RG.NM_MAE,
   5   BOP_RG.DT_NASCIMENTO
   6  FROM BOP_RG_FONEMA,
   7  BOP_RG
   8WHERE BOP_RG_FONEMA.FONEMA LIKE '%'||:b2 ||'%'
   9   AND BOP_RG.ID_RG = BOP_RG_FONEMA.ID_RG;
 
 577757 rows selected.
 
 Elapsed: 00:05:19.83
 
 Execution Plan
 --
0  SELECT STATEMENT Optimizer=CHOOSE (Cost=12848 Card=112467 
By
   tes=22718334)
 
10   HASH JOIN (Cost=12848 Card=112467 Bytes=22718334)
21 INDEX (RANGE SCAN) OF 'IDX2_BOP_RG_FONEMA' (NON-
UNIQUE)
   (Cost=88 Card=112467 Bytes=2024406)
 
31 INDEX (FAST FULL SCAN) OF 'IDX5_BOP_RG' (NON-UNIQUE) 
(Co
   st=6010 Card=2249333 Bytes=413877272)
 
 
 
 
 
 Statistics
 --
   0  recursive calls
   0  db block gets
   72271  consistent gets
   98716  physical reads
   0  redo size
   118090042  bytes sent via SQL*Net to client
  269853  bytes received via SQL*Net from client
   38519  SQL*Net roundtrips to/from client
   0  sorts (memory)
   0  sorts (disk)
  577757  rows processed
 
 
 Tenho os seguintes índices
 
 CREATE INDEX EBOP.IDX5_BOP_RG ON EBOP.BOP_RG
 (NM_NOME, ID_RG, NM_MAE, DT_NASCIMENTO)
 Distinct Keys:2249329
 
 CREATE INDEX EBOP.IDX2_BOP_RG_FONEMA ON EBOP.BOP_RG_FONEMA
 (FONEMA, ID_RG)
 Distinct Keys:2249330
 
 Tabela BOP_RG:
 2249333 Linhas
 
 Tabela BOP_RG_FONEMA:
 2249330 Linhas
 
 
 O tempo esta muito alto, alguma ídeia para melhorar essa query?
 
 Att,
 Jorge Donato







--
Atenção! As mensagens deste grupo são de acesso público e de inteira 
responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--__

OPORTUNIDADES DE TRABALHO, VAGAS, EMPREGOS PARA PROFISSIONAIS ORACLE VISITE: 
http://www.oraclebr.com.br/
__
Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine  
Links do Yahoo! Grupos

* Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/oracle_br/

* Para sair deste grupo, envie um e-mail para:
[EMAIL PROTECTED]

* O uso que você faz do Yahoo! Grupos está sujeito aos:
http://br.yahoo.com/info/utos.html