Blz ? Então, standby_file_management é um dos parâmetros ** críticos ** que devem ser observados num standby, junto (embora por outros motivos) com standbylogs e uns tantos outros : não observou, é kaput muitas vezes... O caso é que dentro de um redo log vc tem os bytes que foram alterados *** MAS *** também dentro deles tem o FILE NUMBER de qual datafile o redo deve ser aplicado : assim, todos os redo que foram criados do instante em que vc criou só em prod a tablespace contém um FILE NUMBER que não existe no standby..... E vc não diz mas *** ESPERO *** que não tenha criado a tablespace manualmente no standby, pois nesse caso a tablespace no standby, com QUASE CERTEZA o datafile dessa tablespace ganharia um FILE NUMBER *** diferente *** daquele que tem em PROD - descompasso total, controlfile, dicionário e redo estão procurando processar um arquivo com file number X e na verdade o número dele é Y, zona completa..... ====>>>> É POR ISSO, inclusive, que bem claramente o manual Oracle "Data Guard Concepts and Administration" no cap. 9 - Managing Physical and Snapshot Standby Databases nos diz : "Table 9-1 Primary Database Changes That Require Manual Intervention at a Physical Standby
Reference Primary Database Change Action Required on Physical Standby Database Section 9.3.1 Add a datafile or create a tablespace No action is required if the STANDBY_FILE_MANAGEMENT database initialization parameter is set to AUTO. If this parameter is set to MANUAL, the new datafile must be copied to the physical standby database. " okdoc ? Assim sendo, sua primeira ação (DEPOIS de corrigir a mancada da grossa aí e deixar o parâmetro de management como deveria ser) deveria ter sido ** COPIAR ** o(s) datafile(s).... E no caso, eu nunca caí nessa situação, mas IMAGINO que seria o caso de botar a tablespace em backup mode, fazer a cópia do arquivo a partir de prod para o standby via scp, ftp, o que puder/tiver disponível e depois tirar de backup mode - via de regra vc NÃO PODE sair copiando simplesmente um datafile, pois PODE SER que o RDBMS cisme de gravar nele justamente no momento que vc tá fazendo a cópia.... Uma vez copiado o arquivo, aí a informação de file number constante no redo, no dicionário E no control file vai em tese ficar equalizada, muito bem... Agora chegamos no ponto do REDO que deve ser aplicado em cima desse datafile : não tenho um ambiente aqui para testar mas IMAGINO que, uma vez o redo todo necessário estando disponível, é simplesmente uma questão de parar e startar de novo o processo de recovery do standby.... No seu caso específico, muito embora vc diga no começo da thread que "o standby nao criou a tablespace e o standby parou de aplicar, mas continou recebendo os archives da produção, realizando os backups" a sua conclusão que ele continuou "apagando os archives em disco" depende FUNDAMENTALMENTE de como está a sua política de deleção : LÓGICO que se ela estiver para deletar apenas após a Aplicação certamente os archives não vão ter sido deletados do disco enquanto não forem aplicados, e (imagino) não estavam sendo aplicados porque tinha um datafile faltante.... VERIFIQUE se foram ou não apagados do disco esses caretas aí sim sim sim ??? Manda um ls -l lá no local deles.... CASO eles tenham sim sido apagados do disco, a minha ** SUPOSIÇÃO ** (novamente, como não estou com um ambiente teste adequado aqui pra testar na prática é só uma Suposição) é que esse redo não aplicado por causa do datafile "faltante" está sendo re-archivado nos archives sendo gerados mais recentemente ainda, por isso o RMAN não deixa vc restaurar essas sequências, o redo relacionado com essas sequências está arquivado em outro archive que está em disco.... Minha Recomendação então é que vc (** DEPOIS ** de consertar o parâmetro, insisto!) providencie a cópia do(s) datafile(s) e restarte o processo de recover no standby, veja se ele consegue extrair o redo faltante dos archives que já estão no disco.... []s Chiappa
