http://imasters.com.

br/artigo/12321/oracle/uma-visao-geral-sobre-backup-erecover

Uma viso geral sobre Backup & Recover

Tera-feira, 14/04/2009 s 10h00, por Rodrigo Almeida

Um assunto muito pouco abordado entre os profissionais Oracle, e que sempre causa estresse e problemas quando necessrio, a eficincia da estratgia de backup & recover de um determinado banco de dados da empresa, pois todos s prestam ateno nesse assunto quando necessrio e j esto com a corda no pescoo. Para ter uma eficiente estratgia de backup & recover, primeiramente deve-se conhecer a infra-estrutura que a empresa oferece para adequar as solues de backup e planejar quais estratgias e tcnicas que sero aplicadas. E quando estamos falando de infra-estrutura, diversos pontos devem ser destacados, como:
Rede LAN dedicada para backup & recover; Dispositivos de Fita (DLT, LTO e DDS) disponveis para armazenamento; Se existe uma necessidade de storage para backup em disco, vivel uma

aquisio?;
Se existem servidores dedicados para testes e validao de restore e

recover;
A empresa possui outro site para planejar estratgias de backup; Se a empresa centraliza backups de outras unidades, qual o tamanho da

banda de rede. O segundo ponto que deve ser analisado a poltica de backup de cada banco de dados, tratado de forma nica, pois em banco de dados, por mais que sejam padronizadas as instalaes, arquitetura e funcionalidades de cada base, necessita de polticas de backup customizadas, onde a aplicao da empresa que ir ditar as principais regras, e existem pontos que merecem ateno, como:
Tempo para janela de recuperao; Tempo de reteno dos dados; Agendamento das rotinas de backup, exemplo: diria, semanal, mensal ou

anual;
Volumetria que ser armazenada; Nvel de proteo dos dados; Tipos de backups que sero executados; Definio dos procedimentos de backup, restore e recover.

Os dois pontos citados so o incio para enxergar as deficincias da empresa ao elaborar as estratgias de backup, so os principais pontos que devem ser levantados para posteriormente planejar as melhores tcnicas e polticas adequadas para as bases.

No adianta o DBA ter diversas ideias e solues de armazenamento e recuperaes timas se a empresa no permite ou no suporta tais tarefas. Seria uma frustrao para o profissional tentar implementar uma soluo sem sucesso ou com diversos problemas e que no conseguisse atingir o principal objetivo que a segurana dos dados e disponibilidade do banco de dados. Em relao ao assunto, solues de backup, existem diversas no mercado, a prpria Oracle oferece diversas solues de backup interessantes, como Oracle Secure Backup, Data Guard, Stand-by Database, Recovery Manager (RMAN) e Legato Single Server. Outros produtos de terceiros podem oferecer solues adequadas a sua empresa, como: CA BrightStor ArcServer e Backup Exec, Symantec NetBackup, IBM Tivoli ou EMC NetWorker. Tudo uma questo de analise, planejamento e execuo na implantao da soluo e, claro, verificar se o valor da soluo est dentro do oramento do departamento de TI. Agora, aos DBAs, existem tcnicas e prticas que podemos aplicar para complementar as estratgias de backup existentes e outras prticas que devem possuir requisitos citados no incio, principalmente na parte de infra-estrutura. Quando vamos pensar em backup & recover, O que lhe vem na cabea? Vamos montar uma lista com as opes: 1. Backup cold; 2. Backup hot; 3. Backup por tablespace; 4. Backup do control file; 5. Export do banco de dados; 6. Arquivos de carga (originadas do ETL ou de algum outro processo); 7. Cpia fria de um servidor para o outro; 8. Cpia dos objetos de banco; 9. E, na pior das hipteses, garantia de alguma coisa no ambiente de desenvolvimento e homologao. OK! Percebeu que estamos falando de um assunto delicado e de forma abrangente, sem determinar o que ser feito, se existe procedimento para tal, quais as garantias que vou ter e sempre pensando naquela frase linda e determinante:

Backup bom aquele que volta.

Agora, vamos discutir um pouco sobre os tipos de backups citados acima. Backup Frio (Cold Backup), backup realizado com o banco de dados offline, ou seja consistente. O backup cold pode ser feito de modo automatizado atravs do RMAN (Recovery Manager) ou atravs de scripts shell (Linux/Unix) ou batch (Windows), onde para o formato manual do backup, pode envolver a cpia at mesmo dos arquivos de redo log, no RMAN no necessrio. Interessante ter um backup frio na sua estratgia de backup. Backup Quente (Hot backup), backup realizado com o banco de dados online, ou seja inconsistente. O backup HOT um dos principais tipos de backup realizados nos ambientes de produo, pois no necessrio a parada do banco de dados,

quando est em modo ARCHIVELOG, porm, uma estratgia de backup HOT pode envolver a utilizao de nveis de backups incrementais, como:
Backup incremental nvel 0, ou backup base; Backup incremental nvel 1, 2, 3 e 4.

Ao colocar esses nveis de backup na sua estratgia, ir ganhar performance, reduo de volumetria de backup gerado e aumentar o nvel de disponibilidade dos dados, dando mais eficincia recuperao. Acho que a opo mnima de backup para o ambiente de produo. Backup por tablespace, backup realizado para uma determinada tablespace, tendo como opo at mesmo a seleo dos datafiles que podero ser copiados, pode ser feito manualmente e automaticamente, mas em alguns banco de dados existem tablespaces que armazenam as principais tabelas da aplicao, em que pode forar uma parada crtica da aplicao. Ento, vem a pergunta valendo 1 milho: Se eu peder uma tablespace com tabelas de alta criticidade aplicao, tenho que voltar o meu banco de dados por completo? A resposta simples: se traou um bom planejamento e tem recursos de hardware disponvel, poder aplicar uma tcnica apenas de recuperao da tablespace e seus respectivos datafiles, chamada TSPITR (Tablespace Point-in-Time Recovery), que pode ser realizado manualmente ou automatizado com RMAN, onde no necessrio voltar seu backup por completo, porm, necessrio uma mquina auxiliar nessa atividade ou espao em disco suficiente na prpria mquina que ocorreu o problema, com isso, podemos recuperar partes do banco de dados de forma completa e deixar a aplicao operante. Backup por control file, o bakcup de um dos principais arquivos do banco de dados, onde armazena todas as informaes do banco de dados com checkpoint, valor de scn, origem dos datafiles, tablespaces, nome do banco de dados, backupsets e etc. Esse backup pode ser feito manualmente ou automtico pelo RMAN ou at mesmo por um trace diretamente do SQL*PLUS, usando o comando ALTER DATABASE BACKUP CONTROLFILE TO TRACE. Export do banco de dados, uma espcie de backup lgico, ou seja, poder realizar um backup completo ou por usurio do banco de dados, porm, muitos se enganam quando deixam apenas um EXPORT, ou apenas DMP (Dump) como conhecido no mercado, pois o EXPORT no garante a segurana total dos dados e com isso poder ter perda de dados, o que geralmente para uma empresa no muito bom. Basta analisar um simples exemplo prtico. Imagine que tenho um banco de dados que atualizado todos os dias, com INSERT/DELETE/UPDATES dirios, um bom e velho OLTP (Online Transaction Processs), e na minha estratgia de backup tenha apenas um Export (ou DMP, como preferir) realizado sempre s 07:00Hs da manh. Em uma bela sexta-feira s 17:45Hs da tarde, o servidor que hospeda esse banco de dados teve problemas nos discos internos, perdeu-se archived logs do dia e um maravilhoso "crash" na base. Sua recuperao ficou impossvel, o que voc tem na mo para salvar o mundo? Apenas um DMPzinho das 07:00Hs da manh, e o que aconteceu com todas as movimentaes das 07:00Hs at as 17:45Hs? Vo sumir? Voc no tem archived logs e a base est totalmente inconsistente para recuperao. Resultado final: muito caf e cigarros para falar esse cenrio com o seu gerente.

Isso apenas um cenrio que ocorre em muitas empresas, onde as Leis de Murphy podem ocorrer, e quando ocorre sua reputao pode estar em jogo. E pior, existem muitos ambientes que esto com esse cenrio atualmente. Arquivos de carga, considerado backup, principalmente para ambiente de Data WareHouse onde existe uma alta volumetria de dados e os bancos de dados no trabalham em ARCHIVELOG, pois, como voc poderia recuperar os dados que foram apagados acidentalmente nos dias 20 e 21 de uma tabela de FATO ou de alguma dimenso importante do seu DW? Com Mgica? Export poderia resolver o problema tambm, mas trazer um export FULL de um DW no seria muito legal (esperar cansa!), e nesse caso, como estamos falando de apenas 2 dias, por que no os arquivos de carga desses dias! Usando o mesmo processo de ETL poderia refazer a carga e completar a tabela novamente com seus respectivos dados, em bem menos tempo. Cpia fria de um banco de dados, uma opo muito interessante para implementar na estratgia de backup da empresa onde tem bancos de dados praticamente abertos ao pblico, ou seja, at o porteiro sabe a senha do owner da aplicao e o estagirio treina seus primeiros comandos DML diretamente na base de produo, porque somente a produo tem uma volumetria para ele testar o tempo e a eficincia do seu DELETE. E quando estamos falando de cpia fria, no precisa ser as prticas do "Old School", baixa o banco de dados e CTRL+C e CTRL+V em todos os arquivos e copia para outra mquina. uma soluo tambm dependendo do ambiente, mas por que no optar por um DUPLICATE DATABASE, usar um Data Guard (Lgico ou Fsico), Stand-by database, ou um backup online na produo e restore em outra mquina, com o RMAN, isso possvel at entre diferentes plataformas, de um Linux para Windows. Olha que maravilha! Desde jeito voc consegue uma imagem da sua produo e consultar essa imagem para reparar os "ensinamentos" do estagirio na produo! Recomendao: Depois ensina o controle ROLLBACK! rs. Cpia dos objetos do banco de dados, esse um ponto interessante tambm, principalmente quando sua empresa no tem definio de ambientes, como desenvolvimento, homologao e produo. Poucos DBAs se atentam nisso, mas quando necessrio voltar uma procedure que foi alterada em produo e essa alterao no ajudou em nada ou pior, s complicou as coisas! Qual a sua estratgia para voltar isso? Montar um owner em alguma base de teste ou na sua prpria mquina e realizar um IMPORT do owner da aplicao sem registros e posteriormente pegar o DDL da procedure? Pegar os DDL do desenvolvimento ou homologao? Ou mandar o desenvolvedor se virar? Quais as alternativas! Para resolver esse simples probleminha, basta comear a realizar um backup lgico dos objetos do banco de dados, pode usar as prprias views do dicionrio de dados do Oracle, como dba_source, dba_triggers, dba_views, dba_mviews e etc, usar o pacote DBMS_METADATA, gerar um DDL script com o Export ou at mesmo para os adeptos de programas grficos como PL/SQL Developer, SQL Developer e TOAD gerar um "scripto" a partir deles! Nessa simples soluo, que pode economizar tempo, menos estresse e agilizar o objeto correto ao banco de dados, vai gastar apenas tempo para preparar os scripts e, posteriormente, realizar os agendamentos necessrios e mandar para FITA, eles podem gerados em arquivos com os nomes e tipos dos objetos, um script completo do owner da aplicao com a data do backup e etc. Fica a gosto do cliente!

Percebeu que existem diversos tipos, formas, tamanhos, tcnicas, solues e prticas de backup, uma boa estratgia de backup varia muito conforme o ambiente e os recursos que a empresa oferece, e tambm as estratgias que o DBA ir implementar na empresa. O banco de dados Oracle oferece para voc um leque de opes, basta saber aplicar essas opes. igual ao antigo slogan do um timo produto da NESTLE.

Existem 1001 maneiras de preparar sua Estratgia de backup, invente a sua!

E ficamos por aqui, dvidas, crticas e sugestes, s entrar em contato. Abraos,