terça-feira, 30 de novembro de 2010

ORACLE RECOVERY MANAGER ( RMAN ) - Oque devo saber? - Parte V

Olá pessoal, vamos dar sequencia então a nossa saga.

Espero que apreciem.

RETENTION POLICY - Particularidades

Bem, já falamos anteriormente sobre politicas de retenção, mas foi apenas um breve OVERVIEW, vejamos mais a fundo o que podemos ter de implicações sobre este assunto.

Veremos aqui que não se configuram politicas de retenção no RMAN, apenas para ter controle dos backups obsoletos, ha algo mais importante por trás desta configuração e também um propósito pelo qual iremos usa-la.

Antes de mais nada vamo ressaltar uma coisa, ao usar a opção na linha de comando CONFIGURE RETENTION POLICY xx, onde "xx" representam os dias em que você quer manter seus backups, não significará que após esses dias seus backupsets serão automaticamente removidos e com isso você perderá sua estratégia de backup por completo, não é disso que estamos falando, a retenção dirá apenas até onde seus backups são válidos para uso, e após isso os marcara como expirados.

Isso não implica em NÃO utilização em definitivo dos seus backupsets, caso você necessite dos mesmos poderá sim se valer deste conjunto de backups marcados como expirados, é apenas uma maneira de remove-los do local para dar maior espaço pra área de manobra, porque imaginem você que por exemplo alguem resolva manter seus backups por 1 (um) ano no disco local do servidor, levando em consideração que ele tenha uma base de 500GB, imaginem só o tamanho do STORAGE ou da área que esta pessoa teria que ter para manter isso disponivel por um ano.


Ou então podemos imaginar o seguinte, alguem pede pra você um conjunto de backup que excedeu seu retention de 10 dias e que já esteja em fita a um mês, isso torna este backup dispensavel? Se fosse dessa forma não haveria necessidade de backupear nada, porque tudo seria obsoleto num curto espaço de tempo.


Esclarecido isso , o Oracle fornece á vocês essa viabilidade de controle do que permanece disponivel ou não localmente, e uma forma de você ver o que já estrapolou sua janela de retenção é através do comando REPORT OBSOLETE, comando este emitido diretamente do prompt do RMAN, vejam :




Reparem que na saida do comando REPORT OBSOLETE aparece logo abaixo a mensagem "no obsolete backups found." Isto se deve ao fato de nós ainda não termos realizado nenhum backup deste que iniciamos a nossa jornada sobre RMAN, porém vou deixar configurado e mais para frente farei um backup e teremos uma breve noção sobre esse comando quando for oportunamente tratado.



Eu havia mudado anteriormente meu DEVICE TYPE para usar uma FITA de Backup , apenas para demonstrar o comando configure, retornei para o DEVICE TYPE TO DISK, para que meus BackupSets sejam gerados localmente, e usei a opção de CONFIGURE RETENTION POLICY TO RECOVERY WINDOWS OF 3 DAYS, para setar meus backupsets como sendo validos por 3 dias após realizar um backup, seja ele FULL ou INCREMENTAL.


Caso vocês não se baseiem em dias para manter uma ploitica de rentenção, mas sim em numeros de cópias dos seus backups, o RMAN lhes dá a opção de usar a clausula REDUNDANCY, onde também é definida em numeros essa quantidade, através da sintaxe :


configure retention policy to redundancy 2;

O RMAN, não é nada fácil de se utilizar, mais é uma ferramenta muito segura, se vocês se dispuserem a usalo com cautela sem pressa , atentanto aos detalhes , descobriram um aliado valioso no dia a dia do DBA.

OBS.: Para aquele que utilizam backups direto para uma fita de dados, pode ser usado também ou melhor , combinado, a politica de retenção do RMAN com a da fita em si, não adianta você utilizar retenções diferentes pois pode ocorrer de você acabar por dispensar um arquivo que para a fita esta obsoleto mais para o RMAN não. 




CRIPTOGRAFIA NO RMAN


É possivel sim, além de tudo , ter um backup encriptado no seu RMAN, isso esta disponivel deste a release 10gR2 e superiores, e isso ocorre no decorrer dos backups como um passo adicional, sendo os mesmos encriptados e gerados em sequencia. No processo de restauração um algoritmo interno do próprio Oracle , tratará de desincriptar seus backups para realizar as tarefas de restauração.


Dentro dos tipos de criptografias disponiveis no RMAN, temos as seguintes:


TRANSPARENT MODE :
- Requer uma integração do DBA , pois para que esse modo seja usado é preciso previamente ter configurado também o ORACLE ENCRYPTION WALLET.


PASSWORD MODE :
- Necessita do fornecimento de um determinado password para que os backups sejam criados encriptados ou restaurados. Isto é possivel utilizando o parametro SET ENCRYPTION ON IDENTIFIED BY PASSWORD ONLY, linha essa que deve ser adicionada aos scripts de backup RMAN.


DUAL MODE :
- Por fim temos o DUAL MODE, que mescla as duas opções acima mostradas.


Você pode usar esta opções de segurança para os seguintes casos :


  • quando todos os arquivos devem ser criptografados
  • quando tablespaces espeficias atenderem a este proposito
  • quais dos tipos de algoritmos serão usados para promover a encriptação de seus backups.

Estas opções se aplicam a backups de archives logs também,  e deve ser usado no momento em que este estão ocorrendo, através da sintaxe SET ENCRYPTION ON.

A politica de retenção funciona igualmente para seus backups via RMAN, tanto para Archives como para o restante, caso você use FRA ou tenha um STANDBY database no seu ambiente , você pode adequar esta retenção para contemplar essas possibilidades, uma opção que envolve standby databases é configurada através da sintaxe :


CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY


O comando acima determina que só será considerado descartavel o Archive que jpa estiver sido aplicado com sucesso em seu ambiente standby, podendo assim ser removido da sua área de FRA ou onde quer que esteja armazenado.


Bem, pararemos por aqui por hoje, retomo a seguir falando em CATALOGO de backup para fecharmos esse assunto do que eu considero importante.


Obrigado á todos pelas visitas, emails e comentários.


Até breve!!!


Abraço.