Para melhor visualização, recomendo resolução de no mínimo 1280 x 800 e navegador Mozilla Firefox


domingo, 4 de setembro de 2011

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

Por Eduardo Legatti

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






11 comentários:

Flávio Soares disse...

Muito bom o artigo Eduardo sobre FlashBack.

Realmente é uma feature poderosissima se bem utilizada !

Parabéns

Até mais

Juliano disse...

Eduardo, parabéns pelo artigo porem estou com algumas duvidas:

1) se estiver criado um ponto de restauração NÃO garantido e a geração de archive for muito alta, se estiver utilizando a flash recovery area, os logs de flashback serão sobrescritos, certo - Existe alguma forma de monitorar esse crescimento para evitar que os logs de flashback não sejam apagados ? Retirar o "archive destination" do flash recovery area seria uma opção ?
2) se estiver criado um ponto de restauracao garantido, os logs de flashback não serão sobregravados pelo archives, arquivos de backup … etc se necessário ?

Obrigado e não sei se fui claro nas minhas perguntas/duvidas,

Juliano

Eduardo Legatti disse...

Olá Juliano,

Com pontos de restauração "não garantidos", realmente você poderá correr este risco. O ideal é ter uma FRA grande o suficiente para armazenar os archives, os backups RMAN e os flashback logs. Sempre monitore a FRA utilizando as views
V$RECOVERY_FILE_DEST e V$FLASH_RECOVERY_AREA_USAGE conforme exemplos na documentação oficial. http://docs.oracle.com/cd/B19306_01/backup.102/b14192/setup005.htm#BABFCJAC

Se você quer utilizar a FRA apenas para armazenar os flashback logs, então alterar o "archive destination" da Flash Recovery Area poderia ser uma opção, mas não veria grandes vantagens nisso. Se você quiser realmente garantir a existência dos flashback logs, então crie pontos de restauração "garantidos". Apenas lembre-se de apagá-los quando não forem mais necessários.

Em relação à sua segunda questão, é isso mesmo. Se você tiver criado um ponto de restauração garantido, os logs de flashback não serão sobregravados pelo archives, arquivos de backup, etc... mas se a FRA encher, seu banco de dados poderá travar na falta de espaço dentro da FRA.

Abraços e até mais...

Perigo eminente disse...

Parabéns, realmente muito bem explicado. Mas poderia me tirar esta dúvida. Caso o flashback esteja off, algum ponto de restauração é criado?

Eduardo Legatti disse...

Olá,

Se o flashback database estiver desabilitado, ainda sim será possível criar pontos de restauração. No entanto, somente será possível realizar o flashback database utilizando o ponto de restauração:

flashback database to restore point ...

não será possível utiliza janela de tempo:

flashback database to timestamp to_timestamp ...

Abraços e até mais

Legatti

Fernando disse...

Olá Eduardo, ótima matéria. Minha dúvida é a seguinte: Se eu ativei o flashback database como ON e criei um ponto de restauração garantido, caso eu precise adicionar um novo datafile em alguma tablespace, isto pode invalidar o processo de restauração pelo flashback, caso eu precise.
Abs.

Eduardo Legatti disse...

Olá Fernando,

O flashback database irá funcionar sem problemas ocasionando a deleção do datafile criado.

SQL> create restore point teste guarantee flashback database;

Restaure o ponto criado.

SQL> drop table scott.t1 purge;

Tabela eliminada.

SQL> select file_name from dba_data_files where tablespace_name='USERS';

FILE_NAME
----------------------------------
E:\ORACLE\ORADATA\BD02\USERS01.DBF

SQL> alter tablespace users add datafile 'E:\ORACLE\ORADATA\BD02\USERS02.DBF' size 10M;

Tablespace alterado.

SQL> select file_name from dba_data_files where tablespace_name='USERS';

FILE_NAME
----------------------------------
E:\ORACLE\ORADATA\BD02\USERS01.DBF
E:\ORACLE\ORADATA\BD02\USERS02.DBF

SQL> shutdown immediate
Banco de dados fechado.
Banco de dados desmontado.
Instância ORACLE desativada.

SQL> startup mount
Instância ORACLE iniciada.

Total System Global Area 242716672 bytes
Fixed Size 1373824 bytes
Variable Size 142608768 bytes
Database Buffers 96468992 bytes
Redo Buffers 2265088 bytes
Banco de dados montado.

SQL> flashback database to restore point teste;

Flashback concluído.

SQL> alter database open resetlogs;

Banco de dados alterado.

SQL> select * from scott.t1;

não há linhas selecionadas

SQL> select file_name from dba_data_files where tablespace_name='USERS';

FILE_NAME
----------------------------------
E:\ORACLE\ORADATA\BD02\USERS01.DBF

Abraços,

Legatti

Anônimo disse...

Olá, Eduardo
Utilizo constantemente flashback database tenho um total de 7 bancos rodando em oracle 11g em cluster recebi a mais 200GB para minha FRA porém não posso dividir esse tamanho igualmente para os bancos, pois um é maior que o outro mais usado também.Como posso conseguir um valor aproximado para distribuir esse espaço? observando total de archives,flashbacklogs e backupsets seria isso?

Eduardo Legatti disse...

Olá Anônimo,

São 7 bancos distintos com uso variável. Acho que não existe uma fórmula para calcular isso. Cada banco irá gerar os flashback logs de acordo com a carga de trabalho atual. Como você disse, uma opção é monitorar a FRA através da view V$FLASH_RECOVERY_AREA_USAGE e ir analisando o espaço utilizado para cada tipo de arquivo. Enfim, sempre monitore a FRA utilizando as views V$RECOVERY_FILE_DEST e V$FLASH_RECOVERY_AREA_USAGE.

Abraços e até mais...

Legatti

Unknown disse...

Boa tarde, excelente didática, agora uma dúvida, quando emito o comando alter database resetlogs, mando limpar os redos correto, si dará uma nova incarnação do banco?
Desde já agradeço!!!!

Eduardo Legatti disse...

Olá Rodrigo,

Exatamente. Uma nova incarnação será criada.

Abraços,

Legatti

Postagens populares