Vamos lá.. Origem era 11.2.0.4
Destino: 11.2.0.4 ( foi instalado do zero, substituindo o antigo, na maquina desenv ) backup de origem: Hot (full + archivelogs) tudo windows x64 Eu já consegui resolver e restaurar o backup. Fiz examente isso.. apaguei tudo do repositorio do rman e cataloguei novamente, pegando um backup de ontem a noite. O servidor original tinha catalogo. Esse nao tem e nem vai ter. O mexe / remexe de trocar caminho das pastas newid etc, era porque o servidor origem tem discos onde os arquivos estavam espalhados Nessa maquina só tem C:\ e D:\ e foram todos moram no D:\ORACLE Como já havia tentado restaurar o backup antes e tinha topado com o problema e também, já havia alterado o pfile, o controle e tudo mais, para deixar tudo apontando para as pastas no D:\ A segunda tentativa de restauração foi relax. O sistema já encontrou tudo e aí fluiu Um detalhe que precisei recriar o tablespace TEMP default novamente a base subiu apontando pra pasta e depois recriar os redos. Eu to montando um passo a passo de backup/restore e colocando nele todas essas coisas que acontecem no meio do caminho até pra usar como referencia já que não é algo que eu faça toda hora. Próximo passo vai ser renomear a base, via nid 2017-04-13 12:41 GMT-03:00 jlchia...@yahoo.com.br [oracle_br] < oracle_br@yahoogrupos.com.br>: > > > Xô entender : o database-origem está rodando em QUAL exata versão de > binários, é essa mesma 11.2.0.4 cujos binários vc instalou na máquina > destino ?? SE NÃO FOR, provavelmente vc vai ter que depois de restaurar > fazer um startup upgrade e executar os scripts de recriação do dicionário > de dados, ie, o catalog.sql e catproc.sql, bem como um utlrp depois... > > Prosseguindo : se vc leu minha thread original, vc vai ver que no meu caso > o primeiro problema foi que meus backups todos estavam sendo registrados em > controlfile e não em banco de catálogo (vc não diz mas PARECE ser esse seu > caso) e casualmente eu tinha registrado nesse controlfile backups MAIS > RECENTES do que aquele cujos backup files eu estava tentando restaurar.... > A solução foi simplesmente *** apagar *** todos os backups outros que já > estavam nesse controlfile após o restore dele, ou seja, , toricar o > procedimento de (depois que os backup files já foram disponibilizados no > servidor destino) : > > "criar o pfile, voltar o spfile, editar, criar o spfile, criar as > pastinhas, restaurar o control, catalogar, restaurar a base,..." > > para : > > "criar o pfile, voltar o spfile, editar, criar o spfile, criar as > pastinhas, restaurar o control, **** APAGAR TODOS OS BACKUPS REGISTRADOS > NESSE CONTROLFILE ***, catalogar, restaurar a base,...." > > faça isso, mal não faz, sim sim ?? > > ===>> Meu OUTRO problema é que não tinham me passado que era backup COLD, > aí eu ficava que nem tonto tentando fazer recover depois do restore... Aí > vem a pergunta, DE QUE TIPO é esse backup que vc está tentando voltar, QUAL > os SCNs contidos nos archives que vc dispõe se for backup HOT, como está o > SCN dos datafiles, como está o SCN do controlfile ??? Com essa info vc vai > ser capaz de identificar se precisa fazer ou não recover depois do restore > (e UNTIL até quando, se for o caso de RESTORE), confirmar que vc tem TODOS > os archives na sequência bonitinhos se for HOT... Sim sim sim ??? > > []s > > Chiappa > > OBS : > > a. eu notei que vc falou que vai "trocar os caminhos" , provavelmente > porque na máquina destino o caminho para os datafiles é diferente, né ? Não > esqueça de que (SE vc não está usando arquivos criados automaticamente pelo > RDBMS) vc precisa usar o comando para isso, pode ser o SET NEWNAME direto > no RMAN, pode ser executando comandos SQL padrão tipo ALTER DATABASE RENAME > FILE 'xxx' TO 'yyy'... Eu prefiro sempre executar um comando para cada > arquivo a renomear/mudar de path, pois assim tenho CERTEZA que não esqueci > nenhum, não confio/não gosto das opções de trocar o destino geral... > E não esqueça que *** OUTROS *** paths podem precisar ser mudados nos > parâmetros do banco : *** LISTE *** na íntegra os parâmetros do > banco-origem e CONFIRME que todos os parâmetros que indicam algum PATH > (aonde gravar log, controlfiles, dumps, etc, etc, etc) estão apontando para > PATHs válidos/apropriados... > > b. Não É INCOMUM que vc queira mudar o NOME do database e/ou da > instância, etc no novo servidor : SE houver essa necessidade, veja os > comandos apropriados, que pode ser dbnewid, pode ser recriar o controlfile > a partir do backup to trace ou outros cfrme preferir... Logicamente, depois > de trocado o nome da instância/do database tipicamente vc tem que RECRIAR > ou RENOMEAR arquivos que contém no nome referência para a > instância/database original, como initfiles, archives, etc > E por ORGANIZAÇÃO também é mega-comum que os diretórios Administrativos > do database contenham o nome dele, se vc renomear o database por questão de > Organização normalmente se renomeia Também esses diretórios... > >
