RES: [oracle_br] Re: Ajuda com Query Urgente

2006-04-04 Por tôpico jlchiappa
optimizer_index_caching=0 e optimizer_index_cost_adj=100 são o 
default, isso mostra que vc não os ajustou, repito, SEM ajustar esses 
caras normalmente não rola direito CBO, use o paper "THE SEARCH FOR 
INTELLIGENT LIFE IN THE COST-BASED OPTIMIZER", de Tim Gorman, online 
em http://www.evdbt.com/papers.htm que ele te dá boas dicas sobre 
como os ajustar, e porque/quando os ajustar. Recomendaria também o já 
clássico "A LOOK UNDER THE HOOD OF CBO: THE 10053 EVENT", de Wolfgang 
Breitling, online em www.hotsos.com (é só se registrar, é grátis) pra 
vc testar se os seus ajustes de CBO estão bem, qual é o comportamento 
duma determinada query em CBO...

 Quanto ao EXISTS, não, eu repito : vc pediu MAX, MAX retorna só uma 
linha, então tanto IN (select max... ) como EXISTS (select max...) 
não fazem muito sentido, a comparação deveria ser campo = (select 
max).
 
 Quanto à diferença de versões, sim, é MUITO comum (já que são bancos 
absolutamente DIFERENTES!!) vc ter performances diferentes... No caso 
do 9i , além dos ajustes de CBO, em casos de performance com sub-
queries vc pode checar os params citados nas notas 258167.1 e 
258945.1, não parece ser o caso aqui, mas vale o check.
 
 Quanto aos histogramas, exatamente para QUAIS colunas vc o 
armazenou, pelo que vejo ao menos nas colunas que sofrem comparação 
(ie, co_tarefa e dt_inicio ) vc deveria, Já que é 9i, vc usou a 
feature de SIZE AUTO na hora de criar os histogramas, ou especificou 
um tamanho diretamente ?
 
 []s
 
  Chiappa
  
--- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo 
<[EMAIL PROTECTED]> escreveu
>
> Oi chiappa,
>  
> Vamos aos parametros
> NAME TypeVALUE
>  ---
> --
> optimizer_dynamic_sampling   integer 1
> optimizer_features_enablestring  9.2.0
> optimizer_index_caching  integer 0
> optimizer_index_cost_adj integer 100
> optimizer_max_permutations   integer 2000
> optimizer_mode   string  CHOOSE
> pga_aggregate_target big integer 83886080
> workarea_size_policy string  AUTO
>  
> Fiz alguns testes com histogramas nas colunas utilizadas e não tive 
exito. A
> tabela tem 126000 registros.  Se trocar o in por exists será que 
melhora?
> Na base em oracle 8.1.7.4 a query voa da mesma maneira. O Negocio é 
que o
> plano de execução do oracle 8i para o 9i está diferente.
>  
> Obrigado desde já pela atenção
>  
> 
> Atenciosamente, 
> Nelson Cartaxo 
> DBA ORACLE 
> 
> 
> -Mensagem original-
> De: jlchiappa [mailto:[EMAIL PROTECTED]
> Enviada em: terça-feira, 4 de abril de 2006 13:06
> Para: oracle_br@yahoogrupos.com.br
> Assunto: [oracle_br] Re: Ajuda com Query Urgente
> 
> 
> Como já dito algumas vezes por aqui mesmo, CBO ** implica ** 
diversas 
> configurações a mais, como por exemplo os parâmetros optimizer_nnn, 
> os parâmetros de PGA (seja sort_area e hash se for workspace 
manual, 
> seja os param de aggregate se work=AUTO), db_multiblock_read, vc os 
> ajustou ??? Rodar CBO sem eles normalmente SÓ PODE dar enrosco, o 
> coitado do otimizador via estar sem algumas infos importantes, vai 
> chutar e muitas vezes erra... Além disso, não basta só 
dizer "tabela 
> analizada" , de que maneira vc coletou essas stats ? Vc ** MANDOU 
** 
> serem montados HISTOGRAMAS nas colunas com valores de distribuição 
> irregular ??? Histogramas são outro ponto-CHAVE em muitos casos... 
> Vamos começar por aí, só faço duas obs para essa query : 
>   1. IN significa que vai haver MUITOS valores, e vc está pedindo 
> MAX, que SEMPRE traz um só, alguma coisa está "estranha" aí
> 
>   2. pra achar o máximo valor, normalmente é MUITO mais negócio vc  
> fazer : SELECT * FROM (SELECT campo from tabela order by campo desc 
> NULLS LAST)
>  WHERE rownum < 2
> 
>   do que o MAX, o MAX normalmente ** implica ** que vc quer ler 
todos 
> os valores.
> 
> []s
> 
>   Chiappa
> 
> --- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo 
> <[EMAIL PROTECTED]> escreveu
> >
> > Pessoal mais uma vez vou tentar recorrer a voces.
> >  
> > Oracle 9.2.0.7 RedHat 2.1
> >  
> > Seguinte ao rodar a query abaixo com a tabela analisada com 
> dbms_stats e
> > indices tambem analisados, o plano mostra um merge join 
(cartesian) 
> e a
> > query trava, ou seja, fica no limbo. Quando coloco um hint de 
RULE 
> a query
> > fica instantanea.   Alguem poderia me dar uma luz como faço para 
> resolver.
> > De repente to comendo mosca em algum parametro do oracle, ou algo 
> parecido.
> >  
> > A query é
> >  
> > SELECT /*+ RULE */st_tarefa
> > FROM siops.tb_log_tarefa Text 
> > WHERE co_tarefa = 10 
> > AND dt_inicio IN ( 
> > SELECT MAX(dt_inicio)
> > FROM siops.tb_log_tarefa TInt 
> > WHERE tExt.co_tarefa = TInt.co_tarefa)
> > 
> >  
> > 
> > Obrigado desde já pelo help.
> > 
> >  
>

RES: [oracle_br] Re: Ajuda com Query Urgente

2006-04-04 Por tôpico Nelson Cartaxo
Oi chiappa,
 
Vamos aos parametros
NAME TypeVALUE
 ---
--
optimizer_dynamic_sampling   integer 1
optimizer_features_enablestring  9.2.0
optimizer_index_caching  integer 0
optimizer_index_cost_adj integer 100
optimizer_max_permutations   integer 2000
optimizer_mode   string  CHOOSE
pga_aggregate_target big integer 83886080
workarea_size_policy string  AUTO
 
Fiz alguns testes com histogramas nas colunas utilizadas e não tive exito. A
tabela tem 126000 registros.  Se trocar o in por exists será que melhora?
Na base em oracle 8.1.7.4 a query voa da mesma maneira. O Negocio é que o
plano de execução do oracle 8i para o 9i está diferente.
 
Obrigado desde já pela atenção
 

Atenciosamente, 
Nelson Cartaxo 
DBA ORACLE 


-Mensagem original-
De: jlchiappa [mailto:[EMAIL PROTECTED]
Enviada em: terça-feira, 4 de abril de 2006 13:06
Para: oracle_br@yahoogrupos.com.br
Assunto: [oracle_br] Re: Ajuda com Query Urgente


Como já dito algumas vezes por aqui mesmo, CBO ** implica ** diversas 
configurações a mais, como por exemplo os parâmetros optimizer_nnn, 
os parâmetros de PGA (seja sort_area e hash se for workspace manual, 
seja os param de aggregate se work=AUTO), db_multiblock_read, vc os 
ajustou ??? Rodar CBO sem eles normalmente SÓ PODE dar enrosco, o 
coitado do otimizador via estar sem algumas infos importantes, vai 
chutar e muitas vezes erra... Além disso, não basta só dizer "tabela 
analizada" , de que maneira vc coletou essas stats ? Vc ** MANDOU ** 
serem montados HISTOGRAMAS nas colunas com valores de distribuição 
irregular ??? Histogramas são outro ponto-CHAVE em muitos casos... 
Vamos começar por aí, só faço duas obs para essa query : 
  1. IN significa que vai haver MUITOS valores, e vc está pedindo 
MAX, que SEMPRE traz um só, alguma coisa está "estranha" aí

  2. pra achar o máximo valor, normalmente é MUITO mais negócio vc  
fazer : SELECT * FROM (SELECT campo from tabela order by campo desc 
NULLS LAST)
 WHERE rownum < 2

  do que o MAX, o MAX normalmente ** implica ** que vc quer ler todos 
os valores.

[]s

  Chiappa

--- Em oracle_br@yahoogrupos.com.br, Nelson Cartaxo 
<[EMAIL PROTECTED]> escreveu
>
> Pessoal mais uma vez vou tentar recorrer a voces.
>  
> Oracle 9.2.0.7 RedHat 2.1
>  
> Seguinte ao rodar a query abaixo com a tabela analisada com 
dbms_stats e
> indices tambem analisados, o plano mostra um merge join (cartesian) 
e a
> query trava, ou seja, fica no limbo. Quando coloco um hint de RULE 
a query
> fica instantanea.   Alguem poderia me dar uma luz como faço para 
resolver.
> De repente to comendo mosca em algum parametro do oracle, ou algo 
parecido.
>  
> A query é
>  
> SELECT /*+ RULE */st_tarefa
> FROM siops.tb_log_tarefa Text 
> WHERE co_tarefa = 10 
> AND dt_inicio IN ( 
> SELECT MAX(dt_inicio)
> FROM siops.tb_log_tarefa TInt 
> WHERE tExt.co_tarefa = TInt.co_tarefa)
> 
>  
> 
> Obrigado desde já pelo help.
> 
>  
> 
>  
> 
> Atenciosamente, 
> Nelson Cartaxo 
> DBA ORACLE 
> 
> 
> -Mensagem original-
> De: Anderson Haertel Rodrigues [mailto:[EMAIL PROTECTED]
> Enviada em: terça-feira, 4 de abril de 2006 11:16
> Para: oracle_br@yahoogrupos.com.br
> Assunto: Re: [oracle_br] ENC: Dúvida BLOB
> 
> 
> Ricardo,
> 
> Eu respondi a sua questão no Sábado a noite.
> 
> 
> --- Ricardo Lyrio <[EMAIL PROTECTED]> escreveu:
> 
> > Pessoal,
> > 
> >  
> > 
> > Estou com um impasse que é o seguinte:
> > 
> >  
> > 
> > Tenho a seguinte estrutura:
> > 
> >  
> > 
> > 36 telas de forms sendo que apenas 5 fazem
> > tratamento de imagens
> > 
> >  
> > 
> > Tabela 1
> > 
> >Campo01
> > 
> >Campo02
> > 
> >...
> > 
> >Campo0n
> > 
> >Imagem01
> > 
> >Imagem02
> > 
> >...
> > 
> >Imagem12
> > 
> >  
> > 
> > As imagens são todas Blob
> > 
> >  
> > 
> > Esta tabela tem mais ou menos 3.000.000 de registros
> > 
> >  
> > 
> > O que seria melhor:
> > 
> >  
> > 
> >Dividir a tabela, retirar as imagens e criar uma
> > outra tabela
> > 
> >  
> > 
> > Tabela 2
> > 
> >FK da tabela1
> > 
> >FK de Descrição da imagem
> > 
> >Imagem
> > 
> >  
> > 
> > Existe alguma limitação para o Oracle tratar em as
> > imagens numa mesma
> > tabela? 
> > 
> >  
> > 
> > Grato
> > 
> > Ricardo Lyrio
> > 
> >  
> > 
> > 
> > 
> > [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/