Bom dia, Pô bem lembrado, isso não pode ser esquecido.. senao ficaria o servidor atualizado com a base desatualizada (nao duvido que isso aconteça muito..)
[]s angelo Em Qua, 15 de ago de 2018 19:20, Evandro Giachetto evandrogiache...@gmail.com [oracle_br] <oracle_br@yahoogrupos.com.br> escreveu: > > > Se seu banco de origem era 11.2.0.3 e vc instalou o software versão > 11.2.0.4 no destino, então vc vai ter que fazer o upgrade logo depois que > fizer o restore do banco. > > Assim que o restore e recover tiverem concluído, vc deve abrir o banco com > resetlogs para recriar os redologs e em modo de upgrade, e rodar o catupgrd > para concluir o upgrade de 11.2.0.3 para 11.2.0.4. > > Algom assim: > > SQL> alter database open resetlogs upgrade; > > SQL> @?/rdbms/admin/catupgrd.sql > > > Esse blog aqui explica bem: > > > http://parthidba.blogspot..com/2014/10/migrating-oracle-database-from-11203-to.html > <http://parthidba.blogspot.com/2014/10/migrating-oracle-database-from-11203-to.html> > > > > Evandro Giachetto > Oracle DBA > evandrogiache...@gmail.com > http://www.dbaoracle.eti.br/ > > <http://www.dbaoracle.eti.br/> > > > > Em qua, 15 de ago de 2018 às 15:21, jlchia...@yahoo.com.br [oracle_br] < > oracle_br@yahoogrupos.com.br> escreveu: > >> >> >> Sim, backup COLD implica em parar o banco enquanto ele está sendo feito - >> realmente com ele vc tem 100% de certeza que NÂO há transações / alterações >> / manipulações de dados comitadas mas ainda não baixadas pro disco,sim, mas >> é Difícil que haja janela pra isso, sim... >> Em não podendo ser COLD (exceções feitas à soluções de snapshot de >> discos que se integrem com o RDBMS e "forcem" um checkpoint completo E >> suspendam I/O no banco enquanto rola o snapshot) aí então SIM, estamos no >> domínio do HOT BACKUP.... >> Pra vc explicar/conceituar HOT BACKUP pra um leigo, é bem simples : diga >> que ele é composto por uma cópia dos dados 'intocados' que estavam em >> disco MAIS uma cópia da trilha de alterações, ie, de TODOS os dados que >> vieram do disco e foram alterados até um determinado ponto no tempo, okdoc >> ? Simples... NÂO EXISTE isso de "99% do que está ali é backupeado", até >> porque backup e gravidez, ou vc tem ou não tem - não existe backup parcial >> , não existe meia gravidez, ou vc tem completo ou não tem..... Assim >> sendo, falando do seu caso, se é backup HOT vc só tem um backup válido SE E >> APENAS SE vc tem uma cópia de TODOS os archived redo logs gerados desde a >> última alteração dos datafiles até a hora do backup : se vc não tem 100% de >> certeza que tem TODOS esses archives backupeados, vc simplesmente NÂO TEM >> CERTEZA de ter um backup íntegro, sim sim sim ??? UM archive que seja >> faltante pronto, já significa que do ponto do tempo onde esse archive >> faltante foi gerado pra frente vc simplesmente NÃO conseguirá recuperar os >> dados desse ponto pra frente - digamos que quando foi feito o backup mais >> recente dos datafiles o SCN marcado num deles era de 72 horas atrás >> (plenamente possível - como nós sabemos quando vc faz COMMIT os dados NÃO >> SÃO gravados imediatamente nos datafiles, por questões de performance), e >> por qquer falha na sua política vc PERDEU o archive que registrava >> alterações de 71 horas atrás : pronto, essa simples falha de UM archive >> crítico faltante te impedirá de recuperar esse datafile em questão... E se >> esse datafile for o que contém a crítica tablespace SYSTEM ?? Ferrou.... >> >> É por isso que eu insisto : backup HOT só é tão confiável o quanto for >> confiável tua política de backups de Archives..... >> >> []s >> >> Chiappa >> > >
