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) 50000, 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 50000 ** 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 file/pieces todos estiverem catalogados no RMAN e fisicamente disponíveis na mídia de backup o RMAN é completamente capaz de localizar exatamente qual backup file/piece contém qual archive que ele precisa.... []s Chiappa
