Pular para o conteúdo principal

Configurando a política de retenção de backups no RMAN

                      Configurando a politica de retenção de backups no RMAN


      O objetivo deste post é explicar como podemos configurar a retenção de backups na poderosa ferramenta de backup do bando de dados Oracle RMAN. Podemos configurar nossa política tendo por base dois tipos: janela de recuperação (recovery window) ou redundãncia (redundancy). Abaixo iremos abordar os dois tipos.


      Para identificar qual dos dois tipos o RMAN está usando, use:

RMAN> show retention policy;

Política baseada em redundância
CONFIGURE RETENTION POLICY TO REDUNDANCY 1;

Política baseada em janela de recuperação
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 DAYS;




·       Política baseada em redundância (REDUNDANCY)

      De uma maneira bem simples e objetiva, o parâmetro REDUNDANCY especifica quantos backups full ou incremental level 0 de cada datafile o RMAN vai manter, os demais são considerados obsoletos. Veja o exemplo abaixo para entender melhor.


     
      Vamos adotar a redundância 2 (REDUNDANCY 2).
      RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 2;

     
      Agora, imagine que realizamos 5 backups full do nosso banco de dados. Os backup foram realizados Segunda, Terça, Quarta, Quinta e Sexta-feira. Baseado na nossa redundância que é de 2, os backups de Quinta e Sexta serão mantidos e os demais serão marcados como obsoletos.






Vamos colocar na prática o exemplo citado.


No comando abaixo, estamos realizando o backup somente do datafile 4 e adicionando a TAG com os dias da semana. Logos após o backup, o RMAN irá listar um resumo dos backups existentes e na sequencia, irá apagar os obsoletos.


      run{
            backup datafile 4  tag = 'Segunda';
            backup datafile 4  tag = 'Terca';
            backup datafile 4  tag = 'Quarta';
            backup datafile 4  tag = 'Quinta';
            backup datafile 4  tag = 'Sexta';
            lista backup summary;
            delete backup obsolete;
            }








·       Política baseada em janela de recuperação (Recovery Window)

Especificando um valor para a janela de recuperação, você estará especificando um número de dias em que o RMAN deve armazenar backups para realizar um recuperacão na janela configurada.
Lembre-se que o RMAN nunca considera um backup full ou incremental de level 0 como obsoleto se ele estiver dentro da janela. Vamos usar nosso exemplo anterior para ficar mais claro.


Temos os mesmo 5 backups realizados, mas agora vamos alterar o retencão do RMAN para uma janela de 5 dias. Vamos imaginar que no sábado pedimos que o RMAN listasse os backups obsoletos. Neste, caso teríamos como obsoletos apenas a segunda-feira, pois está fora da nossa janela especificada de sábado até terça já temos os 5 dias citados na janela de recuperação.









·       Desabilitando a política de retenção


Caso precise usar o RMAN sem nenhum das políticas de retenção, basta usar:

CONFIGURE RETENTION POLICY TO NONE;

Lembre-se fazendo isso, você está desabilitando a política de retenção do RMAN. Após realizar esta alteração, os commandos REPORT OBSOLETE e DELETE OBSOLETE irão retornar um erro, pois não existe política ativa.

Comentários

Postagens mais visitadas deste blog

Permissões necessárias para criar triggers no Oracle

Há pouco tempo passei por um problema durante a criação de uma trigger de LOGON na versão 12c do banco de dados Oracle. Estava com alguns problemas em uma aplicação que tinha uma trigger de Logon. A trigger em si era bem simples, vou por o código mais abaixo, o problema é que ela estava criada dentro do usuário SYSTEM. Provavelmente foi a maneira mais fácil e preguiçosa de criar o objeto, uma vez que o SYSTEM já possui todas as permissões necessárias para criação. Porém isso não uma boa prática. Então resolvi tirar do SYSTEM e jogar para o usuário dono dos objetos da aplicação. Quando fui tentar criar o objeto no SCHEMA dono dos objetos da aplicação, recebi um erro com falta de permissões: ORA-01031: insufficient privileges . O erro ocorreu porque estava esquecendo de conceder a role ADMINISTER DATABASE TRIGGER para o usuário. Em resumo, as permissões necessárias para criação de uma trigger: CREATE TRIGGER - para criar uma trigger no seu próprio esquema (SCHEMA) CREATE AN

ORA-01623 ORA-00312 - Removendo redo logs

Após realizar um restore de um ambiente de Oracle RAC para um single instance usando snapshot de storage, tentei recriar os redo logs recebi o seguinte erro durante a exclusão de um grupo de discos. SQL> alter database drop logfile group 2; ORA-01623: o log 2 é o log atual para a instância UOW (thread 1) - não é possível eliminar ORA-00312: thread 2 do log 1 on-line: '+DATA/UOW/ONLINELOG/group_2.1638.1051804433' ORA-00312: thread 2 do log 1 on-line: '+DATA/UOW/ONLINELOG/group_2.981.1051804433' O erro quer dizer que o grupo de redo pertence a outra thread. Quer dizer que ele pertence a outra instância do ambiente RAC. Como no meu caso não precisarei mais dela, basta usar o comando: SAL> alter database disable thread 2; Database altered.   Usei o SQL abaixo para gerar os comandos para excluir os redo logs SQL> select distinct 'alter database drop logfile group '||(group#)||';' from v$log where thread#=2; 'ALTERDATABASEDROPLOGFILEGROUP'||(G