segunda-feira, 3 de janeiro de 2011

ORACLE RECOVERY MANAGER (RMAN ) - O que devo saber? - Parte VI

Olá pessoal, como estão vocês?

Bem, festas terminadas, ano virado, e tudo recomeça mais uma vez, porém não como da ultima vez, espero que esse ano seja fantastico para todos os leitores e contribuidores deste BLOG.

Vamos ao que interessa? Minha ultima postagem sobre este assunto que me deu tanto prazer em falar, espero que tenham gostado.

CATALOGO DE RECUPERAÇÃO E SUAS CONSIDERAÇÕES



Todos nós sabemos que, é necessário termos uma boa estrutura em termos de administração de Banco de Dados, seja lá qual for a plataforma ( Microsoft, Oracle, IBM ou Open Source).

Em se tratando de Oracle, e falando em BACKUP, nós temos uma das melhores ferramentas disponíveis no mercado para criarmos estratégias de backup's, adequadas as nossas realidades de ambientes do dia a dia. E é ai onde entra o nosso personagem principal o RMAN ou Recovery Manager.

Aliado ao nosso RMAN, temos uma ferramenta adicional chamada RECOVERY CATALOG, que ao meu ver é a porção do RMAN mais eficaz e com muita eficiência que eu já experimentei no meu dia a dia.

Usando uma citação do meu amigo e colega de profissão Rodrigo Almeida, que é na minha opinião um especialista em RMAN, pois por causa dele que estes artigos estão sendo escritos, “BACKUP BOM É BACKUP QUE VOLTA”. Essa citação por vezes me fez pensar muito em diversas situações pelas quais eu poderia passar e o que eu poderia precisar do RMAN ou do ORACLE mesmo , para me auxiliar nas recuperações ou até mesmo na definição de algumas tarefas em Backup e Recover.

Notadamente, o CATALOGO DO RMAN, te proporciona uma ampla atuação no sentido de verificar a situação do seu backup, lhe dando informações cruciais na hora de uma recuperação delicada e que requer maior atenção e minucia.


Bem, vamos estabelecer alguns conceitos , como é de costume, antes de avançarmos no assunto.



Conceito: o recovery catalog é um repositório onde o RMAN armazenará as informações relacionadas aos seus conjuntos de backup que são gerados diariamente ou conforme sua estratégia. Seu armazenamento é feito e localização apartada da base onde esta sendo executado o backup, adiante explicaremos o porque disso, trata-se de uma feature opcional na hora de realizar seus backup's, mas em determinados casos é realmente necessário ter um catalogo de recuperação para facilitar a tarefa.



BENEFICIOS DE SE USAR UM RECOVERY CATALOG.

Hoje em dia, quem usa um recovery catalog, sabe bem os beneficios que ele proporciona, mas há quem diga e seja mais resistente a utilização deste artefato, sob a alegação de que não hora de fazer um RESTORE, basta voltar tudo que foi para a fita e ponto, executa-se a restauração e fim de papo, não deixa de ser uma verdade, mais os anos de experiencia ensinaram a nós que a coisa é bem diferente, vejam alguns beneficios de se usar um RECOVERY CATALOG:

armazenamento de script's RMAN dentro do repositório .


centralização das informações dos backups.


flexibilidade na hora de montar relatórios sobre as politivas de backups executadas, podendo executar relatórios atemporais.


padronização do canal de configuração .






Como já citei anteriormente, há algumas situações em que você pode descartar o uso do Recovery Catalog, como por exemplo se você estiver usando opções de AUTOBACKUP para os CONTROLFILES, obviamente não precisará do catalogo para restaura-lo, basta usar a opção “RESTORE FROM AUTOBACKUP;”, outra situação é correlacionada a RESETLOGS que já é suportado pelo 10g.






Uma coisa muito importante quando se fala em recuperações e restaurações via RMAN, é ter sempre a mão seus respectivos DBID's, isso facilitará em muito as tarefas.






QUANDO EU DEVO USAR UM CATALOGO DE RECUPERAÇÃO.






De acordo com Robert Freeman e Matthew Hart :






“If you have just a few databases, then the recovery catalog is probably not worth the extra effort and hassle...”






Recomendações a parte, são os mestres falando, mas vale a pena mesmo que sejam poucas porém importantes bases, você se dar ao trabalho de manter um catalogo inicialmente, se mais para frente você perceber que não lhe ajuda mesmo remova-o e fim de papo.






Se você tem ambientes em alta disponibilidade com técnicas de redundância como o uso do DATA GUARD, um catalogo é imprescindível.






É também a melhor pratica se você pretende centralizar seus backups, realizar manutenções e manter uma organização das suas estratégias de backup e recuperação.






ATENÇÃO: Se a sua base onde está o catalogo de recuperação estiver OFFLINE, todos seus backups irão falhar, portanto é de suma importância que se você quer garantir seus backup's ou até mesmo assegurar que independente de qualquer coisa eles sejam realizados, crie processos de pré - check antes de executar via catalogo, ou crie duas opções, uma com e uma sem catalogo, isso com certeza dobrará seu tempo de backup, pois terá de executar 2 vezes a mesma coisa, mas se você não tem operadores atentos e não esta em um ambiente em 24x7 com escalas e pessoas olhando para o ambiente a todo momento, é algo a se pensar com muito carinho.






Como por padrão o RMAN usa a opção NOCATALOG na hora de conectar-se ao TARGET, você DEVE informar a opção CATALOG na hora de se conectar, pois isso indicará que além de estabelecer uma ligação com o TARGET DATABASE também deve ser realizada uma conexão no CATALOGO DE RECUPERAÇÃO, que deve sempre ficar em uma base apartada, por razões obvias que levam você a entender a importância de um catalogo, veja a seguinte situação.






Você esta usando seu catalogo na mesma base que o seu banco de produção, todos seus script's estão armazenados dentro do catalogo, toda informação sobre o que , quando e onde esta backupeado estão dentro dele também, e sua base sofre um DOWN inesperado, COMO VOCÊ IRA ACESSAR AS INFORMAÇÕES SOBRE A SUA RECUPERAÇÃO? Em uma breve analise de ALERT.LOG você percebeu que é a SYSTEM que deve recuperar, você tem de área em disco 500GB disponíveis , seu backup é de 550GB no momento, você pensa: “AH! VOU RESTAURAR TUDO NO DISCO , MANDO BALA NO COMANDO DE RECOVER, E SAIU BONITO NA FOTO.”, engano grave, seu backup não cabe no espaço em disco disponível.






Neste caso você tem duas opções, dar uma de escovador de bits, e sair deletando arquivos que não são importantes pra ganhar 50GB ou usar seu catalogo de recuperação , acessar a base de conhecimento dele sobre seus backups, e restaurar apenas os Backup Pieces relacionados a Tablespace SYSTEM e seus respectivos ARCHIVED LOG's.






Veja a TAG de conexão para catalogo abaixo:






RMAN target=''/'' as sysdba@''


catalog=''/''@''










CRIANDO MEU PRIMEIRO CATALOGO DE RECUPERAÇÃO






Já vimos a parte teórica sobre nosso amigo RECOVERY CATALOG, que tal agora sabermos como criar essa 'belezinha' em nosso database de recuperação?






Para criarmos nosso “brinquedo novo”, precisaremos então antes de mais nada atender a alguns requisitos determinados pela Oracle para a criação da base que abrigará o catalogo do RMAN, vejam:






Tablespaces                                     Tamanho recomendado


SYSTEM                                                                        900 MB


TEMP                                                                                   5MB


UNDO                                                                                   5MB


RECOVER CATALOG SCHEMA                                  15 MB


ONLINE REDO LOGS                                                        1 MB










Notem que não é nada do outro mundo, uma instancia com no máximo uns 300mb de SGA atende muitíssimo bem a um banco de dados dessas proporções, e não comprometerá tanto assim seu desempenho , até porque o banco de Recover Catalog, será acessado nos momentos de backup apenas ou quando houver necessidade de realizar alguma tarefa no mesmo.






CRIANDO MEU USUÁRIO DO CATALOGO DE RECUPERAÇÃO






Criar um usuário como qualquer outro não requer muita expertise, o que nos chama atenção aqui é os GRANTS específicos que este usuário deverá ter e que veremos na sequencia.














Bem , primeiro uma breve query para sabermos onde estão nossos datafiles, em seguida criamos uma tablespace para abrigar o RECOVERY CATALOG, logo depois criamos o usuário RCVCAT que recebeu as respectivas permissões : CONNECT,RESOURCE e RECOVERY_OWNER_CATALOG.






Pronto já que criamos nosso usuário, tablespace e concedemos as devidas permissões é hora então de criarmos o catalogo.






CRIANDO O CATALOGO DE RECUPERAÇÃO






Logo acima nós podemos ver que é muito simples de se criar o usuário para mantermos nosso catalogo de recuperação em funcionamento, agora vamos ver como fazer para criarmos o catalogo propriamente dito :














Aqui já nos mostra conectados em nosso banco de dados ( LAB10g), em nosso usuário de Catalogo e na sequencia a criação do Catalogo de Recuperação, o Registro da Base de Dados catalogada e depois um REPORT SCHEMA para vermos o que temos à backupear.






Há a possibilidade também de remoção do nosso catalogo de recuperação. Porém como todo comando DROP conhecido no ORACLE, ele eliminará todo e qualquer dado pré - existente sobre os seus Backups realizados, portanto se for fazê-lo , PENSE BEM, para eliminar seu catalogo use o comando “DROP CATALOG;”.






Outra coisa que é muito importante é que, se você optar por criar um banco novo para o seu catalogo de RMAN, este TAMBÉM deve ter uma estratégia de Backup tão eficiente quanto as dos seus bancos de Produção.






Bom pessoal , por fim nós podemos ainda depois de optarmos tardiamente pelo uso do catalogo de recuperação, adicionar ao nosso repositório as informações sobre backups já realizados anteriormente a sua existência, isso é feito através do uso da clausula CATALOG veja abaixo algumas possibilidades :






RMAN> CATALOG DATAFILE 'path+datafilename';


RMAN> CATALOG ARCHIVELOG 'path+archivefilename';


RMAN> CATALOG BACKUPPIECE 'path+bkppiecename';


RMAN> CATALOG START WITH 'path dos seus backups';






Bem era mais isso que tinha para dividir com vocês, espero que tenham gostado da série, logo mais eu volto com execução de Backups via RMAN, dando exemplos de como fazê-los de maneira mais eficiente e reduzindo nosso tempo de trabalho.

Agradeço á todos que acompanham este BLOG, contribuindo sempre de alguma forma, peço que continuem fazendo isso, e opinem sempre que possivel.

Abraço á todos!!!!