Banco de Dados · 29 de julho de 2024 · 11 min de leitura

Recovery Oracle Database

Bem-vindos ao nosso laboratório de recuperação de dados no Banco de Dados Oracle, onde vamos aprender sobre o processo de recuperação em diferentes contextos: Ambiente Standard e Ambiente Enterprise. Neste ambiente de aprendizado, vamos desvendar os passos essenciais para recuperar dados valiosos em cenários desafiadores.

Durante este lab abordaremos cenários como:

1. Recuperação Após Perda Total de Datafiles: Exploraremos como recuperar dados quando todos os arquivos de dados estão perdidos, utilizando estratégias de recuperação.

2.Recuperação de Um Tablespace Específico: Mostraremos como restaurar um tablespace comprometido, destacando as nuances da recuperação.

3.Recuperação Ponto a Ponto: Aprenderemos como atingir um ponto específico no tempo, executando recuperações pontuais.

4.Recuperação Após Falha de Mídia: Abordaremos como lidar com falhas de mídia e como realizar recuperação.

5.Recuperação Após Erro Humano: Discutiremos como reverter alterações indesejadas, com foco na aplicação prática desses procedimentos em ambientes distintos.

Este laboratório é uma oportunidade única para desenvolver uma compreensão clara das diferenças e semelhanças entre a recuperação de dados em ambientes Standard e Enterprise no Banco de Dados Oracle. Ao final, você estará equipado com conhecimentos práticos que permitirão enfrentar com confiança as situações de perda de dados e manter a integridade de seu ambiente de banco de dados, independentemente de sua configuração. Vamos começar a jornada rumo à maestria na recuperação de dados no Oracle!

Requisitos:

  • Oracle linux 7.9
  • Oracle Database 19c Standard Edition
  • Oracle Database 19c Standard Edition

Recuperação Após Perda Total de Datafiles

Neste primeiro caso iremos simular uma perca total de todos Datafiles. Seja em ambienteStandard ou Enterprise, iremos realizar a recuperação da mesma forma.

$ cd /u01/oradata/WINT/
$ rm -rf *.dbf

Passo 1: Avaliação da Situação

  1. Se todos os seus datafiles foram pro espaço, não entre em pânico. Você tem seus backups do RMAN, certo? E os registros de redo log também são seus amigos.
$ su - oracle
$ . ~/.profileWINT
$ tail -200f
$ORACLE_BASE/diag/rdbms/$ORA_DB_UNQ_NAME/$ORACLE_SID/trace/alert_$ORACLE_SID.log

Passo 2: Preparar o Ambiente Para Recuperação

  1. Vamos tentar acessar o rman porem não vamos conseguir, vai ser necessário baixar o banco e tentar montar novamente para listar os backups
  2. Como o banco de dados estava em aberto, vamos precisar encerrar ele para iniciar a recuperação.
  3. Ao tentar baixar o banco vamos observar que vai ser necessário utilizar o comando abort para encerrar a instância.
  4. Agora iremos iniciar o banco em mount para iniciar a recuperação
$ rman target /
$ sqlplus / as sysdba
# shutdown immediate; ( Vai dar erro )
# shutdown abort;
# startup mount;

Passo 3: Listar os backups disponível

  1. Vamos primeiro listar os backups e verificar qual backup está mais recente.
$ rman target /
> list backupset of database;

Passo 4: Restauração do banco de dados

  1. Agora chegou a hora de restaurar os datafiles a partir do backup mais recente.
> restore database;

Passo 5: Recuperação do banco de dados

  1. Depois de restaurar os datafiles, você precisa recuperar o banco de dados para deixá-lo consistente. O RMAN vai aplicar os registros de redo log nos datafiles
    restaurados.
  2. Após a recuperação, o banco de dados estará em modo de recuperação.
> recover database;
> alter database open;

Finalizado! Independentemente de estar no Oracle Standard ou Enterprise, o processo é bastante similar.

Recuperação de Um Tablespace Específico

Agora iremos simular a perca de um datafile de alguma tablespace. Neste caso iremos deletar um datafile da TS_DADOS e iremos recuperar ele.

$ cd /u01/oradata/WINT/
$ rm -rf ts_dados01.dbf

Passo 1: Identificação do Problema

  1. Identificamos pelo alert.log que após tentativa de utilizar o banco ele mostra que não encontrou o datafile 4 no diretório.
  2. No rman podemos realizar uma validação para identificar também o problema
$ su - oracle
$ . ~/.profileORCL
$ tail -200f
$ORACLE_BASE/diag/rdbms/$ORA_DB_UNQ_NAME/$ORACLE_SID/trace/alert_$ORACLE_SID.log
$ rman target /
> validate database:

Passo 2: Localizando a Peça de Backup

  1. Agora iremos verificar quais backups de datafile estão disponíveis.
> list backup of datafile 4;

Passo 3: Restauração do Datafile

  1. Para iniciar a restauração do datafile, primeiro iremos deixar ele em OFFLINE.
  2. Agora podemos restaurar o datafile afetado
> alter database datafile 4 offline;
> restore datafile 4;

Passo 6: Recuperação do Datafile

  1. Após a restauração, você precisa recuperar o datafile para deixá-lo consistente. Então vamos realizar a recuperação.
  2. Quando a recuperação estiver completa, você pode abrir o datafile para que os usuários possam acessar os dados novamente.
> recover datafile 4;
> alter database datafile 4 online;

Finalizado! Independentemente de estar no Oracle Standard ou Enterprise, o processo também é bastante similar.

Recuperação Ponto a Ponto

Agora iremos simular uma alteração indevida em alguma tabela, e iremos realizar uma recuperação desse banco de dados para um ponto específico no tempo, utilizando backups incrementais e logs de redo.

$ su - oracle
$ . ~/.profileWINT
$ sqlplus / as sysdba
# UPDATE ORACLE.CLIENTE SET NOME = 'MURILO';
# COMMIT;

Passo 1: Identificação do Momento Específico

Antes de começar, identifique o momento específico no tempo para o qual deseja recuperar o banco de dados.

# SELECT SEQUENCE#, FIRST_TIME
FROM V$ARCHIVED_LOG
WHERE APPLIED = 'NO';

Passo 2: Restauração e Recuperação

  1. No RMAN, baixe o banco de dados e depois coloque o mesmo em mount.
  2. Agora inicie o processo de recuperação.
# shutdown immediate;
# startup mount;
$ rman target /

Opção 1: utilizar a sequência para recuperar

RUN {
SET UNTIL SEQUENCE=34;
RESTORE DATABASE;
RECOVER DATABASE;
}

Opção 2: utilizar o dia e hora para recuperar

RUN {
SET UNTIL TIME="TO_DATE('03/09/2023 20:00:00','DD/MM/YYYY HH24:MI:SS')";
RESTORE DATABASE;
RECOVER DATABASE;
}

Passo 3: Abrindo o Banco de Dados

  1. Quando a recuperação estiver completa, você pode abrir o banco de dados para que os usuários possam acessar os dados recuperados.
  2. Ao tentar abrir o banco normalmente, podemos verificar que vai dar erro e será necessário iniciar uma nova encarnação.
  3. Também podemos validar;
> alter database open; ( Vai dar erro )
> alter database open resetlogs;
$ sqlplus / as sysdba
$ select * from oracle.cliente;

Recuperação finalizada!

Recuperação Após Falha de Mídia

Agora iremos simular a perca de dois arquivos após uma falha na mídia. Vamos simular a perca do spfile e controlfile.

$ cd /u01/app/oracle/19.3.0.0/db_1/dbs/
$ rm -rf initWINT.ora spfileWINT.ora
# rm -rf /u01/oradata/WINT/control01.ctl
# rm -rf /u01/app/oracle/fast_recovery_area/WINT/control02.ctl

Passo 1: Identificando o problema

  1. Verificamos no alertlog que os erros apresentados, no primeiro momento podemos ver que ele alertou somente sobre a falta do controlfile.
$ su - oracle
$ . ~/.profileWINT
$ tail -200f
$ORACLE_BASE/diag/rdbms/$ORA_DB_UNQ_NAME/$ORACLE_SID/trace/alert_$ORACLE_SID.log

Passo 2: Preparação para restauração

  1. Como não vamos conseguir baixar a instância normalmente, vamos precisar executar o comando “Shutdown Abort” para poder iniciar a restauração
  2. Para iniciar a restauração do Control file é necessário deixar o banco de dados em Nomount, pois para montar o banco o Control file é necessário.
  3. Ao tentar deixar o banco de dados em Nomount, ele nos da o erro de que também não tem o Spfile.
$ sqlplus / as sysdba
$ shutdown immediate; ( Vai dar erro )
$ shutdown abort;
$ startup nomount;

Passo 3: Restauração spfile

  1. Para deixar o banco em Nomount primeiro vamos resolver o erro sobre o Spfile.
  2. Para recuperar o spfile, nos podemos ir no alert.log da instância para verificar os parâmetros necessários para criar um pfile. Esses parâmetros foram gravados
    quando o banco foi iniciado anteriormente.
  3. Agora que pegamos os parâmetros, iremos criar o Pfile com os parâmetros que copiamos no alert.log e iremos colocar o banco em Nomount com o Pfile criado.
$ vim $ORACLE_BASE/diag/rdbms/$ORA_DB_UNQ_NAME/$ORACLE_SID/trace/alert_$ORACLE_SID.log
$ vim /u01/app/oracle/19.3.0.0/db_1/dbs/initWINT.ora
# sqlplus / as sysdba
# startup nomount pfile='/u01/app/oracle/19.3.0.0/db_1/dbs/initWINT.ora';

Passo 4: Restauração Control file

  1. Pronto, com o banco em Nomount já podemos restaurar o Control file pelo backup e criar o Spfile.

Passo 5: Finalizando recuperação.

  1. Após realizar o restauração do Control file é necessário realizar a recuperação para atualizar o Control file
  2. Ao tentar deixar o banco de dados em open vamos verificar que é necessário iniciar uma nova encarnação após perca do Control file.
> recover database;
> alter database open; ( Vai dar erro )
> alter database open resetlogs;
Obs: Como é iniciado uma nova encarnação é importante realizar um novo backup físico full.

Recuperação finalizada!

Recuperação Após Erro Humano

Agora iremos simular erros humanos no banco de dados e iremos realizar a recuperação.
Neste passo iremos fazer um Drop e realizar alguns Update e depois iremos recuperar utilizando backups lógicos e a função flashback.

CASO 1 – Neste caso iremos realizar um drop na tabela e iremos recuperar pelo backup lógico realizado.

$ su – oracle
$ . ~/.profileORCL
$ sqlplus / as sysdba
# DROP TABLE ORACLE.PRODUTO;

OPÇÃO 1 – IMPDP

Passo 1: Identificar a tabela Localizar o backup

  1. Após saber qual tabela iremos realizar a recuperação, agora iremos analisar o backup logico.
  2. Verificamos que foi feito o backup logico, agora iremos descompactar o arquivo para iniciar a importação do backup
$ cd /u02/oradata/ORCL/export/
$ rar e EXPDP_ORCL_FULL_28082023-12h.rar

Passo 2: Realizar importação da tabela

  1. Agora que descompactamos o backup iremos realizar a importação do dump. Para realizar a importação somente de uma tabela iremos utilizar o parâmetro “TABLES” iniciando com o nome do schema.
  2. Após importação esta produto a recuperação da tabela.
$ impdp system/oracle DUMPFILE=EXPDP_ORCL_FULL_28082023-12h.dmp
LOGFILE=IMPDP_TABELA_03092023.LOG TABLES=ORACLE.PRODUTO DIRECTORY=EXPORT_DIR

**CASO 2 – Neste caso iremos realizar um UPDATE na tabela sem utilizar a clausula
**
WHERE iremos recuperar pela cláusula FLASHBACK QUERY usando o operador AS OF TIMESTAMP ou AS OF SCN

$ su - oracle
$ sqlplus / as sysdba
# UPDATE ORACLE.PRODUTO SET DESCRICAO='TOMADA';
# COMMIT;
# SELECT * FROM ORACLE.PRODUTO;
## UPDATE ORACLE.PRODUTO T1 SET T1.DESCRICAO=(SELECT T2.DESCRICAO FROM
ORACLE.PRODUTO_BACKUP T2 WHERE T1.CODPROD=T2.CODPROD);

Passo 1: Identificar o tempo para recuperação

  1. Usuário realizou a alteração na tabela tem pouco tempo e precisamos recuperar essas informações que foram atualizadas indevidamente.
  2. Para realizar recuperação por SCN precisamos consultar a sequence que está atualmente com esse select abaixo.
# SELECT ORA_ROWSCN, CODPROD, DESCRICAO, MARCAPROD FROM ORACLE.PRODUTO;

Passo 2: Iniciando recuperação dos dados

Opção 1 ‘AS OF TIMESTAMP’

# CREATE TABLE ORACLE.PRODUTO_BACKUP AS
SELECT * FROM ORACLE.PRODUTO
AS OF TIMESTAMP (SYSTIMESTAMP - INTERVAL '10' MINUTE);

Opção 2 ‘AS OF SCN’

# CREATE TABLE ORACLE.PRODUTO_BACKUP AS
SELECT * FROM ORACLE.PRODUTO
AS OF SCN 1730589;

CASO 3 – Neste caso iremos realizar recuperação da tabela utilizando uma configuração de FLASHBACK que só pode ser ativada na versão Enterprise.

Requisitos :

  • Versão Enteprise
  • **Fashback_on ativado
    **
$ su - oracle
$ .~/.profileWINT
$ sqlplus / as sysdba
# ALTER DATABASE FLASHBACK ON;
# ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET = 4320 SCOPE=BOTH;
# SELECT FLASHBACK_ON FROM V$DATABASE;
# UPDATE ORACLE.CLIENTE SET NOME='Carolina Almeida' WHERE CODCLI=60;
# COMMIT;

Passo 1: Identificando o ponto para recuperação

3. Vamos identificar qual ponto vamos realizar a recuperação pelo Select.

# COLUMN VERSIONS_STARTSCN FORMAT 99999999999999999
# COLUMN VERSIONS_STARTTIME FORMAT A24
# COLUMN VERSIONS_ENDSCN FORMAT 99999999999999999
# COLUMN VERSIONS_ENDTIME FORMAT A24
# COLUMN VERSIONS_XID FORMAT A16
# COLUMN VERSIONS_OPERATION FORMAT A1
# COLUMN NOME FORMAT A24
# SET LINESIZE 200
# SELECT VERSIONS_STARTSCN, VERSIONS_STARTTIME,
VERSIONS_ENDSCN, VERSIONS_ENDTIME,
VERSIONS_XID, VERSIONS_OPERATION,
NOME
FROM ORACLE.CLIENTE
VERSIONS BETWEEN TIMESTAMP TO_TIMESTAMP('2023-08-28 15:05:08', 'YYYY-MM-DD
HH24:MI:SS')
AND TO_TIMESTAMP('2023-08-28 15:15:34', 'YYYY-MM-DD HH24:MI:SS')
WHERE CODCLI=60;

Passo 2: Agora que identificamos o ponto que foi feito alteração na tabela iremos realizar a recuperação dos dados.

# CREATE TABLE ORACLE.CLIENTE_BACKUP AS
SELECT *
FROM ORACLE.CLIENTE
AS OF SCN 1482822;
# UPDATE ORACLE.CLIENTE T1 SET T1.NOME=(SELECT T2.NOME FROM ORACLE.CLIENTE_BACKUP T2
WHERE T2.CODCLI=60) WHERE T1.CODCLI=60;

A diferença do parâmetro flashback_on estar ativo significa que teremos um tempo maior de “retenção” das informações que foram alteradas para realizar a recuperação delas. Os comandos executados para recuperação também são possíveis realizar em ambiente standard, porém com um período menor de retenção dessas informações.

Atualizado em 6 de agosto de 2024.

Esse problema aparece no seu ambiente?

Diagnóstico gratuito de infraestrutura e banco de dados — sem compromisso.

Falar com um especialista