"Erro" em processo de RESTORE de backup RMAN em novo servidor
Pessoal, já há algum tempo atrás ocorreu um "erro" bem curioso num processo
de RESTORE que os DBAs juniores tavam fazendo, vale a pena comentar que
certamente vai servir de exemplo, imagino...
Pois bem, a situação foi : o backup RMAN teve seus arqs enviados pro novo
servidor (com o mesmo SO, mesmos discos/mountpoints, etc), o software RDBMS de
mesma versão que a origem foi instalado, uma instância com o mesmo nome , dbid
idêntico ao prod origem foi setado, CONTROLFILE AUTOBACKUP FORMAT setado para o
local aonde estava o backup do controlfile, controlfile restaurado com restore
controlfile from autobackup; , banco montado com alter database mount;,
CHANNELs necessários setados, arqs de backup catalogados com catalog start
with 'pathnecessário'; , tudo com sucesso, seguindo procedimento by-the-book,
totalmente de acordo com os guias que se acha pelaí na net...
Após isso porém, o restore database; falha com uma msg genérica tipo :
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: falha do comando restore
ORA-19693: componente de backup nnnnnn jß foi incluÝdo
Aí foi o primeiro erro dos juniores : NINGUÉM confirmou A data de origem,
Como/com qual destino de catálogo e Quando/com qual periodicidade era feito o
backup na origem, e a questão era que o backup era diário, os arqs de backup
copiados eram de dois dias anteriores,na origem o backup era feito para
controlfile E já existia um backup feito há um dia atrás, POSTERIOR ao backup
copiado... Aí, LOGICAMENTE ao se resturar o controlfile de origem ele veio com
metadados de backups POSTERIORES ao desejado, e o comando RESTORE por default
busca o último backup....
Uma vez que se descobriu isso, a solução foi simplesmente DELETAR os
metadados dos backups posteriores, yep ?? Então não é que os sites da internet
e a documentação que o pessoal seguiu tavam errados, simplesmente não se é
possível cobrir TODOS os cenários.... POR ISSO, inclusive, que em threads
anteriores aqui no Forum eu sempre insisti em Questionar os DETALHES do backup
a se restaurar....
Mas não acabou aí : depois do CONTROLFILE limpo e só contendo os metadados
necessários, o bloco de comandos com restore e recover abortava com :
RMAN-03002: failure of alter db command ...
ORA-01152: file 1 was not restored from a sufficiently old backup
Aí a falha era conceitual : o backup origem era "COLD" (na verdade
CONSISTENTE, já que o RMAN é INCAPAZ de fazer um backup COLD real, com o banco
fechado, pois que ele tinha que gravar no controlfile), e o pessoal não tinha o
conceito de que para backup Consistente vc não pode pedir um recover completo,
tem que ser com alguma limitação de UNTIL - preferencialmente anotando o Ckp
SCN do backup, que vai ser o mesmo para todos os datafiles no caso de backup
consistente, e usar esse número como limitador, ALÉM de se poder usar a
cláusula NOREDO, sinalizando que o recover é FAKE, os datafiles Já estão tipo :
run {
set until SCN=CkpSCNanotado;
restore database;
recover database noredo;
alter database open resetlogs;
}
cfrme a nota metalink How to Restore a Cold Backup and Open Resetlogs via
RMAN Without Applying Redo [ID 257326.1] documenta.... Por isso que em threads
anteriores referentes à RESTORE eu insisti em questionar o tipo exato do backup
origem, a questão do limitador usado no UNTIL, etc, etc...
Aí sim, com os pontos esclarecidos a restauração do backup no servidor novo
foi uma seda...
[]s
Chiappa
