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.
