Re: RES: RES: [oracle_br] Re: RES: Arqs de Trace no UDUMP
Foram correções no 9ir2 e no 10gr1. Eu devo ter muita sorte com o suporte!! Tu tá usando o suporte de que maneira? Está abrindo SR no metalink? Se o bug ainda não é conhecido a primeira coisa que eles tem que te pedir é o alert log, os traces gerados e rodar o RDA na máquina. A Oracle é obrigada a resolver o problema. Como o Chiappa falou é obrigação deles. Ivan escreveu: Eu não sei que suporte da oracle você usa pra eles resolverem seus problemas dessa forma. Talvez voce use o 10G, em que eles se interessam mais em resolver bugs... E o caso que eu relatei não foi isolado: Estes dias tive problema com drop de partiçoes antigas enquanto o loader estava rodando... Dava outro ORA-600. A sugestão do suporte: parar o loader! Ora, se essa é a solução do problema, eu não preciso do suporte da oracle! E por aí vai... Perco mais tempo com esse suporte que perguntando aqui na lista... -Mensagem original- De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Gabriel Hanauer Enviada em: sábado, 30 de setembro de 2006 20:51 Para: oracle_br@yahoogrupos.com.br Assunto: Re: RES: [oracle_br] Re: RES: Arqs de Trace no UDUMP Ué, porque tu não confia se eles te deram a solução?? ;) Já peguei 3 bugs em que eles tiveram que gerar critical patch. E sempre o fizeram. E sempre resolveu o problema. Inclusive nos últimos dois o suporte me ligou para ver se a aplicação do patch tinha resolvido o problema. O suporte da Oracle é um dos pontos fortes. Ivan escreveu: 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:41Para: oracle_br@yahoogrupos.com.brAssunto: [oracle_br] Re: RES: Arqs de Trace no UDUMP Pra gente poder comentar, penso que em PRIMEIRO lugar teríamos quesaber 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 podemser 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 aslinhas 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 qo formato é tipo : /oracle/admin/BDPROD/udumpcat BDPROD_ora_23571.trc == as primeiras linhas identificam a instância, é blablabla
RES: RES: [oracle_br] Re: RES: Arqs de Trace no UDUMP
Na verdade se for sev1 realmente tem que resolver pra ontem, mas é plenamente aceitável um work-around enquanto não vem correção em casos não-severos, onde o banco não pare (como é o caso dum bug no loader ocasionando 0600), o que é inaceitável é uma resposta dizendo pra parar de usar SEM oferecer outra opção aceitável (que por exemplo poderia ser usar INSERT from externaltableapontandoproarqtexto), realmente se NÃO ofereceram algo do tipo pro Ivan ele tem TOTAL DIREITO de escalar isso, de re-abrir o chamado, o que precisar... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Gabriel Hanauer [EMAIL PROTECTED] escreveu Foram correções no 9ir2 e no 10gr1. Eu devo ter muita sorte com o suporte!! Tu tá usando o suporte de que maneira? Está abrindo SR no metalink? Se o bug ainda não é conhecido a primeira coisa que eles tem que te pedir é o alert log, os traces gerados e rodar o RDA na máquina. A Oracle é obrigada a resolver o problema. Como o Chiappa falou é obrigação deles. Ivan escreveu: Eu não sei que suporte da oracle você usa pra eles resolverem seus problemas dessa forma. Talvez voce use o 10G, em que eles se interessam mais em resolver bugs... E o caso que eu relatei não foi isolado: Estes dias tive problema com drop de partiçoes antigas enquanto o loader estava rodando... Dava outro ORA-600. A sugestão do suporte: parar o loader! Ora, se essa é a solução do problema, eu não preciso do suporte da oracle! E por aí vai... Perco mais tempo com esse suporte que perguntando aqui na lista... -Mensagem original- De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Gabriel Hanauer Enviada em: sábado, 30 de setembro de 2006 20:51 Para: oracle_br@yahoogrupos.com.br Assunto: Re: RES: [oracle_br] Re: RES: Arqs de Trace no UDUMP Ué, porque tu não confia se eles te deram a solução?? ;) Já peguei 3 bugs em que eles tiveram que gerar critical patch. E sempre o fizeram. E sempre resolveu o problema. Inclusive nos últimos dois o suporte me ligou para ver se a aplicação do patch tinha resolvido o problema. O suporte da Oracle é um dos pontos fortes. Ivan escreveu: 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:41Para: oracle_br@yahoogrupos.com.brAssunto: [oracle_br] Re: RES: Arqs de Trace no UDUMP Pra gente
Re: RES: RES: [oracle_br] Re: RES: Arqs de Trace no UDUMP
Sempre dois lados ;-) Tenho um aparente bug aberto em severidade 4 lá, já tem 2 dias e ainda não fizeram update. Eu escrevi algo sobre o bug no site http://mportes.blogspot.com/2006/09/grant-direto-para-desenvolvedor.html Porém, tive sorte em outros problemas como corrupção do orapwd. O procedimento confere com o que o Gabriel disse, eu enviei o RDA e o alert, abri como sev 3 e o retorno foi bastante satisfatório. On 10/1/06, Gabriel Hanauer [EMAIL PROTECTED] wrote: Foram correções no 9ir2 e no 10gr1. Eu devo ter muita sorte com o suporte!! Tu tá usando o suporte de que maneira? Está abrindo SR no metalink? Se o bug ainda não é conhecido a primeira coisa que eles tem que te pedir é o alert log, os traces gerados e rodar o RDA na máquina. A Oracle é obrigada a resolver o problema. Como o Chiappa falou é obrigação deles. Ivan escreveu: Eu não sei que suporte da oracle você usa pra eles resolverem seus problemas dessa forma. Talvez voce use o 10G, em que eles se interessam mais em resolver bugs... E o caso que eu relatei não foi isolado: Estes dias tive problema com drop de partiçoes antigas enquanto o loader estava rodando... Dava outro ORA-600. A sugestão do suporte: parar o loader! Ora, se essa é a solução do problema, eu não preciso do suporte da oracle! E por aí vai... Perco mais tempo com esse suporte que perguntando aqui na lista... -Mensagem original- De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Gabriel Hanauer Enviada em: sábado, 30 de setembro de 2006 20:51 Para: oracle_br@yahoogrupos.com.br Assunto: Re: RES: [oracle_br] Re: RES: Arqs de Trace no UDUMP Ué, porque tu não confia se eles te deram a solução?? ;) Já peguei 3 bugs em que eles tiveram que gerar critical patch. E sempre o fizeram. E sempre resolveu o problema. Inclusive nos últimos dois o suporte me ligou para ver se a aplicação do patch tinha resolvido o problema. O suporte da Oracle é um dos pontos fortes. Ivan escreveu: 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:41Para: oracle_br@yahoogrupos.com.brAssunto: [oracle_br] Re: RES: Arqs de Trace no UDUMP Pra gente poder comentar, penso que em PRIMEIRO lugar teríamos quesaber A QUE se referem esses traces : se estão no UDUMP ok, éreferente à processo de usuário e não geral
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/udumpcat 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.0002.0010 scn:0x0676.0e52a51f On-disk rba:0x0542b3.04ca. scn:0x0676.0e52e742 Use incremental checkpoint cache-low RBA Thread 1 recovery from rba:0x0542b2.09a9. scn:0x. - 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 X 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 X102 49 X TX-0004000f-0009ce70 102 49 X105 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=363311632 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
RES: [oracle_br] Re: RES: Arqs de Trace no UDUMP
Procedure que usa o comando SQL chamado MERGE dando erros ? Já vi uns bugs assim em alguns releases do 9ir2, normalmente há work-around, cheque com o SUporte, e mais importante, tenha CERTEZA que REALMENTE o bug não está corrompendo mais nada, fazendo um exp completo, um DBV online, outro offline (se puder) e um ANALYZE VALIDATE STRUCTURE dos índices todos... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Ivan [EMAIL PROTECTED] escreveu 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/udumpcat 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.0002.0010 scn:0x0676.0e52a51f On-disk rba:0x0542b3.04ca. scn:0x0676.0e52e742 Use incremental checkpoint cache-low RBA Thread 1 recovery from rba:0x0542b2.09a9. scn:0x. - 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 X 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 X102 49 X TX-0004000f-0009ce70 102 49 X105 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=363311632 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
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/udumpcat 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.0002.0010 scn:0x0676.0e52a51f On-disk rba:0x0542b3.04ca. scn:0x0676.0e52e742 Use incremental checkpoint cache-low RBA Thread 1 recovery from rba:0x0542b2.09a9. scn:0x. - 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 X 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 X102 49 X TX-0004000f-0009ce70 102 49 X105 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=363311632 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 é
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/udumpcat 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.0002.0010 scn:0x0676.0e52a51f On-disk rba:0x0542b3.04ca. scn:0x0676.0e52e742 Use incremental checkpoint cache-low RBA Thread 1 recovery from rba:0x0542b2.09a9. scn:0x. - 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 X 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
RES: [oracle_br] Re: RES: Arqs de Trace no UDUMP
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/udumpcat 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.0002.0010 scn:0x0676.0e52a51f On-disk rba:0x0542b3.04ca. scn:0x0676.0e52e742 Use incremental checkpoint cache-low RBA Thread 1 recovery from rba:0x0542b2.09a9. scn:0x. - 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
Re: RES: [oracle_br] Re: RES: Arqs de Trace no UDUMP
Ué, porque tu não confia se eles te deram a solução?? ;) Já peguei 3 bugs em que eles tiveram que gerar critical patch. E sempre o fizeram. E sempre resolveu o problema. Inclusive nos últimos dois o suporte me ligou para ver se a aplicação do patch tinha resolvido o problema. O suporte da Oracle é um dos pontos fortes. Ivan escreveu: 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/udumpcat 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.0002.0010 scn:0x0676.0e52a51f On-disk rba:0x0542b3.04ca. scn:0x0676.0e52e742 Use incremental checkpoint cache-low RBA Thread 1 recovery from rba:0x0542b2.09a9. scn:0x. - 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
RES: [oracle_br] Re: RES: Arqs de Trace no UDUMP
Ivan, só um detalhe aí : isso acontece é pura CONVERSA MOLE, absolutamente não dá pra aceitar, principalmente se vc recebe um ORA-600, POR DEFINIÇÃO isso é bug, é ERRO DO SOFTWARE, não tem nada de é assim mesmo, e sendo um bug o Suporte terá que fazer 4 coisas pra vc : a) reconhecer o bug como tal, dando um NÚMERO DE BUG pra ele, e uma previsão de quando deverá ser solucionado, em qual futura versão de banco - LÓGICO, temos q reconhecer que em softs complexos quase nunca um bug é solucionado de pronto, é plenamente aceitável algum tempo de análise, mas AO MENOS eles tem que reconhecer o bug b) DOCUMENTAR as condições em que o bug ocorre : não é só falar, ah, é dentro de stored procedure, mas não sei bem quando, não sei se é a fase da lua, se são as manchas solares, se são os gremlins... Eles TEM que o mais precisamente possível isolar as condições onde o bug ocorre. Isso vai ser VITAL pra vc mesmo, na hora que vc for aplicar o work-around deles, a linguagem SQL é ultra-expressiva, MUITAS vezes há diversas maneiras de se fazer a mesma coisa, SABENDOP EXATAMENTE onde tá o prob, vc muitas vezes consegue contornar MELHOR do que o Suporte ... c) enquanto a solução não vem, te dar um work-around que seja aceitável pra vc d) garantir que o bug não corrompeu nada mais (ou pelo menos te auxiliar nas verificações) == Todos esses itens são OBRIGAÇÃO deles e são um DIREITO de quem tem Suporte contratado, se algum deles ficou faltando REABRA o chamado (e de NOVO e de NOVO se não funcionar), telefone pro gerente ou pro VP adequado da Oracle (como empresa norte-americana isso pe o que não falta :) , use a opção do metalink de retorno de TARs, manda um mail pro suporte da matriz, carta registrada se for o caso, enfim, numa palavra, NÂO PERCA TEMPo batendo boca com atendente no telefone, ESCALE isso, ok ??? Como consumidores, só assim a gente consegue obter um produto melhor, e isso seja qual for o fornecedor, seja qual for o produto ou serviço... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Ivan [EMAIL PROTECTED] escreveu 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
Re: RES: [oracle_br] Re: RES: Arqs de Trace no UDUMP
É aqui no Citibank tivemos um ORA-00600 referente a latch na shared pool e o banco (produção) caia como uma pedra. Abrimos chamado e a resposta...MIGRE PARA 9.2.0.8 sendo que estavamos na 9.2.0.7, ridículo! aumentamos a shared pool e nunca mais tivemos problema. Depois que o suporte da Oracle foi para a India ficou horrivel, mas acho que vale a pena vc conversar com seu account manager da Oracle e ver se ele pode te auxiliar no escalonamento do chamado! boa sorte Ivan. abs, Luis Figueiredo. --- jlchiappa [EMAIL PROTECTED] escreveu: Ivan, só um detalhe aí : isso acontece é pura CONVERSA MOLE, absolutamente não dá pra aceitar, principalmente se vc recebe um ORA-600, POR DEFINIÇÃO isso é bug, é ERRO DO SOFTWARE, não tem nada de é assim mesmo, e sendo um bug o Suporte terá que fazer 4 coisas pra vc : a) reconhecer o bug como tal, dando um NÚMERO DE BUG pra ele, e uma previsão de quando deverá ser solucionado, em qual futura versão de banco - LÓGICO, temos q reconhecer que em softs complexos quase nunca um bug é solucionado de pronto, é plenamente aceitável algum tempo de análise, mas AO MENOS eles tem que reconhecer o bug b) DOCUMENTAR as condições em que o bug ocorre : não é só falar, ah, é dentro de stored procedure, mas não sei bem quando, não sei se é a fase da lua, se são as manchas solares, se são os gremlins... Eles TEM que o mais precisamente possível isolar as condições onde o bug ocorre. Isso vai ser VITAL pra vc mesmo, na hora que vc for aplicar o work-around deles, a linguagem SQL é ultra-expressiva, MUITAS vezes há diversas maneiras de se fazer a mesma coisa, SABENDOP EXATAMENTE onde tá o prob, vc muitas vezes consegue contornar MELHOR do que o Suporte ... c) enquanto a solução não vem, te dar um work-around que seja aceitável pra vc d) garantir que o bug não corrompeu nada mais (ou pelo menos te auxiliar nas verificações) == Todos esses itens são OBRIGAÇÃO deles e são um DIREITO de quem tem Suporte contratado, se algum deles ficou faltando REABRA o chamado (e de NOVO e de NOVO se não funcionar), telefone pro gerente ou pro VP adequado da Oracle (como empresa norte-americana isso pe o que não falta :) , use a opção do metalink de retorno de TARs, manda um mail pro suporte da matriz, carta registrada se for o caso, enfim, numa palavra, NÂO PERCA TEMPo batendo boca com atendente no telefone, ESCALE isso, ok ??? Como consumidores, só assim a gente consegue obter um produto melhor, e isso seja qual for o fornecedor, seja qual for o produto ou serviço... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Ivan [EMAIL PROTECTED] escreveu 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
