Chiappa, eh impressionante como vc abidica parte do seu tempo para nos ajudar,
nao somente para me ajudar, mas para ajudar a todos do grupo. Com embasamentos
teoricos, explicando cada detalhe para nos fazer entender cada procedimento.
Estou sem palavras para lhe agradecer, voce eh uma das melhores pessoas que ja
conheci (por meios de forum e blogs). Obrigado por compartilhar um pouco do seu
conhecimento conosco.
Em Quarta-feira, 8 de Março de 2017 10:02, "[email protected]
[oracle_br]" <[email protected]> escreveu:
Blz ? Vamos começr pela questão do RESETLOGS : quando vc perde
completamente o controlfile, como eu disse na minha msg anterior ** ou ** vc
restaura ele de um backup , ** OU ** (se TIVER toda a informação que vai nele E
se tiver os archives/redo logs necessários todinhos) vc o recria com o comando
CREATE CONTROLFILE - se por acaso além de perder todoas as n cópias do
controlfile que o RDBMS mantém vc ainda por cima não tiver backup do
controlfile e não puder recriar ele por não ter todas as informações em mãos
(ou pior, por tem mais alguma coisa perdida/corrompida além do controlfile),
normalmente é game over....
A questão no vídeo do cara é que (de um modo meio Artificial, só pra servir de
exemplo) ele simulou a perda apenas e tão somente dos controlfiles, mantendo-se
totalmente íntegros os redo log files, os archives TODINHOS e os datafiles -
ora, numa situação assim, onde vc tem 100% de certeza de ter os datafiles
fisicamente íntegros E ainda por cima tem todinhos os redo log files e os
archives, aí SIM vc pode pedir um OPEN NORESETLOGS : a FINALIDADE do
NORESETLOGS é justamente essa, ie, vc indica pro RDBMS que vc ** TEM **
absolutamente TODO o fluxo de redo (redo que estava online, principalmente,
além dos óbvios redos archivado, que vc SEMPRE precisa em situação de banco em
archivemode que vc não tem 100% de certeza de shutdown limpo OU está voltando
backup) necessário para deixar o database consistente.... Da documentação 11gR2
:
"NORESETLOGS Specify NORESETLOGS if you want Oracle Database to use all files
in the LOGFILE clause as they were when the database was last open. These files
must exist and must be the current online redo log files rather than restored
backups. The database reassigns the redo log file groups to the threads to
which they were previously assigned and reenables the threads as they were
previously enabled."
OK ? Torno a repetir, esse exemplo do cara mostra que em tese é possível se
reconstruir controlfile sem resetar logs mas ele foi ARTIFICIAL, num caso real
da vida como ela é vc ** não vai ter 100% de certeza ** que os redo online não
corromperam, então vc vai de RESETLOGS, o que instrui o RDBMS a recriar os redo
log files, desprezando a informação que estava neles.... Não tenho o contexto
mas ACREDITO que é isso o que o Portilho estava demonstrando, uma situação REAL
onde vc não tem 100% de certeza que os redo onlines estão presentes e íntegros,
por isso ele (corretamente) foi de RESETLOGS.....
Pense no RESETLOGS como um comando para o database IGNORAR a informação de
SCN corrente que estava no redo log ativo - e INCLUSIVE, é Por Isso que via de
regra vc ao voltar um backup hot/online vc tem que pedir resetlogs, pois o RMAN
** não tem garantia ** alguma de conseguir copiar o redo logfile que está no
uso (pois tranquilamente o RDBMS pode estar gravando nele no momento que o RMAN
tentar copiar), então o RMAN optou por simplesmente *** NUNCA *** copiar o redo
online num backup online/hot/inconsistente : sem redo online no backup (ou sem
garantia de ter o redo online, no caso de crash) = necessidade de usar
RESETLOGS... É POR ISSO, também, que em algum momento da thread foi Recomendado
que vc pedisse para ARCHIVAR o redo online via alter system archive log
current; - isso é uma Garantia a Mais que o redo que estava sendo gerado por
transações ativas/abertas vai ser arquivado e portanto vai ser backupeado...
Agora sobre INCARNATION : vc pode pensar numa INCARNATION como uma "nova vida",
uma nova "versão" do seu database... Tirando do Glossário do 11gR2 :
"incarnation
A separate version of a database. The incarnation of the database changes when
you open it with the RESETLOGS option, but you can recover backups from a prior
incarnation so long as the necessary redo is available."
Para vc poder entender o conceito, antes de tudo é preciso vc entender que o
SCN além de ser um número sequencial e crescer a cada commit, checkpoint e etc,
ele TAMBÉM cresce sozinho em pequenos intervalos de tempo,funcionando assim na
prática como um RELÓGIO INTERNO para o database se controlar - é POR ISSO que
vc pode tranquilamente MUDAR a data/hora do servidor onde o RDBMS Oracle roda
absolutamente sem prejuízo algum para o funcionamento do kernel do RDBMS, o
banco em si internamente NÃO USA a hora do sistema pra nada - satélites e/ou
aplicações que dependem da hora (como JOBs, por exemplo) seriam afetados mas o
banco em si nunca, já que ele se controla é pelo SCN....
Muito bem : já que o database se controla/sabe quanto "tempo" passou através
do SCN e que cfrme acima quando vc pede um RESETLOGS ele RECRIA o redo log com
um SCN diferente online E que vc tinha informação de SCN constando no redo log,
vc VAi ter um GAP aí : antes o redolog online tinha um SCN X, depois com a
reconstrução dele (junto com os demais logfiles) o redo online passou a ter um
SCN Y diferente.... Para evitar inconsistência nesse GAP aí, o RDBMS considera
que nesse ponto no tempo onde Y passou a ser o SCN o database criou uma 'vida
nova', uma nova 'versão', em princípio INCOMPATÍVEL com o passado - isso é
importante no mundo Oracle porque o RDBMS Oracle não só atende às exigências
das regras de Codd (que exigem que uma transação possa ser desfeita a qualquer
momento, que seja durável, que registre log, etc) mas TAMBÉM (dado que separa
UNDO de REDO) desde muuuto tempo atrás o RDBMS Oracle sempre ofereceu a
possibilidade de VOLTA NO TEMPO, ie, fazer o database voltar a uma posição
íntegra num ponto do passado desfazendo o redo, o chamado ROLLING BACKWARD -
veja
https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:913283900346408687
para refs...
Por causa desse "GAP" artificial gerado pelo RESETLOGS, obviamente não temos
nenhum redo cobrindo o intervalo entre X e Y, teria uma INCONSISTÊNCIA se eu
fosse voltar além desse ponto : assim Y passou a ser em princípio o início de
uma nova 'vida', de uma nova 'versão' do database, quase como se ele tivesse
sido RECRIADO em Y, logicamente falando.... É POR ISSO, inclusive, que a Oracle
introduziu no conceito de FLASHBACK DATABASE a figura dos ** FLASHBACK LOGS **
, que por serem independentes de sequência de SCN permitem que vc volte no
tempo o database até mesmo para encarnações passadas...
Já que vc está testando metodologias e conceitos de backup, esse conceito de
INCARNATION vai ser ** totalmente crítico ** no que se refere à RECOVER : para
vc fazer o recover de um backup restaurado, como já dito o RDBMS vai aplicar os
redos arquivados, e ele só consegue fazer isso se a ENCARNAÇÃO é a mesma.....
OU SEJA, na prática no instante em que vc cria uma nova ENCARNAÇÂO do seu
database os archives da encarnação anterior ficam "incompatíveis" com a
encarnação registrada no database atualmente, elas são de uma 'vida' anterior à
qual vc não tem acesso, digamos assim.... SE a sua política eventualmente prevê
rolling backward via REDO pra um tempo no passado a priori, fique Ciente
disso... OU AINDA, imagine que vc fez um backup full no dia 1 (digamos), aí foi
fazendo incrementais e backups de archives, aí no dia 5 vc criou uma nova
encarnação fazendo um OPEN RESETLOGS (porque teve que voltar backup hot,
digamos, enfim) mas inadvertidamente NÃO fez nada mais e continuou só
backupeando archives - esses archives são de uma NOVA encarnação, vc terá
PROBLEMAS ao tentar aplicá-los em cima do backup full do dia 1 que é de uma
encarnação anterior..... Ate o banco 10g vc estaria com problemas Graves aí na
sua recuperabilidade, mas no 11g foi introduzida a figura do RESET DATABASE que
coloca o database numa outra encarnação, veja
http://shahiddba.blogspot.com.br/2012/10/resetting-or-recovering-database-with.html
incremental para refs....
[]s
Chiappa #yiv1166750234 #yiv1166750234 -- #yiv1166750234ygrp-mkp
{border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0
10px;}#yiv1166750234 #yiv1166750234ygrp-mkp hr {border:1px solid
#d8d8d8;}#yiv1166750234 #yiv1166750234ygrp-mkp #yiv1166750234hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv1166750234 #yiv1166750234ygrp-mkp #yiv1166750234ads
{margin-bottom:10px;}#yiv1166750234 #yiv1166750234ygrp-mkp .yiv1166750234ad
{padding:0 0;}#yiv1166750234 #yiv1166750234ygrp-mkp .yiv1166750234ad p
{margin:0;}#yiv1166750234 #yiv1166750234ygrp-mkp .yiv1166750234ad a
{color:#0000ff;text-decoration:none;}#yiv1166750234 #yiv1166750234ygrp-sponsor
#yiv1166750234ygrp-lc {font-family:Arial;}#yiv1166750234
#yiv1166750234ygrp-sponsor #yiv1166750234ygrp-lc #yiv1166750234hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv1166750234
#yiv1166750234ygrp-sponsor #yiv1166750234ygrp-lc .yiv1166750234ad
{margin-bottom:10px;padding:0 0;}#yiv1166750234 #yiv1166750234actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv1166750234
#yiv1166750234activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv1166750234
#yiv1166750234activity span {font-weight:700;}#yiv1166750234
#yiv1166750234activity span:first-child
{text-transform:uppercase;}#yiv1166750234 #yiv1166750234activity span a
{color:#5085b6;text-decoration:none;}#yiv1166750234 #yiv1166750234activity span
span {color:#ff7900;}#yiv1166750234 #yiv1166750234activity span
.yiv1166750234underline {text-decoration:underline;}#yiv1166750234
.yiv1166750234attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv1166750234 .yiv1166750234attach div a
{text-decoration:none;}#yiv1166750234 .yiv1166750234attach img
{border:none;padding-right:5px;}#yiv1166750234 .yiv1166750234attach label
{display:block;margin-bottom:5px;}#yiv1166750234 .yiv1166750234attach label a
{text-decoration:none;}#yiv1166750234 blockquote {margin:0 0 0
4px;}#yiv1166750234 .yiv1166750234bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv1166750234
.yiv1166750234bold a {text-decoration:none;}#yiv1166750234 dd.yiv1166750234last
p a {font-family:Verdana;font-weight:700;}#yiv1166750234 dd.yiv1166750234last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv1166750234
dd.yiv1166750234last p span.yiv1166750234yshortcuts
{margin-right:0;}#yiv1166750234 div.yiv1166750234attach-table div div a
{text-decoration:none;}#yiv1166750234 div.yiv1166750234attach-table
{width:400px;}#yiv1166750234 div.yiv1166750234file-title a, #yiv1166750234
div.yiv1166750234file-title a:active, #yiv1166750234
div.yiv1166750234file-title a:hover, #yiv1166750234 div.yiv1166750234file-title
a:visited {text-decoration:none;}#yiv1166750234 div.yiv1166750234photo-title a,
#yiv1166750234 div.yiv1166750234photo-title a:active, #yiv1166750234
div.yiv1166750234photo-title a:hover, #yiv1166750234
div.yiv1166750234photo-title a:visited {text-decoration:none;}#yiv1166750234
div#yiv1166750234ygrp-mlmsg #yiv1166750234ygrp-msg p a
span.yiv1166750234yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv1166750234
.yiv1166750234green {color:#628c2a;}#yiv1166750234 .yiv1166750234MsoNormal
{margin:0 0 0 0;}#yiv1166750234 o {font-size:0;}#yiv1166750234
#yiv1166750234photos div {float:left;width:72px;}#yiv1166750234
#yiv1166750234photos div div {border:1px solid
#666666;height:62px;overflow:hidden;width:62px;}#yiv1166750234
#yiv1166750234photos div label
{color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv1166750234
#yiv1166750234reco-category {font-size:77%;}#yiv1166750234
#yiv1166750234reco-desc {font-size:77%;}#yiv1166750234 .yiv1166750234replbq
{margin:4px;}#yiv1166750234 #yiv1166750234ygrp-actbar div a:first-child
{margin-right:2px;padding-right:5px;}#yiv1166750234 #yiv1166750234ygrp-mlmsg
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv1166750234
#yiv1166750234ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv1166750234
#yiv1166750234ygrp-mlmsg select, #yiv1166750234 input, #yiv1166750234 textarea
{font:99% Arial, Helvetica, clean, sans-serif;}#yiv1166750234
#yiv1166750234ygrp-mlmsg pre, #yiv1166750234 code {font:115%
monospace;}#yiv1166750234 #yiv1166750234ygrp-mlmsg *
{line-height:1.22em;}#yiv1166750234 #yiv1166750234ygrp-mlmsg #yiv1166750234logo
{padding-bottom:10px;}#yiv1166750234 #yiv1166750234ygrp-msg p a
{font-family:Verdana;}#yiv1166750234 #yiv1166750234ygrp-msg
p#yiv1166750234attach-count span {color:#1E66AE;font-weight:700;}#yiv1166750234
#yiv1166750234ygrp-reco #yiv1166750234reco-head
{color:#ff7900;font-weight:700;}#yiv1166750234 #yiv1166750234ygrp-reco
{margin-bottom:20px;padding:0px;}#yiv1166750234 #yiv1166750234ygrp-sponsor
#yiv1166750234ov li a {font-size:130%;text-decoration:none;}#yiv1166750234
#yiv1166750234ygrp-sponsor #yiv1166750234ov li
{font-size:77%;list-style-type:square;padding:6px 0;}#yiv1166750234
#yiv1166750234ygrp-sponsor #yiv1166750234ov ul {margin:0;padding:0 0 0
8px;}#yiv1166750234 #yiv1166750234ygrp-text
{font-family:Georgia;}#yiv1166750234 #yiv1166750234ygrp-text p {margin:0 0 1em
0;}#yiv1166750234 #yiv1166750234ygrp-text tt {font-size:120%;}#yiv1166750234
#yiv1166750234ygrp-vital ul li:last-child {border-right:none
!important;}#yiv1166750234
