Re: RES: [oracle_br] Re: Algumas duvidas sobre blocos corrompidos
Prezado Ivan,
Já utilizei o procedimento abaixo em algumas situações e resolveu meu
problema:
1) Executar o seguinte procedimento de sistema:
dbms_repair.skip_corrupt_blocks
('',''.'');
2) Criar uma tabela temporária com os dados da tabela corrompida:
create table as select * from ;
3) Dropar a tabela corrompida, criar uma nova e tranferir os dados
recém-carregados da
tabela temporária:
drop table ;
create table as select * from ;
Espero tê-lo ajudado!
Bom dia!
Kika.
"Ivan Ricardo Schuster" <[EMAIL PROTECTED]>
Enviado Por: oracle_br@yahoogrupos.com.br
18/01/2006 07:40
Responder a oracle_br
Para:
cc:
Assunto: RES: [oracle_br] Re: Algumas duvidas sobre blocos
corrompidos
Chiappa,
Parei e iniciei o banco novamente (shutdown immediate / startup) e a
tabela
continua inacessivel. Se eu definir estes blocos como inutilizáveis será
que
esta tabela não ficará perdida e inutilizável? É uma tabela grande (180
GB)
e tenho outra maior ainda nesta mesma tablespace.
Abraço
Ivan
-Mensagem original-
De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em
nome de jlchiappa
Enviada em: terça-feira, 17 de janeiro de 2006 11:42
Para: oracle_br@yahoogrupos.com.br
Assunto: RES: [oracle_br] Re: Algumas duvidas sobre blocos corrompidos
afaik, não é preciso : quando vc baixa e sobe o banco, os
blocos "temporários" do tipo voltam pra dba_free_space, vão ser re-
usados, e já que vc rodou a verificação de hw e o bloco está
fisicamente bom no disco, quando ele for re-usado será lido/gravado
sem probs, creio.
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, "Ivan Ricardo Schuster"
<[EMAIL PROTECTED]> escreveu
>
> > 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.
>
>
> Acredito que terei que apagar esta tabela, certo?
>
>
>
> -Mensagem original-
> De: oracle_br@yahoogrupos.com.br
[mailto:[EMAIL PROTECTED] Em
> nome de jlchiappa
> Enviada em: terça-feira, 17 de janeiro de 2006 10:49
> Para: oracle_br@yahoogrupos.com.br
> Assunto: RES: [oracle_br] Re: Algumas duvidas sobre blocos
corrompidos
>
> --- 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 quan
RES: [oracle_br] Re: Algumas duvidas sobre blocos corrompidos
É,realmente então esses blocos estão perdidos mesmo, o negócio é os marcar como inacessíveis. Não, a tabela não vai ficar inacessível, o que vai ficar inacessível são as n linhas da tabela que residiam no (s) bloco(s) corrupto(s). O que eu faria se fosse vc é fazer uma salvagem dos dados dessa tabela antes, lendo os dados dos outros blocos (seja via PL/SQL como mostrado na nota do metalink 2064553.4, , seja via pro*C se vc tiver um mínimo conhecimento de C como mostrado na nota 97357.1). SE vc tiver um mínimo conhecimento nalguma linguagem de programação que permita ler um arquivo binário especificando o ponto de origem da leitura (como o fseek no C), vc pode tentar ler e gravar o conteúdo dos blocos ruins , OU vc pode tentar um dump desses blocos com o comando alter system dump datafile nn block xxx; de repente ainda dá pra extrair alguma informação mais. ==> Tendo essa salvagem em mãos pra se garantir, aí sim é usar a DBMS_REPAIR pra marcar os blocos como inusáveis, é isso. Quanto à questão de ter "mais outras tabelas na mesma tablespace" : ** SE ** vc tem o hardware absolutamente checado (como vc já disse que tem), se após a correção dos blocos todos vc fez um DBV com o banco online, um export full, usou a rotina de check de objeto da DBMS_REPAIR, fez outro DBV com o banco offline e refez o check de disco, vc já tem a garantia possível de que está tudo bem, nesse cenário não há porque se preocupar com as tabelas na mesma tablespace mais do que com qquer outras. ´[]s Chiappa --- Em oracle_br@yahoogrupos.com.br, "Ivan Ricardo Schuster" <[EMAIL PROTECTED]> escreveu > > Chiappa, > > Parei e iniciei o banco novamente (shutdown immediate / startup) e a tabela > continua inacessivel. Se eu definir estes blocos como inutilizáveis será que > esta tabela não ficará perdida e inutilizável? É uma tabela grande (180 GB) > e tenho outra maior ainda nesta mesma tablespace. > > Abraço > Ivan > > -Mensagem original- > De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em > nome de jlchiappa > Enviada em: terça-feira, 17 de janeiro de 2006 11:42 > Para: oracle_br@yahoogrupos.com.br > Assunto: RES: [oracle_br] Re: Algumas duvidas sobre blocos corrompidos > > afaik, não é preciso : quando vc baixa e sobe o banco, os > blocos "temporários" do tipo voltam pra dba_free_space, vão ser re- > usados, e já que vc rodou a verificação de hw e o bloco está > fisicamente bom no disco, quando ele for re-usado será lido/gravado > sem probs, creio. > > []s > > Chiappa > --- Em oracle_br@yahoogrupos.com.br, "Ivan Ricardo Schuster" > <[EMAIL PROTECTED]> escreveu > > > > > 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. > > > > > > Acredito que terei que apagar esta tabela, certo? > > > > > > > > -Mensagem original- > > De: oracle_br@yahoogrupos.com.br > [mailto:[EMAIL PROTECTED] Em > > nome de jlchiappa > > Enviada em: terça-feira, 17 de janeiro de 2006 10:49 > > Para: oracle_br@yahoogrupos.com.br > > Assunto: RES: [oracle_br] Re: Algumas duvidas sobre blocos > corrompidos > > > > --- 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
RES: [oracle_br] Re: Algumas duvidas sobre blocos corrompidos
Chiappa, Parei e iniciei o banco novamente (shutdown immediate / startup) e a tabela continua inacessivel. Se eu definir estes blocos como inutilizáveis será que esta tabela não ficará perdida e inutilizável? É uma tabela grande (180 GB) e tenho outra maior ainda nesta mesma tablespace. Abraço Ivan -Mensagem original- De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de jlchiappa Enviada em: terça-feira, 17 de janeiro de 2006 11:42 Para: oracle_br@yahoogrupos.com.br Assunto: RES: [oracle_br] Re: Algumas duvidas sobre blocos corrompidos afaik, não é preciso : quando vc baixa e sobe o banco, os blocos "temporários" do tipo voltam pra dba_free_space, vão ser re- usados, e já que vc rodou a verificação de hw e o bloco está fisicamente bom no disco, quando ele for re-usado será lido/gravado sem probs, creio. []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "Ivan Ricardo Schuster" <[EMAIL PROTECTED]> escreveu > > > 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. > > > Acredito que terei que apagar esta tabela, certo? > > > > -Mensagem original- > De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em > nome de jlchiappa > Enviada em: terça-feira, 17 de janeiro de 2006 10:49 > Para: oracle_br@yahoogrupos.com.br > Assunto: RES: [oracle_br] Re: Algumas duvidas sobre blocos corrompidos > > --- 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,
RES: [oracle_br] Re: Algumas duvidas sobre blocos corrompidos
afaik, não é preciso : quando vc baixa e sobe o banco, os blocos "temporários" do tipo voltam pra dba_free_space, vão ser re- usados, e já que vc rodou a verificação de hw e o bloco está fisicamente bom no disco, quando ele for re-usado será lido/gravado sem probs, creio. []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "Ivan Ricardo Schuster" <[EMAIL PROTECTED]> escreveu > > > 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. > > > Acredito que terei que apagar esta tabela, certo? > > > > -Mensagem original- > De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em > nome de jlchiappa > Enviada em: terça-feira, 17 de janeiro de 2006 10:49 > Para: oracle_br@yahoogrupos.com.br > Assunto: RES: [oracle_br] Re: Algumas duvidas sobre blocos corrompidos > > --- 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/ > -
RES: [oracle_br] Re: Algumas duvidas sobre blocos corrompidos
> 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. Acredito que terei que apagar esta tabela, certo? -Mensagem original- De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de jlchiappa Enviada em: terça-feira, 17 de janeiro de 2006 10:49 Para: oracle_br@yahoogrupos.com.br Assunto: RES: [oracle_br] Re: Algumas duvidas sobre blocos corrompidos --- 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 -- 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
RES: [oracle_br] Re: Algumas duvidas sobre blocos corrompidos
--- 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
RES: [oracle_br] Re: Algumas duvidas sobre blocos corrompidos
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, e a sua resposta "Esses blocos não podem ser usados do jeito que estão" já explica bastante coisa. Estou lendo sobre DBMS_REPAIR e acho que vai ser esta a solução pra estes problemas. Eu fiquei na duvida, pois alguns destes blocos corrompidos, ao apagar o objeto, foram preenchidos de forma correta novamente, sem corrompimento. 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. Vou continuar meus estudos sobre o DBMS_REPAIR, se tiver maia alguma dica, será bem-vinda. Abraço Ivan -Mensagem original- De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de jlchiappa Enviada em: segunda-feira, 16 de janeiro de 2006 20:52 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Re: Algumas duvidas sobre blocos corrompidos Respostas pra cada item : --- Em oracle_br@yahoogrupos.com.br, "Ivan Ricardo Schuster" <[EMAIL PROTECTED]> escreveu > > Pessoal, > > BD: ORACLE 9.2.0.7.0 > SO: Linux Red Hat Advanced Server > > No mês passado tive alguns problemas com blocos corrompidos e detectamos > falha em um dos discos do RAID de um BD. > > Solicitamos a troca do disco, que foi efetuada e teoricamente não tenho mais > problema de hardware. ==> num servidor de Produção, vc NÂO PODE ficar em teoria, vc TEM QUE comprovar que o hardware está OK, normalmente isso implica em rodar algum software de teste PRIFUNDO de hardware, só os testes do SO absolutamente não bastam Pra discos, muitas vezes o próprio fornecedor do storage oferece algo, veja lá. > > Rodei o DBVerify, que me reportou vários problemas de blocos lógicos > corrompidos. Esses blocos não podem ser usados do jeito que estão... >Como de costume, identifiquei pares de file_id/block_id e > relacionei a objetos do meu banco - alguns blocos eram utilizados por > objetos e outros não. Bloco não usado por índice/tabelas ou é da tablespace temporária, ou é bloco de undo/rollback, é por aí Consulte o file_id na dba_data_files e na dba_temp_files que vc deve achar à quais datafiles/temnpfiles eles pertencem... > > > Pergunto: > > O Oracle tem problemas ao reutilizar blocos lógicos corrompidos vazios? ==> é simples aqui, o Oracle ** espera ** que o hardware esteja ok, e ele é um banco de dados, não uma tool de SO, então ele NÂO SABE que o tal bloco já esteve ruim alguma vez. Se vc não quer que esses blocos que já estiveram/estão ruins não sejam usados, é VOCÊ que tem que os marcar como "não-usáveis", isso pode ser feito no SO (a maioria dos softs gerenciadores de storage tem utilitários pra isso) , ou vc pode usar a package DBMS_REPAIR . Com a package, o Oracle não vai mais usar o bloco marcado como inusável, MAS nada impede que o SO, ou outros programas, use-o para alguma coisa, se houver permissão. >Ele > não os conserta automaticamente? ==>> Não , vc é que tem que acionar o procedimento. NA verdade, a corrupção PODE ser em management do bloco (como freelists), pode ser bitmap, pode ser bloco de índice ou de data, há muitas possibilidades, o pessoal da Oracle preferiu que o banco não se metesse a "adivinhar" o que fazer, e ao invés só reportasse um status pro DBA quando solicitado, o que é até um procedimento mais seguro, Se for o caso, o DBV não marca estes blocos > como inutilizáveis? Também não, é o mesmo caso acima, DBV te reporta os problemas, é vc que os terá que corrigir. > Como marcar ou consertar estes blocos para que o problema não mais ocorra? ==>>> UMA VEZ que vc tenha absoluta certeza que p hardware está MESMO ok, vc pode tentar corrigir o bloco de disco formatando-o via utilitários do SO (a maioria dos fornecedores de storage oferece utilitários pra isto), ou, caso via SO não dê certo, vc pode marcar o bloco pra que o Oracle não o use mais,isso é com a package DBMS_REPAIR rotina dbms_repair.SKIP_CORRUPT_BLOCKS. > > > Mais uma pergunta, relacionada à anterior: > > Uma tabela particionada apresenta erro de blocos corrompidos, seja qual for > a partição que eu defina no select. O erro aparece inclusive se eu tento > consultar uma partição inexistente da tabela. Será que não há corrupção nalgum índice dessa tabela?? Ou ainda nos bitmaps dela ?? É o DBV que vai te dizer se os datafiles da tabela E dos índices estão íntegros. E eu prefiro sempre que possível rodar um dbv com o banco offline... > A consulta "select * from dba_extents where file_id= and > between block_id and block_id+blocks-1" não me retorna nenhum objeto. O que > afinal de contas está inválido no meu banco? Este datafile não é da > tablespace system. ==> como eu disse acima, SE o bloc não é encontrado, é sinal que não pé um bloco de dados/índice, a QUAL tablespace pertence o file_id em questão ?? É de um datafile ou de um tempfile ?? []s Chia
