Tuesday, December 9, 2008

Estratégia de backup

Vou apenas descrever uma estratégia de backup a qual é realizado um misto de backup diferencial e cumulativos, com o banco é claro em archivelog, com o propósito de impactar o quanto menos a base de dados em produção e proporcionar um tempo razoável de restore.

Convenções

Full backup - Todos os blocos usados de todos os datafiles. OBS - Não pode ser usado como base para backups incrementais.
Level 0 incremetal backup - Equivale ao full backup, porém é marcado como level 0. OBS - Pode ser usado como base de backup incrementais.
Cumulative level 1 - Todos os blocos modificados após o backup level 0.
Diferential level 1 - Todos os blocos modificados após o utimo backup incremental.

Retenção

A politica de retenção pode ser configurada com o comando configure retention policy no rman, o que irá determinar no report e no delete a nossa politica de backup. A retention policy somente é aplicada para backups full, level 0 datafile e control file, em casos de backup incrementais level 1 e archives não será aplicados politicas de rentenção já que os mesmos se tornão inválidos após a remoção de backup level 0.
Se utilizado a flash recovery area durante os backups, o comando delete não apenas remove a entrada no control file ou catalog como também remove o arquivo do SO.

Na nossa estratégia de backup iremos utilizar um misto de backup incrementais, utilizaremos backups cumulativos duas vezes durante a semana, e quatro backups incrementais e um backup incremental level 0.

level 0 level 0
|<------------------------------------------------------|
| | | | | |<----| |
|<---------------------------------| | |
| | | |<-----| | | |
|<-------------------| | | | |
| |<-----| | | | | |
|<---- | | | | | | |
LVL 0 1 1 1C 1 1C 1 0
DAY Sun Mon Tue Wed Thu Fri Sat Sun

Comparações entre o backup cumulativo e o diferencial.

  • O backup diferencial é o mais rápido backup, ocupa menos espaço, porém em operações de recover é mais lento em relação o cumulativo, pois há a necessidade de se aplicar o outros backups incrementais.
  • O backup cumulativo é o mais lento e ocupa maior espaço, porém em operações de recover é favorecido em relação ao tempo.

Durante o processo de backup, o rman precisa fazer um full scan em todos os datafiles. Para reduzir o tempo de cpu e o tempo dos backups incrementais pode ser aplicado um feature do Oracle, o Block Change Tracking, o qual consiste em armazenar em uma arquivo todos os blocos modificados, a fim não haver mais a necessidade da leitura completa dos datafiles, podemos imaginar esse arquivo como um indice, onde o qual feito a leitura é indicado somente os blocos modificados e necessário para o backup, reduzindo assim o tampo de backup e ciclos de cpus.

Habilitando o block change tracking:

Temos o seguinte procidento:

SQL> ALTER DATABASE ENABLE
2> BLOCK CHANGE TRACKING
3> USING FILE '/MYDIR/MYFILE.DBF'
4> REUSE;

Caso esteja usando Oracle Manage Files, o parametro db_create_file_dest esteja ativo não há necessidade de indicar o arquivo.

O tamanho do arquivos do block changing tracking depende não da utilização do banco, mas sim, da retenção de seus backups e o tamanho da base de dados.

Backup sintaxe

O procedimento de backup no rman é muito simples, a seguir temos as tres sintaxes necessárias para nossa estratégia de backup:

RMAN> BACKUP AS COMPRESSED BACKUPSET TAG 'WEEKLY' INCREMENTAL LEVEL 0 DATABASE PLUS ARCHIVELOG DELETE INPUT;
RMAN> BACKUP AS COMPRESSED BACKUPSET TAG 'DAILY DIF' INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG DELETE INPUT;
RMAN> BACKUP AS COMPRESSED BACKUPSET TAG 'DAILY CUM' INRECMENTAL LEVEL 1 CUMULATIVE DATABASE PLUS ARCHIVELOG DELETE INPUT;

O conjunto de procedimentos anteriores são uma amostra de como podemos realizar nossa estratégia de backup, vamos estudar parte a parte.

O parametro AS COMPRESSED é utilizado para comprimir o backup, reduzindo o tráfego na rede e reduzindo o espaço do arquivo de backup, porém torna operações de backup e recover mais lentas.

TAG é utilizada para colocar um apelido no backup, o que pode tornar mais fácil para administrar os backups.

O comando PLUS ARCHIVELOG realiza o backup dos archives logs, o DELETE INPUT remove os archives recém backupeados, assim reduzindo a ocupação em disco.

INCREMENTAL LEVEL [0|1] é o tipo de backup.

BACKUP DATABASE, chama a operação de backup.

Para tornar nossa estratégia de backup completa, é essencial realizar o backup do controlfile. Podemos então configurar o rman para faze-lo, dentro do rman, podemos usar o show all, o qual irá nos mostrar os nossos parametros de backup, o parametro CONTROLFILE AUTOBACKUP é o qual determinará se é realizado ou não o backup do controlfile, se habilitado, a cada backup do banco é feito então o backup dos controlfiles, assim como o backup também do seu arquivo de parametro. Para habilita-lo é feito o comando:

CONFIGURE CONTROLFILE AUTOBACKUP ON;

Para voltar ao padrão, CONFIGURE CONTROLFILE AUTOBACKUP CLEAR;

Simulando falhas:

Imaginemos a seguinte situação, nossa estratégia de backup está em prática há alguns meses, perdemos um datafile de uma de nossas tablespaces na quinta-feira, e estamos na sexta, precisamos voltar o banco em seu estado consistente. Para isso iremos realiza o restore do backup incremental level 0 do domingo, o rescover do backup incremental cumulativo level 1 da quarta, recover do backup incremental diferencial level 1 da quinta, aplicar os archives necessários e se necessário os redo logs.

Pois ai está uma estrágia de backup a qual venho estudando e pode ser satisfatória, dependendo do ambiente.

c-ya.

Referencias:

http://www.oracle.com/technology/oramag/oracle/04-nov/o64rman.html
Manuais Oracle.

2 comments:

Alberto said...

Se eu quisesse restaurar esses backups em outra maquina, como faria? Qual seria os comandos de restauração?

Diogo Hikaru Nomura said...

Desculpe a demora ao responder, porém para restaurar esse backup, caso o mesmo foi feito a fita, na maquina onde você deseja restaura-lo você deve configurar o SO e as variaveis de ambiente do Oracle como ORACLE_SID e ORACLE_HOME, realizar os apontamento necessário para fita e conectar no catalogo ( Só pode ser recuperado o controlfile pelo RMAN através do catalogo ) e realizar os mesmos comando utilizados para restaurar em produção, basicamente, abrir o banco em nomount com o spfile de produção, restaurar o controlfile, colocar em mount, restaurar os datafiles, aplicar archive e abrir com resetlogs. Com relações a backup incremental o próprio rman pelo restore database irá procurar qual backupset ele irá utilizar, e não é necessário nenhuma configuração a mais, basicamente dentro do RMAN seria:

run {
starup nomount;
restore controlfile from autobackup;
alter database mount;
restore database;
recover database;
alter database open resetlogs;
sql 'alter system switch logfile;
}