E é claro, só complementando, remoto ou não, ALGUÉM tem que fazer os checks de integridade penso eu - como é que se pode garantir que é só essa tabela, como é que se pode considerar válido esse dicionário de dados (e as tabelas internas do banco) sem checar/validar ao menos? É uma necessidade essas tarefas após um crash de server/banco, imho....
[]s Chiappa --- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <jlchia...@...> escreveu > > Ok, acredito que removendo os "complementos" , tipo constraints, índices, > partições, vc deva conseguir dropar esse sujeito, OU até mesmo, numa outra > opção, vc poderia tentar RENOMEAR o dito-cujo e criar o cara de novo a partir > dos seus exports... > Agora, uma recomendação : meu amigo, que esteja ** ESCRITO ** e ** ASSINADO > ** em algum lugar que vc não se responsabiliza pela inra-estrutura, E que se > eles querem o ** mínimo ** de estabilidade eles TEM QUE investirem num bom > gerador, no-breaks senoidais de qualidade pors servidores, em > correção/estabilização das linhas elétricas.... Digo isso porque no meu > último cliente (que era uma indústria também, no interior de SP) volta e meia > a região enfrentava apagões e quetais, a infra externa da cidade realmente > era meia boca, se não fosse o gerador e os nobreaks ferozes que eles tinham > o CPD deles tinha ido pro saco faz tempo... E é aquele begócio, o Oracle é um > banco de dados parrudo, cheio de seguranças internas, confiável, mas falha de > hardware e infra não tem software que segure... > > > []s > > Chiappa > --- Em oracle_br@yahoogrupos.com.br, "Akira" <akirasigma@> escreveu > > > > Bom Chiappa, valeu pelas dicas. > > O banco é de produção de uma indústria e que está remoto, bem remoto, por > > isso o *provavelmente*. A região tem problema de energia, internet, > > asfalto, meio de locomoção, etc. > > O servidor ficou por conta deles mesmo instalarem (so) , eu instalei o > > oracle, criei a base e importei minha estrutura de erp. > > Tenho backup com rman, archives e export full no último caso. Isso irá > > salvá-los! > > A correção é provisória mesmo, porque acabaram de comprar um novo server > > (melhor) para esse banco. Mas como existe a lei de murphy, tinha que dar > > esse problema antes de instalarem o novo. > > Por isso eu estava tentando apenas dropar e recriar a tabela que estava > > dando problema, por ser uma tabela bem pequena também (uns 500 registros > > só), e não encontrei nada no metalink à primeira vista. > > Depois eu posto o que fiz. > > > > Obrigado e boa noite > > Akira > > > > > > > > > > > > ----- Original Message ----- > > From: jlchiappa > > To: oracle_br@yahoogrupos.com.br > > Sent: Thursday, August 20, 2009 4:34 PM > > Subject: [oracle_br] Re: Problema com tabela (Urgente) > > > > > > Colega, primeiro essa "** provavelmente ** falha de hardware" me > > assusta, se for banco importante nem é preciso dizer que não pode ser > > PROVAVELMENTE, vc tem é que ter CERTEZA, descobrir mesmo o que aconteceu, > > ou ao menos fazer uma verificação de hardware ** PROFUNDA ** para garantir > > que não aconteça mais, senão vc tem um banco absolutamente INCONFIÀVEL em > > mãos... > > Respondendo especificamente à sua pergunta, temos que : > > > > a) a Oracle recomenda que todo e qualquer ORA-600 necessariamente seja > > objeto de um chamado no Suporte, é um erro sério > > > > b) comando transcedental desconheço, mas se vc for recriar o dicionário > > isso se faz com scripts sqlplus que ficam no servidor Oracle , em > > $ORACLE_HOME/rdbms/admin , como o catalog e o catproc, vc os pode executar > > mas TORNO A DIZER, se for um banco importante vc faz isso COM a juda do > > Suporte da Oracle, e (óbvio) com BACKUP antes e com cópia de dados (via > > export, geração de arqs texto, o que for) > > > > c) numa googlada rápida (que sempre deve ser um passo a se tomar) achei > > http://sandeepredkar.blogspot.com/2009/06/ora-600-ktadrprc-1.html , que > > basicamente reporta a questão como corrupção/inconsistência em tabs > > internas, antes de recriar o dicionário (** com ** ajuda do Suporte, friso > > de novo) pode valer a pena tentar remover constraints, types, índices e/ou > > as partições pertencentes à essa tabela, tentar um TRUNCATE nela... > > > > d) a pesquisa no metalink (que ** sempre ** tem que ser feita também), > > numa busca rapidinha não me trouxe nada específico, então recomendo que vc > > a faça e veja se alguns dos bugs/cenários citados tem a ver com vc > > > > e) já que não se sabe se estamos lidando com corrupção geral ou não nos > > objs internos, além das tools de verificação (que inclusive discutimos hoje > > aqui no fórum) a Oracle nos dá scripts de checagem não dos blocos, mas do > > banco como um todo, tais como citados nas notas Subject:"hcheck.sql script > > to check for known problems in Oracle8i, Oracle9i, Oracle10g and Oracle > > 11g" com Doc ID:36697.1 e nas nela citadas, SE o banco é importante vale > > uma checagem com eles > > > > > > []s > > > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, "Akira" <akirasigma@> escreveu > > > > > > Houve um problema, provavelmente falha de hardware no servidor onde > > fica o banco de dados. > > > Oracle 10.2.0.3 > > > Oracle Enterprise Linux (2.6.9-34.ELsmp) > > > > > > Após isso, o banco ficava caindo conforme uso, não ficava nem 1 hora > > aberto, mas consegui deixá-lo estável após dropar um objeto table que > > provavelmente estava corrompido, usando procedimentos que encontrei no > > metalink. > > > Agora ficou outro problema, em outra tabela não existe coluna, e por > > isso, não consigo nem dropá-la para recriá-la. O dicionário de dados está > > com problema, com certeza. > > > > > > Alguém tem idéia de como poderei resolver isso? Algum comando > > transcedental? > > > > > > Desde já agradeço. > > > > > > Akira > > > > > > > > > > > > Connected to: > > > Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production > > > With the Partitioning, OLAP and Data Mining options > > > > > > SQL> ANALYZE TABLE tipo_baixa_usuario VALIDATE STRUCTURE; > > > ANALYZE TABLE tipo_baixa_usuario VALIDATE STRUCTURE > > > * > > > ERROR at line 1: > > > ORA-00600: internal error code, arguments: [25027], [0], [0], [], [], > > [], [], > > > [] > > > > > > > > > SQL> drop table tipo_baixa_usuario; > > > drop table tipo_baixa_usuario > > > * > > > ERROR at line 1: > > > ORA-00600: internal error code, arguments: [ktadrprc-1], [], [], [], > > [], [], > > > [], [] > > > > > > > > > SQL> desc tipo_baixa_usuario > > > > > > SQL> select object_name, object_type from dba_objects where object_name > > = 'TIPO_BAIXA_USUARIO'; > > > > > > OBJECT_NAME > > > ---------------------------------------------------------- > > > OBJECT_TYPE > > > ------------------- > > > TIPO_BAIXA_USUARIO > > > TABLE > > > > > > > > > SQL> select table_name from dba_tables where table_name = > > 'TIPO_BAIXA_USUARIO'; > > > > > > no rows selected > > > > > > SQL> select * from tipo_baixa_usuario; > > > select * from tipo_baixa_usuario > > > * > > > ERROR at line 1: > > > ORA-30732: table contains no user-visible columns > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > >
