Aldo, alguns detalhes aí :
a) esse número de bug consta como corrigido nos últimos patches do
8i, cfrme :
...
Bug Fixes by Category
=====================
Category Fixed BugNo Description
....
Errors & Internal Errors
8174 1230798 Concurrent ALTER TABLESPACE READ ONLY can fail
with ORA-60
8174 1395086 OERI:6731 possible on update of chained row
locked by a DEAD transaction
8174 1395967 BACKUP CONTROLFILE TO TRACE does not escape
quotation marks in the filename (ORA-1967)
==> então COBRE desses DBAs aí que o patch REALMENTE esteja aplicado,
ok ?
b) SMON rodando constantemente necessariamente ** cheira ** a
tablespace permanente sendo feito coalesce, tenha ABSOLUTA certeza de
que esse banco, como SEMPRE é recomendado, vc só use tablespaces LMT
e que a tablespace temp ** não ** é do tipo permamente, e que usa
TEMPFILES, e nunca datafiles, E que NINGUÉM use outra tablespace
afora a TEMP como tablespace tempórária, cobre isso dos DBAs aí...
c) a área de sort, como qquer área de memória no bd Oracle em sendo
conexão dedicada, é alocada à pedido do banco pelo SO, então o SO **
tem ** que estar corretamente ajustado, no caso de unix peça que
sejam checados os params de kernel E o ulimit do usuário oracle
[]s
Chiappa
===========================================================
Participe do ENPO - Encontro de Profissionais Oracle 2006 !
Informações e inscrições em www.enpo-br.org
José Laurindo Chiappa, Palestrante ENPO-2006
===========================================================
--- Em oracle_br@yahoogrupos.com.br, "Aldo Moreira Beleza"
<[EMAIL PROTECTED]> escreveu
>
> Ah e ja foi feita a sugestão descrita no Metalink.
>
> 2006/10/9, Aldo Moreira Beleza <[EMAIL PROTECTED]>:
> >
> > o Metalink diz o seguinte :
> >
> > There was a bug:1395086 in Oracle8i
> > "An ORA-600 [6731] can occur if an update / delete
> > operation tries to modify a chained row if block level
> > recovery has recovered the row head-piece but not the
> > chained row pieces."
> >
> > Workaround:
> > Set the following parameter in init.ora and restart
> > the instance:
> > _enable_block_level_transaction_recovery=FALSE
> > When this parameter is set to false, the error won't
> > happen again.
> > Row locks of failed transactions will be recovered the
> > same way as before block level transaction recovery
> > was available.
> >
> > Chamaram 2 DBA's para cuidar do caso aqui , não tenho o knowhow
sufuciente
> > pra cuidar do caso, mas eles fizeram o seguinte, droparam a
tablespace
> > temporaria , deram o shutdown no banco, e criaram outra, agora o
smon está
> > rodando direto , sorry, o smon ja estava rodando antes, mas agora
está
> > pegando 70% da CPU, e continuamos com o mesmo problema, estou
esperando
> > eles chegarem e colher maiores informações .
> >
> > Agradeço à lista mais uma vez.
> >
> > Aldo Beleza.
> >
> > Em 09/10/06, jlchiappa <[EMAIL PROTECTED]> escreveu:
> > >
> > > Verdade, quando se fala em performance de ordenação a primeira
coisa
> > > que se pensa é nos params sort_area_nn, hash_area_nn e
assemelhados,
> > > MAS não podemos esquecer que na msg o colega lá fala :
> > >
> > > "erro ora-0600 [6731]"
> > >
> > > ==> e como SEMPRE, SEMPRE, absolutamente TODO e QUALQUER erro
ORA-600
> > > significa "bug encontrado, acionar Suporte Oracle ao ao menos
> > > pesquisar no metalink casos semelhantes", sem sombra de dúvida.
> > >
> > > []s
> > >
> > > Chiappa
> > >
> > > ===========================================================
> > > Participe do ENPO - Encontro de Profissionais Oracle 2006 !
> > > Informações e inscrições em www.enpo-br.org
> > > José Laurindo Chiappa, Palestrante ENPO-2006
> > > ===========================================================
> > >
> > > --- Em oracle_br@yahoogrupos.com.br, "Sandro Niederauer"
> > > <[EMAIL PROTECTED]> escreveu
> > > >
> > > > Se o problema só ocorre quando se coloca o ORDER BY, então é
porque
> > > o
> > > > SORT_AREA_SIZE está muito pequeno.
> > > >
> > > > Sandro
> > > >
> > > >
> > > > 2006/10/7, Aldo Moreira Beleza <[EMAIL PROTECTED]>:
> > > > >
> > > > > Pessoal ,
> > > > >
> > > > > Estou com um problema de lentidão no oralcle, a maquina não
esta
> > > > > sobrecarregada, mas ao fazer consultas no banco estou tendo
> > > problemas de
> > > > > lentidão, um select simples em 1 tabela de 5000 registros
não
> > > consegue
> > > > > trazer o resultset, isso só ocorre quando coloco order by,
sem
> > > ele a
> > > > > resposta é intantanea, já olhei a tablespace temporária e há
> > > espaço
> > > > > suficiente nela, nesta madrugada deu um erro ora-0600
[6731] .
> > > Alguem sabe
> > > > > o
> > > > > que pode estaro ocorrendo ??
> > > > >
> > > > > Grato,
> > > > >
> > > > > Aldo Beleza.
> > > > >
> > > > >
> > > > > [As partes desta mensagem que não continham texto foram
removidas]
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > [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 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/
--------------------------------------------------------------------------------------------------------------------------__________________________________________________________________
Vem aí: ENPO-BR 2006 - Encontro Nacional de Profissionais Oracle
VISITE: http://www.enpo-br.org/ - Dia 11/11 "Vagas Limitadas"
__________________________________________________________________
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
