Re: RES: RES: RES: Res: [oracle_br] Corrupção de dados

2011-04-28 Por tôpico Leonardo Mello
Procurei no metalink por OSg e nao achei nada sobre a aplicacao. Teria o
nome completo do produto ?

Em 28 de abril de 2011 14:11, José Laurindo escreveu:

>
>
> Sim, ele vai ficar em background, coletando, até vc rodar o script de stop
> : no seu caso, como vc especificou, ele vai acordar a cada 60 segundos,
> fazer uma coleta, voltar a dormir, coletar 60 segundos depois, e assim por
> diante, enquanto vc não rodar o script de stop. Como vc especificou 24 horas
> de armazenamento, quando vc rodar o script de stop vc vai ver que apenas os
> resultados das últimas 24h vão estar registrado.
> O legal acho que é vc ter uma coleção de coletas de um dia sem usuários
> (tipo um Sábado/domingo), um de um dia normal de uso, uma outra de um dia de
> uso mais intenso (tipo, um fechamento de mês, sei la´) e aí vc comparar um
> com o outro - com o OSg (busque no metalink) vc pode inclusive gerar
> gráficos com a informação, ao invés de simplesmente comparar números...
>
> []s
>
> Chiappa
>
>
> --- Em oracle_br@yahoogrupos.com.br, Márcio Ricardo Alves da Silva
>  escreveu
>
> >
> > Chiappa,
> >
> > peguei as suas dicas de "monitoramento" do ambiente e estou implantando
> no meu banco, Release 10.2.0.5 (por enquanto homologação), HP-UX 11.23B.
> >
> > Primeiramente coloquei o OSWATCHER, coloquei os parâmetros com 60
> segundos e ficar armazenado 24 horas.
> > # ./startOSW.sh 60 24
> > #
> >
> > Testing for discovery of OS Utilities...
> >
> > VMSTAT found on your system.
> > IOSTAT found on your system.
> > MPSTAT found on your system.
> > NETSTAT found on your system.
> > TOP found on your system.
> >
> > Discovery completed.
> >
> > Starting OSWatcher v3.0.1 on Thu Apr 28 11:11:50 SAT 2011
> > With SnapshotInterval = 60
> > With ArchiveInterval = 24
> >
> > OSWatcher - Written by Carl Davis, Center of Expertise, Oracle
> Corporation
> >
> > Starting Data Collection...
> >
> > osw heartbeat:Thu Apr 28 11:11:50 SAT 2011
> > osw heartbeat:Thu Apr 28 11:12:50 SAT 2011
> > osw heartbeat:Thu Apr 28 11:13:50 SAT 2011
> > osw heartbeat:Thu Apr 28 11:14:50 SAT 2011
> > osw heartbeat:Thu Apr 28 11:15:50 SAT 2011
> > osw heartbeat:Thu Apr 28 11:16:50 SAT 2011
> > osw heartbeat:Thu Apr 28 11:17:50 SAT 2011
> > osw heartbeat:Thu Apr 28 11:18:51 SAT 2011
> >
> > Ele está dessa maneira, ele fica rodando assim ou fica em background?
> >
> > Grato,
> > Márcio.
> > - Original Message -
> > From: José Laurindo
> > To: oracle_br@yahoogrupos.com.br
> > Sent: Tuesday, April 26, 2011 7:12 PM
> > Subject: Re: RES: RES: RES: Res: [oracle_br] Corrupção de dados
> >
> >
> >
> > OK : cheque então os ** outros ** parãmetros de checksum de banco, se els
> estão Ativos ou não, e se Podem (se o SAP deixa eles ) serem Ativados : se
> não pode, não pode 
> > De resto é o que eu falei nas outras msgs : fazer as checagens online
> possíveis, instalar/rodar os utilitários de banco que indiquei, E continuar
> com o trabalho de check de harwadre E de software, em todos os níveis (ie,
> fornecedores de hardware, admins de SO, Suporte de banco, e de Aplicação)
> 
> >
> > []s
> >
> > Chiappa
> >
> > --- Em oracle_br@yahoogrupos.com.br, "Carlos Alfredo M. Menezes"
>  escreveu
> > >
> > > Chiappa,
> > >
> > > O parâmetro db_block_checksum é ativado por default no SAP, como disse,
> ele trabalha com parâmetros muito específicos, tem inclusive um relatório
> que checa se os parâmetros corretos estão ativados, mostra os que devem ser
> desativados, etc. Esse relatório roda com um arquivo de script que é
> atualizado mensalmente pela SAP. Como disse é muito diferente de outros
> sistemas que já trabalhei.
> > >
> > >
> > > Abraços,
> > >
> > > Carlos Alfredo M. de Menezes
> > >
> > >
> > >
> > > -Mensagem original-
> > > De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br]
> Em nome de José Laurindo
> > > Enviada em: terça-feira, 26 de abril de 2011 18:22
> > > Para: oracle_br@yahoogrupos.com.br
> > > Assunto: Re: RES: RES: Res: [oracle_br] Corrupção de dados
> > >
> > > Ah, e um pontinho adicional : enquanto a root cause da corrupção não é
> descoberta, avalie a possibilidade de ativar os recursos de checksum de
> blocos do bd Oracle (ie, os parâmetros DB_BLOCK_CHECKING, DB_BLOCK_CHECKSUM
> e similares) - eles impõem um overhead, que pode ser até de uns 10% (depende
> do caso,

Re: RES: RES: Res: [oracle_br] Corrupção de dados

2011-04-26 Por tôpico José Laurindo
ndados pelo fabricante de banco.
> 
> >
> > 4- Já está aberta uma investigação como os administradores de
> > hardware/SO/Storage para identificarem o problema.
> 
> OK, eu só recomendo :
> 
> a. seja ESPECÍFICO , não adianta de PATAVINA vc virar pros caras e dizer "ó, 
> faz um check aí", vc TEM que Explicitamente dizer : recebi um erro de bloco 
> corrupto tal no arquivo tal do servidor tal no filesystem tal, bloco esse 
> usado pelo aplicativo banco de dados Oracle, que roda no account aix tal - 
> por favor, fazer análise RIGOROSA das mensagens do sistema, dos logs , dos 
> arqs de erro , etc, procurando por Evidências de falha no software 
> (SO/drivers/firmware) e/ou no hardware - e se vc souber o nome dos 
> utilitários aix referentes a isso (tais como dmesg, errpt, etc, etc) cite 
> também... 
>  Já pro pessoal que vai fazer o teste de hardware,novamente, seja Explícito : 
> explica/evidencia pra eles que vc RECEBEU a msg de bloco corrupto , E que o 
> software que vc usa (banco de dados Oracle) primeiro lê o bloco do disco, 
> depois o altera em memória , se preciso envia dados via rede pro cliente e 
> finalmente depois recebe eventuais dados e os gravam no bloco, que vai pro 
> disco :  assim sendo PODE SER que seja falha em disco corrompendo o que foi 
> lido/gravado, PODE SER que seja falha nalgum pente de memória, alterando 
> bits/bytes do que vai ser gravado, PODE SER que seja falha de rede, 
> enviando/recebendo algum bit/byte alterado... Por isso que vc quer um teste 
> PROFUNDO de hardware - esses softwares de teste de hardware fazem justamente 
> isso, gravam uma série determinada de bytes em cada posição da memória, 
> depois fazem gravações em disco, e conferem bit-a-bit o que foi 
> lido/gravado... No meu tempo de sysadmin AIX (com a venerável versão 4.x em 
> RISC) já vinha junto com o servidor um CD com softwares do tipo, aí bastava 
> vc bootar o server com ele em modo monousuário e seguir o menu : não sei como 
> está hoje, mas o que vc quer é isso, é um teste PROFUNDO comprovando que o 
> hardware está OK...
>   
> 
> b. se quiser vc pode instalar e rodar (até em modo ONLINE mesmo com bd ativo) 
> a tool Oracle chamada RDA, ela já faz a coleta dos logs todos do banco E da 
> maioria dos logs do SO, e apresenta depois isso numa página web bonitinha... 
> Checa no metalink que vc a acha... 
> 
> c. Outras tools Oracle que vc pode baixar do metalink são :
> 
>  => OSWatcher :  ele roda alguns comandos unix (tipo iostat, vmstat, sar) 
> automaticamente com a frequência que vc indicar e depois gera um relatório - 
> a idéia aqui é mais ter uma "carga programada", ter o servidor sendo medido 
> periodicamente , há chances de que eventuais bugs/falhas de hardware causem 
> diferenças nas medições... Não é chance grande mas a tool é de grátis e não 
> impõe quase nada de overhead, então é usar sem pensar duas vezes
>  
>  => Cluster Healthcheck : vc afaik não diz, mas se for RAC vc pode baixar & 
> usar esse cara, ele faz uma checagem geral do cluster - não é incomum vc ver 
> issues estranhas no banco por causa dalgum software externo que seja 
> requerido pela tua versão/ambiente/instalação, vale a checagem
>  
>   []s
>   
> Chiappa
> 
> 
> --- Em oracle_br@yahoogrupos.com.br, "Carlos Alfredo M. Menezes" 
>  escreveu
> >
> > Bom dia Chiappa e a todos da lista.
> > 
> > Obrigado pelas considerações, mas ainda estou com algumas dúvidas 
> > conceituais:
> > 
> > 1- Se o RMAN só detecta problemas físicos, ele é útil para resolver 
> > corrupções lógicas ?, ou seja, o rman continua sendo executado sem 
> > problemas, se eu fizer um recvovery a partir deste backup, ele consegue 
> > corrigir a tabela corrompida apenas no nível lógico?
> > 
> > 2- Infelizmente não consigo rodar o dbv com a instância no ar, o AIX 6.1 
> > com Oracle 10g e JSF2, está montando as partições onde estão os datafiles 
> > em modo exclusivo, tenho que pedir para montar estas partições com a opção 
> > -cio, já tenho a nota explicando isso;
> > 
> > 3- O brtools é a ferramenta da SAP para fazer entre outras coisas 
> > backup/Restore de base de dados Oracle, inclusive integrado com o RMAN, 
> > como no meu caso, mas não suporta todas as operações possíveis de se fazer 
> > como no RMAN diretamente.
> > 
> > 4- Já está aberta uma investigação como os administradores de 
> > hardware/SO/Storage para identificarem o problema.
> > 
> > Abraços.
> > 
> > Carlos Alfredo M. de Menezes
> > 
> > 
> > -Mensagem original-
> > De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em 

Re: RES: RES: Res: [oracle_br] Corrupção de dados

2011-04-26 Por tôpico José Laurindo
g de bloco corrupto , E que o 
software que vc usa (banco de dados Oracle) primeiro lê o bloco do disco, 
depois o altera em memória , se preciso envia dados via rede pro cliente e 
finalmente depois recebe eventuais dados e os gravam no bloco, que vai pro 
disco :  assim sendo PODE SER que seja falha em disco corrompendo o que foi 
lido/gravado, PODE SER que seja falha nalgum pente de memória, alterando 
bits/bytes do que vai ser gravado, PODE SER que seja falha de rede, 
enviando/recebendo algum bit/byte alterado... Por isso que vc quer um teste 
PROFUNDO de hardware - esses softwares de teste de hardware fazem justamente 
isso, gravam uma série determinada de bytes em cada posição da memória, depois 
fazem gravações em disco, e conferem bit-a-bit o que foi lido/gravado... No meu 
tempo de sysadmin AIX (com a venerável versão 4.x em RISC) já vinha junto com o 
servidor um CD com softwares do tipo, aí bastava vc bootar o server com ele em 
modo monousuário e seguir o menu : não sei como está hoje, mas o que vc quer é 
isso, é um teste PROFUNDO comprovando que o hardware está OK...
  

b. se quiser vc pode instalar e rodar (até em modo ONLINE mesmo com bd ativo) a 
tool Oracle chamada RDA, ela já faz a coleta dos logs todos do banco E da 
maioria dos logs do SO, e apresenta depois isso numa página web bonitinha... 
Checa no metalink que vc a acha... 

c. Outras tools Oracle que vc pode baixar do metalink são :

 => OSWatcher :  ele roda alguns comandos unix (tipo iostat, vmstat, sar) 
automaticamente com a frequência que vc indicar e depois gera um relatório - a 
idéia aqui é mais ter uma "carga programada", ter o servidor sendo medido 
periodicamente , há chances de que eventuais bugs/falhas de hardware causem 
diferenças nas medições... Não é chance grande mas a tool é de grátis e não 
impõe quase nada de overhead, então é usar sem pensar duas vezes
 
 => Cluster Healthcheck : vc afaik não diz, mas se for RAC vc pode baixar & 
usar esse cara, ele faz uma checagem geral do cluster - não é incomum vc ver 
issues estranhas no banco por causa dalgum software externo que seja requerido 
pela tua versão/ambiente/instalação, vale a checagem
 
  []s
  
Chiappa


--- Em oracle_br@yahoogrupos.com.br, "Carlos Alfredo M. Menezes" 
 escreveu
>
> Bom dia Chiappa e a todos da lista.
> 
> Obrigado pelas considerações, mas ainda estou com algumas dúvidas conceituais:
> 
> 1- Se o RMAN só detecta problemas físicos, ele é útil para resolver 
> corrupções lógicas ?, ou seja, o rman continua sendo executado sem problemas, 
> se eu fizer um recvovery a partir deste backup, ele consegue corrigir a 
> tabela corrompida apenas no nível lógico?
> 
> 2- Infelizmente não consigo rodar o dbv com a instância no ar, o AIX 6.1 com 
> Oracle 10g e JSF2, está montando as partições onde estão os datafiles em modo 
> exclusivo, tenho que pedir para montar estas partições com a opção -cio, já 
> tenho a nota explicando isso;
> 
> 3- O brtools é a ferramenta da SAP para fazer entre outras coisas 
> backup/Restore de base de dados Oracle, inclusive integrado com o RMAN, como 
> no meu caso, mas não suporta todas as operações possíveis de se fazer como no 
> RMAN diretamente.
> 
> 4- Já está aberta uma investigação como os administradores de 
> hardware/SO/Storage para identificarem o problema.
> 
> Abraços.
> 
> Carlos Alfredo M. de Menezes
> 
> 
> -Mensagem original-----
> De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em 
> nome de José Laurindo
> Enviada em: segunda-feira, 25 de abril de 2011 20:45
> Para: oracle_br@yahoogrupos.com.br
> Assunto: Re: RES: Res: [oracle_br] Corrupção de dados
> 
> Carlos, xo comentar em cima de alguns pontos :
> 
> - "Até onde eu sei, o rman faz uma verificação durante o backup e até então 
> eu confiava exclusivamente nele para me reportar prováveis problemas de 
> corrupção. "
> 
> => Bad, very Very Bad move, my friend : veja, o conceito do RMAN é que ele 
> copia blocos do disco, então (é óbvio) ele verifica se o bloco foi lido 
> corretamente, ele basicamente detecta corrupção FÍSICA portanto - se há 
> corrupção lógica (ie, o bloco tá legível, mas digamos, por bug ou qquer 
> problema o cabeçalho do bloco aponta prum lugar inválido, ou o dicionário de 
> dados não registra um objeto corretamente, enfim) via de regra o RMAN  
> não consegue  detectar isso... É Por Isso que a nota-mãe do metalink 
> sobre detecção de corrupção (Best Practices for Avoiding and Detecting 
> Corruption , Doc ID 428570.1) Recomenda vc além do backup RMAN fazer um DBV, 
> um ANALYZE de objetos (o ANALYZE é Totalmente Obsoleto pra coleta de 
> estatísticas, mas COMPLETAMENTE necessário e válido para análise de estrutura 
> de objetos), fazer um export... A idéia do export , inclusive, é e

Re: RES: RES: Res: [oracle_br] Corrupção de dados

2011-04-26 Por tôpico Neto Longhi
cara posso estar falando besteira, mas vc ja deu um select na dba_objects??
tem esse objeto??
pq o erro que ta dando, objeto inexistente, entao acho q ele nao ta
encontrando no dicionario.

Posso estar falando besteira. Me corrijam se eu estiver errado.

Em 26 de abril de 2011 11:22, Eliandro Jakubski
escreveu:

>
>
> Colega,
>
> o teste que funcionou "select sum(modno) from sapsr3.snap;" deve estar
> utilizando um índice.
> Verifique se existe um índice sobre esse campo (embora isso não resolva o
> seu problema!)
>
>
>
>
>
> De:
> "Carlos Alfredo M. Menezes" 
> Para:
> "oracle_br@yahoogrupos.com.br" 
> Data:
> 26/04/2011 11:17
> Assunto:
> RES: RES: Res: [oracle_br] Corrupção de dados
>
>
>
>
> Colega,
> Esse teste não tinha feito, tentei e nada, veja um que consigo e o que dá
> erro:
>
> SQL> desc sapsr3.snap
> Name Null? Type
> - 
> 
> DATUM NOT NULL VARCHAR2(24)
> UZEIT NOT NULL VARCHAR2(18)
> AHOST NOT NULL VARCHAR2(96)
> UNAME NOT NULL VARCHAR2(36)
> MANDT NOT NULL VARCHAR2(9)
> MODNO NOT NULL NUMBER(10)
> SEQNO NOT NULL VARCHAR2(9)
> XHOLD NOT NULL VARCHAR2(3)
> FLIST NOT NULL VARCHAR2(600)
> FLIST02 NOT NULL VARCHAR2(600)
> FLIST03 NOT NULL VARCHAR2(600)
> FLIST04 NOT NULL VARCHAR2(600)
> FLIST05 NOT NULL VARCHAR2(600)
> FLIST06 NOT NULL VARCHAR2(600)
> FLIST07 NOT NULL VARCHAR2(600)
> FLIST08 NOT NULL VARCHAR2(600)
>
> SQL> select sum(modno) from sapsr3.snap;
>
> SUM(MODNO)
> --
> 24022
>
> SQL> create table teste as select * from sapsr3.snap;
> create table teste as select * from sapsr3.snap
> *
> ERROR at line 1:
> ORA-08103: object no longer exists
>
> Att,
>
> Carlos Alfredo M. de Menezes
> Analista de Suporte Sr.
> (82) 3217-2828 / 9921-0603
>
> -Mensagem original-----
> De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em
> nome de Marcelo Cauduro
> Enviada em: terça-feira, 26 de abril de 2011 11:11
> Para: oracle_br@yahoogrupos.com.br
> Assunto: Re: RES: Res: [oracle_br] Corrupção de dados
>
> Você menciona que os selects retornam ok, então você consegue dar um:
>
> CREATE TABLE TESTE AS
> SELECT * FROM XX;
>
> 2011/4/26 Carlos Alfredo M. Menezes 
>
> >
> >
> > Não colega, tentativa de export também dá o mesmo erro. Mas tentei
> > vários SQL´s nesta mesma tabela e todos retornam sem problemas. Curioso.
> >
> > Att,
> >
> > Carlos Alfredo M. de Menezes
> > Analista de Suporte Sr.
> > (82) 3217-2828 / 9921-0603
> >
> >
> >
> > -Mensagem original-
> > De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br]
> > Em nome de David Ricardo Enviada em: terça-feira, 26 de abril de 2011
> > 11:00
> > Para: oracle_br@yahoogrupos.com.br
> > Assunto: Re: RES: Res: [oracle_br] Corrupção de dados
> >
> > Carlos,
> > Você consegue exportar essa tabela apenas?
> >
> > Caso consiga exporta-la por completo, sugiro que o faça e recrie-a ,
> > para que ele realoque o objeto em outro segement block.
> >
> > Abraço
> >
> > Em 26 de abril de 2011 10:52, Carlos Alfredo M. Menezes <
> > carlos.mene...@usinacoruripe.com.br> escreveu:
> >
> > >
> > >
> > > Caro colega, bom dia.
> > >
> > > Obrigado pela dica, tentei fazer o procedimento, mas não estou tendo
> > > sucesso em fazer a visão v$database_block_corruption ser populada.
> > > Veja como
> > > fiz:
> > >
> > > sapdtc101:orasm0 2> rman target = /
> > >
> > > Recovery Manager: Release 10.2.0.4.0 - Production on Tue Apr 26
> > > 10:19:14
> > > 2011
> > >
> > > Copyright (c) 1982, 2007, Oracle. All rights reserved.
> > >
> > > connected to target database: SM0 (DBID=1149775909)
> > >
> > > RMAN> backup validate check logical database;
> > >
> > > Starting backup at 26-APR-11
> > > using target database control file instead of recovery catalog
> > > allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=125
> > > devtype=DISK channel ORA_DISK_1: starting full datafile backupset
> > > channel
> > > ORA_DISK_1: specifying datafile(s) in backupset input datafile
> > > fno=9 name=/oracle/SM0/sapdata2/sr3_6/sr3.data6
> > > input datafile fno=00012 name=/oracle/SM0/sapdata2/sr3_9/sr3.data9
> > > input datafile fno=4 name=/oracle/SM0/sapdata2/sr3_1/sr3.data1
> > > input data

Re: RES: Res: [oracle_br] Corrupção de dados

2011-04-26 Por tôpico Marcelo Cauduro
Você menciona que os selects retornam ok, então você consegue dar um:

  CREATE TABLE TESTE AS
 SELECT * FROM XX;

2011/4/26 Carlos Alfredo M. Menezes 

>
>
> Não colega, tentativa de export também dá o mesmo erro. Mas tentei vários
> SQL´s nesta mesma tabela e todos retornam sem problemas. Curioso.
>
> Att,
>
> Carlos Alfredo M. de Menezes
> Analista de Suporte Sr.
> (82) 3217-2828 / 9921-0603
>
>
>
> -Mensagem original-
> De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em
> nome de David Ricardo
> Enviada em: terça-feira, 26 de abril de 2011 11:00
> Para: oracle_br@yahoogrupos.com.br
> Assunto: Re: RES: Res: [oracle_br] Corrupção de dados
>
> Carlos,
> Você consegue exportar essa tabela apenas?
>
> Caso consiga exporta-la por completo, sugiro que o faça e recrie-a , para
> que ele realoque o objeto em outro segement block.
>
> Abraço
>
> Em 26 de abril de 2011 10:52, Carlos Alfredo M. Menezes <
> carlos.mene...@usinacoruripe.com.br> escreveu:
>
> >
> >
> > Caro colega, bom dia.
> >
> > Obrigado pela dica, tentei fazer o procedimento, mas não estou tendo
> > sucesso em fazer a visão v$database_block_corruption ser populada.
> > Veja como
> > fiz:
> >
> > sapdtc101:orasm0 2> rman target = /
> >
> > Recovery Manager: Release 10.2.0.4.0 - Production on Tue Apr 26
> > 10:19:14
> > 2011
> >
> > Copyright (c) 1982, 2007, Oracle. All rights reserved.
> >
> > connected to target database: SM0 (DBID=1149775909)
> >
> > RMAN> backup validate check logical database;
> >
> > Starting backup at 26-APR-11
> > using target database control file instead of recovery catalog
> > allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=125 devtype=DISK
> > channel ORA_DISK_1: starting full datafile backupset channel
> > ORA_DISK_1: specifying datafile(s) in backupset input datafile
> > fno=9 name=/oracle/SM0/sapdata2/sr3_6/sr3.data6
> > input datafile fno=00012 name=/oracle/SM0/sapdata2/sr3_9/sr3.data9
> > input datafile fno=4 name=/oracle/SM0/sapdata2/sr3_1/sr3.data1
> > input datafile fno=6 name=/oracle/SM0/sapdata2/sr3_3/sr3.data3
> > input datafile fno=5 name=/oracle/SM0/sapdata2/sr3_2/sr3.data2
> > input datafile fno=8 name=/oracle/SM0/sapdata2/sr3_5/sr3.data5
> > input datafile fno=7 name=/oracle/SM0/sapdata2/sr3_4/sr3.data4
> > input datafile fno=00010 name=/oracle/SM0/sapdata2/sr3_7/sr3.data7
> > input datafile fno=00011 name=/oracle/SM0/sapdata2/sr3_8/sr3.data8
> > input datafile fno=00023 name=/oracle/SM0/sapdata2/sr3_12/sr3.data12
> > input datafile fno=00022 name=/oracle/SM0/sapdata2/sr3_11/sr3.data11
> > input datafile fno=00013 name=/oracle/SM0/sapdata2/sr3_10/sr3.data10
> > input datafile fno=00014
> > name=/oracle/SM0/sapdata3/sr3701_1/sr3701.data1
> > input datafile fno=00015
> > name=/oracle/SM0/sapdata3/sr3701_2/sr3701.data2
> > input datafile fno=00016
> > name=/oracle/SM0/sapdata3/sr3701_3/sr3701.data3
> > input datafile fno=00017
> > name=/oracle/SM0/sapdata3/sr3701_4/sr3701.data4
> > input datafile fno=2 name=/oracle/SM0/sapdata1/undo_1/undo.data1
> > input datafile fno=00024 name=/oracle/SM0/sapdata2/sr3_13/sr3.data13
> > input datafile fno=00019 name=/oracle/SM0/sapdata4/sr3db_1/sr3db.data1
> > input datafile fno=00020 name=/oracle/SM0/sapdata4/sr3db_2/sr3db.data2
> > input datafile fno=00021 name=/oracle/SM0/sapdata4/sr3db_3/sr3db.data3
> > input datafile fno=1
> > name=/oracle/SM0/sapdata1/system_1/system.data1
> > input datafile fno=3
> > name=/oracle/SM0/sapdata1/sysaux_1/sysaux.data1
> > input datafile fno=00018
> > name=/oracle/SM0/sapdata4/sr3usr_1/sr3usr.data1
> > channel ORA_DISK_1: backup set complete, elapsed time: 00:12:26
> > channel ORA_DISK_1: starting full datafile backupset channel
> > ORA_DISK_1: specifying datafile(s) in backupset including current
> > control file in backupset including current SPFILE in backupset
> > channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
> > Finished backup at 26-APR-11
> >
> > Após isso, continua sem registrar nenhuma corrupção lógica:
> >
> > SQL> select * from v$database_block_corruption;
> >
> > no rows selected
> >
> > Mas se tento fazer o validate na tabela com problemas:
> >
> > SQL> analyze table sapsr3.snap validate structure;
> > analyze table sapsr3.snap validate structure
> > *
> > ERROR at line 1:
> > ORA-08103: object no longer exists
> >
> > Mas alguma sugestão??
> &g

Re: RES: Res: [oracle_br] Corrupção de dados

2011-04-26 Por tôpico David Ricardo
Carlos,
Você consegue exportar essa tabela apenas?

Caso consiga exporta-la por completo, sugiro que o faça e recrie-a , para
que ele realoque o objeto em outro segement block.

Abraço

Em 26 de abril de 2011 10:52, Carlos Alfredo M. Menezes <
carlos.mene...@usinacoruripe.com.br> escreveu:

>
>
> Caro colega, bom dia.
>
> Obrigado pela dica, tentei fazer o procedimento, mas não estou tendo
> sucesso em fazer a visão v$database_block_corruption ser populada. Veja como
> fiz:
>
> sapdtc101:orasm0 2> rman target = /
>
> Recovery Manager: Release 10.2.0.4.0 - Production on Tue Apr 26 10:19:14
> 2011
>
> Copyright (c) 1982, 2007, Oracle. All rights reserved.
>
> connected to target database: SM0 (DBID=1149775909)
>
> RMAN> backup validate check logical database;
>
> Starting backup at 26-APR-11
> using target database control file instead of recovery catalog
> allocated channel: ORA_DISK_1
> channel ORA_DISK_1: sid=125 devtype=DISK
> channel ORA_DISK_1: starting full datafile backupset
> channel ORA_DISK_1: specifying datafile(s) in backupset
> input datafile fno=9 name=/oracle/SM0/sapdata2/sr3_6/sr3.data6
> input datafile fno=00012 name=/oracle/SM0/sapdata2/sr3_9/sr3.data9
> input datafile fno=4 name=/oracle/SM0/sapdata2/sr3_1/sr3.data1
> input datafile fno=6 name=/oracle/SM0/sapdata2/sr3_3/sr3.data3
> input datafile fno=5 name=/oracle/SM0/sapdata2/sr3_2/sr3.data2
> input datafile fno=8 name=/oracle/SM0/sapdata2/sr3_5/sr3.data5
> input datafile fno=7 name=/oracle/SM0/sapdata2/sr3_4/sr3.data4
> input datafile fno=00010 name=/oracle/SM0/sapdata2/sr3_7/sr3.data7
> input datafile fno=00011 name=/oracle/SM0/sapdata2/sr3_8/sr3.data8
> input datafile fno=00023 name=/oracle/SM0/sapdata2/sr3_12/sr3.data12
> input datafile fno=00022 name=/oracle/SM0/sapdata2/sr3_11/sr3.data11
> input datafile fno=00013 name=/oracle/SM0/sapdata2/sr3_10/sr3.data10
> input datafile fno=00014 name=/oracle/SM0/sapdata3/sr3701_1/sr3701.data1
> input datafile fno=00015 name=/oracle/SM0/sapdata3/sr3701_2/sr3701.data2
> input datafile fno=00016 name=/oracle/SM0/sapdata3/sr3701_3/sr3701.data3
> input datafile fno=00017 name=/oracle/SM0/sapdata3/sr3701_4/sr3701.data4
> input datafile fno=2 name=/oracle/SM0/sapdata1/undo_1/undo.data1
> input datafile fno=00024 name=/oracle/SM0/sapdata2/sr3_13/sr3.data13
> input datafile fno=00019 name=/oracle/SM0/sapdata4/sr3db_1/sr3db.data1
> input datafile fno=00020 name=/oracle/SM0/sapdata4/sr3db_2/sr3db.data2
> input datafile fno=00021 name=/oracle/SM0/sapdata4/sr3db_3/sr3db.data3
> input datafile fno=1 name=/oracle/SM0/sapdata1/system_1/system.data1
> input datafile fno=3 name=/oracle/SM0/sapdata1/sysaux_1/sysaux.data1
> input datafile fno=00018 name=/oracle/SM0/sapdata4/sr3usr_1/sr3usr.data1
> channel ORA_DISK_1: backup set complete, elapsed time: 00:12:26
> channel ORA_DISK_1: starting full datafile backupset
> channel ORA_DISK_1: specifying datafile(s) in backupset
> including current control file in backupset
> including current SPFILE in backupset
> channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
> Finished backup at 26-APR-11
>
> Após isso, continua sem registrar nenhuma corrupção lógica:
>
> SQL> select * from v$database_block_corruption;
>
> no rows selected
>
> Mas se tento fazer o validate na tabela com problemas:
>
> SQL> analyze table sapsr3.snap validate structure;
> analyze table sapsr3.snap validate structure
> *
> ERROR at line 1:
> ORA-08103: object no longer exists
>
> Mas alguma sugestão??
>
> Att,
>
>
> Carlos Alfredo M. de Menezes
> Analista de Suporte Sr.
>
>
>
> -----Mensagem original-
> De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em
> nome de David Ricardo
> Enviada em: terça-feira, 26 de abril de 2011 09:52
> Para: oracle_br@yahoogrupos.com.br
> Assunto: Re: RES: Res: [oracle_br] Corrupção de dados
>
> Carlos bom dia, tudo bem?
> Já solucionou seu problema?
>
> Caso não tenha solucionado ainda, dê uma passadinha neste endereço, lá tem
> um passo a passo de como usar o BMR via RMAN, talvez isso lhe ajude a
> elucidar algumas coisas.
>
> http://databaseguard.blogspot.com/2009/08/rman-bmr-block-media-recover.html
>
> No mais se precisar de ajuda, meu email é drb.rica...@gmail.com
>
> Abraço.
>
> Em 26 de abril de 2011 08:16, Carlos Alfredo M. Menezes <
> carlos.mene...@usinacoruripe.com.br> escreveu:
>
> >
> >
> > Bom dia Chiappa e a todos da lista.
> >
> > Obrigado pelas considerações, mas ainda estou com algumas dúvidas
> > conceituais:
> >
> > 1- Se o RMAN só detecta problemas físicos, ele é útil para resolver
> > c

RES: RES: Res: [oracle_br] Corrupção de dados

2011-04-26 Por tôpico Carlos Alfredo M. Menezes
Caro colega, bom dia.

Obrigado pela dica, tentei fazer o procedimento, mas não estou tendo sucesso em 
fazer a visão v$database_block_corruption ser populada. Veja como fiz:

sapdtc101:orasm0 2> rman target = /

Recovery Manager: Release 10.2.0.4.0 - Production on Tue Apr 26 10:19:14 2011

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

connected to target database: SM0 (DBID=1149775909)

RMAN> backup validate check logical database;

Starting backup at 26-APR-11
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=125 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=9 name=/oracle/SM0/sapdata2/sr3_6/sr3.data6
input datafile fno=00012 name=/oracle/SM0/sapdata2/sr3_9/sr3.data9
input datafile fno=4 name=/oracle/SM0/sapdata2/sr3_1/sr3.data1
input datafile fno=6 name=/oracle/SM0/sapdata2/sr3_3/sr3.data3
input datafile fno=5 name=/oracle/SM0/sapdata2/sr3_2/sr3.data2
input datafile fno=8 name=/oracle/SM0/sapdata2/sr3_5/sr3.data5
input datafile fno=7 name=/oracle/SM0/sapdata2/sr3_4/sr3.data4
input datafile fno=00010 name=/oracle/SM0/sapdata2/sr3_7/sr3.data7
input datafile fno=00011 name=/oracle/SM0/sapdata2/sr3_8/sr3.data8
input datafile fno=00023 name=/oracle/SM0/sapdata2/sr3_12/sr3.data12
input datafile fno=00022 name=/oracle/SM0/sapdata2/sr3_11/sr3.data11
input datafile fno=00013 name=/oracle/SM0/sapdata2/sr3_10/sr3.data10
input datafile fno=00014 name=/oracle/SM0/sapdata3/sr3701_1/sr3701.data1
input datafile fno=00015 name=/oracle/SM0/sapdata3/sr3701_2/sr3701.data2
input datafile fno=00016 name=/oracle/SM0/sapdata3/sr3701_3/sr3701.data3
input datafile fno=00017 name=/oracle/SM0/sapdata3/sr3701_4/sr3701.data4
input datafile fno=2 name=/oracle/SM0/sapdata1/undo_1/undo.data1
input datafile fno=00024 name=/oracle/SM0/sapdata2/sr3_13/sr3.data13
input datafile fno=00019 name=/oracle/SM0/sapdata4/sr3db_1/sr3db.data1
input datafile fno=00020 name=/oracle/SM0/sapdata4/sr3db_2/sr3db.data2
input datafile fno=00021 name=/oracle/SM0/sapdata4/sr3db_3/sr3db.data3
input datafile fno=1 name=/oracle/SM0/sapdata1/system_1/system.data1
input datafile fno=3 name=/oracle/SM0/sapdata1/sysaux_1/sysaux.data1
input datafile fno=00018 name=/oracle/SM0/sapdata4/sr3usr_1/sr3usr.data1
channel ORA_DISK_1: backup set complete, elapsed time: 00:12:26
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset
including current SPFILE in backupset
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 26-APR-11

Após isso, continua sem registrar nenhuma corrupção lógica:

SQL> select * from v$database_block_corruption;

no rows selected

Mas se tento fazer o validate na tabela com problemas:

SQL> analyze table sapsr3.snap validate structure;
analyze table sapsr3.snap validate structure
*
ERROR at line 1:
ORA-08103: object no longer exists

Mas alguma sugestão??

Att,


Carlos Alfredo M. de Menezes
Analista de Suporte Sr.



-Mensagem original-
De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome 
de David Ricardo
Enviada em: terça-feira, 26 de abril de 2011 09:52
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: Res: [oracle_br] Corrupção de dados

Carlos bom dia, tudo bem?
Já solucionou seu problema?

Caso não tenha solucionado ainda, dê uma passadinha neste endereço, lá tem um 
passo a passo de como usar o BMR via RMAN, talvez isso lhe ajude a elucidar 
algumas coisas.

http://databaseguard.blogspot.com/2009/08/rman-bmr-block-media-recover.html

No mais se precisar de ajuda, meu email é drb.rica...@gmail.com

Abraço.

Em 26 de abril de 2011 08:16, Carlos Alfredo M. Menezes < 
carlos.mene...@usinacoruripe.com.br> escreveu:

>
>
> Bom dia Chiappa e a todos da lista.
>
> Obrigado pelas considerações, mas ainda estou com algumas dúvidas
> conceituais:
>
> 1- Se o RMAN só detecta problemas físicos, ele é útil para resolver 
> corrupções lógicas ?, ou seja, o rman continua sendo executado sem 
> problemas, se eu fizer um recvovery a partir deste backup, ele 
> consegue corrigir a tabela corrompida apenas no nível lógico?
>
> 2- Infelizmente não consigo rodar o dbv com a instância no ar, o AIX 
> 6.1 com Oracle 10g e JSF2, está montando as partições onde estão os 
> datafiles em modo exclusivo, tenho que pedir para montar estas 
> partições com a opção -cio, já tenho a nota explicando isso;
>
> 3- O brtools é a ferramenta da SAP para fazer entre outras coisas 
> backup/Restore de base de dados Oracle, inclusive integrado com o 
> RMAN, como no meu caso, mas não suporta todas as operações possíveis 
> de se fazer como no RMAN diretamente.
>
> 4- Já está aberta uma investigação como os administradores de 
&

Re: RES: Res: [oracle_br] Corrupção de dados

2011-04-26 Por tôpico David Ricardo
Carlos bom dia, tudo bem?
Já solucionou seu problema?

Caso não tenha solucionado ainda, dê uma passadinha neste endereço, lá tem
um passo a passo de como usar o BMR via RMAN, talvez isso lhe ajude a
elucidar algumas coisas.

http://databaseguard.blogspot.com/2009/08/rman-bmr-block-media-recover.html

No mais se precisar de ajuda, meu email é drb.rica...@gmail.com

Abraço.

Em 26 de abril de 2011 08:16, Carlos Alfredo M. Menezes <
carlos.mene...@usinacoruripe.com.br> escreveu:

>
>
> Bom dia Chiappa e a todos da lista.
>
> Obrigado pelas considerações, mas ainda estou com algumas dúvidas
> conceituais:
>
> 1- Se o RMAN só detecta problemas físicos, ele é útil para resolver
> corrupções lógicas ?, ou seja, o rman continua sendo executado sem
> problemas, se eu fizer um recvovery a partir deste backup, ele consegue
> corrigir a tabela corrompida apenas no nível lógico?
>
> 2- Infelizmente não consigo rodar o dbv com a instância no ar, o AIX 6.1
> com Oracle 10g e JSF2, está montando as partições onde estão os datafiles em
> modo exclusivo, tenho que pedir para montar estas partições com a opção
> -cio, já tenho a nota explicando isso;
>
> 3- O brtools é a ferramenta da SAP para fazer entre outras coisas
> backup/Restore de base de dados Oracle, inclusive integrado com o RMAN, como
> no meu caso, mas não suporta todas as operações possíveis de se fazer como
> no RMAN diretamente.
>
> 4- Já está aberta uma investigação como os administradores de
> hardware/SO/Storage para identificarem o problema.
>
> Abraços.
>
>
> Carlos Alfredo M. de Menezes
>
> -Mensagem original-
> De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em
> nome de José Laurindo
> Enviada em: segunda-feira, 25 de abril de 2011 20:45
>
> Para: oracle_br@yahoogrupos.com.br
> Assunto: Re: RES: Res: [oracle_br] Corrupção de dados
>
>
> Carlos, xo comentar em cima de alguns pontos :
>
> - "Até onde eu sei, o rman faz uma verificação durante o backup e até então
> eu confiava exclusivamente nele para me reportar prováveis problemas de
> corrupção. "
>
> => Bad, very Very Bad move, my friend : veja, o conceito do RMAN é que ele
> copia blocos do disco, então (é óbvio) ele verifica se o bloco foi lido
> corretamente, ele basicamente detecta corrupção FÍSICA portanto - se há
> corrupção lógica (ie, o bloco tá legível, mas digamos, por bug ou qquer
> problema o cabeçalho do bloco aponta prum lugar inválido, ou o dicionário de
> dados não registra um objeto corretamente, enfim) via de regra o RMAN 
> não consegue  detectar isso... É Por Isso que a nota-mãe do metalink
> sobre detecção de corrupção (Best Practices for Avoiding and Detecting
> Corruption , Doc ID 428570.1) Recomenda vc além do backup RMAN fazer um DBV,
> um ANALYZE de objetos (o ANALYZE é Totalmente Obsoleto pra coleta de
> estatísticas, mas COMPLETAMENTE necessário e válido para análise de
> estrutura de objetos), fazer um export... A idéia do export , inclusive, é
> exercitar o dicionário : como nós sabemos, o RMAN só quer copiar blocos dos
> datafiles(ele não se "interessa" se aquele bloco é da tabela x ou índice y,
> ele copia os blocos do datafile que está sendo backupeado), enquanto o
> export não, ele copia Tabelas e Schemas, então (obviamente) o export ao
> contrário Precisa consultar o dicionário pra "encontrar" as
> tabelas/índices/constraints/etc a copiar...
>
> - "Realmente só pensei em fazer o dbv com a instância parada, mas como
> ainda não surgiu uma janela para tal operação, continuo na minha pesquisa."
>
> => ok, um DBV offline sempre é legal, MAS enquanto não é possível, vc Sabe
> que é totalmente possível rodar um DBV online, com o banco Ativo ??? E
> óbvio, o export é online, os ANALYZEs são online, vc tem Sim várias opções
> pra check online...
>
> - "Também pensei em fazer via RMAN o block recover, mas fiquei na dúvida se
> esse procedimento faz algum tipo de mídia recovery? Se tem algum impacto na
> disponibilidade do ambiente, e se eu posso fazer via brtools (é uma base SAP
> Solution Manager)."
>
> => Sim, claro que o RMAN faz mídia recover, ele regrava BLOCOS : o conceito
> é Direto, o que o RMAN sabe/conhece basicamente é copiar e ler BLOCOS de
> datafiles... Indisponibilidade geral isso não acarreta, mas OBVIAMENTE no
> tempinho que levar pro RMAN localizar e ler da fita/disco/whatever o bloco
> que será regravado , o objeto em questão VAI ficar inacessível.
> Quanto ao tal do brtools, não sei mas eu TOTALMENTE recomendo vc fazer
> recuperação de banco Oracle com as tools Oracle da maneira Recomendada pela
> Oracle - no caso do RMAN é usar em linha de comando o utilitário rman , com
> as variáveis ORA

RES: RES: Res: [oracle_br] Corrupção de dados

2011-04-26 Por tôpico Carlos Alfredo M. Menezes
Bom dia Chiappa e a todos da lista.

Obrigado pelas considerações, mas ainda estou com algumas dúvidas conceituais:

1- Se o RMAN só detecta problemas físicos, ele é útil para resolver corrupções 
lógicas ?, ou seja, o rman continua sendo executado sem problemas, se eu fizer 
um recvovery a partir deste backup, ele consegue corrigir a tabela corrompida 
apenas no nível lógico?

2- Infelizmente não consigo rodar o dbv com a instância no ar, o AIX 6.1 com 
Oracle 10g e JSF2, está montando as partições onde estão os datafiles em modo 
exclusivo, tenho que pedir para montar estas partições com a opção -cio, já 
tenho a nota explicando isso;

3- O brtools é a ferramenta da SAP para fazer entre outras coisas 
backup/Restore de base de dados Oracle, inclusive integrado com o RMAN, como no 
meu caso, mas não suporta todas as operações possíveis de se fazer como no RMAN 
diretamente.

4- Já está aberta uma investigação como os administradores de 
hardware/SO/Storage para identificarem o problema.

Abraços.

Carlos Alfredo M. de Menezes


-Mensagem original-
De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome 
de José Laurindo
Enviada em: segunda-feira, 25 de abril de 2011 20:45
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: Res: [oracle_br] Corrupção de dados

Carlos, xo comentar em cima de alguns pontos :

- "Até onde eu sei, o rman faz uma verificação durante o backup e até então eu 
confiava exclusivamente nele para me reportar prováveis problemas de corrupção. 
"

=> Bad, very Very Bad move, my friend : veja, o conceito do RMAN é que ele 
copia blocos do disco, então (é óbvio) ele verifica se o bloco foi lido 
corretamente, ele basicamente detecta corrupção FÍSICA portanto - se há 
corrupção lógica (ie, o bloco tá legível, mas digamos, por bug ou qquer 
problema o cabeçalho do bloco aponta prum lugar inválido, ou o dicionário de 
dados não registra um objeto corretamente, enfim) via de regra o RMAN  não 
consegue  detectar isso... É Por Isso que a nota-mãe do metalink sobre 
detecção de corrupção (Best Practices for Avoiding and Detecting Corruption , 
Doc ID 428570.1) Recomenda vc além do backup RMAN fazer um DBV, um ANALYZE de 
objetos (o ANALYZE é Totalmente Obsoleto pra coleta de estatísticas, mas 
COMPLETAMENTE necessário e válido para análise de estrutura de objetos), fazer 
um export... A idéia do export , inclusive, é exercitar o dicionário : como nós 
sabemos, o RMAN só quer copiar blocos dos datafiles(ele não se "interessa" se 
aquele bloco é da tabela x ou índice y, ele copia os blocos do datafile que 
está sendo backupeado), enquanto o export não, ele copia Tabelas e Schemas, 
então (obviamente) o export ao contrário Precisa consultar o dicionário pra 
"encontrar" as tabelas/índices/constraints/etc a copiar...

- "Realmente só pensei em fazer o dbv com a instância parada, mas como ainda 
não surgiu uma janela para tal operação, continuo na minha pesquisa."

=> ok, um DBV offline sempre é legal, MAS enquanto não é possível, vc Sabe que 
é totalmente possível rodar um DBV online, com o banco Ativo ??? E óbvio, o 
export é online, os ANALYZEs são online, vc tem Sim várias opções pra check 
online...

- "Também pensei em fazer via RMAN o block recover, mas fiquei na dúvida se 
esse procedimento faz algum tipo de mídia recovery? Se tem algum impacto na 
disponibilidade do ambiente, e se eu posso fazer via brtools (é uma base SAP 
Solution Manager)."

=> Sim, claro que o RMAN faz mídia recover, ele regrava BLOCOS : o conceito é 
Direto, o que o RMAN sabe/conhece basicamente é copiar e ler BLOCOS de 
datafiles... Indisponibilidade geral isso não acarreta, mas OBVIAMENTE no 
tempinho que levar pro RMAN localizar e ler da fita/disco/whatever o bloco que 
será regravado , o objeto em questão VAI ficar inacessível. 
 Quanto ao tal do brtools, não sei mas eu TOTALMENTE recomendo vc fazer 
recuperação de banco Oracle com as tools Oracle da maneira Recomendada pela 
Oracle - no caso do RMAN é usar em linha de comando o utilitário rman , com as 
variáveis ORACLE setadas, direitinho...
 
 
==> E Ululantemente óbvio : corrupção absolutamente *** NUNCA *** acontece por 
si, do nada - nós estamos falando de banco Oracle aqui, não de Clipper/dBASE 
que a toda hora corrompia e vc tinha que fazer rebuild... Vc TEM QUE descobrir 
a Causa da corrupção (que necessariamente será um problema de Hardware - seja 
placa-mãe, placa de rede, I/O, memória -, OU um bug , seja bug no 
firmware/drivers, nos software de banco, e/ou no aplicativo...
 Assim, se o teu ambiente é Realmente crítico, vc TEM QUE agendar uma checagem 
PROFUNDA do teu hardware, com ferramentas de análise de baixo nível do hardware 
(NÂO É só rodar um fsck e achar que tá tudo bem), procurar nos logs/msgs do 
sistema/SO por falhas, E também abrir chamados no Suporte da Oracle, do 
aplicativo E do SO...
 
 []s
 
   Chiappa
   

--- Em oracle_br@yahoogr

Re: RES: Res: [oracle_br] Corrupção de dados

2011-04-25 Por tôpico José Laurindo
Carlos, xo comentar em cima de alguns pontos :

- "Até onde eu sei, o rman faz uma verificação durante o backup e até então eu 
confiava exclusivamente nele para me reportar prováveis problemas de corrupção. 
"

=> Bad, very Very Bad move, my friend : veja, o conceito do RMAN é que ele 
copia blocos do disco, então (é óbvio) ele verifica se o bloco foi lido 
corretamente, ele basicamente detecta corrupção FÍSICA portanto - se há 
corrupção lógica (ie, o bloco tá legível, mas digamos, por bug ou qquer 
problema o cabeçalho do bloco aponta prum lugar inválido, ou o dicionário de 
dados não registra um objeto corretamente, enfim) via de regra o RMAN  não 
consegue  detectar isso... É Por Isso que a nota-mãe do metalink sobre 
detecção de corrupção (Best Practices for Avoiding and Detecting Corruption , 
Doc ID 428570.1) Recomenda vc além do backup RMAN fazer um DBV, um ANALYZE de 
objetos (o ANALYZE é Totalmente Obsoleto pra coleta de estatísticas, mas 
COMPLETAMENTE necessário e válido para análise de estrutura de objetos), fazer 
um export... A idéia do export , inclusive, é exercitar o dicionário : como nós 
sabemos, o RMAN só quer copiar blocos dos datafiles(ele não se "interessa" se 
aquele bloco é da tabela x ou índice y, ele copia os blocos do datafile que 
está sendo backupeado), enquanto o export não, ele copia Tabelas e Schemas, 
então (obviamente) o export ao contrário Precisa consultar o dicionário pra 
"encontrar" as tabelas/índices/constraints/etc a copiar...

- "Realmente só pensei em fazer o dbv com a instância parada, mas como ainda 
não surgiu uma janela para tal operação, continuo na minha pesquisa."

=> ok, um DBV offline sempre é legal, MAS enquanto não é possível, vc Sabe que 
é totalmente possível rodar um DBV online, com o banco Ativo ??? E óbvio, o 
export é online, os ANALYZEs são online, vc tem Sim várias opções pra check 
online...

- "Também pensei em fazer via RMAN o block recover, mas fiquei na dúvida se 
esse procedimento faz algum tipo de mídia recovery? Se tem algum impacto na 
disponibilidade do ambiente, e se eu posso fazer via brtools (é uma base SAP 
Solution Manager)."

=> Sim, claro que o RMAN faz mídia recover, ele regrava BLOCOS : o conceito é 
Direto, o que o RMAN sabe/conhece basicamente é copiar e ler BLOCOS de 
datafiles... Indisponibilidade geral isso não acarreta, mas OBVIAMENTE no 
tempinho que levar pro RMAN localizar e ler da fita/disco/whatever o bloco que 
será regravado , o objeto em questão VAI ficar inacessível. 
 Quanto ao tal do brtools, não sei mas eu TOTALMENTE recomendo vc fazer 
recuperação de banco Oracle com as tools Oracle da maneira Recomendada pela 
Oracle - no caso do RMAN é usar em linha de comando o utilitário rman , com as 
variáveis ORACLE setadas, direitinho...
 
 
==> E Ululantemente óbvio : corrupção absolutamente *** NUNCA *** acontece por 
si, do nada - nós estamos falando de banco Oracle aqui, não de Clipper/dBASE 
que a toda hora corrompia e vc tinha que fazer rebuild... Vc TEM QUE descobrir 
a Causa da corrupção (que necessariamente será um problema de Hardware - seja 
placa-mãe, placa de rede, I/O, memória -, OU um bug , seja bug no 
firmware/drivers, nos software de banco, e/ou no aplicativo...
 Assim, se o teu ambiente é Realmente crítico, vc TEM QUE agendar uma checagem 
PROFUNDA do teu hardware, com ferramentas de análise de baixo nível do hardware 
(NÂO É só rodar um fsck e achar que tá tudo bem), procurar nos logs/msgs do 
sistema/SO por falhas, E também abrir chamados no Suporte da Oracle, do 
aplicativo E do SO...
 
 []s
 
   Chiappa
   

--- Em oracle_br@yahoogrupos.com.br, "Carlos Alfredo M. Menezes" 
 escreveu
>
> Colega,
> Realmente só pensei em fazer o dbv com a instância parada, mas como ainda não 
> surgiu uma janela para tal operação, continuo na minha pesquisa. Fiz vários 
> SQL´s e todos retornam normalmente as linhas, isso é que está me perturbando, 
> se tentar fazer o export, dá o erro que comentei. Estou pensando em reiniciar 
> a instância, me parece que tem algum BUG a respeito.
> 
> Também pensei em fazer via RMAN o block recover, mas fiquei na dúvida se esse 
> procedimento faz algum tipo de mídia recovery? Se tem algum impacto na 
> disponibilidade do ambiente, e se eu posso fazer via brtools (é uma base SAP 
> Solution Manager).
> 
> Att,
> 
> Carlos Alfredo M. de Menezes
> Analista de Suporte Sr.
> (82) 3217-2828 / 9921-0603
> 
> 
> 
> -Mensagem original-
> De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em 
> nome de Marcus Pavan
> Enviada em: segunda-feira, 25 de abril de 2011 18:37
> Para: oracle_br@yahoogrupos.com.br
> Assunto: Res: Res: [oracle_br] Corrupção de dados
> 
> Carlos, boa tarde.
> 
> 
> Faça um SELECT na tabela, verifique se retorna as informações.
> Caso o erro persista e voc

Res: Res: [oracle_br] Corrupção de dados

2011-04-25 Por tôpico Marcus Pavan
Carlos... boa tarde.


Vai de boa, pode fazer o BLOCK RECOVER. Este processo deixará somente o BLOCO 
"parado".
Não aconselho fazer restart na instância, recupere o bloco e depois faça o 
EXPORT.


Atenciosamente,

 Marcus Pavan.





De: Diego Leite 
Para: oracle_br@yahoogrupos.com.br
Enviadas: Segunda-feira, 25 de Abril de 2011 17:54:07
Assunto: Re: Res: [oracle_br] Corrupção de dados

Carlos,

Verifique se vc tem mais algum bloco corrompido.
Vc pode tentar fazer a recuperacao de bloco.

select * from V$Database_Block_Corruption;

blockrecover datafile 6 block 258307 ;

Se for mais de um user o corruption list.

-- 
Att,


Diego Leite
DBA ORACLE
Em 25 de abril de 2011 18:37, Marcus Pavan escreveu:

>
>
> Carlos, boa tarde.
>
> Faça um SELECT na tabela, verifique se retorna as informações.
> Caso o erro persista e você tenha um BACKUP pelo RMAN, use o BLOCK RECOVER
> para
> recuperar este bloco.
> O DBV pode ser executado, porém prefiro executá-lo com o datafile em OFF,
> na
> versão 11g já está mais seguro a execução com ele online.
>
> Atenciosamente,
>
> Marcus Pavan.
>
> 
> De: MARCIO CASTRO 
>
> Para: oracle_br@yahoogrupos.com.br
> Enviadas: Segunda-feira, 25 de Abril de 2011 17:29:20
> Assunto: Res: [oracle_br] Corrupção de dados
>
>
> Carlos; você poderia utilizar o dbv no datafile/segmento? Também retorna
> erro?
>
> 
> De: Carlos Alfredo M. Menezes 
> Para: "oracle_br@yahoogrupos.com.br" 
> Enviadas: Segunda-feira, 25 de Abril de 2011 18:18:16
> Assunto: [oracle_br] Corrupção de dados
>
> Caros boa noite,
> Recebi aquele conhecido erro de corrupção:
>
> Corrupt block relative dba: 0x0183f103 (file 6, block 258307)
> Bad header found during buffer read
> Data in bad block:
> type: 2 format: 2 rdba: 0x00806981
> last change scn: 0x.0408ab74 seq: 0x27 flg: 0x04
> spare1: 0x0 spare2: 0x0 spare3: 0x0
> consistency value in tail: 0xab740227
> check value in block header: 0x617a
> computed block checksum: 0x0
> Reread of rdba: 0x0183f103 (file 6, block 258307) found valid data
>
> Rodei o sql:
> select segment_name,segment_type,owner
> from sys.dba_extents
> where file_id=(6)
> and (258307) between block_id and block_id + blocks -1;
>
> Identifiquei o segmento afetado, no caso uma tabela.
>
> O curioso é que o comando analyze table xxx validate structure continua
> dando:
> ORA-08103: object no longer exists. O mesmo acontece com o exp. Mas o
> backup via
>
> rman não reporta nenhum problema. Até onde eu sei, o rman faz uma
> verificação
> durante o backup e até então eu confiava exclusivamente nele para me
> reportar
> prováveis problemas de corrupção. Ainda não reiniciei a instância para
> tentar um
>
> novo analyze table xxx validate structure.
>
> Alguém tem uma sugestão de reparo, aparentemente o Recovery a partir do
> backup
> via rman após o problema, mesmo ele executando normalmente, pode não ser
> confiável.
>
> Detalhes da versão:
> Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
> PL/SQL Release 10.2.0.4.0 - Production
> CORE 10.2.0.4.0 Production
> TNS for IBM/AIX RISC System/6000: Version 10.2.0.4.0 - Productio
> NLSRTL Version 10.2.0.4.0 - Production
>
> Abraços a todos.
>
> Att,
> Carlos Alfredo
> Carlos Alfredo M. de Menezes
> Analista de Suporte Sr.
> (82) 3217-2828 / 9921-0603
>
> [As partes desta mensagem que não continham texto foram removidas]
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>  
>


[As partes desta mensagem que não continham texto foram removidas]





--

>Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira 
>responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--

>Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » 
>Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: 
>http://www.oraclebr.com.br/  
>

 Links do Yahoo! Grupos

[As partes desta mensagem que não continham texto foram removidas]



RES: Res: [oracle_br] Corrupção de dados

2011-04-25 Por tôpico Carlos Alfredo M. Menezes
Colega,
Realmente só pensei em fazer o dbv com a instância parada, mas como ainda não 
surgiu uma janela para tal operação, continuo na minha pesquisa. Fiz vários 
SQL´s e todos retornam normalmente as linhas, isso é que está me perturbando, 
se tentar fazer o export, dá o erro que comentei. Estou pensando em reiniciar a 
instância, me parece que tem algum BUG a respeito.

Também pensei em fazer via RMAN o block recover, mas fiquei na dúvida se esse 
procedimento faz algum tipo de mídia recovery? Se tem algum impacto na 
disponibilidade do ambiente, e se eu posso fazer via brtools (é uma base SAP 
Solution Manager).

Att,

Carlos Alfredo M. de Menezes
Analista de Suporte Sr.
(82) 3217-2828 / 9921-0603



-Mensagem original-
De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome 
de Marcus Pavan
Enviada em: segunda-feira, 25 de abril de 2011 18:37
Para: oracle_br@yahoogrupos.com.br
Assunto: Res: Res: [oracle_br] Corrupção de dados

Carlos, boa tarde.


Faça um SELECT na tabela, verifique se retorna as informações.
Caso o erro persista e você tenha um BACKUP pelo RMAN, use o BLOCK RECOVER para 
recuperar este bloco.
O DBV pode ser executado, porém prefiro executá-lo com o datafile em OFF, na 
versão 11g já está mais seguro a execução com ele online.


Atenciosamente,

 Marcus Pavan.





De: MARCIO CASTRO 
Para: oracle_br@yahoogrupos.com.br
Enviadas: Segunda-feira, 25 de Abril de 2011 17:29:20
Assunto: Res: [oracle_br] Corrupção de dados

  
Carlos; você poderia utilizar o dbv no datafile/segmento? Também retorna erro?


De: Carlos Alfredo M. Menezes 
Para: "oracle_br@yahoogrupos.com.br" 
Enviadas: Segunda-feira, 25 de Abril de 2011 18:18:16
Assunto: [oracle_br] Corrupção de dados

Caros boa noite,
Recebi aquele conhecido erro de corrupção:

Corrupt block relative dba: 0x0183f103 (file 6, block 258307) Bad header found 
during buffer read Data in bad block:
type: 2 format: 2 rdba: 0x00806981
last change scn: 0x.0408ab74 seq: 0x27 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0xab740227
check value in block header: 0x617a
computed block checksum: 0x0
Reread of rdba: 0x0183f103 (file 6, block 258307) found valid data

Rodei o sql:
select segment_name,segment_type,owner
from sys.dba_extents
where file_id=(6)
and (258307) between block_id and block_id + blocks -1;

Identifiquei o segmento afetado, no caso uma tabela. 

O curioso é que o comando analyze table xxx validate structure continua dando: 
ORA-08103: object no longer exists. O mesmo acontece com o exp. Mas o backup 
via 

rman não reporta nenhum problema. Até onde eu sei, o rman faz uma verificação 
durante o backup e até então eu confiava exclusivamente nele para me reportar 
prováveis problemas de corrupção. Ainda não reiniciei a instância para tentar 
um 

novo analyze table xxx validate structure.

Alguém tem uma sugestão de reparo, aparentemente o Recovery a partir do backup 
via rman após o problema, mesmo ele executando normalmente, pode não ser 
confiável.

Detalhes da versão:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi PL/SQL Release 
10.2.0.4.0 - Production
CORE10.2.0.4.0  Production
TNS for IBM/AIX RISC System/6000: Version 10.2.0.4.0 - Productio NLSRTL Version 
10.2.0.4.0 - Production

Abraços a todos.

Att,
Carlos Alfredo
Carlos Alfredo M. de Menezes
Analista de Suporte Sr.
(82) 3217-2828 / 9921-0603

[As partes desta mensagem que não continham texto foram removidas]


 

[As partes desta mensagem que não continham texto foram removidas]





--
>Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira 
>responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
--
>Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » 
>Procedure » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO 
>ESPAÇO! VISITE: http://www.oraclebr.com.br/

 Links do Yahoo! Grupos




Res: Res: [oracle_br] Corrupção de dados

2011-04-25 Por tôpico Marcus Pavan
Carlos, boa tarde.


Faça um SELECT na tabela, verifique se retorna as informações.
Caso o erro persista e você tenha um BACKUP pelo RMAN, use o BLOCK RECOVER para 
recuperar este bloco.
O DBV pode ser executado, porém prefiro executá-lo com o datafile em OFF, na 
versão 11g já está mais seguro a execução com ele online.


Atenciosamente,

 Marcus Pavan.





De: MARCIO CASTRO 
Para: oracle_br@yahoogrupos.com.br
Enviadas: Segunda-feira, 25 de Abril de 2011 17:29:20
Assunto: Res: [oracle_br] Corrupção de dados

  
Carlos; você poderia utilizar o dbv no datafile/segmento? Também retorna erro?


De: Carlos Alfredo M. Menezes 
Para: "oracle_br@yahoogrupos.com.br" 
Enviadas: Segunda-feira, 25 de Abril de 2011 18:18:16
Assunto: [oracle_br] Corrupção de dados

Caros boa noite,
Recebi aquele conhecido erro de corrupção:

Corrupt block relative dba: 0x0183f103 (file 6, block 258307)
Bad header found during buffer read
Data in bad block:
type: 2 format: 2 rdba: 0x00806981
last change scn: 0x.0408ab74 seq: 0x27 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0xab740227
check value in block header: 0x617a
computed block checksum: 0x0
Reread of rdba: 0x0183f103 (file 6, block 258307) found valid data

Rodei o sql:
select segment_name,segment_type,owner
from sys.dba_extents
where file_id=(6)
and (258307) between block_id and block_id + blocks -1;

Identifiquei o segmento afetado, no caso uma tabela. 

O curioso é que o comando analyze table xxx validate structure continua dando: 
ORA-08103: object no longer exists. O mesmo acontece com o exp. Mas o backup 
via 

rman não reporta nenhum problema. Até onde eu sei, o rman faz uma verificação 
durante o backup e até então eu confiava exclusivamente nele para me reportar 
prováveis problemas de corrupção. Ainda não reiniciei a instância para tentar 
um 

novo analyze table xxx validate structure.

Alguém tem uma sugestão de reparo, aparentemente o Recovery a partir do backup 
via rman após o problema, mesmo ele executando normalmente, pode não ser 
confiável.

Detalhes da versão:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE10.2.0.4.0  Production
TNS for IBM/AIX RISC System/6000: Version 10.2.0.4.0 - Productio
NLSRTL Version 10.2.0.4.0 - Production

Abraços a todos.

Att,
Carlos Alfredo
Carlos Alfredo M. de Menezes
Analista de Suporte Sr.
(82) 3217-2828 / 9921-0603

[As partes desta mensagem que não continham texto foram removidas]


 

[As partes desta mensagem que não continham texto foram removidas]