Utilizando o processo Flashback Data Archive

Neste artigo, conheceremos o funcionamento do Flashback Data Archive, que é uma feature do Oracle Database 11g. Ele é também uma estrutura lógica para o armazenamento de informações históricas para uma ou mais tabelas e, em seguida, 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 definida 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 esteja no buffer cache, então ele o lê nos segmentos de UNDO. Depois disso ele consolida as 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.

Os índices originais das tabelas não são mantidos no flashback data archive, pois partimos da premissa de que o dado que será recuperado vai ser utilizado para propósitos diferentes do dado atual da tabela. Para suprir essa demanda, é possível criar índices específicos para a tabela que está no modo Flashback Data Archive.

O uso

Uma das situações mais críticas pelas quais passei foi quando tive que retornar o dado que tinha acabado de atualizar. O analista me mandou um script com uma correção; eu executei e depois da execução ele percebeu o erro. A solução 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 ela é cíclica. E isso significa que o dado pode ser reescrito.

Outra técnica que pode ser utilizada é a configuração do banco em Flashback (presente na versão 10g). Porém, as duas técnicas apresentam limitação, já que a retenção do dado está limitada em relação à atividade do banco e à configuração do tempo de retenção. E 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 até mesmo anos e nos preocuparmos somente com espaço. Fazendo uma definição bem pobre, podemos dizer que o Flashback da Archive é a nossa UNDO sem a expiração em horas.

Pré-requisitos

  • Gerenciamento automático da UNDO: Init parameter UNDO_MANAGEMENT= ‘AUTO ‘;
  • Grant Flashback Archive Administer para o usuário que administra o Flashback Data Archive;
  • O banco não precisa estar em archive log mode;
  • Uma tablespace normal separada para o flashback data archive.

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;
/

Neste artigo, conheceremos o funcionamento do Flashback Data Archive, que é uma feature do Oracle Database 11g. Ele é também uma estrutura lógica para o armazenamento de informações históricas para uma ou mais tabelas e, em seguida, 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 definida 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 esteja no buffer cache, então ele o lê nos segmentos de UNDO. Depois disso ele consolida as 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.

Os índices originais das tabelas não são mantidos no flashback data archive, pois partimos da premissa de que o dado que será recuperado vai ser utilizado para propósitos diferentes do dado atual da tabela. Para suprir essa demanda, é possível criar índices específicos para a tabela que está no modo Flashback Data Archive.

O uso

Uma das situações mais críticas pelas quais passei foi quando tive que retornar o dado que tinha acabado de atualizar. O analista me mandou um script com uma correção; eu executei e depois da execução ele percebeu o erro. A solução 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 ela é cíclica. E isso significa que o dado pode ser reescrito.

Outra técnica que pode ser utilizada é a configuração do banco em Flashback (presente na versão 10g). Porém, as duas técnicas apresentam limitação, já que a retenção do dado está limitada em relação à atividade do banco e à configuração do tempo de retenção. E 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 até mesmo anos e nos preocuparmos somente com espaço. Fazendo uma definição bem pobre, podemos dizer que o Flashback da Archive é a nossa UNDO sem a expiração em horas.

Pré-requisitos

Gerenciamento automático da UNDO: Init parameter UNDO_MANAGEMENT= ‘AUTO ‘;

Grant Flashback Archive Administer para o usuário que administra o Flashback Data Archive;

O banco não precisa estar em archive log mode;

Uma tablespace normal separada para o flashback data archive.

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;

/

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 às 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

SQL> update tb_pedidos set qtde=36 where id=27;

1 row updated.

SQL> commit;

Commit complete.

SQL> select * from tb_pedidos where id=27;

        ID    CLIENTE    PRODUTO       QTDE HORARIO
---------- ---------- ---------- ---------- ---------
        27       1234        900         36 19-OCT-11

Vejam que o valor foi alterado para 36. Com a tabela alterada, depois das 19:32:37, vamos descobrir agora 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:32:37, era 10. Com essa informação posso reconstruir o dado.

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 seu espaço:
  • SQL> alter flashback archive flashvendas modify tablespace tbsd_flash_archive quota 800m
  • Podemos expurgar os seus dados:
  • SQL> alter flashback archive flashvendas purge before timestamp(systimestamp – interval ’10 ‘ day)

Podemos dropá-lo:

  • SQL> alter table tb_pedidos no flashback archive
  • SQL> drop flashback archive flashvendas

Restrições

Uma tabela onde o Flashback Data Archive está ativado não pode sofrer:

  • Adição de partições, subpartições e movimentação;
  • Conversão de colunas do tip LONG para LOB;
  • Drop table;
  • Incluir cláusula UPGRADE TABLE com, ou sem a cláusula INCLUDING DATA.

Transparent schema evolution

O Flashback Data Archive suporta na release 11gR2:

  • Drop de colunas e partiçõ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

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 deste 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.

Referências Bibliográ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 aqui. Acesso em: 19 out. 2011.

Fonte: João Paulo Spaulonci/IMasters

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *