artigo sql magazine 51- Backup & Recover com RMAN

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Artigo da revista SQL Magazine edição 51.

Esse artigo faz parte da revista SQL Magazine edição 51. Clique aqui para ler todos os artigos desta edição

 

Oracle

Backup & Recover com RMAN

Parte II: Backup usando o modo ARCHIVELOG

 

Nesse artigo, vamos abordar as técnicas para realização de cópia (backup) e recuperação (recover) de banco de dados usando o SGBD Oracle no modo ARCHIVELOG, que é o modo mais utilizado ultimamente. Para lembrarmos, na edição anterior foi publicado o artigo “Backup & Recover com RMAN – Parte I”, onde trabalhamos somente com o modo NOARCHIVELOG.

Backup no modo ARCHIVELOG

Diversas empresas utilizam seus bancos de dados no modo ARCHIVELOG, pois trabalham no modo OLTP (On-line Transaction Processing). Isso permite recuperação em Point-In-time, ou seja, podemos recuperar o banco de dados até o último minuto antes do crash da instância, como citado no primeiro artigo, e diversas outras estratégias de recuperação, tais como:

·         TSPITR – Tablespace Point-in-Time recover: recuperação de tablespaces até o momento desejado ou até segundos antes do desastre.

·         Recursos de Flashback: para ambiente de alta disponibilidade, essa opção utiliza uma área de recuperação rápida (Flashback Area) onde podemos recuperar um banco de dados usando Flashback Database, tabelas com Flashback table ou até mesmo apenas alguns registros usando Flashback Query.

·         Change Tracking: recurso do RMAN que lhe permite recuperar apenas os blocos de dados que estão corrompidos no banco de dados.

 

No modo ARCHIVELOG, sempre utilizaremos os archives logs (ver Nota 1) para recuperação. É de extrema importância que todas as seqüências de archives logs geradas pelo Oracle, através do processo de background Archive Process (ARCn,  ver Nota 2), sejam armazenadas com segurança, pois no caso de qualquer perda de uma numeração de archive log, a recuperação será até o número anterior da seqüência perdida.

 

 

Nota 1. Archive Logs
Os archives logs são responsáveis por armazenar todas as alterações no banco de dados que foram registradas nos grupos de REDO LOGS. Assim sendo, para cada archive log criado, existe uma numeração de SCN (System Change Number) que pode auxiliar na recuperação do banco de dados para uma posição desejada.

 

Nota 2. Archive Process
O Archive Process é um processo de plano de fundo da instância Oracle responsável pela cópia dos arquivos de redo log para uma área determinada no servidor. O destino é especificado pelo parâmetro LOG_ARCHIVE_DEST da instância.
O archive log é gerado depois de ocorrer a troca do arquivo redo log pelo Archive Process. Uma instância Oracle pode ter de 1 a 10 processos de Archive Process, ou ARCn (ARC0 até ARC9), e esse processo só pode ser habilitado com o banco de dados no modo archivelog.

 

Utilizando o mesmo banco de dados do artigo anterior, chamado RANET, iremos neste artigo criar uma estratégia de recuperação onde serão utilizados backups incrementais, archives logs e backup de tablespaces específicas.

Para melhorar o entendimento dos processos de recuperação, a Tabela 1 contém o cenário que iremos seguir com os dias da semana e os tipos de backup a serem realizados no banco de dados. Isso permite ao DBA boas opções de recuperação com segurança.

 

BACKUP

Segunda

Terça

Quarta

Quinta

Sexta

Sábado

Domingo

Incremental nível 0

 

 

 

 

 

 

X

Incremental nível 1

X

X

X

X

X

X

 

archive

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?