Obrigado a todos que participaram dessa thread.
Pode ser um BUG mesmo, eu conferi todos os restores de spfile, controlfile e
datafiles, estão ok.
Acho que deve ter sido por algum restore de controle file sem backup que eu
fiz, realizei um restore pegando informações do backup controlfile trace. E
abri o database sem a opção de open resetlogs;
Não sei se fiz corretamente (se alguem puder comentar sobre isso agradeceria),
pois vejo que na grande maioria das vezes quando se tem um cenário de perda
total de controlfiles vc abre o database com a opção resetlogs; porém vi um
tutorial de um indiano abrindo o database sem resetlogs a partir do trace do
controlfile e repeti o cenário em meu ambiente.
Acho que após esse restore, deve ter havido algum problema com o database com
relação aos SCN da vida.
Será que isso faz sentindo?
Outra coisa, posso abrir o database sem a opção de recovery e abrir com
resetlogs perdendo dados? Já que o restore funcionou?
Em Segunda-feira, 6 de Março de 2017 14:47, "Luis Freitas
[email protected] [oracle_br]" <[email protected]> escreveu:
Carlos,
Para ter certeza é preciso confirmar no log do backup, e não tenho nenhum
aqui para ver, mas provavelmente esse log sequencia 5 foi gerado no meio do
backup full, por um "log switch" durante o backup, mas antes do autobackup do
controlfile.
Dessa forma ele está registrado no controlfile, mas não está presente no
ultimo backup.
Para ter todos os logs seria preciso fazer um shutdown do database, startup
mount, e rodar um backup dos archivelogs restantes.
Qualquer cópia do controlfile feita com o banco aberto vai sempre ter
registradas sequencias de log que ainda estão ativas como redo files.
Numa situação de desastre você pode recuperar as ultimas transações usando
esses arquivos de redo como archivelogs, assumindo que tenha sobrevivido uma
cópia deles.
Atc,
Luis Freitas
On Monday, March 6, 2017 10:59 AM, "[email protected] [oracle_br]"
<[email protected]> wrote:
Carlos, se vc tem ** 100% ** de certeza que o comando de RESTORE DATABASE
tá restaurando o backup correto (eu particularmente ** tenho uma birra e não
confio ** no default do RESTORE sem argumento nenhum, sempre peço um RESTORE
DATABASE usando um LABEL específico, e/ou se estou usando controlfile como
catálogo depois de restaurar o controlfile manda um list backup e ** REMOVO **
os backups todos que não interessam), que não havia nenhum tipo de standby e/ou
de retention setado no RMAN ou coisa assim ** segurando ** a necessidade para o
archive que contém essa sequência bem antiga E QUE o controlfile que vc
restaurou é o mais recente (E QUE o controlfile apontado pelo spfile/initfile é
esse correto, E que ele foi removido certinho do disco), pra mim o que pode
estar acontecendo aí é :
a) vc ** NÃO APAGOU ** os archives que tinha em disco na área de archive (o que
parece ser o caso, já que vc cita "..deletando todos os arquivos do servidor,
SPFILE, PFILE, TEMPFILE, CONTROLFILE, UNDO, SYSTEM, TODOS OS DATAFILES e REDO
LOGS" - NÃO VI referência a deleção aos archives -, e por bug/comportamento
inadequado o RMAN tentou restaurar um desses archives e esse archive ainda
referenciava uma sequência antiga
ou
b) vc ainda tem catalogado nesse RMAN archives muito antigos (ie, vc *** NÃO
PEDIU *** um DELETE EXPIRED antes), e por BUG /comportamento inadequado o RMAN
ainda está procurando por esses archives
a e b são maaais ou menos parecidos com o que é notado no documento 235973.1 do
metalink, grosso modo....
ou
c) nada impede que por algum motivo (transação de longa duração, delayed apply,
o que for) não tenha havido o checkpoint/aplicação no datafile o redo contido
nesse archive antigo, aí a leitura consistente que o RMAN faz voltou, voltou e
voltou até esse redo.... O grande detalhe é que, ** se ** o RMAN por causa de
algo nesse estilo (transação longa, ou o que for) precisa de algum redo
constante no archive X ** E ** consultando o catálogo ele verificar que X já
foi backupeado, salvo instrução contrária mesmo que X ainda esteja em disco ele
*** NÃO VAI BACKUPEAR X **, ok ?
O conceito é, o BACKUP DATABASE PLUS ARCHIVELOG vai te backupear além dos
datafiles os archives todos que sejam necessários *** MAS QUE *** ainda não
foram backupeados anteriormente, sim sim sim ???? Vc NÃO PODE pensar no jogo de
backup criado pelo database plus archivelog como uma unidade autônoma, pois ele
*** CONFIA *** que eventuais archives mais antigos eventualmente necessários
que constam como catalogados VÃO SIM estar disponíveis, ok ??
==> EU particularmente desconfio de a) ou b) , ie, o controlfile erradamente
referenciando archives velhos que vc não removeu dele (o que configuraria SIM
bug/comportamento inadequado), mas até pode ser que c) seja a sua razão...
Já que vc está testando, eu diria para vc REFAZER teu teste com um outro banco
de testes Atentando-se à questão de deletar o que estiver expired, ter apenas
um backup registrado no controlfile (se controlfile é onde tá teu catálogo) ou
então especificar DIRETAMENTE o backup que vc quer restaurar, etc, etc... E PLZ
*** peça *** um RESTORE PREVIEW pra ver exatamente o que vai ser necessário pra
restaurar ok ?
Recomendo também que vc inclua na sua rotina antes do backup o seguinte :
sql 'alter system switch logfile';
sql 'alter system archive log current';
[]s
Chiappa
#yiv4243518734 #yiv4243518734 -- #yiv4243518734ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv4243518734
#yiv4243518734ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv4243518734
#yiv4243518734ygrp-mkp #yiv4243518734hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv4243518734 #yiv4243518734ygrp-mkp #yiv4243518734ads
{margin-bottom:10px;}#yiv4243518734 #yiv4243518734ygrp-mkp .yiv4243518734ad
{padding:0 0;}#yiv4243518734 #yiv4243518734ygrp-mkp .yiv4243518734ad p
{margin:0;}#yiv4243518734 #yiv4243518734ygrp-mkp .yiv4243518734ad a
{color:#0000ff;text-decoration:none;}#yiv4243518734 #yiv4243518734ygrp-sponsor
#yiv4243518734ygrp-lc {font-family:Arial;}#yiv4243518734
#yiv4243518734ygrp-sponsor #yiv4243518734ygrp-lc #yiv4243518734hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv4243518734
#yiv4243518734ygrp-sponsor #yiv4243518734ygrp-lc .yiv4243518734ad
{margin-bottom:10px;padding:0 0;}#yiv4243518734 #yiv4243518734actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv4243518734
#yiv4243518734activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv4243518734
#yiv4243518734activity span {font-weight:700;}#yiv4243518734
#yiv4243518734activity span:first-child
{text-transform:uppercase;}#yiv4243518734 #yiv4243518734activity span a
{color:#5085b6;text-decoration:none;}#yiv4243518734 #yiv4243518734activity span
span {color:#ff7900;}#yiv4243518734 #yiv4243518734activity span
.yiv4243518734underline {text-decoration:underline;}#yiv4243518734
.yiv4243518734attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv4243518734 .yiv4243518734attach div a
{text-decoration:none;}#yiv4243518734 .yiv4243518734attach img
{border:none;padding-right:5px;}#yiv4243518734 .yiv4243518734attach label
{display:block;margin-bottom:5px;}#yiv4243518734 .yiv4243518734attach label a
{text-decoration:none;}#yiv4243518734 blockquote {margin:0 0 0
4px;}#yiv4243518734 .yiv4243518734bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv4243518734
.yiv4243518734bold a {text-decoration:none;}#yiv4243518734 dd.yiv4243518734last
p a {font-family:Verdana;font-weight:700;}#yiv4243518734 dd.yiv4243518734last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv4243518734
dd.yiv4243518734last p span.yiv4243518734yshortcuts
{margin-right:0;}#yiv4243518734 div.yiv4243518734attach-table div div a
{text-decoration:none;}#yiv4243518734 div.yiv4243518734attach-table
{width:400px;}#yiv4243518734 div.yiv4243518734file-title a, #yiv4243518734
div.yiv4243518734file-title a:active, #yiv4243518734
div.yiv4243518734file-title a:hover, #yiv4243518734 div.yiv4243518734file-title
a:visited {text-decoration:none;}#yiv4243518734 div.yiv4243518734photo-title a,
#yiv4243518734 div.yiv4243518734photo-title a:active, #yiv4243518734
div.yiv4243518734photo-title a:hover, #yiv4243518734
div.yiv4243518734photo-title a:visited {text-decoration:none;}#yiv4243518734
div#yiv4243518734ygrp-mlmsg #yiv4243518734ygrp-msg p a
span.yiv4243518734yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv4243518734
.yiv4243518734green {color:#628c2a;}#yiv4243518734 .yiv4243518734MsoNormal
{margin:0 0 0 0;}#yiv4243518734 o {font-size:0;}#yiv4243518734
#yiv4243518734photos div {float:left;width:72px;}#yiv4243518734
#yiv4243518734photos div div {border:1px solid
#666666;height:62px;overflow:hidden;width:62px;}#yiv4243518734
#yiv4243518734photos div label
{color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv4243518734
#yiv4243518734reco-category {font-size:77%;}#yiv4243518734
#yiv4243518734reco-desc {font-size:77%;}#yiv4243518734 .yiv4243518734replbq
{margin:4px;}#yiv4243518734 #yiv4243518734ygrp-actbar div a:first-child
{margin-right:2px;padding-right:5px;}#yiv4243518734 #yiv4243518734ygrp-mlmsg
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv4243518734
#yiv4243518734ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv4243518734
#yiv4243518734ygrp-mlmsg select, #yiv4243518734 input, #yiv4243518734 textarea
{font:99% Arial, Helvetica, clean, sans-serif;}#yiv4243518734
#yiv4243518734ygrp-mlmsg pre, #yiv4243518734 code {font:115%
monospace;}#yiv4243518734 #yiv4243518734ygrp-mlmsg *
{line-height:1.22em;}#yiv4243518734 #yiv4243518734ygrp-mlmsg #yiv4243518734logo
{padding-bottom:10px;}#yiv4243518734 #yiv4243518734ygrp-msg p a
{font-family:Verdana;}#yiv4243518734 #yiv4243518734ygrp-msg
p#yiv4243518734attach-count span {color:#1E66AE;font-weight:700;}#yiv4243518734
#yiv4243518734ygrp-reco #yiv4243518734reco-head
{color:#ff7900;font-weight:700;}#yiv4243518734 #yiv4243518734ygrp-reco
{margin-bottom:20px;padding:0px;}#yiv4243518734 #yiv4243518734ygrp-sponsor
#yiv4243518734ov li a {font-size:130%;text-decoration:none;}#yiv4243518734
#yiv4243518734ygrp-sponsor #yiv4243518734ov li
{font-size:77%;list-style-type:square;padding:6px 0;}#yiv4243518734
#yiv4243518734ygrp-sponsor #yiv4243518734ov ul {margin:0;padding:0 0 0
8px;}#yiv4243518734 #yiv4243518734ygrp-text
{font-family:Georgia;}#yiv4243518734 #yiv4243518734ygrp-text p {margin:0 0 1em
0;}#yiv4243518734 #yiv4243518734ygrp-text tt {font-size:120%;}#yiv4243518734
#yiv4243518734ygrp-vital ul li:last-child {border-right:none
!important;}#yiv4243518734
