Menu de navegação

[mpvargasParticipante]

Caros Amigos,
Gostaria de alguma dica pra duplicar uma base sem uso do Data Guard.
… sei que existem alguns tópicos relativos a esse assunto, mas gostaria de saber se alguém tem algum exemplo para que eu possa aplicar aqui na empresa. Obrigado.

[rmanParticipante]

@mpvargas

Qual é o objetivo em duplicar o banco ? É para criar um banco de teste/homologacao/desenvolvimento ?

Da para fazer por DataPump ou RMAN.

[mpvargasParticipante]

@rman
gostaria de ter uma base no servidor de desenvolvimento para uso dos analistas e que essa base fosse “a mais próxima” possível a nível de atualização da base de produção… na verdade gostaria de atualizar essa base todos os dias durante a madrugada, para que no dia seguinte pela manhã ela esteja similar a produção…
a minha base tem aprox 200 GB.
E queria saber também se com essa duplicação eu consigo atualizar essa base aplicando os logs (archives e redo) no caso de crash da produção?
Obrigado pela ajuda.

[msantinoParticipante]

@mpvargas,

Acho que você está misturando as 2 coisas: Ambiente de desenvolvimento e ambiente de standby.

Um banco em standby para aplicação de logs (archives) não pode ser aberto, portanto não pode ser consultado e não serviria pra sua equipe de desenvolvimento.

Já no banco de desenvolvimento, como o própprio nome já diz, geralmente é para os desenvolvedores fazerem novas modificações antes de entrar em produção. E uma vez aberto esse banco e alterado, não tem como aplicar archives para servir como stand by.

Minha sugestão é que você valide se serão feitas alterações por parte da equipe de DEV nessa base. Se forem, agendar com eles uma atualização periódica dessa base, pois se não eles perderão tudo que fizerem no dia seguinte, após o novo restore. Se não forem feitas alterações, você então poderá pegar um backup full do RMAN e restaura-lo no servidor de desenvolvimento. É o processo mais rápido pra isso…

O DATAGUARD na verdade seria pra manter o ambiente de standby, que faz o controle da aplicação dos archives automaticamente pra você não precisar criar rotinas manuais pra isso (bem resumidamente, é claro! rs…)

Você pode até criar uma nova instância nesse mesmo servidor de desenvolvimento pra servir como stand by. Nesse caso, você teria 2 instâncias, sendo uma delas aberta para utilização e a outra em recovery mode com a aplicação dos archives.

Tenho alguns ambientes assim aqui aonde trabalho e funciona na boa…

[mpvargasParticipante]

@msantino
obrigado pela dica…
Na verdade não misturei não… acho que me expressei mal…
Ainda não temos o DataGuard aqui na empresa, mas pretendemos implementar e quando o fizermos essa questão será resolvida, porque teremos a base stand by (data guard) que estará atualizada e servirá para consulta e uma outra base que atualizarei conforme solicitação…
O que eu preciso é de uma forma de tentar manter uma base de “STAND BY” sempre atualizada, usando rman duplicate, expdp ou cópia física, tanto faz… desde que eu consiga colocá-la em produção com aplicação de archives e redos… com isso eu consigo minimizar o tempo de recuperação.
Gostaria de “simular” o data guard… no caso eu teria essa base standby “parada” para uma possível recuperação em caso de crash.

[msantinoParticipante]

@mpvargas,

Entendi, mas ainda assim acho que você não está entendendo que, uma vez que você abra a base de dados pra consultas, ou seja, “ALTER DATABASE OPEN”, você não consegue mais aplicar archives nela.

Você pode ter uma base em stand by mesmo sem o dataguard. Eu mesmo mantenho algumas assim, pois em alguns clientres não foi possível colocar o dataguard. Então como funciona:
– A base de produção está em archivemode
– Todos os archives gerados são enviados (RSYNC ou SCP) pro servidor de standby
– Na maquina de standby, o CRON (no caso do Linux) periodicamente (10 em 10 minutos, por exemplo) roda um script que verifica se há novos arquivos de archive em disco. Se existe, ele aplica os archives.

Dessa forma, ela está SEMPRE atualizada com a base de produção. Se a de produção cair, forçamos o envio dos ultimos archives pra o outro servidor e rodamos o script manualmente e abrimos a base. Só que essa base é exclusivamente para standby, ela não é aberta de forma alguma para leitura/escrita.

Quanto à máquina de desenvolvimento atualizada periodicamente, se o hardware for exatamente igual, você pode simplesmente para o banco de produção (se for possível, claro), copiar todos os arquivos do Oracle pra outra máquina de forma que fique exatamente igual à de produção e então subir nela! É meio feio mas funciona na boa! rs…

[rmanParticipante]

@mpvargas

Essa ultima técnica que o @msantino citou é o famoso COLD BACKUP gerenciado pelo usuário. O ponto que inviabiliza é a parada do banco de dados para a realização do backup.

[mpvargasParticipante]

@msantino @rman
blz… consegui compreender !!!
O cold backup não é viável pois não posso parar o banco…
Imaginei que fosse possível liberar pra consulta e tê-la como opção para uma possivel recuperação de crash… sendo assim, vou utilizar essa estratégia que você me passou como exemplo…
É possível esclarecer-me algumas dúvidas:

1) você cria o banco stand by e vai copiando os archives, mas tem algum momento que você atualiza seus datafiles, tipo, um COLD BACKUP… porque senão fica um acúmulo muito grande de archives, certo?

2) no caso de um crash, quando você executa um startup na banco standby ele funciona normalmente ou tem que mandar restaurar ou fazer recover… fiquei com essa dúvida por causa dos controles internos do banco, tipo SCN, etc

3) Com relação ao que está no redo log, é possível recuperar se copiar os redos também?

[rmanParticipante]

@mpvargas

1- É necessário apenas de um backup RMAN Full, o próprio archive log vai atualizar o datafile. Todo archive log deve ser aplicado no stand by, depois de aplicado pode ser descartado.

2- O Stand by nada mais é que um restore com recover infinito. O banco Stand by só é aberto se for usar ele, ou seja, quando a base de producao sofrer um desastre. No geral é assim, se faz um restore e todo archive log aplicado vem no recover.

3- Creio que não, o que ficar no redo log vai ser perdido, só vai ser possível pegar o que tiver no redo se você forcar a geração do archive log, mas dependendo do desastre você não conseguirá fazer isso.

[mpvargasParticipante]

OK @rman … Obrigado
Só mais uma dúvida pra finalizar:
O banco stand by deve ser criado com o RMAN Duplicate ou pode ser qualquer outro tipo de restore (RMAN Restore/Recover, impdp ou cópia física)?

[rmanParticipante]

@mpvargas

RMAN Restore/Recover é certeza.
RMAN Duplicate não tenho certeza.
IMPDP não é possível.
Cópia física não é possível.

[Ricardo Portilho ProniParticipante]

Para complicar um pouco mais a questão, o Oracle Database 11gR2 permite que um PHYSICAL STANDBY comporte-se como um banco de homologação (ou seja, aberto para escrita). Ao término da homologação, com um comando você o torna um STANDBY novamente. com mais um comando ele volta a ser homologação novamente, e por aí vai.
É o SNAPSHOT STANDBY.

http://docs.oracle.com/cd/E11882_01/ser … #SBYDB4802

[mpvargasParticipante]

hehehehe O Portilho complicou mais ainda…
bem… eu uso o 10g
só pra finalizar esse tópico, se eu quiser manter uma base stanby em outro servidor para simular o data guard, eu sigo os seguintes passos:
1 – Crio esse novo banco com o RMAN restore/recover
2 – Monto um script para copiar os archives
3 – Coloco esse script pra rodar de 30 em 30 minutos (por exemplo) pra atualizar os logs…
OK?

No caso de crash no banco de produção basta que eu aplique os archives e terei o banco recuperado

Obs.: Com relação ao banco standby, como ele deve ficar? OFF, Mount, Open

[msantinoParticipante]

É isso ai!

Mas no caso de crash, os archives que serão aplicados são apenas os que não foram dentro dos últimos 30 minutos. Mas a lógica é essa mesma.

Se não me engano, a base em standby ficará em mount. A galera ai vai confirmar p vc!

[Ricardo Portilho ProniParticipante]

O RECOVER só funciona com o banco de MOUNT.
Ele pode ser aberto com ALTER DATABASE OPEN READ ONLY. Se for aberto com ALTER DATABASE OPEN ou diretamente com STARTUP, ou seja, aberto para escrita, ele não pode ser utilizando como “StandbyPobre” novamente.

[Autor]

Posts