Pois é Chiappa, fiquei de cara com a situação que me encontrei. Quando um parâmetro como esse está manual e você tem dba's que atuam pela manhã/tarde e noite em diversos clientes, setar um parâmetro desse manual é para matar qualquer um. Um ponto que verifiquei foi que esse datafile que foi criado é de número 125 que se encontra em um diskgroup +DATA no primary. Verificando no standby o arquivo foi criado no $ORACLE_HOME/dbs/UNNAMED00167.dbf (arquivo esse, que alguém deve ter deletado do SO pq não existe e memso se existisse o standby nao iria reconhecer). Seria mais ou menos, assim?
Primario: SQL> alter tablespace xuxa begin backup;ASMCMD> cp tbs_data01837.dbf /home/oracle/tbs_data01837 scp para o servidor standby SQL> alter tablespace xuxa endbackup; standby: SQL> alter system set standby_file_management=manual; cp /home/oracle/tbs_data01837 SQL> alter database rename file '.......UNNAMED00167' to '<>'; EM ambos: alter system set standby_file_management=AUTO; standby: alter database recover managed standby database Em Sexta-feira, 14 de Abril de 2017 11:57, "jlchia...@yahoo.com.br [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu: 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 #yiv8132326830 #yiv8132326830 -- #yiv8132326830ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv8132326830 #yiv8132326830ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv8132326830 #yiv8132326830ygrp-mkp #yiv8132326830hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv8132326830 #yiv8132326830ygrp-mkp #yiv8132326830ads {margin-bottom:10px;}#yiv8132326830 #yiv8132326830ygrp-mkp .yiv8132326830ad {padding:0 0;}#yiv8132326830 #yiv8132326830ygrp-mkp .yiv8132326830ad p {margin:0;}#yiv8132326830 #yiv8132326830ygrp-mkp .yiv8132326830ad a {color:#0000ff;text-decoration:none;}#yiv8132326830 #yiv8132326830ygrp-sponsor #yiv8132326830ygrp-lc {font-family:Arial;}#yiv8132326830 #yiv8132326830ygrp-sponsor #yiv8132326830ygrp-lc #yiv8132326830hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv8132326830 #yiv8132326830ygrp-sponsor #yiv8132326830ygrp-lc .yiv8132326830ad {margin-bottom:10px;padding:0 0;}#yiv8132326830 #yiv8132326830actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv8132326830 #yiv8132326830activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv8132326830 #yiv8132326830activity span {font-weight:700;}#yiv8132326830 #yiv8132326830activity span:first-child {text-transform:uppercase;}#yiv8132326830 #yiv8132326830activity span a {color:#5085b6;text-decoration:none;}#yiv8132326830 #yiv8132326830activity span span {color:#ff7900;}#yiv8132326830 #yiv8132326830activity span .yiv8132326830underline {text-decoration:underline;}#yiv8132326830 .yiv8132326830attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv8132326830 .yiv8132326830attach div a {text-decoration:none;}#yiv8132326830 .yiv8132326830attach img {border:none;padding-right:5px;}#yiv8132326830 .yiv8132326830attach label {display:block;margin-bottom:5px;}#yiv8132326830 .yiv8132326830attach label a {text-decoration:none;}#yiv8132326830 blockquote {margin:0 0 0 4px;}#yiv8132326830 .yiv8132326830bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv8132326830 .yiv8132326830bold a {text-decoration:none;}#yiv8132326830 dd.yiv8132326830last p a {font-family:Verdana;font-weight:700;}#yiv8132326830 dd.yiv8132326830last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv8132326830 dd.yiv8132326830last p span.yiv8132326830yshortcuts {margin-right:0;}#yiv8132326830 div.yiv8132326830attach-table div div a {text-decoration:none;}#yiv8132326830 div.yiv8132326830attach-table {width:400px;}#yiv8132326830 div.yiv8132326830file-title a, #yiv8132326830 div.yiv8132326830file-title a:active, #yiv8132326830 div.yiv8132326830file-title a:hover, #yiv8132326830 div.yiv8132326830file-title a:visited {text-decoration:none;}#yiv8132326830 div.yiv8132326830photo-title a, #yiv8132326830 div.yiv8132326830photo-title a:active, #yiv8132326830 div.yiv8132326830photo-title a:hover, #yiv8132326830 div.yiv8132326830photo-title a:visited {text-decoration:none;}#yiv8132326830 div#yiv8132326830ygrp-mlmsg #yiv8132326830ygrp-msg p a span.yiv8132326830yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv8132326830 .yiv8132326830green {color:#628c2a;}#yiv8132326830 .yiv8132326830MsoNormal {margin:0 0 0 0;}#yiv8132326830 o {font-size:0;}#yiv8132326830 #yiv8132326830photos div {float:left;width:72px;}#yiv8132326830 #yiv8132326830photos div div {border:1px solid #666666;height:62px;overflow:hidden;width:62px;}#yiv8132326830 #yiv8132326830photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv8132326830 #yiv8132326830reco-category {font-size:77%;}#yiv8132326830 #yiv8132326830reco-desc {font-size:77%;}#yiv8132326830 .yiv8132326830replbq {margin:4px;}#yiv8132326830 #yiv8132326830ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv8132326830 #yiv8132326830ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv8132326830 #yiv8132326830ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv8132326830 #yiv8132326830ygrp-mlmsg select, #yiv8132326830 input, #yiv8132326830 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv8132326830 #yiv8132326830ygrp-mlmsg pre, #yiv8132326830 code {font:115% monospace;}#yiv8132326830 #yiv8132326830ygrp-mlmsg * {line-height:1.22em;}#yiv8132326830 #yiv8132326830ygrp-mlmsg #yiv8132326830logo {padding-bottom:10px;}#yiv8132326830 #yiv8132326830ygrp-msg p a {font-family:Verdana;}#yiv8132326830 #yiv8132326830ygrp-msg p#yiv8132326830attach-count span {color:#1E66AE;font-weight:700;}#yiv8132326830 #yiv8132326830ygrp-reco #yiv8132326830reco-head {color:#ff7900;font-weight:700;}#yiv8132326830 #yiv8132326830ygrp-reco {margin-bottom:20px;padding:0px;}#yiv8132326830 #yiv8132326830ygrp-sponsor #yiv8132326830ov li a {font-size:130%;text-decoration:none;}#yiv8132326830 #yiv8132326830ygrp-sponsor #yiv8132326830ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv8132326830 #yiv8132326830ygrp-sponsor #yiv8132326830ov ul {margin:0;padding:0 0 0 8px;}#yiv8132326830 #yiv8132326830ygrp-text {font-family:Georgia;}#yiv8132326830 #yiv8132326830ygrp-text p {margin:0 0 1em 0;}#yiv8132326830 #yiv8132326830ygrp-text tt {font-size:120%;}#yiv8132326830 #yiv8132326830ygrp-vital ul li:last-child {border-right:none !important;}#yiv8132326830