14 e 15 - Pedro F. Carvalho

Pedro F. Carvalho
Analista de Sistemas
[email protected]
www.pedrofcarvlho.com.br
CAPITULO 14 e 15 BACKUPS NO ORACLE
Um assunto muito pouco abordado entre os profissionais Oracle, e que sempre causa
estresse e problemas quando necessário, é a eficiência da estratégia de backup &
recover de um determinado banco de dados da empresa, pois todos só prestam
atenção nesse assunto quando é necessário e já estão com a corda no pescoço.
Para ter uma eficiente estratégia de backup & recover, primeiramente deve-se
conhecer a infra-estrutura que a empresa oferece para adequar as soluções de backup
e planejar quais estratégias e técnicas que serão 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) disponíveis para armazenamento;
Se existe uma necessidade de storage para backup em disco, é viável uma
aquisição?;
Se existem servidores dedicados para testes e validação de restore e recover;
A empresa possui outro site para planejar estratégias 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 política de backup de cada banco de
dados, tratado de forma única, pois em banco de dados, por mais que sejam
padronizadas as instalações, arquitetura e funcionalidades de cada base, necessita de
políticas de backup customizadas, onde a aplicação da empresa que irá ditar as
principais regras, e existem pontos que merecem atenção, como:
Tempo para janela de recuperação;
Tempo de retenção dos dados;
Agendamento das rotinas de backup, exemplo: diária, semanal, mensal ou
anual;
Volumetria que será armazenada;
Nível de proteção dos dados;
Tipos de backups que serão executados;
Definição dos procedimentos de backup, restore e recover.
Os dois pontos citados são o início para enxergar as deficiências da empresa ao
elaborar as estratégias de backup, são os principais pontos que devem ser levantados
para posteriormente planejar as melhores técnicas e políticas adequadas para as
bases.
Não adianta o DBA ter diversas ideias e soluções de armazenamento e recuperações
ótimas se a empresa não permite ou não suporta tais tarefas. Seria uma frustração
para o profissional tentar implementar uma solução sem sucesso ou com diversos
problemas e que não conseguisse atingir o principal objetivo que é a segurança dos
dados e disponibilidade do banco de dados.
Em relação ao assunto, soluções de backup, existem diversas no mercado, a própria
Oracle oferece diversas soluções 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 soluções adequadas a sua empresa,
como: CA BrightStor ArcServer e Backup Exec, Symantec NetBackup, IBM Tivoli ou
Pedro F. Carvalho
Analista de Sistemas
[email protected]
www.pedrofcarvlho.com.br
EMC NetWorker. Tudo é uma questão de analise, planejamento e execução na
implantação da solução e, é claro, verificar se o valor da solução está dentro do
orçamento do departamento de TI.
Agora, aos DBAs, existem técnicas e práticas que podemos aplicar para complementar
as estratégias de backup existentes e outras práticas que devem possuir requisitos
citados no início, principalmente na parte de infra-estrutura. Quando vamos pensar em
backup & recover, O que lhe vem na cabeça? Vamos montar uma lista com as opções:
1.
2.
3.
4.
5.
6.
7.
8.
9.
Backup cold;
Backup hot;
Backup por tablespace;
Backup do control file;
Export do banco de dados;
Arquivos de carga (originadas do ETL ou de algum outro processo);
Cópia fria de um servidor para o outro;
Cópia dos objetos de banco;
E, na pior das hipóteses, garantia de alguma coisa no ambiente de
desenvolvimento e homologação.
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 através do RMAN
(Recovery Manager) ou através de scripts shell (Linux/Unix) ou batch (Windows), onde
para o formato manual do backup, pode envolver a cópia até mesmo dos arquivos de
redo log, no RMAN não é necessário. Interessante ter um backup frio na sua estratégia
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 produção, pois não é necessário a parada do banco de dados, quando
está em modo ARCHIVELOG, porém, uma estratégia de backup HOT pode envolver a
utilização de níveis de backups incrementais, como:
Backup incremental nível 0, ou backup base;
Backup incremental nível 1, 2, 3 e 4.
Ao colocar esses níveis de backup na sua estratégia, irá ganhar performance, redução
de volumetria de backup gerado e aumentar o nível de disponibilidade dos dados,
dando mais eficiência à recuperação. Acho que é a opção mínima de backup para o
ambiente de produção.
Backup por tablespace, backup realizado para uma determinada tablespace, tendo
como opção até mesmo a seleção dos datafiles que poderão ser copiados, pode ser
feito manualmente e automaticamente, mas em alguns banco de dados existem
tablespaces que armazenam as principais tabelas da aplicação, em que pode forçar
uma parada crítica da aplicação. Então, vem a pergunta valendo 1 milhão: Se eu peder
Pedro F. Carvalho
Analista de Sistemas
[email protected]
www.pedrofcarvlho.com.br
uma tablespace com tabelas de alta criticidade à aplicação, tenho que voltar o meu
banco de dados por completo?
A resposta é simples: se traçou um bom planejamento e tem recursos de hardware
disponível, poderá aplicar uma técnica apenas de recuperação da tablespace e seus
respectivos datafiles, chamada TSPITR (Tablespace Point-in-Time Recovery), que pode
ser realizado manualmente ou automatizado com RMAN, onde não é necessário voltar
seu backup por completo, porém, é necessário uma máquina auxiliar nessa atividade
ou espaço em disco suficiente na própria máquina que ocorreu o problema, com isso,
podemos recuperar partes do banco de dados de forma completa e deixar a aplicação
operante.
Backup por control file, é o bakcup de um dos principais arquivos do banco de
dados, onde armazena todas as informações 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 automático 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 espécie de backup lógico, ou seja, poderá realizar
um backup completo ou por usuário do banco de dados, porém, muitos se enganam
quando deixam apenas um EXPORT, ou apenas DMP (Dump) como é conhecido no
mercado, pois o EXPORT não garante a segurança total dos dados e com isso poderá
ter perda de dados, o que geralmente para uma empresa não é muito bom. Basta
analisar um simples exemplo prático.
Imagine que tenho um banco de dados que é atualizado todos os dias, com
INSERT/DELETE/UPDATES diários, um bom e velho OLTP (Online Transaction
Processs), e na minha estratégia 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 recuperação ficou impossível, o que você tem na
mão para salvar o mundo? Apenas um DMPzinho das 07:00Hs da manhã, e o que
aconteceu com todas as movimentações das 07:00Hs até as 17:45Hs? Vão sumir?
Você não tem archived logs e a base está totalmente inconsistente para recuperação.
Resultado final: muito café e cigarros para falar esse cenário com o seu gerente.
Isso é apenas um cenário que ocorre em muitas empresas, onde as Leis de Murphy
podem ocorrer, e quando ocorre sua reputação pode estar em jogo. E pior, existem
muitos ambientes que estão com esse cenário atualmente.
Arquivos de carga, é considerado backup, principalmente para ambiente de Data
WareHouse onde existe uma alta volumetria de dados e os bancos de dados não
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
dimensão importante do seu DW? Com Mágica? Export poderia resolver o problema
também, mas trazer um export FULL de um DW não seria muito legal (esperar
cansa!), e nesse caso, como estamos falando de apenas 2 dias, por que não 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.
Pedro F. Carvalho
Analista de Sistemas
[email protected]
www.pedrofcarvlho.com.br
Cópia fria de um banco de dados, é uma opção muito interessante para
implementar na estratégia de backup da empresa onde tem bancos de dados
praticamente abertos ao público, ou seja, até o porteiro sabe a senha do owner da
aplicação e o estagiário treina seus primeiros comandos DML diretamente na base de
produção, porque somente a produção tem uma volumetria para ele testar o tempo e a
eficiência do seu DELETE.
E quando estamos falando de cópia fria, não precisa ser as práticas do "Old School",
baixa o banco de dados e CTRL+C e CTRL+V em todos os arquivos e copia para outra
máquina. É uma solução também dependendo do ambiente, mas por que não optar
por um DUPLICATE DATABASE, usar um Data Guard (Lógico ou Físico), Stand-by
database, ou um backup online na produção e restore em outra máquina, com o
RMAN, isso é possível até entre diferentes plataformas, de um Linux para Windows.
Olha que maravilha! Desde jeito você consegue uma imagem da sua produção e
consultar essa imagem para reparar os "ensinamentos" do estagiário na produção!
Recomendação: Depois ensina o controle ROLLBACK! rs.
Cópia dos objetos do banco de dados, esse é um ponto interessante também,
principalmente quando sua empresa não tem definição de ambientes, como
desenvolvimento, homologação e produção. Poucos DBAs se atentam nisso, mas
quando é necessário voltar uma procedure que foi alterada em produção e essa
alteração não ajudou em nada ou pior, só complicou as coisas! Qual a sua estratégia
para voltar isso? Montar um owner em alguma base de teste ou na sua própria
máquina e realizar um IMPORT do owner da aplicação sem registros e posteriormente
pegar o DDL da procedure? Pegar os DDL do desenvolvimento ou homologação? Ou
mandar o desenvolvedor se virar? Quais as alternativas!
Para resolver esse simples probleminha, basta começar a realizar um backup lógico
dos objetos do banco de dados, pode usar as próprias views do dicionário 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 gráficos como PL/SQL Developer, SQL Developer e TOAD gerar um
"scriptão" a partir deles!
Nessa simples solução, 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 necessários e mandar para FITA, eles
podem gerados em arquivos com os nomes e tipos dos objetos, um script completo do
owner da aplicação com a data do backup e etc. Fica a gosto do cliente!
Percebeu que existem diversos tipos, formas, tamanhos, técnicas, soluções e práticas
de backup, uma boa estratégia de backup varia muito conforme o ambiente e os
recursos que a empresa oferece, e também as estratégias que o DBA irá implementar
na empresa. O banco de dados Oracle oferece para você um leque de opções, basta
saber aplicar essas opções. É igual ao antigo slogan do um ótimo produto da NESTLE
ORACLE DATAPUMP
No Oracle 10g você pode usar um utilitário de movimentação de dados chamado Data
Pump para aumentar o desempenho no transporte de dados, pois o mesmo é 60%
Pedro F. Carvalho
Analista de Sistemas
[email protected]
www.pedrofcarvlho.com.br
mais rápido do que os utilitários de export e import que ainda estão disponíveis no
10g.
O Data Pump utiliza recursos de processamento paralelos no transporte de dados e
pode ler arquivos de exportação criados pelo utilitário export. Ele emprega a
Tecnologia DIRECT PATH para carregar ou exportar dados. Diferentemente dos
programas Import e Export que funciona no lado cliente de uma sessão do banco de
dados, o Data Pump executa no servidor. Assim, você deve usar um diretório de banco
de dados para especificar a localização de arquivos de Dump e Log.
O Data Pump pode ser chamado da linha de comando com os programas IMPDB e
EXPDP ou através do PACKAGE DBMS_DATAPUMP. Você pode pedir ao expdp uma lista
completa de parâmetros, especificando o parâmetro help=y.
Parâmetros
Descrição
Full=y
Modo de exportação de banco de dados
Schemas=schema_list
Especifica exportação em modo schema
Tables=tables_list
Exportação em Modo Tabela
Content=content_option
Indica quando dados ou metadados serão
exportados default ALL
Network_link=db_link
Especifica um Banco de Dados Remoto
com a origem de dados
Dumpfile=dir:file
Nome do Arquivo Dump, Se o nome do
Arquivo contiver %U ,este será
substituído por dois dígitos .
Filesize=size_limit
Tamanho máximo do arquivo Dump e Log
Logfile=dir:file
Localização e nome do Arquivo de Log
Directory=dir
Localização para Arquivo Dump e Log
Pedro F. Carvalho
Analista de Sistemas
[email protected]
www.pedrofcarvlho.com.br
Nologfile=y
Indica que não será gravado um arquivo
de log.
Job_name=identifier
Especifica um nome que pode ser utilizado
por um job de importação
Parallel=degree
Número máximo de processos de
palalelismo.
Parfile=dir:file
Localização e nome do arquivo de
Parâmetros
Utilizando o Data Pump para Exportar dados
Você inicia uma exportação via Data Pump executando o Programa EXPDP ou
executando um Programa PL/SQL que chama a procedure DBMS_DATAPUMP.O
Enterprise Manager Também fornece uma interface gráfica para a execução do Data
Pump.
Aprenderemos agora como Exporta dados utilizando a linha de comando com o Data
Pump.
O programa de exportação do Data Pump pode funcionar de vários modos, incluindo
banco de dados, Schema, Tabela, Tablespace. Em uma exportação de modo de banco
de dados, o banco de dados inteiro é exportado para arquivo de sistema operacional
incluindo contas de usuários, sinônimos públicos, roles e profiles.
Em uma exportação de modo schema, todos os dados e metadados de uma lista de
schema são exportados. No modo de tabela, inclui os dados e metadados de uma lista
de tabelas no modo tablespace, extrai tanto dados como metadados de todos os
objetos em uma lista de tablespace bem como qualquer objeto dependente daquela
lista de tablespaces especificada.
Os arquivos criados pelo Data Pump são chamados de DUMP FILES, um ou vários
desses arquivos podem ser criados durante uma única execução do Data Pump.
Múltiplos arquivos podem ser criados se a execução do Data Pump tiver um grau de
paralelismo maior que um ou se um arquivo exceder o tamanho limite do parâmetro
FILISEZE. Todos os arquivos de dump de uma execução são chamados de dump file
set.
Veremos agora como executar o data pump em seus diferentes modos de exportação.
Entre com o usuário system, dê o privilégio create any directory para criar o diretório
onde será guardado o dump file
Conn system/password@orcl
Pedro F. Carvalho
Analista de Sistemas
[email protected]
www.pedrofcarvlho.com.br
Create or replace directory teste_dir as ‘E:\teste_dir’;
Grant read, write on directory teste_dir to scott;
Fazendo o export de tabelas com expdp
Expdp scott/tiger@orcl tables=emp,dept directory=teste_dir
Dumpfile=emp_dept.dmp logfile=expdppemp_dept.log nologfile =y
content=metadata_only
Pedro F. Carvalho
Analista de Sistemas
[email protected]
www.pedrofcarvlho.com.br
O parâmetro nologfile=y diz ao DATA PUMP para não gravar um arquivo de log em
disco. O parâmetro content=metadata_only diz ao DATA PUMP para exportar só os
metadados, não os dados das tabelas. Para especificar somente dados, sem
metadados, substitua o parâmetro metadata_only por data_only.
O parâmetro tables_exists_action=append permite importar dados para uma tabela
que já tem dados .
Fazendo o export de schemas com expdp
Expdp system/oracle@orcl schemas=scott directory=teste_dir dumpfile=scott.dmp
logfile=impdpscott.log
Pedro F. Carvalho
Analista de Sistemas
[email protected]
www.pedrofcarvlho.com.br
Fazendo o exporte do Banco de Dados com expdp
Expdp system/password@orcl full=y directory=teste_dir dumpfile=db10g.dmp
logfile=impdpdb10g.log
Pedro F. Carvalho
Analista de Sistemas
[email protected]
www.pedrofcarvlho.com.br
Fazendo o exporte das tablespaces
Expdp system/password@orcl directory=teste_dir dumpfile=db10tabelspace.dmp
logfile=exptbs10g.log tablespaces=users
Para monitorar as operações realizadas pelo Data Pump, consulte as views:
Dba_datapump_jobs
Dba_datapump_sessions
Datapump_paths
Importando com usuario TESTE no Oracle Data Pump, remapeando por
schemas(schema TESTE para o TESTE2) e remapeando por Tablespaces(Tablespace
TESTE para o TESTE2):
- Impdp teste/teste directory=dump dumpfile=teste.dmp logfile=testeimp.log
remap_schema=teste:teste2 remap_tablespace=teste:teste2