llashback Data Archie

.v Oracte !bite Paer

]vve 200


FIashback Data Archive Page 2

NOTE:
1he ollowing is intended to outline our general product direction. It is intended
or inormation purposes only, and may not be incorporated into any contract. It is
not a commitment to delier any material, code, or unctionality, and should not be
relied upon in making purchasing decisions. 1he deelopment, release, and timing
o any eatures or unctionality described or Oracle`s products remains at the sole
discretion o Oracle.
FIashback Data Archive Page 3
llashback Data Archie

INTRODUCTION
Organizations are aced with increasing data retention and change control
requirements. 1he major phenomenon ueling this trend is regulatory oersight and
compliance. Regulations such as Sarbanes-Oxley, lIPAA and Basel-II enorce
strict change control and tracking requirements or customer data. 1hese
regulations aect companies both big and small, in all industry segments. Most o
these regulations speciy long retention periods, typically 5 or more years, during
which the history should be readily accessible. Stop gap or short-term approaches
to managing history data do not work. Companies need a robust, long-term history
management system. Organizations are urther realizing the business alue that can
be extracted rom the historical or temporal dimensions o data. Valuable customer
inormation can be mined rom the historical data store. lailure to maintain
appropriate tracking and retention is expensie. Non-compliance could lead to
ines, loss o inestor conidence and reputation.
A ariety o approaches are currently employed to create and manage historical
transaction data. Unortunately all o them come with signiicant limitations and
orce organizations to make costly compromises. llashback Data Archie is a new
eature in Oracle Database 11g that can automatically track and maintain historical
changes to all Oracle data in highly application transparent, secure and eicient
manner. Part o the Oracle 1otal Recall Option, llashback Data Archie
oercomes the limitations o the current approaches to historical data management
and proides enterprises with a quick, centralized and extremely eicient solution
to meet their historical data management needs.
HISTORICAL DATA MANAGEMENT: CURRENT APPROACHES
A popular approach to implementing a historical data management system is at the
application leel. 1he logic or history management and archiing is embedded
within the business logic. A key adantage o this approach is that applications
understand the business context and can proide easy grouping o dierent
business components that need to be tracked. loweer, this comes with a cost:
increased application complexity. Data access has to be through deined application
interaces to ensure accurate and complete history tracking. Direct updates to the
data at the database leel could introduce data integrity issues with the history and
FIashback Data Archive Page 4
more importantly, could inalidate the whole history. In an organization where
there are typically 100s o applications, with a mix o third party and homegrown
applications, implementing the historical data management system in eery
application is extremely diicult. 1his problem is urther accentuated by application
upgrades, changing retention requirements and a lack o centralized management
interace.
A second approach is to use database triggers to maintain data history. 1his
approach soles many o the problems associated with application-managed data
history. It, howeer, suers rom limitations such as a lack o centralized
management interace, which leads to increased maintenance oerhead. Moreoer,
since triggers are executed with eery transaction in the oreground, user processes
and applications could suer rom degraded perormance.
linally, there are third-party solutions that mine redo logs to create data history.
Since history is stored in a separate database, this approach cannot proide
seamless access to the OL1P and history data. Additionally, these might require
extra training or users due to dierent interaces and are oten expensie and
diicult to build. None o these approaches proide a high-perormance, secure
and seamless history data management system.
FLASHBACK DATA ARCHIVE
1he llashback Archie Data leature in Oracle Database 11g oercomes most o
the aboe limitations. It automatically tracks eery single change made to the data
stored inside the database and maintains a secure, eicient and easily accessible
archie o historical data. 1he captured historical data can be retained or as long as
the business demands and is easily accessible using standard SQL constructs.
listorical data tracking can be enabled on both existing and new tables
instantaneously and more importantly, in a completely application transparent
manner.
Implemented natiely inside the database, llashback Data Archie presents a high-
perormance, storage optimized solution with a centralized management interace
or satisying data retention and change control requirements or organizations. 1he
primary adantages o using llashback Data Archie or historical data tracking
include:
1. Application 1ransparent - Lnabling historical data capture on one or more
tables can be done instantaneously with no or minimal application
changes. Customers can thereore use this eature to capture historical data
or both packaged as well as home grown applications.
2. Seamless Access - listorical data can be easily accessed using amiliar
llashback SQL constructs. llashback Data Archie includes support or
llashback Queries. Applications can seamlessly query the history o table
data, as it existed in dierent points in time. No special snapshots need to
be taken to take adantage o this eature.
FIashback Data Archive Page 5
3. Security - historical data, once generated, is immutable to all users. 1his is
enabled out-o-the-box and no special or extra setup is required. Access to
the internal history tables is restricted to reads only. No DML operations
are allowed to users, including administrators. Applications need not query
the internal history tables directly as seamless access is proided through
the llashback Query mechanism.
4. Minimal perormance oerhead - Regular user transactions will see
negligible impact. llashback Data Archie employs a lightweight
mechanism to mark DML operations on tracked tables or archiing. 1he
actual history generation and archiing is done asynchronously through a
background process as explained later.
5. Storage Optimized - 1he history data is internally partitioned and highly
compressed to reduce the storage ootprint. llashback Data Archie
employs a highly eicient compression scheme to compress the internal
history tables. In addition, it automatically partitions the internal history
tables based on a range-partitioning scheme. Both compression and
partitioning in lashback data archie are managed automatically and
require no special administration.
6. Centralized Management - llashback Data Archie proides a centralized
and policy-based management interace to automate a number o ongoing
administratie tasks. \ith llashback Data Archie, you can easily group
tables and set a common retention policy. New tables will automatically
inherit the retention parameter rom the lashback data archie it is a part
o. Oracle will automatically purge aged-out history data or all tracked
tables based on the speciied retention. 1his rees up the administrator
rom the repetitie management o history data and aoids costly errors
associated with manual maintenance such as purging wrong history.
ORACLE FLASHBACK TECHNOLOGY
Oracle`s llashback technology proides a set o unctionality to access data as o a
time in the past and recoer rom human errors. llashback technology is unique to
the Oracle Database and supports recoery at any leel o granularity including the
row, transaction, table, and database wide. Using lashback eatures you can query
past ersions o data as well as perorm change analysis and sel-serice repair to
recoer rom logical corruption while the database is online. llashback technology
includes the ollowing eatures:
Ilashback Query allows the user to query data at some point-in-time in
the past to reconstruct lost data that may hae been deleted or changed by
accident
Ilashback Version Query proides a mechanism to iew changes made
to the database oer time at the row leel.
FIashback Data Archive Page 6
Ilashback 1ransaction Query proides a mechanism to iew changes
made to the database at the transaction leel.
Ilashback Database is a new strategy or doing point-in-time recoery.
It quickly rewinds an Oracle database to a preious time to correct any
problems caused by logical data corruption or user error.
Ilashback 1able proides the ability to recoer a table, or a set o tables,
to a speciied point in time in the past ery quickly and easily.
Ilashback Drop proides a saety net when dropping objects as you can
ery quickly and easily undrop a table and its dependent objects.
llashback Data Archie is the newest addition to the llashback amily. In Oracle
Database 11g Release 1, llashback Data Archie proides support or querying the
history data using the amiliar llashback Query SQL construct AS Ol`. An
important distinction that distinguishes llashback Data Archie rom the other
llashback eatures is that history data can be accessed or any speciied duration,
ar and beyond the amount o retained undo or lashback log data. listorical data
can be retained or any length o time as required or compliance or other business
reasons. \ith llashback Data Archie, history data is always aailable and readily
queryable.
ARCHITECTURE
Oracle implements a multi-ersioning mechanism that ensures read-consistency
while maintaining high degree o concurrency. \hen DML operations such as
insert, update or delete happen on data, Oracle writes the data into an undo
tablespace that is used not only or transaction rollbacks but also guaranteeing read
consistency in a concurrent enironment. llashback Data Archie works with the
undo data as with many other llashback eatures. As stated aboe, howeer, the
historical data retain in the lashback data archie is no limited by the size o undo
tablespace. listory generation is implemented in a non-intrusie manner through a
new background process called bda`. Ater a table has been enabled or history
FIashback Data Archive Page 7
tracking with llashback Data Archie, all transactions and the corresponding undo
records are marked or archial. In order to guarantee that eery transaction is
archied, the undo records are not recycled until the history is generated and stored
in the database. 1he process sleeps and wakes up at system-managed interals and
processes the undo data marked or archial. Ater bda` generates the history, the
transactions and undo records are candidates or recycling. 1his asynchronous
bda` process ensures negligible impact on the oerall transaction or oreground
perormance.
1he bda` process intelligently adjusts its sleep interal based on the system undo
generation rate. As transaction actiity increases, bda` automatically reduces the
sleep interal rom the deault sleep time o 5 minutes. lor better perormance,
bda` process also adjusts its sleep time in order to maximize undo data reads rom
the buer cache. llashback Data Archie also uses an internal partitioning scheme
or all the historical data or better perormance. It also employs table compression
to reduce the storage ootprint o the historical data that could easily grow into
hundreds o terabytes or longer retention times.
UNDERSTANDING FLASHBACK DATA ARCHIVE
A llashback Data Archie is a logical container or managing historical inormation
or related tables. It is a new data dictionary object in Oracle Database 11g that
deines archie storage and data purging policies A llashback Data Archie can
span multiple tablespaces. Administrators can deine the amount o space a
lashback data archie can use in each tablespace using the QUO1A` parameter.
Multiple lashback data archies can be created as needed to implement dierent
archiing policies. Lach lashback data archie contains a RL1LN1ION`
parameter that speciied the duration or retaining the historical changes. llashback
Data Archie guarantees that historical data will be retained or the duration
speciied by RL1LN1ION` and automatically purges out aged historical data.
Additionally, administrators, with the necessary priileges, can purge historical data
in an ad-hoc manner.
llashback Data Archie creates an internal history table or eery tracked table. 1he
internal history table is a replica o the tracked table with additional timestamp
columns. \hen one or more columns in the tracked table are updated, a new row is
inserted into the history table that is the beore-image o the row beore the
transaction. It is important to note that UPDA1L and DLLL1L operations
generate a new record in the history table. llashback Data Archie does not create
a new history record or INSLR1 operations. 1he internal history table is
partitioned or better perormance. No modiications are allowed to internal
partitions. 1he internal history tables are compressed to reduce the disk space
requirements. Applications or users need not access the internal history tables
directly. 1he AS Ol` SQL construct can be used to seamlessly query the historical
data.
FIashback Data Archive Page 8
HISTORY TRACKING USING FLASHBACK DATA ARCHIVE
FIashback Data Archive Requirements
1. 1ablespaces managed with automatic segment space management ,ASSM, are
required or using with llashback Data Archie
2. Automatic Undo Management must be enabled
Step-by-Step Approach
1here are 3 steps to enabling history tracking on tables using llashback Data
Archie.
1. Create a new tablespace with automatic segment space management or storing
historical data ,Optional,
2. Create a lashback data archie
CREATE FLASHBACK ARCHIVE fda1
TABLESPACE tbs1
RETENTION 5 YEAR;

1his creates a new lashback data archie called da1` on tablespace tbs1 with a
retention policy o 5 years. Since QUO1A` is not speciied, the deault setting o
Unlimited is used. At this point, we hae created a logical container or placeholder
or historical data.

3. Lnable history data archiing desired tables
ALTER TABLE EMPLOYEES FLASHBACK ARCHIVE fda1;

1able LMPLO\LLS now has been enabled or historical data tracking and its
history data will be stored in lashback data archie da1`. \hen the irst DML
operation happens, the internal history table is created in da1`.
lLASlBACK ARClIVL ADMINIS1LR system priilege is required or
creating a new lashback data archie
1he ollowing static data dictionary iews are aailable
DBA,USLR_lLASlBACK_ARClIVL - Displays inormation about
llashback Data Archies
DBA,USLR_lLASlBACK_ARClIVL_1S - Displays tablespaces and
the mapping to llashback Data Archies
lLASlBACK ARClIVL object priilege is required to enable historical data
tracking
1he ollowing static data dictionary iews are aailable
DBA,USLR_lLASlBACK_ARClIVL_1ABLLS Displays
inormation about tables that are enabled or lashback archiing.
FIashback Data Archive Page 9

QUERYING HISTORY DATA
llashback Data Archie proides seamless access to the historical data using the
AS Ol` SQL construct. \ou can query or the state o any row in the tracked table
going as ar back as your speciied retention period.
1he ollowing is an example or querying the salary details or employee with
id~193 on June 1, 200.
SELECT last_name, first_name, salary
FROM EMPLOYEES AS OF TIMESTAMP TO_TIMESTAMP ('2007-06-
01 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
WHERE employee_id=193;
MANAGING FLASHBACK DATA ARCHIVES
llashback Data Archie guarantees historical data capture or all transactional
changes to tracked tables. llashback Data Archie thereore automatically disallows
any operation that would inalidate history. DDL operations that are disallowed on
tracked tables include dropping, truncating or renaming tables, dropping or
modiying columns. Partition or subpartition operations on the internal history
tables are also disallowed. It is howeer possible to add new columns without
disrupting historical data capture.
New PriviIeges for FIashback Data Archive
lLASlBACK ARClIVL ADMINIS1LR - A new system priilege managing
lashback data archies. Allowed operations include:
Create new lashback data archie
Modiy existing lashback data archie
Make a speciic lashback data archie as deault
Set RL1LN1ION time
Ad-hoc purge o history data
Add,remoe tablespaces
Disable tracking or tracked tables
Drop lashback data archie
lLASlBACK ARClIVL - A new object priilege or enabling tracking on
tables on the lashback data archies
FIashback Data Archive Page 10
RECOMMENDED BEST PRACTICES
In order to optimize perormance and space consumption, llashback Data Archie
does not automatically replicate base table indexes on the internal history tables.
Users are recommended to query the
DBA,USLR_lLASlBACK_ARClIVL_1ABLLS iew or the name o the
internal table using and create the desired indexes on this internal history table. It is
important to note that these indexes will hae a perormance impact on the
llashback Data Archie process as it will hae to maintain the indexes in addition
to collecting and archiing the transactional changes.
Secondly, it is recommended to use dedicated tablespaces or lashback data
archies. 1he QUO1A parameter should be let at the deault alue o Unlimited.
1his makes space planning and maintenance o lashback data archies easier. Also,
group tables based on desired retention period and create a new lashback data
archie or each retention period.
linally, access to the system priilege lLASlBACK ARClIVL ADMINIS1LR`
should be restricted. It is recommended to separate user access to the system
priilege lLASlBACK ARClIVL ADMINIS1LR` rom the object priilege
lLASlBACK ARClIVL`.
CONCLUSION
llashback Data Archie proides a secure, eicient and application transparent
solution or generating and managing historical data. It proides a centralized and
integrated interace to manage and retain data history. An automated, policy-based
management greatly simpliies administration. \ith llashback Data Archie, you
can easily implement historical data tracking to comply with new regulations or
adapt to changing business needs.


White Paper TitIe
June 2007
Author: RAVI RAJAMANI

OracIe Corporation
WorId Headquarters
500 OracIe Parkway
Redwood Shores, CA 94065
U.S.A.

WorIdwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracIe.com

Copyright 2007, OracIe. AII rights reserved.
This document is provided for information purposes onIy and the
contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to any
other warranties or conditions, whether expressed oraIIy or impIied
in Iaw, incIuding impIied warranties and conditions of merchantabiIity
or fitness for a particuIar purpose. We specificaIIy discIaim any
IiabiIity with respect to this document and no contractuaI obIigations
are formed either directIy or indirectIy by this document. This document
may not be reproduced or transmitted in any form or by any means,
eIectronic or mechanicaI, for any purpose, without our prior written permission.
OracIe is a registered trademark of OracIe Corporation and/or its affiIiates.
Other names may be trademarks of their respective owners.