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