alphaspirit - Fotolia


Oracle RMAN case study: Improving backup and recovery efficiency

A case study showing how Oracle's RMAN improves backup and recovery efficiency in a multi-platform, multi-application environment

The National Business Center (NBC) provides business services to government agencies in the areas of Financial...

Management, Human Resources Management, Training, Acquisitions, Information Technology Hosting, Aviation Services, Appraisal Services, and other administrative areas. One of the top priority areas in the Information Technology Hosting unit at NBC is data protection and fast data retrieval in case of disk failure or disaster recovery.

The NBC's data center runs its Oracle databases on multiple platforms (z/OS, Sun Solaris, Linux) and utilizes various applications including SAP, Oracle Federal Financials, and other third party applications. Before the introduction of Oracle Recovery Manager (RMAN) in 2001, all the OLTP databases and data mart databases (total of ~3TB) on the mainframe and other platforms were being backed up using third party tools at the OS level. This case study describes how NBC implemented RMAN on all platforms, from UNIX/Linux to the mainframe, resulting in faster backups and reduced application downtime.

RMAN usage for Oracle Financials databases on Linux

While NBC uses SAP for its large clients, NBC's small clients' accounting operations and IT services are implemented using Oracle Federal Financials 11i (OFF). NBC uses RMAN to back up these databases running on Linux servers. Oracle Federal Financial databases are backed up using daily RMAN online backups via Tivoli Data Protection agents, which are installed on each server. While the backup/restore implementation for OFF is similar to FBMS, RMAN is also used to clone the OFF production databases. Using RMAN for this purpose has been a major time and labor saver versus manual cloning methods. Cloning is used to refresh test and QA servers from production for the purpose of testing patches, especially security-related patches.

The following advantages were realized using RMAN to clone databases versus manual methods:

  • RMAN restore is faster than using Tivoli tape restore operation at the OS level as RMAN only restores the blocks that have ever been used.
  • The clone database DBID is automatically changed at the end of the cloning operation.
  • The new clone database can be immediately registered in the catalog and backed up using RMAN.

The following steps are used to clone OFF databases:

  • TDPO.OPT file is changed to point to the source node in Tivoli.
  • Set DB_FILE_NAME_CONVERT, LOG_FILE_NAME_CONVERT parameters in the target database initialization file.
  • Connect to the RMAN catalog.
  • Connect to the target database.
  • Connect to the auxiliary instance in the no mount mode.
  • Run the following RMAN script:
run {
allocate auxiliary channel aux1 type 
'sbt_tape' parms 
'ENV=(DSMI_ORC_CONFIG=/opt/tivoli/tsm/client/oracle/ testdb/dsm.opt,
TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/testdb/ tdpo.opt)';
duplicate target database to TEST 
PFILE=/ora002/oracle/shrdev04db/9.2.0/dbs/ initTEST.ora;
  • Open and register the database in RMAN.
  • Create necessary tempfiles after this restore.
  • Register the database in Tivoli with the new node.
  • Change TDPO.OPT file with the new node.
  • Run a backup of the new database.

Read more about RMAN usage with SAP (Unix), data warehouses (Z/OS), and Data Guard here.

About the author

Rama Balaji is an Oracle Certified Professional and senior Oracle DBA at Infoteknow International, Inc.

Dig Deeper on Oracle database backup and recovery