Oracle 10g New Features: Flashback and RMAN

Submitted by admin on Mon, 2004-04-26 01:00
articles: 
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 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: 
    SQL> STARTUP MOUNT EXCLUSIVE;
SQL> ALTER DATABASE FLASHBACK ON;
  4. Set the Flashback Database retention target:
    - db_flashback_retention_target
  5. Determine if Flashback Database is enabled: 
    SQL> select flashback_on
      2  from   v$database;
    
    FLASHBACK_ON
    ------------
    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 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 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 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.
»

Comments

Submitted by jayanta ghosh (not verified) on Tue, 2006-10-31 01:09.

This is an excelent document.

»
premkumar_gmca's picture

Submitted by premkumar_gmca on Wed, 2007-01-17 07:03.

its realy helps to know the new updations in oracle

thnk you

natalka and admin

»