The DBMS_FLASHBACK_ARCHIVE
package contains procedures for performing various tasks such as:
Disassociation and reassociation of a Flashback Data Archive (FDA) enabled table from/with its underlying FDA
Tamper-proofing the tables of an application
Importing of user history
Caution:
Importing user-generated history can lead to inaccurate, or unreliable results. This procedure should only be used after consulting with Oracle Support.Enabling and disabling of session-level support for valid-time
See Also:
Oracle Database Development Guide for more information about "Using Flashback Data Archive (Oracle Temporal)"This chapter contains the following topics:
Overview
Security Model
Constants
Flashback Data Archive (FDA) provides strict protection on the internal history tables that it creates and maintains for users.
The read-only semantics prohibit users, including a DBA, from doing updates, deletes, and inserts on the Flashback Data Archive internal history tables. Users are also prevented from issuing any DDL statements on these tables. This strict security enforcement helps meet the requirements of applications in regulatory / compliance environments. Flashback Data Archive supports most common DDL statements, including those that alter the table definition or incur data movement. However, some DDL statements are not supported on Flashback Data Archive-enabled tables. Since most application schemas are modified during application software upgrades, the ability to perform DDL operations on tracked tables is critical.
To support schema evolution during application upgrades and other table maintenance tasks that require use of DDL statements not supported by Flashback Data Archive, the DBMS_FLASHBACK_ARCHIVE
package provides a set of simple-to-use PL/SQL procedures:
To disassociate a Flashback Data Archive enabled base table from the underlying FDA
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.
Users need the FLASHBACK_ARCHIVE_ADMINISTER
privilege to import user-generated history, to set context level, and to tamper-proof tables. After a table is disassociated, users can perform DDL and DML statements on the table if they have the necessary privileges. Enabling and disabling session-level Valid Time Temporal flashback needs no additional privileges.
Caution:
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.Table 71-2 DBMS_FLASHBACK_ARCHIVE Package Subprograms
Subprogram | Description |
---|---|
Takes an application name and adds a table to the application as a security table |
|
Creates a table called |
|
Takes an application name and marks a table in it as a security table |
|
Disables session level valid-time flashback |
|
Disassociates the given table from the flashback data archive |
|
Takes an application name and removes it from the list of applications |
|
Takes an application name and enables Flashback Data Archive on all the security tables for this application |
|
Enables session level valid time flashback |
|
Extends time mappings to times in the past |
|
Gets the context previously selected by the SET_CONTEXT_LEVEL Procedure |
|
Imports history from a table called |
|
Takes an application name and makes all the security tables read-only. The group called |
|
Purges the context to be saved selected by the SET_CONTEXT_LEVEL Procedure |
|
Reassociates the given table with the flashback data archive |
|
Takes an application name and optionally a Flashback Data Archive, and registers an application for database hardening |
|
Takes an application name and marks a table in it as no longer being a security table |
|
Defines how much of the user context is to be saved |
This procedure takes an application name and adds a table to the application as a security table. If the application is enabled for Flashback Data Archive, then this table will also be enabled for Flashback Data Archive.
DBMS_FLASHBACK_ARCHIVE.ADD_TABLE_TO_APPLICATION ( application_name IN VARCHAR2, table_name IN VARCHAR2, schema_name IN VARCHAR2 := NULL);
Table 71-3 ADD_TABLE_TO_APPLICATION Procedure Parameters
Parameter | Description |
---|---|
|
Name of the application for which a table has been added as a security table |
|
Name of the table to add as a security table for the given application |
|
Name of the schema containing the desired table. If no schema name is specified, the current schema is used. |
This procedure creates a table called TEMP_HISTORY
with the correct definition in schema.
DBMS_FLASHBACK_ARCHIVE.CREATE_TEMP_HISTORY_TABLE ( owner_name1 IN VARCHAR2, table_name1 IN VARCHAR2);
This procedure takes an application name and disables Flashback Data Archive on all of its security tables.
This procedure disassociates the given table from the flashback data archive.
This procedure takes an application name and removes it from the list of applications. As part of this procedure, Flashback Data Archive will be disabled on all security-enabled tables and all history data will be lost. The group called SYSTEM
cannot be dropped.
This procedure takes an application name and enables Flashback Data Archive on all the security tables for this application. Once an application is enabled, every change to an FDA enabled table will be tracked.
This procedure enables session level valid time flashback.
DBMS_FLASHBACK_ARCHIVE.ENABLE_AT_VALID_TIME ( level IN VARCHAR2, query_time IN TIMESTAMP DEFAULT SYSTIMESTAMP);
Table 71-10 ENABLE_AT_VALID_TIME Procedure Parameters
Parameter | Description |
---|---|
|
Options:
|
|
Used only if level is |
This function gets the context previously selected by the SET_CONTEXT_LEVEL Procedure.
DBMS_FLASHBACK_ARCHIVE.GET_SYS_CONTEXT ( xid IN RAW, namespace IN VARCHAR2, parameter IN VARCHAR2) RETURN VARCHAR2;
This procedure is called after invoking the CREATE_TEMP_HISTORY_TABLE Procedure procedure, and after the TEMP_HISTORY
table is populated with user-generated history data.
Caution:
Importing user-generated history can lead to inaccurate, or unreliable results. This procedure should only be used after consulting with Oracle Support.DBMS_FLASHBACK_ARCHIVE.IMPORT_HISTORY ( owner_name1 IN VARCHAR2, table_name1 IN VARCHAR2 temp_history_name IN VARCHAR2 DEFAULT 'TEMP_HISTORY', options IN BINARY_INTEGER DEFAULT 0);
Table 71-12 IMPORT_HISTORY Procedure Parameters
Parameter | Description |
---|---|
|
Schema of the Flashback Data Archive-enabled table |
|
Name of the Flashback Data Archive-enabled table |
|
Optional temporary history table from which we import history data |
|
One (or a combination) of constants ( |
The database function TIMESTAMP_TO_SCN
can be used to convert times to SCN when populating the temporary history table.
This procedure takes an application name and makes all the security tables read-only. The group called SYSTEM
cannot be locked.
This procedure purges the context to be saved selected by the SET_CONTEXT_LEVEL Procedure.
This procedure reassociates the given table with the flashback data archive.
The procedure will signal an error if the base table and the history table do not have identical data definitions. For example, when columns are added or table is split, the resulting base table and history table need to have the same schema.
The FDA internal history table schema has some row versions metadata columns. The procedure will signal an error if any metadata column is dropped by users.
This procedure takes an application name and optionally a Flashback Data Archive, and registers an application for database hardening. When database hardening is enabled, then all the security tables for that application are enabled for Flashback Data Archive using the given Flashback Data Archive. If no Flashback Data Archive is specified, the default Flashback Data Archive is used.
See Also:
Using Flashback Data Archive in Oracle Database Development Guide regarding database hardeningDBMS_FLASHBACK_ARCHIVE.REGISTER_APPLICATION ( application_name IN VARCHAR2, flashback_archive_name IN VARCHAR2 := NULL);
Table 71-16 REGISTER_APPLICATION Procedure Parameters
Parameter | Description |
---|---|
|
Name of the application which is being registered. The application |
|
Name of the Flashback Data Archive in which the historical data for the security tables for given application is stored. If no Flashback Data Archive is specified, the default Flashback Data Archive is used. |
This procedure takes an application name and marks a table in it as no longer being a security table. If the application is already enabled for Flashback Data Archive, Flashback Data Archive will be disabled for this table.
DBMS_FLASHBACK_ARCHIVE.REMOVE_TABLE_TO_APPLICATION ( application_name IN VARCHAR2, table_name IN VARCHAR2, schema_name IN VARCHAR2 := NULL);
Table 71-17 REMOVE_TABLE_FROM_APPLICATION Procedure Parameters
Parameter | Description |
---|---|
|
Name of the application for which a table is being removed from the list of security tables |
|
Name of the table to mark as being no longer a security table for the given application |
|
Name of the schema containing the desired table. If no schema name is specified, the current schema is used. |