Menu de navegação

[HitotuziParticipante]

Boa tarde!

As tabelas de um schema foram removidas do banco possuo um backup RMAN full (level-0) e três backups incrementais diferenciais (level-1), baixei o banco e iniciei no estado “mount”, executei o comando “restore database;” e em seguida “recover database;”. Executou normalmente, não ocorreu nenhum erro, porém, as tabelas não retornaram… Alguém poderia me ajudar? Está faltando incluir algum comando no procedimento de recuperação pelo RMAN?

[caadecarvalhoParticipante]

Olá, Hitotuzi.

Provavelmente você não definiu uma data no passado pra fazer a restauração do banco e o mesmo trouxe até o presente. Utilize a instrução abaixo para fazer isso, porém substitua a data para a que desejar, também estou alocando cinco canais para efetuar esta recuperação:

run {

allocate channel ch01 type disk;
allocate channel ch05 type disk;
allocate channel ch03 type disk;
allocate channel ch04 type disk;
allocate channel ch05 type disk;

set until time “to_date(’10/10/2014′,’dd/mm/yyyy’)”
restore database;
recover database;

release channel ch01;
release channel ch02;
release channel ch03;
release channel ch04;
release channel ch05;

}

Abraços.

[rmanParticipante]

@Hitotuzi

É necessário você saber o momento em que ocorreu a remoção das tabelas, siga a dica do @Carlos Anibal Amaral de Carvalho.

Como não foi especificado um ponto no tempo ao fazer o RECOVER foi atualizado até o momento atual. Logo passou novamente pela remoção das tabelas.

[HitotuziParticipante]

Obrigado @Carlos Anibal Amaral de Carvalho e @rman!

Vou testar o procedimento e postar o resultado.

[HitotuziParticipante]

Boa tarde @Carlos Anibal Amaral de Carvalho e @rman!

    Obrigado pela dica, consegui recuperar as tabelas removidas com o procedimento indicado, porém, só funcionou quando eu removi os comandos "allocate channel" e "release channel". Agora que estou me aprofundando mais no RMAN, então ficou a dúvida, porque devo alocar canais? e o que seria o "release channel"?

[rmanParticipante]

@Hitotuzi

Geralmente para ter acesso a qualquer recurso que use paralelismo é necessário a versão Enterprise. Neste caso também.

Na versão Standard é possível utilizar apenas 1 canal, talvez seja isso a causa do erro que você viu.

Canal seria como se fosse thread.

RELEASE CHANNEL é a liberação do canal. Primeiro você aloca com ALLOCATE CHANNEL e depois você libera.

Você não faz backup lógico com o Datapump? Caso não faça, é um bom complemento na estratégia de backup.

Como neste caso foi uma falha lógica, seria mais simples utilizar o backup lógico, ao invés de utilizar o backup físico.

No caso do restore do backup físico o database inteiro voltou na posição do tempo antes da falha lógica. Talvez isso não seja interessante. O que você precisava mesmo era voltar as tabelas eliminadas.

[HitotuziParticipante]

@rman,

      Obrigado pelo esclarecimento, faço backup lógico com o Datapump, porém, estou com um problema, meu banco está grande, 260GB e para compactar esse backup diário com o "rar" leva muito tempo e esse processo acaba usando bastante recurso (processamento) do servidor, por consequência a aplicação fica lenta. Foi então que testei fazer backup full com o rman 1 vez na semana (domingo) e diariamente, backups incrementais diferenciais, para que o processo de backup diário libere recurso da máquina mais rápido, assim não prejudicando as atividades dos usuários pelo sistema. 
      Foi então que fiz o procedimento em um ambiente de teste fazendo o backup e recovery com o RMAN. Não sei se essa estratégia será a mais adequada e mais segura, analisando esse meu cenário, qual a sua opnião?

[HitotuziParticipante]

@rman,

      Obrigado pelo esclarecimento, faço backup lógico com o Datapump, porém, estou com um problema, meu banco está grande, 260GB e para compactar esse backup diário com o "rar" leva muito tempo e esse processo acaba usando bastante recurso (processamento) do servidor, por consequência a aplicação fica lenta. Foi então que testei fazer backup full com o rman 1 vez na semana (domingo) e diariamente, backups incrementais diferenciais, para que o processo de backup diário libere recurso da máquina mais rápido, assim não prejudicando as atividades dos usuários pelo sistema. 
      Foi então que fiz o procedimento em um ambiente de teste fazendo o backup e recovery com o RMAN. Não sei se essa estratégia será a mais adequada e mais segura, analisando esse meu cenário, qual a sua opinião?

[rmanParticipante]

@Hitotuzi

Realmente compactar um dump do Datapump leva tempo e gasta processamento. Aqui eu não compacto, será mesmo que você precisa compactar? Qual é a retenção desses dumps? O problema é espaço para armazenar e reter? Dependendo talvez é hora de comprar mais discos… Ficar sem fazer os dumps talvez pode custar mais caro… Pense que você precisa recuperar o banco no menor tempo possível. 1 hora com o banco de dados fora do ar representa quanto de prejuízo para o seu cliente?

O tratamento que faço é o seguinte, falha lógica se trata com backup lógico e falha física com backup físico.

Qual a versão do Oracle que você utiliza? Standard ou Enterprise?

[HitotuziParticipante]

@rman

Primeiramente obrigado pela resposta, respondendo suas perguntas, aqui, atualmente, eu preciso compactar devido o backup do schema em questão de 260 Gigas ser “full” através do “exp”, daí faço a compactação do mesmo para no dia seguinte quando o script de backup for executado pelo “crontab” ter espaço suficiente para o próximo backup. Atualmente no servidor só cabe o “dmp” de 260 GB + a compactação (rar) 28 GB gerada para o dia.

Então pelo que entendi, vc aconselha eu ter os dois backups, lógico e físico certo?

Possuímos o banco Oracle 11G Standard Edition e como vc falou, precisamos recuperar e realizar o backup do banco no menor tempo possível pois 1 hora com o BD fora do ar representa um alto prejuízo R$ :ohmy: . Assim preciso ver uma forma de realizar backups de um schema de 260 GB da forma mais rápida, que ocupem menor espaço possível em disco e que seja possível recuperá-lo em menor tempo possível… Esse é desafio… complicado :dry: …

[rmanParticipante]

@Hitotuzi

É complicado é fazer uma política de backup/restore com recursos físicos limitados. Bom é claro a necessidade de mais espaço para o dump.

Aqui nós temos um deduplicador da EMC. Faço um dump diário de 270 gb. Esse dump fica retido por 90 dias. O dump do dia primeiro de cada mês é copiado para fita e mantido para sempre. Faço também um backup físico diário e backup de archivelog a cada 30 minutos.

Uma pergunta, o servidor de aplicação fica na mesma maquina que o servidor de banco de dados? O ideal é ter uma máquina dedicada ao banco de dados, isso evitaria da aplicação ficar lenta no momento do backup do banco de dados.

Vou te dar um exemplo onde o restore de um backup físico não poderia ser aplicado, ainda mais com a versão Standard do Oracle Database. Vamos supor que existam 2 sistemas na empresa: Contabilidade e Folha de Pagamento. Foi removida 2 tabelas do sistema de Folha de Pagamento e foi percebido isso após um dia de trabalho. Se você voltar um backup físico até instantes do acidente você fará com que a Contabilidade perdesse horas de trabalho, pois o restore voltaria o database inteiro a um determinado ponto no tempo. Se fosse a versão Enterprise era possível fazer o restore por tablespace, isso evitaria perda de dados no sistema da Contabilidade. Se você fazer o restore de um backup lógico é possível voltar apenas essas 2 tabelas. Por isso é importante ter os tipos de backup implementado, o físico e o lógico. O lógico é um complemento de backup, e as vezes é mais simples e mais rápido fazer o restore dele.

[HitotuziParticipante]

@rman,

Agora clareou, obrigado pela dica, eu já ia cometer um vacilo fazendo apenas backups lógicos do meu banco. Nossas realidades são um pouco semelhantes pelo menos quanto ao volume dos dados que trabalhamos, o seu é de 270 GB o meu é 260 GB. Aqui, possuímos uma máquina copiadora de fitas da IBM que está parada, pois migramos os servidores de aplicação e banco de dados do Windows para o Linux e ainda não conseguiram instalar a mesma nessa nova plataforma. Vou tentar ativá-la e aplicar a mesma política de backup que vc faz. Mais uma vez muito obrigado pelas dicas!

1 abraço!

[Autor]

Posts