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
