Chegou a ver se este BUG não foi corrigido no patch 9.2.0.8.0?
 
Caso não, hehehe...se não tem remédio, remediado está, ou, mude o Código da 
Stored Procedure, ao invés de MERGE, passe a fazer uns SELECTs antes do 
INSERT/UPDATE........
 
Sucesso,
 
Atenciosamente,

Anderson Haertel Rodrigues
Administrador de Banco de Dados
Florianópolis/SC - [EMAIL PROTECTED] 


-----Mensagem original-----
De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] nome de Ivan
Enviada em: quarta-feira, 20 de setembro de 2006 17:46
Para: oracle_br@yahoogrupos.com.br
Assunto: RES: [oracle_br] Re: RES: Arqs de Trace no UDUMP


Pois é, como eu disse, isto já ocorreu. 

Da outra vez, recebi um erro "ORA-600 kcbnew_3". 
Abri um chamado na oracle e eles se limitaram a me dizer que isso acontece,
e que o "workaround" era sempre dropar o indice antes de fazer o merge. 
Achei um absurdo! 

Por estas e outras que eu não confio no suporte da oracle!
O resumo deles na época:


CAUSE DETERMINATION
====================
ORA-600 kcbnew_3 on indexes after massive loads


CAUSE JUSTIFICATION
====================
NA

.
POTENTIAL SOLUTION(S)
======================
Use workaround:
* Drop index
* Merge operations (they'll run faster as no index adjustement will be
needed)
* Create index


POTENTIAL SOLUTION JUSTIFICATION(S)
====================================
Workaround worked for cust


.
SOLUTION / ACTION PLAN
=======================
Use workaround:
* Drop index
* Merge operations (they'll run faster as no index adjustement will be
needed)
* Create index




> -----Mensagem original-----
> De: oracle_br@yahoogrupos.com.br 
> [mailto:[EMAIL PROTECTED] Em nome de Anderson 
> Haertel Rodrigues - FLN
> Enviada em: quarta-feira, 20 de setembro de 2006 17:09
> Para: oracle_br@yahoogrupos.com.br
> Assunto: RES: [oracle_br] Re: RES: Arqs de Trace no UDUMP
> 
> Índice Corrompido constantemente....É Oracle ou Clipper? - 
> hehehhee....
> 
> Ivan, passe um DBV com o Banco fora do ar e no ar e veja os 
> resultados..........
> 
> ps: procure por bug também no MetaLink.
> 
> -----Mensagem original-----
> De: oracle_br@yahoogrupos.com.br 
> [mailto:[EMAIL PROTECTED] nome de Ivan Enviada 
> em: quarta-feira, 20 de setembro de 2006 15:29
> Para: oracle_br@yahoogrupos.com.br
> Assunto: RES: [oracle_br] Re: RES: Arqs de Trace no UDUMP
> 
> 
> 
> Chiappa, descobri o problema.
> 
> Isto já me aconteceu e se apresentou de outra forma, tenho 
> uma procedure que é atualizada constantemente usando um 
> merge. Sabe-se lá o motivo, o indice fica corrompido e dá 
> estes erros bizarros...
> 
> Solução: drop index/merge/create index
> 
> Obrigado pela ajuda
> 
> Abraço
> Ivan
> 
> > -----Mensagem original-----
> > De: oracle_br@yahoogrupos.com.br
> > [mailto:[EMAIL PROTECTED] Em nome de jlchiappa 
> Enviada em: 
> > quarta-feira, 20 de setembro de 2006 11:41
> > Para: oracle_br@yahoogrupos.com.br
> > Assunto: [oracle_br] Re: RES: Arqs de Trace no UDUMP
> > 
> > Pra gente poder comentar, penso que em PRIMEIRO lugar teríamos que 
> > saber A QUE se referem esses traces : se estão no UDUMP ok, é 
> > referente à processo de usuário e não geral de banco, mas 
> eles podem 
> > ser traces de SQL decorrentes do evento 10046, OU traces devidos à 
> > eliminação inesperada do processo de usuário (por exemplo 
> DEADLOCKs), 
> > OU de efetivação de recovery de sessão.... Pra vc saber 
> isso, leia as 
> > linhas iniciais de vários dos arqs gerados (todos os 
> arquivos .TRC são 
> > textos ASCII, pode ser via editor ou via comandos do SO), 
> vc vai ver q 
> > o formato é tipo :
> > 
> > /oracle/admin/BDPROD/udump>cat BDPROD_ora_23571.trc
> > 
> > ==> as primeiras linhas identificam a instância, é blablabla...
> > 
> > /u1/app/oracle/admin/BDPROD/udump/BDPROD_ora_23571.trc
> > Oracle9i Enterprise Edition Release 9.2.0.5.0 - 64bit 
> Production With 
> > the Partitioning option JServer Release 9.2.0.5.0 - Production 
> > ORACLE_HOME = /u1/app/oracle/product/9.2.0
> > System name:    HP-UX
> > Node name:      BDPROD
> > Release:        B.11.11
> > Version:        U
> > Machine:        9000/800
> > Instance name: BDPROD
> > Redo thread mounted by this instance: 1 Oracle process 
> number: 20 Unix 
> > process pid: 23571, image: [EMAIL PROTECTED] (TNS V1-V3)
> > 
> > ==> e depois aí sim vem a identificação do tipo do arquivo, 
> abaixo é 
> > um arquivo gerado por recovery :
> > 
> > *** SESSION ID:(19.3) 2006-08-26 08:34:29.563 Thread checkpoint 
> > rba:0x0542b2.00000002.0010 scn:0x0676.0e52a51f On-disk 
> > rba:0x0542b3.000004ca.0000 scn:0x0676.0e52e742 Use incremental 
> > checkpoint cache-low RBA Thread 1 recovery from 
> > rba:0x0542b2.000009a9.0000 scn:0x0000.00000000
> > ----- Redo read statistics for thread 1 ----- Read rate
> > (ASYNC): 8990Kb in 1.98s => 4.04 Mb/sec Longest record: 8Kb,
> > moves: 1/24277 (0%) Change moves: 100/994 (10%), moved: 0Mb
> > ----------------------------------------------
> > ... blablabla ...
> > 
> > ==> um exemplo de seção de identificação de um arquivo de trace por 
> > deadlock :
> > 
> > ... blablabla, pula a seção de identificação ...
> > 
> > *** 2006-09-07 00:46:04.207
> > *** SESSION ID:(79.20632) 2006-09-07 00:46:04.193 DEADLOCK DETECTED 
> > Current SQL statement for this session:
> > update XXXXX  set IMPORTE=(IMPORTE+:b0),IMPORTE_IVA_1=
> > (IMPORTE_IVA_1+:b1
> > ),FECHA_ULT_MOD=SYSDATE,USUARIO_ULT_MOD=:b2 where ROWID=:b3 The 
> > following deadlock is not an ORACLE error. It is a deadlock due to 
> > user error in the design of an application or from issuing 
> incorrect 
> > ad-hoc SQL. The following information may aid in determining the 
> > deadlock:
> > Deadlock graph:
> >                        ---------Blocker(s)--------  ---------Waiter
> > (s)---------
> > Resource Name          process session holds waits  process session 
> > holds waits
> > TX-00020010-0010e380       105      79     X            102      
> > 49           X
> > TX-0004000f-0009ce70       102      49     X            105      
> > 79           X
> > 
> > ==> um exemplo de seção de identificação de um arquivo de 
> trace de SQL 
> > :
> > 
> > ... blablabla, pula a seção de identificação ...
> > APPNAME mod='nomedoprograma' mh=3669949024 act='' 
> > ah=4029777240 ===================== PARSING IN CURSOR #3
> > len=18 dep=0 uid=22 oct=3 lid=22
> > tim=3633166700097 hv=271604965 ad='714e5898'
> > ... primeiro cursor do SQL sendo tracejado ...
> > END OF STMT
> > PARSE
> > #3:c=0,e=1271,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=3633166661632
> > ....
> > 
> > Então ABRA e LEIA as linhas iniciais desses arqs aí, 
> identifique o que 
> > eles são, que aí SIM a gente pode sugerir algo...
> > 
> > []s
> > 
> > Chiappa
> > 
> > --- Em oracle_br@yahoogrupos.com.br, "Ivan" <[EMAIL PROTECTED]> escreveu
> > >
> > > Ninguem tem ideia do que pode ser? 
> > > 
> > > > -----Mensagem original-----
> > > > De: Ivan [mailto:[EMAIL PROTECTED]
> > > > Enviada em: terça-feira, 19 de setembro de 2006 10:22
> > > > Para: 'oracle_br@yahoogrupos.com.br'
> > > > Assunto: Arqs de Trace no UDUMP
> > > > 
> > > > Oracle 9.2.0.7 on Linux
> > > > 
> > > > Pessoal,
> > > > 
> > > > Notei estes dias que vários arquivos .trc estão sendo 
> gerados na 
> > > > pasta UDUMP do meu servidor. Olhando o trace, não parece
> > ter nenhum
> > > > erro, e nenhum erro é reportado ao usuario também.
> > > > 
> > > > Analisando mais a fundo, cheguei ao processo - na verdade a 
> > > > procedure - causadora deste trace.
> > > > 
> > > > Criei uma procedure com nome diferente mas o mesmo conteudo da 
> > > > outra. E esta nova não gera  este trace. O que pode estar 
> > > > acontecendo? Algum usuario pode ter ativado isso? Como? Como 
> > > > desativá-lo?
> > > > 
> > > > Acredito que apagando esta procedure e criando novamente deva 
> > > > resolver, mas gostaria de resolver de uma forma mais "elegante".
> > > > 
> > > > Obrigado
> > > > Ivan
> > >
> > 
> > 
> > 
> > 
> > 
> >  
> > 
> 
> 
> 
> 
> 
> [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/ 
--------------------------------------------------------------------------------------------------------------------------__________________________________________________________________

OPORTUNIDADES DE TRABALHO, VAGAS, EMPREGOS PARA PROFISSIONAIS ORACLE VISITE: 
http://www.oraclebr.com.br/
__________________________________________________________________
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

 


Responder a