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.
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
BEGIN_TIME
FLASHBACK_DATA
ESTIMATED_FLASHBACK_SIZE
DB_DATA
REDO_DATA
753664
5324800
970752
1720320
4751360
3124224
1802240
4833280
3168256
1867776
4587520
3146752
1835008
4800512
3115008
1785856
4702208
3120128
1703936
4571136
3102720
2768896
5767168
3237888
1753088
4636672
3142656
2686976
7143424
4862976
1703936
4685824
3145728
1785856
4653056
3137536
1785856
4620288
3107840
1769472
4964352
3245056
1720320
4587520
3130368
1769472
4669440
3112960
1703936
4800512
3161088
1785856
4653056
3155968
1802240
4784128
3164160
1753088
4685824
3120128
1687552
4718592
3143680
1851392
4603904
3120128
1720320
4816896
3154944
1736704
4587520
3196928
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;
1440
48316416
ESTIMATED_FLASHBACK_SIZE
------------------------
21823488
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.
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.
from
user_recyclebin;
no rows selected
Table dropped.
from
user_recyclebin;
OBJECT_NAME
ORIGINAL_NAME
TYPE
------------------------ ----------------
------------------
RB$$42513$TABLE$0
TABLE
TEST
Table created.
from
user_recyclebin;
OBJECT_NAME
ORIGINAL_NAME
TYPE
------------------------ ----------------
------------------
RB$$42513$TABLE$0
TABLE
TEST
Table dropped.
OBJECT_NAME
ORIGINAL_NAME
TYPE
------------------------ ----------------
------------------
RB$$42513$TABLE$0
TEST
TABLE
RB$$42514$TABLE$0
TEST
TABLE
Flashback complete.
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;
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;
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.
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.
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';