Menu de navegação

[jspaulonciParticipante]

Bom dia caros colegas, semana passada vivi a pior experiência profissional da minha vida, o Administrador Unix crashou a ASM do nosso ambiente de homologação/desenvolvimento.

Eu solicitei um disco para ser montado em file system, o ADM Unix sem querer pegou um disco da ASM e formatou.

Resultado ?, crash da ASM, perdemos 3 bases em RAC, que totalizam pouco mais de 400 gb.

Quando eu fazia um select na DBA_SEGMENTS(pelo menos foi onde sentimos o problema, já a DBA_USERS estava intáctca aparentemente) , aparecia bloco corrompido

SQL> select instance_name,status from v$instance;

INSTANCE_NAME STATUS
—————- ————
dbhml11 OPEN

SQL> select sum(bytes/1024/1024) from dba_segments;
select sum(bytes/1024/1024) from dba_segments
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-01578: ORACLE data block corrupted (file # 1, block # 166941)
ORA-01110: data file 1: ‘+DADOS/dbhml1/datafile/system.271.647802969’

Bom… isso era 10:40 do dia 12/03/2009, aí abri um chamado na Oracle mas o feeling que eu tinha era que iriamos precisar refazer todo o ambiente, e assim foi.
Como não tinhamos espelhamento na nossa ASM, tivemos que voltar tudo, aí refizemos todo o ambiente, e voltamos EXPDATAPUMP do dia anterior, fiquei 28 horas trabalhando.

Bom,,,postei isso para afim de trocarmos experiência, quando eu for solicitar um file system, antes irei fazer um select na V$ASM_DISK.

Abraços

João Paulo Spaulonci

[Rodrigo AlmeidaParticipante]

João,

Mas isso é inexperiência do ADM Unix, pq os discos são rawdevices para o ASM, e ele deveria checar pelo fdisk ou volume manager da vida os discos que teria disponível.

Até mesmo pela controladora dos discos!!! Mas, ninguem é perfeito e isso acontece! =D

Agora, tu poderia também perfeitamente, pegar o backup da produção e fazer o restore no ambiente de homologação, tu já testaria o seu backup ! XD

Abraços,
Rodrigo Almeida

[jspaulonciParticipante]

Entaum Rodrigo, gostaria realmente de validar este backup, acontece que o EXPDATAPUMP eu achei que fosse a escolha mais confiável.

Abraços

João Paulo Spaulonci

[cviniciusParticipante]

Nesse tipo de caso onde houve crash do ASM por conta do Unix, a melhor e mais confiavel solucão é o EXPDATAPUMP mesmo. Aplicar outra solução poderia propagar o problema.

Att.
Caio Vinicius

[CleitonHanzenParticipante]

Opá..

Bom, já passei uma vez por uma situação bem parecida, e fiz através de duplicate do RMAN mesmo (demorou 8hrs pra voltar 1TB) se fosse via import, ia demorar 1 dia no mínimo…

[Rodrigo AlmeidaParticipante]

Exatamente… e o bom que o +ASM foi feito para backups por RMAN…

E fora que pode usar canais, large_pool, sync_disk e etc para performance.

Mas, cada solução resolve. O importante é resolver o problema!!!

Abraços,

Rodrigo Almeida

[vieriParticipante]

jspaulonci ,

poderia postar para gente ai o script que utilizou
para o expdp e impdp?

Excelente pensamento Rodrigo,
o importante é resolver o problema,
a melhor solução é a que cada um tem mais domínio
e se sente confiante em faze-lo.

abraços.

[vieriParticipante]

Cleiton,

tem exemplos ai do duplicate RMAN ?

[]s

[CleitonHanzenParticipante]

Opá…

Fala vieri, blz?

Bom, a respeito do duplicate, depende aonde você vai fazer o duplicate, se for no mesmo servidor tem alguns cuidados extras, se for em um server diferente é mais simples.

Confirma pra mim, aonde vc vai fazer e te passo os procedimentos…. 😉

Vlws…

[]s

[Rodrigo AlmeidaParticipante]

Vou passar um exemplo de script de DUPLICATE que usamos aqui na empresa, esse duplicate é realizado entre server diferentes.

RMAN

run {
ALLOCATE AUXILIARY CHANNEL aux1 DEVICE TYPE DISK;
ALLOCATE AUXILIARY CHANNEL aux2 DEVICE TYPE DISK;
ALLOCATE AUXILIARY CHANNEL aux3 DEVICE TYPE DISK;
ALLOCATE AUXILIARY CHANNEL aux4 DEVICE TYPE DISK;
ALLOCATE AUXILIARY CHANNEL aux5 DEVICE TYPE DISK;
ALLOCATE AUXILIARY CHANNEL aux6 DEVICE TYPE DISK;
DUPLICATE TARGET DATABASE TO dm1
PFILE=/u01/app/oracle/product/10.2.0/db_1/dbs/initdm1.ora
NOFILENAMECHECK;
}

Agora, a dica para DUPLICATE entre os servers quando está usando o NFS entre eles, habilite esse parâmetro no init da instância de destino, no exemplo, a instância DM1.

event=’10298 trace name context forever, level 32′

Ele evita os erros que vai ocorrer quando realizar o RESTORE da base duplicada por causa do NFS… é um saco!!!

Abraços,
Rodrigo Almeida

[CleitonHanzenParticipante]

Olá Rodrigo.

Qual versão de Oracle você está usando? Tentei uma vez fazer duplicate somente alocando os canais “auxiliary” e deu pau dizendo que não tinha alocado canais.
Para o duplicate, não aloco canal nenhum (quando usamos o TSM ou DataProtector), mas quando uso o backup em disco aloco os dois canais (auxiliary e o normal).

Flws…

[David SiqueiraParticipante]

Cleiton a Release que usamos é a 10.2.0.3 tanto em produção quanto em ambiente D-1.

Abcs

David

[Rodrigo AlmeidaParticipante]

Cleiton,

O david que trabalha aqui comigo tb está ficando esperto com o RMAN. Aqui trabalhamos com a cópia entre as bases em disco, por isso as táticas nos eventos para o NFS.

Para o duplicate, vai ter quer ter um canal auxiliar e outro target, pois ele precisa ir na produção e pegar as informações da base e o auxiliar para restaurar esses arquivos, a quantidade de canais, você que mensura da melhor forma!

Se trabalhar com catálogo, vai precisar de estar conectado no Metadata!!! =D (Nosso caso)

Uma correção, O script que postei só tem os canais AUXILIARES porque deixamos ele dentro do bloco RUN, porém, ao executar ele, precisa me conectar no catálogo e depois um canal para o banco TARGET! Sem o target os auxliares dão problema mesmo, porque ficam perdidos!!

Abraços,
Rodrigo Almeida

[Autor]

Posts