Re: [oracle_br] Ajuste em consulta
Amigo, Mostra o seu plano de execucao que fica mais facil de entendermos, mesmo tendo indice. explain plan for SELECT MAX(nu_seq_recibo) FROM SMS.recibo_env WHERE CO_ENV_RET = c.CO_ENV_RET; SELECT * FROM TABLE(dbms_xplan.display); Em 19 de julho de 2013 07:56, Jales Jose Moraes malphig...@yahoo.com.brescreveu: ** Sim, tem índice, inclusive são as chaves primárias das respectivas tabelas. Acredito que está acontecendo os gargalos são nas chamadas co-relacionadas na coluna c.CO_ENV_RET (que faz parte da consulta externa). Mas não estou sabendo estruturar a consulta de outra forma. De: Rodrigo Mufalani rodr...@mufalani.com.br Para: oracle_br@yahoogrupos.com.br Enviadas: Quinta-feira, 18 de Julho de 2013 17:05 Assunto: Re: [oracle_br] Ajuste em consulta Verifique se essas duas colunas tem índices.. Segue abaixo um pequeno teste. SQL create table teste as select * from dba_objects; Tabela criada. SQL @trcon SQL select max(created) from teste; Plano de Execuc?o -- Plan hash value: 2217472448 -- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time| -- | 0 | SELECT STATEMENT | |1 |9 | 358 (2)| 00:00:05 | | 1 | SORT AGGREGATE| |1 |9 || | | 2 | TABLE ACCESS FULL| TESTE | 101K| 892K| 358 (2)| 00:00:05 | -- Note - - dynamic sampling used for this statement (level=2) Estatisticas -- 7 recursive calls 0 db block gets 1385 consistent gets 1302 physical reads 0 redo size 363 bytes sent via SQL*Net to client 364 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed SQL create index ix_teste on teste(created); Indice criado. SQL select max(created) from teste; Plano de Execuc?o -- Plan hash value: 631728714 -- | Id | Operation | Name| Rows | Bytes | Cost (%CPU)| Time| -- | 0 | SELECT STATEMENT | |1 |9 |1 (0)| 00:00:01 | | 1 | SORT AGGREGATE| |1 |9 || | | 2 | INDEX FULL SCAN (MIN/MAX)| IX_TESTE |1 |9 |1 (0)| 00:00:01 | -- Note - - dynamic sampling used for this statement (level=2) Estatisticas -- 5 recursive calls 0 db block gets 77 consistent gets 1 physical reads 0 redo size 363 bytes sent via SQL*Net to client 364 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed SQL É claro que tem muito mais em jogo do que isso, porém é um bom começo O Guob está chegando 10/08/2013, não deixe de se inscrever em www.guob.com.br Atenciosamente, Rodrigo Mufalani rodr...@mufalani.com.br www.mufalani.com.br On 18/07/2013, at 16:53, Jales Jose Moraes malphig...@yahoo.com.br wrote: Bom tarde! Pessoal estou com uma consulta onde está executando muito lentamente, ao analisar o plano, descobri que os dois selects internos à consulta (estão abaixo), são os responsáveis pelo gargalo SELECT MAX(nu_seq_recibo) FROM SMS.recibo_env WHERE CO_ENV_RET = c.CO_ENV_RET SELECT MAX(nu_seq_libera) FROM SMS.libera_recibo WHERE co_env_ret = c.CO_ENV_RET; Alguém tem alguma dica para me ajudar com a questão? [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas] -- Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -- Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: http://www.oraclebr.com.br/ -- Links do Yahoo! Grupos [As partes desta mensagem que não continham texto foram removidas] -- Att, Diego Leite DBA ORACLE [As partes desta mensagem que não continham texto foram removidas
Re: [oracle_br] Ajuste em consulta
Diego gerei o plano, porém ele só vem a confirmar que não está usando o índice... | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | --- | 0 | SELECT STATEMENT | | 1 | 268 | | 6527 (2)| 00:01:19 | |* 1 | FILTER | | | | | | | | 2 | NESTED LOOPS ANTI | | 1 | 268 | | 6522 (2)| 00:01:19 | | 3 | NESTED LOOPS | | 1 | 266 | | 6518 (2)| 00:01:19 | | 4 | NESTED LOOPS | | 1 | 221 | | 6517 (2)| 00:01:19 | | 5 | NESTED LOOPS | | 1 | 191 | | 6516 (2)| 00:01:19 | | 6 | NESTED LOOPS | | 1 | 171 | | 6515 (2)| 00:01:19 | | 7 | NESTED LOOPS OUTER | | 1 | 157 | | 6514 (2)| 00:01:19 | |* 8 | HASH JOIN OUTER | | 1 | 127 | | 6513 (2)| 00:01:19 | | 9 | NESTED LOOPS OUTER | | 1 | 114 | | 6371 (2)| 00:01:17 | |* 10 | HASH JOIN | | 1 | 84 | | 6370 (2)| 00:01:17 | |* 11 | HASH JOIN | | 22757 | 1200K| | 5391 (2)| 00:01:05 | |* 12 | TABLE ACCESS FULL | RECIBO_ENV | 22757 | 622K| | 1855 (3)| 00:00:23 | | 13 | VIEW | VW_SQ_2 | 136K| 3458K| | 3535 (2)| 00:00:43 | | 14 | HASH GROUP BY | | 136K| 1330K| 18M| 3535 (2)| 00:00:43 | | 15 | TABLE ACCESS FULL | RECIBO_ENV_RETORNO | 953K| 9308K| | 1820 (1)| 00:00:22 | De: Diego Leite diegoleit...@gmail.com Para: oracle_br@yahoogrupos.com.br Enviadas: Sexta-feira, 19 de Julho de 2013 8:21 Assunto: Re: [oracle_br] Ajuste em consulta Amigo, Mostra o seu plano de execucao que fica mais facil de entendermos, mesmo tendo indice. explain plan for SELECT MAX(nu_seq_recibo) FROM SMS.recibo_env WHERE CO_ENV_RET = c.CO_ENV_RET; SELECT * FROM TABLE(dbms_xplan.display); Em 19 de julho de 2013 07:56, Jales Jose Moraes malphig...@yahoo.com.brescreveu: ** Sim, tem índice, inclusive são as chaves primárias das respectivas tabelas. Acredito que está acontecendo os gargalos são nas chamadas co-relacionadas na coluna c.CO_ENV_RET (que faz parte da consulta externa). Mas não estou sabendo estruturar a consulta de outra forma. De: Rodrigo Mufalani rodr...@mufalani.com.br Para: oracle_br@yahoogrupos.com.br Enviadas: Quinta-feira, 18 de Julho de 2013 17:05 Assunto: Re: [oracle_br] Ajuste em consulta Verifique se essas duas colunas tem índices.. Segue abaixo um pequeno teste. SQL create table teste as select * from dba_objects; Tabela criada. SQL @trcon SQL select max(created) from teste; Plano de Execuc?o -- Plan hash value: 2217472448 -- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -- | 0 | SELECT STATEMENT | | 1 | 9 | 358 (2)| 00:00:05 | | 1 | SORT AGGREGATE | | 1 | 9 | | | | 2 | TABLE ACCESS FULL| TESTE | 101K| 892K| 358 (2)| 00:00:05 | -- Note - - dynamic sampling used for this statement (level=2) Estatisticas -- 7 recursive calls 0 db block gets 1385 consistent gets 1302 physical reads 0 redo size 363 bytes sent via SQL*Net to client 364 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed SQL create index ix_teste on teste(created); Indice criado. SQL select max(created) from teste; Plano de Execuc?o -- Plan hash value: 631728714 -- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -- | 0 | SELECT STATEMENT | | 1 | 9 | 1 (0)| 00:00:01 | | 1
Re: [oracle_br] Ajuste em consulta
Este plano é referente as consultas que usou no primeiro email? Manda a consulta completa. Acho que mandou o plano da consulta completa e a consulta esta quebrada nao? SELECT MAX(nu_seq_recibo) FROM SMS.recibo_env WHERE CO_ENV_RET = c.CO_ENV_RET SELECT MAX(nu_seq_libera) FROM SMS.libera_recibo WHERE co_env_ret = c.CO_ENV_RET; Em 19 de julho de 2013 08:39, Jales Jose Moraes malphig...@yahoo.com.brescreveu: ** Diego gerei o plano, porém ele só vem a confirmar que não está usando o índice... | Id | Operation| Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | -- | 0 | SELECT STATEMENT | | 1 | 268 | | 6527 (2)| 00:01:19 | |* 1 | FILTER | | | | || | | 2 | NESTED LOOPS ANTI | | 1 | 268 | | 6522 (2)| 00:01:19 | | 3 |NESTED LOOPS | | 1 | 266 | | 6518 (2)| 00:01:19 | | 4 | NESTED LOOPS | | 1 | 221 | | 6517 (2)| 00:01:19 | | 5 | NESTED LOOPS| | 1 | 191 | | 6516 (2)| 00:01:19 | | 6 | NESTED LOOPS | | 1 | 171 | | 6515 (2)| 00:01:19 | | 7 |NESTED LOOPS OUTER| | 1 | 157 | | 6514 (2)| 00:01:19 | |* 8 | HASH JOIN OUTER | | 1 | 127 | | 6513 (2)| 00:01:19 | | 9 | NESTED LOOPS OUTER | | 1 | 114 | | 6371 (2)| 00:01:17 | |* 10 | HASH JOIN | | 1 |84 | | 6370 (2)| 00:01:17 | |* 11 |HASH JOIN || 22757 | 1200K| | 5391 (2)| 00:01:05 | |* 12 | TABLE ACCESS FULL| RECIBO_ENV | 22757 | 622K| | 1855 (3)| 00:00:23 | | 13 | VIEW | VW_SQ_2| 136K| 3458K| | 3535 (2)| 00:00:43 | | 14 | HASH GROUP BY || 136K| 1330K|18M| 3535 (2)| 00:00:43 | | 15 | TABLE ACCESS FULL | RECIBO_ENV_RETORNO | 953K| 9308K| | 1820 (1)| 00:00:22 | De: Diego Leite diegoleit...@gmail.com Para: oracle_br@yahoogrupos.com.br Enviadas: Sexta-feira, 19 de Julho de 2013 8:21 Assunto: Re: [oracle_br] Ajuste em consulta Amigo, Mostra o seu plano de execucao que fica mais facil de entendermos, mesmo tendo indice. explain plan for SELECT MAX(nu_seq_recibo) FROM SMS.recibo_env WHERE CO_ENV_RET = c.CO_ENV_RET; SELECT * FROM TABLE(dbms_xplan.display); Em 19 de julho de 2013 07:56, Jales Jose Moraes malphig...@yahoo.com.brescreveu: ** Sim, tem índice, inclusive são as chaves primárias das respectivas tabelas. Acredito que está acontecendo os gargalos são nas chamadas co-relacionadas na coluna c.CO_ENV_RET (que faz parte da consulta externa). Mas não estou sabendo estruturar a consulta de outra forma. De: Rodrigo Mufalani rodr...@mufalani.com.br Para: oracle_br@yahoogrupos.com.br Enviadas: Quinta-feira, 18 de Julho de 2013 17:05 Assunto: Re: [oracle_br] Ajuste em consulta Verifique se essas duas colunas tem índices.. Segue abaixo um pequeno teste. SQL create table teste as select * from dba_objects; Tabela criada. SQL @trcon SQL select max(created) from teste; Plano de Execuc?o -- Plan hash value: 2217472448 -- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -- | 0 | SELECT STATEMENT | |1 |9 | 358 (2)| 00:00:05 | | 1 | SORT AGGREGATE| |1 |9 || | | 2 | TABLE ACCESS FULL| TESTE | 101K| 892K| 358 (2)| 00:00:05 | -- Note - - dynamic sampling used for this statement (level=2) Estatisticas -- 7 recursive calls 0 db block gets 1385 consistent gets 1302 physical reads 0 redo size 363 bytes sent via SQL*Net to client 364 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed SQL create index ix_teste on teste(created); Indice criado. SQL select max(created) from teste; Plano de Execuc?o -- Plan hash value: 631728714 -- | Id | Operation
Re: [oracle_br] Ajuste em consulta
Meu caro, Além de plano de execução você deve analisar uma série de outras informações, taisl como : * Estatísticas * Parâmetros que modificam o comportamento do otimizador * Parâmetros que estão sendo setados em sua sessão (no aplicativo); * Seletividade (creio que por ser uma coluna de data não é o maior dos seus problemas); * Qualquer tipo de hint na consulta visto que você não a postou por inteiro; * Versão do seu banco de dados (patches/S.O); * Se essa consulta já funcionou em algum período e agora teve uma mudança de comportamento e etc; O Guob está chegando 10/08/2013, não deixe de se inscrever em www.guob.com.br Atenciosamente, Rodrigo Mufalani rodr...@mufalani.com.br www.mufalani.com.br On Fri, 19 Jul 2013 09:14:26 -0300, Diego Leite diegoleit...@gmail.com wrote: Este plano é referente as consultas que usou no primeiro email? Manda a consulta completa. Acho que mandou o plano da consulta completa e a consulta esta quebrada nao? SELECT MAX(nu_seq_recibo) FROM SMS.recibo_env WHERE CO_ENV_RET = c.CO_ENV_RET SELECT MAX(nu_seq_libera) FROM SMS.libera_recibo WHERE co_env_ret = c.CO_ENV_RET; Em 19 de julho de 2013 08:39, Jales Jose Moraes malphig...@yahoo.com.brescreveu: ** Diego gerei o plano, porém ele só vem a confirmar que não está usando o índice... | Id | Operation| Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | -- | 0 | SELECT STATEMENT | | 1 | 268 | | 6527 (2)| 00:01:19 | |* 1 | FILTER | | | | || | | 2 | NESTED LOOPS ANTI | | 1 | 268 | | 6522 (2)| 00:01:19 | | 3 |NESTED LOOPS | | 1 | 266 | | 6518 (2)| 00:01:19 | | 4 | NESTED LOOPS | | 1 | 221 | | 6517 (2)| 00:01:19 | | 5 | NESTED LOOPS| | 1 | 191 | | 6516 (2)| 00:01:19 | | 6 | NESTED LOOPS | | 1 | 171 | | 6515 (2)| 00:01:19 | | 7 |NESTED LOOPS OUTER| | 1 | 157 | | 6514 (2)| 00:01:19 | |* 8 | HASH JOIN OUTER | | 1 | 127 | | 6513 (2)| 00:01:19 | | 9 | NESTED LOOPS OUTER | | 1 | 114 | | 6371 (2)| 00:01:17 | |* 10 | HASH JOIN | | 1 |84 | | 6370 (2)| 00:01:17 | |* 11 |HASH JOIN || 22757 | 1200K| | 5391 (2)| 00:01:05 | |* 12 | TABLE ACCESS FULL| RECIBO_ENV | 22757 | 622K| | 1855 (3)| 00:00:23 | | 13 | VIEW | VW_SQ_2| 136K| 3458K| | 3535 (2)| 00:00:43 | | 14 | HASH GROUP BY || 136K| 1330K|18M| 3535 (2)| 00:00:43 | | 15 | TABLE ACCESS FULL | RECIBO_ENV_RETORNO | 953K| 9308K| | 1820 (1)| 00:00:22 | De: Diego Leite diegoleit...@gmail.com Para: oracle_br@yahoogrupos.com.br Enviadas: Sexta-feira, 19 de Julho de 2013 8:21 Assunto: Re: [oracle_br] Ajuste em consulta Amigo, Mostra o seu plano de execucao que fica mais facil de entendermos, mesmo tendo indice. explain plan for SELECT MAX(nu_seq_recibo) FROM SMS.recibo_env WHERE CO_ENV_RET = c.CO_ENV_RET; SELECT * FROM TABLE(dbms_xplan.display); Em 19 de julho de 2013 07:56, Jales Jose Moraes malphig...@yahoo.com.brescreveu: ** Sim, tem índice, inclusive são as chaves primárias das respectivas tabelas. Acredito que está acontecendo os gargalos são nas chamadas co-relacionadas na coluna c.CO_ENV_RET (que faz parte da consulta externa). Mas não estou sabendo estruturar a consulta de outra forma. De: Rodrigo Mufalani rodr...@mufalani.com.br Para: oracle_br@yahoogrupos.com.br Enviadas: Quinta-feira, 18 de Julho de 2013 17:05 Assunto: Re: [oracle_br] Ajuste em consulta Verifique se essas duas colunas tem índices.. Segue abaixo um pequeno teste. SQL create table teste as select * from dba_objects; Tabela criada. SQL @trcon SQL select max(created) from teste; Plano de Execuc?o -- Plan hash value: 2217472448 -- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -- | 0 | SELECT STATEMENT | |1 |9 | 358 (2)| 00:00:05 | | 1 | SORT AGGREGATE| |1 |9 || | | 2 | TABLE ACCESS FULL| TESTE | 101K| 892K
[oracle_br] Ajuste em consulta
Bom tarde! Pessoal estou com uma consulta onde está executando muito lentamente, ao analisar o plano, descobri que os dois selects internos à consulta (estão abaixo), são os responsáveis pelo gargalo SELECT MAX(nu_seq_recibo) FROM SMS.recibo_env WHERE CO_ENV_RET = c.CO_ENV_RET SELECT MAX(nu_seq_libera) FROM SMS.libera_recibo WHERE co_env_ret = c.CO_ENV_RET; Alguém tem alguma dica para me ajudar com a questão? [As partes desta mensagem que não continham texto foram removidas]
Re: [oracle_br] Ajuste em consulta
Estes campos nu_seq_recibo e nu_seq_libera estão indexados ? 2013/7/18 Jales Jose Moraes malphig...@yahoo.com.br ** Bom tarde! Pessoal estou com uma consulta onde está executando muito lentamente, ao analisar o plano, descobri que os dois selects internos à consulta (estão abaixo), são os responsáveis pelo gargalo SELECT MAX(nu_seq_recibo) FROM SMS.recibo_env WHERE CO_ENV_RET = c.CO_ENV_RET SELECT MAX(nu_seq_libera) FROM SMS.libera_recibo WHERE co_env_ret = c.CO_ENV_RET; Alguém tem alguma dica para me ajudar com a questão? [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas] -- Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -- Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: http://www.oraclebr.com.br/ 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: oracle_br-unsubscr...@yahoogrupos.com.br * O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
Re: [oracle_br] Ajuste em consulta
Verifique se essas duas colunas tem índices.. Segue abaixo um pequeno teste. SQL create table teste as select * from dba_objects; Tabela criada. SQL @trcon SQL select max(created) from teste; Plano de Execuc?o -- Plan hash value: 2217472448 | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | | 0 | SELECT STATEMENT | | 1 | 9 | 358 (2)| 00:00:05 | | 1 | SORT AGGREGATE| | 1 | 9 || | | 2 | TABLE ACCESS FULL| TESTE | 101K| 892K| 358 (2)| 00:00:05 | Note - - dynamic sampling used for this statement (level=2) Estatisticas -- 7 recursive calls 0 db block gets 1385 consistent gets 1302 physical reads 0 redo size 363 bytes sent via SQL*Net to client 364 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed SQL create index ix_teste on teste(created); Indice criado. SQL select max(created) from teste; Plano de Execuc?o -- Plan hash value: 631728714 --- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --- | 0 | SELECT STATEMENT | | 1 | 9 | 1 (0)| 00:00:01 | | 1 | SORT AGGREGATE| | 1 | 9 || | | 2 | INDEX FULL SCAN (MIN/MAX)| IX_TESTE | 1 | 9 | 1 (0)| 00:00:01 | --- Note - - dynamic sampling used for this statement (level=2) Estatisticas -- 5 recursive calls 0 db block gets 77 consistent gets 1 physical reads 0 redo size 363 bytes sent via SQL*Net to client 364 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed SQL É claro que tem muito mais em jogo do que isso, porém é um bom começo O Guob está chegando 10/08/2013, não deixe de se inscrever em www.guob.com.br Atenciosamente, Rodrigo Mufalani rodr...@mufalani.com.br www.mufalani.com.br On 18/07/2013, at 16:53, Jales Jose Moraes malphig...@yahoo.com.br wrote: Bom tarde! Pessoal estou com uma consulta onde está executando muito lentamente, ao analisar o plano, descobri que os dois selects internos à consulta (estão abaixo), são os responsáveis pelo gargalo SELECT MAX(nu_seq_recibo) FROM SMS.recibo_env WHERE CO_ENV_RET = c.CO_ENV_RET SELECT MAX(nu_seq_libera) FROM SMS.libera_recibo WHERE co_env_ret = c.CO_ENV_RET; Alguém tem alguma dica para me ajudar com a questão? [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas] -- Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -- Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: http://www.oraclebr.com.br/ 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: oracle_br-unsubscr...@yahoogrupos.com.br * O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
