Obrigado mais uma vez Chiappa por sua explicação. Eu tenho uma nova chance de colocar isso pra funcionar e tentarei fazer da forma correta agora :)
Vou gerar uma nova cópia do controlfile e ver se consigo restaurar o banco a partir desse novo controlfile. Mesmo tendo que acessar o servidor antigo neste momento. Eu pensei em configurar um backup do controlfile de tempos em tempos direto no FRA (ou usar o snapshot controlfile [???????] não sei se é possível restaurar com o snapshot). Esse backup sempre vai ter um scn mais antigo e talvez eu possa abrir o banco aplicando os archives que já estão no FRA. De qualquer forma. A cópia entre discos é feita com os discos no servidor secundário ainda desmontados. Ou seja, eles são "desapresentados" do SO e reapresentados quando a transferência está completa a partir do console do EMC. Então, ninguém está tocando nos discos eqto a transferência é feita. Eu achei intrigante ele não abrir, já que imaginei que, com a cópia dos arquivos, mesmo que sem o último checkpoing aplicado o banco abriria numa boa. Evandro Giachetto Oracle DBA evandrogiache...@gmail.com Em 25 de junho de 2015 11:45, jlchia...@yahoo.com.br [oracle_br] < oracle_br@yahoogrupos.com.br> escreveu: > > > Opa, blz ? Então, eu não trabalhei com essa daí ainda, mas farei a > Observação geral e genérica que faço ** SEMPRE ** aqui no Fórum quando se > fala de replicação por storage (veja as muitas msgs mais antigas sobre > isso) que vai ser usada com banco-origem ONLINE/ATIVO : a primeira coisa > que vc TEM que receber (do Suporte, da Documentação, enfim, de alguma fonte > CONFIÁVEL sobre a solução de replicação de blocos de disco) é que ela ** > EFETIVAMENTE BLOQUEIA ** o acesso aos blocos TODOS nquanto a > cópia/transferência está rolando, ok ?? O que esse pessoalzinho muitas > vezes esquece é o RDBMS Oracle ** nunca ** grava imediatamente a informação > alterada em disco de forma imediata (SEMPRE é em background, e de forma > "preguiçosa", e que pode iniciar a Qualquer Momento em Qualquer Bloco do > disco) E ** tranquilamente ** (ainda que NÃO estejam havendo Transações!!) > alguns arquivos (especialmente CONTROLFILEs!) podem estar sendo gravados... > Em cima disso, imagine que a solução de replicação leu o bloco x, e por > azar nesse instante em que o está replicando o RDBMS cisma de querer gravar > e grava coisa nesse bloco... Ou ainda, imagine que (ainda durante a cópia > de blocos) o RDBMS atualizou o SCN num datafile MAs não atualizou ainda no > controlfile, ou vice-versa : SCN inapropriado é o Mínimo que se pode > esperar se vc quiser subir uma cópia nesses condições.... REPITO, Alguém > Tem que te Garantir que esse tipo de coisa não ocorre, que a Solução > efetivamente BLOQUEIA acesso ao Storage no instante em que a Replicação > está rolando... SE vc realmente quer ter failover instantâneo, a solução de > replicação do STorage TEM que te garantir esse tipo de Integridade... > > Aí chegamos no ponto da CONFIGURAÇÃO eventualmente necessária : por > exemplo, já vo Soluções que (justamente por não bloquear/garantir que > ninguém tá atualizando algo enquanto rola a transferência )exigiam que vc > tivesse no "servidor-réplica" um BACKUP do Controlfile numa posição mais > antiga e daí, quando esse servidor for "assumir" como Produção, vc TINHA > que antes pedir o restore desse controlfile mais antigo e APLICAR os > archives daí em diante, o que Logicamente não era instantâneo... > > []s > > Chiappa > > >
