Flashback Data Archive
While you can rely on the undo data in the undo tablespace to query older versions of a row or even perform a logical recovery, there’s a limit on how far back you can go. Because the main purpose of the undo data is to provide data consistency, you can’t expect to find very old versions of a row in the undo segments. Undo tablespaces are usually sized by the DBA to provide read consistency for the longest transactions run in a database. The undo tablespace was never meant to be a historical repository of all the changes made to a row in a table.
In addition, the undo tablespace contains all the data changes made in the database, not just changes for a specific table. If you want to go back, say, two years in time to find out what values a certain table’s row had then, the undo tablespace can’t help you. Your only choice was to maintain the change records in separate tables and maintain them yourself. Oracle Database 11g’s new flashback data archive feature enables you to automatically store changes made to a table’s data over time. The flashback data archive lets you store data changes for any length of time you want. An undo tablespace can only help you if the SCN of the transaction you are interested in exists in one of the undo segments. A flashback data archive has nothing to do with the SCN of the transactions—it will simply store the data for the period of time you specify. Once the retention period is up, the archive will purge the older data automatically. Thus, the archive imposes hardly any administrative burden on you. You simply create the flashback data archive and walk away from it! You don’t turn on the flashback data archive for the entire database, as you do with automatic undo management. You specify the table or tables for which you want the archive to track and store changes.
You can’t modify any data stored in a flashback data archive, but you are allowed to purge data from it.
Flashback Data Archive and Flashback Database
The flashback data archive is quite different from the Flashback Database feature,
although both involve some kind of flashing back to a previous state of the database.
However, the two features are quite distinct, as follows:
The Flashback Database feature lets you take the database back in time. A flashback data archive doesn’t change the current data. That is, the database remains in its current state—the flashback data archive simply lets you access the data from a previous point in time.
You must enable table tracking for the flashback data archive to function, whereas you must configure the
Flashback Database feature.
The flashback data archive is an online feature, while the Flashback Database is an offline feature.
You can use the Flashback Database only at the database level, whereas you can enable the flashback data archive at the table level.
A Flashback Database operation enables you to take back the entire database to the same point in time in the past, whereas the flashback data archive feature enables you to go to different points in time for different tables.
How Flashback Data Archiving Works
The flashback data archive itself is a logical container for historical data for one or more tables in the database. The archive contains the data itself along with the retention and purging policies for the data. The flashback data archive stores its data in one or more tablespaces that you assign to the archive. In order for the database to archive a table’s changes, you must first enable that table for the flashback archiving. Once you do this, the new Oracle background process fbda (Flashback Data Archiver) writes the changed data in the tables to the flashback data archive. You should be aware of the following aspects of the flashback data archive feature:
- A flashback data archive can contain data from multiple tables.
- You can set different retention periods for different tables, by assigning them to different flashback data archives.
- You can create multiple flashback data archives. In fact, Oracle recommends that you do this so that you can dedicate one flashback area, say, for long-term storage, such as five years, and the other flashback data archive for a shorter period, such as a year or six months. You can assign one of the flashback data archives as the default flashback archive for the database. Any table for which you don’t specify a flashback data archive will then use the default flashback archive for archival storage.
- The database automatically purges the flashback data archive by deleting the necessary data a day after the expiration of the retention period you set for that table.
- Once you enable a table for flashback data archiving, the database creates an internal history table for that table to hold the historical data. In addition to the columns of the original table, the historical table will have a few additional columns showing the time stamp of the transactions in order to track transactions.
An insert operation won’t cause the database to add any rows to the historical table because that row doesn’t have a before change image. But when you update or delete a row in the original table, the fbda process marks the undo records corresponding to these operations for archival. The fbda records the pre-commit image of the row that was affected by the delete or update operation in the history table. The fbda process first tries to use the undo in the buffer cache. If the undo is gone from the buffer cache already, fbda will read the necessary values from the undo segments. At system-determined intervals (default is 5 minutes), the fbda process wakes up and copies the necessary undo data to the history table. To enable the functioning of the flashback data archiving process, the database ensures that any undo records that the fbda has marked for recording to the history table aren’t recycled. The database automatically adjusts the sleep time of the fbda process by lowering it when the database is generating a large amount of undo data, thus enabling fbda to read frequently from the buffer cache. Because the fbda doesn’t work continuously, there will be a lag between the time an update or delete operation commits and the time the changed data shows up in the history table.
Benefits of Using a Flashback Data Archive
The flashback data archive feature provides the following important benefits:
- You can set a common retention policy for a related group of tables.
- The database automatically purges older data from the flashback archive.
- Instead of writing your own administrative interface, you can use a centralized management interface to manage the data archive.
- You can use the as of flashback query to retrieve historical data.
- The database makes the retrieval of historical data efficient by automatically partitioning the internal history tables using a range-partitioning scheme.
- You don’t need to make any application changes to implement the feature.
- There is a very small overhead for implementing data archiving because the fbda process archives the data so efficiently.
- The database stores the archived data in a compressed format, saving storage space.
- Archiving data is safe because no one, including the DBA, can directly update the historical data—they can only query it. Because you can’t modify the archived data, the archive remains tamper proof, which is a big objective behind using the archive. In fact, the data in the archive is safer than the original data because the archived data is tamper-proof.
Creating a Flashback Data Archive
You can query the DBA_SYS_PRIVS view, as shown here, to find out which users have the flashback archive administer privilege.
SQL> select * from dba_sys_privs where privilege like '%FLASH%';
GRANTEE PRIVILEGE ADM
----------- --------------------- ----
SYS FLASHBACK ANY TABLE NO
DBA FLASHBACK ANY TABLE YES
DBA FLASHBACK ARCHIVE ADMINISTER YES
You grant the flashback archive administer privilege to a user as follows:
SQL> grant flashback archive administer to hr;
Grant succeeded.
It’s probably a good idea to designate a DBA or some other user as your flashback data archive administrator and grant the flashback data archive privilege to that user alone in order to make the archive secure. The flashback archive administer system privilege allows a user to execute the following statements pertaining to the administration of the flashback data archives.
create flashback archive
alter flashback archive
drop flashback archive
You allow a user access to a specific flashback data archive by granting the flashback archive object privilege on that flashback data archive to the user, as shown here:
SQL> grant flashback archive on flash1 to oe;
The previous grant flashback archive statement confers the privilege to the user OE to use the flashback archive flash1. Once you grant the flashback archive object privilege to a user, that user can enable flashback archiving for a specific table in the flashback archive for which the user was granted the flashback archive privilege. You must also grant the users the flashback and select privileges on all the objects referenced in a query, so the users are allowed to access to those objects. You must also grant a user the execute privilege on the DBMS_FLASHBACK feature, so the user can use the DBMS_FLASHBACK.ENABLE and DBMS_FLASHBACK.DISABLE procedures to enable and disable the flashback data archive for which they’ve been granted the flashback archive object privilege.
Use the create flashback statement to create a flashback data archive. Remember that the flashback data archive, while it’s a database object, is only a logical construct. The tablespace you assign to the archive stores the data. Thus, you first create a new tablespace to assign to the flashback data archive you’re about to create. You may also use an already available tablespace for this purpose because the archive doesn’t require a dedicated tablespace.
When creating a flashback data archive with the create flashback statement, you can specify the following:
A flashback data archive name
Whether the flashback data archive is the default archive for the database (you don’t have to create a default archive)
The name of the tablespace to which you want to assign the flashback data archive
You must first create the tablespace that will host the flashback data archive. You may specify the following things while creating a new flashback data archive:
- A quota for the flashback data archive in the tablespace you’re assigning for the archive: If you don’t assign a quota, the archive can take up all the space available in that tablespace.
- A retention period for the archive: This is a mandatory attribute, because it determines how long the database must retain the data in the archive before purging it.
You size the flashback data archive based on the amount of transactions you anticipate the database will be archiving and the length of time for which you want the archive to retain the data. If the flashback data archive runs out of space, Oracle issues an out-of-space alert and marks it in the archive log for the database. You can then either purge older data to free up space in the archive or add space to the tablespace that you assigned for the flashback data archive.
The following script creates a new tablespace, then creates two flashback data archives using the CREATE FLASHBACK ARCHIVE command. The first is limited in size to 10Gig with a retention period of 1 year, while the second has an unlimited quota and a retention period of 2 years.
CREATE TABLESPACE fda_ts
DATAFILE '/u01/app/oracle/oradata/DB11G/fda1_01.dbf'
SIZE 1M AUTOEXTEND ON NEXT 1M;
CREATE FLASHBACK ARCHIVE DEFAULT fda_1year TABLESPACE fda_ts
QUOTA 10G RETENTION 1 YEAR;
CREATE FLASHBACK ARCHIVE fda_2year TABLESPACE fda_ts
RETENTION 2 YEAR;
Management of flashback archives falls into three distinct categories.
Tablespace management.
-- Set as default FBA
ALTER FLASHBACK ARCHIVE fba_name SET DEFAULT;
-- Add up to 10G of the specified tablespace to the specified flashback archive.
ALTER FLASHBACK ARCHIVE fba_name ADD TABLESPACE ts_name QUOTA 10G;
-- Add an unlimited quota of the specified tablespace to the specified flashback archive.
ALTER FLASHBACK ARCHIVE fba_name ADD TABLESPACE ts_name;
-- Change the tablespace quota to 20G.
ALTER FLASHBACK ARCHIVE fba_name MODIFY TABLESPACE ts_name QUOTA 20G;
-- Change the tablespace quota to unlimited.
ALTER FLASHBACK ARCHIVE fba_name MODIFY TABLESPACE ts_name;
-- Remove the specified tablespace from the archive.
ALTER FLASHBACK ARCHIVE fba_name REMOVE TABLESPACE ts_name;
Modifying the retention period.
ALTER FLASHBACK ARCHIVE fba_name MODIFY RETENTION 2 YEAR;
Purging data.
-- Remove all historical data.
ALTER FLASHBACK ARCHIVE fba_name PURGE ALL;
-- Remove all data before the specified time.
ALTER FLASHBACK ARCHIVE fba_name PURGE BEFORE TIMESTAMP (SYSTIMESTAMP - INTERVAL '1' DAY);
-- Remove all data before the specified SCN.
ALTER FLASHBACK ARCHIVE fba_name PURGE BEFORE SCN 728969;
Archives are removed using the DROP FLASHBACK ARCHIVE command, which drops the archive and all its historical data, but doesn't drop the associated tablespace.
DROP FLASHBACK ARCHIVE fba_name;
To enable flashback archiving on a specific table the user must have the FLASHBACK ARCHIVE object privilege on the specific flashback archive used. To try this out create a test user and grant the object privilege on the first flashback archive created earlier.
CONN sys/password AS SYSDBA
CREATE USER fda_test_user IDENTIFIED BY fda_test_user QUOTA UNLIMITED ON users;
GRANT CONNECT, CREATE TABLE TO fda_test_user;
GRANT FLASHBACK ARCHIVE ON fda_1year TO fda_test_user;
If we connect to the test user we are able to create a table and associate it with the default flashback archive as follows.
CONN fda_test_user/fda_test_user
CREATE TABLE test_tab_1 (
id NUMBER,
desription VARCHAR2(50),
CONSTRAINT test_tab_1_pk PRIMARY KEY (id)
)
FLASHBACK ARCHIVE;
If we try to create a similar table, but point it at the second archive it fails, as we have no privileges on it.
CONN fda_test_user/fda_test_user
CREATE TABLE test_tab_2 (
id NUMBER,
desription VARCHAR2(50),
CONSTRAINT test_tab_2_pk PRIMARY KEY (id)
)
FLASHBACK ARCHIVE fda_2year;
CREATE TABLE test_tab_2 (
*
ERROR at line 1:
ORA-55620: No privilege to use Flashback Archive
The ALTER TABLE command allows existing tables to have flashback archiving switched on or off.
-- Enable using the default FBDA.
ALTER TABLE table_name FLASHBACK ARCHIVE;
-- Enable using specific FBDA.
ALTER TABLE table_name FLASHBACK ARCHIVE fda_name;
-- Disable flashback archiving.
ALTER TABLE table_name NO FLASHBACK ARCHIVE;
Note: When you include the no flashback archive clause, the database will remove all the flashback data for that table from the flashback data archive. The previous statement would only affect flashback logging for the EMPLOYEES table. The flashback logging for the other tables would continue and the flashback archive itself remains in place. In order to remove the flashback archive itself, you must use the drop flashback archive statement.
As with the CREATE TABLE statement, the FLASHBACK ARCHIVE object privilege must be granted on the flashback archive being used.
Once flashback archiving is enabled the table is protected, so it cannot be switched off unless you have the FLASHBACK ARCHIVE ADMINISTER system privilege, or are logged on as SYSDBA.
SQL> ALTER TABLE test_tab_1 NO FLASHBACK ARCHIVE;
ALTER TABLE test_tab_1 NO FLASHBACK ARCHIVE
*
ERROR at line 1:
ORA-55620: No privilege to use Flashback Archive
Flashback archive Restrictions
In addition, there are certain DDL restrictions associated with having flashback archiving enabled in 11gR1. The following operations result in a ORA-55610 error.
ALTER TABLE statements that drop, rename or modify columns.
ALTER TABLE statements that performs partition or subpartition operations.
ALTER TABLE statements that converts a LONG column to a LOB column.
ALTER TABLE statements that includes an UPGRADE TABLE clause, with or without an INCLUDING DATA clause.
DROP TABLE statements.
RENAME TABLE statements.
TRUNCATE TABLE statements.
In 11gR2 some of these restrictions have been removed and the following DDL is supported.
Add, drop, rename or modify column.
Drop or truncate partitions.
Rename or truncate tables.
Add, drop, rename or modify constraints.
More complex DDL can be performed in conjunction with the DISASSOCIATE_FBA and REASSOCIATE_FBA procedures of the DBMS_FLASHBACK_ARCHIVE package.
Monitoring Flashback Data Archives
Information about flashback data archives is displayed using the %_FLASHBACK_ARCHIVE view.
Information about flashback data archives is displayed using the %_FLASHBACK_ARCHIVE view.
SQL> CONN sys/password AS SYSDBA
SQL> COLUMN flashback_archive_name FORMAT A20
SQL> SELECT flashback_archive_name, retention_in_days, status
FROM dba_flashback_archive;
FLASHBACK_ARCHIVE_NA RETENTION_IN_DAYS STATUS
-------------------- ----------------- -------
FDA_2YEAR 730
FDA_1YEAR 365 DEFAULT
2 rows selected.
The %_FLASHBACK_ARCHIVE_TS view displays the tablespaces and quotas associated with each flashback archive.
SQL> COLUMN flashback_archive_name FORMAT A20
SQL> COLUMN quota_in_mb FORMAT A10
SQL> SELECT flashback_archive_name, tablespace_name, quota_in_mb
FROM dba_flashback_archive_ts;
FLASHBACK_ARCHIVE_NA TABLESPACE_NAME QUOTA_IN_M
-------------------- ------------------------------ ----------
FDA_2YEAR FDA_TS
FDA_1YEAR FDA_TS 10240
2 rows selected.
The %_FLASHBACK_ARCHIVE_TABLES view displays tables associated with each flashback archive, along with the name of the table holding the historical information.
SQL> COLUMN table_name FORMAT A15
SQL> COLUMN owner_name FORMAT A15
SQL> COLUMN flashback_archive_name FORMAT A20
SQL> COLUMN archive_table_name FORMAT A20
SQL> SELECT table_name, owner_name, flashback_archive_name, archive_table_name
FROM dba_flashback_archive_tables;
TABLE_NAME OWNER_NAME FLASHBACK_ARCHIVE_NA ARCHIVE_TABLE_NAME
--------------- --------------- -------------------- --------------------
TEST_TAB_1 FDA_TEST_USER FDA_1YEAR SYS_FBA_HIST_72023
1 row selected.
Using Flashback Data Archives
The following examples illustrate the versatility of the flashback data archive feature.
SQL> select transaction_number, doctor_name, count
from patient_info as of
timestamp to_timestamp ('2007-01-01 00:00:00',
'YYYY-MM-DD HH23:MI:SS');
You can use the as_of clause to recover from logical errors, by retrieving older data, even when you don’t know the exact time when the wrong data entry was made. The following example shows how to use the as_of clause to correct wrongly updated data in a table.
SQL> update hr.employees set salary =
(select salary from hr.employees
as of timestamp (systimestamp - interval '120' minute);
where last_name='Zlotkey')
where last_name='Zlotkey';
1 row updated.
SQL> commit;
Commit complete.
The update shown here uses historical values made possible by the use of the flashback data archive but the use of the flashback data archive is transparent. That is, in order to correct the logical error by retrieving the historical value of the SALARY column, you don’t have to query the history table directly. The database will use that information automatically because you specified the as of clause in your update statement. The systimestamp - interval '120' clause tells the database to retrieve the values that prevailed two hours before for the SALARY column for the user Zlotkey. If you want, you can specify seconds, days, and months as well in the systimestamp clause, as shown here:
systimestamp - interval '60' second
systimestamp - interval '7' day
systimestamp - interval '12' month
You can use the historical data stored in the flashback data archive to create reports that span a long period of time in the past. Use the versions between timestamp clause as shown here to get values for a table’s columns that prevailed during a time interval that you specify.
SQL> select * from patient_info
versions between timestamp
to_timestamp('2008-01-01 00:00:00','YYYY-MM-DD HH23:MI:SS')
and maxvalue
where name ='ALAPATI';
The query uses the versions between timestamp clause to capture all versions of the data in the PATIENT_INFO table between January 1, 2008 and today for the patient named ALAPATI.
You can also use the versions between clause to retrieve multiple versions of a row to satisfy the requirement of information lifecycle management (ILM) applications. Instead of your having to collect and store the multiple versions over time, you can simply enable flashback data archiving for the tables that you need to track for an ILM application. Here’s an example that shows how you can specify the versions between clause to retrieve all versions of a table’s rows during a specific interval of time.
SQL> select * from patient_info
versions between timestamp
to_timestamp ('2008-01-01 00:00:00',
'YYYY-MM-DD HH24:MI:SS')
and
to_timestamp ('2008-06-01 00:00:00',
'YYYY-MM-DD HH24:MI:SS')
where name='ALAPATI';
The select statement shown here utilizes the flashback data archive to retrieve all versions of the rows in the PATIENT_INFO table for the first six months of the year 2008.
参考至:《McGraw.Hill.OCP.Oracle.Database.11g.New.Features.for.Administrators.Exam.Guide.Apr.2008》
http://www.oracle-base.com/articles/11g/flashback-and-logminer-enhancements-11gr1.php#flashback_data_archive
本文原创，转载请注明出处、作者
如有错误，欢迎指正
参考至:《McGraw.Hill.OCP.Oracle.Database.11g.New.Features.for.Administrators.Exam.Guide.Apr.2008》
http://www.oracle-base.com/articles/11g/flashback-and-logminer-enhancements-11gr1.php#flashback_data_archive
本文原创，转载请注明出处、作者
如有错误，欢迎指正