Oracle RMAN

One (if not the, most important) jobs of the Oracle DBA is to ensure that the databases in their
care are protected. Databases, or data in the database, can be lost through a variety of ways
including:

* User error

* Hardware failure

* Software failure

* Disasters

* Application errors

To protect your database, you will need to know how to back it up and you will need to know
how to recover your database. Backup and recovery is what this last chapter is all about. Backup
and recovery can be a very difficult and complex topic, for there are a number of different
options for you to choose from when it comes to backing up a database. In this chapter, we aim
to set you on the right course, showing you how to perform basic database backup and recovery
operations.

In this chapter we will use the Oracle RMAN tool. It comes with the Oracle RDBMS and it’s
free. In this chapter we will cover:

* Backing up your database with RMAN

* Restoring your database with RMAN

So, without further delay, let’s get started on getting your database backed up.

Backup Your Database with RMAN

Database backups with RMAN are actually quite easy. Your database can be in one of two
modes, ARCHIVELOG or NOARCHIVELOG mode. The mode your database is in determines
what kinds of backups you can perform on your database. In this section we will cover the
following topics:

Starting RMAN
The RMAN client is started from the operating system prompt. To use RMAN, simply set the
Oracle environment as you would before you use any other Oracle client (like SQL*Plus). Once
the environment is set, then you start RMAN as seen in this example:
rman target=/

Once you have started RMAN you will find yourself at the RMAN prompt. We are then ready to
begin our database backup.

Perform an Offline (Cold) Backup of your Database with

RMAN
In this section we will show you how to perform an offline (or cold) backup using RMAN. This
will require that the database be down (that’s why it’s called an offline backup). Oracle supports
online backups also, and we will be covering these shortly.

Before we can use RMAN we need to configure a few settings. In this section we will look at
configuring the database for our backup, and then we will proceed to do the backup.

Configure Oracle and RMAN for Backup

Before we can use RMAN we will need to configure a few settings. In this section we will
assume:

1. That you will be backing up to a file system called /u01/app/oracle/backup. You will need to
create this file system if it does not already exist.

2. That you are using an SPFILE.

Note that if you created your database as we described earlier in the book, you should already be
using an SPFILE.

The configuration is pretty basic. First, we need to configure a couple of database parameters.
These parameters will configure the Flash Recovery Area of the database.

This is the location that all the disk backups will be made to. To configure the flash recovery
area we will use the alter system command to set the value of two database parameters:

* db_recovery_file_dest – Determines the location of the flash recovery area.

* db_recovery_file_dest_size – Determines how much space can be used by Oracle in the flash
recovery area.

We will configure the flash recovery area to the value of /u01/app/oracle/backup, and we will
assign it a 2 Gigabyte limit.   Note!  Oracle flash recovery area re-named to fast recovery area

You may need to assign your flash recovery area more space depending on the following factors:

* The size of your database

* The number of backups you want to keep

* If you are running your database in ARCHIVELOG mode (which we will discuss later in this
chapter).

Here is an example of configuring the flash recovery area for the settlings listed previously. This
assumes your database is using a SPFILE which we discussed in earlier chapters:
Alter system set db_recovery_file_dest=’/u01/app/oracle/backup’;

Alter system set db_recovery_file_dest_size=2G;

We will also want to set a couple of RMAN settings before we do our first backup. Start RMAN
as detailed earlier in this section with:

$ rman target /

Now, we want to configure the following:

* Automatic backups of the control file and SPFILE.

* Retention policy to a redundancy of 2

Next, we can use the RMAN configure command to configure these settings as seen in this
example:
-- Configure the retention policy to redundancy of 2.
-- This means RMAN will try to keep 2 copies of the database backups.
 
RMAN> configure retention policy to redundancy 2;
 
-- Configure automated backups of the control file and SPFILE.
 
RMAN>configure controlfile autobackup on;

Now that RMAN and the database are configured, we are ready to proceed to backup the
database.

Also, see my notes on the different backup types and the differences between incremental
cumulative and incremental differential backups.

             Oracle 10g New Features: Flashback and RMAN

Oracle 10g New Features: Flashback and RMAN,

from the bestselling Oracle10g book Oracle Database 10g New Features by Mike Ault,
Madhu Tumma and Daniel Liu, published by Rampant TechPress.

Two improvements have been made in the backup and recovery areas in Oracle 10g. When
user errors and logical corruptions occur in the database, flashback functionalities provide
fast and flexible data recovery. When physical or media corruption occurs in the database,
RMAN delivers an improved and simplified recovery method.

Here is a list of extended flashback features:

Flashback Database - This feature introduces the FLASHBACK DATABASE statement

in SQL. It allows you to quickly bring your database to a prior point in time by undoing all
of the changes that have taken place since that time. This operation is fast, because you do
not need to restore the backups. This results in much less downtime following data
corruption or human error.

Flashback Standby Database - This feature improves the switchover and failover time
of a standby database. You no longer need to specify a log apply delay, because you can
now roll back the standby database if an error occurs on the primary and is propagated to
the standby.

Flashback Reinstantiation - This feature reduces the need to reinstantiate the old
primary database following a failover. This in turn lets you restore full resiliency after a
failure more quickly. You can do this by using the SQL statement FLASHBACK
DATABASE to roll back the primary database in time to synchronize with the standby
database.

Flashback Drop - Oracle now provides a way to restore tables that were dropped
accidentally.

Flashback Table - This feature introduces the FLASHBACK TABLE statement in SQL,
which lets you quickly recover a table to a previous point in time without restoring a
backup.

Flashback Row History - Using undo data stored in the database, you can now view
the changes to one or more rows along with all the metadata of the changes.

Flashback Transaction History - This feature lets you examine changes to the
database at the transaction level. With flashback transaction history, you can diagnose
problems, perform analysis, and audit transactions.

Here is a list of enhanced RMAN features:

Automated Channel Failover for Backup and Restore - Recovery Manager

(RMAN) now automatically retries a failed backup or restore operation, reducing the risk
of stranding you without a backup of the Oracle database because of an error.

Automated File Creation During Recovery - This feature enhances RMAN recovery
by automatically creating and recovering datafiles that have never been backed up.

Simplified Backups to Disk - Image backups provide fast recovery by being readily
usable. The Recovery Manager (RMAN) BACKUP command has been enhanced to
perform image copy backups at the database, tablespace, and datafile level.

Proxy Copy Backup of Archivelogs - You can now back up archive logs by using the
Recovery Manager (RMAN) Proxy Copy.

Incrementally Updated Backups - You can now apply a Recovery Manager (RMAN)
incremental backup to a datafile image backup. This results in reduced recovery time,
because fewer logs need to be applied, and reduced time to back up the database, because
you do not always have to back up the whole database.

Simplified Recovery Through Resetlogs - You no longer have to backup your

database following an incomplete recovery or an OPEN RESETLOGS operation. This is an
enabling feature for Flashback Reinstantiation.

Full Database Begin Backup Command - It is no longer necessary to issue a separate

command to place each tablespace in hot backup mode. You can now use the ALTER
DATABASE statement to place all tablespaces in backup mode. Also, the BEGIN BACKUP
command now runs faster than before.

Changes to the ALTER DATABASE END BACKUP Command - You can issue the
ALTER DATABASE END BACKUP command when the database is open.

Change-Aware Incremental Backups - By using a new type of log file to track blocks
that have changed in the database, Recovery Manager (RMAN) can avoid scanning the
entire datafile during an incremental backup. Instead, the amount of data scanned is
proportional to the amount of data changed.

Automated Disk-Based Backup and Recovery - This release supports automated

disk-based backup and recovery. The result is a simplified and unified storage location for
backups, archivelogs, and any other files needed for Oracle recovery. It also provides
automatic deletion of the files after they have been successfully backed up by RMAN, and
the equivalent of a disk cache for tape, which reduces the time needed to restore a file
from tape. It reduces the risk of an out-of-space condition on disk by deleting files that are
no longer necessary for successful database recovery.

RMAN Database Dropping and Deregistration - The new DROP DATABASE and
UNREGISTER DATABASE RMAN commands remove the database and its entry from the
RMAN recovery catalog.

Automated TSPITR Instantiation - This feature automatically creates the auxiliary

instance needed to perform tablespace point-in-time recovery (TSPITR) and incorporates
the RMAN TSPITR operations.

Simplified Recovery Manager Cataloging of Backup Files - You can now catalog
RMAN proprietary backup metadata into a backup repository. If a backup is overwritten
in the control file, or a backup file is moved to a new location on disk, then you can easily
uncatalog the backup metadata from the repository.

Extended Flashback Functions

In Oracle 10g, the flashback functionality has been greatly extended.

Flashback Database

Flashback Database is faster than traditional point-in-time recovery. Traditional recovery

uses redo log files and backups. Flashback Database is implemented using a new type of
log file called Flashback Database logs. The Oracle database server periodically logs before
images of data blocks in the Flashback Database logs. The data block images are used to
quickly back out changes to the database during Flashback Database.

Flashback Database reduces the time required to recover the database to a previous point.
The time to restore a database is proportional to the number of changes that need to be
backed out, not the size of the database.

RVWR Background Process

When Flashback Database is enabled, a new RVWR background process is started. This
process is similar to the LGWR (log writer) process. The new process writes Flashback
Database data to the Flashback Database logs.
Figure 12.1 RVWR Background process and Flashback Database Logs

The list below shows all the background processes for the 'grid' instance.

$ ps -ef | grep grid

  oracle 25124     1  0 16:32:05 ?        0:00 ora_s000_grid
  oracle 25116     1  0 16:32:04 ?        0:00 ora_reco_grid
  oracle 25169     1  0 16:32:22 ?        0:00 ora_rvwr_grid
  oracle 25112     1  0 16:32:04 ?        0:00 ora_ckpt_grid
  oracle 25110     1  0 16:32:04 ?        0:00 ora_lgwr_grid
  oracle 25108     1  0 16:32:04 ?        0:00 ora_dbw0_grid
  oracle 25114     1  0 16:32:04 ?        0:00 ora_smon_grid
  oracle 25118     1  0 16:32:04 ?        0:00 ora_cjq0_grid
  oracle 25120     1  0 16:32:04 ?        0:00 ora_rbal_grid
  oracle 25122     1  0 16:32:04 ?        0:00 ora_d000_grid
  oracle 25106     1  0 16:32:04 ?        0:00 ora_pmon_grid

Enabling Flashback Database

You can enable Flashback Database using the following steps:

1. Make sure the database is in archive mode.

2. Configure the recovery area by setting the two parameters:
- db_recovery_file_dest
- db_recovery_file_dest_size
3. Open the database in MOUNT EXCLUSIVE mode and turn on the flashback feature:
4.         SQL> STARTUP MOUNT EXCLUSIVE;
SQL> ALTER DATABASE FLASHBACK ON;

5. Set the Flashback Database retention target:

- db_flashback_retention_target
6. Determine if Flashback Database is enabled:

7.         SQL> select flashback_on

8.               2  from   v$database;
9.             
10.          FLASHBACK_ON
11.          ------------
    YES

Disabling Flashback Database

Issue the following command to disable Flashback Database:

SQL> ALTER DATABASE FLASHBACK OFF;

You can also perform the same task in Enterprise Manger:

Figure 12.2 Disabling Flashback Database in Enterprise Manager

Monitoring Flashback Database

The following displays a selection of the Flashback Database logs:

SQL> select begin_time, flashback_data,

   2        db_data, redo_data, ESTIMATED_FLASHBACK_SIZE
   3 from   v$flashback_database_stat;
 

BEGIN_TIME           FLASHBACK_DATA    DB_DATA  REDO_DATA ESTIMATED_FLASHBACK_SIZE

-------------------- -------------- ---------- ---------- ------------------------

Oct 08 2003 14:17:34         753664    5324800       970752                              0
Oct 08 2003 13:17:32        1720320    4751360     3124224                      21749760
Oct 08 2003 12:17:31        1802240    4833280     3168256                      21774336
Oct 08 2003 11:17:28        1867776    4587520     3146752                     21774336
Oct 08 2003 10:17:24        1835008    4800512     3115008                      21749760
Oct 08 2003 09:17:22        1785856    4702208     3120128                      21749760
Oct 08 2003 08:17:17        1703936    4571136     3102720                      21749760
Oct 08 2003 07:17:14        2768896    5767168     3237888                      21798912
Oct 08 2003 06:17:11        1753088    4636672     3142656                      21479424
Oct 08 2003 04:47:09        2686976    7143424     4862976                      21479424
Oct 08 2003 03:47:05        1703936    4685824     3145728                      21479424
Oct 08 2003 02:46:57        1785856    4653056     3137536                      21528576
Oct 08 2003 01:46:52        1785856    4620288     3107840                      21528576
Oct 08 2003 00:46:47        1769472    4964352     3245056                      21528576
Oct 07 2003 23:46:44        1720320    4587520     3130368                      21528576
Oct 07 2003 22:46:40        1769472    4669440     3112960                      21577728
Oct 07 2003 21:46:38        1703936    4800512     3161088                      21577728
Oct 07 2003 20:46:35        1785856    4653056     3155968                      21626880
Oct 07 2003 19:46:30        1802240    4784128     3164160                      21651456
Oct 07 2003 18:46:28        1753088    4685824     3120128                      21528576
Oct 07 2003 17:46:26        1687552    4718592     3143680                      21553152
Oct 07 2003 16:46:24        1851392    4603904     3120128                      21577728
Oct 07 2003 15:46:21        1720320    4816896     3154944                      21577728
Oct 07 2003 14:46:18        1736704    4587520     3196928                      21577728
Oct 07 2003 13:46:16        1736704    4685824     3194880                      21602304
 
 

25 rows selected.

You can use the v$flashback_database_log to monitor the Flashback Database retention
target.

SQL> select *
   2 from   v$flashback_database_log;
 

OLDEST_FLASHBACK_SCN OLDEST_FLASHBACK_TIME RETENTION_TARGET FLASHBACK_SIZE EST_FLASHBACK_SIZE

-------------------- --------------------- ---------------- -------------- ------------------

          2.2029E+12 Oct 06 2003 09:44:42             1440       48316416           21774336

Note: The default flashback retention time is 1400 minutes.

You can also use the v$flashback_database_log view to assist in adjusting the recovery
area disk quota:

SQL> select estimated_flashback_size

   2 from   v$flashback_database_log;
 

ESTIMATED_FLASHBACK_SIZE

------------------------

                21823488

Example 1: Flashback a Database using RMAN

RMAN> FLASHBACK DATABASE

   2> TO TIME = TO_DATE
   3> ('06/25/03 12:00:00','MM/DD/YY HH:MI:SS');

Example 2: Flashback a database using SQL command

The database must be in mount state to issue these commands:

SQL> FLASHBACK DATABASE TO TIMESTAMP (SYSDATE - 5/24);

SQL> FLASHBACK DATABASE TO SCN 76239;

You must issue the following command afterwards:

SQL> ALTER DATABASE RESETLOGS;

Flashback Standby Database

If you have multiple standby sites, you may utilize the DELAY option in Data Guard to
prevent physical/logical corruption or user errors in your primary database.
For example, the first scenario in the diagram below has only one standby database. Here,
a logical or physical corruption in the primary database will cause an immediate
corruption in the standby database.

To avoid such a pitfall, you can implement a second standby database with the 'Delay'
option (introducing a delay of minutes or hours on the second standby database for
applying archive log changes). This will prevent the corruptions on the second standby
database and allow recovery from a possible physical/logical corruption or user errors in
the primary database.

You can issue the following command to accomplish this:

SQL> alter database recover managed standby database delay 60 disconnect;

Figure 12.3 Using Flashback Database in a Standby Database Configuration

However, in Oracle 10g, you can configure the standby database with Flashback Database
to achieve the same benefit as the DELAY option. Therefore, there is no need to
implement a second standby database with the DELAY option.
Flashback Re-instantiation

In an Oracle9i Data Guard environment, a failover operation leads to a resetlogs. This

operation invalidates the old primary database. Therefore, you need to perform a hot
backup on the new primary database immediately, and then re-create a new standby
database. This operation can take a long time, and your new primary database is
vulnerable during this period.

The new Flashback Re-instantiation feature reduces the need to reinstantiate the old
primary database following a failover. This feature allows you to quickly restore full
resiliency after a failure. This is accomplished by using the SQL statement FLASHBACK
DATABASE to roll back the old primary database in time to synchronize with the old
standby database.

Figure 12.4 Flashback Re-instantiation of Standby Database

Here are the steps to perform Flashback Re-instantiation:

1. On your new primary database (Instance B): SQL> select standby_became_primary_scn

from v$database;
 STANDBY_BECAME_P
----------------
2960985

2. Mount the old primary database (Instance A).

SQL> STARTUP MOUNT
3. Flashback the old primary database (Instance A) to the SCN.
SQL> flashback database to scn 2960985;
4. Disable Flashback on the old primary database (Instance A).
SQL> ALTER DATABASE FLASHBACK OFF;
5. On the old primary database (Instance A), create a standby control file.
SQL> alter database create standby controlfile
as'/dba/standby/stbycf.f' reuse;
6. Shutdown the old primary database (Instance A), and replace the control files with the new
standby control files.
SQL> shutdown immediate;
$ cp /dba/standby/stbyct.f /u02/oradata/sid/control01.ctl
$ cp /dba/standby/stbyct.f /u02/oradata/sid/control02.ctl
7. Bring up the old primary database as a new physical standby database (Instance A).
SQL> startup mount;
8. Turn flashback back on the new primary database (Instance A).
SQL> alter database flashback on;
9. Enable transport from the new primary database (Instance B)
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_1=ENABLE;
10. On the new standby database (Instance A), start real time apply.
SQL> RECOVER MANAGED STANDBY DATABASE using current logfile DISCONNECT;
11. The Managed Recovery process (MRP) will hit the End-Of-Redo and then need to be
restarted.
SQL> RECOVER MANAGED STANDBY DATABASE using current logfile DISCONNECT;

Flashback Drop

Prior to Oracle 10g, a DROP command permanently removed objects from the database.
In Oracle 10g, a DROP command places the object in the recycle bin. The extents allocated
to the segment are not reallocated until you purge the object. You can restore the object
from the recycle bin at any time.

This feature eliminates the need to perform a point-in-time recovery operation. Therefore,
it has minimum impact to other database users.

Recycle Bin

A recycle bin contains all the dropped database objects until,

- You permanently drop them with the PURGE command.

- Recover the dropped objects with the UNDROP command.
- There is no room in the tablespace for new rows or updates to existing rows.
- The tablespace needs to be extended.

You can view the dropped objects in the recycle bin from two dictionary views:

- user_recyclebin - lists all dropped user objects

- dba_recyclebin - lists all dropped system-wide objects

Example 1: Dropping an Object

In the example below, the name of the object is changed when it is dropped and moved to
the recycle bin. The recycle bin also keeps the original name of the object. This feature
allows you to create a new object of the same name and then drop it again.

SQL> create table test (col_a varchar(4));

 
Table created.
 
 
SQL> select object_name, original_name, type
     from   user_recyclebin;
 
 
no rows selected
 
 
SQL> drop table test;
 
 
Table dropped.
 
 
SQL> select object_name, original_name, type
     from   user_recyclebin;
 
 
OBJECT_NAME                ORIGINAL_NAME       TYPE
------------------------ ----------------   ------------------
RB$$42513$TABLE$0         TEST                 TABLE
 
 

SQL> create table test (col_b varchar(4));

Table created.
 
 
SQL> select object_name, original_name, type
     from   user_recyclebin;
 
 
OBJECT_NAME                ORIGINAL_NAME       TYPE
------------------------ ----------------   ------------------
RB$$42513$TABLE$0         TEST                 TABLE
 
 

SQL> drop table test;

Table dropped.
 
 
SQL> select object_name, original_name, type from user_recyclebin;
OBJECT_NAME                ORIGINAL_NAME       TYPE
------------------------ ----------------   ------------------
RB$$42513$TABLE$0         TEST                 TABLE
RB$$42514$TABLE$0         TEST                 TABLE

Example 2: Restoring a Dropped Object

This example will restore a dropped table test.

SQL> flashback table RB$$42514$TABLE$0 to before drop;

 

Flashback complete.
Example 3: Dropping a Table Permanently

This statement puts the table in the recycle bin:

SQL> drop table test purge;

This statement removes the table permanently:

SQL> purge table RB$$42514$TABLE$0;

Table purged.

Example 4: Dropping a Tablespace

You can only issue this command when the tablespace users is empty. Objects in the
recycle bin of tablespace users will be purged:

SQL> drop tablespace users;

When you issue this command, objects in the tablespace users are dropped. They are not
placed in the recycle bin. Any objects in the recycle bin belonging to the tablespace users
are purged.

SQL> drop tablespace users including contents;

Example 5: Purging the Recycle Bin

This statement purges the user recycle bin:

SQL> purge recyclebin;

 

Recyclebin purged.

This statement removes all objects from the recycle bin:

SQL> purge dba_recyclebin;

 
DBA Recyclebin purged.

This statement purges all objects from tablespace users in the recycle bin:

SQL> purge tablespace users;

 

Tablespace purged.

Flashback Table

Flashback Table allows you to recover a table or tables to a specific point in time without
restoring a backup. When you use the Flashback Table feature to restore a table to a
specific point in time, all associated objects, such as indexes, constraints, and triggers will
be restored.

Flashback Table operations are not valid for the following object types:

- Tables that are part of a cluster

- Materialized views
- Advanced Queuing tables
- Static data dictionary tables
- System tables
- Partitions of a table
- Remote tables (via database link)

Flashback Table is extremely useful when a user accidentally inserts, deletes, or updates
the wrong rows in a table. It provides a way for users to easily and quickly recover a table
to a previous point in time.

However, if the following DDL commands are issued, the flashback table command does
not work:

- ALTER TABLE ... DROP COLUMN

- ALTER TABLE ... DROP PARTITION
- CREATE CLUSTER
- TRUNCATE TABLE
- ALTER TABLE ... MOVE

undo_retention Parameter

Data used to recover a table is stored in the undo tablespace. You can use the parameter
undo_retention to set the amount of time you want undo information retained in the
database.

To create an undo tablespace with the RETENTION GUARANTEE option, issue the
following command:

CREATE UNDO TABLEAPCE undo_tbs

DATAFIEL '/u02/oradata/grid/undo_tbs01.dbf' SIZE 1 G
RETENTION GUARANTEE;

Guaranteed Retention

When an active transaction uses all the available undo tablespace, the system will start
reusing undo space that would have been retained, unless you have specified RETENTION
GUARANTEE for the tablespace.

Flashback Table Privileges

You must have the FLASHBACK TABLE or FLASHBACK ANY TABLE system privilege to
use the Flashback Table feature.

Example 1: Flashback Table using SCN

This statement brings a table 'billing' back to a certain SCN number; table row movement
must be enabled as a prerequisite:

SQL> FLASHBACK TABLE billing TO SCN 76230;

Example 2: Flashback Table using TIMESTAMP

This statement brings a table 'billing' back to a certain timestamp:

SQL> FLASHBACK TABLE billing

     TO TIMESTAMP
     TO_TIMESTAMP('06/25/03 12:00:00','MM/DD/YY HH:MI:SS');

Flashback Row History

Flashback Query was first introduced in Oracle9i to provide a way to view historical data.
In Oracle 10g, this feature has been extended. You can now retrieve all versions of the
rows that exist or ever existed between the time the query was issued and a point back in
time. This type of query is called Flashback Row History.

You can use the VERSIONS BETWEEN clauses to retrieve all historical data related to a
row.

Let's take a look at the example below:

SQL> create table emp (name   varchar2(10),

                          salary number(8,2));
 
Table created.
 
 
SQL> insert into emp
     values ('DANIEL',2000);
 
 
1 row created.
 
 
SQL> commit;
 
 
Commit complete.
 
 
SQL> update emp set salary = 3000
     where  name = 'DANIEL';
 
 
1 row updated.
 
 
SQL> commit;
 
 
Commit complete.
 
 
SQL> select * from emp;
 
 
NAME             SALARY
---------- ----------
DANIEL            3000
 
 
SQL> select *
     from   emp
     versions between scn minvalue and maxvalue;
 
 
NAME             SALARY
---------- ----------
DANIEL            3000
DANIEL            2000

As you can see, the Flashback Row History feature retrieves all committed occurrences of
the row. It provides you with a way to view and repair historical data. In addition, it also
provides a new way to audit the rows of a table and retrieve information about the
transactions that changed the rows. You can use the transaction ID obtained from
Flashback Row History to perform transaction mining using LogMiner or Flashback
Transaction History (see next section) to obtain additional information about the
transaction.

The VERSION BETWEEN clause does not change the query plan. You can use the clause
in a SELECT statement against a view. However, you cannot use the VERSION BETWEEN
clause in a view definition.

The row history data is stored in the undo tablespace. The undo_retention initialization
parameter specifies how long the database will keep the committed undo information. If a
new transaction needs to use undo space and there is not enough free space left, any undo
information older than the specified undo retention period will be overwritten. Therefore,
you may not be able to see all the row histories. However, you can set the undo tablespace
option to RETENTION GUARANTEE to retain all row histories.

To verify the retention value for the tablespace, you can issue the following statement:

SQL> select tablespace_name, retention

  2  From   dba_tablespaces;
 
TABLESPACE_NAME                 RETENTION
------------------------------ -----------
SYSTEM                            NOT APPLY
UNDOTBS1                          NOGUARANTEE
SYSAUX                            NOT APPLY
TEMP                               NOT APPLY
EXAMPLE                           NOT APPLY
USERS                             NOT APPLY
 
 
6 rows selected.

Flashback Transaction History

The Flashback Transaction History feature provides a way to view changes made to the
database at the transaction level. It allows you to diagnose problems in your database and
perform analysis and audit transactions. You can use this feature in conjunction with the
Flash Row History feature to roll back the changes made by a transaction. You can also
use this feature to audit user and application transactions. The Flashback Transaction
History provides a faster way to undo a transaction than LogMiner.

You can retrieve the transaction history from dba_transaction_query view:

SQL> desc dba_transaction_query

Name                                 Null?    Type
------------------------------------ -------- ----------------
XID                                           RAW(8)
START_SCN                                     NUMBER
START_TIMESTAMP                               DATE
COMMIT_SCN                                    NUMBER
COMMIT_TIMESTAMP                              DATE
LOGON_USER                                    VARCHAR2(30)
UNDO_CHANGE#                                  NUMBER
 OPERATION                                     VARCHAR2(32)
TABLE_NAME                                    VARCHAR2(256)
TABLE_OWNER                                   VARCHAR2(32)
ROW_ID                                        VARCHAR2(19)
UNDO_SQL                                      VARCHAR2(4000)
 
SQL> select   versions_xid, name, salary       
  2  from      emp
  3  versions between scn minvalue and maxvalue;
 
 
VERSIONS_XID     NAME            SALARY
---------------- ---------- ----------
0003000E00000FE2 DANIEL           3000
                   DANIEL           2000
 
 
SQL> select *
  2  from   dba_transaction_query
  3  where  xid = '0003000E00000FE2';

The above is an excerpt from the bestselling Oracle10g book Oracle Database 10g New Features by
Mike Ault, Madhu Tumma and Daniel Liu, published by Rampant TechPress.

Mike Ault, one of the world's most widely-read Oracle experts, has finally consented to release his
complete collection of more than 450 Oracle scripts, covering every possible area of Oracle
administration and management.

This is the definitive collection of Oracle monitoring and tuning scripts, and it would take
thousands of hours to re-create this vast arsenal of scripts from scratch.

Mike has priced his collection of 465 scripts at $39.95, less than a dime per script. You can
download them immediately at this link:
http://www.rampant-books.com/download_adv_mon_tuning.htm