Í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] -------------------------------------------------------------------------------------------------------------------------- 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
