 |
|
Oracle 11g Total
Recall/Flashback Data Archive
Oracle 11g New Features Tips by Donald BurlesonJune 29, 2015 |
Oracle 11g New Features Tips
Tracking transactional changes on tables over
its lifetime by using FLASHBACK DATA ARCHIVE
Also see
Oracle Total
Recall Tips.
More and more, legal regulations
such as Sarbanes Oxley and Basel II are challenging
all kinds of organizations by enforcing strict change control of
customer data. These obligations demand that a history of all
changes to customer data must be maintained. Nowadays, companies
are commonly required to retain their data for periods of 5 or more
years, and must be able to review historical data almost in real
time.
One common approach to this
problem is the implementation of essentially home grown data
management systems which integrate the maintenance of the history
and archiving in business logic. The application has to keep track
of data changes which can make applications terribly complex, and
create difficulties in applying upgrades to the application.
The approach of using PL/SQL
triggers for tracking changes can have a massive impact on the
performance of an application. This is because it
is compiled source code, stored in the data
dictionary, which needs to execute again and again. Another drawback
of such a solution is that there is no central interface for the
management of those triggers.
Most of the flashback
functionalities rely on UNDO data which will error out with an
ORA-1555 snapshot too old if the required before image
cannot be read any more. ORA-1555 occurs because it
has already been overwritten in the undo
tablespace. Furthermore, it is very unlikely that the old values
can be reconstructed over a longer period of time, like months or
even years, from data stored in the undo segments.
Luckily, this UNDO data time
issue can now be remedied. With the flashback data
archive functionality of 11g the Oracle database is capable
of automatically tracking transactional changes to data over very
long periods. Oracle achieves this by storing UNDO information in
special segments within dedicated tablespaces.
The usage of this feature is
completely transparent for the application and the end user, who can
view historical data from the flashback archive seamlessly with
regular SQL statements. This is done by utilizing traditional
flashback functionalities, such as flashback query,
flashback versions query, flashback transaction query,
etc.
The historical information in the flashback data
archive ages out automatically and Oracle automatically purges it
after the specified retention period has exceeded. However, the
flashback data archive provides the DBA with a central interface for
the management of historical data and change tracking.
%
With a flashback data archive it is possible to view data
as any point in time since the flashback data archive
was created. However, attempting to view data
as a timestamp before the data archive is created causes the
following error: ORA-01466: unable to read data -
table definition has changed
The technology behind flashback data
archive
With every Oracle 11g database
startup, the new flashback data archiver background
process, FBDA, is automatically started. This is what
generates and archives the historical data.
Transactions encounter very
little performance impact from flashback data archiving because
Oracle only marks DML operations as candidates for archiving. A
special background process then generates and archives the history
information asynchronously for tables enabled for flashback
archival.
Oracle also automatically compresses the
internally used history tables and partitions them based on a range
partitioning scheme. The partitioning and compression of the history
tables is fully transparent and does not require any additional
administrative intervention.
A flashback data archive
consists of at least one tablespace, and can span multiple
tablespaces. It is possible to add a new tablespace to a flashback
archive at any time.