Backup & Recovery Parte 3 - Recuperação Incompleta

Quando um Banco de Dados se encontrar danificado, em quase toda as circunstâncias o DBA deve fazer uma recuperação completa, ou seja voltar a base sem perdas de transações "commitadas". Contudo em algumas situações extremas não será possível faze-lo.

Pode acontecer também que o DBA deliberadamente decida perdes transações, o que não quer dizer necessariamente perdas de dados. Pois se um usuário executar um comando delete com um commit na tabela inteira de funcionário, no que consiste em uma transação de banco de dados está tudo correto, mas a nível de negocio não.

Será mostrado como realizar uma recuperação incompleta do banco de dados, primeiramente restaurando o banco a uma tempo qualquer no passado para recuperar uma antiga informação e depois será apresentado um caso extremo como devido a falto do Log de Redo On-line, será feito um recover incompleto do banco de dados.

Para poder realizar as operações neste artigo é necessário que o banco de dados esteja configurado para realizar backup, conforme os artigos anteriores. Nestes testes serão usados duas maquinas virtuais com Windows 7, uma maquina virtual simulará o banco de produção, e a outra será um banco restaurado a partir dos backup de produção. A maquina real será um servidor de backup, onde guardará os backup feito pelo banco de produção.

 E evidente que este ambiente é somente para estudo e demostração neste artigo, em um ambiente real de produção, casa servidor seria uma maquina separada e fisicamente protegida contra acidentes e eventuais roubos.

Recuperando o Banco a partir de uma perda lógica 

Em um cenário de uma T.I, por volta das 08h50min da manhã do dia 21/11/2012 um desenvolver exclui um SCHEMA importante do sistema de produção, achando que estava logado em uma base de teste. Então depois de cerca de 10 minutos depois ele de forma desesperada decide acionar o DBA para solucionar o problema. Os demais SCHEMAS estão funcionando normalmente recebendo milhares de inserções e cada segundo que o banco esteja fora do ar representa prejuízo para a empresa.
Em cenários como estes, é importante que o banco de dados esteja com o recurso flashback, pois o “Recover Incompleto” inspecionará os arquivos de dados restaurados, e neste caso seria necessário restaurar todos os datafiles o que demandaria uma janela de tempo de recuperação maior.
Por isto, ative o flashback database do banco de dados conforme os passos abaixo:

SQL> alter system set db_recovery_file_dest=' C:\bck_oracle\flash_recovery_area;

SQL> alter system set db_recovery_file_dest_size=8G;

SQL> alter system set db_flashback_retention_target=240;

SQL> shutdown immediate;

SQL> startup mount;

SQL> alter database flashback on;

SQL> alter database open;

Feito esta devida configuração, segue a simulação da recuperação do schema dropado.

O DBA entra com usuário SYS e verifica que realmente as tabelas daquele schema não existem;

SQL> connect sys/senha as sysdba

Conectado.

SQL> select count(*) from schema_importante.aca_aluno;

select count(*) from schema_importante.aca_aluno

ERRO na linha 1: ORA-00942: a tabela ou view não existe
Então o próximo passo é desligar o banco de dados.

SQL> shutdown immediate;

Banco de dados fechado.

Banco de dados desmontado.

InstÔncia ORACLE desativada.

Inicie o banco no Estado montado, o banco não ficará disponíveis para os usuários e estará pronto para aguardar a recuperação.

SQL> startup mount;

InstÔncia ORACLE iniciada.

Total System Global Area  612368384 bytes

Fixed Size                  1292060 bytes

Variable Size             436209892 bytes

Database Buffers          171966464 bytes

Redo Buffers                2899968 bytes

Banco de dados montado.

Execute o comando de flashback para voltar o banco de dados como estava as 8h50min.

SQL> flashback database to timestamp to_timestamp('21-11-2012 08:50:00','dd/mm/yyyy hh24:mi:ss');
 Flashback concluÝdo.

Depois abra o banco como comente leitura.

SQL> alter database open read only;

Verifique se os dados foram restaurados, caso não apareça, volte a executar o comando flashback voltando ainda mais o tempo.

SQL> select count(*) from schema_importante.aca_aluno;

  COUNT(*)

----------

       705

Após confirmado que o Schema foi restaurado no banco de dados, realize a exportação do schema.

C:\>exp system/senha file=c:\bck_oracle\schema_importante.dmp owner=schema_importante

Export: Release 10.2.0.3.0 - Production on Qua Nov 21 09:31:00 2012
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
Conectado a: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Product

. sobre exportar tabelas de SCHEMA_IMPORTANTE ... via Caminho Convencional ...

. . exportando tabela                      ACA_ALUNO        705 linhas exportada

. . exportando tabela                      ACA_CURSO          8 linhas exportada

. . exportando tabela                    ACA_DIAAULA       1080 linhas exportada

.....

. exportando filhos e grupos de renovaþÒo

. exportando dimens§es

. exportando objetos e aþ§es procedurais posteriores ao esquema

. exportando estatÝstica

ExportaþÒo encerrada com sucesso, sem advertÛncias.

Depois de exportado o schema, faça o recover completo do banco de dados.

C:\>sqlplus /nolog

SQL> connect sys/senha as sysdba;

SQL> shutdown immediate;

SQL> startup mount;

SQL> recover database;

SQL> alter database open;

 O banco de dados irar restaurar todas as transações feita no banco de dados, e então logicamente o DROP do Schema, como confirmado no SQL abaixo:

SQL> connect sys/senha as sysdba

Conectado.

SQL> select count(*) from schema_importante.aca_aluno;

select count(*) from schema_importante.aca_aluno

ERRO na linha 1: ORA-00942: a tabela ou view não existe

Neste momento faça o importe banco a partir do arquivo dump gerado.

C:\>imp system/senha touser=schema_importante fromuser=schema_importante file=C:\bck_oracle\schema_importante.dmp
SQL> select count(*) from schema_importante.aca_aluno;

  COUNT(*)

----------

       705

Então seus dados foram recuperados sem nenhuma perda de dados, tanto as transações dos usuários feitas no intervalo de 08:50 e 09:00 bem o schema dropado foram restaurados.

Restaurando o Banco de Dados em Outro Servidor

 

O próximo cenário é uma situação mais complexa e não é uma tarefa trivial. Ocorre que o servidor sofreu uma pane geral, prejudicando todos os discos e todos os arquivos de banco de dados como os controlfiles, datafiles, online redo log files, além do spfile, foram perdidos.

Em uma instalação padrão este cenário seria terrível para o DBA, mas se o banco de dados foi ajustado conforme os artigos anteriores, o Backup do Oracle bem como os archives está protegido em outro servidor.

Neste artigo, o cenário é que já tem um banco de dados Oracle em outra maquina. Os passos será dropar o banco de dados e depois restaurar/recuperar o Banco de dados.  Se no caso o Oracle precisar ser instalado, instale somente o software e faça o restore/recover e para facilitar a restauração instale a mesma versão e a instância com o mesmo nome.

No cenário montado, o servidor Oracle é o IP 192.168.138.129 que sofreu a pane. Todos os backup’s e o archives encontra-se no IP 192.168.149.1. A restauração será realizada na maquina de IP 192.168.138.130.

Para dropar logue no banco de dados e inicie no modo restrito e execute o drop database como mostrado a seguir:

C:\>sqlplus /nolog

SQL> connect sys/senha as sysdba

SQL> shutdown immediate;

SQL> startup mount restrict;

SQL> drop database;

Banco de Dados eliminado.

Inicie o banco de dados com o backup do ini.ora

SQL> connect sys/senha as sysdba

Conectado a uma instância inativa.

SQL> startup nomount pfile=\\192.168.149.1\bck_oracle\INIT.ORA

Instância ORACLE iniciada.

Total System Global Area  612368384 bytes

Fixed Size                  1292060 bytes

Variable Size             306186468 bytes

Database Buffers          301989888 bytes

Redo Buffers                2899968 bytes

SQL>

Todos os scripts de backup’s realizado nesta série de artigos tem a inclusão do controlfile, por isso sempre terá dois arquivos de backup, um com o tamanho próximo do banco, que é o backup dos datafiles, e um pequeno (neste exemplo tem 6 mega) que é do ControlFile. No Rman execute o Restore do ControlFile a partir do backup mais novo do controlfile.

C:\>rman target sys/senha nocatalog

conectado ao banco de dados de destino: PROD (not mounted)

usar o arquivo de controle do banco de dados de destino em vez do catálogo de re

cuperação

RMAN> restore controlfile from '\\192.168.149.1\bck_oracle\Level0\LEV0DAT02NQPNL5.BKP';

Iniciando restore em 21/11/12

canal alocado: ORA_DISK_1

canal ORA_DISK_1: sid=156 devtype=DISK

canal ORA_DISK_1: restaurando arquivo de controle

canal ORA_DISK_1: restauraþÒo concluÝda, tempo decorrido: 00:00:11

nome do arquivo de saÝda=C:\ORACLE\PRODUCT\10.2.0\ORADATA\PROD\CONTROL01.CTL

nome do arquivo de saÝda=C:\ORACLE\PRODUCT\10.2.0\ORADATA\PROD\CONTROL02.CTL

nome do arquivo de saÝda=C:\ORACLE\PRODUCT\10.2.0\ORADATA\PROD\CONTROL03.CTL

Finalizado restore em 21/11/12

Com o ControlFile restaurado monte o banco de dados.

RMAN>alter database mount;
Execute o comando List backup e veja todos os backups que estão catalogados no controlfile.

RMAN>list backup;
....

    Lista de Itens de Backup do conjunto de backup 1 No. da C¾pia1....

    BP Key  Pc# Status      Piece Name

    ------- --- ----------- ----------

    1       1   AVAILABLE   C:\BCK_ORACLE\LEVEL0\LEV0DAT01NQPNFV.BKP

  C¾pia do Conjunto de Backup n·m. 2 do conjunto de backup 1

  Tipo de Dispositivo Tempo Decorrido Horßrio de ConclusÒo Tag Compactada

  ----------- ------------ -------------------- ---------- ---

  DISK        00:02:42     20/11/12             NO         TAG20121120T144935

    Lista de Itens de Backup do conjunto de backup 1 No. da C¾pia2

    BP Key  Pc# Status      Piece Name

    ------- --- ----------- ----------

    2       1   AVAILABLE   \\192.168.149.1\BCK_ORACLE\LEVEL0\LEV0DAT01NQPNFV.BKP

Observe que como os backup’s eram multiplexados tanto no servidor local como na maquina remota, o Oracle tem em seu catalogo todos os backup’s, mas como servidor de produção deu pane, não temos os backup’s na unidade C:\. É preciso informar isso para o Oracle através do comando CROSSCHECK para ele verificar se existe realmente o backup. Como não encontrará da unidade C:\ mande apaguar com o comando delete do Rman.

RMAN> crosscheck backup;

Iniciando implicit crosscheck backup em 21/11/12

.......

componente de backup submetido a verificaþÒo cruzada: localizado como 'EXPIRED'

handle de componente de backup=C:\BCK_ORACLE\LEVEL0\LEV0DAT01NQPNFV.BKP id reg.=

1 marcaþÒo=799858176

componente de backup submetido a verificaþÒo cruzada: localizado como 'AVAILABLE'

handle de componente de backup=\\192.168.149.1\BCK_ORACLE\LEVEL0\LEV0DAT01NQPNFV

.BKP id reg.=2 marcaþÒo=799858176

Fez a verificaþÒo cruzada de 2 objetos

O backup que encontra-se na Unidade C:\ foi marcado como EXPIRED, ou seja o Oracle não encontrou o backup. Isto é obvio, pois este backup esta na unidade C:\ do servidor de produção. Exclua do catalogo este backup.

RMAN> delete expired backup;

utilizando o canal ORA_DISK_1

Lista de Componentes de Backup

BP Key  BS Key  Pc# Cp# Status      Device Type Piece Name

------- ------- --- --- ----------- ----------- ----------

1       1       1   1   EXPIRED     DISK        C:\BCK_ORACLE\LEVEL0\LEV0DAT01NQ

PNFV.BKP

Deseja realmente deletar os objetos acima (informe YES ou NO)? yes

componente de backup deletado

handle de componente de backup=C:\BCK_ORACLE\LEVEL0\LEV0DAT01NQPNFV.BKP id reg.=

1 marcaþÒo=799858176

Deletou 1 objetos EXPIRADOS

RMAN>

O backup de rede foi marcado como ‘AVAILABLE' e o Oracle sabe que este backup está disponível e pode contar com este para recuperação. Então execute o Restore.

RMAN> restore database;

Iniciando restore em 21/11/12

restaurando arquivo de dados 00001 para C:\ORACLE\PRODUCT\10.2.0\ORADATA\PROD\SYSTEM01.DBF
.....Finalizado restore em 21/11/12

Antes de executar o backup, instrua o Oracle para usar os archives que estão na Rede e depois limpe o segundo parâmetro para não usar os archives locais, como foi configurado o banco de produção nos artigos anteriores.

SQL> alter system set log_archive_dest_1='location=\\192.168.149.1\bck_oracle\Archives\';

SQL> alter system set log_archive_dest_2='';

Depois realize um recover do banco de dados a partir do Backup de Controlfile. O Oracle irar sincronizar todos os datafiles usando todos os archives disponíveis na rede. Todas as transações que estava somente no Log de Redo Online não serão restauradas, pois os mesmo se perderam no servidor de produção.

Vale lembrar que Log de Redo Online contem todas as alterações feitas no banco, mas confirmadas e as que não, então pode acontecer que dentro do Log de Redo OnLine tenham somente transações incompleta, se isto ocorrer a recuperação incompleta será na verdade completa, pois estas transações seria desfeitas (RollBack), mas não temos garantia quanto a isso, todavia se houver perdas de transações confirmadas estas serão mínimas.

SQL> recover database until cancel using backup controlfile;

ORA-00279: alterar 607324 gerado em 11/20/2012 14:49:36 necessario para o

thread 1

ORA-00289: sugest?o :

\\192.168.149.1\BCK_ORACLE\ARCHIVES\ARC00008_0799846584.001

ORA-00280: alterar 607324 para o thread 1 esta na sequencia  #8

Especificar log: {=nome de arquivo | sugerido | AUTO | CANCEL}

Aceite a sugestão do Oracle digitando Auto, o Oracle irar aplicar todos os archives que ele encontrar no diretório sinalizado, em um determinado momento ele irar tentar aplicar o archive que ainda não existe retornando o erro abaixo.

'\\192.168.149.1\BCK_ORACLE\ARCHIVES\ARC00010_0799846584.001 arquivado'

ORA-27041: n?o e possivel abrir arquivo

OSD-04002: n┐o ┐ poss┐vel abrir arquivo

O/S-Error: (OS 2) O sistema n┐o pode encontrar o arquivo especificado.

Agora abra o banco de dados com ResetLogs

SQL> alter database open resetlogs;

Banco de dados alterado.

SQL>

Pronto, seu banco de dados foi recuperado em outro servidor, basta fazer os sistemas logarem no novo servidor.

Conciderações

Neste artigo foi mostrado como restaurar o Banco de Dados, quando ocorre uma catástrofe tanto logica como física.

Na primeira situação, foi usado o recurso de FlashBack DataBase (em materiais oficiais da Oracle, recuperação incompleta e FlashBack DataBase são tratados em tópicos diferentes.) para agilizar a restauração. Na segunda situação apresentamos uma restauração incompleta aplicando todos os archivelogs disponíveis na rede.

Com a recuperação feita neste artigo, é possível criar um Banco de Homologação/Teste em outro servidor a partir do Backup Rman. Criando scripts que execute em lote todos os passos apresentados neste artigo, caso o servidor de Homologação/Teste não tenha os mesmos diretórios de produção será preciso executar uns passos a mais como mostrados nos artigos de backup anteriores para renomear os arquivos de banco de dados.

Backup & Recovery Parte 2 - Realizando o Backup e Restaurando o Banco de dados

No artigo anterior, foi mostrando as configurações para aumentar as chances do banco de dados ser recuperado, neste arquivo será mostrado o processo de backup e recuperação.

Backup Oracle pelo RMAN

Todo backup que o feito para o RMAN é catalogado, ou seja o Rman sabe onde estão os arquivos de backup, e no momento do Restore, o RMAN irá procurar pelos backup onde ele os criou. O catalogo do Rman é obrigatoriamente feito no ControlFile,e opcionalmente em outro banco, que seria um banco de catalogo, este artigo irar trabalhar somente com o catalogo no ControlFile.

O Rman executa uma variedade de backups, tais como Cópia de Imagem e backup Piece entre outros. O que será apresentado é backup incremental, que para poder funcionar o banco deve esta no modo archive log, como já apresentado.

Em resumo o backup incremental é composto por um backup completo do banco de dados, chamado de nível 0 e depois temos os backups incrementais, nível 1, que inclui tudo que ocorreu no banco após o último backup nível zero.

Primeiramente crie um arquivo Texto com o nome RmanLEVEL0.rman e inclua os comandos abaixo, adaptado para o local onde deseja realizar o backup, para realizar o backup nível Zero.

run { allocate channel discozero type disk format
'C:\bck_oracle\Fisico\Level0\LEV0dat%u.bkp',
' \\172.16.1.21\BCK_ORACLE\Fisico\Level0 \LEV0dat%u.bkp';
backup copies 2 incremental level = 0 (database include current controlfile);}

Depois crie outro arquivo com o nome RmanLEVEL1.rman e inclua o comando

run { allocate channel discozero type disk format
'C:\bck_oracle\Fisico\Level1\LEV1dat%u.bkp',
' \\172.16.1.21\BCK_ORACLE\Fisico\Level1 \LEV1dat%u.bkp';
backup copies 2 incremental level = 1 (database include current controlfile);}

É preciso criar outro script executável (.bat ou cmd no Windows) para chamar o Rman e invocar o arquivo de Backup. Crie no mesmo diretório onde encontra o arquivo o RmanLEVEL0.rman o arquivo “bck_fisico_Leval0.cmd”,dentro dele, coloque a instrução abaixo:

Rman target sys/@xe nocatalog @RmanLEVEL0.rman >> log_nivel_0.log

Através do agendador de tarefa do Sistema Operacional, configure o backup nível 0 a ser realizado pelo menos duas vezes na semana, e o nível 1 para fazer nos demais dias da semana.

Estes scripts instrui o Rman a criar um backup multiplexado, sendo um em disco local e outro no disco remote e sempre incluir o controlFile no backup.

NOTA: Caso ocorrá erros de privilegios ao executar o backup no disco remoto, configure o serviço do banco de dados com algum usuário de rede, conforme mostrado na 1º parte deste artigo.

Os backups multiplexado têm a grande vantagem de um ser exatamente igual ao outro, então caso tenhamos somente backups da maquina remota, por exemplo, os incrementais não dependerão de pedaços que encontra na maquina onde hospeda o banco de dados. Se os backups forem executados primeiro em um destino e depois no outros, os backups incrementais dependerão de todo o conjunto de backup.

Depois, criei mais dois arquivos para apagar os backup's obsoletos - que estão fora da janela de 7 dias, (como mostrado no artigo anterior) um para logar e chamar o arquivo que contem o comando rman que apaga e outro arquivo que contem a instrução, DELETE OBSOLETE.

run {
backup database plus archivelog;
crosscheck archivelog all;
crosscheck backup;
delete obsolete;
}

                                                Recuperação do Banco de Dados

Apesar da tarefa de restore & recover não ser uma tarefa trivial, se seguido os passos informado neste artigo a recuperação do banco de dados será perfeitamente possível e ainda em uma janela pequena de tempo.

Serão apresentadas algumas situações de falhas e quais ações são necessárias para a restauração do Banco.

Contudo, antes de apresentar é preciso especificar o que RESTARAÇÃO e RECUPERAÇÃO do banco de dados.

RESTAURAÇÃO: Consiste no processo da recriação de um ou mais arquivos que compõe o banco de dados, se for necessário a restauração de todos os arquivos, diz que se faz restauração do banco de dados. Existe situação, tal quando é preciso restaurar um backup do ControFile, é preciso restaurar o banco de dados inteiro.

RECUPERAÇÃO: Consiste no processo quando o arquivo existe, porém ele (ou mais de um arquivo) encontra-se inconsistente em relação ao ControlFile e demais arquivos que compõem o banco de dados. Dentro do ControlFile o e no cabeçalho de cada arquivo o guardo o valor SCN, um número seqüencial, que se comporta como um relógio de tempo do banco de dados. Antes de abrir o banco de dados checa se todos os arquivos têm o mesmo SCN, caso não o arquivo necessita de restauração.

Primeiramente, para realizar a recuperação do arquivo de dados, é preciso que o arquivo esteja inconsistente. Para isso desligue o banco, faça uma copia de qualquer arquivo de dados, inicie o banco de dados e desligue novamente, troque o arquivo de dados original pelo arquivo de dados copiado e inicie novamente.

Ocorrerá o erro ora-01113, dizendo que o arquivo de dados precisa de recuparação de midia ao tentar abrir o banco de dados.

ORA-01113: o arquivo 5 precisa da recuperação de mídia
ORA-01110: 5 do arquivo de dados:
'C:\ORACLEXE\APP\ORACLE\ORADATA\XE\DADOS01.DBF'

Neste caso o Oracle, informou que qual arquivo de dados esta com problema, então basta simplemente executar o comando RECOVER e depois abrir o banco de dados.

SQL> recover datafile 5;
Recuperaçãode mídia concluída.
SQL> alter database open;

Banco de dados alterado.

Pronto, seu banco de dados já está disponível, parece simples não? E é, quando você já preparou tudo antes da falha acontecer. Mas o que aconteceu aqui? É preciso entender o que ocorreu. Lembre o SCN que é um numero sequencial interno do Oracle que funciona como um relogio. Pois bem, o arquivo 5 do datafile estava dessincronizado com restante do banco de dados.

Para ilustração, suponha que o banco de dados esteja com valor igual a 10 o scn, quando foi desligado pela primeira fez foi para 11, neste instante o arquivo 5 foi copiado. Feito isso, o banco de dados foi iniciado, SCN foi para 12, então o banco foi desligado novamente, SCN foi para 13. O arquivo de dados 5 foi trocado pela cópia (que esta com SCN igual a 11) , ao tentar abrir o banco de dados checou o valor do SCN de todos os arquivos que compoem o banco de dados, e com isso conclui que o arquivo 5 precisa de recuperação de mídia.

Como toda operação que ocorre no banco de dados, o Oracle grava no Log de Redo Online e também em algum arquivo do S.O. O Oracle usou o conteúdo do Archive, caso necessario, e o conteúdo do Log de Redo Online para atualizar as operações no datafile 5 e como consequencia, colocar o SCN deste arquivo como 13, podendo então este banco ser aberto.

Agora, será feito a RESTAURAÇÃO de algum arquivo de dados, para isso, desligue o servidor e apague algum arquivo de dados do Oracle e tente iniciar o banco, irar aparecer uma mensagem de erro.

Banco de dados montado.
ORA-01157: não é possível identificar/bloquear arquivo de dados 5 - consulte arquivo de análise BWR
ORA-01110: 5 do arquivo de dados:
'C:\ORACLEXE\APP\ORACLE\ORADATA\XE\DADOS01.DBF'

Agora o Oracle após montar a instância, ele procurou todos os arquivos de dados que o controlfile disse que existe, e como o arquivo não existe, apareceu o erro. Este erro pode acontecer por exemplo se os datafiles estão em vários discos e ocorre algum crash em um dos disco.

Basta executar o banco RESTORE e depois RECOVER no RMAN e então abrir o banco de dados.

C:\>rman target sys/senha nocatalog
RMAN> restore datafile 5;
Iniciando restore em 06/02/12
......
RMAN> recover datafile 5;
RMAN> sql "alter database open";

Ao executar o Restore, o banco de dados usou o último backup físico nível zero para recriar o arquivo de dados, como este arquivo vai estar descincronizado com o banco, execute o restore, depois abrar o banco.
Note que o Oracle recriou arquivo no mesmo diretorio que ele espera que o arquivo existia, mas se este arquivo esta em algum disco que esta indisponivel?

Para simular isso, desligue o banco de dados e altere o arquivo para diretorio do S.O e depois tente iniciar.

SQL> shutdown immediate
Banco de dados fechado.
Banco de dados desmontado.
InstÔncia ORACLE desativada.

Copie algum arquivo de dados para outro diretorio e depois inicie o banco de dados no esta mount.

SQL> startup mount;
InstÔncia ORACLE iniciada.
Total System Global Area 795127808 bytes
Fixed Size 1386496 bytes
Variable Size 499124224 bytes
Database Buffers 289406976 bytes
Redo Buffers 5210112 bytes
Banco de dados montado.

Renome o arquivo, informando o novo local do datafile.

SQL> ALTER DATABASE RENAME FILE
to 'C:\Particular\DADOS01.DBF';
Banco de dados alterado.

Desligue o banco, depois apague o diretorio, ou renomei - o que acha melhor - e então tente abrir, a mesangem erro irar aparecer ORA-01157.

Ao simplesmente executar o comando restore irar aparecer um erro, sinalizando que o oracle não consegue criar o arquivo porque o diretorio que este esta tentando fazer a restauração não existe.

RMAN> restore datafile 5;
Iniciando restore em 06/02/12
.....
ORA-19504: falha ao criar arquivo "C:\PARTICULAR\DADOS01.DBF"
ORA-27040: erro ao criar arquivo, não foi possível criar o arquivo
OSD-04002: não foi possível abrir arquivo
O/S-Error: (OS 3) O sistema não pode encontrar o caminho especificado.
failover para backup anterior
.....

Como o diretorio onde estava o Data File não esta disponivel, será preciso dizer ao Oracle para usar algum diretorio disponivel. Para isso use o comando SET NEWNAME e depois o restore.

run {set newname for datafile 5 to 'C:\oraclexe\app\oracle\oradata\XE\dados01.dbf';
restore datafile 5;}

executando comando: SET NEWNAME
Iniciando restore em 06/02/12
....
Finalizado restore em 06/02/12

Depois informe ao CONTROLFILE o ludar onde esta o arquivo de Dados Restaurado.

SQL> ALTER DATABASE RENAME FILE 'C:\Particular\DADOS01.DBF' to 'C:\oraclexe\app\
oracle\oradata\XE\dados01.dbf';
Banco de dados alterado.

Faça a recuperação do arquivo recem criado.
SQL> recover datafile 5;
Recuperação de mídia concluída.

Então abra o Banco de dados.

SQL> alter database open;
Banco de dados alterado.

Agora, será feito o exercicio, onde precisaremos restaurar o banco de dados inteiro. Pode ser que alguem deliberadamente apagou todos os arquivos do banco de dados ou em um outro cenário, onde o Oracle foi instado no c:\ , mas todos os arquivos do banco esta em outro disco, unidade d:\, por exemplo.

Para simular o primeiro cenario desligue a base de dados, então exclua todos os datafile e o(s) controlfile(s) do banco de dados. Neste cenario ao tentar iniciar a instancia, será apresentado o erro: Ora-00205, o que significa que o banco nem consegui ser montado, porque o ControlFile não foi excluido.

SQL> startup
Instância ORACLE iniciada.
Total System Global Area  795127808 bytes
Fixed Size                  1386496 bytes
Variable Size             499124224 bytes
Database Buffers          289406976 bytes
Redo Buffers                5210112 bytes
ORA-00205: erro na identificação do arquivo de controle, verifique o log de
alertas para obter mais informações.

Como as informações dos backup's estão no controlfile, antes de executar o Restore/Recover, será preciso Restaurar o ControlFile. Será preciso saber onde estão o seus backup, para informar ao Oracle a sua localização.

Como todo script de backup tem a instrução de incluir o ControlFile em seus backup, existirá dois arquivos para cada backup executado, um com o Backup de todos o DataFile e outro do ControlFile. Como o ControlFile é pequeno, o backup dele também será pequeno em relação aos datafile.

RMAN> restore controlfile from 'C:\Backup\LEV0DATE06N2KN55.BKP';
Iniciando restore em 07/02/12
....
Finalizado restore em 07/02/12

Com o ControlFile resturado, monte o banco de dados e faça a restauração dos DataFiles do Banco de dados, depois a recuperação e abra o banco de dados.

RMAN> sql "alter database mount";

RMAN> restore database;
Iniciando restore em 07/02/12
...
Finalizado restore em 07/02/12

RMAN> recover database;
Iniciando recover em 07/02/12
....
Finalizado recover em 07/02/12

RMAN> sql "alter database open resetlogs";


Feito isso, o Banco de Dados já foi restaurado e pronto para uso. Neste cenario, os diretorios originais do ControlFile e DataFile existia, contudo se eles não estiverem disponiveis, por exemplo, o Oracle foi instado no c:\ , mas todos os arquivos do banco esta em outro disco, unidade d:\, e este disco perdeu.

Para simular isto, desligue novamente a base e depois apague todos os arquivos de dados e renomei a basta onde estão seus arquivos. No caso, foi excluidos todos os arquivos e depois a pasta XE, onde se encontrava todos os arquivos do banco de dados foi renomeado para XENEW.

C:\oraclexe\app\oracle\oradata\XE para C:\oraclexe\app\oracle\oradata\XENEW

No SQLPLUS tente iniciar a instância, ocorrerá o erro ORA-00205, então pelo Rman, tente restaurar o ControlFile. Então ocorrerá erro ORA-27040.

RMAN> restore controlfile from 'C:\Backup\LEV0DATE06N2KN55.BKP';
Iniciando restore em 07/02/12
....
ORA-27040: erro ao criar arquivo, não foi possível criar o arquivo
OSD-04002: não á possível abrir arquivo
O/S-Error: (OS 3) O sistema não pode encontrar o caminho especificado.
RMAN>

Este erro ocorreu, porque o Oracle tentou criar o ControlFile no diretorio de origem, onde o mesmo não esta disponivel, com isso será preciso intruir o Oracle há criar o ControlFile em outro diretorio, para crie um arquivo INIT.ORA a partir do SPFILE do Oracle, pois o SPFILE tem todos os parametros atualizado.

 SQL> create pfile='c:\backup\init.ora' from spfile;

Abra o arquivo e altere o parametro ControlFile para algum diretorio disponivel, desligue o banco de dados, inicie o banco no estado nomount com o pfile, crie um no spfile de depois execute o recover pelo Rman.

 SQL> shutdown immediate;
ORA-01507: banco de dados não montado
Instância ORACLE desativada.

SQL> startup nomount pfile='c:\backup\init.ora';
Instância ORACLE iniciada.
Total System Global Area  795127808 bytes
Fixed Size                  1386496 bytes
Variable Size             499124224 bytes
Database Buffers          289406976 bytes
Redo Buffers                5210112 bytes
SQL> create spfile from pfile='c:\backup\init.ora';

RMAN> restore controlfile from 'C:\Backup\LEV0DATE06N2KN55.BKP';
Iniciando restore em 07/02/12
...
nome do arquivo de saída=C:\ORACLEXE\APP\ORACLE\ORADATA\XENEW\CONTROL.DBF
Finalizado restore em 07/02/12
RMAN>

Neste momento pode alterar o local de arquivo por arquivo, como ilustado anteriormento, ou simplemente instruir o RMAN a restaurar todos os DataFile para um diretorio comum, para isso faça:

SQL> alter system set DB_CREATE_FILE_DEST='C:\oraclexe\app\oracle\oradata\XENEW'

RMAN> run {set newname for datafile 1 to NEW;
           set newname for datafile 2 to NEW;
           set newname for datafile 3 to NEW;
           set newname for datafile 4 to NEW;
           set newname for datafile 5 to NEW;
           restore database;
           switch datafile all;}
executando comando: SET NEWNAME
....
canal ORA_DISK_1: restaurando o arquivo de dados 00001 em C:\ORACLEXE\APP\ORACLE
\ORADATA\XENEW\XE\DATAFILE\O1_MF_SYSTEM_%U_.DBF
...
canal ORA_DISK_1: restaurando o arquivo de dados 00005 em C:\ORACLEXE\APP\ORACLE
\ORADATA\XENEW\XE\DATAFILE\O1_MF_DADOS_%U_.DBF
....
Finalizado restore em 07/02/12

arquivo de dados 1 alternado para a cópia do arquivo de dados
cópia do arquivo de dados de entrada RECID=6 STAMP=774622994 file name=C:\ORACLE
XE\APP\ORACLE\ORADATA\XENEW\XE\DATAFILE\O1_MF_SYSTEM_7M2H67KV_.DBF
.....
RMAN>

Com estes comandos o Rman criou novos DataFiles dentro do caminho indicado e o comando switch datafile all,  realiza a troca dos nomes antigos pelos novos criados, com isso não será necessário executar o comando ALTER DATABASE RENAME FILE.

Agora basta fazer a recuperação do banco de dados e depois abrir-lo com ResetLog's.

RMAN> recover database;
Iniciando recover em 07/02/12
...
Finalizado recover em 07/02/12

RMAN> sql "alter database open resetlogs";

Pronto, banco de dados disponivel para os usuarios.


                                                           Conciderações

Este artigo é apenas uma parte da vasta opções de Backup e Recover do banco de dados Oracle. Em demais artigos irei mostrar outras opções de Recover, como por exemplo a Recuperação Incompleta e a recuperação em outras maquinas, tanto util para situações de extrema necessidade como simplemente criar um banco de dados de teste.

Backup & Recovery Parte 1 - Configurando o Banco Recuperação

De todas as tarefas que um DBA precisa fazer, o Recover é a principal delas, ao contrario que muita gente pensa ser o Backup. O Backup nada mais do que uma tarefa para se chegar no Recover. Quando um banco de dados falhar, o DBA estará sob enorme pressão para recuperá-lo o mais rapidamente possível, contudo nenhuma DBA sofrerá pressão para fazer Backup. É fundamental estar preparado, não será nada bom ficar procurando as soluções nos manuais antes de tomar as medidas adequadas. Devido a isso a formula é estudar, conhecer o banco de dados e depois: Praticar, praticar e praticar.

Esta série de artigos visa mostrar o processo de Backup e Recover usando o RMAN em backups incrementais. O ambiente mostrado é em Windows com Oracle 10g, mas totalmente adaptável para Linux, com backup’s baseados em discos (levando em consideração do preço dos discos e a capacidade de armazenamento, atende muito bem a muitas empresas), nesta primeira parte será mostrado conceitos básicos e a configuração para preparar o banco para recuperação.

Antes de mostrar como faz backup no Oracle, será apresentado uma compreensão de como funciona o Oracle, e isto é muito importante, pois no momento em que precisar fazer o Recover e as coisas não irem bem, ter o conhecimento de como funciona o mecanismo Oracle irá ajudar e muito neste processo.

SGBD Oracle

O Oracle é composto basicamente por duas partes:

      ·         Instância Oracle
      ·         Banco de Dados Oracle

Instância Oracle

A instância é a estrutura de memória e os processos Oracle que se encontram na memória principal, obviamente uma instância existe quando a maquina está ligada, pois os dados da memória principal são voláteis.

A instância é composta por duas áreas de memória o SGA e o PGA, sendo que o 1º é uma área de memória publica e é dividida em varias outras pequenas áreas como cache de consulta ou estrutura de tabela e pacote para otimização dos processos Oracle, enquanto a segunda é uma área privada onde guarda os valores de variáveis e processos de cada sessão.

Banco de Dados

O Oracle database é composto por três tipos de arquivos que encontra-se no sistema operacional

*ControlFile

*DataFile

*LogRedo

Para saber a localização destes arquivos, basta executarem algumas consultas no dicionário de dados do Oracle.

ControlFile: O ControlFile é um arquivo pequeno, mas muito importante, pois nele contem todas as informações necessária para montar uma instancia Oracle, ou seja nele contem a informação como nome do Banco de dados, os arquivos do banco de dados e qual o valor atual do SCN, além disse as informações do backup estarão nele, e caso este arquivo corrompa é necessário restaurar o banco de dados inteiro, por isso é crucial temos backup dele.

DataFile : O DataFile é onde são armazenados as informações do banco de dados. Tanto os dados dos usuários como os dados interno do Oracle - dicionário de dados - são armazenados nestes arquivos.

RedoLog : Log de redo é um conjunto de arquivos que guardas as últimas operações de um banco de dados Oracle, no mínimo é preciso ter 2 arquivos desse, e as operações ocorrem de modo síncrono, ou seja guarda as informações no 1º arquivo depois no 2º, quando termina o Oracle sobrescreve o 1º arquivo. Quando ocorre algum uma falha, para recuperar a consistência do banco de dados ele usa o Log de Redo. Porém se por algum motivo for preciso restaurar um o algum arquivo ou o mesmo o banco de dados inteiro, será preciso usar os logRedo e/ou os Log que foram sobre-escrito, mas guardo em algum local no disco, o chamado archive, que será explicado mais para frente.

Operação na Database

Toda operação que ocorre no banco de dados, a operação é registrada a nível de instância em uma área da memória chamada Redo Log Buffer e de tempo em tempo o conteúdo deste Buffer é aplicado no arquivo ativo do Redo log. Também quando ocorre um commit o Oracle obrigatoriamente aplica o que está no Buffer no RedoLog.

Isso significa que o Oracle não grava de imediato nos DataFiles as operações do banco. Outro processo que é responsável de transferir o conteúdo do RedoLog para o DataFile. O algoritmo de gravação do Buffer paraRedoLog é extremamente rápido, ao passo que do RedoLog para DataFile é "preguiçoso". Nunca os dados que estão gravados no RedoLog são sobre-escrito antes de serem replicados para os DataFiles e opcionalmente (obrigatoriamente em produção) para algum local no disco - o chamado archive.

Um fato a ser percebido é que a gravação no RedoLog representa um gargalo de desempenho do Oracle, ele é um funil, nunca um commit será mais rápido do que o processo de escrita do Buffer para o RedoLog. E se necessário o banco trava até os processos responsáveis por replicar o conteúdo do RedoLog nos datafiles e arquivar o conteúdo no disco. Este é um ponto a ser avaliado em questão de performance do banco de dados Oracle.

Entendo o que é Backup Oracle

Um banco de dados pode guardar uma enorme quantidade de dados e por isso são feitos backups do banco de dados. Os backups são cópias de segurança, que deverão ser usados caso ocorra alguma falha no software ou hardware que venha a gerar inconsistência da informação.

O SGBD Oracle oferece uma variedade de procedimentos e opções de backup que ajudam a proteger um banco. Quando adequadamente implementada, essas opções permitirão que se faça a recuperação da base de dados.

O Banco de dados Oracle oferece backups lógicos, backups físicos e os backups incrementais. Estes são os tipos de backup que o Oracle faz independente da plataforma (Sistema Operacional) que estiver rodando.

Um backup lógico envolve a leitura de um conjunto de registro do banco de dados e a gravação deste em um arquivo. Este tipo de backup geralmente não é a primeira opção para a restauração de um banco de dado. Contudo é ideal quando se deseja recuperar objeto(s) especifico a nível lógico, como tabelas, views entre outros.

O backup físico envolve a cópia dos arquivos que constituem o banco de dados Oracle. Em geral é a opção mais usada, pois caso ocorra uma falha em apenas um dos arquivos de dados do banco é possível fazer uma restauração e a recuperação apenas deste arquivo, gerando assim menos tempo de indisponibilidade do SGBD. É possível fazer backup's a nível de Sistema Operacional com os comandos cp ou copy, contudo este tipo de backup só é considerado consistente com o banco desligado normalmente. Entretanto o RMAN é a ferramenta mais usada para realizar este tipo de backup, e em conjunto o modo archive é perfeitamente recuperável um banco mesmo tendo backup's inconsistente feito com o banco aberto e disponível para os usuários.

O backup incremental também é um backup físico. Consiste em fazer um backup das transações que ocorreram após o ultimo backup completo, opção disponível quando o banco esta no modo archive que os backups sendo feito pelo Rman.

Protegendo um Banco de Dados Oracle

                                                Multiplexação do ControlFile e LOG de Redo

Como um ControlFile é muito importante a primeira ação a ser feita é a Multiplexação dele. Para isso é preciso desligar o banco de dados.

Multiplexação é a processo de espelhamento, muito usado em disco, o chamado RAID, este processo é feito via hardware, mas neste caso a multiplexação é feito via o software do Oracle e é uma solução para quem não tem como adquirir espelhamento em discos com RAID.

Realize a consulta ”select name from v$controlfile” para saber a localização do ControlFile.

Depois baixe o serviço do Oracle. Logado com SYS execute - shutdown immediate depois faça a copia do arquivo ControlFile.

Feito isso, cola o arquivo em algum diretório, neste exemplo foi criado o diretório “c:\oracle\espelhoControlFile”  e incluir três copias do arquivo. É importante saber que todos os controlfiles devem ter nomes distintos e que o Oracle somente usa um dos arquivos, mas cada alteração feita no controlfile é refletida nos arquivos espelhos. O ideal é que cada copia fique em discos diferentes, mas mesmo que tenha apenas um disco na maquina é aconselhado a criação das copias do controlfile e pelo menos em diretórios diferente como neste exemplo.

É preciso informar ao Oracle a localização dos espelhos do controlFile, para isto acesse  o arquivo de texto INIT.ORA que por padrão fica localizado em “C:\oraclexe\app\oracle\product\10.2.0\server\config\scripts” e alterar o parâmetro Control_file.

Inclua a localização de todos os arquivos, sendo que o 1º e o controlfile que será usado e os demais serão espelhos.

Feito isso inicie o serviço do Oracle indicando o arquivo de parâmetro, para isso execute no SQLPLUS

Startup pfile= C:\oraclexe\app\oracle\product\10.2.0\server\config\scripts\init.ora

Depois disso realize a consulta do controlfile para ver que o banco de dados já tem ciência da copia dos controlfile. Para não precisar subir o banco pelo arquivo init.ora, recrie o SPFILE a partir do pfile.

Se preferir pode alterar o parâmetro pelo SPFILE e depois desligar o banco de dados, copiar os novos controlfile e depois iniciar o banco de dados:

alter system set control_files =
'c:\oraclexe\oradata\XE\control.dbf’,
 'c:\oracle\EspelhoControlFile\control01.ctl',
'c:\oracle\EspelhoControlFile\control02.ctl',
'c:\oracle\EspelhoControlFile\control03.ctl',
 scope = spfile;

 Outro tipo de arquivo que suporta o recurso de multiplexação é o LOG de Redo. Como dito anteriormente o LOG de REDO grava todas as ultimas ações realizada no banco de dados e por isso é importância para recuperação de instância. No mínimo existe dois grupo de LOG de REDO com um membro.

Ao realizar o SQL “select * from v$logfile”, percebe que o Oracle XE vem de fábrica com a configuração mínima, e totalmente insegura, ou seja apenas dois grupos e um arquivo por grupo. Para multiplexar, adicionando membros aos grupos, pasta executar o comando abaixo.

 alter database add logfile member 'C:\ORACLE\ONLINELOG\MEMBRO02.log' to group 1;
 alter database add logfile member 'C:\ORACLE\ONLINELOG\MEMBRO02.log' to group 2;

As mesmas recomendações do controlfile são válidas para o LOG de REDO, se tiver mais de um disco, coloque cada membro em disco separado.

Cada membro serão identicos, assim caso no momento do recover a chance de perder dados minimiza, pois terá vários arquivos que contém as ultimas alteração de dados.

                                                         Trabalhar no Modo Archive

Archive log mode ou Modo de Registro de Arquivamento é um do recurso que cópia o conteúdo do LOG de REDO para outro destino antes deste ser sobrescrito por novas entradas de dados.  Pode-se gravar em até 10 destinos diferente, talvez seja um excesso, mas pelo menos 2 destino um local e outro remoto é primordial para recuperação do banco de dados.

Para conseguir realizar operações fora dos discos locais, é preciso mudar o serviço Oracle no Windows. Por padrão, no Windows o serviço Oracle roda com privilégios de usuário administrador da maquina local, com isso qualquer tentativa de backup e/ou Arquivamento do LOG de REDO fora da maquina local, ocasionará erro de privilégios. Logo, no serviço do Oracle e do Listener altere o Log On de Conta Local para uma conta de Rede.

Feito isso configure o Banco de Dados para modo Achive e dois destinos, um local outro remoto:

1-Conecte com SQL*Plus com usuário SYS com privilegio de SYSDBA.

SQL> connect / as sysdba

2-Sete dois diretório de destino. Note que é necessário incluir uma barra no final do nome do diretório.

           SQL> alter system set log_archive_dest_1='location=C:\bck_oracle\Archive\' scope=spfile;

           SQL> alter system set log_archive_dest_2='location=\\172.16.1.21\particularTI\Alessandro\bck_oracle\ARCH' scope=spfile;

3-Depois desligue, inicie no modo mount, coloque no modo archive e abra o banco.

SQL> shutdown immediate;

SQL> startup mount;
SQL> alter database archivelog;
SQL> alter database open;

Para confirmar que o banco esta no modo ArchiveLog execute as query abaixos:

SQL> select log_mode from v$database;
SQL> select archiver from v$instance;

 Neste momento o Oracle está instruído para nunca sobrescrever os LOG de REDO antes de enviar o conteúdo deste para os dois destinos, isso significa que se o Oracle não conseguir arquivar o LOG de REDO ele irá parar até que resolva o problema que não permite a gravação.

Dois problemas já podem ser mapeados e ajustados aqui para evitá-los. O primeiro consiste em a área de archive encontra-se cheio e o segundo que a rede (ou a maquina remota) encontra-se indisponível.

Para evitar o primeiro problema, é preciso instruir o Oracle que apague os backup’s obsoletos. Para isso logue no rman no prompet de comando:

Rman target sys nocatalog

RMAN> configure retention policy to recovery window of 7 days;

Neste caso o Oracle guardará os backup’s e os archive necessário para restaurar o banco que qualquer tempo dentro da janela de 7 dias. O que não estiver nesta situação e considerado backup obsoleto.

Para evitar o segundo problema execute no SQL PLUS:

   SQL> alter system set log_archive_min_succeed_dest=1 scope=spfile;

 Isso irá instruir o Oracle poder sobrescrever o LOG de REDO caso apenas um destino esteja gravando, neste caso o destino local.

                                                               Conciderações

Nesta primeira parte, foi mostrado para preparar o banco de dados para a recuperação, isto é muito importante, pois em alguns casos, será decisivo se o banco de dados terá ou não recuperação. Com a multiplexção de arquivos importante como o ControlFile e o LogRedo Online, e o o processo archive, que grava em discos todo o conteúdo do  LogRedo Online, antes de sobreescrever a informação, aumenta muito a garantia que não ocorrá perdas de dados.

Na próxima parte, será apresentado a realização de backup's pelo Rman e depois alguns cenários onde será feito a restauração do banco de dados.