RES: RES: RES: RES: RES: [oracle_br] Ajuda com Query Urgente
Chiappa, O multiblock eu fiz testes com alter session e não ajudou muito. Mas sua sugestão certamente foi válida e vou alterar para 16 o que normalmente aqui é o default. Com relação aos testes vou fazer sim. Mais uma vez obrigado pela ajuda e pela paciencia. Abraços, Nelson Cartaxo DBA ORACLE -Mensagem original- De: jlchiappa [mailto:[EMAIL PROTECTED] Enviada em: quarta-feira, 5 de abril de 2006 16:03 Para: oracle_br@yahoogrupos.com.br Assunto: Re: RES: RES: RES: RES: [oracle_br] Ajuda com Query Urgente Nelson, não deixe de tentar seguir o procedimento q citei em outra msg e testar/alterar os params de subquery/merge e subir o multiblock_read, veja se isso te ajuda, pelo jeito creio que sim... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo <[EMAIL PROTECTED]> escreveu > > Desculpe Marcio, realmente não me expliquei direito. Quis dizer que a query > funcionou e retornou o mesmo resultado quando eu coloco o hint de rule. O > tempo de resposta tambem ficou bom. Agora vou ver com a equipe de > desenvolvimento se esta query que a principio tem o mesmo efeito da > "Mardita" serve pra eles. > > Abraços, > > > Atenciosamente, > Nelson Cartaxo > DBA ORACLE > -Mensagem original- > De: Marcio Portes [mailto:[EMAIL PROTECTED] > Enviada em: quarta-feira, 5 de abril de 2006 14:32 > Para: oracle_br@yahoogrupos.com.br > Assunto: Re: RES: RES: RES: [oracle_br] Ajuda com Query Urgente > > > > A query teve o mesmo resultado? Isso significa o que? Funcionou? > Serviou? Ficou rápido? > > o over faz parte das analytics functions. Elas são basicamente > funções de agrupamento que voce pode usar sem o group by. > > No seu caso voce está fazendo full tablescan da mesma tabela 2 vezes > desnecessariamente. Basta um único full e voce tem a resposta. > > Procure por "analytic function" no manual. > > --- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo > <[EMAIL PROTECTED]> escreveu > > > > Marcio, > > > > Obrigado. A query teve o mesmo resultado. Vc poderia dar uma > explicação > > breve sobre esse "over" e partition que vc usou aqui? Meu forte > nunca foi > > tuning de query. > > > > Desde já agradeço a ajuda. > > > > > > Atenciosamente, > > Nelson Cartaxo > > DBA ORACLE > > > > > > -Mensagem original- > > De: Marcio Portes [mailto:[EMAIL PROTECTED] > > Enviada em: terça-feira, 4 de abril de 2006 21:56 > > Para: oracle_br@yahoogrupos.com.br > > Assunto: Re: RES: RES: [oracle_br] Ajuda com Query Urgente > > > > > > Voce poderia usar o hint /*+ no_merge */ ou o que eu prefiro > rescrever a > > query. > > > > select st_tarefa > > from ( > > select st_tarefa, max(dt_inicio) over (partition by co_tarefa order > by > > co_tarefa ) mx_dtini, > >dt_inicio > > from siops.tb_log_tarefa > > where co_tarefa = 10 > >) > > where mx_dtini = dt_inicio > > / > > > > > > On 4/4/06, Nelson Cartaxo <[EMAIL PROTECTED]> wrote: > > > > > > Mais uma duvida. O pq do "MALDITO" merge join. Isso que ta > quebrando a > > > query. Existe algum parametro que altere isso? Se uso o hint de > rule ele > > > vai bem. Veja > > > > > > PLAN_TABLE_OUTPUT > > > > > > > > -- -- > > > > > > > > > > -- > - > > > | Id | Operation| Name | Rows | Bytes | > Cost | > > > -- > - > > > | 0 | SELECT STATEMENT || | > | | > > > |* 1 | FILTER || | > | | > > > |* 2 | TABLE ACCESS FULL | TB_LOG_TAREFA | | > | | > > > | 3 | SORT AGGREGATE || | > | | > > > |* 4 |TABLE ACCESS FULL | TB_LOG_TAREFA | | > | | > > > -- > - > > > > > > Quando faz acesso full vai super rápido. > > > > > > Obrigado mais uma vez. > > > > > > > > > Atenciosamente, > > > Nelson Cartaxo > > > DBA ORACLE > > > -Mensagem original- > > > De: jlchiappa [mailto:[
Re: RES: RES: RES: RES: [oracle_br] Ajuda com Query Urgente
Nelson, não deixe de tentar seguir o procedimento q citei em outra msg e testar/alterar os params de subquery/merge e subir o multiblock_read, veja se isso te ajuda, pelo jeito creio que sim... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo <[EMAIL PROTECTED]> escreveu > > Desculpe Marcio, realmente não me expliquei direito. Quis dizer que a query > funcionou e retornou o mesmo resultado quando eu coloco o hint de rule. O > tempo de resposta tambem ficou bom. Agora vou ver com a equipe de > desenvolvimento se esta query que a principio tem o mesmo efeito da > "Mardita" serve pra eles. > > Abraços, > > > Atenciosamente, > Nelson Cartaxo > DBA ORACLE > -Mensagem original- > De: Marcio Portes [mailto:[EMAIL PROTECTED] > Enviada em: quarta-feira, 5 de abril de 2006 14:32 > Para: oracle_br@yahoogrupos.com.br > Assunto: Re: RES: RES: RES: [oracle_br] Ajuda com Query Urgente > > > > A query teve o mesmo resultado? Isso significa o que? Funcionou? > Serviou? Ficou rápido? > > o over faz parte das analytics functions. Elas são basicamente > funções de agrupamento que voce pode usar sem o group by. > > No seu caso voce está fazendo full tablescan da mesma tabela 2 vezes > desnecessariamente. Basta um único full e voce tem a resposta. > > Procure por "analytic function" no manual. > > --- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo > <[EMAIL PROTECTED]> escreveu > > > > Marcio, > > > > Obrigado. A query teve o mesmo resultado. Vc poderia dar uma > explicação > > breve sobre esse "over" e partition que vc usou aqui? Meu forte > nunca foi > > tuning de query. > > > > Desde já agradeço a ajuda. > > > > > > Atenciosamente, > > Nelson Cartaxo > > DBA ORACLE > > > > > > -Mensagem original- > > De: Marcio Portes [mailto:[EMAIL PROTECTED] > > Enviada em: terça-feira, 4 de abril de 2006 21:56 > > Para: oracle_br@yahoogrupos.com.br > > Assunto: Re: RES: RES: [oracle_br] Ajuda com Query Urgente > > > > > > Voce poderia usar o hint /*+ no_merge */ ou o que eu prefiro > rescrever a > > query. > > > > select st_tarefa > > from ( > > select st_tarefa, max(dt_inicio) over (partition by co_tarefa order > by > > co_tarefa ) mx_dtini, > >dt_inicio > > from siops.tb_log_tarefa > > where co_tarefa = 10 > >) > > where mx_dtini = dt_inicio > > / > > > > > > On 4/4/06, Nelson Cartaxo <[EMAIL PROTECTED]> wrote: > > > > > > Mais uma duvida. O pq do "MALDITO" merge join. Isso que ta > quebrando a > > > query. Existe algum parametro que altere isso? Se uso o hint de > rule ele > > > vai bem. Veja > > > > > > PLAN_TABLE_OUTPUT > > > > > > > > -- -- > > > > > > > > > > -- > - > > > | Id | Operation| Name | Rows | Bytes | > Cost | > > > -- > - > > > | 0 | SELECT STATEMENT || | > | | > > > |* 1 | FILTER || | > | | > > > |* 2 | TABLE ACCESS FULL | TB_LOG_TAREFA | | > | | > > > | 3 | SORT AGGREGATE || | > | | > > > |* 4 |TABLE ACCESS FULL | TB_LOG_TAREFA | | > | | > > > -- > - > > > > > > Quando faz acesso full vai super rápido. > > > > > > Obrigado mais uma vez. > > > > > > > > > Atenciosamente, > > > Nelson Cartaxo > > > DBA ORACLE > > > -Mensagem original- > > > De: jlchiappa [mailto:[EMAIL PROTECTED] > > > Enviada em: terça-feira, 4 de abril de 2006 15:57 > > > Para: oracle_br@yahoogrupos.com.br > > > Assunto: Re: RES: RES: [oracle_br] Ajuda com Query Urgente > > > > > > > > > Colega, PMFJI mas uma das mais importantes coisas quando se > analiza > > > um provável caso de full-scan "errado" é a número de linhas que > cada > > > passo do plano traz : isso já aparece direitonho na PLAN_TABLE da > > > versão 9i, mas o seu
RES: RES: RES: RES: [oracle_br] Ajuda com Query Urgente
Desculpe Marcio, realmente não me expliquei direito. Quis dizer que a query
funcionou e retornou o mesmo resultado quando eu coloco o hint de rule. O
tempo de resposta tambem ficou bom. Agora vou ver com a equipe de
desenvolvimento se esta query que a principio tem o mesmo efeito da
"Mardita" serve pra eles.
Abraços,
Atenciosamente,
Nelson Cartaxo
DBA ORACLE
-Mensagem original-
De: Marcio Portes [mailto:[EMAIL PROTECTED]
Enviada em: quarta-feira, 5 de abril de 2006 14:32
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: RES: RES: [oracle_br] Ajuda com Query Urgente
A query teve o mesmo resultado? Isso significa o que? Funcionou?
Serviou? Ficou rápido?
o over faz parte das analytics functions. Elas são basicamente
funções de agrupamento que voce pode usar sem o group by.
No seu caso voce está fazendo full tablescan da mesma tabela 2 vezes
desnecessariamente. Basta um único full e voce tem a resposta.
Procure por "analytic function" no manual.
--- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo
<[EMAIL PROTECTED]> escreveu
>
> Marcio,
>
> Obrigado. A query teve o mesmo resultado. Vc poderia dar uma
explicação
> breve sobre esse "over" e partition que vc usou aqui? Meu forte
nunca foi
> tuning de query.
>
> Desde já agradeço a ajuda.
>
>
> Atenciosamente,
> Nelson Cartaxo
> DBA ORACLE
>
>
> -Mensagem original-
> De: Marcio Portes [mailto:[EMAIL PROTECTED]
> Enviada em: terça-feira, 4 de abril de 2006 21:56
> Para: oracle_br@yahoogrupos.com.br
> Assunto: Re: RES: RES: [oracle_br] Ajuda com Query Urgente
>
>
> Voce poderia usar o hint /*+ no_merge */ ou o que eu prefiro
rescrever a
> query.
>
> select st_tarefa
> from (
> select st_tarefa, max(dt_inicio) over (partition by co_tarefa order
by
> co_tarefa ) mx_dtini,
>dt_inicio
> from siops.tb_log_tarefa
> where co_tarefa = 10
>)
> where mx_dtini = dt_inicio
> /
>
>
> On 4/4/06, Nelson Cartaxo <[EMAIL PROTECTED]> wrote:
> >
> > Mais uma duvida. O pq do "MALDITO" merge join. Isso que ta
quebrando a
> > query. Existe algum parametro que altere isso? Se uso o hint de
rule ele
> > vai bem. Veja
> >
> > PLAN_TABLE_OUTPUT
> >
> >
>
> >
> >
> > --
-
> > | Id | Operation| Name | Rows | Bytes |
Cost |
> > --
-
> > | 0 | SELECT STATEMENT || |
| |
> > |* 1 | FILTER || |
| |
> > |* 2 | TABLE ACCESS FULL | TB_LOG_TAREFA | |
| |
> > | 3 | SORT AGGREGATE || |
| |
> > |* 4 |TABLE ACCESS FULL | TB_LOG_TAREFA | |
| |
> > --
-
> >
> > Quando faz acesso full vai super rápido.
> >
> > Obrigado mais uma vez.
> >
> >
> > Atenciosamente,
> > Nelson Cartaxo
> > DBA ORACLE
> > -Mensagem original-
> > De: jlchiappa [mailto:[EMAIL PROTECTED]
> > Enviada em: terça-feira, 4 de abril de 2006 15:57
> > Para: oracle_br@yahoogrupos.com.br
> > Assunto: Re: RES: RES: [oracle_br] Ajuda com Query Urgente
> >
> >
> > Colega, PMFJI mas uma das mais importantes coisas quando se
analiza
> > um provável caso de full-scan "errado" é a número de linhas que
cada
> > passo do plano traz : isso já aparece direitonho na PLAN_TABLE da
> > versão 9i, mas o seu script de consulta à PLAN_TABLE pelo jeito
não o
> > está mostrando (que pelo famigerado lpad deduzo ser uma versão
> > ANTIGA, dessas copiadas pelos sites/livros de Oracle) : sugiro
que vc
> > APOSENTE esse morto-vivo aí, e passe a usar o seguinte no 9i :
> >
> > [EMAIL PROTECTED]:SQL>get explain
> > 1 select distinct statement_id from plan_table;
> > 2 accept V_STATEMENT_ID prompt 'Statement a Explicar
(respeitando
> > maiúsculas/minusc.) :'
> > 3* select * from table(dbms_xplan.display
> > ('PLAN_TABLE', '&V_STATEMENT_ID', 'ALL'));
> > [EMAIL PROTECTED]:SQL>
> >
> > e tenha no 9i o parâmetro statistics_level ao menos como TYPICAL,
> > olha só como é mais completinho o report assim :
> >
> > [EMAIL PROTECTED]:SQL>ed
> > Gravou arquivo afiedt.buf
> >
> > 1 e
Re: RES: RES: RES: [oracle_br] Ajuda com Query Urgente
A query teve o mesmo resultado? Isso significa o que? Funcionou?
Serviou? Ficou rápido?
o over faz parte das analytics functions. Elas são basicamente
funções de agrupamento que voce pode usar sem o group by.
No seu caso voce está fazendo full tablescan da mesma tabela 2 vezes
desnecessariamente. Basta um único full e voce tem a resposta.
Procure por "analytic function" no manual.
--- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo
<[EMAIL PROTECTED]> escreveu
>
> Marcio,
>
> Obrigado. A query teve o mesmo resultado. Vc poderia dar uma
explicação
> breve sobre esse "over" e partition que vc usou aqui? Meu forte
nunca foi
> tuning de query.
>
> Desde já agradeço a ajuda.
>
>
> Atenciosamente,
> Nelson Cartaxo
> DBA ORACLE
>
>
> -Mensagem original-
> De: Marcio Portes [mailto:[EMAIL PROTECTED]
> Enviada em: terça-feira, 4 de abril de 2006 21:56
> Para: oracle_br@yahoogrupos.com.br
> Assunto: Re: RES: RES: [oracle_br] Ajuda com Query Urgente
>
>
> Voce poderia usar o hint /*+ no_merge */ ou o que eu prefiro
rescrever a
> query.
>
> select st_tarefa
> from (
> select st_tarefa, max(dt_inicio) over (partition by co_tarefa order
by
> co_tarefa ) mx_dtini,
>dt_inicio
> from siops.tb_log_tarefa
> where co_tarefa = 10
>)
> where mx_dtini = dt_inicio
> /
>
>
> On 4/4/06, Nelson Cartaxo <[EMAIL PROTECTED]> wrote:
> >
> > Mais uma duvida. O pq do "MALDITO" merge join. Isso que ta
quebrando a
> > query. Existe algum parametro que altere isso? Se uso o hint de
rule ele
> > vai bem. Veja
> >
> > PLAN_TABLE_OUTPUT
> >
> >
>
> >
> >
> > --
-
> > | Id | Operation| Name | Rows | Bytes |
Cost |
> > --
-
> > | 0 | SELECT STATEMENT || |
| |
> > |* 1 | FILTER || |
| |
> > |* 2 | TABLE ACCESS FULL | TB_LOG_TAREFA | |
| |
> > | 3 | SORT AGGREGATE || |
| |
> > |* 4 |TABLE ACCESS FULL | TB_LOG_TAREFA | |
| |
> > --
-
> >
> > Quando faz acesso full vai super rápido.
> >
> > Obrigado mais uma vez.
> >
> >
> > Atenciosamente,
> > Nelson Cartaxo
> > DBA ORACLE
> > -Mensagem original-
> > De: jlchiappa [mailto:[EMAIL PROTECTED]
> > Enviada em: terça-feira, 4 de abril de 2006 15:57
> > Para: oracle_br@yahoogrupos.com.br
> > Assunto: Re: RES: RES: [oracle_br] Ajuda com Query Urgente
> >
> >
> > Colega, PMFJI mas uma das mais importantes coisas quando se
analiza
> > um provável caso de full-scan "errado" é a número de linhas que
cada
> > passo do plano traz : isso já aparece direitonho na PLAN_TABLE da
> > versão 9i, mas o seu script de consulta à PLAN_TABLE pelo jeito
não o
> > está mostrando (que pelo famigerado lpad deduzo ser uma versão
> > ANTIGA, dessas copiadas pelos sites/livros de Oracle) : sugiro
que vc
> > APOSENTE esse morto-vivo aí, e passe a usar o seguinte no 9i :
> >
> > [EMAIL PROTECTED]:SQL>get explain
> > 1 select distinct statement_id from plan_table;
> > 2 accept V_STATEMENT_ID prompt 'Statement a Explicar
(respeitando
> > maiúsculas/minusc.) :'
> > 3* select * from table(dbms_xplan.display
> > ('PLAN_TABLE', '&V_STATEMENT_ID', 'ALL'));
> > [EMAIL PROTECTED]:SQL>
> >
> > e tenha no 9i o parâmetro statistics_level ao menos como TYPICAL,
> > olha só como é mais completinho o report assim :
> >
> > [EMAIL PROTECTED]:SQL>ed
> > Gravou arquivo afiedt.buf
> >
> > 1 explain plan set statement_id='P1' for
> > 2 select *
> > 3from (select e.empno, d.dname
> > 4from emp e ,dept d
> > 5 where e.deptno=d.deptno
> > 6 and sal > 1000
> > 7 order by sal desc
> > 8 )
> > 9* where rownum < 10
> > [EMAIL PROTECTED]:SQL>/
> >
> > Explicado.
> >
> > [EMAIL PROTECTED]:SQL>@explain
> >
> > STATEMENT_ID
> > --
> > P1
> >
> > Statement a Explicar (respeitando maiúsculas/minusc.) :P1
> > antigo 1: select * from table(dbms_xplan.display
> > ('PLAN_TABLE', '&V_STATEMENT_ID', 'ALL'))
> > novo 1: select * from table(dbms_xplan.display
> > ('PLAN_TABLE', 'P1', 'ALL'))
> >
> > PLAN_TABLE_OUTPUT
> > -
> >
> > --
> > --
> > |Id |Operation | Name |Rows
|Bytes|Cost
> > (%CPU)|
> > --
> > --
> > | 0 |SELECT STATEMENT | |9| 198|
> > 21 (5)|
> > |*1 | COUNT STOPKEY | | |
> > | |
> > | 2
Re: RES: RES: RES: RES: [oracle_br] Ajuda com Query Urgente
E os params _ de merge e subquery mostrados nas notas metalink da
mesma msg, vc os testou ? Esse multiblock_read de 8, não está muito
pequeno, aumente-o para 16.
Se tudo feito e não adiantou, como tínhamos pedido em outra msg,
diga exatamenete como vc está coletando as stats (ie, se analyze, se
dbms_stats), mostrando o comando inteiro pra que possamos ver a
sintaxe, como estão sendo criados os histogramas (comando completo
também), e já que é uma tabela só manda o script de CREATE dela e um
script que via LOOP insira uns tantos mils registros nela, mas com
uma distribuição de dados parecida com a sua real (ie, a sua tabela
tem cento e poucos mils, mas se com a condição de co_tarefa = 10 só
X% das linhas volta, que isso se reflita no script, aí podemos fazer
uns testes por aqui também.
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo
<[EMAIL PROTECTED]> escreveu
>
> Oi chiappa,
>
> Eu alterei ontem mesmo, mas esqueci de colocar no email. Alterei o
> optimizer_index_caching para 90 e optimizer_index_cost_adj para
20. Mas
> como esta tabela não tem indice algum, não teve qualquer alteração.
>
>
> Atenciosamente,
> Nelson Cartaxo
> DBA ORACLE
> GABD - Ger. Adm. de Banco de Dados
> DATASUS/RJ (MS)
> Tel: 3985-7090
>
> -Mensagem original-
> De: jlchiappa [mailto:[EMAIL PROTECTED]
> Enviada em: quarta-feira, 5 de abril de 2006 10:42
> Para: oracle_br@yahoogrupos.com.br
> Assunto: Re: RES: RES: RES: [oracle_br] Ajuda com Query Urgente
>
>
> Colega, eu ainda acho, depois de dar uma olhada nos planos, que a
> diferença do 9i pro outro está MESMO sendo os parãmetros de
> optimizer_nn que vc deixou no default, novamente vou recomendar que
> vc os altere, usando os textos que passei em outra msg como
> referência, NEM que seja só via ALTER SESSION pra ver se é isso. Na
> mesma msg eu citei os parâmetros de subquery e de merge que foram
> alterados no 9i e passei as notas metalink que os documentam, não
> parece ser o caso mas teste-os também.
>
> []s
>
> Chiappa
> --- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo
> <[EMAIL PROTECTED]> escreveu
> >
> > Mais uma duvida. O pq do "MALDITO" merge join. Isso que ta
> quebrando a
> > query. Existe algum parametro que altere isso? Se uso o hint de
> rule ele
> > vai bem. Veja
> >
> > PLAN_TABLE_OUTPUT
> > --
--
>
> >
> >
> > --
--
> ---
> > | Id | Operation| Name | Rows | Bytes |
> Cost |
> > --
--
> ---
> > | 0 | SELECT STATEMENT || |
> | |
> > |* 1 | FILTER || |
> | |
> > |* 2 | TABLE ACCESS FULL | TB_LOG_TAREFA | |
> | |
> > | 3 | SORT AGGREGATE || |
> | |
> > |* 4 |TABLE ACCESS FULL | TB_LOG_TAREFA | |
> | |
> > --
--
> ---
> >
> > Quando faz acesso full vai super rápido.
> >
> > Obrigado mais uma vez.
> >
> >
> > Atenciosamente,
> > Nelson Cartaxo
> > DBA ORACLE
> > -Mensagem original-
> > De: jlchiappa [mailto:[EMAIL PROTECTED]
> > Enviada em: terça-feira, 4 de abril de 2006 15:57
> > Para: oracle_br@yahoogrupos.com.br
> > Assunto: Re: RES: RES: [oracle_br] Ajuda com Query Urgente
> >
> >
> > Colega, PMFJI mas uma das mais importantes coisas quando se
analiza
> > um provável caso de full-scan "errado" é a número de linhas que
> cada
> > passo do plano traz : isso já aparece direitonho na PLAN_TABLE da
> > versão 9i, mas o seu script de consulta à PLAN_TABLE pelo jeito
não
> o
> > está mostrando (que pelo famigerado lpad deduzo ser uma versão
> > ANTIGA, dessas copiadas pelos sites/livros de Oracle) : sugiro
que
> vc
> > APOSENTE esse morto-vivo aí, e passe a usar o seguinte no 9i :
> >
> > [EMAIL PROTECTED]:SQL>get explain
> > 1 select distinct statement_id from plan_table;
> > 2 accept V_STATEMENT_ID prompt 'Statement a Explicar
> (respeitando
> > maiúsculas/minusc.) :'
> > 3* select * from table(dbms_xplan.display
> > ('PLAN_TABLE', '&V_STATEMENT_ID', 'ALL'));
> > [EMAIL PROTECTED]:SQL>
> >
> > e tenha no 9i o parâmetro s
RES: RES: RES: RES: [oracle_br] Ajuda com Query Urgente
Oi chiappa,
Eu alterei ontem mesmo, mas esqueci de colocar no email. Alterei o
optimizer_index_caching para 90 e optimizer_index_cost_adj para 20. Mas
como esta tabela não tem indice algum, não teve qualquer alteração.
Atenciosamente,
Nelson Cartaxo
DBA ORACLE
GABD - Ger. Adm. de Banco de Dados
DATASUS/RJ (MS)
Tel: 3985-7090
-Mensagem original-
De: jlchiappa [mailto:[EMAIL PROTECTED]
Enviada em: quarta-feira, 5 de abril de 2006 10:42
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: RES: RES: [oracle_br] Ajuda com Query Urgente
Colega, eu ainda acho, depois de dar uma olhada nos planos, que a
diferença do 9i pro outro está MESMO sendo os parãmetros de
optimizer_nn que vc deixou no default, novamente vou recomendar que
vc os altere, usando os textos que passei em outra msg como
referência, NEM que seja só via ALTER SESSION pra ver se é isso. Na
mesma msg eu citei os parâmetros de subquery e de merge que foram
alterados no 9i e passei as notas metalink que os documentam, não
parece ser o caso mas teste-os também.
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo
<[EMAIL PROTECTED]> escreveu
>
> Mais uma duvida. O pq do "MALDITO" merge join. Isso que ta
quebrando a
> query. Existe algum parametro que altere isso? Se uso o hint de
rule ele
> vai bem. Veja
>
> PLAN_TABLE_OUTPUT
>
>
>
>
---
> | Id | Operation| Name | Rows | Bytes |
Cost |
>
---
> | 0 | SELECT STATEMENT || |
| |
> |* 1 | FILTER || |
| |
> |* 2 | TABLE ACCESS FULL | TB_LOG_TAREFA | |
| |
> | 3 | SORT AGGREGATE || |
| |
> |* 4 |TABLE ACCESS FULL | TB_LOG_TAREFA | |
| |
>
---
>
> Quando faz acesso full vai super rápido.
>
> Obrigado mais uma vez.
>
>
> Atenciosamente,
> Nelson Cartaxo
> DBA ORACLE
> -Mensagem original-
> De: jlchiappa [mailto:[EMAIL PROTECTED]
> Enviada em: terça-feira, 4 de abril de 2006 15:57
> Para: oracle_br@yahoogrupos.com.br
> Assunto: Re: RES: RES: [oracle_br] Ajuda com Query Urgente
>
>
> Colega, PMFJI mas uma das mais importantes coisas quando se analiza
> um provável caso de full-scan "errado" é a número de linhas que
cada
> passo do plano traz : isso já aparece direitonho na PLAN_TABLE da
> versão 9i, mas o seu script de consulta à PLAN_TABLE pelo jeito não
o
> está mostrando (que pelo famigerado lpad deduzo ser uma versão
> ANTIGA, dessas copiadas pelos sites/livros de Oracle) : sugiro que
vc
> APOSENTE esse morto-vivo aí, e passe a usar o seguinte no 9i :
>
> [EMAIL PROTECTED]:SQL>get explain
> 1 select distinct statement_id from plan_table;
> 2 accept V_STATEMENT_ID prompt 'Statement a Explicar
(respeitando
> maiúsculas/minusc.) :'
> 3* select * from table(dbms_xplan.display
> ('PLAN_TABLE', '&V_STATEMENT_ID', 'ALL'));
> [EMAIL PROTECTED]:SQL>
>
> e tenha no 9i o parâmetro statistics_level ao menos como TYPICAL,
> olha só como é mais completinho o report assim :
>
> [EMAIL PROTECTED]:SQL>ed
> Gravou arquivo afiedt.buf
>
> 1 explain plan set statement_id='P1' for
> 2 select *
> 3from (select e.empno, d.dname
> 4from emp e ,dept d
> 5 where e.deptno=d.deptno
> 6 and sal > 1000
> 7 order by sal desc
> 8 )
> 9* where rownum < 10
> [EMAIL PROTECTED]:SQL>/
>
> Explicado.
>
> [EMAIL PROTECTED]:SQL>@explain
>
> STATEMENT_ID
> --
> P1
>
> Statement a Explicar (respeitando maiúsculas/minusc.) :P1
> antigo 1: select * from table(dbms_xplan.display
> ('PLAN_TABLE', '&V_STATEMENT_ID', 'ALL'))
> novo 1: select * from table(dbms_xplan.display
> ('PLAN_TABLE', 'P1', 'ALL'))
>
> PLAN_TABLE_OUTPUT
> -
>
>
--
> --
> |Id |Operation | Name |Rows
|Bytes|Cost
> (%CPU)|
>
--
> --
> | 0 |SELECT STATEMENT | |9| 198|
> 21 (5)|
> |*1 | COUNT STOPKEY
Re: RES: RES: RES: [oracle_br] Ajuda com Query Urgente
Colega, eu ainda acho, depois de dar uma olhada nos planos, que a
diferença do 9i pro outro está MESMO sendo os parãmetros de
optimizer_nn que vc deixou no default, novamente vou recomendar que
vc os altere, usando os textos que passei em outra msg como
referência, NEM que seja só via ALTER SESSION pra ver se é isso. Na
mesma msg eu citei os parâmetros de subquery e de merge que foram
alterados no 9i e passei as notas metalink que os documentam, não
parece ser o caso mas teste-os também.
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo
<[EMAIL PROTECTED]> escreveu
>
> Mais uma duvida. O pq do "MALDITO" merge join. Isso que ta
quebrando a
> query. Existe algum parametro que altere isso? Se uso o hint de
rule ele
> vai bem. Veja
>
> PLAN_TABLE_OUTPUT
>
>
>
>
---
> | Id | Operation| Name | Rows | Bytes |
Cost |
>
---
> | 0 | SELECT STATEMENT || |
| |
> |* 1 | FILTER || |
| |
> |* 2 | TABLE ACCESS FULL | TB_LOG_TAREFA | |
| |
> | 3 | SORT AGGREGATE || |
| |
> |* 4 |TABLE ACCESS FULL | TB_LOG_TAREFA | |
| |
>
---
>
> Quando faz acesso full vai super rápido.
>
> Obrigado mais uma vez.
>
>
> Atenciosamente,
> Nelson Cartaxo
> DBA ORACLE
> -Mensagem original-
> De: jlchiappa [mailto:[EMAIL PROTECTED]
> Enviada em: terça-feira, 4 de abril de 2006 15:57
> Para: oracle_br@yahoogrupos.com.br
> Assunto: Re: RES: RES: [oracle_br] Ajuda com Query Urgente
>
>
> Colega, PMFJI mas uma das mais importantes coisas quando se analiza
> um provável caso de full-scan "errado" é a número de linhas que
cada
> passo do plano traz : isso já aparece direitonho na PLAN_TABLE da
> versão 9i, mas o seu script de consulta à PLAN_TABLE pelo jeito não
o
> está mostrando (que pelo famigerado lpad deduzo ser uma versão
> ANTIGA, dessas copiadas pelos sites/livros de Oracle) : sugiro que
vc
> APOSENTE esse morto-vivo aí, e passe a usar o seguinte no 9i :
>
> [EMAIL PROTECTED]:SQL>get explain
> 1 select distinct statement_id from plan_table;
> 2 accept V_STATEMENT_ID prompt 'Statement a Explicar
(respeitando
> maiúsculas/minusc.) :'
> 3* select * from table(dbms_xplan.display
> ('PLAN_TABLE', '&V_STATEMENT_ID', 'ALL'));
> [EMAIL PROTECTED]:SQL>
>
> e tenha no 9i o parâmetro statistics_level ao menos como TYPICAL,
> olha só como é mais completinho o report assim :
>
> [EMAIL PROTECTED]:SQL>ed
> Gravou arquivo afiedt.buf
>
> 1 explain plan set statement_id='P1' for
> 2 select *
> 3from (select e.empno, d.dname
> 4from emp e ,dept d
> 5 where e.deptno=d.deptno
> 6 and sal > 1000
> 7 order by sal desc
> 8 )
> 9* where rownum < 10
> [EMAIL PROTECTED]:SQL>/
>
> Explicado.
>
> [EMAIL PROTECTED]:SQL>@explain
>
> STATEMENT_ID
> --
> P1
>
> Statement a Explicar (respeitando maiúsculas/minusc.) :P1
> antigo 1: select * from table(dbms_xplan.display
> ('PLAN_TABLE', '&V_STATEMENT_ID', 'ALL'))
> novo 1: select * from table(dbms_xplan.display
> ('PLAN_TABLE', 'P1', 'ALL'))
>
> PLAN_TABLE_OUTPUT
> -
>
>
--
> --
> |Id |Operation | Name |Rows
|Bytes|Cost
> (%CPU)|
>
--
> --
> | 0 |SELECT STATEMENT | |9| 198|
> 21 (5)|
> |*1 | COUNT STOPKEY | | |
> | |
> | 2 | VIEW | | 13|
> 286| |
> |*3 | SORT ORDER BY STOPKEY | | 13| 247|
> 21 (5)|
> |*4 |TABLE ACCESS BY INDEX ROWID| EMP |2| 16|
> 2 (50)|
> | 5 | NESTED LOOPS | | 13| 247|
> 9 (12)|
> | 6 | TABLE ACCESS FULL| DEPT |6| 66|
> 2 (0)|
> |*7 | INDEX RANGE SCAN | IDX_DEPTNO_JOB|5| |
> 1 (0)|
>
--
> --
>
> Predicate Information (identified by operation id):
> ---
>
>1 - filter(ROWNUM<10)
>3 - filter(ROWNUM<10)
>4 - filter("E"."SAL">1000)
>7 - access("E"."DEPTNO"="D"."DEPTNO")
>
> 21 linhas selecionadas.
>
> [EMAIL PROTECTED]:SQL>
>
> ==< taí ó, mostrando direitinho que operação cada passo está
fazendo,
RES: RES: RES: [oracle_br] Ajuda com Query Urgente
Marcio,
Obrigado. A query teve o mesmo resultado. Vc poderia dar uma explicação
breve sobre esse "over" e partition que vc usou aqui? Meu forte nunca foi
tuning de query.
Desde já agradeço a ajuda.
Atenciosamente,
Nelson Cartaxo
DBA ORACLE
-Mensagem original-
De: Marcio Portes [mailto:[EMAIL PROTECTED]
Enviada em: terça-feira, 4 de abril de 2006 21:56
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: RES: [oracle_br] Ajuda com Query Urgente
Voce poderia usar o hint /*+ no_merge */ ou o que eu prefiro rescrever a
query.
select st_tarefa
from (
select st_tarefa, max(dt_inicio) over (partition by co_tarefa order by
co_tarefa ) mx_dtini,
dt_inicio
from siops.tb_log_tarefa
where co_tarefa = 10
)
where mx_dtini = dt_inicio
/
On 4/4/06, Nelson Cartaxo <[EMAIL PROTECTED]> wrote:
>
> Mais uma duvida. O pq do "MALDITO" merge join. Isso que ta quebrando a
> query. Existe algum parametro que altere isso? Se uso o hint de rule ele
> vai bem. Veja
>
> PLAN_TABLE_OUTPUT
>
>
>
>
> ---
> | Id | Operation| Name | Rows | Bytes | Cost |
> ---
> | 0 | SELECT STATEMENT || | | |
> |* 1 | FILTER || | | |
> |* 2 | TABLE ACCESS FULL | TB_LOG_TAREFA | | | |
> | 3 | SORT AGGREGATE || | | |
> |* 4 |TABLE ACCESS FULL | TB_LOG_TAREFA | | | |
> ---
>
> Quando faz acesso full vai super rápido.
>
> Obrigado mais uma vez.
>
>
> Atenciosamente,
> Nelson Cartaxo
> DBA ORACLE
> -Mensagem original-
> De: jlchiappa [mailto:[EMAIL PROTECTED]
> Enviada em: terça-feira, 4 de abril de 2006 15:57
> Para: oracle_br@yahoogrupos.com.br
> Assunto: Re: RES: RES: [oracle_br] Ajuda com Query Urgente
>
>
> Colega, PMFJI mas uma das mais importantes coisas quando se analiza
> um provável caso de full-scan "errado" é a número de linhas que cada
> passo do plano traz : isso já aparece direitonho na PLAN_TABLE da
> versão 9i, mas o seu script de consulta à PLAN_TABLE pelo jeito não o
> está mostrando (que pelo famigerado lpad deduzo ser uma versão
> ANTIGA, dessas copiadas pelos sites/livros de Oracle) : sugiro que vc
> APOSENTE esse morto-vivo aí, e passe a usar o seguinte no 9i :
>
> [EMAIL PROTECTED]:SQL>get explain
> 1 select distinct statement_id from plan_table;
> 2 accept V_STATEMENT_ID prompt 'Statement a Explicar (respeitando
> maiúsculas/minusc.) :'
> 3* select * from table(dbms_xplan.display
> ('PLAN_TABLE', '&V_STATEMENT_ID', 'ALL'));
> [EMAIL PROTECTED]:SQL>
>
> e tenha no 9i o parâmetro statistics_level ao menos como TYPICAL,
> olha só como é mais completinho o report assim :
>
> [EMAIL PROTECTED]:SQL>ed
> Gravou arquivo afiedt.buf
>
> 1 explain plan set statement_id='P1' for
> 2 select *
> 3from (select e.empno, d.dname
> 4from emp e ,dept d
> 5 where e.deptno=d.deptno
> 6 and sal > 1000
> 7 order by sal desc
> 8 )
> 9* where rownum < 10
> [EMAIL PROTECTED]:SQL>/
>
> Explicado.
>
> [EMAIL PROTECTED]:SQL>@explain
>
> STATEMENT_ID
> --
> P1
>
> Statement a Explicar (respeitando maiúsculas/minusc.) :P1
> antigo 1: select * from table(dbms_xplan.display
> ('PLAN_TABLE', '&V_STATEMENT_ID', 'ALL'))
> novo 1: select * from table(dbms_xplan.display
> ('PLAN_TABLE', 'P1', 'ALL'))
>
> PLAN_TABLE_OUTPUT
> -
>
> --
> --
> |Id |Operation | Name |Rows |Bytes|Cost
> (%CPU)|
> --
> --
> | 0 |SELECT STATEMENT | |9| 198|
> 21 (5)|
> |*1 | COUNT STOPKEY | | |
> | |
> | 2 | VIEW | | 13|
> 286| |
> |*3 | SORT ORDER BY STOPKEY | | 13| 247|
> 21 (5)|
> |*4 |TABLE ACCESS BY INDEX ROWID| EMP |2| 16|
> 2 (50)|
> | 5 | NESTED LOOPS | | 13| 247|
> 9 (12)|
> | 6 | TABLE ACCESS FULL| DEPT |6| 66|
> 2 (0)|
> |*7 | INDEX RANGE SCAN | IDX_DEPTNO_JOB|5| |
> 1 (0)|
> --
> --
>
> Predicate Information (identified by operation id):
> ---
>
>1 - filter(ROWNUM<10)
>3 - filter(ROWNUM<10)
>4 - filter("E"."SAL">1000)
>7 - access("
RES: RES: RES: [oracle_br] Ajuda com Query Urgente
Mais uma duvida. O pq do "MALDITO" merge join. Isso que ta quebrando a
query. Existe algum parametro que altere isso? Se uso o hint de rule ele
vai bem. Veja
PLAN_TABLE_OUTPUT
---
| Id | Operation| Name | Rows | Bytes | Cost |
---
| 0 | SELECT STATEMENT || | | |
|* 1 | FILTER || | | |
|* 2 | TABLE ACCESS FULL | TB_LOG_TAREFA | | | |
| 3 | SORT AGGREGATE || | | |
|* 4 |TABLE ACCESS FULL | TB_LOG_TAREFA | | | |
---
Quando faz acesso full vai super rápido.
Obrigado mais uma vez.
Atenciosamente,
Nelson Cartaxo
DBA ORACLE
-Mensagem original-
De: jlchiappa [mailto:[EMAIL PROTECTED]
Enviada em: terça-feira, 4 de abril de 2006 15:57
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: RES: [oracle_br] Ajuda com Query Urgente
Colega, PMFJI mas uma das mais importantes coisas quando se analiza
um provável caso de full-scan "errado" é a número de linhas que cada
passo do plano traz : isso já aparece direitonho na PLAN_TABLE da
versão 9i, mas o seu script de consulta à PLAN_TABLE pelo jeito não o
está mostrando (que pelo famigerado lpad deduzo ser uma versão
ANTIGA, dessas copiadas pelos sites/livros de Oracle) : sugiro que vc
APOSENTE esse morto-vivo aí, e passe a usar o seguinte no 9i :
[EMAIL PROTECTED]:SQL>get explain
1 select distinct statement_id from plan_table;
2 accept V_STATEMENT_ID prompt 'Statement a Explicar (respeitando
maiúsculas/minusc.) :'
3* select * from table(dbms_xplan.display
('PLAN_TABLE', '&V_STATEMENT_ID', 'ALL'));
[EMAIL PROTECTED]:SQL>
e tenha no 9i o parâmetro statistics_level ao menos como TYPICAL,
olha só como é mais completinho o report assim :
[EMAIL PROTECTED]:SQL>ed
Gravou arquivo afiedt.buf
1 explain plan set statement_id='P1' for
2 select *
3from (select e.empno, d.dname
4from emp e ,dept d
5 where e.deptno=d.deptno
6 and sal > 1000
7 order by sal desc
8 )
9* where rownum < 10
[EMAIL PROTECTED]:SQL>/
Explicado.
[EMAIL PROTECTED]:SQL>@explain
STATEMENT_ID
--
P1
Statement a Explicar (respeitando maiúsculas/minusc.) :P1
antigo 1: select * from table(dbms_xplan.display
('PLAN_TABLE', '&V_STATEMENT_ID', 'ALL'))
novo 1: select * from table(dbms_xplan.display
('PLAN_TABLE', 'P1', 'ALL'))
PLAN_TABLE_OUTPUT
-
--
--
|Id |Operation | Name |Rows |Bytes|Cost
(%CPU)|
--
--
| 0 |SELECT STATEMENT | |9| 198|
21 (5)|
|*1 | COUNT STOPKEY | | |
| |
| 2 | VIEW | | 13|
286| |
|*3 | SORT ORDER BY STOPKEY | | 13| 247|
21 (5)|
|*4 |TABLE ACCESS BY INDEX ROWID| EMP |2| 16|
2 (50)|
| 5 | NESTED LOOPS | | 13| 247|
9 (12)|
| 6 | TABLE ACCESS FULL| DEPT |6| 66|
2 (0)|
|*7 | INDEX RANGE SCAN | IDX_DEPTNO_JOB|5| |
1 (0)|
--
--
Predicate Information (identified by operation id):
---
1 - filter(ROWNUM<10)
3 - filter(ROWNUM<10)
4 - filter("E"."SAL">1000)
7 - access("E"."DEPTNO"="D"."DEPTNO")
21 linhas selecionadas.
[EMAIL PROTECTED]:SQL>
==< taí ó, mostrando direitinho que operação cada passo está fazendo,
quem está sendo filtrado, as LINHAS e os BYTES envolvidos em cada
passo, muito mais completo - a tua query extrai o custo da
PLAN_TABLE, legal, mas e o resto ?
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo
<[EMAIL PROTECTED]> escreveu
>
> Marcio, talvez eu possa tentar com a equipe de desenvolvimento que
mudem a
> query, desde que tenha os mesmos resultados.Se vc tiver alguma dica
> agradeço.
>
> Segue os planos de desenvolmimento (9.2.0.7) e produção (8.1.7.4)
>
> Resultado na Base de Produção
>
> LPAD('',2*(LEVEL-1))||OPERATION
>
>
> OPTIONSObject
POSITION
> COST
> -- -- --
> --
> SELECT STATEMEN
RES: RES: RES: [oracle_br] Ajuda com Query Urgente
Valeu chiappa, realmente não uso muito o explain pelo sqlplus, normalmente
uso ferramenta gráfica e fica dificil copiar. De qualquer maneira segue com
o script que vc enviou.
-
| Id | Operation | Name | Rows | Bytes | Cost |
-
| 0 | SELECT STATEMENT || 1 |26 | 2165K|
|* 1 | FILTER|| | | |
| 2 | SORT GROUP BY|| 1 |26 | 2165K|
| 3 |MERGE JOIN CARTESIAN||71M| 1763M| 1965K|
|* 4 | TABLE ACCESS FULL | TB_LOG_TAREFA | 8433 | 75897 | 233 |
| 5 | BUFFER SORT|| 8433 | 140K| 2165K|
|* 6 | TABLE ACCESS FULL | TB_LOG_TAREFA | 8433 | 140K| 233 |
-
Abraços,
Nelson Cartaxo
DBA ORACLE
-Mensagem original-
De: jlchiappa [mailto:[EMAIL PROTECTED]
Enviada em: terça-feira, 4 de abril de 2006 15:57
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: RES: [oracle_br] Ajuda com Query Urgente
Colega, PMFJI mas uma das mais importantes coisas quando se analiza
um provável caso de full-scan "errado" é a número de linhas que cada
passo do plano traz : isso já aparece direitonho na PLAN_TABLE da
versão 9i, mas o seu script de consulta à PLAN_TABLE pelo jeito não o
está mostrando (que pelo famigerado lpad deduzo ser uma versão
ANTIGA, dessas copiadas pelos sites/livros de Oracle) : sugiro que vc
APOSENTE esse morto-vivo aí, e passe a usar o seguinte no 9i :
[EMAIL PROTECTED]:SQL>get explain
1 select distinct statement_id from plan_table;
2 accept V_STATEMENT_ID prompt 'Statement a Explicar (respeitando
maiúsculas/minusc.) :'
3* select * from table(dbms_xplan.display
('PLAN_TABLE', '&V_STATEMENT_ID', 'ALL'));
[EMAIL PROTECTED]:SQL>
e tenha no 9i o parâmetro statistics_level ao menos como TYPICAL,
olha só como é mais completinho o report assim :
[EMAIL PROTECTED]:SQL>ed
Gravou arquivo afiedt.buf
1 explain plan set statement_id='P1' for
2 select *
3from (select e.empno, d.dname
4from emp e ,dept d
5 where e.deptno=d.deptno
6 and sal > 1000
7 order by sal desc
8 )
9* where rownum < 10
[EMAIL PROTECTED]:SQL>/
Explicado.
[EMAIL PROTECTED]:SQL>@explain
STATEMENT_ID
--
P1
Statement a Explicar (respeitando maiúsculas/minusc.) :P1
antigo 1: select * from table(dbms_xplan.display
('PLAN_TABLE', '&V_STATEMENT_ID', 'ALL'))
novo 1: select * from table(dbms_xplan.display
('PLAN_TABLE', 'P1', 'ALL'))
PLAN_TABLE_OUTPUT
-
--
--
|Id |Operation | Name |Rows |Bytes|Cost
(%CPU)|
--
--
| 0 |SELECT STATEMENT | |9| 198|
21 (5)|
|*1 | COUNT STOPKEY | | |
| |
| 2 | VIEW | | 13|
286| |
|*3 | SORT ORDER BY STOPKEY | | 13| 247|
21 (5)|
|*4 |TABLE ACCESS BY INDEX ROWID| EMP |2| 16|
2 (50)|
| 5 | NESTED LOOPS | | 13| 247|
9 (12)|
| 6 | TABLE ACCESS FULL| DEPT |6| 66|
2 (0)|
|*7 | INDEX RANGE SCAN | IDX_DEPTNO_JOB|5| |
1 (0)|
--
--
Predicate Information (identified by operation id):
---
1 - filter(ROWNUM<10)
3 - filter(ROWNUM<10)
4 - filter("E"."SAL">1000)
7 - access("E"."DEPTNO"="D"."DEPTNO")
21 linhas selecionadas.
[EMAIL PROTECTED]:SQL>
==< taí ó, mostrando direitinho que operação cada passo está fazendo,
quem está sendo filtrado, as LINHAS e os BYTES envolvidos em cada
passo, muito mais completo - a tua query extrai o custo da
PLAN_TABLE, legal, mas e o resto ?
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo
<[EMAIL PROTECTED]> escreveu
>
> Marcio, talvez eu possa tentar com a equipe de desenvolvimento que
mudem a
> query, desde que tenha os mesmos resultados.Se vc tiver alguma dica
> agradeço.
>
> Segue os planos de desenvolmimento (9.2.0.7) e produção (8.1.7.4)
>
> Resultado na Base de Produção
>
> LPAD('',2*(LEVEL-1))||OPERATION
>
>
> OPTIONSObject
POSITION
> COST
> -- -- --
> --
> SELECT STATEMENT
>
