--- Em oracle_br@yahoogrupos.com.br, "Ivan Ricardo Schuster" <[EMAIL PROTECTED]> escreveu > > Chiappa, inicialmente obrigado pela explicação. > > Com o "teoricamente" não ter mais problemas de hardware, quis dizer que já > foram feitos todos os testes com as ferramentas do fornecedor do storage
==>. ESSE é o ponto que quis frisar, não pode haver dúvidas sobre a confiabilidade do hw, ok ... > a sua resposta "Esses blocos não podem ser usados do jeito que estão" já > explica bastante coisa. E é como falei, o Oracle ** não ** sai "consertando" blocos automaticamente porque, além de não "saber" fazer isso (há n+1 hardwares possíveis pelaí, x+1 tipos de filesystems/volume groups, etc), ainda há a questão do negócio, tranquilamente pode ser que alguns blocos corrupots pertencem a tabelas/índices;objetos que PODEM ser dropados, outros não, só vc é que pode dizer. > > Estou lendo sobre DBMS_REPAIR e acho que vai ser esta a solução pra estes > problemas. Na verdade é um conjunto de ações : agora que hardware está confiável, primeiro passo é o DBV contra TODOS os datafiles (eu se possível faço um dbv com o banco aberto E um com o banco fechado), e TODOS os blocos reportados como ruins pelo DBV deven ser corrigidos (inicialmente pode ser correção soft, pelo DBMS_REPAIR mesmo). Feito isso, novos DBVs pra mostrar que a corrupção foi MESMO corrigida, e como toque final um export full sem gerar .dmp (tipo desviando pra /dev/null) pra "forçar" a leitura de todos os segmentos, uma checagem com DBMS_REPAIR.CHECK_OBJECT nos objetos do banco, e é isso aí. >Eu fiquei na duvida, pois alguns destes blocos corrompidos, ao > apagar o objeto, foram preenchidos de forma correta novamente, sem > corrompimento. Isso é uma indicação que realmente o problema devia ser mesmo disco ruim, pois quando vc trocou o disco e refez o array, os blocos em questão (que antes deviam estar no disco ruim), passaram a apontar pra um outro disco bom, e nele foram gravados/lidos com sucesso. > > Sobre a tabela que eu estou sem acesso, o datafile é de dados, não é de > índices, nem temporário, nem system. Por isso achei bastante estranho. Na verdade, mesmo em tablespaces de dados podem ser criados extents temporários , por exemplo quando vc faz um INSERT /* APPEND */, nessa situação os caras sendo inseridos vão pra cima do high-water mark e são marcados como segmentos temporários (portanto NÃO entram na DBA_SEGMENTS/DBA_EXTENTS) : quando ocorre um COMMIT, o banco só marca esses extents como definitivos e avança a HWM. Num caso desses, se tiver corrupção/pau qquer no processo, logicamente esses blocos não serão encontrados na DBA_EXTENTS/DBA_SEGMENTS. []s Chiappa -------------------------------------------------------------------------------------------------------------------------- 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/ --------------------------------------------------------------------------------------------------------------------------_____________________________________________________________________ Area de download do grupo - http://www.4shared.com/dir/101727/a4dcc423 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