Skip to Main Content
  • Questions
  • Flashback Data Archive Limitation -- Please clarify

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Srikanth.

Asked: November 10, 2016 - 2:05 pm UTC

Last updated: October 30, 2017 - 2:38 am UTC

Version: 11.2.0.4.0 - 64bit

Viewed 10K+ times! This question is

You Asked

Hi Tom,

I have observed a limitation with Flashback Data Archive. Once Flashback Data Archive is disabled for a table, all the information in History table until that point is lost. Once Flashback Data Archive is enabled again for the same table, we get data from that point which means only incremental data is available.

Am I right? Does historical data is lost once we disable Flashback Data Archive (alter table <table_name> no flashback archive)? Here is one sample example :

create table test100(id number);

alter table test100 flashback archive TESTFDA2;
alter table test100 succeeded.

insert into test100 values (100);
update test100 set id = 1000;
commit;
select * from TEST;
ID
1000

select * from user_flashback_archive_tables where table_name = 'test100';
TABLE_NAME OWNER_NAME FLASHBACK_ARCHIVE_NAME ARCHIVE_TABLE_NAME STATUS
TEST100 TESTUSER2 TESTFDA2 SYS_FBA_HIST_167611 ENABLED

When I try to query the history table, I am getting output as below :
select * from sys_fba_hist_167611;
RID STARTSCN ENDSCN XID OPERATION ID
AAAo67AAQAAACXrAAA 137935804 137936204 00050018000249E4 I 100

I am able to query versions
select * from test100 versions between scn minvalue and maxvalue;
ID
1000
100

Until this everything is fine. Atleast I am able to query history table. But once I disable and enable again the problem comes.

alter table test100 no flashback archive;
alter table test100 succeeded.

select * from user_flashback_archive_tables where table_name = 'test100';
no rows selected (as FDA is disabled).

Now I am trying to enable again.

alter table test100 flashback archive TESTFDA2;
alter table test100 succeeded.

select * from user_flashback_archive_tables where table_name = 'test100';
TABLE_NAME OWNER_NAME FLASHBACK_ARCHIVE_NAME ARCHIVE_TABLE_NAME STATUS
TEST100 TESTUSER2 TESTFDA2 SYS_FBA_HIST_167611 ENABLED

When I try to query the history table, I am getting output as below :
select * from sys_fba_hist_167611;
ORA-00942: table or view does not exist
00942. 00000 - "table or view does not exist"
*Cause:
*Action:
Error at Line: 17 Column: 14

Here I am not able to query at all. Because History table is not present in database.

Still I am able to query versions even though history table is not existing.
select * from test100 versions between scn minvalue and maxvalue;
ID
1000
100

The history table is showing in the above view, but not actually existing. It is coming into picture only when I perform any DML operations again. But it is not storing the previous data i.e. before disabling.

For eg, delete from test100;
1 rows deleted

commit;
commited

Now, I am able to query history table.

select * from sys_fba_hist_167611;
RID STARTSCN ENDSCN XID OPERATION ID
AAAo67AAQAAACXrAAA 137940222 137940222 00050008000249E7 D 1000
AAAo67AAQAAACXrAAA (null) 137940222 (null) (null) 1000

Finally when I try to query versions,
select * from test100 versions between scn minvalue and maxvalue;
ID
1000
1000

My questions are:
--> From above test case it is evident that upon disabling Flashback data archive, history is being lost. After enabling FDA again, history table is getting created but with new data. There may be situations in which Flashback data archive needs to be disabled and re enabled. Business cutover may take place in normal business days which means that concerned team need to extract data from table before disabling FDA. They may not be available all the time when needed, which may create data loss. Is there any way to overcome this?
--> After disabling FDA, history table is lost. Even after enabling FDA, history table is not created until fresh DML operations are performed. So how can I get data through versions query? Is it referring Undo table? Also please note that last versions query's output is different.

Please clarify on this.

Thanks,
Srikanth

and Chris said...

Your analysis is correct. Once you disable flashback archive for a table, the history tables are gone.

Flashback queries will still work against the table though! As you suspect, this uses undo to do the flashback.

You can temporarily suspend flashback on a table. Use the DBMS_FLASHBACK_ARCHIVE.DISASSOCIATE_FBA and DBMS_FLASHBACK_ARCHIVE.REASSOCIATE_FBA procedures to do this.

But beware! The docs have this to say about doing this:

Oracle cannot endorse compliance history of a table after the table is disassociated. Disassociating a table should only be done after consulting with Oracle Support.

http://docs.oracle.com/database/121/ARPLS/d_flashb_archive.htm#ARPLS72465

Eeep! So if you need to do this, speak with support first.

And it's worth asking: do you really need to disable FBA?

Rating

  (3 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Regarding FBA disable

Srikanth, November 10, 2016 - 6:53 pm UTC

Hi Chris,

Thanks a lot for your prompt reply.

As you have asked "And it's worth asking: do you really need to disable FBA?" Please find my answer below:

Yes FBA needs to be disabled in some cases when business demands. Sometimes as part of business, some DDL operations needs to be performed. As we know that DDL cannot be performed on tables where FBA is enabled, we need to disable FBA for some point of time. Once that process is finished, we can enable FBA. That is the reason behind disabling FBA.

Your suggestion is much useful. I will check whether it works for my case. Will come back to you in case of queries/concerns.


Thanks a lot,
Srikanth
Connor McDonald
November 11, 2016 - 8:25 am UTC

We're better with allowing ddl on fda in 12c.

DBMS_FLASHBACK_ARCHIVE

Rajeshwaran Jeyabal, November 14, 2016 - 10:46 am UTC

....
Sometimes as part of business, some DDL operations needs to be performed. As we know that DDL cannot be performed on tables where FBA is enabled, we need to disable FBA for some point of time. Once that process is finished, we can enable FBA. That is the reason behind disabling FBA.
....

Yes it is for this reason DBMS_FLASHBACK_ARCHIVE package is designed.
http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_flashb_archive.htm#ARPLS72473
<quote>
The Flashback Data Archive feature, which is available through the Total Recall option, 
provides strict protection on the internal history tables that it creates and maintains for users.

The read-only semantics provided prohibits users, including a DBA, from doing updates, deletes, and inserts
on the Flashback Data Archive internal history tables. 
The feature also prohibits users from issuing any DDL statements on these tables. 
This strict security enforcement by Flashback Data Archive meets the requirements of regulatory-compliance type of applications.
The feature supports a lot of common DDL statements, including some DDL statements that alter table definition or incur data movement, 
on user tables that are enabled for Flashback Data Archive. However, there are some DDL statements that are not supported on tables 
enabled for the feature. Since most applications schemas evolve as they release new versions of their software, 
the ability to perform DDL operations on the base table is a key customer requirement.

In order to support user applications' schema evolution during application upgrade and other table maintenance 
tasks beyond DDL statements supported by Flashback Data Archive, the DBMS_FLASHBACK_ARCHIVE package provides a set of simple-to-use PL/SQL procedures:

o To disassociate a Flashback Data Archive enabled base table from the underlying FDA.
o To reassociate a temporarily disassociated base table with its underlying FDA.

After a user has disassociated the base table from its FDA, it's possible to issue any DDL statements 
on the base table or the history tables in the FDA. Having finished with the schema changes, the user can then reassociate 
the base table with its FDA so that Flashback Data Archive protection is in operation and automatic tracking and archiving is resumed.
</quote>

Chris Saxon
November 14, 2016 - 1:43 pm UTC

Yes. Just remember the original warning:

Oracle cannot endorse compliance history of a table after the table is disassociated. Disassociating a table should only be done after consulting with Oracle Support.

http://docs.oracle.com/database/121/ARPLS/d_flashb_archive.htm#ARPLS72465

Clarification of use of dbms_flashback_archive disassociate

Kevin Payne, October 26, 2017 - 7:31 am UTC

Hi,

Great answer, really gives a reality check on the use of dbms_flashback_archive / disassociate.

Hope you don't mind, but I just wanted some clarity on a particular use case we have in this area: We would like to turn off FBA on a table when it is undergoing a heavy overnight load process. And then turn it back on using the FBA dbms_flashback_archive reassociate function once the load has finished.

I guess my questions are: 1) will this method actually save any run time 2) is it safe to do this given the warnings around the use of these functions - Bearing in mind the use case is just a simple bulk insert load process, ie no DDL.
Connor McDonald
October 30, 2017 - 2:38 am UTC

I guess my questions are:

1) will this method actually save any run time

FDA is aimed to be faster than *other* methods that could be used to capture historical records of data (eg triggers etc). The capture is done asychrously, ie, not by your own session, but obviously there are basic limits on what is possible. As I typically say... test it on your own server/infrastructure and find it.

2) is it safe to do this given the warnings around the use of these functions - Bearing in mind the use case is just a simple bulk insert load process, ie no DDL.

Yes..but than what benefit do you really have on the archive ? It is now (potentially) missing a big chunk of data no ? Have you not just lost the heavy overnight loading you just did ?

More to Explore

PL/SQL demos

Check out more PL/SQL tutorials on our LiveSQL tool.

PL/SQL docs

PL/SQL reference manual from the Oracle documentation library