Blog do Rodrigo Almeida

Olá,

Um dos grandes pontos fortes de trabalhar com o Recovery Manager (RMAN) é a possibilidade de alocar uma determinada quantidade de canais necessários no processo de Backup para melhorar o desempenho de I/O durante a tarefa, diminuindo o tempo do backup.

Os administradores de banco de dados (DBA) muitas vezes gostam de utilizar a alocação de canal manual para efetuar o backup e com isso, torna necessário mencionar a cada canal (channel) alocado o caminho que deverá ser gerado o backup set.  Como o script abaixo:

RMAN> run {

2> allocate channel t1 type disk format '/u02/app/oracle/backup/rman/bkp_%d_%t_%s.rman';

3> backup current controlfile tag 'BKP_CF';

4> release channel t1;

5> }

Perceba que durante a alocação do canal t1, é utilizada a cláusula FORMAT, que posteriormente menciona o caminho e o nome do backupset que será gerado pelo RMAN. Pois bem, se você costuma utilizar 3, 4, 5 ou mais canais, em um único caminho de backup e usando sempre a mesma máscara de nomenclatura de backup set, tornando os scripts frágeis.

Vamos analisar o exemplo e dividir as tarefas e customizar o RMAN, a partir da cláusula FORMAT. Veja:

Quantidade de canais = 3

Caminho de Backup =  /u02/app/oracle/backup/rman

Nomenclatura de Backup set = bkp_%d_%t_%s.rman

Sobre a nomenclatura utilizada, segue a explicação:

bkp_ = Nome inicial dos backupsets gerados, ou seja, definido por mim, é um valor fixo.

%d = Variável do RMAN para identificar o nome do banco de dados.

%t = Variável do RMAN para o Time Stamp do backup set.

%s = Variável do RMAN para identificar a sequência do backup set.

Agora, vamos colocar na prática essa customização.

1°) Logar-se no banco de dados usando o RMAN.

[oracle@ORA11G ~]$ rman target /

Recovery Manager: Release 11.1.0.6.0 - Production on Thu Aug 6 10:57:15 2009

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

connected to target database: RADB (DBID=1241100324)

2°) Configura o caminho e nome do backup set no control file.

As informações sobre a customização do RMAN será armazenada no control file. Para configurar emita o comando abaixo:

RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/u02/app/oracle/backup/rman/bkp_%d_%t_%s.rman';

new RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '/u02/app/oracle/backup/rman/bkp_%d_%t_%s.rman';
new RMAN configuration parameters are successfully stored

3°) Definir a quantidade de alocação de canal automático.

Para definir a quantidade de alocação de canais automáticos, quando executado qualquer script do RMAN para o banco de dados alvo, a estratégia é utilizar o PARALELISMO. E para configurar essa opção, basta executar o passo abaixo:

RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO BACKUPSET;

new RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO BACKUPSET;
new RMAN configuration parameters are successfully stored

4°) Verifique as configurações alteradas.

RMAN> show all;

using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name RADB are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO BACKUPSET;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT   '/u02/app/oracle/backup/rman/bkp_%d_%t_%s.rman';
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BZIP2'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/11.1.0/db_1/dbs/snapcf_RADB.f'; # default

5°) Testando o novo script.

Agora, veja como ficou o script com as customizações que foram feitas. Em negrito está as novas configurações realizadas para o RMAN.

RMAN> run {
2> shutdown immediate;
3> startup mount;
4> backup database include current controlfile tag 'BKP_FULL';
5> alter database open;
6> }

database closed

database dismounted

Oracle instance shut down

connected to target database (not started)

Oracle instance started

database mounted

Total System Global Area     644468736 bytes

Fixed Size                     1301840 bytes

Variable Size                293601968 bytes

Database Buffers             343932928 bytes

Redo Buffers                   5632000 bytes

Starting backup at 06/08/2009 11:26:16

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=154 device type=DISK

allocated channel: ORA_DISK_2

channel ORA_DISK_2: SID=153 device type=DISK

allocated channel: ORA_DISK_3

channel ORA_DISK_3: SID=151 device type=DISK

channel ORA_DISK_1: starting full datafile backup set

channel ORA_DISK_1: specifying datafile(s) in backup set

input datafile file number=00001 name=/u02/app/oracle/oradata/RADB/system01.dbf

channel ORA_DISK_1: starting piece 1 at 06/08/2009 11:26:26

channel ORA_DISK_2: starting full datafile backup set

channel ORA_DISK_2: specifying datafile(s) in backup set

input datafile file number=00002 name=/u02/app/oracle/oradata/RADB/sysaux01.dbf

input datafile file number=00004 name=/u02/app/oracle/oradata/RADB/users01.dbf

channel ORA_DISK_2: starting piece 1 at 06/08/2009 11:26:34

channel ORA_DISK_3: starting full datafile backup set

channel ORA_DISK_3: specifying datafile(s) in backup set

input datafile file number=00005 name=/u02/app/oracle/oradata/RADB/example01.dbf

input datafile file number=00003 name=/u02/app/oracle/oradata/RADB/undotbs01.dbf

channel ORA_DISK_3: starting piece 1 at 06/08/2009 11:26:47

channel ORA_DISK_3: finished piece 1 at 06/08/2009 11:30:03

piece handle=/u02/app/oracle/backup/rman/bkp_RADB_694178799_15.rman tag=BKP_FULL comment=NONE

channel ORA_DISK_3: backup set complete, elapsed time: 00:03:16

channel ORA_DISK_3: starting full datafile backup set

channel ORA_DISK_3: specifying datafile(s) in backup set

including current control file in backup set

channel ORA_DISK_3: starting piece 1 at 06/08/2009 11:30:43

channel ORA_DISK_3: finished piece 1 at 06/08/2009 11:31:23

piece handle=/u02/app/oracle/backup/rman/bkp_RADB_694179009_16.rman tag=BKP_FULL comment=NONE

channel ORA_DISK_3: backup set complete, elapsed time: 00:00:40

channel ORA_DISK_1: finished piece 1 at 06/08/2009 11:34:13

piece handle=/u02/app/oracle/backup/rman/bkp_RADB_694178778_13.rman tag=BKP_FULL comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:07:48

channel ORA_DISK_2: finished piece 1 at 06/08/2009 11:35:04

piece handle=/u02/app/oracle/backup/rman/bkp_RADB_694178786_14.rman tag=BKP_FULL comment=NONE

channel ORA_DISK_2: backup set complete, elapsed time: 00:08:30

Finished backup at 06/08/2009 11:35:04

Starting Control File and SPFILE Autobackup at 06/08/2009 11:35:04

piece handle=/u01/app/oracle/flash_recovery_area/RADB/autobackup/2009_08_06/o1_mf_s_694178760_57otk638_.bkp comment=NONE

Finished Control File and SPFILE Autobackup at 06/08/2009 11:35:29

database opened

PRONTO! Deste modo conseguimos definir regras de backup mais customizadas para cada banco de dados. É válido lembrar que nos exemples realizei os testes de backup diretamente para disco, porém, é possível configurar os mesmos parâmetros para FITA, de acordo com a sua configuração MML no ambiente.

Abraços,

Olá,

Um assunto muito pouco abordado entre os profissionais Oracle e que sempre causa estresse e problemas quando necessário, e 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 quanto é necessário e já está 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 existe 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 politíca de backup de cada banco de dados, tratado de forma única, pois em banco de dados, pelo mais que seja padronizado 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áriamente, semanalmente, mensalmente ou anual;
• Volumetria que será armazenada;
• Nível de proteção dos dados;
• Tipos de backups que serão executados;
• Definicação dos procedimentos de backup, restore e recover.

Os dois pontos citados, é 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 politícas 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 frustação ao profissional tentar implementar uma solução sem sucesso ou com diversos problemas e que não consegue 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 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. 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. Cópia fria de um servidor para o outro;
8. Cópia dos objetos de banco;
9. E no pior das hípoteses, 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 atráves do RMAN (Recovery Manager) ou atráves 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 dado 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 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, e geralmente para uma empresa isso 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 foi apagado 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, porquê 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.

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 aberto 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 porquê 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 scripts 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.

“Existe 1001 maneiras de preparar sua Estratégia de backup, invente a sua!”

E Ficamos por aqui, dúvidas, críticas e sugestões, só entrar em contato.

Abraços,

Olá,

Os organizadores da ENPO já disponibilizaram as palestras em vídeo que fizeram parte dessa última edição. Abaixo estou postando a minha palestra.

http://video.google.com/videoplay?docid=8521428875400605543

Para mais informações

ENPO - www.enpo-br.org

GPO - www.profissionaloracle.com.br

No site terá mais palestrars disponível para download e suas respectivas apresentações.

Abraços,

Olá!

A GPO já colocou a disposição em seu website a apresentação sobre a ferramenta RMAN que foi utilizada para a palestra na V ENPO para consulta dos profissionais. Acho legal realizarem o download do power point, pois a apresentação traz mais detalhes sobre a ferramenta e técnicas de backup e recover.

Para fazer o download, basta clicar aqui. E caso tenha dúvidas ou sugestões, fique a vontade para entrar em contato.

Abraços,

 

Olá,

Demorei um pouco para postar como foi o Encontro Nacional de Profissionais Oracle que ocorreu no sábado passado (29/11/2008)  na FIAP, pois estava numa correria danada e precisando um pouco de descanso.

Bom, como todas as edições da ENPO, tivemos ótimas palestras, oportunidade de conhecer diversos profissionais oracle, aumentando a rede social e agregar conhecimentos.

Nessa edição, tive o prazer para poder palestrar sobre um tema bem discutido, que é backup e recover com RMAN. Bem, a apresentação tinha bastante slides e o assunto é extenso, tive 1 hora para contar os conceitos básicos da arquitetura da ferramenta rman e suas principais funcionalidades, foi um pouco corrido, mas acho que deu para o público conhecer e entender um pouco sobre essa maravilhosa ferramenta. Em breve a apresentação estará disponível no site da ENPO e GPO.

Tivemos outras palestras bem interessantes também, como do nosso parceiro de blog e comunidade Oracle Ricardo Portilho que discutiu sobre o Load Balance em RAC, que teve uma apresentação bastante divertida (principalmente a imagem do balanceamento de cerveja entre a mulher e o homem), tive o prazer de conhecer pessoalmente, e é um cara super gente fina! Vale a recomendação de conhecer o blog dele também aqui na GPO com contéudo bem legal.

Outras palestras como o Chiappa, que discutiu um pouco sobre a utilização e o modo de utilizar a ferramenta SQL*Plus, o nosso velho e bom amigo de todos os dias, tivemos também Roberto Serson, ou show man Oracle, falando um pouco sobre Expressões Regulares, que se existe um desenvolvedor que gosta da trabalhar com a metodologia POG, ao conhecer as expressões regulares, ninguem mais irá dar manutenção em seus códigos! =D

Para o público, tivemos ainda uma boa visão geral de como trabalha o Oracle Spatial, que teve como palestrante o profissional Marcos Couto, de como o BI trabalha no geral como o Francisco Piedade, que detalhou e mostrou experiência no assunto.

E como todo palestrante, abaixo segue a imagem do meu novo trófeu recebido pelos organizadores da ENPO, que será guardado com muito carinho.

Gostei da participação da galera no geral, e desculpas por não ter dado muita atenção ao pessoal que veio tirar dúvidas durante os coffee breaks ou me esperado para almoçar, pois estava muito corrido o dia e muita gente comigo também, então estava díficil administrar tudo, quem quizer ainda discutir alguma coisa, fique a vontade de mandar e-mails para mim.

E agradeço aos organizadores (Fernanda, Morgado e Willians) pela oportunidade e aos amigos, tanto da iMasters, Affinia, Pellegrino, GPTI, IBTA e aos leitores em geral que compareceram ao evento.

Abraços,

Olá,

Em Novembro terá a 5° Edição da ENPO (Encotro Nacional de Profissionais Oracle) em São Paulo, que irá ocorrer na faculdade FIAP (www.fiap.com.br), é sempre importante ressaltar que nesses eventos podemos criar e melhorar nosso network, assim como agregar mais informações sobre os produtos e mercado Oracle.

O evento irá contar com palestras e stands de parceiros voltados ao mercado Oracle. O GPO também estará para marcar presença e compartilhar conhecimentos Oracle para seus convidados.

O cronograma das palestras esse ano está abordando assuntos bem interessantes, que variam desde RAC (Real Application Cluster) , RMAN (Recovery Manager), BI (Bussiness Inteligence), SQL*PLUS, Oracle Spatial e a utilização de Expressões Regulares no 10g e 11g.

Esse ano vocês irão ter que me aturar um pouco, irei palestrar sobre RMAN - Vilão ou Héroi? Vamos falar sobre as funcionalidades, entender a arquitetura, como funciona os backups para bancos em ARCHIVELOG e NOARCHIVELOG, tipos de backup incrementais e recover, catálogo de recuperação, dicas do dia-a-dia, as técnicas que podemos aplicar como o TSPITR (Tablespace Point-In-Time Recover), Migration Platform, Duplicate DP e Transportable Tablespace.

Espero que o público da ENPO goste desse assunto, vou procurar abordar a maioria das funcionalidades do RMAN. E também teremos outros 5 palestras que realmente são sensacionais, como, Chiappa falando sobre SQL*PLUS, como sempre digo:

“DBA que é DBA, usa SQL*PLUS”

Irá nos fornecer informações de como dominar essa ferramenta, teremos também palestra sobre RAC comPaulo Shorr, que na ENPO do início do ano fez uma ótima apresentação sobre RAC com caso de estudo, teremos o Roberto Serson discutindo sobre a utilização de Expressões regulares no 10g e 11g, assim como outras palestras sobre Oracle Spatial, que é um produto fantástico e BI que é uma área que está crescendo cada vez mais, que está com um ótimo mercado.

Então, fica o convite para todos e se encontramos na 5º Edição da ENPO.

Abraços,

Olá,

Uma dos maiores problemas de realizar uma recuperação completa ou uma restauração de um banco de dados para um novo servidor, é o problema de mencionar o DBID (Database Identifier - Identificação do banco de dados) para o catálogo do RMAN.

Pois, para conseguir uma restauração da base, é necessário mencionar o DBID ao catálogo de recuperação para conseguir associar o banco de dados no catálogo e posteriormente restaurar e recuperar seus backups sets.

Agora, vamos mencionar quais os meios que podemos encontrar o DBID de um banco de dados.

1. Dicionário de dados

Podemos realizar um simples select na view v$database para conseguir a informação, veja.

SQL> select dbid from v$database;

      DBID
----------
4263396950

1 linha selecionada.

2. RMAN - Inicío de sessão

O DBID também é informado quando você conecta ao RMAN, lembrando, que o DBID será informado se o banco de dados estiver em MOUNT ou OPEN, se apenas com NOMOUNT, não será informado, pois não irá ler o arquivo de controle, ou control file. Exemplo.

[oracle@PELSPOWMS2 ~]$ rman

Recovery Manager: Release 10.2.0.1.0 - Production on Thu Oct 23 17:15:23 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

RMAN> connect target ‘rman/##########@wmssp.world’;

connected to target database: WMSSP (DBID=4263396950)

RMAN>

3. RMAN - Usando o comando List incarnation

Outro modo de se conseguir o DBID do banco de dados, é após logar-se no banco de dados target e estar conectado ao catálogo de recuperação, utilizar o comando LIST INCARNATION, exemplo:

RMAN> list incarnation;
List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
8451    8458    WMSSP    4263396950       PARENT  1          30/06/2005 19:09:40
8451    8452    WMSSP    4263396950       CURRENT 446075     27/02/2008 09:03:20

RMAN>

Uma dica muito importante é sempre manter uma planilha com todos os bancos de dados, senhas e seus respectivos DBID armazenados após as criação do banco de dados para não correr risco de não saber o DBID do banco de dados criado.

Abraços,

Olá,

Nesse post vamos realizar um simples backup e recover do controlfile do banco de dados utilizando o RMAN, sem a necessidade de um catálogo de recuperação.

Nos exemplos, vou utilizar a versão XE (Oracle Express Edition) que é gratuita e disponível para download no site da Oracle Technology Network e também fornacerá um pequeno treinamento na utilização do RMAN. Pois bem, vamos checar alguns pontos para iniciar nossos testes, como demostrado abaixo:

C:\>start OracleServiceXE
O sistema não pode encontrar o arquivo OracleServiceXE.

C:\>sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on Sex Ago 22 13:28:33 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.
Conectado a:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

SQL> @id

HORA EXECUTADA
-------------------
22-08-2008 13:28:36
INSTANCE_NAME   HOST_NAME            STATUS
--------------- -------------------- ----------
xe              DBARODRIGO          OPEN

USER IS "SYS"

SQL> select * from v$controlfile;
STATUS     NAME                                                         IS_ BLOCK_SIZE FILE_SIZE_BLKS
---------- ------------------------------------------------------------ --- ---------- --------------
           C:\ORACLE\ORADATA\XE\CONTROL.DBF                             NO       16384            430

Atenção

Existe uma etapa que emito o comando @id, ele é apenas um script que utilizo para ver as horas, instância, servidor e o status da instância. Ele está disponível na área de script aqui do Blog, depois comento como configurar o SQLPATH para executar scripts sem a necessidade do caminho absoluto. Não confunda com um comando interno do banco de dados ou do SQL*PLUS.

Nessas etapas, estamos apenas checando informações básicas do banco e onde está seu controlfile, por padrão no XE, o controlfile veem com extensão DBF, o que pode ser um pouco diferente para quem geralmente trabalha com os controlfiles em extensão CTL (mas, não muda nada!).

Agora, vamos executar um backup atual do nosso controlfile com o RMAN, para termos um backup atualizado em casos de futuros problemas. O processo a seguir irá desativar o banco de dados pelo SQL*PLUS e posteriormente, logar-se pelo RMAN e iniciar o banco de dados no estado montado, ou seja, vou apenas abrir o controlfile do banco de dados e coletar as suas informações, porém, nesse estado, fica inutilizável para os usuários.

SQL> shutdown immediate;
Banco de dados fechado.
Banco de dados desmontado.
Instância ORACLE desativada.
SQL> exit
Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

C:\>rman target /

Gerenciador de Recuperação: Release 10.2.0.1.0 - Production on Sex Ago 22 13:30:48 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

conectado ao banco de dados de destino (não iniciado)

RMAN> startup mount;

instância Oracle iniciada
banco de dados montado

Total da área Global do Sistema     146800640 bytes

Fixed Size                     1286220 bytes
Variable Size                 62918580 bytes
Database Buffers              79691776 bytes
Redo Buffers                   2904064 bytes

RMAN> list backup of controlfile;

usar o arquivo de controle do banco de dados de destino em vez do catálogo de recuperação

Lista de Conjuntos de Backup
===================

RMAN>

Observe, executei o comando shutdown immediate para desativar o banco de dados, e logo em seguida, me conectei no RMAN usando uma autenticação pelo sistema operacional, por isso o (target /), e sem a necessidade de um catálogo de recuperação, pois o RMAN quando não usa um catálogo de recuperação pega as informações do controlfile, sobre SCN, datafiles, logs e etc.

Para uma simples conferência, acima executei o comando LIST BACKUP OF CONTROLFILE apenas para saber se já exisitia ou não um backup do controlfile. E Finalmente o mais interessante, como realizar o backup do controlfile:

RMAN> run {
2> allocate channel t1 type disk format 'c:\oracle\backup\rman\BKP_CF_%d_%t_%s.rman';
3> backup current controlfile tag 'BKP_CF';
4> release channel t1;
5> }

canal alocado: t1
canal t1: sid=35 devtype=DISK

Iniciando backup em 22/08/08
canal t1: iniciando conjunto de backup completo de arquivo de dados
canal t1: especificando arquivo(s) de dados no conjunto de backups
incluindo arquivo de controle atual no conjunto de backups
canal t1: iniciando o componente 1 em 22/08/08
canal t1: componente 1 finalizado em 22/08/08
handle de componente=C:\ORACLE\BACKUP\RMAN\BKP_CF_XE_663427972_18.RMAN tag=BKP_CF comentário=NONE
canal t1: conjunto de backups concluído, tempo decorrido: 00:00:05
Finalizado backup em 22/08/08

canal liberado: t1

RMAN> exit

No script acima, coloquei apenas um canal de I/O para realizar o backup e mandar para o destino do backup, que no exemplo, foi “c:\oracle\backup\rman\”, sempre utilizo variáveis de ambiente do RMAN para gerar o meu arquivo de backupset, no caso, %d (nome do banco de dados), %t (timestamp) e %s (sequência de backupsets gerados) junto com a extensão .RMAN, para saber que foi gerado pelo Recovery Manager.

Após realizar a tarefa, vamos ver o arquivo gerado e posteriormente os passos para simular a restauração do controlfile, todos os passos estão abaixo:

C:\>cd c:\oracle\backup\rman

C:\oracle\backup\rman>dir
 O volume na unidade C é DBA
 O número de série do volume é 7A9D-6C81

 Pasta de C:\oracle\backup\rman

22/08/2008  13:32    <DIR>          .
22/08/2008  13:32    <DIR>          ..
19/08/2008  21:58               187 afiedt.buf
22/08/2008  13:32         7.110.656 BKP_CF_XE_663427972_18.RMAN
              2 arquivo(s)  7.110.853 bytes
               2 pasta(s)  5.920.763.904 bytes disponíveis

Agora, vou para a pasta que está os arquivos de dados do Oracle XE, para deletar o controlfile.

C:\oracle\backup\rman>cd ..

C:\oracle\backup>cd ..

C:\oracle>cd oradata

C:\oracle\oradata>cd xe

C:\oracle\oradata\XE>dir
 O volume na unidade C é DBA
 O número de série do volume é 7A9D-6C81

 Pasta de C:\oracle\oradata\XE

19/08/2008  22:21    <DIR>          .
19/08/2008  22:21    <DIR>          ..
22/08/2008  13:33         7.061.504 CONTROL.DBF
22/08/2008  13:30       450.895.872 SYSAUX.DBF
22/08/2008  13:30       356.524.032 SYSTEM.DBF
19/08/2008  22:21        20.979.712 TEMP.DBF
22/08/2008  13:30        94.380.032 UNDO.DBF
22/08/2008  13:30       104.865.792 USERS.DBF
               6 arquivo(s)  1.034.706.944 bytes
               2 pasta(s)  5.920.763.904 bytes disponíveis

Vou logar no banco de dados novamente, para deletar o arquivo, pois, em ambiente windows, não é possível deletar os arquivos quando estão em uso. Então segue novamente os passos. Lembrando que meu banco de dados sempre esteve no modo MOUNT.

C:\oracle\oradata\XE>sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on Sex Ago 22 13:34:51 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.
Conectado a:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

SQL> shutdown immediate;
ORA-01109: banco de dados não aberto
Banco de dados desmontado.
Instância ORACLE desativada.
SQL> exit
Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

C:\oracle\oradata\XE>del /F /Q CONTROL.DBF

C:\oracle\oradata\XE>dir
 O volume na unidade C é DBA
 O número de série do volume é 7A9D-6C81

 Pasta de C:\oracle\oradata\XE

22/08/2008  13:35    <DIR>          .
22/08/2008  13:35    <DIR>          ..
22/08/2008  13:30       450.895.872 SYSAUX.DBF
22/08/2008  13:30       356.524.032 SYSTEM.DBF
19/08/2008  22:21        20.979.712 TEMP.DBF
22/08/2008  13:30        94.380.032 UNDO.DBF
22/08/2008  13:30       104.865.792 USERS.DBF
               5 arquivo(s)  1.027.645.440 bytes
               2 pasta(s)  5.927.821.312 bytes disponíveis

C:\oracle\oradata\XE>sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on Sex Ago 22 13:35:25 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Conectado a uma instância inativa.

SQL> startup;
Instância ORACLE iniciada.

Total System Global Area  146800640 bytes
Fixed Size                  1286220 bytes
Variable Size              62918580 bytes
Database Buffers           79691776 bytes
Redo Buffers                2904064 bytes
ORA-00205: erro na identificação do arquivo de controle, verifique o log de alertas para obter mais informações
SQL> @id

HORA EXECUTADA
-------------------
22-08-2008 13:35:36
INSTANCE_NAME   HOST_NAME            STATUS
--------------- -------------------- ----------
xe              PELSPOMARIO          STARTED

USER IS "SYS"
SQL> shutdown immediate;
ORA-01507: banco de dados n?o montado
Instância ORACLE desativada.
SQL> exit
Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

Depois de todo o processo, e ao deletar o CONTROL.DBF, tentei iniciar o banco de dados e apareceu a seguinte mensagem de erro, ORA-00205, onde não foi possível encontrar um controlfile para montar o banco de dados e posteriormente abrir aos usuários.

Isso é comum quando se perde um controlfile, em ambiente corporativos o controlfile sempre estará multiplexado, ou seja, sempre terá uma cópia fiel dos controlfile na abertura do banco, porém, dependentdo do crash, o Oracle pode dizer que um controlfile está mais atualizado que o outro, e isso é um assunto para outro post. rs.

Mas, vamos em frente, o que temos que fazer agora é apenas restaurar o controlfile que fizemos backup no início do post, aquele que foi gerado no caminho “c:\oracle\backup\rman”, e o processo de restauração também é bem fácil, observe a recuperação abaixo:

C:\oracle\oradata\XE>rman target /

Gerenciador de Recuperação: Release 10.2.0.1.0 - Production on Sex Ago 22 13:36:05 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

conectado ao banco de dados de destino (não iniciado)

RMAN> startup nomount;

instância Oracle iniciada

Total da área Global do Sistema     146800640 bytes

Fixed Size                     1286220 bytes
Variable Size                 62918580 bytes
Database Buffers              79691776 bytes
Redo Buffers                   2904064 bytes

RMAN> restore controlfile from 'c:\oracle\backup\rman\BKP_CF_XE_663427972_18.RMAN';

Iniciando restore em 22/08/08
usar o arquivo de controle do banco de dados de destino em vez do catálogo de recuperação
canal alocado: ORA_DISK_1
canal ORA_DISK_1: sid=36 devtype=DISK

canal ORA_DISK_1: restaurando arquivo de controle
canal ORA_DISK_1: restauração concluída, tempo decorrido: 00:00:03
nome do arquivo de saída=C:\ORACLE\ORADATA\XE\CONTROL.DBF
Finalizado restore em 22/08/08

RMAN> alter database mount;

banco de dados montado
canal liberado: ORA_DISK_1

RMAN> alter database open resetlogs;

banco de dados aberto.

C:\oracle\oradata\XE>sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on Sex Ago 22 13:38:15 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

Conectado a:
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

SQL> @id

HORA EXECUTADA
-------------------
22-08-2008 13:39:41
INSTANCE_NAME   HOST_NAME            STATUS
--------------- -------------------- ----------
xe              PELSPOMARIO          OPEN

 

 PRONTO! Olhe no início do LOG que ao se conectar ao RMAN, peço para realizar a restauração do controlfile pelo arquivo gerado pelo backup, ou seja, do arquivo ‘c:\oracle\backup\rman\BKP_CF_XE_663427972_18.RMAN’, e assim sendo após a restauração com sucesso é só mandar abrir o banco de dados com a opção RESETLOGS (será gerado uma nova incarnação) e permitir o acesso novamente dos usuários.

A ideia do post, vou comentar de maneira bem rápida e de fácil entendimento, como podemos realizar um backup e restore do controlfile de um banco de dados. Espero que tenham gostado.

Abraços,

 

 

Olá,

Vou passar 2 dicas preciosas para quem trabalha no dia-a-dia com o RMAN, e quer monitorar os processos realizados por ele. Segue as dicas.

1° Dica

A primeira dica é monitorar os processos de servidor (Channels) do RMAN ao efetuar um backup ou recover na instância de destino (TARGET), pois, nunca sabemos se irá demorar ou não para realizar o backup, para acabar com esse problema, existe o SELECT abaixo:

SQL> l
  1  select sid,
  2         serial#,
  3         context,
  4         sofar,
  5         totalwork,
  6         round(sofar/totalwork*100,2) “%_complete”
  7  from
  8         v$session_longops
  9  where
 10         opname like ‘RMAN%’
 11         and opname not like ‘%aggregate%’
 12         and totalwork != 0
 13*        and sofar <> totalwork

SQL> /

  SID   SERIAL#   CONTEXT     SOFAR   TOTALWORK %_complete
 ----   -------  --------   ------- ----------- ----------
  312     54367         1    455672     1044904      43,61
  295     58222         1    435192     1076910      40,41

 Para cada canal (channel) alocado no banco de dados para realização da tarefa de backup ou recover, representa uma sessão no resultado acima. Para exemplificar, o script de RMAN utilizado para realizar o backup (de archives), segue abaixo:

RMAN> print script bkp_archives_diario;

printing stored script: bkp_archives_diario
 {

  allocate channel t1 type disk format '/u02/backup/rman/BKP_ARCHIVES_DIARIO_%d_%t_%s.rman';
  allocate channel t2 type disk format '/u02/backup/rman/BKP_ARCHIVES_DIARIO_%d_%t_%s.rman';
  sql 'alter system checkpoint global';
  backup archivelog all tag 'BKP_ARCHIVES_DIARIO';
  release channel t2;
  release channel t1;
}

Como nosso script acima está usando 2 canais (Channel t1 e Channel t2), será exibido o progresso de cada sessão que é o ”%_complete” de cada canal utilizado. Resumindo, com esse simples SELECT feito na instância TARGET, conseguimos monitorar as tarefas básicas do RMAN.

2° Dica

Para acompanhar o status das tarefas realizadas pelo RMAN na sua base target, o SELECT abaixo pode lhe auxiliar, veja:

SQL> l
  1  select operation as “OPERACAO”,
  2         object_type as “TIPO”,
  3         status,
  4         output_device_type as “MEDIA”,
  5         to_char(end_time,’DD-MM-RRRR HH24:MI:SS’) as “DATA”,
  6         round(MBYTES_PROCESSED/1024,2) as “TAMANHO(MB)”
  7  from
  8         v$rman_status
  9  where
 10         operation <> ‘CATALOG’
 11         and trunc(end_time)>=trunc(sysdate-1)
 12  order by
 13*        end_time
SQL> /

OPERACAO                                 TIPO          STATUS          MEDIA             DATA              TAMANHO(MB)
---------------------------------------- ------------- --------------- ----------------- -------------------- -----------
CONTROL FILE AND SPFILE AUTOBACK                       COMPLETED       DISK              27-07-2008 20:08:27          ,01
BACKUP                                   DB FULL       COMPLETED       DISK              27-07-2008 20:08:31        22,21
RMAN                                                   COMPLETED                         27-07-2008 20:08:31        22,21
CONTROL FILE AND SPFILE AUTOBACK                       COMPLETED       DISK              27-07-2008 22:00:34          ,01
BACKUP                                   ARCHIVELOG    COMPLETED       DISK              27-07-2008 22:00:38          ,53
RMAN                                                   COMPLETED                         27-07-2008 22:00:38          ,54
CONTROL FILE AND SPFILE AUTOBACK                       COMPLETED       DISK              27-07-2008 23:00:22          ,01
BACKUP                                   ARCHIVELOG    COMPLETED       DISK              27-07-2008 23:00:22           ,3
RMAN                                                   COMPLETED                         27-07-2008 23:00:26          ,31
CONTROL FILE AND SPFILE AUTOBACK                       COMPLETED       DISK              28-07-2008 15:40:08          ,01
BACKUP                                   ARCHIVELOG    COMPLETED       DISK              28-07-2008 15:40:12         1,02
RMAN                                                   COMPLETED                         28-07-2008 15:40:12         1,03
RMAN                                                   COMPLETED WITH                    28-07-2008 16:32:24            0
                                                       ERRORS

O resultado será todas as atividades feitas pelo RMAN que foram registradas pelo catálogo de recuperação, perceba que para cada atividade, a coluna TIPO nos mostra qual atividade foi feita na instância junto  com o seu respectivo status. Deste modo conseguimos ter mais controle sobre as operações do RMAN em cada banco de dados gerenciado por ele.

A view v$rman_status fornece mais informações importantes que você poderá adaptar a sua necessidade, as outras opções existente estão abaixo, quando realizo o select abaixo, veja:

SQL> select column_name from dba_tab_columns where table_name = 'V_$RMAN_STATUS';

COLUMN_NAME
------------------------------
SID
RECID
STAMP
PARENT_RECID
PARENT_STAMP
SESSION_RECID
SESSION_STAMP
ROW_LEVEL
ROW_TYPE
COMMAND_ID
OPERATION
STATUS
MBYTES_PROCESSED
START_TIME
END_TIME
INPUT_BYTES
OUTPUT_BYTES
OPTIMIZED
OBJECT_TYPE
OUTPUT_DEVICE_TYPE

Espero que essas dicas possa ajudar.