quarta-feira, 21 de novembro de 2012

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.