Flashback Data Archive

Saudações pessoal, nesse artigo conheceremos o funcionamento do Flashback Data Archive, que é uma feature do Oracle Database 11g

I – Introdução

O Flashback Data Archive é uma estrutura lógica para o armazenamento de informações históricas para uma ou mais tabelas, e armazenar esse histórico em uma ou mais tablespaces. As informações nas tabelas serão retidas de acordo com uma política de retenção definifida no Flashback Data Archive. Quem realiza essa tarefa é novo processo background FBDA que, trabalha lendo o dado de undo no buffer cache, caso o dado de undo não estiver no buffer cache, então ele lê os dados de undo nos segmentos de undo, depois disso ele consolida das linhas necessárias e escreve no flashback data archive.  
Supondo que o período de retenção seja de 10 dias, toda a informação depois do décimo dia, será deletada do flashback data archive.
Os indices originais das tabelas não são mantidos no flashback data archive, pois partimos da premissa, que o dado que será recuperado do flashback data archive, será utilizado para propósitos diferentes do dado atual da tabela. Para suprir essa demanda é possível criar indices específicos para a tabela que está no modo flashback data archive.

II – O uso
Uma das situações mais críticas que passei, foi quando tive que retornar o dado que eu tinha acabado de atualizar. O analista me mandou um script com uma correção, eu executei , depois da execução ele percebeu o erro. A alternativa foi ler os dados que ainda estavam na retenção da UNDO. Essa técnica de leitura dos segmentos de UNDO é aplicável quando o erro é percebido rapidamente, pois a UNDO é ciclíca, logo, o dado pode ser reescrito. Outra técnica que pode ser utilizada é, configuração do banco em flashback (presente na versão 10g). Porem as duas técnicas apresentam limitação, pois a retenção do dado está limitado em relação a atividade do banco e a configuração do tempo de retenção. Quem tem uma UNDO retention de 5 anos ? Com o flashback data archive podemos alterar esse comportamento. Nele, podemos definir um período de retenção em dias, meses ou anos, e nos preocuparmos somente com espaço. Fazendo uma definição bem pobre, podemos dizer que o flashback da archive é nossa UNDO
sem a expiração em horas. Quer dizer que o dado nunca expira ? – Sim, ele nunca expira, antes da retenção definida no flashback data archive.

III – Pré requisitos
– Gerenciamento automático de undo : Init parameter UNDO_MANAGEMENT=’AUTO’
– Grant “flashback archive administer” para o usuário que estiver administrando o flashback data archive
– O banco não precisa estar em archive log mode
– Uma tablespace normal separada para o flashback data archive

IV – Construindo o ambiente
SQL> conn sys as sysdba
SQL> create tablespace tbsd_vendas datafile ‘+dg1’ size 1g;
SQL> create tablespace tbsd_flash_archive datafile ‘+dg1’ size 1g;
SQL> create user vendas identified by a default tablespace tbsd_vendas;
SQL> grant unlimited tablespace to vendas;
SQL> grant resource to vendas;
SQL> grant create sequence to vendas;
SQL> grant flashback archive administer to vendas;
SQL> grant create session to vendas;
SQL> conn vendas/a
SQL> create flashback archive flashvendas tablespace tbsd_flash_archive quota 500m retention 1 year;
SQL> create sequence seq_pedidos start with 1 increment by 1 nocache;
SQL> create table tb_pedidos (
   id number(5)
   ,cliente number(19)
   ,produto number(10)
   ,qtde number(5)
   ,horario date) tablespace tbsd_vendas;
SQL> alter table tb_pedidos flashback archive flashvendas;
SQL> begin
for r in 0..100 loop
insert into tb_pedidos values (seq_pedidos.nextval,1234,900,10,sysdate);
end loop;
commit;
end;
/

V – O caso
Vamos simular a necessidade de encontrar o valor, referente ao campo qtde, da tabela tb_pedidos referente ao id 27, no dia
19/10/2011 as 19:32:37.
Para isso iremos realizar um update alterando o seu valor de 10 para 36.

SQL> select to_char(sysdate,’dd/mm/yyyy hh24:mi:ss’) as horario from dual;
HORARIO
——————-
19/10/2011 19:32:37

SQL> select * from tb_pedidos where id=27;
        ID    CLIENTE    PRODUTO       QTDE        HORARIO
        27       1234        900                      10           19-OCT-11

Vejam, o valor foi alterado para 36

– Tabela alterada, depois das 19:32:37, agora vamos descobrir o seu valor no horário 19:32:37
SQL> select * from tb_pedidos as of timestamp to_timestamp(’19/10/2011 19:32:37′,’dd/mm/yyyy hh24:mi:ss’) where id=27;
        ID    CLIENTE    PRODUTO       QTDE     HORARIO
        27       1234        900                       10        19-OCT-11

Pronto, o valor do campo qtde para o id 27 no horário 19/10/2011 19:32:37 era 10. Com essa informação posso reconstruir o dado.

VI – Gerenciando o flashback data archive.
– Podemos alterar a retenção do flashback data archive
SQL> alter flashback archive flashvendas modify retention 3 year;

– Podemos aumentar o espaço do flashback data archive
SQL> alter flashback archive flashvendas modify tablespace tbsd_flash_archive quota 800m;

– Podemos expurgar dados do flashback data archive
SQL> alter flashback archive flashvendas purge before timestamp(systimestamp – interval ’10’ day);

– Podemos dropar o flashback data archive.
SQL> alter table tb_pedidos no flashback archive;
SQL> drop flashback archive flashvendas;

VII – Restrições
Uma tabela onde o flashback data archive está ativado não pode sofrer:
– Adição de partições , subpartições ou movimentação
– Conversão de colunas do tip LONG para LOB
– Drop table
– Incluir clausula UPGRADE TABLE com ou sem a clausula INCLUDING DATA

VIII – Transparent schema evolution

O Flashback data archive suporta na release 11gR2:
– Drop de colunas e particões
– Modificação e renomeação de colunas
– Renomeação de tabelas
– Truncate de tabelas e partições.

O Flashback data archive suporta na release 11gR1:
– Adição de colunas

IX – Conclusão
Recomendo a aplicação desse recurso para as tabelas mais críticas do negócio. Mesmo tendo algumas restrições, ainda temos considerável grau de flexibilidade na manutenção de tabelas em modo flashback data archive. Reforço que, somente a leitura desse artigo não é o suficiente para uma implementação em produção, recomendo a leitura de material adicional e a máxima de sempre, para implementação em qualquer ambiente de produção, sempre, desenvolver, testar, homologar e depois implementar.

X – Referências Bibligráficas

ORACLE University. Oracle Database 11g New Features for Administrators: 19-Flashback Technology, Log Miner, and Data Pump Enhacements. California USA. 2.1 ed. Setembro 2010. v.II, p.212-230
Disponível em http://kamranagayev.com/2010/07/21/oracle-flashback-data-archive-total-recall/. Acesso em: 19 out. 2011.

Um forte abraço e até a próxima.

Anúncios
Comente ou deixe um trackback: URL do Trackback.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s

%d blogueiros gostam disto: