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: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] > > > > > > > > > > > > > > > > > > -- > > Gabriel Hanauer > > > > > > -- Gabriel Hanauer -------------------------------------------------------------------------------------------------------------------------- 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
