Chiappa,
Perfeito, entendido...
Uma ultima pergunta: então antes de começar o recover database, o RMAN verifica
os archivelog que ele irá precisar, e como ele não encontra ele dá aquele erro?
Saideira: o melhor para este caso seria fazer um recover database until
sequence xxx; ou fazer um restore dos archivelog em disco e depois aplicar?
Grato,
Ednilson
De:
sentto-1682896-121558-1487782614-ednilson.silva=jbs.com...@returns.groups.yahoo.com
[mailto:sentto-1682896-121558-1487782614-ednilson.silva=jbs.com...@returns.groups.yahoo.com]
Em nome de jlchia...@yahoo.com.br [oracle_br]
Enviada em: quarta-feira, 22 de fevereiro de 2017 13:57
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: RES: RES: [oracle_br] Re: Recover database
Opa : sobre os backups, não conheço essa solução (StarOnce) então não posso
dizer nada sobre integridade (em especial coisas se ela tem proteção contra,
digamos, tentar backupear um archive no exato instante em que ele está ainda
aberto e em uso pelo RDBMS Oracle) - eu sempre dou ** total ** preferência para
backups via RMAN justamente por confiar mais que esse tupo de coisa nunca
acontece, já que o RMAN ** reconhece ** os locks/proteções de arquivos impostos
pelo RDBMS mas ok, por desconhecimento não posso comentar nada sobre ela,
repito...
Isso traz um outro ponto à baila : Obviamente, o RMAN só conhece os backups
feitos por ele : se vc tá usando essa tal solução de terceiros (StarOnce), a
menos que ela tenha alguma "ligação" com o RMAN via library/DLL/whatever, o
RMAN *** não saberá NADICA DE NADA *** sobre ela, então o controle desses
backups vc faz à parte , com as tools/ferramentas do fornecedor,
necessariamente
Sobre sua outra pergunta, o funcionamento do RDBMS e do RMAN é : o banco
possui um número (uma SEQUENCE numérica, se vc quiser) constantemente crescendo
a cada poucos segundos ** ou ** quando uma transação é startada (cada Transação
sempre vai ter seu 'número' único), e esse "sequencial" se chama SCN, e ele é
referenciado nos datafiles (quando as coisas que estão nos buffers são
efetivadas no datafile fica registrado no cabeçalho dele o SCN corrente dessa
ocasião, que pode ser rara, já que o RDBMS tenta gravar o mínimo possível nos
datafiles e sempre lentamente, em background), no CONTROLFILE (indicando o SCN
mais atual do sistema, digamos assim) e nos REDO LOG FILES (no formato LOW and
HIGH, ie, um par indicando que aquele REDO LOG FILE tal possui logs que se
referem à transações feitas desde o SCN x até o SCN y)... Mais tarde, quando o
REDO LOG FILE é arquivado, ele ganha um SEQUENCE NUMBER, ie, um OUTRO número
sequencial que serve para identificar unicamente aquele archive
==> OU SEJA : em tese, é perfeitamente possível que uma transação T1 comece e
ganhe um SCN 1000 (e portanto teu REDO LOG FILE atual L1 tenha como LOW SCN
1000), aí SEM encerrar essa transação outras transações T2, T3, etc, comecem e
passem a gerar montes de redo, que vão encher o logfile L1, depois o L2, depois
o L3, etc, etc , que vão ser arquivados e gerar os archives com sequências
(digamos) 5, 50001, 50002, etc, E ao mesmo tempo o SCN corrente vai
avançando no controlfile e para fins didáticos suponha que os datafiles não
sejam atualizados nesse intervalo e portanto continuem com SCN abaixo de
1000 Aí digamos que só então a nossa transação T1 volte a gerar redo no
logfile atual L5 : como essa transação ** ainda ** tem como SCN 1000,
necessariamente esse logfile vai ter 1000 como LOW SCN, e quando esse logfile
for arquivado ele ganha digamos uma sequence de 50005, e que ela é comitada
pouco depois...
Neste cenário, se mais tarde vc tiver que recuperar e atualizar esse banco,
justamente por causa dessa transação T1 que se "espalhou" por diferentes
logfiles archivados em diferentes sequências vc vai precisar TANTO do archive
com sequência 5 ** quanto ** do archive com sequência 50005 Esse tipo
de coisa pode ** sim ** acontecer, e imho EXPLICAM adequadamente os casos em
que vc é solicitado a localizar archives com sequences muito distantes entre
si, em especial sequências muito "antigas" no tempo : normalmente as pessoas
lembram que quando vc faz o backup o RMAN força um checkpoint (atualizando o
SCN nos datafiles, okdoc) mas Não encerra as transações porventura
acontecendo
Assim, te respondendo : se vc pediu um RECOVER ** sem ** especificar o limite
e ele tá pedindo por archives gerados ** depois ** do backup pra mim é isso, vc
tinha alguma transação aberta no momento do HOT BACKUP (que tem esse nome
Justamente porque o banco está ABERTO pra transações durante o backup) , que
gerou redo log em logfiles posteriores ao término do backup de banco
Finalmente : o fato de em um backup file/backup piece vc poder ter diferentes
archives (cada um, óbvio, com diferentes sequences) sem uma ordenação definida,
não tem problema algum - como foi dito, se os backup
