Flashback table

No dia a dia, estamos sujeitos aos mais variados tipos de erros e falhas, desde falha de aplicação ou mesmo erro humano. Agora imagine a situação na qual alguma destas falhas/erros ocasiona uma alteração incorreta ou mesmo a remoção de dados de alguma tabela.

A partir da versão 10g, a Oracle disponibilizou uma feature chamada flashback table, que permite restaurar tabelas para um ponto anterior no tempo. Essa possibilidade de retorno está diretamente relacionada aos dados de undo do ambiente, uma vez que estes são usados para realizar a restauração da tabela.

É importante destacar também que as operações de flashback table, podem ser utilizadas apenas para recuperações lógicas, não podendo ser utilizado em um banco de dados standby e não permite a restauração de operações DDL (upgrading, moving, or truncating a table; adding a constraint to a table, adding a table to a cluster; modifying or dropping a column; adding, dropping, merging, splitting, coalescing, or truncating a partition or subpartition (with the exception of adding a range partition)). 

Através da utilização deste recurso, é possível restaurar o estado das linhas em uma tabela, a partir de um ponto de tempo passado. Também é possível restaurar os índices, triggers e restrições relacionados a uma tabela com a base no ar, sem impacto para as aplicações correntes.

Além do flashback table, a Oracle fornece outras features de flashback que não serão abordadas neste artigo, sendo elas Oracle Flashback Query, Oracle Flashback Version Query, Flashback Transaction Query, DBMS_FLASHBACK Package,Flashback Transaction, Flashback Data Archive (Oracle Total Recall), Oracle Flashback Drop e Oracle Flashback Database.

• Voltando ao flashback table, vamos a prática:

Para executar um flashback table, o usuário a realizar a operação deve ter o privilégio flashback para a tabela a ser restaurada ou flashback any table, para flashback de qualquer tabela.

Antes de iniciar os exemplos, estarei verificando o timestamp atual, pois o mesmo será utilizado como base para o processo de flashback.

 SQL> show user;
USER is "LAMIM"
SQL> select to_char(SYSTIMESTAMP,'DD/MM/YYYY HH24:MI:SS') FROM DUAL;

TO_CHAR(SYSTIMESTAM
-------------------
30/03/2016 22:07:05

Estarei criando uma tabela flashback_table e populando a mesma com valores de 1 a 30000 para que possamos simular o processo.

 SQL> conn lamim/lamim
Connected.
SQL> CREATE TABLE flashback_table (id NUMBER );

Table created.

SQL> begin
for i in 1..30000
loop
insert into flashback_table values  (i);
end loop;
commit;
end;
/
  2    3    4    5    6    7    8

PL/SQL procedure successfully completed.

Agora vamos listar os ID de valores menor que 10 e depois realizar um delete para simular uma situação na qual os dados são apagados por engano.

SQL> select * from flashback_table where ID<10 order by id asc;

        ID
----------
         1
         2
         3
         4
         5
         6
         7
         8
         9

9 rows selected.

SQL> DELETE flashback_table where ID<10;

9 rows deleted.

SQL> COMMIT;

Commit complete.

SQL> select * from flashback_table where ID<10 order by id asc;

no rows selected

SQL>  select to_char(SYSTIMESTAMP,'DD/MM/YYYY HH24:MI:SS') FROM DUAL;

TO_CHAR(SYSTIMESTAM
-------------------
30/03/2016 22:48:18

Sabendo que a remoção equivocada dos registros ocorreu entre as 22:07 e as 22:48, vamos realizar o processo de flashback table usando este intervalo. Primeiro listarei os dados de flashback e depois irei inseri-los novamente na tabela.

SQL>  select * from flashback_table AS OF TIMESTAMP
 (SYSTIMESTAMP - INTERVAL '10' MINUTE)
 where ID<10 order by id asc;  2    3

        ID
----------
         1
         2
         3
         4
         5
         6
         7
         8
         9

9 rows selected.

SQL> insert into flashback_table
  2  select * from flashback_table AS OF TIMESTAMP
 (SYSTIMESTAMP - INTERVAL '10' MINUTE)
 where ID<10 order by id asc;  3    4

9 rows created.

SQL> commit;

Commit complete.

SQL>
SQL> select * from flashback_table where ID<10 order by id asc;

        ID
----------
         1
         2
         3
         4
         5
         6
         7
         8
         9

9 rows selected.

Pronto, o erro foi revertido rapidamente sem a necessidade de restaurarmos um backup. Isso tudo com o ambiente em produção e sem impactar as demais operações.

Vale ressaltar que o tempo que os dados estarão disponíveis para recuperação dependerão exclusivamente da área de UNDO disponível e a utilização da mesma. É possível usar como parâmetro para restauração tanto o timestamp quando o SCN.

Fonte: https://docs.oracle.com/cd/B28359_01/appdev.111/b28424/adfns_flashback.htm https://docs.oracle.com/cd/B28359_01/backup.111/b28270/rcmflash.htm
http://psoug.org/reference/flash_table.html