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