Oracle 10g New Features: Flashback and

RMAN
Submitted by admin on Mon, 2004-04-26 00:00
RDBMS Server
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
oracle
oracle
oracle
oracle
oracle
oracle
oracle
oracle
oracle
oracle
oracle

| grep grid
25124
1
25116
1
25169
1
25112
1
25110
1
25108
1
25114
1
25118
1
25120
1
25122
1
25106
1

0
0
0
0
0
0
0
0
0
0
0

16:32:05
16:32:04
16:32:22
16:32:04
16:32:04
16:32:04
16:32:04
16:32:04
16:32:04
16:32:04
16:32:04

?
?
?
?
?
?
?
?
?
?
?

0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00
0:00

ora_s000_grid
ora_reco_grid
ora_rvwr_grid
ora_ckpt_grid
ora_lgwr_grid
ora_dbw0_grid
ora_smon_grid
ora_cjq0_grid
ora_rbal_grid
ora_d000_grid
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
ESTIMATED_FLASHBACK_SIZE

DB_DATA

REDO_DATA

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

Oct 08 2003 14:17:34

0

753664

5324800

970752

Oct 08 2003 13:17:32

21749760

1720320

4751360

3124224

Oct 08 2003 12:17:31

21774336

1802240

4833280

3168256

Oct 08 2003 11:17:28

21774336

1867776

4587520

3146752

Oct 08 2003 10:17:24

21749760

1835008

4800512

3115008

Oct 08 2003 09:17:22

21749760

1785856

4702208

3120128

Oct 08 2003 08:17:17

21749760

1703936

4571136

3102720

Oct 08 2003 07:17:14

21798912

2768896

5767168

3237888

Oct 08 2003 06:17:11

21479424

1753088

4636672

3142656

Oct 08 2003 04:47:09

21479424

2686976

7143424

4862976

Oct 08 2003 03:47:05

21479424

1703936

4685824

3145728

Oct 08 2003 02:46:57

21528576

1785856

4653056

3137536

Oct 08 2003 01:46:52

21528576

1785856

4620288

3107840

Oct 08 2003 00:46:47

21528576

1769472

4964352

3245056

Oct 07 2003 23:46:44

21528576

1720320

4587520

3130368

Oct 07 2003 22:46:40

21577728

1769472

4669440

3112960

Oct 07 2003 21:46:38

21577728

1703936

4800512

3161088

Oct 07 2003 20:46:35

21626880

1785856

4653056

3155968

Oct 07 2003 19:46:30

21651456

1802240

4784128

3164160

Oct 07 2003 18:46:28

21528576

1753088

4685824

3120128

Oct 07 2003 17:46:26

21553152

1687552

4718592

3143680

Oct 07 2003 16:46:24

21577728

1851392

4603904

3120128

Oct 07 2003 15:46:21

21577728

1720320

4816896

3154944

Oct 07 2003 14:46:18

21577728

1736704

4587520

3196928

Oct 07 2003 13:46:16

21602304

1736704

4685824

3194880

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

21774336

1440

48316416

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

TABLE

TEST

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

TABLE

TEST

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
-----------------------------SYSTEM
UNDOTBS1
SYSAUX
TEMP
EXAMPLE
USERS

RETENTION
----------NOT APPLY
NOGUARANTEE
NOT APPLY
NOT APPLY
NOT APPLY
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?
------------------------------------ -------XID
START_SCN
START_TIMESTAMP
COMMIT_SCN
COMMIT_TIMESTAMP
LOGON_USER
UNDO_CHANGE#
OPERATION
TABLE_NAME
TABLE_OWNER
ROW_ID
UNDO_SQL

Type
---------------RAW(8)
NUMBER
DATE
NUMBER
DATE
VARCHAR2(30)
NUMBER
VARCHAR2(32)
VARCHAR2(256)
VARCHAR2(32)
VARCHAR2(19)
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';