Um pouco sobre o Flashback Database 10g/11g ...

Olá,

Para quem já teve a oportunidade de utilizar esta feature disponível desde a versão do Oracle 10g deve percebido o quanto a mesma é incrível. Na minha visão a tecnologia flashback é uma das features mais incríveis e uma das que eu eu mais gosto no Oracle. Nessas últimas semanas tenho trabalhado muito em algumas bases de mais ou menos 1 TB de tamanho realizando flahback database em um ambiente montado para realização de cenários de teste repetidos. Aliás, prefiro criar pontos de restauração garantidos (Guaranted Restore Point) que é uma feature nova no Oracle 10g R2 para não ter que depender do parâmetro DB_FLASHBACK_RETENTION_TARGET (default 24 horas). Houve um dia que uma operação de flashback database demorou cerca de 4 horas para voltar uma base até um ponto específico no tempo dentro da janela flashback. Não foi surpresa pra mim pois nesse meio tempo tinham sido realizadas várias operações DML e DDL como criação de índices, particionamentos de tabelas entre outras operações em muitas tabelas gigantescas. Fico pensando quanto tempo demoraria se tivéssemos que voltar um backup!

Como eu disse anteriormente, o flashback database é muito útil nos casos em que temos vários cenários de testes repetidos. Digamos que você tem uma aplicação que está sendo testada em um ambiente de desenvolvimento. Toda vez que você executa a aplicação, ela executas vários comandos DML e, desta forma, altera vários registros em várias tabelas. Em um determinado momento ao final dos testes, você deseja retornar os dados para os seus valores originais antes da realização do próximo teste. Portanto, o flashback é uma ferramenta excelente para isso.

Bom, diferente de outras tecnologias flashback como a flashback query por exemplo, o flashback database não depende da retenção de blocos no tablespace de UNDO. Quando o flashback database está habilitado ou até mesmo quando não está, mas algum ponto de restauração garantido existe, o Oracle registra informações extras na Flash Recovery Area (no 11g o termo agora é Fast Recovery Area) em arquivos chamados de flashback logs. Os logs de flashback possuem os dados para retornar os blocos até um tempo anterior. O legal do flashback database é que podemos voltar o banco em um determinado tempo no passado e abrir o banco no modo read only para ver se voltou o suficiente. Caso contrário, poderemos avançar no tempo ou retroceder ainda mais quantas vezes forem necessárias antes de abrir o banco com a opção resetlogs. O interessante é que mesmo após abrir o banco com a opção resetlogs, ainda assim poderemos utilizar os pontos de restauração criados e ainda não removidos. A figura abaixo nos dá uma visão geral de algumas das possibilidades dentro de uma janela de tempo em que poderemos atuar:

Vale a pena salientar que pontos de restauração garantidos ficarão eternos até que sejam removidos. Por outro lado, caso um ponto de restauração garantido não seja criado e a Flash Recovery Area precisar de mais espaço para acomodar outros tipos de arquivos, os flashback logs que foram gerados serão removidos para dar espaço a outros tipos de arquivos, como archive logs e arquivos de backup do RMAN. Portanto, seja cuidadoso ao criar um ponto de restauração garantido pois os logs de flashback crescerão até que o mesmo seja removido. Um outro ponto importante a dizer é que para que o flashback seja ativado o banco de dados precisar estar em modo ARCHIVELOG, ou seja, em algum momento os archive logs gerados serão necessários para dar suporte aos flashback logs. Então, não apague nenhum archive log. Me lembro de algumas vezes ter tido que realizar o flashback de dentro do RMAN, pois alguns archive logs necessários para realização do flashback não estavam mais no disco e sim em algum backupset, devido a estratégia de política de backup em vigor.

No mais, neste artigo irei demonstrar como o flashback database reage às alterações de algumas propriedades dos tablespaces e datafiles (create, resize, drop) realizados dentro da janela flashback. Em alguns momentos tive que abrir mão de alguns datafiles no momento da realização do flashback database. Neste caso, é bom termos cuidado pois dependendo da alteração estrutural no nível de datafiles realizada no banco de dados, essa alteração poderá impactar no flashback da base de dados de forma total ou parcial.

Inicialmente irei realizar um teste no Oracle 10g R2 e depois irei realizar um teste no Oracle 11g R2 para demonstrar alguns pontos.

Acima estão listados os tablespaces e seus respectivos datafiles do meu banco de dados. Abaixo irei realizar um shutdown do banco para iniciá-lo em estado MOUNT afim de ativar o modo flashback.

O comando "archive log list" me mostra que o banco já está operando no modo ARCHIVELOG.

Acima verifiquei o destino e o tamanho da Flash Recovery Area. Deixarei de lado o parâmetro DB_FLASHBACK_RETENTION_TARGET na qual o valor default é 24 horas, pois irei criar pontos de restauração garantidos e neste caso este período de retenção será desconsiderado.

Após ativar o flashback database, irei criar a abaixo um ponto de restauração garantido com o nome de "stable".

Pronto. O banco já está com o suporte de flashback ativado e com um ponto de restauração criado. Abaixo irei realizar algumas operações como criar uma tablespace, renomear uma tablespaces, dropar outra, e redimensionar alguns datafiles.

Após realizadas as alterações acima, o layout do meu de banco de dados ficou como demonstrado pelo resultado da query acima. Agora irei realizar o flashback database para o restore point criado anteriormente. Para tanto, será necessário deixar a base no estado MOUNT.

Acima está uma lição a ser aprendida e que está muito bem documentada. Não efetue nenhuma operação de redução de tamanho de datafile enquanto o banco de dados estiver com o flashback ativo. Como demonstrado acima, o datafile 4 pertencente ao tablespace USERS inviabilizou a realização do flashback.

Colocar o datafile 4 em modo off-line não bastou para resolver o problema.



Portanto, terei de abrir mão do datafile 4 executando o comando abaixo.




Agora irei tentar realizar novamente o flashback do banco de dados.

Em relação ao datafile 4 o problema foi resolvido abrindo mão do mesmo, mas agora o Oracle está reclamando do datafile 5 que pertence ao tablespace TBS01 que foi dropado. Bom, uma outra lição aprendida é de que o flashback database não recupera tablespaces e datafiles que foram removidos.

Por fim, poderei realizar o flashback database com sucesso como demonstrado abaixo:

Conclusão:

• A tablespace TBS03 que foi criada após o ponto de restauração foi removida do banco de dados.
• O datafile 3 pertencente ao tablespace SYSAUX que teve o seu tamanho aumentado voltou para o seu tamanho original.
• O datafile 4 pertencente ao tablespace USERS que teve o seu tamanho reduzido permanenceu off-line e portanto foi perdido. Qualquer tentativa de recover do mesmo precisará de um backup de uma incarnação anterior.
• A tablespace TBS02 que foi renomeada para TABLESPACE02 foi desfeita e voltou para o nome original.
• A tablespace TBS01 que foi dropada, não foi recuperada e portanto, o seu datafile foi perdido.

Nos testes que realizei com o Oracle 11g R2, verifiquei que o comando "alter database flashback on" pode ser emito também enquanto o banco de dados está aberto (OPEN) e não mais somente no estado MOUNT. Em relação a operação de redução do tamanho de um datafile, o mesmo inviabilizou o flashback do banco de dados, mas agora não será necessário utilizar a cláusula offline-drop do comando "alter database datafile" como demonstrado abaixo.

Em relação a criação de um ponto de restauração garantido sem o modo de flashback ativado, podemos verificar abaixo que o mesmo é possível nas versões 10g R2 e 11g como demonstrado abaixo:

Os valores possíveis para a coluna FLASHBACK_ON da view V$DATABASE da versão 10g R1 são (YES/NO). Na versão 10g R2 foi incluído o valor "RESTORE POINT ONLY" o que significa que só é possível realizar o flashback do banco de dados para um ponto de restauração.

Acima foi até possível pegar um erro de tradução para o português da mensagem do erro ORA-38726. O certo seria "ORA-38726: Log do banco de dados de flashback não está ativado."

No mais, após remover o ponto de restauração, poderemos perceber que o valor da coluna FLASHBACK_ON da view V$DATABASE terá o seu valor atualizado para "NO".