Menu de navegação

[Edgar Rombesso RisolaParticipante]

Possuo um ambiente de produção e preciso clonar o banco de dados para o ambiente de homologação que é em um servidor diferente. Alguém teria um procedimento passo a passo para ajudar?

PRODUÇÃO:
IP: 10.20.253.10
HOSTNAME: BDPROD
Oracle: Database 10g 10.2.0.5 – 64 bits Standard
Instancia:manprod
S.O: Suse Linux Enterprise 10 R2 64 Bits
Estrutura de diretorios: /u1/oradata/manprod_data/

HOMOLOGAÇÃO
IP: 10.21.253.92
HOSTNAME: BDHOM
Oracle: Database 10g 10.2.0.5 – 64 bits Standard
Instancia:manprod
Estrutura de diretorios: /u1/oradata/manprod_data/

[José Laurindo ChiappaModerador]

Já que afora o IP e o hostname entendo que ** todos ** os outros pontos do hardware e do Sistema Operacional são Rigorosamente os mesmos, E QUE vc quer ter um clone exato do banco E da instância prod no servidor homo (servidor esse que é idêntico ao PROD exceto por IP e hostname, repito) eu entendo que a sua melhor opção é simplesmente voltar no servidor homo um backup de prod, é isso…. Tal estratégia ainda te daria a vantagem de servir de TESTE pra sua rotina de backup, ainda por cima…
O procedimento básico seria :

a. enviar pro servidor Homo os conjuntos mais recentes de arquivos de backup TODOS (ie, backup de banco, backup de archivelog se necessários, backup de controlfile, backup de initfile/spfile). Esses conjuntos devem estar Íntegros, ie : vc tem que ter certeza de que os archives necessários para o SCN de cada datafile estão presentes, que o controlfile não foi tomado num SCN anterior ao início do backup de datafiles, enfim, se assegurar que não é lixo digital que vc tem em mãos….
CASO não tenha certeza, é até válido de repente vc fazer um backup seu agora, completo, ao invés de confiar no passado, e depois enviar esses arqs de backup pro servidor remoto

b. parar a instância manprod que eventualmente estiver rodando no servidor homo

c. restaurar os backups no servidor Homo, e se necessário fazer o recover

d. subir a instãncia

===> Pra gente poder de dar um passo-a-passo melhor/mais detalhado, vc TEM que nos mostrar exatamente quais são os comandos de backup que vc faz hoje (listando o script de comandos em uso, inclusive especificando o tipo de backup, se é online ou com banco parado, se usa FRA ou não, se é em modo archive ou não, se vai pra disco ou pra fita, frequência de backups, se é Incremental ou full a cada vez, se os backups vão prum catálogo RMAN ou não, etc – DETALHES todos plz) que só aí a gente pode indicar uma ref com o passo-a-passo – AO CONTRÁRIO do que muita gente menos experiente pensa, CADA AMBIENTE é único, cada banco tem necessidades ESPECÍFICAS muitas vezes, cada aplicação/empresa tem regras únicas, RIGOROSAMENTE nÃO DÁ pra ter uma rotina de backup one-size-fits-all….

[]s

Chiappa

OBS :

1) acima eu estava pensando principalmente em backup RMAN, que é o padrão para o RDBMS Oracle, mas que fique Claro que logicamente é Sim possível (se vc não usa ASM) vc fazer um backup a nível de sistema operacional, normalmente cold (ie, feito com banco parado), zipar/fazer um tarball desses arquivos de SO e enviar (via ftp ou como puder) pra outra máquina…. Feito isso é só expandir os arquivos lá e subir a instância e abrir o banco

2) se vc tem conexão de rede entre as máquinas prod e homo, uma Outra opção poderia ser usar o comando DUPLICATE do RMAN : ele deve ser entendido como uma “automação” do método de restauro de backup, o que o comando faz é gerar pra vc um backup, enviar pela rede e o restaurar no destino….
EU cito essa possibilidade apenas por questão de complementação, para que a resposta fique mais rica, mas Torno a recomendar que vc use seus backups mesmo, até para os testar como eu disse

[Edgar Rombesso RisolaParticipante]

Então…o hardware é diferente…o servidor de homologação é virtual….enquanto o de produção é físico…No momento meu backup teria que ser HOT…não posso parar o servidor para efetuar cópias no momento…
Atualmente ele possui um padrão de backup que desconheço e não tenho acesso momentâneo…
Existe a comunicação entre os servidores a nível de rede, pensei no rman com duplicate também…
A estrutura seria praticamente a mesma a nível de diretórios e arquivos. A diferença ocorre apenas nos ip´s e endereço web de acesso à base, mas são itens que não gera impacto grande de alteração manual. Na verdade a única coisa que seria preciso são os dados contidos em cada tabela da instancia de produção ser restaurada na instancia de homologação.

[José Laurindo ChiappaModerador]

Bom, antes de te responder eu ** tenho ** que Observar que se vc é o responsável por manter esse ambiente aí, NÂO EXISTE essa de padrão de backup que desconhece, Demorou pra vc levantar isso, OU mesmo jogar fora o que existe e criar um novo…. O que NÂO PODE é vc não saber na ponta da lí9ngua TUDPO o que se refere á backup : é aquela coisa, se vc cometer um erro de tuning, tem como alterar/consertar, se vc cometer um erro de programação também , MAS se vc cometer um erro de política de backup e restore e por causa disso vc perder dados, é bilhete Azul, é rua na hora….. Backup e restore é CRÍTICO, isso são dados da empresa, é perda de receita e incapacidade de fazer negócios se isso é perdido…

Muito bem : primeiro, não sei o que vc quer fazer nesse novo ambiente mas o nome de HOMOLOGAÇÃO normalmente implica que vc quer rodar uma aplicação nele para tentar SIMULAR o que vai acontecer em produção, perceber erros antes que eles aconteçam em prod, tentar PREVER a performance quando o negócio for rodar em prod….

SE é isso que vc quer aí :

a) com certeza se seu objetivo é isso aí de cima , nesse caso vc NÃO precisa apenas só “dos dados contidos em cada tabela”, não senhor : pra vc poder testar/prever performance/etc (enfim, Homologar) vc PRECISA dos sinônimos, PRECISA dos índices, PRECISA das contraints, PRECISA dos schemas/usuários de conexão, dos schemas….. NÂO É só dados

b) com ABSOLUTA certeza também, a sua aplicação *** NÂO DEVE PRECISAR ** de ** cada ** uma das tabelas RODAS que existem num database Oracle : há um MONTÃO DELAS que são tabelas internas, usadas apenas para auto-controle do database pelo software de RDBMS Oracle…. Se te falaram que quyerem TODAS as tabelas, com certeza quase que ABSOLUTA quem te disse isso não entende esse conceito….

c) o Certo, o Ideal, Correto, Prático e Recomendado para que vc possa Homologar (e aqui, repito, HOMOLOGAR tem as implicações e objetivos que citei acima) é que o servidor de Homologação seja EXATAMENTE e PRECISAMENTE IGUAL ao de PROD : é meio ÓBVIO que se vc tem hardwares ou softwares ou quantidades de usuários ou volume / valores / dados diferentes entre PROD x HOMO, ou clientes que não os de Prod ou coisas assim vc ** NÂO VAI CONSEGUIR ** prever o que vai acontecer em PROD a partir de uma execução do aplicativo em HOMO, pois condições diferentes LOGICAMENTE podem dar performances diferentes, erros diferentes….
Tá claro isso, que homologando num ambiente minimamente diferente vc introduz uma variável de indeterminação aí ???? E Sorry, mas se vc não tá 100% certo de que as condições são Iguais, na prática vc tá fazendo uma homologação de FANTASIA, algo pró-forma, só pra Inglês ver, pois NÃO TEM COMO vc ter certeza que os teus testes e análises em HOMO vão se repetir em PROD ???
Isso imho é Básico….

==> Isso posto, a sua Resposta : como às vezes é meio difícil vc extrair dos desenvolvedores/analistas/usuários uma lista completa de tudo o que a Aplicação precisa e/ou de quais tabelas/schemas a aplicação precisa, por isso eu diria pra vc usar alguma opção de clone completo, recriando no destino não só as tabelas mas os índices, copnstraints, sinônimos, tablespaces, schemas, enfim, tudinho…. Muito disso talvez não seja necessário, rigorosamente falando, mas como é meio difícil o pessoal te dar essa informação decentemente, manda tudo pra homo….
LOGICAMENTE, pra que vc possa mandar TUDO pra HOMO/fazer um clone completo, a primeira coisa necessária é que, mesmo o hardware sendo diferente, ele AO MENOS tem quer ter a MESMA CAPACIDADE de Prod, ou maior …. Assim, para permitir o clone completo o servidor HOMO tem pelo menos que ter a MESMA CAPACIDADE DE RAM que prod, pelo menos o MESMO espaço livre em disco que PROD… OK ? Isso é Óbvio, afora casos Graves de fragmentação / mau-uso de espaço, não é porque vc tá clonando que magicamente os dados que ocupavam x gigabytes no server PROD vão ocupar alguma coisa Significativamente menor, Óbvio…

Continuando a análise, vc diz também que não pode “parar o servidor para efetuar cópias no momento” – entendo que não é SERVIDOR que vc se refere, sim sim DATABASE, é o DATABASE que vc não pode parar, creio…
Sendo isso, saiba que a opção de fazer um DUPLICATE online, sem parar/indisponibilizar o banco, só existe no banco 11g , com a sintaxe DUPLICATE ACTIVE DATABASE – como vc já disse que é 10g, miou essa Opção…

Nesse cenário, somando a exigência de clone online com teu desconhecimento da política e procedimentos de backup atuais (se é que existem), pra mim vc VAI TER QUE fazer mesmo que fazer um backup hot seu, aí na mão, enviar os arqs desse backup pro servidor HOMO e restaurar o backup lá, é isso….

Pra gente poder te dar um passo-a-passo de como fazer isso mais detalhado, renovo o pedido : PLZ nos diga se vc usa catálogo RMAN ou não aí, se vc usa ASM ou não, se o banco está em modo archive ou não, se vc tem FRA setada ou não, nos diga se vc tem fita de backup aí ou se vai ter que ser backup pra disco (e CONFIRME que vc tem uma área livre adicional afora a dos datafiles de tamanho suficiente pra manter/criar os arquivos de backup, se for pra disco)….. APENAS com essas infos é que podemos tentar detalhar mais/indicar uma ref mais apropriada….

[]s

Chiappa

[Edgar Rombesso RisolaParticipante]

Então…

Não tem catalogo RMAN
Não tem ASM
Banco em modo archive
FRA não está setada
Backup para disco é o que será usado inicialmente
área livre adicional de 500GB disponível na partição(mais do que suficiente)
Sim…verificando …não é somente dos dados que se necessita….todos objetos, pois ocorrem alterações em sequences por exemplo…

[Edgar Rombesso RisolaParticipante]

Então jlchiappa,
Resolvi fazer a clonagem do ambiente copiando os datafiles…tem um passo a passo de como devo fazer isso? parece-me que devo usar o ALTER DATABASE BEGIN BACKUP correto?

[José Laurindo ChiappaModerador]

Sim , entre outras coisas será necessário pedir um BEGIN BACKUP para cada tablespace (ou ALTER DATABASE BEGIN BACKUP, que já serve para todas as tablespaces) : a Razão disso é Conceitual : para melhor performance, no RDBMS Oracle quando vc comita uma Transação as alterações/inclusões/deleções feitas *** podem não ser gravadas *** diretamente nos datafiles, mas sim fiquem num CACHE de memória, o log buffer – aí, depois disso, lentamente e em background, o RDBMS vai gravando nos datafiles as alterações que estão no log…. Assim sendo, vc NUNCA sabe num dado momento se o RDBMS vai precisar ou não gravar algo nos datafiles, sem o comando BEGIN BACKUP (que “interrompe” o processo de gravação / atualização dos datafiles) vc correria sérios riscos de que o RDBMS resolvesse gravar nalgum datafile da mesma tablespace que vc está copiando, o que resultaria quase que certamente em CORRUPÇÃO, sim….

Vc deve notar, porém, que há MAIS ALGUNS conceitos fundamentais do RDBMS Oracle que vc TEM que conhecer pra poder fazer em segurança e de modo íntegro a operação pretendidada :

1) um database gerenciado pelo RDBMS Oracle consiste NÂO APENAS de datafiles, mas também de um conjunto de arquivos que LISTA e controla as características dos datafiles (os chamados CONTROLFILEs), um arquivo que contém os parâmetros de inicialização (o initfile, que pode ser do tipo pfile ou do tipo spfile), um Conjunto de arquivos com os logs de alteração (os REDO LOG FILES), as cópias dos log files que encheram (os ARCHIVED REDO LOG FILES)…. SE vc copiar APENAS e TÃO SOMENTE os datafiles, SEM os controlfiles correspondentes que registram a posição mais recente dos datafiles, SEM os inits, SEM os redo log, vc vai obter **** LIXO DIGITAL ****, tá bem ??? Isso vale pra todos mas Principalmente para os controlfiles, pois normalmente a cada poucos segundos o RDBMS grava no controlfile qual o último byte/posição/”data/hora” gravado no datafile a partir do buffer, grava o status do database como um todo, sem isso o datafile em si é INÚTIL, não tem como vc o abrir…
Dada essa situação, fica Patente que se os teus datafiles todos estão abaixo de /u1/oradata/manprod_data/ ok, vc os copia, MAS TAMBÉM vc ** PRECISA ** descobrir onde estão os seus controlfiles, seus archives, seu initfile, etc, E OS TEM QUE COPIAR TAMBÉM… okdoc ??? Inclusive, essa é uma vantagem do RMAN, ao vc dar o comando BACKUP DATABASE PLUS ARCHIVELOG; no RMAN corretamente configurado o próprio RMAN já sai procurando fisicamente onde estão os controlfiles, os archives, etc, e já os copia , SEM que vc tenha que indicar isso – se vc optar por copiar os arquivos manualmente, é por sua conta consultar as views/tabelas internas do database (e o arquivo de inicialização, talvez) pra descobrir onde está sendo criado/mantido cada aqruivo que compõe o database…

2) para vc abrir um database, os binários do RDBMS Oracle tem que estarem carregados pra memória (formando o que chamamamos de INSTÂNCIA) , e os arquivos todos que compõe o database precisam ser Lockados pelos binários do RDBMS Oracle : assim sendo, se lá na máquina destino vc já tiver uma instância manprod Ativa abrindo um database, *** ANTES *** de vc copiar os arqs do database prod pra máquina destino vc ** PRECISA ** fechar esse database e desligar a instância nesse servidor destino – imagino que tarefas simples do tipo vc sabe como fazer

3) ainda por questão de performance E segurança, via de regra o conteúdo do log buffer em memória é a cada poucos segundos (ou após um COMMIT, isso é configurável) copiado para um dos redo log files, E assim que o redo log file fica cheio (ele tem um tamanho fixo, configurável) o RDBMS faz uma cópia dele, como archived redo log file – assim, para que vc possa Restaurar um backup CERTINHO, com todas as operações comitadas presentes, aém dos datafiles vc PODE PRECISAR também dos archived redo log files…. Não é incomum num banco Oracle muito ativo que fisicamente haja um datafile que só foi atualizado há, digamos, umas dez horas atrás, num caso desses além da cópia do datafile em si vc *** PRECISARÁ *** dos archives todos dessas últimas dez horas, SEM FALTAR NENHUM, okdoc ??? E pra marcar a “data/hora” que um datafile foi refrescado, o RDBMS Oracle não usa a data/hora do servidor, mas sim um sequencial interno próprio dele, o chamado SCN…
Como vc diz que não sabe a política de backup em uso nesse banco prod, sabe-se lá se vc vai ter em disco ainda *** TODOS *** os archives necessários para atualizar os datafiles copiados do SCN em que eles estão até a posição atual, do SCN quando começou o backup…. para vc pesquisar se vc tem os archives todos em disco basicamente é consultar a v$archived_log pra ver qual SCN está em cada archive, e a V$DATAFILE e a V$TABLESPACE para ver os SCNs fisicamente registrados nos datafiles, veja o manual de “Backup e Recover” para mais detalhes e info…

===> Com esses Cruciais conceitos compreendidos, http://blogs.adobe.com/shwetank/2011/10/19/manual-backuprestore-of-an-oracle-11gr2-database/ é um exemplo de como vc faria as consultas necessárias e como implementaria a sequência necessária para um backup externo ao RDBMS, via cópia de arquivos , que seria basicamente ALTER DATABASE BACKUP, cópia dos datafiles, cópia do initfile, Alter system archive log current, cópia do controlfile com Alter database backup controlfile to’pathdesejado’, e finalizando com a cópia dos archived redo log files….

E é claro : se vc levar em conta todos os checks que vc tem que fazer, E o risco de alguém alterar path/nome de algum dos diversos arquivos necessários na origem e esquecer de o fazer no banco-destino, imho ainda é um pouco mais simples fazer o backup via RMAN : http://www.thegeekstuff.com/2013/08/oracle-rman-backup/ é um exemplinho, que vc pode customizar alterando o FORMAT para indicar a área onde os arquivos de backup vão ser gravados… Depois de copiar/transferir os arquivos do backup pro servidor destino, se a área/diretório onde estarão os arquivos do backup for a mesma/tiver o mesmo nome, lá é fazer um RESTORE do controlfile (que já vai ter o backup catalogado nele), restore database, restore dos archives e recover database, http://www.oracledistilled.com/oracle-database/restore-database-to-another-host-using-rman/ exemplifica…

[]s

Chiappa

OBS :

é importante notar que nenhuma das opções Não é difícil de se implementar, mas quem vai o fazer ** TEM ** que ser um DBA com um mínimo de experiência, não dá pra te dar um step-by-step ao nível de bê-a-bá mais basico possível – afinal de contas, por mais que muitos desconheçam, um SGBD é um *** TANTINHO ** mais complexo do que um editor/controlador de arquivos apenas, E é programado para operar num nível de performance/eficiência/segurança MUITO mais alto do que um gerenciador de arquivos, então daí decorrem esses conceitos todos que Proíbem que vc só copie os datafiles a acabou, sim sim ?? Portanto, minha Recomendação se esse banco é de importância, seria que vc chamasse um DBA mais experiente para fazer as verificações pra vc antes, que automatizasse via scripts…

[Autor]

Posts