Colega, além da instabilidade INERENTE ao se usar o operador de igual com 
ROWNUM, *** sempre *** há a possibilidade de bugs, ok, ESPECIALMENTE em vc 
usando essa versão tão antiga e bugada como é a 10.2.0.3 : num cliente do 
interior há alguns anos , ao migrar a aplicação deles no ambiente HOMO para 10g 
10.2.0.4 (isso foi pouco antes do patchset 10.2.0.5 sair) o pessoal caiu em 
MONTES de bugs com ORA-600 ou wrong results (ou mesmo NO ROWS) em queries com 
subqueries, de repente é ISSO que está pegando aí.... Só para vc ter uma idéia 
das possibilidades, veja o Bug 7324323 - Wrong results (no rows) with ROWNUM=1 
[ID 7324323.8] (que PARECE MUITO o seu caso), o Bug 6083292 - Wrong results 
from join predicate pushdown , Bug 6155146  Wrong results from query rewrite 
with pushed predicate , Bug 6707916 - Wrong results from join elimination .....
    Assim sendo, eu RECOMENDO FORTEMENTE que vc patcheie AO MENOS para o 
patchset 10.2.0.5, sim ???
        
         []s
         
           Chiappa
           

--- Em oracle_br@yahoogrupos.com.br, Rafael Bahr Esposito da Rocha 
<rocha.oracle@...> escreveu
>
> Boa tarde Milton,
> 
> sim, tenho certeza sobre o funcionamento, que fazendo rownum <= funciona. No 
> caso que estou enfrentado a versão é 10.2.0.3.
> 
> Há uns 6 meses passei pelo mesmo problema em uma versão do 11 e o DBA 
> responsável pela base do cliente atualizou um 
> patch ou atualizou versão, porém não tenho mais contato com ele e não sei o 
> que ele realmente fez. Estou tentando evitar 
> ter que revisar todas consultas da aplicação.
> 
> Att.
> 
> Rafael Bahr
> 
> Em 18/04/2013 17:08, Milton Bastos Henriquis Jr. escreveu:
> > Boa tarde Rafael
> >
> > Cara, eu aprendi muito tempo atrás que o correto era fazer sempre ROWNUM <
> > N.
> > Exemplo: se eu queria rownum = 1 (igual teu caso) eu deveria fazer rownum <
> > 2.
> > Como eu aprendi isso mais de 10 anos atrás eu realmente NÃO LEMBRO o motivo.
> >
> > O que sei é que no 10g tinha um BUG (4513695, corrigido na versão 10.2.0.4)
> > que deixava o rownum = 1
> > muito mais lento do que o rownum < 2.
> >
> > Mas no seu caso vc não disse que é lentidão, disse que simplesmente não
> > retorna informação,
> > o que é MUITO estranho.
> > Vc tem certeza absoluta que a mesma query que vc está fazendo retorna
> > informação se colocar
> > o  "=<" ou apenas "<"?
> >
> >
> >
> >
> >
> >
> > 2013/4/18 Rafael Bahr Esposito da Rocha <rocha.oracle@...>
> >
> >> **
> >>
> >>
> >> Boa tarde,
> >>
> >> em algumas versões do oracle (10g) ao utilizar um select com a estrutura
> >> abaixo não retorna nenhuma informação.
> >>
> >> SELECT *
> >> FROM (SELECT *
> >> FROM QUALQUER_TABELA t)
> >> WHERE ROWNUM = 1
> >>
> >> Porém se colocar a condição <=funciona normalmente.
> >>
> >> Em várias consultas da aplicação utilizamos a condição rownum = 1. Existe
> >> algumconfigurações ou atualização que resolva
> >> este problema sem ter que alterar todas consultas da aplicação?
> >>
> >> Soluçãojá aplicadaem alguma consultas:
> >>
> >> SELECT *
> >> FROM (SELECT *
> >> FROM QUALQUER_TABELA t)
> >> WHERE ROWNUM <= 1
> >>
> >> Atenciosamente,
> >>
> >> Rafael Bahr
> >>   
> >>
> >
> > [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
> >
> >
> >
>


Responder a