HP 3PAR Recovery Manager 4.3.0 Software for Oracle
User Guide
Abstract
This document provides the information needed to install, configure, and use the HP 3PAR Recovery Manager 4.3.0 Software
for Oracle on Solaris, Red Hat Linux, Oracle Linux, and HP UX. This document is for system administrators and database
administrators who are responsible for backing up databases and who understand Sun™ Solaris™ and/or Linux and/or HP
UX, and are familiar with the Oracle10g™ and Oracle11g™ Databases.
HP Part Number: QL226-96659
Published: November 2012
© Copyright 2012 Hewlett-Packard Development Company, L.P.
Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial
Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under
vendor's standard commercial license.
The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express
warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall
not be liable for technical or editorial errors or omissions contained herein.
Acknowledgements
Intel®, Itanium®, Pentium®, Intel Inside®, and the Intel Inside logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries
in the United States and other countries.
Microsoft, Windows, Windows 2000, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation.
Java and Oracle are registered trademarks of Oracle and/or its affiliates.
UNIX® is a registered trademark of The Open Group.
All other trademarks and registered trademarks are owned by their respective owners.
Contents
1 Overview of Recovery Manager Operations..................................................7
Virtual Copies..........................................................................................................................7
About the Recovery Manager for Oracle Repository......................................................................7
Interacting with Oracle..............................................................................................................8
Interacting with Symantec NetBackup and Oracle RMAN..............................................................9
Recovery Manager for Oracle Utilities.......................................................................................10
The Database Configuration Utility.......................................................................................10
The Virtual Copy Creation Utility..........................................................................................10
The Virtual Copy Display Utility...........................................................................................12
The Virtual Copy Mount Utility.............................................................................................12
The Virtual Copy Unmount Utility.........................................................................................13
The Virtual Copy Export Utility.............................................................................................14
The Database Cloning Utility...............................................................................................14
The Cloned Database Removal Utility...................................................................................15
The Virtual Copy Removal Utility..........................................................................................15
Integration with HP 3PAR Virtual Lock Software......................................................................16
The Virtual Copy Repository.....................................................................................................16
The Virtual Copy Repository Removal Utility...........................................................................16
Virtual Copy Policy.................................................................................................................16
Database Rollback from a Virtual Copy.....................................................................................17
The Database Rollback Utility..............................................................................................17
Recovery Manager for Oracle and Third-Party Backup Tools.........................................................17
The Database Backup Utility................................................................................................18
Immediate Backup.........................................................................................................18
Automatic Backup.........................................................................................................19
The Database Restoration Utility...........................................................................................20
Recovery Manager for Oracle with Oracle Standby Database......................................................21
Recovery Manager for Oracle and Autonomic Groups.................................................................21
Recovery Manager for Oracle and Domain Sets....................................................................21
Recovery Manager for Oracle and Host Sets.........................................................................22
Recovery Manager for Oracle and Virtual Volume Sets...........................................................22
Recovery Manager for Oracle with Remote Copy........................................................................22
Recovery Manager for Oracle and Peer Motion..........................................................................22
Preparing Recovery Manager for Oracle for Peer Motion Data Migration..................................22
Recovery Manager for Oracle and Fat-to-Thin and Thin-to-Fat.......................................................23
Converting Virtual Volumes.................................................................................................23
2 Installing and Uninstalling Recovery Manager..............................................24
Referencing the Support Matrix.................................................................................................24
Preinstallation Requirements.....................................................................................................24
Installing Recovery Manager for Oracle on Linux Systems.............................................................25
Installation........................................................................................................................26
Verifying Installation...........................................................................................................27
Removing Recovery Manager from Linux Systems........................................................................27
Installing Recovery Manager on Solaris Systems.........................................................................27
Installation........................................................................................................................28
Verifying Installation...........................................................................................................28
Removing Recovery Manager from Solaris Systems......................................................................28
Installing Recovery Manager for Oracle on HP UX Systems..........................................................29
Installation........................................................................................................................29
Verifying Installation...........................................................................................................30
Removing Recovery Manager from HP UX Systems.................................................................30
Contents 3
3 Configuring Recovery Manager for Oracle..................................................31
Setting Up SSH Connections for Recovery Manager....................................................................31
SSH Restrictions.................................................................................................................32
Modifying the SSH Daemon Configuration............................................................................32
Generating an SSH Key Pair for the Backup Server.................................................................33
Generating an SSH Key Pair for the Database Server..............................................................33
Setting Up Connections from the Backup Server to the Database Server....................................34
Verifying Connections from the Backup Server to the Database Server.......................................34
Setting Up Connections from the Backup Server to the NetBackup Master Server........................34
Verifying Connections from the Backup Server to the NetBackup Master Server..........................34
Setting Up Connections from the Backup Server to the HP 3PAR Storage System.........................35
Verifying Connections from the Backup Server to the HP 3PAR Storage System...........................36
Setting Connections from the Database Server to the HP 3PAR Storage System...........................37
Verifying Connections from the Database Server to the HP 3PAR Storage System........................38
Setting up National Language Host Support...............................................................................39
Setting up Manual Pages on Database and Backup Servers.........................................................39
Setting up a Search Path on Database and Backup Servers..........................................................39
Setting Up NetBackup Policies for NBU (User-Managed) Backup...................................................39
Configuring the NetBackup Policy for Database Backup..........................................................40
Configuring the NetBackup Policy for Archive Log Backup.......................................................40
Setting Up NetBackup Configuration Parameters for the Backup Server.....................................40
Setting Up NetBackup Configuration Parameters for the Database Server..................................41
Setting Up NetBackup Policies for Oracle RMAN Backup.............................................................41
Configuring the NetBackup Policy for Database Backup with RMAN.........................................41
Configuring the NetBackup Policy for Archive Log Backup.......................................................42
Creating an RMAN Recovery Catalog..................................................................................42
Recovery Manager for Oracle Configuration Files.......................................................................44
Creating a Recovery Manager for Oracle Configuration File without Remote Copy.....................44
Creating Configuration Files Using the Command Line Interface on the Backup Server............44
Creating a Recovery Manager for Oracle Configuration File using the GUI on the backup
server..........................................................................................................................48
Creating a Recovery Manager for Oracle Configuration File for Remote Copy Configuration.......49
Creating a Recovery Manager for Oracle Configuration File Using the Command Line
Interface......................................................................................................................49
Creating a Recovery Manager for Oracle Configuration File using the GUI...........................52
4 Using the Recovery Manager Command Line Interface..................................54
Recovery Manager Commands................................................................................................54
rmora_backup...................................................................................................................54
rmora_checkconfig.............................................................................................................58
rmora_chown....................................................................................................................58
rmora_config.....................................................................................................................60
rmora_create.....................................................................................................................63
rmora_createdb ................................................................................................................66
rmora_display...................................................................................................................68
rmora_export....................................................................................................................70
rmora_mount.....................................................................................................................72
rmora_remove...................................................................................................................74
rmora_removedb...............................................................................................................75
rmora_restore....................................................................................................................76
rmora_rmrep.....................................................................................................................79
rmora_rollback..................................................................................................................80
rmora_rsync......................................................................................................................82
rmora_set.........................................................................................................................85
rmora_umount...................................................................................................................87
4 Contents
5 Using the Recovery Manager for Oracle Graphical User Interface..................88
Starting and Stopping the Recovery Manager for Oracle GUI......................................................88
Starting the GUI................................................................................................................88
Stopping the GUI...............................................................................................................89
Creating Configuration Files.....................................................................................................89
Modifying Configuration Files...................................................................................................89
Removing Configuration Files...................................................................................................89
Configuring Email...................................................................................................................89
Creating a Virtual Copy..........................................................................................................89
Setting up a Time-Based Virtual Copy Policy...............................................................................90
Setting up a Numeric-Based Virtual Copy Policy..........................................................................91
Extending Virtual Copy Expiration and Retention Time.................................................................92
Refreshing Virtual Copy Information..........................................................................................92
Mounting a Virtual Copy.........................................................................................................93
Unmounting a Virtual Copy......................................................................................................93
Rolling Back Using a Virtual Copy............................................................................................93
Viewing Rollback Status......................................................................................................94
Removing a Virtual Copy.........................................................................................................94
Backing up a Virtual Copy.......................................................................................................94
Removing a Virtual Copy Repository.........................................................................................94
Restoring Archive Log, Datafiles, and Tablespaces.......................................................................95
Refreshing Database Information..............................................................................................95
Exporting a Virtual Copy to an Alternate Backup Server..............................................................95
Cloning a Database................................................................................................................95
Removing a Cloned Database.............................................................................................96
Periodic Database Synchronization............................................................................................96
Starting Periodic Synchronization.........................................................................................96
Verifying the Periodic Synchronization Process........................................................................97
Refreshing Remote Copy Information.....................................................................................97
Backing Up a Database..........................................................................................................97
Using the Task Manager..........................................................................................................98
Viewing Event Messages..........................................................................................................98
Viewing Online Help..............................................................................................................98
Using a Web Browser to Access Online Help and Event Messages...............................................99
Additional Information about the Recovery Manager for Oracle GUI.............................................99
RAC Databases.................................................................................................................99
Standby Databases............................................................................................................99
6 Using the Recovery Manager Rollback Utility.............................................100
rmora_rollback Usage...........................................................................................................100
Rollback Using a Database Read-Only Virtual Copy.............................................................100
Rollback Using a Database Read-Write Virtual Copy............................................................101
7 Using Remote Copy with Recovery Manager..............................................103
Overview............................................................................................................................103
Recovery Manager for Oracle’s Remote Copy Requirements..................................................103
How Remote Copy Works......................................................................................................104
Creating Virtual Copies.........................................................................................................106
8 Support and Other Resources...................................................................107
Contacting HP......................................................................................................................107
HP 3PAR documentation........................................................................................................107
Typographic conventions.......................................................................................................110
HP 3PAR branding information...............................................................................................110
Contents 5
9 Documentation feedback.........................................................................111
A Case Study: Remote Copy with Recovery Manager for Oracle......................112
Introduction..........................................................................................................................112
Systems and Software Configurations......................................................................................112
Configuration Diagram.....................................................................................................113
Preparing for Remote Copy Operation.....................................................................................113
Recovering to the Synchronous Backup System when the Local System is Unavailable.....................115
Recovering to the Asynchronous Periodic Backup System when the Local and Synchronous Backup
Systems are Unavailable........................................................................................................126
B Troubleshooting......................................................................................140
Index.......................................................................................................198
6 Contents
1 Overview of Recovery Manager Operations
Recovery Manager for Oracle offers a specific data protection solution that has been enhanced
to provide rapid online recovery from space-efficient online point-in-time snapshots of an Oracle
database. Further, Recovery Manager for Oracle enables off-host backup of an Oracle database
to tape, minimizing any impact to the production Oracle server.
This chapter introduces Virtual Copy technology and describes how HP 3PAR Recovery Manager
for Oracle backs up and restores Oracle databases.
In this document, the following terminology is used:
• Database server - A host where the Oracle database is running.
• Backup server - A host where all HP 3PAR Recovery Manager operations are initiated.
Virtual Copies
A Virtual Copy is a point-in-time image of a virtual volume created using the copy-on-write technique.
It is composed of a pointer to the parent virtual volume and a record of all the changes made to
the parent since the Virtual Copy was created. These changes can be rolled back to reproduce
the parent’s earlier state.
A Virtual Copy can be exported to or mounted on a server to allow regular operations such as
backup or off-host processing.
Within HP 3PAR Recovery Manager for Oracle, a Virtual Copy of a database is a point-in-time
image of the database. It consists of Virtual Copies of the virtual volumes where the data files
and/or archive logs reside. Recovery Manager can be used to create an online, offline, datafile,
or archive log Virtual Copy of an Oracle database. An online or offline Virtual Copy is a
point-in-time image of a database, which is taken while the database is OPEN (online) or CLOSED
(offline), respectively. A datafile Virtual Copy is a point-in-time image of all database's datafiles,
which is taken while the database is OPEN (online). An archive log Virtual Copy is a point-in-time
image of database's archive log destination, which is taken while the database is online (OPEN).
Hereinafter, the term Virtual Copy is used to refer to a Virtual Copy of a database, rather than of
a virtual volume.
About the Recovery Manager for Oracle Repository
Information about Virtual Copies, database structures, and backup images (if backed up via Oracle
RMAN and/or Symantec NetBackup) are stored in the HP 3PAR Recovery Manager for Oracle
repository when a Virtual Copy is created, or when a backup operation is performed. The
information in the repository is used to manage Virtual Copies and to restore from a Virtual Copy
backup image.
Some other Oracle-related files such as parameter files, password files, ASM metadata, and control
files are also saved in the Recovery Manager repository, along with the backup image information,
for each Virtual Copy created.
WARNING! Do not modify these repository files.
The Recovery Manager for Oracle repository is located in the following directory on the backup
server:
/etc/3par/solutions/<db_server>.ora.<oracle_sid>
Virtual Copies 7
where:
• <db_server> is the host name of the database server.
• <oracle_sid> is the Oracle SID of the database instance.
The following example displays the location of the Recovery Manager for Oracle repository on
the backup server for Oracle database instance test that is running on database server Host1.
/etc/3par/solutions/Host1.ora.test
If the database is a Real Application Cluster (RAC) database, there will be multiple repositories,
one for each RAC instance.
NOTE: For more information about using the utility to manage the repository, refer to “The Virtual
Copy Repository” (page 16).
Interacting with Oracle
HP 3PAR Recovery Manager for Oracle interacts with Oracle database through the SQL*Plus utility
to perform the following:
• Retrieve database structure information in order to create Virtual Copy for the database.
• Interact with the Oracle database (putting database in backup mode, stopping redo applied
process or performing database log switching) as necessary to create a consistent Virtual
Copy.
In order to create a consistent Virtual Copy of an Oracle database, the database structure must
satisfy the following requirements:
• The database must be running in archive log mode and automatic archiving must be enabled
in order to create an online Virtual Copy, datafile Virtual Copy, or archive log Virtual Copy.
• Datafiles and archive logs must reside on separate 3PAR virtual volumes.
• The online redo logs and control files should not reside on the virtual volumes used by the
datafiles and archive logs to avoid being rolled back along with datafiles and archive logs
virtual volumes. However, the online redo logs and control files can share the same 3PAR
virtual volumes.
• If the database files reside on Symantec VxVM volumes, datafiles and archive logs must reside
on separate VxVM disk groups. The online redo logs and control files should reside on separate
VxVM volumes used by the datafiles and archive logs.
• If the Oracle database is an ASM managed database, the datafiles and archive logs must
reside on separate ASM disk groups. The online redo logs and control files should not reside
on the same ASM disk groups used by the datafiles and archive logs to avoid being rolled
back when using the Recovery Manager Rollback feature.
• ASM disk groups should not be shared between different databases.
• If you use Logical Volume Manager (LVM) on HP or Linux, the Oracle datafiles and archive
logs must reside on separate LVM volume groups. In addition, online redo logs and control
files must not reside on LVM volume groups that are used by Oracle datafiles and archive
logs. However, the online redo logs and control files can reside on the same LVM volume
group.
• If the database is an RAC database, all RAC instances must share the same archive log
destinations (same cluster file systems or same ASM disk groups).
8 Overview of Recovery Manager Operations
To ensure that the database is running in automatic archive log mode, use SQL*Plus utility to ensure
the Database log mode is Archive Mode and that Automatic archival is Enabled, as
in the following example:
$ sqlplus "/as sysdba"
SQL*Plus: Release 9.2.0.1.0 - Production on Wed Nov 14 13:59:13 2007
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.1.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /rac9i_db/rac9i_arch2
Oldest online log sequence 764
Next log sequence to archive 764
Current log sequence 765
Oracle standby databases are supported. An Oracle standby database is a synchronized copy
of the production database. The following are required for standby database support:
• Only Oracle 10g and 11g are supported.
• A standby database must be a physical database. Logical or snapshot standby databases
are not supported.
• If using RMAN backup, the primary database (not standby) must be registered with Oracle
Recovery Catalog.
• A snapshot of a standby database can be used to promote standby database volumes, but
cannot be used to promote primary database volumes (even though a backup of the snapshot
can be used to restore the primary database).
• Oracle parameter and control files are not compatible between the standby and primary
databases. They cannot be used to restore the primary database unless Oracle RMAN (11g)
is used. The Oracle parameter and control files of the primary database must be backed up
manually outside of Recovery Manager for Oracle.
Interacting with Symantec NetBackup and Oracle RMAN
HP 3PAR Recovery Manager for Oracle integrates HP 3PAR Virtual Copy with Symantec NetBackup
(NBU) and Oracle RMAN to dramatically reduce the performance impact on the database server,
as well as to minimize database down time during backup. Instead of a traditional backup where
the database is backed up directly on the production server, Recovery Manager for Oracle creates
a Virtual Copy (snapshot) of the database, imports it to a secondary host (backup server), and
then performs the backup of the Virtual Copy on the backup server.
Recovery Manager for Oracle provides two ways to perform backup and restoration: NBU
(user-managed) and Oracle RMAN.
NOTE: For an ASM managed database, Oracle RMAN backup is the only supported backup
method.
For NBU (user-managed) backup and restoration, Recovery Manager for Oracle interacts directly
with NBU to trigger the backup/restore process. Recovery Manager for Oracle requires that the
NBU client must be installed on the primary host and the backup server.
For Oracle RMAN backup, Recovery Manager for Oracle supports backup to tape and backup
to local disk. If Recovery Manager is configured to perform backup to local disk, Recovery Manager
for Oracle interacts with Oracle RMAN to trigger the backup process. If Recovery Manager for
Interacting with Symantec NetBackup and Oracle RMAN 9
Oracle is configured to perform backup to tape, Recovery Manager for Oracle interacts with
Oracle RMAN, which in turn interacts with NBU to trigger the backup/restore process. Recovery
Manager for Oracle requires that Oracle database software (Oracle RMAN) and Symantec
NetBackup Client must be installed on the database server and the backup server. Additionally,
Symantec NetBackup for Oracle (Oracle Agent) must be installed on the database server, backup
server, and NetBackup master server, if you select to backup to tape.
Recovery Manager for Oracle requires that at least one NBU policy must be created per database.
Optionally, a separate NBU policy can be created for archive log backup (backup archive log
only). The NBU policies must be created as "standard" type or "Oracle" type for NBU
(user-managed) backup/restore or Oracle RMAN backup/restore, respectively (see “Setting Up
NetBackup Policies for NBU (User-Managed) Backup” (page 39) or “Setting Up NetBackup Policies
for Oracle RMAN Backup” (page 41) for detailed information).
Recovery Manager for Oracle Utilities
Read this section for general information regarding HP 3PAR Recovery Manager for Oracle utilities
available through the Recovery Manager for Oracle command line interface and graphical user
interface.
The Database Configuration Utility
The database configuration utility (rmora_config) of HP 3PAR Recovery Manager for Oracle
creates a Recovery Manager for Oracle configuration file for each database. All operations that
are available from Recovery Manager for Oracle require this configuration file. After the Recovery
Manager for Oracle configuration file is created for a database, it is stored at:
/etc/3par/solutions/<db_server>.ora.<oracle_sid>/config
An equivalent environment file is also created for each configuration file. It contains all configuration
options that are specified in the configuration file. Recovery Manager for Oracle uses the
environment file for its operations. The environment file is also stored at the same location as the
configuration file.
/etc/3par/solutions/<db_server>.ora.<oracle_sid>/config_exp.sh
If a configuration file of a database instance exists, it is overwritten. The permission of the
configuration file is set to the user that created the file.
To check the configuration on a specific database, use the rmora_checkconfig command.
Resolve any issues before you create Virtual Copies.
The Virtual Copy Creation Utility
The Virtual Copy creation utility (rmora_create command) of HP 3PAR Recovery Manager
Software for Oracle creates an online, offline, datafile, or archive log Virtual Copy of an Oracle
database.
• Online or offline Virtual Copy - A point-in-time snapshot image of a database while it is OPEN
(online) or CLOSED (offline).
• Archive log Virtual Copy - A snapshot image of the archive log destination of a database
while it is online (OPEN).
• Datafile Virtual Copy - A point-in-time snapshot image of the datafiles of a database while it
is online (OPEN). A datafile Virtual Copy alone cannot be used for recovery without the archive
logs generated up to the point when the Virtual Copy is taken. It is assumed that the user is
responsible for making sure all required archive logs exist.
10 Overview of Recovery Manager Operations
Once created, the Virtual Copy can be mounted on the backup server for off-host processing
purposes such as backup and database cloning.
A database Virtual Copy consists of multiple Virtual Copies of underlying 3PAR virtual volumes
used by Oracle datafiles, archive log destination, or both, depending on which option is specified
(online, offline, datafile, or archlog). An archive log Virtual Copy can be used in
conjunction with online or offline Virtual Copy to simulate an incremental backup.
If Recovery Manager for Oracle is configured to use Oracle RMAN for backup, an RMAN Recovery
Catalog must have been created and configured prior to running the create utility. The Recovery
Manager create utility performs Recovery Catalog synchronization during the Virtual Copy creation
process.
When creating an online Virtual Copy, the create utility performs the following actions:
• Discovers devices (HP 3PAR virtual volumes) used by the datafiles and archive log destination.
• Puts the database in backup mode.
• Creates a Virtual Copy for the datafile virtual volumes.
• Takes the database out of backup mode.
• Switches online redo logs and archives them to archive log destination.
• Re-synchronizes the Recovery Catalog to update with newly generated archive logs if the
Virtual Copy is to be backed up using Oracle RMAN.
• Creates a Virtual Copy for the archive log destination virtual volumes.
A datafile Virtual Copy is created while the database is OPEN. The create utility performs the
following actions:
• Discovers devices (HP 3PAR virtual volumes) used by the datafiles.
• Puts the database in backup mode.
• Creates a Virtual Copy for the datafile virtual volumes.
• Takes the database out of backup mode.
An offline Virtual Copy is created while the database is CLOSED. The create utility performs the
following actions:
• Starts up the database in MOUNTED mode to retrieve a list of datafiles and shuts down the
database.
• Discovers devices (HP 3PAR virtual volumes) used by the datafiles.
• Creates a Virtual Copy for the datafile virtual volumes.
An archive log Virtual Copy is created while the database is OPEN and performs the following
actions:
• Discovers devices (HP 3PAR virtual volumes) used by the archive log destination.
• Switches logs and archives online redo logs to archive log destination.
• Re-synchronizes the Recovery Catalog to update with newly generated archive logs if the
Virtual Copy is to be backed up using Oracle RMAN.
• Creates a Virtual Copy for the archive log destination virtual volumes.
NOTE: If the Virtual Copy is to be backed up using Oracle RMAN, a Recovery Catalog must
have been created and configured prior to running this utility. For an RAC database, archive log
destinations of all RAC instances must be on shared storage (same cluster file systems or same
ASM disk groups).
Recovery Manager for Oracle Utilities 11
The Virtual Copy Display Utility
The Virtual Copy utility (rmora_display) of HP 3PAR Recovery Manager Software for Oracle
displays database Virtual Copies along with other information including creation time, type, status,
and backup status. For systems running HP 3PAR OS 2.3.1 and above, the rmora_display
utility also provides the option to display the retention and expiration times of the Virtual Copy.
A type of Virtual Copy can be either Online, Offline, Datafile, or Archlog.
• An Online Virtual Copy indicates that the Virtual Copy for the database was created while it
was OPEN (online).
• An Offline Virtual Copy indicates that the Virtual Copy for the database was created while it
was CLOSED (offline).
• A Datafile Virtual Copy indicates that the Virtual Copy for the database was created while it
was OPEN (online) and contains only datafiles (no archive log destination).
• An Archlog Virtual Copy indicates that the Virtual Copy was created for archive log destination
only.
The status of a Virtual Copy can be either Available, Orphaned, Removed, Mounted,
Mounted(P), or Database.
• Available status indicates that the Virtual Copy exists and is not currently mounted or cloned.
• Removed status indicates that the Virtual Copy is removed.
• Mounted status indicates that the Virtual Copy is currently mounted.
• Mounted(P) status indicates that the Virtual Copy is partially mounted.
NOTE: To remount the Virtual Copy, use the rmora_mount command with the –r option.
To change the Virtual Copy status to Available, use the rmora_umount command.
• Database status indicates that a database has been cloned using the Virtual Copy.
• An Orphaned status indicates the current database volumes are no longer the parents of the
Virtual Copy volumes.
The backup status of a Virtual Copy can be either Y or N, where Y indicates that the Virtual Copy
has been backed up and N indicates that the Virtual Copy has not been backed up.
The Virtual Copy Mount Utility
The Virtual Copy mount utility of HP 3PAR Recovery Manager Software for Oracle mounts an
existing database Virtual Copy that was created using the create utility on the backup server using
the rmora_mount command. The mounted Virtual Copy can be used for off-host processing
purposes such as backup or database cloning.
The following restrictions apply when mounting a database Virtual Copy:
• The Virtual Copy must have an Available or Mounted(P) status in order to be mounted.
The Virtual Copy's status can be retrieved using the Recovery Manager for Oracle display
utility.
• The same Virtual Copy cannot be mounted concurrently at different mount points.
• If the database files reside on Symantec VxVM Volumes, only one Virtual Copy per database
can be mounted at any time on the backup server. This is due to the VxVM disk groups from
different Virtual Copies of the same database having the same names and so cannot be
imported at the same time.
• If Oracle datafiles and archive logs reside on LVM logical volumes, HP 3PAR Recovery Manager
for Oracle allows only one Virtual Copy of the same database to be mounted. You must
unmount a mounted Virtual Copy before mounting a different Virtual Copy.
12 Overview of Recovery Manager Operations
• If the database files reside on ASM disk groups, it is dependent on which ASM database
version is installed on the backup server, different restrictions apply as follows:
◦ If the ASM version on the backup server is 10.2.0.5 or 11.1.0.7 and above, one Virtual
Copy per database can be mounted at any time on the backup server. However, Virtual
Copies from different databases can be mounted concurrently.
◦ If the ASM version on the backup server is lower than the releases mentioned in the
previous bullet, only one Virtual Copy can be mounted at any time on the backup server.
This restriction prevents an Oracle ASM instance on the backup server from hanging due
to some ASM's idle processes still holding a Virtual Copy's devices, even though the
corresponding ASM disk groups are dropped.
NOTE: The ASM version on the backup server must be equal or higher than the ASM version
on the database server.
• On Linux systems, if the database files reside on OCFS2 1.4.1 or above file systems, Recovery
Manager for Oracle supports multiple Virtual Copies per database being mounted at the same
time. For versions lower than OCFS2 1.4.1, only one Virtual Copy per database can be
mounted at any time on the backup server.
Mounting a database Virtual Copy involves the following actions:
• A read-write Virtual Copy of the original (read-only) Virtual Copy is created.
• The read-write Virtual Copy is imported to the backup server.
• Snapshots of Symantec VxVM disk groups are imported and all corresponding snapshot VxVM
volumes are started if the database files reside on VxVM volumes.
• Snapshots of HP or Linux LVM volume groups are imported and all corresponding LVM snapshot
volumes are activated if the database files reside on LVM logical volumes.
• All snapshot file systems are mounted if the database files reside on file systems.
• For Virtual Copies from an ASM-managed database, based on the different ASM database
releases on the backup server, the operation is different.
◦ For ASM versions 10.2.0.5 or 11.0.1.7 and above, if an ASM instance exists and is up
on the backup server, then all diskgroups from the Virtual Copy are mounted in this ASM
instance. If no ASM instance is up on the backup server, , an ASM instance is started up
on the backup server, and all ASM disk groups in the Virtual Copy are mounted.
◦ For ASM versions lower than the releases mentioned in the previous bullet, if an ASM
instance is up on the backup server, the mount utility checks if there is any mounted
diskgroup. If none, the ASM instance is shut down, otherwise, the mount utility gives an
error and exits. If there are no errors, a new ASM instance is started up and all diskgroups
contained in the current Virtual Copy are mounted.
The Virtual Copy Unmount Utility
The Virtual Copy unmount utility (rmora_umount) of HP 3PAR Recovery Manager Software for
Oracle unmounts the file system where a Virtual Copy is currently mounted, or drops ASM disk
groups if ASM is used. The read-write Virtual Copy is removed, as well as any components that
were created during the mount Virtual Copy stage.
The Virtual Copy must have Mounted or Mounted(P) status in order to be unmounted. The status
of a Virtual Copy can be obtained using a display utility such as the rmora_display command.
Recovery Manager for Oracle Utilities 13
Unmounting a database Virtual Copy involves the following actions:
• For an ASM-managed database, if the ASM database on the backup server has a version at
or above 10.2.0.5 or 11.1.0.7, unmounting the Virtual Copy drops the ASM diskgroups that
are contained in the Virtual Copy and cleans up the ASM disks.
• If the ASM database on the backup server has versions lower than those listed in the previous
bullet, unmounting shuts down the ASM instance and cleans up ASM disks.
• Unmounts all snapshot file systems if the database files reside on file systems.
• Destroys all snapshot VxVM disk groups and their VxVM volumes if the database files reside
on VxVM volumes.
• Destroys all snapshot LVM volume groups and their logical volumes if the database files reside
on LVM logical volumes.
• Deports the read-write Virtual Copy from the backup server.
• Removes the read-write Virtual Copy.
The Virtual Copy Export Utility
The Virtual Copy export utility of HP 3PAR Recovery Manager Software for Oracle exports an
existing Virtual Copy to an alternate backup server (rmora_export command). The exported
Virtual Copy can then be mounted, backed up or cloned at the alternate backup server.
The Virtual Copy must have Available status in order to be exported. An alternate backup server
must have the same operating system, file system, volume manager, and Recovery Manager for
Oracle version as the current backup server. Status of a Virtual Copy can be obtained using a
display utility such as the rmora_display command.
The following restrictions apply to exporting Virtual Copies:
• If Symantec Volume Manager is used, the alternate backup server must have the same version
of Symantec Volume Manager that is currently installed.
• The alternate backup server must be connected to the same HP 3PAR StoreServ Storage system
as the current backup server.
• SSH must be configured to access the alternate backup server, the NetBackup master server,
and any other related servers, from the current backup server without prompting for a pass
phrase. For more information, see “Setting Up SSH Connections for Recovery Manager” (page
31).
• Once exported, the Virtual Copy on the alternate backup server can be mounted, unmounted,
backed up, and restored.
• Once the exported Virtual Copy is no longer needed, its repository can be removed from the
alternate backup server.
The Database Cloning Utility
The database cloning utility (rmora_createdb command) of HP 3PAR Recovery Manager Software
for Oracle creates a single-instance database, or starts up a cloned database in MOUNTED mode
for backup (RMAN) purposes. A single-instance database can be used for any off-host processing
purpose. A cloned database that is started in MOUNTED mode, can be used for RMAN backup.
The Virtual Copy used for cloning a database must be either an online or offline Virtual Copy
(created using the rmora_create or rmora_rsync command). The Virtual Copy must have
been mounted using the rmora_mount command prior to running this command.
A clone database can be created using an ASCII or binary control file which was saved in the
Recovery Manager for Oracle repository at the time the Virtual Copy was created. Using an ascii
control file is more flexible as it allows you to change database instance name as well as the
structure of the database.
14 Overview of Recovery Manager Operations
When using an ascii control file:
• The structure of the clone database is not required to be exactly the same as the structure of
the original database. Therefore the Virtual Copy can be mounted at any mount point.
• Because the Virtual Copy does not contain online redo logs and control files, their locations
can be specified using the -d option (can be one or more directories or ASM diskgroups,
depending on the desired multiplexing).
• The number of multiplex redo log locations must be equal to, or less than, the original database
when creating the clone database. Otherwise, the extra redo log multiplex location will be
ignored.
• If the locations of the redo logs and control files are not specified, they will be created at the
repository location for the Virtual Copy
(/etc/3par/solutions/<host>.ora.<sid>/<vc_name>).
When using a binary control file:
• The structure of the clone database must be exactly the same as the structure of the original
database. Therefore, the Virtual Copy must be mounted at '/' if the datafiles and archive logs
are on file systems.
• Because the Virtual Copy does not contain redo logs and control files, the same directory
structure or same ASM diskgroups for the redo logs and control files must be pre-created on
the backup server.
When creating a clone database for backup (RMAN) purposes, the database is started in
MOUNTED mode using the binary control file from the repository without recovering the database.
This can be achieved by using the -o for_backup or -o binary,norecovery option.
A clone database can be created with or without automatic recovery (applying archivelogs from
the Virtual Copy) using the –o recovery or -o norecovery option. If recovery is chosen, the
clone database is open with a resetlogs. If no recovery is chosen, the clone database is mounted
and archive logs from the Virtual Copy are not applied.
The Cloned Database Removal Utility
HP 3PAR Recovery Manager Software for Oracle’s cloned database removal utility
(rmora_removedb command) removes a cloned database, which was created using the
rmora_createdb command.
The cloned database is shutdown with the shutdown immediate option. The database related
files (Oracle parameter file, control files and redo logs), which were previously created by the
rmora_createdb command, are removed. The read-write Virtual Copy remains mounted.
The Virtual Copy Removal Utility
HP 3PAR Recovery Manager for Oracle’s Virtual Copy removal utility removes an existing Virtual
Copy from the HP 3PAR StoreServ Storage system. The Virtual Copy must have Available status
in order to be removed using the rmora_remove command. The status of a Virtual Copy is
obtained by using the display utility rmora_display.
This utility only removes the read-only Virtual Copy from the system to free up the snapshot space.
It does not actually remove the repository information if the Virtual Copy has been backed up to
the media. This enables Recovery Manager for Oracle to restore a Virtual Copy, which has been
previously backed-up to the media on the original volumes, as long as the Virtual Copy repository
exists.
Recovery Manager for Oracle Utilities 15
Integration with HP 3PAR Virtual Lock Software
HP 3PAR Virtual Lock Software allows administrators to apply a configurable retention period to
virtual volumes - including thin volumes created with HP 3PAR Thin Provisioning Software and
virtual volume copies, such as those created with HP 3PAR Recovery Manager for Oracle.
The Virtual Lock utilities prevent read-only Virtual Copies from being accidentally or intentionally
removed. This is achieved by enforcing a predefined retention time for the read-only Virtual Copy.
Be cautious that once the retention time is set, it cannot be removed or reduced. It can only be
removed after the retention time ends.
This feature is only available for HP 3PAR OS 2.3.1 or above and requires an HP 3PAR Virtual
Lock Software license.
There are a few ways to enforce the retention time for read-only Virtual Copies.
• During configuration, the retention value specified will be the default value for new read-only
Virtual Copies created via rmora_create, rmora_rsync, and rmora_backup (without
the -t option).
• Use rmora_create -r or rmora_rsync -r to override the default value specified during
configuration.
• Use the rmora_set command for the specified Virtual Copy to extend its retention time.
• Retention time can be displayed by using rmora_display with the -r option.
The Virtual Copy Repository
HP 3PAR Recovery Manager Software for Oracle records important information for each Virtual
Copy taken by the Recovery Manager for Oracle utilities. The information is used by Recovery
Manager for Oracle, especially for database restoration. The information is stored in the repository
at:
/etc/3par/solutions/<db_server>.ora.<oracle_sid>/<timestamp>
To avoid unpredictable errors, do not manually modify the directories and files in this repository.
The Virtual Copy Repository Removal Utility
HP 3PAR Recovery Manager Software for Oracle’s Virtual Copy repository removal utility removes
a Virtual Copy’s repository that was created using the create utility (“The Virtual Copy Creation
Utility” (page 10)). The Virtual Copy that has been removed must have Removed status in order
for Recovery Manager for Oracle to remove the repository. The status of a Virtual Copy can be
obtained using the display utility (“The Virtual Copy Display Utility” (page 12)).
If a Virtual Copy has been backed up, the remove repository utility command fails unless the -f
option is used.
Virtual Copy Policy
HP 3PAR Recovery Manager Software for Oracle provides the capability to limit the number of
Virtual Copies per database at any time. There are two ways to achieve this. One is to use a
time-based policy, which is based on the expiration time (the Virtual Copy is removed automatically
by an internal scheduler once the expiration time is reached) of the Virtual Copy . The second way
is to use a numeric-based policy, which is based on the maximum number of Virtual Copies specified
in the configuration file (the maximum allowed value is 500).
For a numeric-based policy example, a policy can be set to only allow twelve Virtual Copies at
any time for a database. Recovery Manager for Oracle always maintains the twelve latest Virtual
Copies by removing the oldest Virtual Copy before creating a new copy. If a Virtual Copy is
protected by retention time, it can only be removed after the retention time ends. The default and
maximum allowed number is 500, meaning that up to 500 read-only Virtual Copies can be created
if you have sufficient snapshot space.
16 Overview of Recovery Manager Operations
For a time-based policy example, if the expiration time is one month (specified in the configuration
file), then the Virtual Copy that reaches the expiration time will be removed from the HP 3PAR
StoreServ Storage system automatically. The system has all the Virtual Copies for last month.
Expiration time can be changed using the rmora_set command.
Database Rollback from a Virtual Copy
When a database is corrupted, you can restore the database to the most recent database images
from the most recently created Virtual Copy by using the rollback utility.
The Database Rollback Utility
The database rollback utility (rmora_rollback) of HP 3PAR Recovery Manager Software for
Oracle promotes the volume of a Virtual Copy back to its base virtual volumes. In other words, the
base virtual volumes used by the database are rolled back to the Virtual Copy volumes. Once the
rollback process completes successfully, the base virtual volumes are exactly the same as the Virtual
Copy volumes. If the base volume size has been changed since the Virtual Copy was taken, the
rollback process will not affect the new size.
• When rolling back from an online Virtual Copy, both datafile and archive log virtual volumes
are rolled back by default. Use the -o option to rollback only datafile virtual volumes or only
archive log virtual volumes.
• When rolling back from an offline or datafile Virtual Copy, only datafile virtual volumes are
rolled back.
• When rolling back from an archive log Virtual Copy, only archive log virtual volumes are
rolled back.
The following restrictions apply when rolling back a Virtual Copy:
• The online redo logs and control file should not reside on the same virtual volumes used by
the datafiles and archive logs. Otherwise, they will be rolled back along with the datafile and
archive log virtual volumes.
• The database instance must be CLOSED for this operation. If the database is an RAC database,
all RAC instances must be CLOSED.
• The base (datafile and/or archive log) virtual volumes must be temporarily removed from the
original database server.
NOTE: For detailed instructions and examples for using the rollback utility, see “Using the Recovery
Manager Rollback Utility” (page 100).
Recovery Manager for Oracle saves an ascii control file and a binary control file for each created
Virtual Copy in its repository. After a rollback, you may need to restore the control file in order to
perform database recovery.
Recovery Manager for Oracle and Third-Party Backup Tools
HP 3PAR Recovery Manager Software for Oracle integrates HP 3PAR Virtual Copy Software with
Symantec NetBackup (NBU) and/or Oracle RMAN to perform off-host backup. Off-host backups
can dramatically reduce performance impact on the database server and minimize database down
time or database in backup mode during backup.
Recovery Manager for Oracle creates a Virtual Copy (snapshot) of the database, mounts it to the
backup server, then performs backup of the Virtual Copy.
Recovery Manager for Oracle supports online (hot), offline (cold), datafile, or archive log backups.
• Online backup - A database backup while it is OPEN.
• Offline backup - A database backup while it is CLOSED.
Database Rollback from a Virtual Copy 17
• Datafile backup - A backup of datafiles only.
• Archive log backup - A backup of archive logs only.
Recovery Manager for Oracle can be configured to perform either NBU (user-managed) backup
or Oracle RMAN backup.
The Database Backup Utility
HP 3PAR Recovery Manager Software for Oracle’s database backup utility supports full and/or
incremental backup of an Oracle database or archive log destination. Full backup of an Oracle
database or archive log destination are always supported regardless of backup method (NBU
backup or Oracle RMAN backup). However, incremental (differential or cumulative) backup of a
whole Oracle database is only available using Oracle RMAN backup. Incremental (differential or
cumulative) backup of archive log destination is only available for the NBU (user-managed) backup
method.
The following restrictions apply when backing up a database using the Recovery Manager for
Oracle database backup utility.
• For NBU (user-managed) backup:
The NBU client must be installed on the backup server, as well as on the database server.◦
◦ At least one NBU policy of standard type must be created and configured for database
backup. Optionally, a separate NBU policy of standard type can be created and
configured for archive log destination backup.
• For Oracle RMAN backup:
◦
◦ If RMAN sbt_tape backup is chosen, at least one NBU policy of the Oracle type must be
◦ An RMAN Recovery Catalog database must be created and configured prior to using
There are two ways to perform backups:
• Immediate backup - a backup that is initiated by Recovery Manager for Oracle through the
database backup utility.
• Automatic backup - a backup that is initiated by NBU from the NBU master server.
Immediate Backup
During an immediate backup, Recovery Manager for Oracle performs the following:
• Creates an online, offline, datafile, or archonly Virtual Copy for the database or archive log
destination.
• Mounts the Virtual Copy on the backup server.
If RMAN sbt_tape backup is chosen, the NBU for Oracle client must be installed on the
backup server, as well as on the database server.
created and configured for database backup. Optionally, a separate NBU policy of the
Oracle type can be created and configured for archive log backup.
the backup utility.
For NBU (user-managed) backup, Recovery Manager for Oracle:
• Generates an include list file that contains a list of datafiles and/or archive log destination
on the mounted Virtual Copy and stores it in the
/usr/openv/netbackup/include_list.<policy_name> file on the NBU client (the
backup server).
• Calls the bpbackup command from the NBU master server to backup files listed in the include
list.
18 Overview of Recovery Manager Operations
For Oracle RMAN backup, Recovery Manager for Oracle:
• Starts up a clone database in mounted mode using the mounted Virtual Copy on the backup
server, assuming ORACLE_HOME is installed and configured in the Recovery Manager
repository.
• Calls an RMAN backup script (rmora_rman_dbbackup.sh or
rmora_rman_archbackup.sh) to backup the cloned database.
• Removes the cloned database.
• Unmounts the Virtual Copy.
NOTE: The RMAN backup scripts (rmora_rman_dbbackup.sh and
rmora_rman_archbackup.sh) are generated at
/etc/3par/solutions/<db_server>.ora.<oracle_sid> during the creation of the
Recovery Manager Configuration file.
Automatic Backup
NOTE: NBU automatic backup can be used when Recovery Manager for Oracle is configured
to run as either root user or Oracle owner.
NOTE: If Recovery Manager for Oracle is configured to be run as an Oracle user and this is an
upgrade from previous Recovery Manager release, the rmora_config command must be run
again for each database that is configured for automatic backup.
During an automatic backup, NBU initiates a backup process on the NBU client (the backup server).
For an NBU (user-managed) backup:
• The NBU client executes the bpstart_notify.<policy_name> script.
• The bpstart_notify script creates a Virtual Copy of the database or archive log destination,
mounts it on the backup server, then generates the include list in the
/usr/openv/netbackup/include_list.<policy_name> file, which contains a list of
files on the Virtual Copy for backup.
• Once the backup process is completed, the NBU client executes the
bpend_notify.<policy_name> script to perform Virtual Copy cleanup.
NOTE: The bpstart_notify and bpend_notify scripts are generated at
/usr/openv/netbackup/bin during the creation of the Recovery Manager Configuration file.
By default, the bpstart_notify script (for database backup policy) will perform an online
backup. If an offline or datafile backup is desired, edit this file to set the value of BACKUP_MODE
to 'offline' or 'datafile' respectively. In addition, the database must be manually shutdown for
offline backup.
For an Oracle RMAN backup:
• The NBU client executes the backup script rmora_nbu_dbbackup.sh or
rmora_nbu_archbackup.sh, which must be specified in the Backup Selection List of the
NBU policy.
• The backup script creates a Virtual Copy of the database or archive log destination, mounts
it on the backup server, starts up a cloned database in MOUNTED mode, then calls the RMAN
backup scripts (rmora_rman_dbbackup.sh or rmora_rman_archbackup.sh) to backup
the cloned database.
Recovery Manager for Oracle and Third-Party Backup Tools 19
NOTE: The backup scripts (rmora_nbu_dbbackup.sh and rmora_nbu_archbackup.sh)
and the RMAN backup scripts (rmora_rman_dbbackup.sh and
rmora_rman_archbackup.sh) are generated at
/etc/3par/solutions/<db_server>.ora.<oracle_sid> during the creation of the
Recovery Manager Configuration file. By default, the rmora_nbu_dbbackup.sh script (for
database backup policy) will perform an online backup. If an offline or datafile backup is desired,
edit this file to set the value of BACKUP_MODE to 'offline' or 'datafile' respectively. In addition,
the database must be manually put in MOUNTED mode for offline backup.
NOTE: To perform automatic backup, SSH must have been configured for root user as Symantec
NetBackup always initiates a backup as root user.
If the Virtual Copy is to be backed up using Oracle RMAN, a Recovery Catalog must have been
created and configured prior to using the backup utility.
For an RAC database, archive log destinations of all RAC instances must be on shared storage
(same cluster file systems or same ASM disk groups).
The Database Restoration Utility
The database restoration utility of HP 3PAR Recovery Manager Software for Oracle restores
databases, tablespaces, datafiles, or archive logs from a backup image of a Virtual Copy. The
Virtual Copy must have been previously backed up using the rmora_backup command. The
Virtual Copy must have a backup status of Y in order to be restored. The backup status of a Virtual
Copy can be retrieved using the Recovery Manager display utility (see “The Virtual Copy Display
Utility” (page 12)).
For an NetBackup (user-managed) restoration, the database restoration utility can be used to restore
a backup image of a Virtual Copy to the backup server, and it can also be used to restore to an
alternate server on an alternate mount point. For an Oracle RMAN restoration, the backup image
is always restored to the database server.
The following restrictions apply when restoring from a backup image of a Virtual Copy:
• When restoring the database control file (using the -c option) using Oracle RMAN, the
database must be in STARTED mode (startup nomount). In addition, restoring the database
control file along with the individual datafile or tablespace is not supported as it is not possible
to perform media recovery.
• When restoring a database, the database must be in CLOSED or MOUNTED mode for NBU
restore or Oracle RMAN restore, respectively. For an RAC database, all RAC instances must
be in CLOSED or MOUNTED mode.
• When restoring individual tablespaces or datafiles, the database can be OPEN, but the
corresponding tablespaces must be offline.
• If the database is an ASM managed database, all ASM disk groups must be mounted prior
to running the restore utility.
• For an NBU (user-managed) restoration, the
/usr/openv/netbackup/db/altnames/<database_hostname|virtual
_hostname> file must be created on the NBU master server prior to running the restore utility,
where <database_hostname|virtual_hostname> is the host name of the database
server.
Depending on the type (online, offline, datafile, or archive log) of backup image of the Virtual
Copy, corresponding database files are restored appropriately.
20 Overview of Recovery Manager Operations
For an NBU (user-managed) restoration:
• Control files are not restored by default.
• For an online Virtual Copy, both datafiles and archive logs are restored unless individual
tablespaces or datafiles are being specified. In this case, only the corresponding datafiles are
restored.
• Only datafiles are restored for an offline or datafile Virtual Copy.
• Only archive logs are restored for an archive log Virtual Copy.
For an Oracle RMAN restoration:
• Control files are not restored by default.
• For an online Virtual Copy, only datafiles are restored. Archive logs are not restored to minimize
restore time as Oracle RMAN can restore only necessary archive logs during recovery.
• Only datafiles are restored for an offline or datafile Virtual Copy.
• Restoring from an archive log Virtual Copy backup image is not supported as Oracle RMAN
can restore necessary archive logs during recovery.
Recovery Manager for Oracle with Oracle Standby Database
All HP 3PAR Recovery Manager Software for Oracle’s utilities can be run against an Oracle
physical standby database instead of the production database. This completely eliminates the
performance impact on the production database.
In addition to the current Recovery Manager for Oracle’s limitations and restrictions when running
against an Oracle primary database, the following limitations and restrictions apply when running
against an Oracle physical standby database:
• Only Oracle 10g and 11g are supported.
• A standby database must be a physical standby database. Logical and snapshot standby
databases are not supported.
• If using Oracle RMAN for backup, the primary database, and not the standby database, must
be registered with Oracle Recovery Catalog.
• A snapshot of a standby database can be used to promote back to the standby database
volumes, but it cannot be used to promote back to the primary database volumes.
• Oracle parameter file and control file are not compatible between the standby database and
the primary database. They cannot be used to restore to the primary database unless Oracle
RMAN (11g) is used for restoring. This means that the Oracle parameter file and control file
of the primary database must be backed up manually outside of the Recovery Manager for
Oracle.
Recovery Manager for Oracle and Autonomic Groups
HP 3PAR Autonomic Groups allow domains, hosts, and virtual volumes to be grouped into a set
that is managed as a single object. HP 3PAR Recovery Manager Software for Oracle supports
domain sets, and can coexist with host sets and volume sets. Refer to the HP 3PAR OS Concepts
Guide for additional information about 3PAR Autonomic Groups.
Recovery Manager for Oracle and Domain Sets
HP 3PAR Recovery Manager Software for Oracle allows the management of multiple database
servers belonging to different virtual domains from a single backup server.
Recovery Manager for Oracle with Oracle Standby Database 21
The following configuration requirements must be met:
• The HP 3PAR StoreServ Storage system must be running HP 3PAR OS 2.3.1 or higher.
• The backup server must belong to a domain set, which contains all database servers’ virtual
domains to be managed by the backup server.
• The HP 3PAR OS user used by Recovery Manager for Oracle to access the HP 3PAR StoreServ
Storage system from the backup server must belong to the virtual domains of all the database
servers.
Recovery Manager for Oracle and Host Sets
Database servers (nodes) within the same Real Application Cluster (RAC) can be grouped into a
set, which can then be managed as a single object. If the backup server also belongs to a host
set, Recovery Manager for Oracle continues to export/deport database Virtual Copies to the
backup server, rather than the host set that contains the backup server.
Recovery Manager for Oracle and Virtual Volume Sets
Database virtual volumes can be grouped into a set on the database server, which can be managed
as a single object. Recovery Manager for Oracle works with the volume sets, but from the backup
server, it does not make use of them as database virtual volumes must still be discovered in order
to ensure all database volumes are included in the volume set.
Recovery Manager for Oracle with Remote Copy
Recovery Manager for Oracle integrates with HP 3PAR Remote Copy Software to copy database
virtual volumes from one HP 3PAR StoreServ Storage system (local/primary) to another
(remote/secondary). Once copied, database Virtual Copies (application consistent snapshots) are
created on the remote/secondary storage system. The Virtual Copies can be used for disaster
recovery or other off-host processing purposes. Recovery Manager for Oracle supports synchronous
and asynchronous periodic mode Remote Copy, as well as Synchronous Long Distance Remote
Copy. See the HP 3PAR Remote Copy Software User's Guide for additional information.
Recovery Manager for Oracle and Peer Motion
You do not need to uninstall and then reinstall Recovery Manager for Oracle when you migrate
data with HP 3PAR Peer Motion.
Preparing Recovery Manager for Oracle for Peer Motion Data Migration
1. Before you use Peer Motion to migrate data, remove all existing Recovery Manager for Oracle
Virtual Copies in the following order:
a. Remove all clone databases; to do so, use the GUI or the rmora_removedb command.
b. Unmount all currently mounted Virtual Copies; to do so, use the GUI or the rmora_umount
command.
c. Remove all existing Virtual Copies; to do so, use the GUI or the rmora_remove command.
2. Start the data migration. While Peer Motion is migrating data, do not use Recovery Manager
for Oracle.
3. Finish host configuration for the new HP 3PAR StoreServ Storage system.
4. Remove the old system from the storage system setup.
5. After Peer Motion migration is complete, reconfigure SSH to allow the database and backup
servers to access the new HP 3PAR StoreServ Storage system.
6. Modify the Recovery Manager for Oracle configuration file to reflect the new HP 3PAR StoreServ
Storage system; to do so, use the GUI or rmora_config command.
7. Begin Recovery Manager for Oracle operations.
22 Overview of Recovery Manager Operations
Recovery Manager for Oracle and Fat-to-Thin and Thin-to-Fat
To improve the existing RMO setup environment, an unlimited bidirectional conversion of volumes
from Fat-to-Thin and Thin-to-Fat is featured with HP 3PAR Operating System Software. The user
may better balance between performance and spacial optimization.
Converting Virtual Volumes
CAUTION: Due to the limitations of HP 3PAR OS, RMO is unable to retain repository information
after online Fat-to-Thin or online Thin-to-Fat conversion process. As a result, all existing Virtual
Copies, including the mounted ones, must be unmounted and removed prior to performing any
online Fat-to-Thin or Thin-to-Fat conversion. Use either the GUI or CLI (rmora_remove) to remove
all Virtual Copies. Do not use the RMO creation process during conversion. Only use the RMO
creation process when the conversion process is complete. RMO can only detect conversion on
specified volume. For example, you can still create a Virtual Copy on a datafile while a conversion
is in progress on archive log volume.
To convert database Virtual Volumes:
1. On HP 3PAR Backup system, use the Recovery Manager GUI or command line interface to
remove all Virtual Copies of the database before converting the volumes.
2. On HP 3PAR StoreServ Storage system, enter tunevv to convert the virtual volumes.
NOTE: Please refer to HP 3PAR Operating System Software User Guide for more details
about using the tunevv command.
3. On HP 3PAR StoreServ Storage system, enter showtask to monitor the Virtual Volume
conversion completion.
Recovery Manager for Oracle and Fat-to-Thin and Thin-to-Fat 23
2 Installing and Uninstalling Recovery Manager
This chapter describes how to install, verify, and remove HP 3PAR Recovery Manager Software
for Oracle on systems running Linux, Solaris, and HP UX.
Referencing the Support Matrix
For information about supported hardware and software platforms, refer to the Single Point of
Connectivity Knowledge for HP Storage Products (SPOCK) Web site at http://
h20272.www2.hp.com/.
Preinstallation Requirements
Recovery Manager for Oracle must be installed on a database server and a backup server. The
database server must be running an Oracle 10g or 11g database.
NOTE: This feature requires the HP 3PAR Recovery Manager for Oracle Software license.
Prior to the installation of Recovery Manager for Oracle, make sure the following preinstallation
requirements are met:
• The same Oracle owner user and Oracle DBA group on the database server must exist on
the backup server.
• Oracle datafiles and archive logs must reside on separate 3PAR virtual volumes.
• Online redo logs and control files can reside on the same virtual volume. However, redo logs
and control files must not reside on virtual volumes on which data files and archive logs reside.
• If Symantec Volume Manager is used, the Oracle datafiles and archive logs must reside on
separate VxVM disk groups. Additionally, online redo logs and control files must not reside
on VxVM disk groups that are used by Oracle datafiles and archive logs. The online redo
logs and control files can reside on the same VxVM disk group. The database and backup
server must have the same level of operating system patches, Symantec Volume Manager
version, and maintenance patch.
• If you use HP or Linux LVM Volume Manager, the Oracle datafiles and archive logs must
reside on separate LVM volume groups. In addition, online redo logs and control files must
not reside on LVM volume groups that are used by Oracle datafiles and archive logs. However,
the online redo logs and control files can reside on the same LVM volume group.
• If ASM is used to manage an Oracle database, Oracle datafiles and archive logs must reside
on different ASM disk groups. Additionally, online redo logs and control files must not reside
on ASM disk groups used by Oracle datafiles and archive logs. The online redo logs and
control files can reside on the same ASM disk group.
• If you are using Symantec NetBackup1:
It is recommended that you use the backup server as the NetBackup master server.◦
◦ The Symantec NetBackup client must be installed on the database and backup servers.
◦ If you are using Symantec NetBackup in conjunction with Oracle RMAN, the NetBackup
for Oracle client must be installed on the database and backup servers. Refer to Symantec
NetBackup for Oracle for installation and configuration instructions.
1. Symantec NetBackup is third-party software, and 3PAR makes no representations or warranties with respect to such
software.
24 Installing and Uninstalling Recovery Manager
◦ If you install the NetBackup for Oracle client, you must link the Oracle libok.so library
on the database and backup servers to point to the Symantec NetBackup Media Library.
For more information, refer to Symantec’s NetBackup for Oracle documentation.
◦ If you separate the NetBackup master server from the backup server, you must also install
Recovery Manager for Oracle on the NetBackup master server. If you use the Oracle
owner user to perform Recovery Manager for Oracle operations, the same Oracle owner
user and Oracle owner group must exist on the NetBackup master server. No Oracle
binary is required.
• If you choose Oracle RMAN for the backup method, you must create an Oracle RMAN
Recovery Catalog and configure Oracle TNS Service and Listener to allow connecting to the
Recovery Catalog from both the database and backup servers. The Recovery Catalog can be
created on any host. Recovery Manager for Oracle recommends that the Recovery Catalog
is created on the backup server. Refer to Oracle documentation for instructions on how to
create a Recovery Catalog, as well as how to configure Oracle TNS Service and Listener.
• In Linux:
If you are using the device mapper multi-path, the supported disk formats on the primary
◦
host are:
– /dev/mapper/diskname
– /dev/mapper/aliasname
– /dev/mapper/mpathn
– /dev/dm-n
– /dev/mpath/diskname
◦ Raw disks (/dev/raw/raw) are not supported.
◦ Each OS disk can only have maximum one partition.
◦ For ext3/ext4 file systems, the journal devices should be within the same file systems
• Virtual volume snapshots used by an Oracle database must be mapped to a Common
Provisioning Group (CPG). Refer to the HP 3PAR Command Line Interface Administrator’s
Manual for details about mapping to CPGs.
• If you are upgrading from an earlier version of Recovery Manager for Oracle, do not use any
upgrade utilities provided by the system. Instead, use rmora_install.sh to perform the
upgrade.
• Refer to the HP 3PAR Implementation Guides for instructions on setting up connections from
hosts to the HP 3PAR StoreServ Storage systems and reserving LUNs with specific Host Bus
Adapters (HBAs) and Multipath configurations.
• To use the Remote Copy feature, you must configure your HP 3PAR StoreServ Storage systems
for Remote Copy Software. The HP 3PAR StoreServ Storage systems must meet the requirements
specified in “Recovery Manager for Oracle’s Remote Copy Requirements” (page 103). For
instructions on configuring storage systems for Remote Copy Software, see the HP 3PAR Remote
Copy Software User’s Guide.
NOTE: This version of HP 3PAR Recovery Manager for Oracle supports English only.
Installing Recovery Manager for Oracle on Linux Systems
Use the instructions in this section to install or upgrade Recovery Manager for Oracle on the
database and backup servers.
Installing Recovery Manager for Oracle on Linux Systems 25
If you are not using the backup server as the NetBackup master server, be sure to install Recovery
Manager for Oracle on the NetBackup master server.
Installation
The following section describes the steps necessary for installing or upgrading Recovery Manager
for Oracle on a Linux system:
To install or upgrade HP 3PAR Recovery Manager:
1. Log in as the root user.
2. Insert the HP 3PAR Recovery Manager CD into a CD-ROM drive.
3. Change to the CD-ROM drive.
4. Enter ./rmora_install.sh.
NOTE: If the CD is not mounted automatically, you can mount it manually.
# mount -t iso9660 -r /dev/cdrom /mnt/cdrom
# cd /mnt/cdrom0/
Read the following information before continuing the installation:
• By default, only user root is allowed to run RMO if the second question is answered no.
• Enter the user and group name of the Oracle owner previously used to install your Oracle
database if different from the names shown in the sample output below.
• The sample output describes a clean installation. The output and first prompt when doing
an upgrade or a re-installation will indicate that an upgrade or re-installation is being
initiated.
Answer the following prompts.
# ./rmora_install.sh
Welcome to HP 3PAR Recovery Manager 4.3.0.9 for Oracle
Checking for existing Recovery Manager installation...
Recovery Manager is not found on the system.
Do you want to install Recovery Manager for Oracle v4.3.0.9? (y/n) y
Installing Recovery Manager for Oracle v4.3.0.9...
Preparing packages for installation...
RMOra-4.3.0-9
Would you like to run RMOra as an Oracle owner? (y/n) y
Enter the user name of the Oracle owner[q]: oracle
Enter the group name of the Oracle owner[q]: oinstall
WARN: Ownership and permission will be changed for all database repositories.
Refer to the Recovery Manager for Oracle User's Guide or the rmora_chown(1M)
man page for details.
Allow RMOra to be run with 'oracle:oinstall' (y/n)?
y
Installation completed.
26 Installing and Uninstalling Recovery Manager
5. After the installation is complete on all the required servers, you can allow Oracle users and
Database Administrators group access to the Recovery Manager commands and utilities by
running the rmora_chown utility if you did not specify during step 4.
You can use the utility command to allow only root or both root and a single non-root user to
manage all RMO database configurations.
#/opt/3PAR/RMOra/bin/rmora_chown -u <user> -g <group>
For more information about allowing types of users to manage all RMO database
configurations, refer to “rmora_chown” (page 58).
Verifying Installation
To verify HP 3PAR Recovery Manager installation on a Linux system:
1. Log in as the root user.
2. Issue the rpm -qi RMOra command and verify:
• RMOra is the displayed package name under the Name field.
• 4.3.0 is the version displayed under the Version field.
Removing Recovery Manager from Linux Systems
To uninstall 3PAR Recovery Manager from a Linux system:
1. Log in as the root user.
2. Insert the HP 3PAR Recovery Manager CD into a CD-ROM drive.
NOTE: If the CD is not mounted automatically, you can mount it manually.
# mount -t iso9660 -r /dev/cdrom /mnt/cdrom
3. Change to the CD-ROM drive.
# cd /mnt/cdrom0/
4. Enter ./rmora_uninstall.sh.
Confirm you want to uninstall RMO when prompted.
# ./rmora_uninstall.sh
Welcome to HP 3PAR Recovery Manager for Oracle
Checking for existing Recovery Manager installation...
The following version of RMOra has been found:
Currently Installed version: 4.3.0.9
Do you want to remove the existing RMOra? (y/n)y
Removing existing RMOra...
Recovery Manager removed
Installing Recovery Manager on Solaris Systems
Use the instructions in this section to install or upgrade Recovery Manager for Oracle on the
database and the backup servers.
Removing Recovery Manager from Linux Systems 27
If you are not using the backup server as the NetBackup master server, be sure to install Recovery
Manager for Oracle on the NetBackup master server.
Installation
To install or upgrade HP 3PAR Recovery Manager on a Solaris system:
1. Log on as the root user.
2. Insert the HP 3PAR Recovery Manager CD into a CD-ROM drive.
3. Change to the CD-ROM drive.
4. Enter ./rmora_install.sh.
If the CD is not mounted automatically, you will need to mount it manually.
# mount -F hsfs -o ro /dev/dsk/c0t6d0s2/cdrom
# cd /cdrom/cdrom0/
The prompts and output from running rmora_install.sh are similar to those when running
rmora_install.sh on Linux. If necessary, refer to “Installation” (page 26). However, the
output on Solaris will include a listing of all RMO package files being installed and you will
also be prompted to confirm the installation of setuid root executables.
NOTE: Install the following patch if applicable:
• Solaris 5.10 requires patch 119130-26 or higher.
The following command can be used to verify whether the patches are installed or not:
• showrev -p | grep 119130
5. After the installation is complete on the required servers, you can allow Oracle users and
Database Administrators group access to the Recovery Manager commands and utilities by
running the rmora_chown utility if you did not specify during step 4.
You can use the utility command to allow only root or both root and a single non-root user to
manage all RMO database configurations.
# /opt/3PAR/RMOra/bin/rmora_chown -u <user> -g <group>
For more information about allowing types of users to manage all RMO database
configurations, refer to “rmora_chown” (page 58).
Verifying Installation
To verify HP 3PAR Recovery Manager installation on a Solaris system:
1. Log in as the root user.
2. Enter the pkginfo -l RMOra command and verify:
• RMOra is the package name displayed under the PKGINST field.
• 4.3.0 is the version displayed under the Version field.
3.
Removing Recovery Manager from Solaris Systems
To remove 3PAR Recovery Manager from a Solaris system:
28 Installing and Uninstalling Recovery Manager
1. Log on as the root user.
2. Insert the HP 3PAR Recovery Manager CD into a CD-ROM drive.
If the CD is not mounted automatically, you will need to mount it manually.
# mount -F hsfs -o ro /dev/dsk/c0t6d0s2/cdrom
3. Change to the CD-ROM drive.
# cd /cdrom/cdrom0/
4. Enter ./rmora_uninstall.sh.
Confirm you want to uninstall RMO when prompted.
# ./rmora_uninstall.sh
Welcome to HP 3PAR Recovery Manager for Oracle
Checking for existing Recovery Manager installation...
The following version of RMOra has been found:
Currently Installed version: 4.3.0.9
Do you want to remove the existing RMOra? (y/n)y
Removing existing RMOra...
Recovery Manager removed
Installing Recovery Manager for Oracle on HP UX Systems
Use the instructions in this section to install or upgrade Recovery Manager for Oracle on the
database and backup servers.
If you are not using the backup server as the NetBackup master server, be sure to install Recovery
Manager for Oracle on the NetBackup master server.
Installation
The following section describes the steps necessary for installing or upgrading Recovery Manager
for Oracle on an HP UX system:
1. Log in as the root user.
2. Insert the HP 3PAR Recovery Manager CD into a CD-ROM drive.
NOTE: If the CD is not mounted automatically, you can mount it manually.
# mount -t iso9660 -r /dev/cdrom /mnt/cdrom
3. Change to the CD-ROM drive.
# cd /mnt/cdrom0/
Installing Recovery Manager for Oracle on HP UX Systems 29
4. Enter ./rmora_install.sh.
The prompts and output from running rmora_install.sh are similar to those when running
rmora_install.sh on Linux. If necessary, refer to “Installation” (page 26).
5. After the installation is complete on all the required servers, you can allow Oracle users and
the Database Administrators group access to the Recovery Manager commands and utilities
by running the rmora_chown utility if you did not specify during step 4.
You can use the utility command to allow only root or both root and a single non-root user to
manage all RMO database configurations.
/opt/3PAR/RMOra/bin/rmora_chown -u <user> -g <group>
For more information about allowing types of users to manage all RMO database
configurations, refer to “rmora_chown” (page 58).
Verifying Installation
1. Log in as the root user.
2. Enter the swlist RMOra command and verify:
• The product name RMOra and the fileset RMOra.RUN are displayed.
• The Version displayed is 4.3.0.
3. To enable a user to schedule tasks (for example, to create a Virtual Copy creation schedule),
add the user name to the /usr/lib/cron/cron.allow file.
Removing Recovery Manager from HP UX Systems
1. Log in as the root user.
2. Insert the HP 3PAR Recovery Manager CD into a CD-ROM drive.
NOTE: If the CD is not mounted automatically, you can mount it manually.
# mount -t iso9660 -r /dev/cdrom /mnt/cdrom
3. Change to the CD-ROM drive.
# cd /mnt/cdrom0/
4. Enter ./rmora_uninstall.sh.
Confirm you want to uninstall RMO when prompted.
# ./rmora_uninstall.sh
Welcome to HP 3PAR Recovery Manager for Oracle
Checking for existing Recovery Manager installation...
The following version of RMOra has been found:
Currently Installed version: 4.3.0.9
Do you want to remove the existing RMOra? (y/n)y
Removing existing RMOra...
Recovery Manager removed
30 Installing and Uninstalling Recovery Manager
3 Configuring Recovery Manager for Oracle
Recovery Manager for Oracle requires that an SSH connection be configured for the backup server,
the database server, the Symantec NetBackup master server, and the HP 3PAR StoreServ Storage
system.
Since Recovery Manager for Oracle can be run by either the root user or Oracle user (Oracle
owner), configure SSH for the root or Oracle user.
NOTE: Recovery Manager for Oracle supports Symantec NetBackup as the root user or Oracle
user.
Setting Up SSH Connections for Recovery Manager
This section provides instructions on how to configure a Secure Shell (SSH) on the database server,
backup server, NetBackup (NBU) master server, and the HP 3PAR StoreServ Storage system.
Recovery Manager for Oracle commands can be run as either root user or Oracle user. SSH must
be configured for the root user or Oracle user.
Figure 1 (page 31) represents the SSH connection relationship between the database server, the
backup server, NBU master server, and the HP 3PAR StoreServ Storage system.
Figure 2 (page 32) represents the SSH connection relationship in a Remote Copy configuration.
Figure 1 SSH Connection Relationship
Setting Up SSH Connections for Recovery Manager 31
Figure 2 SSH Connection Relationship for Remote Copy Support
SSH Restrictions
Recovery Manager for Oracle has the following SSH restrictions:
• The ssh and scp commands must be located in the /usr/bin/ directory. Create symbolic
links if necessary. For example, if SSH and SCP are located at /usr/local/bin, create
symbolic links as follows:
#ln -s /usr/local/bin/ssh /usr/bin/ssh
#ln -s /usr/local/bin/scp /usr/bin/scp
• SSH keys on the database and backup servers must be generated with no passphrase. Recovery
Manager for Oracle does not support an SSH passphrase or SSH agent.
Modifying the SSH Daemon Configuration
If SSH needs to be configured for the root user, then the SSH daemon on the database server,
backup server, and NetBackup master server must be configured to allow root access. Perform the
following on each system:
1. Verify that the SSH daemon allows root access by checking the sshd_config file for the
following line:
PermitRootLogin yes
NOTE: If you are using native SSH, the sshd_config file is located in
/etc/ssh/sshd_config.
If you are using HP UX, the sshd_config file is located in /opt/ssh/etc/sshd_config.
2. If the line reads PermitRootLogin no, change the line to read yes.
32 Configuring Recovery Manager for Oracle
3. If you are using HP UX, verify that the SSH daemon has strict mode disabled:
a. Check the sshd_config file for the following line:
StrictModes no
b. If StrictModes is set to yes, change the entry to no.
Generating an SSH Key Pair for the Backup Server
To generate an SSH key pair for the backup server:
1. Log on to the backup server as the root or Oracle owner user.
2. Create a key pair with no passphrase using the ssh-keygen command. If a key-pair already
exists, skip this section.
<backup_server>:# ssh-keygen -b 1024 -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (//.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in //.ssh/id_rsa.
Your public key has been saved in //.ssh/id_rsa.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx root@<backup_server>
NOTE: You can create the SSH key as either dsa or rsa. The recommended key length is
1024 (the total of the public and private key lengths).
The ssh-keygen utility generates two files, id_rsa and id_rsa.pub (or id_dsa and
id_dsa.pub). The id_rsa (or id_dsa) file contains the private key and the id_rsa.pub
(or id_dsa.pub) file contains the public key.
Generating an SSH Key Pair for the Database Server
You can either use the same SSH key pair generated for the backup server or generate a different
SSH key pair for the database server. If you choose to use the same key pair, create one HP 3PAR
CLI user, otherwise, create two different HP 3PAR CLI users to be accessed from the database
server and the backup server, respectively. If you are generating a different SSH key pair for the
database server, perform the procedure described in “Setting Connections from the Database
Server to the HP 3PAR Storage System” (page 37) on the database server.
NOTE: In a Real Application Cluster (RAC) environment, all the nodes in the RAC cluster must
have the same SSH key pair in order to run Recovery Manager for Oracle utilities against any
RAC instance on any node.
If you choose to use the same SSH key pair, create one HP 3PAR CLI user. Then copy the SSH key
pair from the backup server to the database server as follows:
<db_server> # scp <backup_server>:~/.ssh/* ~/.ssh
The authenticity of host 'pilot (192.168.3.130)' can't be established.
RSA key finger print is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'pilot (192.168.3.130)' to the list of known hosts.
root@pilot's password:
Setting Up SSH Connections for Recovery Manager 33
Setting Up Connections from the Backup Server to the Database Server
To set up an SSH connection from the backup server to the database server, perform the following:
• Copy the public key (id_rsa.pub) of the backup server to the authorized_keys file of
the database server.
<backup_server> # scp ~/.ssh/id_rsa.pub <db_server>:~/.ssh/authorized_keys
If the authorized_keys file already exist, add the public key (from ~/.ssh/id_rsa.pub on
the backup server) to the end of the authorized_keys file on the database server.
Verifying Connections from the Backup Server to the Database Server
From the backup server, verify the connection to the database server as follows:
NOTE: If you are prompted for a password, the connection was not set up correctly. To fix the
issue:
• Redo the connection setup.
• Verify that the .ssh directory and the files within the .ssh directory have the correct
permissions.
<backup_server># ssh <user>@<db_server>
The authenticity of host '<db_server>' can't be established.
DSS key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:x:xx:xx.
Are you sure you want to continue connecting (yes/no)?
yes
Warning: Permanently added '<db_server>' (DSS) to the list of
known hosts.
where <user> is either root or the Oracle owner user and <db_server> is the database server’s
hostname.
Setting Up Connections from the Backup Server to the NetBackup Master Server
To set up an SSH connection from the backup server to the NetBackup (NBU) master server, perform
the following:
• Copy the public key (id_rsa.pub) of the backup server to the authorized_keys file of
the NBU master server.
<backup_server # scp ~/.ssh/id_rsa.pub <NBU_server>:~/.ssh/authorized_keys
If the authorized_keys file already exist, add the public key (from ~/.ssh/id_rsa.pub
on the backup server) to the end of the authorized_keys file on the NetBackup master
server.
Verifying Connections from the Backup Server to the NetBackup Master Server
From the backup server, verify the connection to the NetBackup master server as follows:
34 Configuring Recovery Manager for Oracle
NOTE: If you are prompted for a password, the setup is incorrect and you must redo the previous
setup.
<backup_server># ssh <user>@<NBU_master>
The authenticity of host '<NBU_master>' can't be established.
DSS key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:x:xx:xx.
Are you sure you want to continue connecting (yes/no)?
yes
Warning: Permanently added '<NBU_master>' (DSS) to the list of
known hosts.
where <user> is either root or the Oracle owner user and <NBU_master> is the name of the
NBU master server.
Setting Up Connections from the Backup Server to the HP 3PAR Storage System
Set up an SSH connection from the backup server to the HP 3PAR StoreServ Storage system as
follows:
1. SSH to the backup server and log in as the root or Oracle owner user.
2. Make sure the SSH key pair exists as follows:
<backup_server> # ls ~/.ssh
id_rsa id_rsa.pub authorized_keys known_hosts
3. Create a CLI user on the HP 3PAR StoreServ Storage system to be used by Recovery Manager
for Oracle to access the system from the backup server. Skip this step if you choose to use an
existing user.
<backup_server># ssh <adm_user>@<ss_name>
<adm_user>'s password: <adm_password>
cli% createuser -c <password> <username> <domainname> <role>
In the example above:
• <adm_user> is the user name of the HP 3PAR StoreServ Storage system’s administrator
(for example, 3paradm). For more information, see the HP 3PAR Command Line Interface
Administrator’s Manual.
• <ss_name> is the system name of the HP 3PAR StoreServ Storage system attached to
the backup server.
• <adm_password> is the administrator password.
• <password> is the password (for the HP 3PAR StoreServ Storage system) for the CLI
user being created.
• <username> is the user being created.
• <domainname> is the domain to which the user will belong (for example, all).
• <role> specifies the authority level of the user (for example, 3PAR_RM).
For details about the createuser command, refer to the HP 3PAR Command Line Interface
Reference.
Setting Up SSH Connections for Recovery Manager 35
4. Copy the public key of the backup server to the HP 3PAR StoreServ Storage system. You can
find the public key in the location specified when generating an SSH key pair; for more
information, see “Generating an SSH Key Pair for the Backup Server” (page 33).
<backup_server># ssh <username>@<ss_name>
<username>'s password: <password>
cli% setsshkey
Please enter the SSH public key below. When finished, press enter twice.
The key is usually long. It's better to copy it from inside an editor
and paste it here. (Please make sure there are no extra blanks.)
The maximum number of characters used to represent the SSH key
(including the "from" option, key type, and additional comments) is 4095.
<paste the public key here and press Enter twice>
<public_key>
SSH public key successfully set!
In the example above:
• <username> is the user you created.
• <ss_name> is the system name of the HP 3PAR StoreServ Storage system attached to
the backup server.
• <password> is the password for the CLI user you created.
• <public_key> is the SSH public key of the backup server.
Verifying Connections from the Backup Server to the HP 3PAR Storage System
From the backup server, verify the connection from the backup server to the HP 3PAR StoreServ
Storage system as follows:
NOTE: If you are prompted for a password, the setup is incorrect and you must redo the previous
setup.
<backup_server># ssh <username>@<ss_name>
The authenticity of host '<ss_name>' can't be established.
DSS key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:x:xx:xx.
Are you sure you want to continue connecting (yes/no)?
yes
Warning: Permanently added '<HP 3PAR Storage system_name>' (DSS) to the list of
known hosts.
where:
• <user_name>is the CLI user created in “Setting Up Connections from the Backup Server to
the HP 3PAR Storage System” (page 35).
• <ss_name> is the system name of the HP 3PAR StoreServ Storage system attached to the
backup server.
36 Configuring Recovery Manager for Oracle
Setting Connections from the Database Server to the HP 3PAR Storage System
Skip this step if the database server has the same SSH key pair as the SSH key pair of the backup
server (see “Generating an SSH Key Pair for the Database Server” (page 33)). Recovery Manager
for Oracle uses the same CLI user to access the HP 3PAR StoreServ Storage system from either the
backup server or database server.
If you created a different CLI user for the database server, perform the following to set up an SSH
connection from the database server to the HP 3PAR StoreServ Storage system.
1. SSH to the database server and log in as the root or Oracle owner user.
2. Make sure the SSH key pair exists as follows:
<db_server> # ls ~/.ssh
id_rsa id_rsa.pub authorized_keys known_hosts
3. Create a CLI user to be used by Recovery Manager for Oracle to access the HP 3PAR StoreServ
Storage system from the database server. Skip this step if you wish to use an existing user
(different from the user created for the backup server).
<db_server># ssh <adm_user>@<ss_name>
<adm_user>'s password: <adm_password>
cli% createuser -c <password> <username> <domainname> <role>
In the example above:
• <adm_user> is the user name of the HP 3PAR StoreServ Storage system’s administrator
(for example, 3paradm).
• <ss_name> is the system name of the HP 3PAR StoreServ Storage system attached to
the database server.
• <adm_password> is the administrator password.
• <password> is the password (for the HP 3PAR StoreServ Storage system) for the CLI
user being created.
• <username> is the user being created.
• <domainname> is the domain to which the user will belong (for example, all)
• <role> specifies the authority level of the user (for example, 3PAR_RM)
Setting Up SSH Connections for Recovery Manager 37
4. Copy the public key of the database server to the HP 3PAR StoreServ Storage system.
<db_server># ssh <username>@<ss_name>
<username>'s password: <password>
cli% setsshkey
Please enter the SSH public key below. When finished, press enter twice.
The key is usually long. It's better to copy it from inside an editor
and paste it here. (Please make sure there are no extra blanks.)
The maximum number of characters used to represent the SSH key
(including the "from" option, key type, and additional comments) is 4095.
<pass the public key here and press Enter twice>
<public_key>
SSH public key successfully set!
In the example above:
• <username> is the user being created.
• <ss_name> is the system name of the HP 3PAR StoreServ Storage system attached to
the database server.
• <password> is the password for the CLI user being created.
• <public_key> is the SSH public key of the database server.
Verifying Connections from the Database Server to the HP 3PAR Storage System
From the database server, verify the connection from the database server to the HP 3PAR StoreServ
Storage system as follows:
NOTE: If you are prompted for a password, the setup is incorrect and you must redo the previous
setup.
<db_server># ssh <username>@<ss_name>
The authenticity of host '<ss_name>' can't be established.
DSS key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:x:xx:xx.
Are you sure you want to continue connecting (yes/no)?
yes
Warning: Permanently added '<ss_name>' (DSS) to the list of
known hosts.
where:
• <username>is the CLI user created in “Setting Up Connections from the Backup Server to
the HP 3PAR Storage System” (page 35).
• <ss_name> is the name of the HP 3PAR StoreServ Storage system attached to the database
server.
38 Configuring Recovery Manager for Oracle
Setting up National Language Host Support
The Recovery Manager for Oracle message catalog and the symbolic link are installed in the
following locations:
Recovery Manager for Oracle Message Catalog
LocationOS
Symbolic Link Location
/usr/lib/locale/en_US/opt/3PAR/msg/en_USSolaris
/usr/lib/locale/en_US/opt/3PAR/RMOra/msg/en_USLinux
/usr/lib/nls/msg/C/opt/3PAR/msg/en_USHP UX
• To retrieve the text messages properly, you must set the NLSPATH path environment; for
example:
# NLSPATH=$NLSPATH:/usr/lib/locale/%L/%N
# export NLSPATH
Setting up Manual Pages on Database and Backup Servers
Recovery Manager for Oracle provides manual pages in the /opt/3PAR/man directory for
Solaris and HP UX systems, and in the /opt/3PAR/RMOra/man directory for Linux systems.
• To access the manual pages, define the environment variable MANPATH as follows:
# MANPATH=$MANPATH:/opt/3PAR/man
# export MANPATH
# LC_ALL=en_US
# export LC_ALL
For Linux systems, change the manual page directory to /opt/3PAR/RMOra/man.
Setting up a Search Path on Database and Backup Servers
Recovery Manager for Oracle executables are stored in the /opt/3PAR/RMOra/bin directory.
• To add the Recovery Manager executables to the Recovery Manager search path, use the
following commands:
# PATH=$PATH:/opt/3PAR/RMOra/bin
# export PATH
Setting Up NetBackup Policies for NBU (User-Managed) Backup
Recovery Manager for Oracle supports NetBackup (NBU) with or without RMAN. The following
sections describe how to set up NBU policies for NBU backup without RMAN.
Recovery Manager for Oracle supports full, incremental, or cumulative incremental archive log
backup (backup only archive logs). When performing NBU backup without RMAN, Recovery
Manager supports only full database backup (incremental database backup is not possible).
However, you can combine full database backup with archive log backup to simulate incremental
database backup.
Recovery Manager for Oracle requires that you create an NBU policy for database backup. If you
wish to perform archive log backup, you must create a separate NBU policy for it.
Setting up National Language Host Support 39
NOTE: This section assumes that you are familiar with the Oracle Database and Symantec
NetBackup (NBU). For more information on creating a NetBackup policy, refer to Symantec
NetBackup documentation.
Configuring the NetBackup Policy for Database Backup
For Recovery Manager for Oracle to perform backup and restoration correctly, you must use the
following guidelines in conjunction with Symantec NetBackup documentation when configuring a
NBU policy:
Backup Attribute 1. Select the standard type for the policy.
2. Select the cross mount points option.
3. Deselect the Allow multiple data stream and Block level incremental options.
Backup
Selections
Backup Schedule 1. Create a schedule for full backup.
Backup Clients
1. It is recommended that you enter /dummy for the backup selections.
2. Recovery Manager generates the backup selection list on the fly to replace the value you entered.
2. If you wish to perform immediate database backup (initiated from Recovery Manager), set the
backup window to 0.
3. If you also wish to perform automatic database backup (initiated from NBU), specify the backup
window to fit your needs.
Set the backup client to the host name of the backup server, as the backup process will actually
take place on the backup server.
Configuring the NetBackup Policy for Archive Log Backup
This procedure is to backup the archive logs only. For Recovery Manager for Oracle to perform
backup and restoration correctly, you must use the following guidelines in conjunction with Symantec
NetBackup documentation when configuring a NBU policy:
Backup Attribute 1. Select the standard type for the policy.
2. Select the cross mount points option.
3. Deselect the Allow multiple data stream and Block level incremental options.
Backup
Selections
1. It is recommended that you enter /dummy for the backup selections.
2. Recovery Manager generates the backup selection list on the fly to replace the value you entered.
Backup Schedule 1. Create two schedules, one for full backup and one for incremental backup (optional). For the
incremental backup schedule, you can create either a differential incremental or cumulative
incremental backup schedule.
NOTE: Incremental backup of archive log using RMAN is not supported.
2. If you wish to perform immediate archive log backup (initiated from Recovery Manager), set the
backup window to 0.
3. If you also wish to perform automatic archive log backup (initiated from NBU), specify the backup
window to fit your needs.
Backup Clients
Set the backup client to the host name of the backup server, as the backup process will actually
take place on the backup server.
Setting Up NetBackup Configuration Parameters for the Backup Server
Recovery Manager uses bpstart and bpend scripts as a hook to NetBackup to create Virtual Copy
of a database then present the database Virtual Copy to the backup server for backup and to
cleanup the Virtual Copy after backup process completes respectively. The BPSTART_TIMEOUT
and BPEND_TIMEOUT in the /usr/openv/netbackup/bp.conf on the backup server should
40 Configuring Recovery Manager for Oracle
be set to at least 600 seconds (10 minutes) to allow enough time for Recovery Manager to perform
all necessary operations prior to the actual backup.
For example, to set the BPSTART_TIMEOUT and BPEND_TIMEOUT parameters to 600 seconds (5
minutes), modify the corresponding parameters in /usr/openv/netbackup/bp.conf on the
backup server as follows:
BPSTART_TIMEOUT = 600
BPEND_TIMEOUT = 600
Setting Up NetBackup Configuration Parameters for the Database Server
If a database is setup for High Availability (HA), then the CLIENT_NAME parameter in the
/usr/openv/netbackup/bp.conf on the database server should be set to the virtual host
name of the database server instead of the physical host name. This allows a backup image to be
restored to the actual database server even the database has fail-overed to another database
server.
For example, to set the CLIENT_NAME parameter to a virtual host name, modify the corresponding
parameter in the /usr/openv/netbackup/bp.conf on the database server as follows:
CLIENT_NAME = <virtual_hostname>
Setting Up NetBackup Policies for Oracle RMAN Backup
The following sections describe how to set up NetBackup (NBU) policies for NBU backup with
RMAN.
To perform NBU backup with RMAN, you must have Symantec NetBackup for Oracle (NBU Agent
for Oracle) installed on the NBU master server, Symantec NetBackup client for Oracle installed
on the database server and the backup server. Refer to Symantec NetBackup for Oracle for
installation and configuration instructions.
In addition, you must create an Oracle RMAN Recovery Catalog and configure Oracle TNS Service
and Listener to allow connections to the Recovery Catalog from the database and backup servers.
The Recovery Catalog can be created on any server. Recovery Manager for Oracle recommends
that the Recovery Catalog is created on the backup server. See “Creating an RMAN Recovery
Catalog” (page 42) for instructions.
When perform NBU backup with RMAN, Recovery Manager supports full, differential, and
cumulative incremental database backup. Recovery Manager also support full archive log backup
(backup only archive logs).
Recovery Manager for Oracle requires that you create a NBU policy for database backup. If you
wish to perform archive log backup, you must create a separate NBU policy for it.
NOTE: This section assumes that you are familiar with Oracle Database and Symantec NetBackup
(NBU). For more information on how to create NetBackup policy, refer to Symantec NetBackup
for Oracle documentation.
Configuring the NetBackup Policy for Database Backup with RMAN
NOTE: NBU automatic backup (initiated by the NBU scheduler) can now be used when Recovery
Manager for Oracle is configured to run as either the root user or Oracle owner. Previously, NBU
automatic backup was only available if Recovery Manager for Oracle was configured for the root
user.
NOTE: If Recovery Manager for Oracle is configured to be run as an Oracle user and this is an
upgrade from previous Recovery Manager release, the rmora_config command must be run
again for each database that is configured for automatic backup.
Setting Up NetBackup Policies for Oracle RMAN Backup 41
For Recovery Manager for Oracle to perform backup and restoration correctly, you must use the
following guidelines in conjunction with Symantec NetBackup documentation when configuring a
NBU policy:
Select the Oracle type for the policy.Backup Attribute
Backup Selections 1. Enter the location of RMAN backup script
(/etc/3par/solutions/<db_server>.ora<oracle_sid>/rmora_nbu_dbbackup.sh).
2. Recovery Manager for Oracle will generate the RMAN backup script at the specified location
when you create the configuration file (see below for details).
Backup Schedule 1. Create two schedules, one for full backup and one for incremental backup (optional). For
the incremental backup schedule, you can create either a differential incremental or cumulative
incremental backup schedule.
2. If you wish to perform immediate database backup (initiated from Recovery Manager), set
the backup window to 0.
3. If you also wish to perform automatic database backup (initiated from NBU), specify the
backup window to fit your needs.
Backup Clients
Set the backup client to the host name of the backup server, as the backup process will actually
take place on the backup server.
Configuring the NetBackup Policy for Archive Log Backup
NOTE: NBU automatic backup can be used when Recovery Manager for Oracle is configured
to run as both root user and Oracle owner.
NOTE: If Recovery Manager for Oracle is configured to be run as an Oracle user and this is an
upgrade from previous Recovery Manager for Oracle release, the rmora_config command
must be run again for each database that is configured for automatic backup.
This procedure is to backup archive logs only. For Recovery Manager for Oracle to perform backup
and restoration correctly, you must use the following guidelines in conjunction with Symantec
NetBackup documentation when configuring a NBU policy:
Select the Oracle type for the policy.Backup Attribute
Backup Selections 1. Enter the location of RMAN backup script
(/etc/3par/solutions/<db_server>.ora.<oracle_sid>/rmora_nbu_archbackup.sh).
2. Recovery Manager will generate the RMAN backup script at the specified location when
you create the configuration file (see below for details).
Recovery Manager will generate the RMAN backup script at the specified location when you
create the configuration file (see Recovery Manager for Oracle Configuration Files for details).
Backup Schedule 1. Create a schedule for full backup.
2. If you wish to perform immediate archive log backup (initiated from Recovery Manager for
Oracle), set the backup window to 0.
3. If you also wish to perform automatic archive log backup (initiated from NBU), specify the
backup window to fit your needs.
Backup Clients
Set the backup client to the host name of the backup server, as the backup process will actually
take place on the backup server.
Creating an RMAN Recovery Catalog
This section describes how to create and configure an RMAN Recovery Catalog. Refer to Oracle
documentation for more detailed information.
42 Configuring Recovery Manager for Oracle
1. Create a database for housing the Recovery Catalog. Oracle suggests the following disk
space requirements:
• System tablespace: 100 MB
• Temp tablespace: 5 MB
• Rollback segment: 5 MB
• Online redo log: 1 MB (each)
• Recovery Catalog: 10 MB
2. Create a tablespace for the Recovery Catalog as follows:
$ export ORACLE_SID=<catdb>
$ export ORACLE_HOME=<oracle_home>
$ sqlplus "/as sysdba"
SQL> create tablespace <cat_tbs> datafile '<path/filename>' size 10M;
SQL> exit
where:
• <catdb> is the Oracle Instance ID of the Recovery Catalog.
• <cat_tbs> is the Recovery Catalog tablespace name.
• <path/filename> is the file path where the datafile is created.
3. Create a user for the Recovery Catalog as follows:
$ sqlplus "/as sysdba"
SQL> create user <rman_user> identified by <rman_password>
temporary tablespace temp
default tablespace <cat_tbs>
quota unlimited on <cat_tbs>;
SQL> grant connect, resource, recovery_catalog_owner to <rman_user>;
where:
• <tbs_name> is the tablespace name of the Recovery Catalog.
• <rman_user> is the user name to be granted access permission to the Recovery Catalog.
• <rman_password> is the password for the <rman_user>.
4. Create the RMAN Recovery Catalog tables as follows:
$ rman catalog <rman_user>/<rman_password>@<catdb>
RMAN> create catalog tablespace <cat_tbs>;
5. Configure TNS services for the Recovery Catalog database by adding an entry in the
$ORACLE_HOME/network/admin/listener.ora file on the database server and backup
server as follows:
<catdb> =
(description =
(address = (protocol = TCP) (host = <cat_host>) (port = 1521))
(connect_data = (server = dedicated) (service_name = <catdb>))
)
where <cat_host> is the host name of the host where the catalog is created.
Setting Up NetBackup Policies for Oracle RMAN Backup 43
6. Configure the Oracle listener for the Recovery Catalog database by adding an entry in the
$ORACLE_HOME/network/admin/listener.ora file on the host where the Recover
Catalog is created as follows:
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = <catdb>)
(ORACLE_HOME = <oracle_home>)
(SID_NAME = <catdb>)
)
)
7. Log in as the Oracle owner user and register the database on the database server.
NOTE: If Recovery Manager for Oracle is used to run against an Oracle standby database,
you must register the primary database on the primary database server instead of the standby
database.
$ rman target / catalog <rman_user>/<rman_password>@<catdb>
RMAN> register database;
Recovery Manager for Oracle Configuration Files
For each database to be managed by Recovery Manager for Oracle, a configuration file must be
created first. There are two types of configuration files for Recovery Manager for Oracle:
• Recovery Manager for Oracle without Remote Copy support.
For this type of configuration, Recovery Manager for Oracle provides an integrated Symantec
NetBackup and Oracle RMAN for backups and restorations.
• Recovery Manager for Oracle with Remote Copy.
For this type of configuration, Recovery Manager for Oracle does not provide tools for media
backups and restorations.
NOTE: Before you create a database configuration:
• Verify that the required SSH setup was successfully completed.
• Ensure the primary database instance is up.
Creating a Recovery Manager for Oracle Configuration File without Remote Copy
You can create the Recovery Manager for Oracle configuration file using:
• Command Line Interface (CLI)
• Graphical User Interface (GUI)
Creating Configuration Files Using the Command Line Interface on the Backup Server
To create a Recovery Manager for Oracle configuration file without Remote Copy support:
1. From the backup server, enter /opt/3PAR/RMOra/bin/rmora_config.
44 Configuring Recovery Manager for Oracle
2. When prompted, press ENTER.
• ORACLE_SID of the database instance [h=help,q=quit]?
Enter ORACLE_SID of the database instance that you want to configure. If the database is an
RAC database, enter ORACLE_SID of any RAC instance.
• Hostname of the database server [h=help,q=quit]?
Enter the host name of the corresponding database server where the specified database
instance is running.
• Oracle Home of the database instance on the database server
[h=help,q=quit]?
Recovery Manager for Oracle provides a default value for the Oracle Home of the specified
database instance if it can be retrieved from the oratab file.
Press ENTER to accept default value or enter the ORACLE_HOME location of the specified
database instance.
• Oracle Home of database instance on the backup server
[h=help,s=skip,q=quit]?
Recovery Manager for Oracle assumes that the ORACLE_HOME on the backup server is the
same as the ORACLE_HOME on the database server. This ORACLE_HOME is needed to
create a clone database or to perform RMAN backup on the backup server. If you do not
intend to use these capabilities, skip it by entering s.
NOTE: RMAN backup requires the cloned database in mounted status. Therefore,
ORACLE_HOME must be installed on the backup server.
Press ENTER to accept default value or enter the ORACLE_HOME location on the backup
server.
• Oracle Home of ASM instance on the database server [h=help,q=quit]?
Recovery Manager for Oracle detects if the specified Oracle instance is managed by ASM.
If it is, Recovery Manager for Oracle prompts this question and provides a default value for
the ORACLE_HOME of the ASM instance on the database server if it can be retrieved from
the oratab file.
Press ENTER to accept the default value or enter ORACLE_HOME of the ASM instance on the
database server.
• Oracle Home of ASM instance on the backup server
[h=help,s=skip,q=quit]?
Recovery Manager for Oracle assumes that the ORACLE_HOME of the ASM instance on the
backup server is the same as the ORACLE_HOME of the ASM instance on the database server.
Press ENTER to accept the default value or enter ORACLE_HOME of the ASM instance on the
backup server.
• Do you want to setup configuration for remote copy? [y,n,q]? (n)
Select n if this configuration is not for a Remote Copy configuration.
NOTE: This feature requires the HP 3PAR Remote Copy Software license.
• HP 3PAR Storage system host name [h=help,q=quit]?
Enter the system name of the HP 3PAR Storage system connecting to the database and the
backup servers. The name of the HP 3PAR Storage system can be retrieved from the output
of the showsys HP 3PAR OS CLI command.
Recovery Manager for Oracle Configuration Files 45
• HP 3PAR Storage system user name for the database server
[h=help,q=quit]?
Recovery Manager for Oracle requires that a HP 3PAR OS Software user must have been
created on the HP 3PAR Storage system to allow access from the database server to the HP
3PAR Storage system.
• HP 3PAR Storage system user name for the backup server
[h=help,q=quit]?
Recovery Manager for Oracle requires that a HP 3PAR OS Software user must have been
created on the HP 3PAR Storage system to allow access from the backup server to the HP
3PAR Storage system.
• Enter Virtual Copy retention time in days(d|D) or hours(h|H)
[h=help,s=skip,q=quit]?
Specifies the amount of time relative to the creation time that the Virtual Copy will be retained.
Input value should be a positive integer and in the range of 1 hour - 43800 hours (1825
days). d/D means days. h/H means hours. The default value is 0: by default, no retention
time is set for read-only Virtual Copies.
This prompt only appears in HP 3PAR Operating System Software OS 2.3.1 or above.
NOTE: This feature requires the HP 3PAR Virtual Lock Software license.
NOTE: If the database volumes do not belong to any domain, then the retention time of the
read-only Virtual Copy cannot exceed the VVRetentionTimeMax value of the system. The
VVRetentionTimeMax default value for the system is 14 days. If the database volumes
belong to a domain, then the retention time of the read-only Virtual Copy cannot exceed the
VVRetentionTimeMax value of the domain, if set. The retention time cannot be removed
or reduced once it is set. The retention time can be extended by rmora_set command. The
VVRetentionTimeMax value can be checked via HP 3PAR OS Software CLI commands
showsys -param and showdomain -d.
• Enter Virtual Copy expiration time in days(d|D) or hours(h|H)
[h=help,s=skip,q=quit]? (default=0d) h
There are two ways to maintain the Virtual Copies in the HP 3PAR StoreServ Storage system:
◦ Time-based policy: Enter an expiration time. When Virtual Copies expire, they are
automatically removed from the system.
To enter an expiration time, enter the amount of time, relative to the current time, that all
future Virtual Copies will expire. Valid expiration times range between 1 to 43,800 hours
(1825 days). You can specify the value in days or hours by adding either 'd' or 'D' for
day, or 'h' or 'H' for hours after the amount of time. The default value, '0d', means the
Virtual Copy has no expiration time.
◦ Count-based or numeric-based policy: Either skip this question or use the default value
'0' for the expiration date. You will be prompted for the maximum Virtual Copies you
want the system to keep.
NOTE: The numeric-based policy is deprecated and will be removed in a future release.
• Enter maximum number of Virtual Copies allowed [h=help,q=quit]?
You will be prompted with this question if you did not set an expiration for a Virtual Copy in
the previous question. Enter the maximum number of Virtual Copies that can be created for
the specified database. Once the maximum number of Virtual Copies for the database is
46 Configuring Recovery Manager for Oracle
reached, Recovery Manager for Oracle removes the oldest Virtual Copy before creating a
new one.
The default maximum number is 500 read-only Virtual Copies for each volume.
• Do you want to remove oldest Virtual Copy when the maximum number
of Virtual Copy is reached [y=yes,n=no,q=quit]?
You will be prompted with this question if you set the maximum number of Virtual Copies in
the previous question. Enter n if you do not want to remove the oldest Virtual Copy when
maximum number of Virtual Copy is reached. Otherwise, enter y.
• Select third-party backup tool [0=None,1=NBU,2=RMAN,h,q]?
Recovery Manager for Oracle supports NBU (user-managed) backup and Oracle RMAN
backup.
NOTE: Oracle RMAN backup is the only method used to back up ASM-managed databases.
If the database is managed by ASM, the option 1=NBU does not appear.
Enter 0 if you do not want to perform backup.
If you enter 0, stop here. No further information is required. If you enter either 1 or 2, you
will be prompted for the following information:
• Remove Virtual Copy after backup complete? [y=yes,n=no,q=quit]?
Enter n if you do not want to remove the Virtual Copy after a backup is completed successfully.
Otherwise, enter y.
• Oracle RMAN Recovery Catalog connection string
[user/password@catdb,h=help,q=quit]?
You will only be prompted with this question if you previously selected Oracle RMAN as the
third-party backup tool.
Enter the Recovery Catalog connection string in user/passwd@catdb format, where catdb
is the service name of the Recovery Catalog, and user/passwd is the user name and
password to be used to connect to the Recovery Catalog.
• Oracle RMAN channel type [d=DISK,s=SBT_TAPE,h=help,q=quit]?
You will only be prompted with this question if you previously selected Oracle RMAN as the
third-party backup tool.
Enter d if you want to backup to local disk, or s if you want to backup to tape through Symantec
NetBackup Media server.
• Number of Oracle RMAN channels to be allocated [h=help,q=quit]?
You will only be prompted with this question if you previously selected Oracle RMAN as the
third-party backup tool.
Enter the number of RMAN channels to be allocated for backup.
• NetBackup master server name [h=help,q=quit]?
Enter the DNS host name of the Symantec NetBackup master server.
• NetBackup policy name for database/datafiles backup [h=help,q=quit]?
Recovery Manager for Oracle requires that an NBU backup policy must have been created
for database backup.
Recovery Manager for Oracle Configuration Files 47
• NetBackup full schedule name for policy 'your policy
name'[h=help,s=skip,q=quit]?
You will only be prompted with this question if you previously selected NBU as the third-party
backup tool.
Enter a schedule name for the policy provided for the previous question that is used to perform
full database backup.
• NetBackup policy name for archive log backup [h=help,s=skip,q=quit]?
A separate Symantec NetBackup policy must have been created for archive log backup if you
want to perform back up of archive logs only. Enter the archive log backup policy, or press
s to skip archive log backup.
• NetBackup full schedule name for policy 'your policy name'
[h=help,s=skip,q=quit]?
You will only be prompted with this question if you previously selected NBU as the third-party
backup tool.
Enter a schedule name of type full for the policy that is used to perform archive log backup.
• NetBackup incremental schedule name for policy 'your policy name'
[h=help,s=skip,q=quit]?
You will only be prompted with this question if you previously selected NBU as the third-party
backup tool.
Enter a schedule name of type differential/cumulative incremental for the policy that is used
to perform archive log backup.
Creating a Recovery Manager for Oracle Configuration File using the GUI on the backup server
To use the Recovery Manager for Oracle GUI to create a configuration file without Remote Copy
support:
1. Start the Recovery Manager for Oracle GUI on the backup server.
a. Ensure the X11 server is running on the destination host where the GUI is displayed. If
the X11 server is not running, issue the following command:
<backup_server># xhost +
b. Ensure the DISPLAY environment variable is set.
<backup_server># echo $DISPLAY
c. Start the Recovery Manager GUI.
<backup_server># rmoragui
If you have not specified /opt/3PAR/RMOra/bin in the PATH environment variable, run
rmoragui using the full path: /opt/3PAR/RMOra/bin/rmoragui
2. From the navigation window, right-click either the Oracle Servers node or a host node, and
then select New Configuration.
The Configure Recovery Manager Properties wizard appear.
3. Configure the host, database, and HP 3PAR StoreServ Storage system properties by entering
the requested information on the wizard screens and clicking Next.
48 Configuring Recovery Manager for Oracle
4. In the Recovery Manager Policy wizard screen, set either a numeric or time-based policy. Click
Next.
5. In the Vendor Backup Product Properties wizard screen, select the Vendor Backup Product
from the menu.
6. Click Finish.
If Recovery Manager for Oracle successfully connects to the database, it retrieves the database
tablespaces, datafiles, the archive log destination, and the virtual volumes where the database
resides.
After verification is completed, Recovery Manager for Oracle creates a Virtual Copy repository
on the backup server (/etc/3par/solutions/<db_server>.ora.<oracle_sid>)
and two configuration files are generated along with one subdirectory for database files
mapping information.
/etc/3par/solutions/<db_server>.ora.<oracle_sid>/config
/etc/3par/solutions/<db_server>.ora.<oracle_sid>/config_exp.sh
/etc/3par/solutions/<db_server>.ora.<oracle_sid>/gui
Creating a Recovery Manager for Oracle Configuration File for Remote Copy Configuration
Before creating the configuration files for Recovery Manager for Oracle to use, you must do the
following:
• Set up physical links between the local and remote HP 3PAR StoreServ Storage systems. Refer
to the HP 3PAR Remote Copy Software User’s Guide for instructions on setting up links.
• Set up Remote Copy targets for the local and remote HP 3PAR StoreServ Storage systems.
• Create one or two Remote Copy groups, assign all virtual volumes used by datafiles and
archive log destinations to one group if only one group is created, or two separate groups if
two groups are created.
CAUTION: Symantec Volume Manager VxVM: If Symantec Volume Manager VxVM is being
used when assigning 3PAR virtual volumes to Remote Copy groups, all volumes in the same
VxVM disk group should be assigned to a Remote Copy group, whether they are actually
being used by the Oracle database or not. Otherwise, you might not be able to import and
mount file systems on the remote backup server. Therefore, it is strongly suggested that Symantec
VxVM disk groups only contain files used by one Oracle database.
HP or Linux LVM Volume Manager: If you are using HP or Linux LVM Volume Manager, you
must admit all HP 3PAR virtual volumes that are used by the LVM volume groups to the
corresponding Remote Copy volume group, whether the volumes are actually being used by
the Oracle database or not. If you do not do so, you might not be able to import and mount
file systems on the remote backup system.
• Start Remote Copy and verify its setup and ensure that the Remote Copy groups are in started
status and all virtual volumes are synced before using Recovery Manager for Oracle.
Creating a Recovery Manager for Oracle Configuration File Using the Command Line Interface
To create the Recovery Manager for Oracle configuration files:
1. From the backup server, issue /opt/3PAR/RMOra/bin/rmora_config.
2. When prompted, press ENTER.
Recovery Manager for Oracle Configuration Files 49
3. When prompted, answer the following questions:
• ORACLE_SID of the database instance [h=help,q=quit]?
Enter ORACLE_SID of the database instance that you want to configure. If the database is an
RAC database, enter ORACLE_SID of any RAC instance.
• Host name of the database server [h=help,q=quit]?
Enter the host name of the corresponding database server where the specified database
instance is running.
• Oracle Home of the database instance on the database server
[h=help,q=quit]?
Recovery Manager for Oracle provides a default value for the ORACLE_HOME of the specified
database instance if it can be retrieved from the oratab file.
Press ENTER to accept default value, or enter ORACLE_HOME location of the specified database
instance.
• Oracle Home of database instance on the backup server
[h=help,s=skip,q=quit]?
Recovery Manager for Oracle assumes that the ORACLE_HOME on the backup server is the
same as the ORACLE_HOME on the database server.
Press ENTER to accept default value, or enter the ORACLE_HOME location on the backup
server. This ORACLE_HOME is needed to create a clone database or to perform RMAN
backup on the backup server. If you do not intend to use these capabilities, you may skip it
by entering s.
• Oracle Home of ASM instance on the database server [h=help,q=quit]?
Recovery Manager for Oracle detects if the specified Oracle instance is managed by ASM.
If it is, Recovery Manager for Oracle prompts this question and provides a default value for
the ORACLE_HOME of the ASM instance on the database server if it can be retrieved from
the oratab file.
Press ENTER to accept the default value, or enter the ORACLE_HOME of the ASM instance
on the database server.
• Oracle Home of ASM instance on the backup server [h,q]?
Recovery Manager for Oracle assumes that the ORACLE_HOME of the ASM instance on the
backup server is the same as the ORACLE_HOME of the ASM instance on the database server.
Press ENTER to accept the default value, or enter ORACLE_HOME of the ASM instance on the
backup server.
• Do you want to setup configuration for remote copy? [y,n,q]? (y)
Select y if this is this configuration is for Remote Copy.
• Primary/Local storage system host name [h=help,q=quit]?
Enter the system name of the primary/local HP 3PAR StoreServ Storage system that is connected
to the database server. The HP 3PAR StoreServ Storage system name can be retrieved from
the output of HP 3PAR OS Software CLI showsys command.
• Secondary/Remote storage system host name [h=help,q=quit]?
Enter the system name of the Secondary/Remote HP 3PAR StoreServ Storage system that is
connected to the backup server. The HP 3PAR StoreServ Storage system name can be retrieved
from the output of the HP 3PAR OS Software CLI showsys command.
50 Configuring Recovery Manager for Oracle
• Primary/Local storage system user name [h=help,q=quit]?
Recovery Manager for Oracle requires that a HP 3PAR Operating System Software user must
have been created on the primary/local HP 3PAR StoreServ Storage system to allow access
from the database server to the primary/local HP 3PAR StoreServ Storage system.
• Secondary/Remote storage system user name [h=help,q=quit]?
Recovery Manager for Oracle requires that a HP 3PAR Operating System Software user must
have been created on the Secondary/Remote HP 3PAR StoreServ Storage system to allow
access from the backup server.
• Enter Virtual Copy retention time in days(d|D) or hours(h|H)
[h=help,s=skip,q=quit]?
Specifies the amount of time relative to the creation time that the Virtual Copy will be retained.
Input value should be a positive integer and in the range of 1 hour to 43800 hours (1825
days). d/D means days. h/H means hours. A value of 0 specifies that there is no retention
time set for read-only Virtual Copies.
This question is only prompted for HP 3PAR Operating System Software 2.3.1 or above.
• Enter Virtual Copy expiration time in days(d|D) or hours(h|H)
[h=help,s=skip,q=quit]? (default=0d)
There are two ways to choose how to maintain the Virtual Copies in the HP 3PAR StoreServ
Storage system:
◦ Time-based policy: Enter an expiration time. When Virtual Copies expire, they are
automatically removed from the system.
To enter an expiration time, enter the amount of time, relative to the current time, that all
future Virtual Copies will expire. Valid expiration times range between 1 to 43,800 hours
(1825 days). You can specify the value in days or hours by adding either 'd' or 'D' for
day, or 'h' or 'H' for hours after the amount of time. The default value, '0d', means the
Virtual Copy has no expiration time.
◦ Count-based or numeric-based policy: Either skip this question or use the default value
'0' for the expiration date. You will be prompted for the maximum Virtual Copies you
want the system to keep.
NOTE: The numeric-based policy is deprecated and will be removed in a future release.
• Maximum number of Virtual Copies allowed [h=help,q=quit]?
You will be prompted with this question if you did not set an expiration time for a Virtual Copy
in the previous question. Enter the maximum number of Virtual Copies that can be created for
the specified database. Once the maximum number of Virtual Copies for the database is
reached, Recovery Manager for Oracle removes the oldest Virtual Copy before creating a
new one.
The default maximum number is 500 read-only Virtual Copies for each volume.
• Remove the oldest Virtual Copy when the maximum number of Virtual
Copy is reached [y=yes,n=no,q=quit]?
NOTE: This feature requires the HP 3PAR Virtual Lock Software license.
You will be prompted with this question if you set the maximum number of Virtual Copies
allowed in the previous question. Enter n if you do not want to remove the oldest Virtual Copy
when maximum number of Virtual Copy is reached. Otherwise, enter y.
Recovery Manager for Oracle Configuration Files 51
NOTE: If the database volumes do not belong to any domain, then the retention time of the
read-only Virtual Copy cannot exceed the VVRetentionTimeMax value of the system. The
VVRetentionTimeMax default value for the system is 14 days. If the database volumes belong
to a domain, then the retention time of the read-only Virtual Copy cannot exceed the
VVRetentionTimeMax value of the domain, if set. The retention time cannot be removed or
reduced once it is set. The retention time can be extended by rmora_set command. The
VVRetentionTimeMax value can be checked via the HP 3PAR Operating System Software CLI
commands showsys -param and showdomain -d.
Creating a Recovery Manager for Oracle Configuration File using the GUI
To use the Recovery Manager for Oracle GUI to create a configuration file with Remote Copy
support, perform the following:
1. Start the Recovery Manager for Oracle GUI on the backup server.
a. Ensure the X11 server is running on the destination host where the GUI is displayed. If
the X11 server is not running, issue the following command:
<backup_server># xhost +
b. Ensure the DISPLAY environment variable is set.
<backup_server># echo $DISPLAY
c. Start the Recovery Manager for Oracle GUI.
<backup_server># rmoragui
If you have not specified /opt/3PAR/RMOra/bin in the PATH environment variable, run
rmoragui using the full path: /opt/3PAR/RMOra/bin/rmoragui
2. From the navigation window, right-click either the Oracle Servers node or a host node, and
then select New Configuration.
3. Configure the requested parameters in the wizard screens and click Next.
4. In the HP 3PAR Storage system Properties wizard screen:
a. Select the Remote Copy option.
b. Enter the requested HP 3PAR Storage system information.
c. Click Next.
5. In the Recovery Manager Policy wizard screen, set either a numeric or time-based policy. Click
Next.
6. In the Vendor Backup Product Properties wizard screen, select the Vendor Backup Product
from the menu.
52 Configuring Recovery Manager for Oracle
7. Click Finish.
If Recovery Manager for Oracle successfully connects to the database, it retrieves the database
tablespaces, datafiles, the archive log destination, and the virtual volumes where the database
resides.
After verification is complete, Recovery Manager for Oracle creates a Virtual Copy repository
on the backup server (/etc/3par/solutions/<db_server>.ora.<oracle_sid>),
and two configuration files are generated along with one subdirectory for database files
mapping information.
/etc/3par/solutions/<db_server>.ora.<oracle_sid>/config
/etc/3par/solutions/<db_server>.ora.<oracle_sid>/config_exp.sh
/etc/3par/solutions/<db_server>.ora.<oracle_sid>/gui
Recovery Manager for Oracle Configuration Files 53
4 Using the Recovery Manager Command Line Interface
This chapter describes the Recovery Manager for Oracle command line utilities.
NOTE: The command line utilities are located in /opt/3PAR/RMOra/bin.
To view error messages, their explanations, and appropriate troubleshooting actions in a web
browser, select Help→Event Messages from the menu bar. Alternatively, see “Troubleshooting”
(page 140).
Recovery Manager Commands
rmora_backup
SYNTAX
rmora_backup -s <oracle_sid> -p <db_server> [-t <timestamp>] [-o
full|incr|cinc] [-v]
or
rmora_backup -s <oracle_sid> -p <db_server> [-o
online|offline|datafile|archlog|archonly[,full|incr|cinc]] [-v]
DESCRIPTION
Recovery Manager for Oracle integrates HP 3PAR Virtual Copy Software feature with Symantec
NetBackup (NBU) and Oracle RMAN to perform snapshot off-host backup. Snapshot off-host
backup can dramatically reduce performance impact on the database server as well as minimize
database down time or the time database in backup mode during backup.
The first form of rmora_backup command initiates an immediate backup of an existing database
Virtual Copy. The Virtual Copy must have Available status (not mounted) in order to be backed
up. The rmora_backup command mounts (presents) the Virtual Copy to the backup server before
initiating an immediate backup (off-host).
The second form of rmora_backup command creates a new database Virtual Copy, mounts
(presents) it to the backup server before initiating an immediate backup (off-host). If the database
being snapshot is a physical standby database and Oracle release is not 11g, the Oracle parameter
file and control file of the production database must be backed up manually in addition to the
Virtual Copy. This is because the parameter file and control file are not compatible between the
standby and production database.
Recovery Manager for Oracle supports NBU (user-managed) backup and Oracle RMAN backup
methods, which can be specified during the Recovery Manager for Oracle configuration process.
If Oracle RMAN is used for backup, the primary (not standby) database must be registered with
the Oracle Recovery Catalog Database. For the Oracle RMAN backup method, you can select
the SBT_TAPE or DISK option to backup to tape or to a local disk on a backup server, respectively.
Starting with Oracle 11g, an RMAN backup image of a standby database to local disk cannot
be seen from the Recovery Catalog from the production database. Therefore, the backup image
cannot be restored to the production database using the rmora_restore command. Please see
the rmora_restore command man page on how to perform restore manually. Regardless of
backup method, Recovery Manager for Oracle supports full backup of an Oracle database or
archive log destination. However, incremental (differential or cumulative) backup of the whole
Oracle database is only available for Oracle RMAN backup method. Incremental (differential or
cumulative) backup of archive log destination is only available for NBU (User-managed) backup
method.
Backup is not supported on Remote Copy configuration.
54 Using the Recovery Manager Command Line Interface
The following list describes the restrictions and automated scripts that are generated when
configuring Recovery Manager. The automated scripts will be executed while the rmora_backup
command is running.
For NBU (user-managed) backup:
• The Symantec NetBackup client must be installed on the backup server and database server.
• At least one NBU policy of standard type must be created and configured for database backup.
Optionally, a separate NBU policy of standard type can be created and configured for archive
log backup.
For Oracle RMAN backup (to tape or local disk):
• The backup server must have an equal or higher Oracle major release version than the Oracle
major release version on the database server.
• To perform RMAN backup to tape, the Symantec NetBackup client must be installed on the
backup server and database server. In addition, Symantec NetBackup for Oracle (Oracle
Agent) must be installed on the backup server, database server, and the NBU master server.
• To perform RMAN backup to tape, at least one NBU policy of Oracle type must be created
and configured for database backup. Optionally, a separate NBU policy of Oracle type can
be created and configured for archive log backup.
• Regardless of tape or disk backup, an Oracle RMAN Recovery Catalog database must be
created and configured prior to running this command.
Depending on which backup method has been configured for the Recovery Manager, the
rmora_backup command performs the following actions:
• Creates a Virtual Copy (online, offline, datafile, or archlog) for the database or archive log
destination if a Virtual Copy is not specified. If VCRETENTION is specified in the configuration
file, the create operation will use -f option to force to create the read-only Virtual Copy with
a retention time.
• Mounts the Virtual Copy on the backup server.
• For NetBackup (user-managed) backups:
Generates an include list file, which contains a list of datafiles and/or the archive log
◦
destination, on the mounted Virtual Copy and stores it in
/usr/openv/netbackup/include_list.<policy_name> on the NetBackup client
(the backup server).
◦ Initiates an immediate backup of the Virtual Copy by calling the NetBackup bpbackup
command on the NetBackup master server.
• For Oracle RMAN backups:
Starts up a clone database in MOUNTED mode, using the mounted Virtual Copy on the
◦
backup server.
◦ Executes the RMAN backup script rmora_rman_dbbackup.sh or
rmora_rman_archbackup.sh to back up the clone database.
NOTE: The RMAN backup scripts rmora_rman_dbbackup.sh and
rmora_rman_archbackup.sh are generated in
/etc/3par/solutions/<db_server>.ora.<oracle_sid> when you create the
Recovery Manager configuration file.
You must run this command as a super user or Oracle owner user from the backup server. To allow
the Oracle Database Administrator (Oracle Owner) to run this command, an identical Oracle
Database Administrator user must exist on the backup server. If the Symantec NetBackup master
Recovery Manager Commands 55
server is separate from the Recovery Manager for Oracle backup server, the Oracle Database
Administrator user and group must exist on the NetBackup master server. In addition, permission
on the Recovery Manager for Oracle Installation and Repository directories must be changed
appropriately.
OPTIONS
The following options are supported:
-s <oracle_sid>
The Oracle SID of the database instance. For Real Application Cluster (RAC) database, an Oracle
SID of any RAC instance can be specified.
-p <db_server>
The host name of the database server, on which the Oracle database instance is running. The
value of the database server name must match the output of the hostname command.
-t <timestamp>
The timestamp of a Virtual Copy to be backed up. The Virtual Copy name can be obtained using
the rmora_display command.
-o online
Creates an online Virtual Copy of a database while it is OPEN (online) prior to backup. This option
is ignored if a Virtual Copy is specified. The offline, online, datafile, and archlog
options are mutually exclusive.
-o hotbkup
This option is the same as the -o online option. This option is deprecated and will be removed
at a later release.
-o offline
Creates an offline Virtual Copy of a database while it is CLOSED (offline) prior to backup. This
option is ignored if a Virtual Copy is specified. The offline, online, datafile, and archlog
options are mutually exclusive.
-o coldbkup
Same as the -o offline option. This option is deprecated and will be removed at a later release.
-o datafile
Creates an Virtual Copy for all datafiles (not including the archive log destinations and temporary
datafile) of a database while it is OPEN (online) prior to backup. This option is ignored if a Virtual
Copy is specified. The online, offline, datafile, and archlog options are mutually
exclusive. A Virtual Copy created with the -o datafile option is only useful when archive
logfiles generated during the creation of the Virtual Copy are also available. You may want to
create separate Virtual Copies using the -o archlog options, or use another backup method to
backup archive log destinations.
-o archlog
Creates a Virtual Copy of the archive log destination prior to backup. This option cannot be used
if a Virtual Copy is specified. The offline, online, datafile, and archlog options are
mutually exclusive.
-o archonly
Same as the -o archlog command. This option is deprecated.
-o full
Performs a full backup of a Virtual Copy. If Symantec NetBackup is selected as the backup method,
this option can be used with the -o archlog option to perform full backup of an archlog
Virtual Copy. Recovery Manager for Oracle will only use one incremental schedule name for either
56 Using the Recovery Manager Command Line Interface
differential incremental or cumulative incremental backup, which is predefined in the NBU schedule.
If Oracle RMAN is selected as the backup method, this option can be used to perform full backup
of an online or offline Virtual Copy.
-o incr
Performs an incremental backup of a Virtual Copy. If Symantec NetBackup is selected as the backup
method, this option can be used with the -o archlog option to perform incremental backup of
an archlog Virtual Copy. If Oracle RMAN is selected as the backup method, this option can be
used to perform an incremental backup of an online or offline Virtual Copy.
-o cinc
Performs a cumulative incremental backup of a Virtual Copy. If Symantec NetBackup is selected
as the backup method, this option can be used with the -o archlog option to perform a
cumulative incremental backup of an archlog Virtual Copy. Recovery Manager for Oracle will
only use one incremental schedule name for either differential incremental or cumulative incremental
backup, which is predefined in the NBU schedule. If Oracle RMAN is selected as the backup
method, this option can be used to perform a cumulative incremental backup of an online or offline
Virtual Copy.
-v
Runs the command in verbose mode.
Recovery Manager Commands 57
rmora_checkconfig
SYNTAX
rmora_checkconfig -s <oracle_sid> -p <db_server> [-o
all|skipdatabase|databaseonly] [-v]
DESCRIPTION
The rmora_checkconfig command validates a Recovery Manager for Oracle configuration
file for a specified database. A configuration file must have been created prior to using this
command.
By default, all configured parameters in the specified configuration file will be validated. One can
select to validate only database parameters or non-database parameters.
You must run this command as a super user or Oracle owner user from the backup server. To allow
the Oracle Database Administrator (Oracle owner) to run this command, an identical Oracle
Database Administrator user must exist on the backup server. In addition, permission on the Recovery
Manager for Oracle Installation and Repository directories must be changed appropriately.
OPTIONS
The following options are supported:
-s <oracle_sid>
The Oracle SID of the database instance. For Real Application Cluster (RAC) database, an Oracle
SID of any RAC instance can be specified.
-p <db_server>
The corresponding hostname of the database server where the specified Oracle database instance
is running. The value of the database server name must match the output of the hostname
command.
-o all
The default option. Validates all parameters specified in the Recovery Manager for Oracle
configuration file.
-o skipdatabase
Validates all non-database parameters specified in the Recovery Manager for Oracle Configuration
file.
-o databaseonly
Validates all database parameters specified in the Recovery Manager for Oracle Configuration
file.
-v
Runs the command in verbose mode.
rmora_chown
SYNTAX
rmora_chown -u <username> [-g <group>] [-s <oracle_sid> | -p
<db_server>][-v] [-f]
DESCRIPTION
The rmora_chown command changes and sets the owner and permissions for the Recovery
Manager for Oracle binaries to be run as an Oracle binary owner. By default, the Recovery
Manager for Oracle binaries and repositories are owned and used by the super user. This command
58 Using the Recovery Manager Command Line Interface
changes the permissions and owners of the necessary files and directories in order to enable an
Oracle binary owner to operate Recovery Manager for Oracle.
Each Recovery Manager for Oracle repository (under /etc/3par/solutions/) should be owned by
either the super user or the Oracle binary owner. Different repositories could be owned by different
Oracle binary owners. Without specifying the Oracle SID and the primary database server name,
the command changes all the repositories to be owned by the same specified user on the backup
server and all primary servers found from the repository names. In the case of Oracle RAC
configurations, ownership and permissions will be changed for all Oracle RAC nodes if applicable.
To change the owner of a certain repository, the -s <oracle_sid> flag and the -p <db_server> may
be used, which makes the change to the backup server, the specified primary server, and related
Oracle RAC nodes where applicable if the configuration is part of Oracle RAC configurations.
OPTIONS
The following options are supported:
-s <oracle_sid>
The Oracle SID of the database instance. For Real Application Cluster (RAC) database, an Oracle
SID of any RAC instance can be specified. This option is used along with the -p option to change
the ownership and permissions for one single repository on the backup server and the primary
database server.
-p <db_server>
The host name of the database server, where the specified Oracle database instance is running.
The host name value must match the output of the hostname command.
-u <username>
The valid user name for Oracle binary owner or Oracle home owner.
-g <group>
The valid group name which the Oracle owner belongs to.
-f Forces to change the owner and permissions without prompting.
-v Verbose mode.
Recovery Manager Commands 59
rmora_config
SYNTAX
rmora_config [-s <oracle_sid> -p <db_server>]
DESCRIPTION
The rmora_config command creates or modifies the Recovery Manager for Oracle configuration
file for a database. A configuration file for each database must be created prior to using any
database snapshot (Virtual Copy) utilities provided by Recovery Manager for Oracle. The
configuration file will be created at
/etc/3par/solutions/<db_server>.ora.<oracle_sid>/config.
An equivalent environment file (config_exp.sh) is also automatically created for each created
configuration file; it contains all configuration parameters specified in the configuration file. Recovery
Manager for Oracle uses the environment file, which is stored at the same location as the
configuration file.
rmora_config is an interactive command. The command will prompt for necessary information
depending on a user selection. Generally, the command will prompt for the following information:
• ORACLE_SID - The Oracle database instance ID. For an RAC database, ORACLE_SID can
be an SID of any instance.
• PRIMARYHOST - The hostname of the database server where the Oracle database instance
is running. The value of the database server name must match the output of the hostname
command.
• ORACLE_HOME - The location of Oracle Home on the database server of the specified database
instance.
• ORACLE_HOME_BACKUP - The location of Oracle Home on the backup server.
• ASM_ORACLE_HOME - The location of Oracle Home of the ASM instance on the database
server. This parameter is only required if the specified database is using ASM.
• ASM_ORACLE_HOME_BACKUP - The location of Oracle Home of the ASM instance on the
backup server. This parameter is only required if the specified database is using ASM.
• TPDHOST - The backup server name defined in the HP 3PAR StoreServ Storage system. The
hostname can be obtained from the output of the showhost CLI command, and may not be
the UNIX hostname of the backup server. If Recovery Manager for Oracle can automatically
retrieve the TPDHOST value, you will not be prompted with this question.
• TPDSYSNAME_PRIMARY - The HP 3PAR StoreServ Storage system node name, which is
connected to the database server
• TPDSYSNAME_BACKUP - The HP 3PAR StoreServ Storage system node name, which is
connected to the backup server.
• TPDUSERNAME_PRIMARY - The HP 3PAR StoreServ Storage system CLI user name to be used
to connect to the HP 3PAR StoreServ Storage system node from the database server or multiple
database servers if the HP 3PAR Operating System Software CLI user is set to multiple domains.
Recovery Manager for Oracle does not support CLI users with the default domain. The HP
3PAR Operating System Software CLI user must be assigned the edit role (privilege) or
3PAR_RM role.
• TPDUSERNAME_BACKUP - HP 3PAR StoreServ Storage system CLI user name to be used to
connect to the HP 3PAR StoreServ Storage system node from the backup server. This HP 3PAR
Operating System Software CLI user must be assigned the edit role (privilege) or 3PAR_RM
role.
• VCRETENTION - The default retention time for database Virtual Copies created using HP 3PAR
Recovery Manager for Oracle Software. The retention time is the amount of time, relative to
60 Using the Recovery Manager Command Line Interface
the current time, that the volume will be retained. To specify a retention time, specify a value
between 1 to 43,800 hours (1825 days).
Retention time considerations:
◦ This feature requires a separate HP 3PAR Virtual Lock license.
◦ The maximum retention time (VVRetentionTimeMax) is either the system's
VVRetentionTimeMax (1825 days) or the virtual domain's VVRetentionTimeMax.
– If the volume belongs to a domain, then its retention time cannot exceed the
VVRetentionTimeMax value of the domain (if set).
– If the volume does not belong to a domain, then its retention time cannot exceed the
VVRetentionTimeMax value of the system. The VVRetentionTimeMax default value
for the system is 14 days.
◦ If you are setting both an expiration time and a retention time, the retention time cannot
be longer than the expiration time.
◦ A value of 0 specifies that the database Virtual Copy be created without a retention time.
◦ After you set a retention time, you cannot remove or reduce the retention time.
• VCEXPIRATION - The default expiration time for database Virtual Copies created using
Recovery Manager for Oracle Software. This feature can be used to remove expired database
Virtual Copies automatically from the system. This feature is only applicable for HP 3PAR
Operating System Software 2.3.1 or above. The value is ranged from 0 to 1825 days. A
value of zero indicates that the database Virtual Copy is created without expiration. You can
set either the expiration time or the maximum number of Virtual Copies, but not both.
• VCDBA_MAXVC - The maximum number of the database Virtual Copies allowed at any time.
Enter a number between 1 and 500 (inclusive).
• VCDBA_RM_OLDVC - The flag indicates if an oldest Virtual Copy should be removed before
creating a new Virtual Copy when the number of Virtual Copies exceeds the maximum allowed.
• BACKUPTOOL - The backup method to be used for backing up a database Virtual Copy
(snapshot). The two backup methods currently supported by Recovery Manager for Oracle
are NBU backup and RMAN backup. If the specified database is an ASM-managed database,
the only supported backup method is RMAN backup.
• NBU_MASTER_SERVER - The Symantec NBU master server.
• DBFILE_CLASS_NAME - The Symantec NBU policy name for backing up database files.
• ARCH_CLASS_NAME - The Symantec NBU policy name for backing up archive logs.
• DBFILE_SCHED_FULL - The Symantec NBU schedule name for backing up database files.
• ARCH_SCHED_FULL - The Symantec NBU schedule name for backing up archive logs (full
backup).
• ARCH_SCHED_INCR - The Symantec NBU schedule name for backing up archive logs
(incremental backup).
• RMAN_CONN_STR - The RMAN connection string for connecting to the Oracle Recovery Catalog
from the database server and the backup server.
• RMAN_CHANNEL_TYPE - The RMAN channel type is either SBT_TAPE or DISK.
• RMAN_NO_CHANNEL - The number of RMAN channels to be allocated during backup and
restore.
Recovery Manager Commands 61
• RMAN_BACKUP_DEST - The backup destination to store RMAN backup image. This option is
only required if the specified RMAN channel type is DISK.
• RMVC_AFTER_BACKUP - Specifies whether the Virtual Copy should be removed after a
successful backup.
You must run this command as a super user or Oracle owner user from the backup server. To allow
the Oracle Database Administrator (Oracle Owner) to run this command, an identical Oracle
Database Administrator user must exist on the backup server. In addition, permission on the Recovery
Manager for Oracle Installation and Repository directories must be changed appropriately.
OPTIONS
The following options are supported:
-s <oracle_sid>
The Oracle SID of the database instance. For Real Application Cluster (RAC) database, an Oracle
SID of any RAC instance can be specified.
-p <db_server>
The host name of the database server where the specified Oracle database instance is running.
The host name value must match the output of the hostname command.
62 Using the Recovery Manager Command Line Interface
rmora_create
SYNTAX
rmora_create -s <oracle_sid> -p <db_server> [ -o
online|offline|datafile|archlog] [ -r <retention_time>{d|D|h|H} -f] [
-e <expiration_time>{d|D|h|H}] [-v]
DESCRIPTION
The rmora_create command can be used to create an online, offline, datafile, or archive log
Virtual Copy of a specified Oracle database instance. The Oracle database instance can be either
a regular database or a physical standby database. The database Virtual Copy can be set to be
retained for a period of time (retention time) preventing them from being removed accidentally or
intentionally. The database Virtual Copy can also be set to expire after a period of time (expiration
time) in which the storage system will remove the expired Virtual Copy automatically once the
expiration time is reached.
NOTE: This feature requires the HP 3PAR Virtual Copy Software license.
• An online or offline Virtual Copy is a consistent point-in-time snapshot image of the database
when it is online or offline, respectively.
• An archive log Virtual Copy is a snapshot image of the archive log destination only. You can
use the archive log Virtual Copy in conjunction with an online Virtual Copy to simulate an
incremental backup.
• A datafile Virtual Copy is a snapshot image of the datafiles only (without the archive logs). If
you use datafile Virtual Copies, be sure to back up the archive logs separately so they are
available for performing database restore and recovery from a datafile Virtual Copy. You
can mount the Virtual Copy on the backup server for any off-host processing purposes (for
example; backup or database cloning).
The specified database instance must be offline when creating an offline Virtual Copy or online
when creating an online, datafile or archive log Virtual Copy. The database instance is considered
to be offline if it is in CLOSED mode. If the database is a RAC database, all RAC instances must
be offline. The database instance is considered to be online if it is in OPEN mode (for regular
database) or in managed recovery mode (for physical standby database). If the database is a
RAC database, the specified database instance must be online, all other RAC instances can be
either online or offline.
If the database being snapshot is a physical standby database and Oracle release is not 11g, the
Oracle parameter file and control file of the production database must be backed up manually in
addition to the Virtual Copy. This is because the parameter file and control file are not compatible
between the standby and production database.
When you create an online or archlog Virtual Copy, a Virtual Copy is created for the virtual
volumes used by all MANDATORY archive log destinations. If there is no MANDATORY archive
log destination, a Virtual Copy is created for the virtual volumes used by all OPTIONAL archive
log destinations.
Recovery Manager for Oracle does not create Virtual Copies for virtual volumes used by Oracle
database temporary files, in order to be consistent with Oracle's backup procedure. However,
Recovery Manager for Oracle does take Virtual Copies for read-only and offline datafiles. (After
the database is cloned on the backup server, be sure to rename the read-only and offline datafiles
as appropriate: use the syntax in the ASCII control file that is saved in the timestamp repository to
replace the real file names that are based on the mount points during cloning.)
When creating an online or datafile Virtual Copy:
• If the specified database instance is a regular database, the database will be temporarily put
into backup mode before the Virtual Copy of datafile virtual volumes is created. The database
Recovery Manager Commands 63
will be then taken out of backup mode. An archive log switch will be performed before Virtual
Copies of archive log virtual volumes are created.
• If the specified database instance is a physical standby database, the database will be
temporarily taken out of managed recovery mode before the Virtual Copy of the datafile virtual
volumes is created. The database will then be put back into the original managed recovery
mode.
A datafile Virtual Copy alone cannot be used to restore and recover the database. An archive log
Virtual Copy can be used in conjunction with an online Virtual Copy to simulate an incremental
backup.
Once created, the Virtual Copy can be mounted on the backup server for off-host processing
purposes such as backup and database cloning. If the Virtual Copy will be backed up using Oracle
RMAN, the primary database (not the standby database) must be registered with the Oracle
Recovery Catalog Database.
To use the rmora_create command, the Oracle database structure must satisfy the following
requirements:
• The database must be running in archive log mode and automatic archival must be enabled
in order to create an online, datafile, or archive log Virtual Copy.
• Each database instance must be started up using either a parameter file (pfile or init.ora
file), or a server parameter file (spfile ) from default location ($ORACLE_HOME/dbs).
• If archive log mode is enabled, the datafiles and archive logs must reside on separate 3PAR
virtual volumes.
• The online redo logs and control files should not reside on the same 3PAR virtual volumes
used by the datafiles and archive logs to avoid being restored when using Recovery Manager
for Oracle Rollback feature. However, the online redo logs and control files can share the
same 3PAR virtual volumes.
• If the database files reside on Symantec VxVM volumes, the datafiles and archive logs must
reside on separate VxVM disk groups. The online redo logs and control files should reside on
separate VxVM volumes used by the datafiles and archive logs.
• If you use HP or Linux LVM Volume Manager, the Oracle datafiles and archive logs must
reside on separate LVM volume groups. In addition, online redo logs and control files must
not reside on LVM volume groups that are used by Oracle datafiles and archive logs. However,
the online redo logs and control files can reside on the same LVM volume group.
• If the Oracle database is an ASM-managed database, the Oracle datafiles and archive logs
must reside on separate ASM disk groups. The online redo logs and control files should not
reside on the same ASM disk groups used by the datafiles and archive logs to avoid being
restored when using the Recovery Manager Rollback feature. In addition, ASM disk groups
should not be shared between different databases.
• If the Oracle database is an RAC database, all RAC instances must share the same archive
log destinations (i.e., the same cluster file system or the same ASM disk groups).
• If the database files are symbolic links pointing to actual files and the links do not reside on
the same file systems as the actual files, only the actual files are backed up. Otherwise, only
the first links and the actual files are backed up; intermediate links will not be backed up.
You must run this command as a super user or Oracle owner user from the backup server. To allow
the Oracle Database Administrator (Oracle owner) to run this command, an identical Oracle
Database Administrator user must exist on backup server. In addition, permission on the Recovery
Manager for Oracle Installation and Repository directories must be changed appropriately.
OPTIONS
The following options are supported:
64 Using the Recovery Manager Command Line Interface
-s <oracle_sid>
The Oracle SID of the database instance. For Real Application Cluster (RAC) database, an Oracle
SID of any RAC instance can be specified.
-p <db_server>
The corresponding host name of the database server where the specified Oracle database instance
is running. The value of the database server name must match the output of the hostname
command.
-o online
Creates a Virtual Copy for datafile and archive log virtual volumes while the database is online.
This is the default option.
-o offline
Creates a Virtual Copy of datafile virtual volumes while the database is offline.
-o datafile
Creates a Virtual Copy of datafile virtual volumes while the database is online.
-o archlog
Creates a Virtual Copy of archive log virtual volumes while the database is online.
-v
Runs the command in verbose mode.
-f
Force to create a database Virtual Copy with a retention time. If retention time is specified either
through the Recovery Manager for Oracle configuration file or through the -r option. This option
must be specified.
-e <time> {d|D|h|H}
Specifies the relative time from the current time that volume will expire. <time> is a positive integer
value and in the range of 1 to 43,800 hours (1825 days). d|D means days. h|H means hours.
A value of 0 indicates the Virtual Copy does not have an expiration period. If the -r option is
used, the expiration time must be equal to or longer than the retention time.
-r <time>{d|D|h|H}
Specifies the amount of time, relative to the current time, that the Virtual Copy will be retained. If
the -r option is not specified, the retention time of the Virtual Copy defaults to the value set in the
configuration file. <time> is a positive integer value and in the range of 0 to 43800 hours (1825
days). d|D means days. h|H means hours. A value of 0 indicates the Virtual Copy does not have
a retention period.
NOTE: If the database volumes do not belong to any domain, then the retention time of the
read-only Virtual Copy cannot exceed the VVRetentionTimeMax value of the system. The
VVRetentionTimeMaxdefault value for the system is 14 days. If the database volumes belong
to a domain, then the retention time of the read-only Virtual Copy cannot exceed the
VVRetentionTimeMax value of the domain, if set. The retention time cannot be removed or
reduced once it is set. The retention time can be extended by rmora_set command.
This option requires the HP 3PAR Virtual Lock Software license.
NOTE: HP 3PAR Operating System Software CLI command showsys -param and showdomain
-d can be used to check the value of VVRetentionTimeMax for value system and domain
respectively.
For online backup, because the Virtual Copy for datafile volumes and the Virtual Copy for archive
log destinations are taken at different times, their retention time are slightly different.
Recovery Manager Commands 65
rmora_createdb
SYNTAX
rmora_createdb -s <oracle_sid> -p <db_server> -t <timestamp>[-n
<clone_sid>] [-h <clone_ora_home>][-o
ascii|binary|for_backup[,recovery|norecovery]] [-d <loc>] [-v]
DESCRIPTION
The rmora_createdb command creates a fully functional single-instance database or starts up
a clone database in MOUNTED mode for RMAN backup purposes. The fully functional
single-instance database can be used for any off-host processing purpose. The clone database that
is started in MOUNTED mode can only be used for RMAN backup.
The Virtual Copy, used for cloning a database, must be either an online or offline Virtual Copy
(created using online or offline option respectively). The Virtual Copy must have been mounted
prior to running this command.
You can create a clone database using an ascii or binary control file which was saved in the
Recovery Manager for Oracle repository at the time the Virtual Copy was created. Using an ascii
control file is more flexible as it allows to change database instance name as well as the structure
of the database.
When using an ascii control file, the structure of the clone database is not required to be exactly
the same as the structure of the original database. Therefore the Virtual Copy can be mounted at
any mount point. However, because the Virtual Copy does not contain online redo logs and control
files, their locations can be specified using -d option (can be one or more directories or ASM
diskgroups, depends on desired multiplexing). If the locations of the redologs and control files are
not specified, they are created at the repository location for the Virtual Copy
(/etc/3par/solutions/<host>.ora.<sid>/<vc_name>).
When using a binary control file, the structure of the clone database must be exactly the same as
the structure of the original database. Therefore, the Virtual Copy must be mounted at '/' if the
datafiles and archive logs are on file systems. Also, because the Virtual Copy does not contain
redologs and control files, the same directory structure or same ASM diskgroups for redologs and
control files must be pre-created on the backup server.
When you use an offline Virtual Copy to clone a database, either with a binary control file or an
ascii control file, the cloned database uses the same archive log destination as that of the primary
database. If archive log mode is enabled, you must pre-create the archive log destination. The
offline Virtual Copy does not contain the archive log destination.
When creating a clone database for backup (RMAN) purposes, the database is started in
MOUNTED mode using the binary control file from the repository without recovering the database.
This can be achieved by using -o for_backup or -o binary,norecovery option.
A clone database can be created with or without automatic recovery (applying archivelogs from
the Virtual Copy) using –o recovery or -o norecovery option, if recovery is chosen, the
clone database is open with reset log, otherwise, the clone database is in mounted status. The
primary database and the standby database cannot coexist on the same backup server.
Recovery Manager for Oracle does not create Virtual Copies for virtual volumes used by Oracle
database temporary files, in order to be consistent with Oracle's backup procedure.
You must run this command as a super user or Oracle owner user from the backup server. To allow
the Oracle Database Administrator (Oracle Owner) to run this command, an identical Oracle
Database Administrator user must exist on the backup server. In addition, permission on the Recovery
Manager for Oracle Installation and Repository directories must be changed appropriately.
OPTIONS
The following options are supported:
66 Using the Recovery Manager Command Line Interface
-s <oracle_sid>
The Oracle SID of the database instance. For Real Application Cluster (RAC) database, an Oracle
SID of any RAC instance can be specified.
-p <db_server>
The corresponding host name of the database server where the specified Oracle database instance
is running. The value of the database server name must match the output of the hostname
command.
-t <timestamp>
The timestamp of a Virtual Copy. It is also the name of the Virtual Copy. The Virtual Copy name
can be obtained using the rmora_display command.
-n <clone_sid>
The Oracle SID of the clone database. If this option is not specified, the clone database will have
the same Oracle SID as the original database. If this option is specified along with -o
binary|for_backup, the specified Oracle SID will be ignored.
-h <clone_ora_home>
The Oracle home directory on the backup server. If specified, this value will be used instead of
the value of the parameter ORACLE_HOME_BACKUP in the configuration file.
-d <loc>
A comma-separated list of directories or ASM diskgroups (for multiplexing) to store the new online
redologs and control files of the clone database. The directories or ASM diskgroups must have
enough available space to hold new online redo logs and control files. Users who run this command
must have write permission to this directory or directories. The number of multiplex redo log locations
must be equal to or less than the original database when creating a clone database. Otherwise,
the extra redo log multiplex location will be ignored.
-o ascii
Use an ascii control file which was saved in the Recovery Manager for Oracle repository to create
a clone database.
-o binary
Use a binary control file which was saved in the Recovery Manager for Oracle repository to create
a clone database.
-o for_backup
Use an binary control file which was saved in the Recovery Manager for Oracle repository to
create a clone database. The clone database is started in MOUNTED mode without recovery for
backup (RMAN) purpose. This option is equivalent to-o binary,norecovery. This option is
deprecated and will be removed in the future release.
-o recovery
Automatically recover the clone database using all available archivelogs that exist on the Virtual
Copy.
-o norecovery
Startup the clone database in mounted mode without recovery.
-v
Runs the command in verbose mode.
Recovery Manager Commands 67
rmora_display
SYNTAX
rmora_display -s <oracle_sid> -p <db_server> [-t <timestamp>] [-r]
DESCRIPTION
The rmora_display command displays database Virtual Copies, along with other information
including creation time, type, status and backup status.
A type of Virtual Copy can be either Online, Offline, Datafile, or Archlog.
• Online or Offline Virtual Copy - Indicates that the Virtual Copy was created for the
database while it was OPEN (online) or CLOSED (offline), respectively.
• Datafile Virtual Copy - Indicates that the Virtual Copy was created for data files only while
the database is open.
• Archlog Virtual Copy- Indicates that the Virtual Copy was created for the archive log
destination only.
The status of a Virtual Copy can be Available,Removed, Mounted, Mounted(P), Orphaned,
or Database. Available status indicates that the Virtual Copy exists and is not currently mounted
or cloned. Removed status indicates that the Virtual Copy is removed. Mounted status indicates
that the Virtual Copy is currently mounted. Mounted(P) status indicates that the Virtual Copy is
partially mounted. An Orphaned status indicates the Virtual Copy exists and is not currently
mounted or cloned, but have been orphaned, as it no longer belongs to the original parent. The
Virtual Copy is usable, but cannot be used for rmora_rollback. Finally, the Database status
indicates that a database has been cloned using the Virtual Copy.
A backup status of a Virtual Copy can be either Y or N, where Y indicates that the Virtual Copy
has been backed up, and N indicates that the Virtual Copy has not been backed up.
You must run this command as a super user from the backup server. To allow the Oracle Database
Administrator (Oracle Owner) to run this command, an identical Oracle Database Administrator
user must exist on backup server. In addition, permission on the Recovery Manager for Oracle
Installation and Repository directories must be changed appropriately.
OPTIONS
The following options are supported:
-s <oracle_sid>
The Oracle SID of the database instance. For Real Application Cluster (RAC) database, an Oracle
SID of any RAC instance can be specified.
-p <db_server>
The corresponding host name of the database server where the specified Oracle database instance
is running. The value of the database server name must match the output of the hostname
command.
-t <timestamp>
The timestamp of a Virtual Copy. It is also the name of the Virtual Copy. The default behavior is
to display all Virtual Copies.
-r
Displays the Virtual Copy’s retention and expiration time. This option is only available for HP 3PAR
Operating System Software 2.3.1 or above, otherwise, this option is ignored.
68 Using the Recovery Manager Command Line Interface
EXAMPLES
• rmora_display -s TEST920 -p pilot.
# Name Create Time Type Status Backup?
============ ======================== ======= ========= ========
1. 012403154751 Fri Jan 24 15:47:51 2003 Offline Available N
2. 012403154650 Fri Jan 24 15:46:50 2003 ArchLog Available N
3. 012403153912 Fri Jan 24 15:39:12 2003 Online Available N
4. 012303174743 Thu Jan 23 17:47:43 2003 Datafile Available N
5. 012303171935 Thu Jan 23 17:19:35 2003 ArchLog Available N
• rmora_display -s TEST920 -p pilot -t 012405154751
# Name Create Time Type Status Backup?
============ ======================== ====== ========= ========
1. 012403153912 Fri Jan 24 15:39:12 2003 Online Available N
Virtual Copy's Content:
/demo/data/system01.dbf
/demo/data/tools01.dbf
/demo/data/rbs01.dbf
Recovery Manager Commands 69
rmora_export
SYNTAX
rmora_export -s <oracle_sid> -p <db_server> -t <timestamp> -r
<alt_backup_server> -e <alt_tpdusername> [-l <alt_tpdhost>] [-v]
DESCRIPTION
The rmora_export command exports a Virtual Copy's repository from the current backup server
to an alternate backup server. The exported Virtual Copy can then be mounted or cloned at the
alternate backup server. A Virtual Copy's repository can be exported to multiple alternate backup
servers, which share the same HP 3PAR StoreServ Storage system as the original backup server.
A Virtual Copy can only be mounted on one backup server at a time.
The first time a Virtual Copy repository is exported to an alternate backup server, the
rmora_export command also copies the Recovery Manager for Oracle configuration file from
the current backup server to the alternate backup server.
The rmora_export command also modifies configuration parameters according to the values
specified in the arguments for alt_tpdhost and alt_tpdusername.
If the rmora_export command is invoked by an Oracle DBA, an identical Oracle owner user
must exist on the alternate backup server.
SSH must be configured to allow accessing from the current backup server to the alternate backup
server as well as from the alternate backup server to the HP 3PAR StoreServ Storage system.
You must run this command as a super user or Oracle owner user from the backup server. To allow
the Oracle Database Administrator to run this command, an identical Oracle Database Administrator
user must exist on alternate backup server. In addition, permission on the /opt/3PAR/RMOra
directory must be changed appropriately.
OPTIONS
The following options are supported:
-s <oracle_sid>
The Oracle SID of the database instance. For Real Application Cluster (RAC) database, an Oracle
SID of any RAC instance can be specified.
-p <db_server>
The corresponding host name of the database server where the specified Oracle database instance
is running. The value of the database server name must match the output of the hostname
command.
-t <timestamp>
The timestamp of a Virtual Copy. It is also the name of the Virtual Copy. The Virtual Copy name
can be obtained using the rmora_display command.
-r <alt_backup_server>
The alternate backup server name.
-l <alt_tpdhost>
The <alt_tpdhost> hostname is the hostname defined on the HP 3PAR StoreServ Storage system,
which represents the alternate backup server. The HP 3PAR Operating System Software CLI
showhost command lists all available TPD host names.
-e alt_tpdusername
The HP 3PAR StoreServ Storage system username that will be used by Recovery Manager for
Oracle to connect to the HP 3PAR StoreServ Storage system from the alternate backup server. The
HP 3PAR StoreServ Storage system user can be created using the HP 3PAR Operating System
70 Using the Recovery Manager Command Line Interface
Software CLI createuser command. The created user must be assigned the edit role (privilege)
or 3PAR_RM role.
-v
Runs the command in verbose mode.
Recovery Manager Commands 71
rmora_mount
SYNTAX
rmora_mount -s <oracle_sid> -p <db_server> -t <timestamp> [-m
<mountpoint>] [-r] [-v]
DESCRIPTION
The rmora_mount command mounts an existing Virtual Copy created by the rmora_create
command or rmora_rsync command on the backup server. The mounted Virtual Copy can be
used for off-host processing purposes such as backup or database cloning.
The following restrictions apply when mounting a database Virtual Copy:
• The Virtual Copy must have an Available or Mounted(P) status in order to be mounted.
The status of a Virtual Copy can be retrieved using the Recovery Manager for Oracle display
utility.
• The same Virtual Copy cannot be mounted concurrently at different mount points.
• If the database files reside on Symantec VxVM Volumes, only one Virtual Copy per database
can be mounted at any time on the backup server. This is due to the VxVM disk groups from
different Virtual Copies of the same database having the same names and so cannot be
imported at the same time.
• If Oracle datafiles and archive logs reside on HP or Linux LVM volumes, HP 3PAR Recovery
Manager for Oracle allows only one Virtual Copy of the same database to be mounted. You
must unmount a mounted Virtual Copy before mounting a different Virtual Copy.
• If the database files reside on ASM disk groups, it is dependent on which ASM database
version is installed on the backup server, different restrictions apply as follows:
◦ Make sure the backup host has +ASM instance created and configured properly in order
for Recovery Manager for Oracle mount and/or unmount operations being able to use
the existing +ASM instance, or bring it up if it is originally down.
◦ If the ASM version on the backup server is 10.2.0.5 or 11.1.0.7 or above, one Virtual
Copy per database can be mounted on the backup server. Virtual copies from different
databases can be mounted concurrently.
◦ If the ASM version on the backup server is running versions lower than the releases
mentioned in the previous bullet, only one Virtual Copy can be mounted at any time on
the backup server. This restriction prevents an Oracle ASM instance on the backup server
from hanging due to some ASM's idle processes still holding a Virtual Copy's devices,
even though the corresponding ASM disk groups are dropped.
• For OCFS2 1.4.1 or above, Recovery Manager for Oracle supports multiple Virtual Copies
per database being mounted simultaneously. For versions lower than OCFS2 1.4.1, only one
Virtual Copy per database can be mounted at any time on the backup server.
• For online backup and archlog backup, all MANDATORY archive log destinations are mounted.
If no MANDATORY archive log destinations are found, all OPTIONAL archive log destinations
are mounted.
Mounting a database Virtual Copy involves the following actions:
• Creates a read-write Virtual Copy of the original read-only Virtual Copy.
• Imports the read-write Virtual Copy to the backup server.
• Imports snapshot Symantec VxVM disk groups and starts up all corresponding snapshot VxVM
volumes if the database files reside on VxVM volumes.
72 Using the Recovery Manager Command Line Interface
• Imports snapshot LVM volume groups and activates all corresponding LVM snapshot volumes
if the database files reside on LVM volumes.
• For Virtual Copies from an ASM-managed database, based on the different ASM database
releases on the backup server, the operation is different.
◦ For ASM versions 10.2.0.5, 11.0.1.7 or above, if an ASM instance exists and is up on
the backup server, then all diskgroups from the Virtual Copy are mounted in this ASM
instance. Otherwise, an ASM instance is started up on the backup server, and all ASM
disk groups in the Virtual Copy are mounted.
◦ For ASM versions lower than the releases mentioned in the previous bullet, if an ASM
instance is up on the backup server, the mount utility checks if there is any mounted
diskgroup. If none, the ASM instance is shut down, otherwise, the mount utility gives an
error and exits. If there are no errors, a new ASM instance is started up and all diskgroups
contained in the current Virtual Copy are mounted.
• Mounts all snapshot file systems if the database files reside on file systems.
You must run this command as a super user or Oracle owner user from the backup server. To allow
the Oracle Database Administrator (Oracle owner) to run this command, an identical Oracle
Database Administrator user must exist on backup server. In addition, permission on the Recovery
Manager for Oracle Installation and Repository directories must be changed appropriately.
OPTIONS
The following options are supported:
-s <oracle_sid>
The Oracle SID of the database instance. For a Real Application Cluster (RAC) database, an Oracle
SID of any RAC instance can be specified.
-p <db_server>
The corresponding host name of the database server where the specified Oracle database instance
is running. The value of the database server name must match the output of the hostname
command.
-t <timestamp>
The timestamp of a Virtual Copy. It is also the name of the Virtual Copy. The Virtual Copy name
can be obtained using the rmora_display command.
-m <mountpoint>
The destination location where the Virtual Copy is mounted. The current user must have permission
to write to this location. By default, the Virtual Copy will be mounted at
/etc/3par/solutions/<db_server>.ora.<oracle_sid>/<timestamp>. If the Virtual
Copy is for an ASM-managed database, this option will be ignored.
-r
Remounts a Virtual Copy that has previously been mounted, but has been unmounted due to system
reboot. This option is also helpful where a Virtual Copy has previously been partially mounted.
-v
Runs the command in verbose mode.
Recovery Manager Commands 73
rmora_remove
SYNTAX
rmora_remove -s <oracle_sid> -p <db_server> -t <timestamp> [-v]
DESCRIPTION
The rmora_remove command removes a database Virtual Copy that was created using the
rmora_create command. The Virtual Copy must have a status of Available to be removed. (To
view the status of the Virtual Copy, use the rmora_display command.
If the specified Virtual Copy is backed up, the rmora_remove command will remove the actual
database Virtual Copy, but will keep its repository in case it is needed for a database restore. To
remove the Virtual Copy's repository, use the rmora_rmrep command.
If you remove the Virtual Copy's repository, Recovery Manager will not be able to perform database
restore operation, even if the Virtual Copy is backed up.
You must run this command as a super user or Oracle owner user from the backup server. To allow
the Oracle owner user to run this command, HP 3PAR Recovery Manager for Oracle must be
configured for the Oracle owner user.
OPTIONS
The following options are supported:
-s <oracle_sid>
The instance ID the primary database. For Real Application Cluster (RAC) database, you can
specify any instance SID.
-p <db_server>
The host name of the database server where the specified Oracle database is running. This host
name value must match the host name value in the output of the hostname command.
-t <timestamp>
The timestamp of the Virtual Copy, which is also the name of the Virtual Copy. To obtain a list of
Virtual Copy names, use the rmora_display command.
[-v]
Verbose mode.
74 Using the Recovery Manager Command Line Interface
rmora_removedb
SYNTAX
rmora_removedb -s <oracle_sid> -p <db_server> -t <timestamp> [-n
<clone_sid>] [-h <clone_ora_home>] [-f] [-v]
DESCRIPTION
The rmora_removedb command removes a clone database that was created using the
rmora_createdb command.
The clone database is shutdown with the shutdown immediate option. All files (Oracle
parameter file, control files, and redo logs), previously created with the rmora_createdb
command are removed. The Virtual Copy remains mounted.
You must run this command as a super user or Oracle owner user from the backup server. To allow
the Oracle Database Administrator (Oracle owner) to run this command, an identical Oracle
Database Administrator user must exist on backup server. In addition, permission on the Recovery
Manager for Oracle Installation and Repository directories must be changed appropriately.
OPTIONS
The following options are supported:
-s <oracle_sid>
The Oracle SID of the database instance. For Real Application Cluster (RAC) database, an Oracle
SID of any RAC instance can be specified.
-p <db_server>
The corresponding host name of the database server where the specified Oracle database instance
is running. The value of the database server name must match the output of the hostname
command.
-t <timestamp>
The timestamp of a Virtual Copy that was previously used to create the clone database.
-n <clone_sid>
The instance ID of the clone database to be removed. If the clone database uses the same oracle_sid
as the primary oracle_sid, this option can be omitted.
-h <clone_ora_home>
The Oracle home directory of the cloned database on the backup server. If specified, this value is
used instead of the value of the ORACLE_HOME_BACKUP parameter in the configuration file.
-f
Forces the removal of the clone database. Recovery Manager for Oracle uses Oracle’s shutdown
abort command to shut down the clone database.
-v
Runs the command in verbose mode.
Recovery Manager Commands 75
rmora_restore
SYNTAX
rmora_restore -s <oracle_sid> -p <db_server> [-t <timestamp>] [-T
<tablespaces>] [-D <dbf1,dbf2,...>] [-m <mountpoint>] [-h <alt_server>]
[-S <alt_sid>] [-H <alt_home>] [-c] [-v]
DESCRIPTION
Restores database files from a Virtual Copy backup image.
The rmora_restore command restores databases, tablespaces, data files, and/or archive logs
from a Virtual Copy backup image. The Virtual Copy must have been previously backed up using
the rmora_backup command. The Virtual Copy must have a status of Y in order to be restored.
The Virtual Copy’s backup status can be retrieved using the rmora_display command.
For NBU (User-managed) restore, the command can also be used to restore to an alternate server
on an alternate mount point. For Oracle RMAN restore, it is always restored to the database server.
If a Virtual Copy’s name is not specified, the rmora_restore command restores from the most
recent full back up.
Restore is not supported on Remote Copy configuration.
The following restrictions apply when restoring from a Virtual Copy’s backup image:
• When restoring the database control file (-c option), the current database instance must be
in STARTED mode (startup nomount). If the database is a Real Application Cluster (RAC)
database, all other RAC instances must be in CLOSED mode. Restoring the database control
file along with individual datafile or tablespace is not supported as it is not possible to perform
media recovery. If the original database is a physical standby database, the backup control
file generally cannot be used to restore to the primary (production) database since they are
not compatible unless Oracle 11g is in use and Oracle RMAN is used to restore.
• When restoring a database instance without restoring control file, the database instance must
be in MOUNTED mode. If the database is a Real Application Cluster (RAC) database, all
other RAC instances must be in CLOSED mode.
• When restoring individual tablespaces or datafiles, the database can be in OPEN or
MOUNTED mode. If the database is in OPEN mode, the corresponding tablespaces must be
offline.
• Restoring control files along with datafiles and/or tablespaces is not allowed.
• If the database is an ASM managed database, all ASM disk groups must be mounted prior
to running this command.
• For NBU (user-managed) restore, a file named
/usr/openv/netbackup/db/altnames/<alt_server> must be created on the NBU
master server in order to perform restoration to a host (including the original database server)
that differs from the backup server. <alt_server> is the host name of the database server
to restore.
• Starting with Oracle 11g, a RMAN backup image of a standby database, which was backup
to local disk, cannot be restored using the rmora_restore command since the backup
76 Using the Recovery Manager Command Line Interface
image cannot be seen from the Recovery Catalog from the primary (production) database.
To restore, the following steps must be performed manually:
◦ The backup image (pieces) must be manually copied from the backup server to the primary
(production) server.
◦ The backup pieces must be then cataloged manually with the Recovery Catalog from the
primary (production) server.
◦ Perform restore manually using Oracle RMAN.
Depending on the type of the Virtual Copy backup image (online, offline, datafile, or archlog),
corresponding database files are restored appropriately.
For NBU (user-managed) restore:
• Control files are not restored by default.
• For an online Virtual Copy, both datafiles and archive logs are restored unless individual
tablespaces or data files are specified. In this case, only the corresponding data files are
restored.
• For an offline Virtual Copy, only datafiles are restored.
• For a datafile only Virtual Copy, only datafiles are restored.
• For an archive log Virtual Copy, only archive logs are restored.
For Oracle RMAN restore:
• Control files are not restored by default.
• For an online Virtual Copy, only data files are restored. Archive logs are not restored to
minimize restoration time. Oracle RMAN can restore necessary archive logs during recovery
(refer to Oracle documentation for details on how to use Oracle RMAN for recovery).
• For an offline Virtual Copy, only data files are restored.
• For a datafile-only Virtual Copy, only data files are restored.
• For an archive log Virtual Copy, archive log restoration is not supported as Oracle RMAN
can restore necessary archive logs during recovery (refer to Oracle documentation for details
on how to use Oracle RMAN for recovery).
Recovery Manager for Oracle backs up ASM metadata if the database is managed by ASM. In
the case you need to restore the metadata to the database server, you need to specify the disk
group name(s) for which to restore the metadata.
You must run this command as a super user or Oracle owner user from the backup server. To allow
the Oracle Database Administrator (Oracle owner) to run this command, an identical Oracle
Database Administrator user must exist on backup server. In addition, permission on the Recovery
Manager for Oracle Installation and Repository directories must be changed appropriately.
Only the super user or the owner of the Virtual Copy can restore the specified Virtual Copy.
OPTIONS
The following options are supported:
-s <oracle_sid>
The Oracle SID of the database instance. For Real Application Cluster (RAC) database, an Oracle
SID of any RAC instance can be specified.
-p <db_server>
The corresponding host name of the database server where the specified Oracle database instance
is running. The value of the database server name must match the output of the hostname
command.
Recovery Manager Commands 77
-t <timestamp>
The timestamp of a Virtual Copy whose backup image is used for restoration. Use the
rmora_display command to retrieve a list of the Virtual Copy names. If a name is not specified,
the most recent Virtual Copy’s backup (full) image is used for the restoration.
-T <tablespaces>
The tablespace(s) that need to be restored. Use commas to separate multiple tablespace names
(no space between the tablespace names).
-D <datafiles>
The datafile(s) that need to be restored. Use commas to separate multiple datafiles and no space
in between the datafiles, and no quote around the datafile names. The TEMP datafile cannot be
restored.
-h <alt_server>
The host name of the alternate server to restore to. If this option is omitted, the Virtual Copy's
backup image is restored to the database server by default.
-m <alt_mountpoint>
The alternate mount point to restore to. If this option is omitted, the Virtual Copy's backup image
is restored to its original location by default.
-c
The control files are restored as well. If this option is omitted, the control files are not restored by
default. Restoring the control file along with individual tablespace or datafiles is not supported.
-v
Runs the command in verbose mode.
-S <alt_sid>
The alternate Oracle SID of the database to be restored. This option can be used to specify the
Oracle SID of the primary (production) database if it is different than the SID of the standby database
from which the backup image is used for restoring.
-H <alt_home>
The alternate Oracle Home of the database to be restored. This option can be used to specify the
Oracle Home on the host that is being restored if the restored host is neither the original database
server nor the backup server.
78 Using the Recovery Manager Command Line Interface
rmora_rmrep
SYNOPSIS
rmora_rmrep -s <oracle_sid> -p <db_server> [-t <timestamp>] [-f] [-v]
DESCRIPTION
The rmora_rmrep command removes a Virtual Copy repository, specified by the <timestamp>
parameter. If the <timestamp> is not specified, the entire database repository will be removed.
If removing a Virtual Copy repository, the status of a Virtual Copy must be Removed and its backup
status must be N. If the status of a Virtual Copy is Y, the -f option can be used to force the removal
of the repository. The status of the Virtual Copy and backup status can be obtained using the
rmora_display command.
If removing a database repository, all of the existing Virtual Copies and their repositories must be
removed first.
You must run this command as a super user from the backup server. To allow the Oracle Database
Administrator (Oracle owner) to run this command, an identical Oracle Database Administrator
user must exist on backup server. In addition, permission on the Recovery Manager for Oracle
Installation and Repository directories must be changed appropriately.
OPTIONS
The following options are supported:
-s <oracle_sid>
The Oracle SID of the database instance. For Real Application Cluster (RAC) database, an Oracle
SID of any RAC instance can be specified.
-p <db_server>
The corresponding host name of the database server where the specified Oracle database instance
is running. The value of the database server name must match the output of the hostname
command.
-t <timestamp>
The timestamp of a Virtual Copy whose repository is to be removed. The Virtual Copy name can
be obtained using rmora_display command. If the <timestamp> is not specified, the entire
repository will be removed.
-f
Forces the removal of the Virtual Copy repository even if the Virtual Copy has been previously
backed up.
-v
Runs the command in verbose mode.
Recovery Manager Commands 79
rmora_rollback
SYNOPSIS
rmora_rollback -s <oracle_sid> -p <db_server> -t <timestamp> [-o
data|arch] [-v] [-w] [-f]
DESCRIPTION
The rmora_rollback command promotes the volumes of a database Virtual Copy back to their
base virtual volumes. Once promoted, the database virtual volumes will be exactly the same as
the volumes of the database Virtual Copy. If the Virtual Copy is the snapshot image of a standby
database, it can only be used to promote back to the standby database virtual volumes.
When rolling back from an online Virtual Copy, both datafile and archive log virtual volumes are
rolled back by default. Use the -o option to roll back only datafile virtual volumes or only archive
log virtual volumes.
When rolling back from an offline or datafile Virtual Copy, only datafile virtual volumes are rolled
back.
When rolling back from an archive log Virtual Copy, only archive log virtual volumes are rolled
back.
The following restrictions apply when rolling back a Virtual Copy:
• The online redo logs and control files should not reside on the same virtual volumes used by
the datafiles and archive logs; if they do, they will be rolled back along with the datafile and
archive log virtual volumes. To avoid possible data corruption for other applications caused
by rolled-back volumes, the volumes used by the database should not be shared with other
applications.
• The database instance must be CLOSED for this operation. If the database is an RAC database,
all RAC instances must be CLOSED.
• The base (data file and/or archive log) virtual volumes and Virtual Copy volumes must not be
exported.
• If the base virtual volumes are involved in a Remote Copy group you must use -f to promote
the Virtual Copies back to their base volumes.
• The specified Virtual Copy must not be Orphaned since it does not belong to the original
parent volumes. The Virtual Copy is usable, but cannot be used for rmora_rollback.
Recovery Manager for Oracle saves an ASCII control file and a binary control file for each created
Virtual Copy in its repository. After a rollback, you may need to restore the control file in order to
perform database recovery.
You must run this command as a super user or Oracle owner user from the backup server. To allow
the Oracle Database Administrator (Oracle owner) to run this command, an identical Oracle
Database Administrator user must exist on the backup server. In addition, permission on the Recovery
Manager for Oracle Installation and Repository directories must be changed appropriately.
OPTIONS
The following options are supported:
-s <oracle_sid>
The Oracle SID of the database instance. For Real Application Cluster (RAC) database, an Oracle
SID of any RAC instance can be specified.
-p <db_server>
The corresponding host name of the database server where the specified Oracle database instance
is running. The value of the database server name must match the output of the hostname
command.
80 Using the Recovery Manager Command Line Interface
-t <timestamp>
The timestamp of a Virtual Copy from which to promote. The Virtual Copy name can be obtained
using the rmora_display command.
-o [data|arch]
• data
Promotes only the Virtual Copy’s datafile volumes back to their base virtual volumes.
• arch
Promotes only the Virtual Copy’s archive log volumes back to their base virtual volumes.
-v
Runs the command in verbose mode.
-w
Promotes the read-write Virtual Copy instead of the read-only Virtual Copy back to its base. The
default is to promote the read-only Virtual Copy.
-f
Forces the promote operation to proceed even if the parent base volumes are currently in a Remote
Copy group, as long as the Remote Copy group has not been started. If started, the promote will
fail.
Recovery Manager Commands 81
rmora_rsync
SYNTAX
rmora_rsync -s <oracle_sid> -p <db_server> [-l <local_backup_server>]
[ -o online|offline|validate] [ -r <retention_time>{d|D|h|H} -f] [ -e
<expiration_time>{d|D|h|H}] [-v]
DESCRIPTION
The rmora_rsync command can be used to create an online of offline database Virtual Copy
on the remote/secondary and local/primary HP 3PAR StoreServ Storage system in a Remote Copy
or Synchronous Long Distance Remote Copy configuration.
NOTE: This feature requires the HP 3PAR Remote Copy Software license.
The Remote Copy configuration can be configured as periodic or synchronous mode (or both as
in SyncLD Remote Copy configuration). For periodic mode, the rmora_rsync command performs
periodic synchronization between the database virtual volumes on the local/primary and the
remote/secondary HP 3PAR StoreServ Storage system. Redo log RC group (if it exists) will not be
synced. Once the synchronization completes, the command will automatically create Virtual Copies
of the corresponding database virtual volumes on the remote/secondary HP 3PAR StoreServ Storage
system. For synchronous mode, the command creates Virtual Copies of the corresponding database
virtual volumes on the remote secondary HP 3PAR StoreServ Storage system without performing
synchronization since they are always in sync. For both periodic and synchronous mode, Virtual
Copies are not created for redo log volumes.
To create a database Virtual Copy on the local/primary HP 3PAR StoreServ Storage system in
addition to a database Virtual Copy on the remote/secondary HP 3PAR StoreServ Storage system,
a local backup server is required. The local backup server must be connected to the local/primary
HP 3PAR StoreServ Storage system. In addition, Recovery Manager for Oracle must be
pre-configured for the database on the local backup server. The local backup server can be used
to manage all database Virtual Copies that are created on the local/primary HP 3PAR StoreServ
Storage system.
The database instance must be offline or online when creating an offline or online database Virtual
Copy respectively. The database instance is considered to be offline if it is in CLOSED mode. If
the database is an RAC database, all RAC instances must be offline. The database instance is
considered to be online if it is in OPEN mode (for primary database) or in managed recovery
mode (for physical standby databases). If the database is an RAC database, the specified database
instance must be online, all other RAC instances can be either online or offline.
If the database being snapshot is a physical standby database and Oracle release is not 11g, the
Oracle parameter file and control file of the production database must be backup manually in
addition to the Virtual Copy. This is because the parameter file and control file are not compatible
between the standby and production database.
When creating an online Virtual Copy, a Virtual Copy is created for the virtual volumes used by
all MANDATORY archive log destinations. If there are no MANDATORY archive log destinations,
a Virtual Copy is created for the virtual volumes used by all OPTIONAL archive log destinations.
Recovery Manager for Oracle does not create Virtual Copies for virtual volumes used by Oracle
database temporary files in order to be consistent with Oracle's backup procedure. However,
Recovery Manager for Oracle does create Virtual Copies for read-only and offline datafiles. (After
the database is cloned on the backup server, you must rename the read-only and offline datafiles
as appropriate: use the syntax in the ascii control file that is saved in the timestamp repository to
replace the real file names that are based on the mount points during cloning.)
82 Using the Recovery Manager Command Line Interface
To use the rmora_rsync command, the following requirements must be satisfied:
• Each database instance must be started up using either a parameter file (pfile) or server
parameter file (spfile) from default location ($ORACLE_HOME/dbs).
• The database must be running in archive log mode and automatic archival must be enabled
in order to create an online Virtual Copy.
• If archive log mode is enabled, the datafiles and archive logs must reside on separate 3PAR
virtual volumes.
• The online redo logs and control files should not reside on the same 3PAR virtual volumes
used by the datafiles and archive logs to avoid being restored when using Recovery Manager
rollback (promote) feature. However, the online redologs and control files can share the same
3PAR virtual volumes.
• If database files reside on Symantec VxVM volumes, the datafiles and archive logs must reside
on separate VxVM disk groups. The online redo logs and control files should not reside on
the same VxVM Volumes used by the datafiles and archive logs.
• If you use LVM Volume Manager, the Oracle datafiles and archive logs must reside on separate
LVM volume groups. In addition, online redo logs and control files must not reside on LVM
volume groups that are used by Oracle datafiles and archive logs. However, the online redo
logs and control files can reside on the same LVM volume group.
• If the Oracle database is an ASM-managed database, the Oracle datafiles and archive logs
must reside on separate ASM disk groups. To avoid being rolled back when using the Recovery
Manager Rollback feature, the online redo logs and control files should not reside on the same
ASM disk groups used by the datafiles and archive logs. In addition, ASM disk groups should
not be shared between different databases.
• If the Oracle database is an RAC database, all RAC instances must share the same archive
log destinations (i.e., the same cluster file system or the same ASM disk groups).
• Datafile and archive log volumes can be in the same Remote Copy (RC) group or separate
RC groups. In SyncLD configuration, if datafile and archive log volumes are in the same RC
group, when a failover occurs, a full synchronization of the RC group between the periodic
secondary system and the new primary system is required. Redo log volumes are not required
to be in an RC group for periodic mode. Redo log volumes must not belong to neither datafile
nor archive log RC groups for synchronous mode or SyncLD configuration.
OPTIONS
The following options are supported:
-s <oracle_sid>
The Oracle SID of the database instance. For Real Application Cluster (RAC) database, an Oracle
SID of any RAC instance can be specified.
-p <db_server>
The corresponding host name of the database server where the specified Oracle database instance
is running. The value of the database server name must match the output of the hostname
command.
-l <local_backup_server>
The host name of a local backup server. When specified, a database Virtual Copy is also created
on the local/primary system. The database Virtual Copy information is saved to the repository on
the local backup server.
NOTE: Recovery Manager for Oracle must be pre-configured on the local backup server prior
to executing rmora_sync with the -l option.
Recovery Manager Commands 83
-o online
Create an online database Virtual Copy in Remote Copy or Synchronous Long Distance
configuration. The specified database instance must be online.
-o offline
Create an offline database Virtual Copy in Remote Copy or Synchronous Long Distance
configuration. The specified database instance must be offline.
-o validate
Validates the Remote Copy configuration.
-v
Runs the command in verbose mode.
-f
Force to create a database Virtual Copy with a retention time. If retention time is specified either
through the Recovery Manager for Oracle configuration file or through the -r option, this option
must be specified.
-e <time> {d|D|h|H}
Specifies the relative time from the current time that volume will expire. <time> is a positive integer
value and in the range of 1 to 43,800 hours (1825 days). d|D means days. h|H means hours.
A value of 0 indicates the Virtual Copy does not have an expiration period. If the -r option is
used, the expiration time must be equal to or longer than the retention time.
-r <time>{d|D|h|H}
Specifies the amount of time, relative to the current time, that the Virtual Copy will be retained. If
the -r option is not specified, the retention time of the Virtual Copy defaults to the value set in the
configuration file. <time> is a positive integer value and in the range of 0 to 43800 hours (1825
days). d|D means days. h|H means hours. A value of 0 indicates the Virtual Copy does not have
a retention period.
84 Using the Recovery Manager Command Line Interface
rmora_set
SYNTAX
rmora_set -s <oracle_sid> -p <db_server> -t <timestamp> [-r <time>
d|D|h|H] [-f] [-e <time> d|D|h|H>] [-v]
Description
The rmora_set command sets the retention time and/or its expiration time of a read-only Virtual
Copy when it is created without a retention time and/or expiration time set, or increases the
retention time and/or changes the expiration time of the Virtual Copy. Setting the expiration time
to 0(D|d) or 0(H|h) means to disable the expiration time property.
If the volumes do not belong to any domain, then the retention time of the volumes cannot exceed
the maximum volume retention time value of the system. The maximum volume retention time default
value for the system is 14 days. If the volumes belong to a domain, then the retention time of a
read-only Virtual Copy cannot exceed the maximum volume retention time value of the domain, if
set. The retention time cannot be removed or reduced once it is set. The command rmora_set
only validates the value for retention or expiration, which should be within the range of 0–1825
days (retention time is within the range of 1–1825 days). It does not validate if the retention value
exceeds the system or domain's maximum volume retention time. It relies on the HP 3PAR Operating
System Software CLI for that validation. Also, retention time cannot be longer than expiration time.
This check also relies on the HP 3PAR Operating System Software command line interface.
rmora_display with the -r option can be used to display all Virtual Copy volumes with their
corresponding retention time and expiration time. If there is no retention or expiration time defined,
N/A is the displayed value.
When using rmora_set to increase the retention time or expiration time, the new values always
starts from the current time.
• If the HP 3PAR Operating System Software version is 2.3.1, this command requires that the
new Virtual Copy retention time always be longer than the previous retention time. For example,
if the previous retention time is set to 4 weeks, and 3 weeks later you want to extend the
retention time for one more week, the new retention time should be set to 4 weeks instead of
2 weeks (the new value should always be longer or equal to the original 4 weeks), which
starts from the time you set it. If the previous retention time is set to 4 weeks, after 5 weeks, if
the Virtual Copy has not been removed and you want to set a new retention time, the new
retention time should be at least 4 weeks long, and starts from the time you reset it.
• If the HP 3PAR Operating System Software version is 3.1.1 or above, if setting the new
retention time would extend the retention end time, any new value is allowed. Or, once the
retention end time is passed, any new retention time is also allowed. The new value is not
necessarily the same or longer than the previous value. For example, if the previous retention
time is set to 4 weeks, and 3 week later you want to extend the retention for one more week,
the new retention time can be set to 2 weeks (the new value is shorter than the original 4
weeks), which starts from the time you set it. If the previous retention time is set to 4 weeks,
after 5 weeks, if the Virtual Copy has not been removed and you want to set a new retention
time, the new retention time can be any value within the allowed system or domain, and starts
from the time you reset it.
This command with the -r option requires the HP 3PAR Virtual Lock license. Contact your local
service provider for more information.
Requirements for setting retention time:
• The retention time will only be applied for read-only database Virtual Copy.
• The retention time can be set during Recovery Manager for Oracle configuration time
(rmora_config) per database as a policy or during Virtual Copy creation time
(rmora_create or rmora_rsync).
Recovery Manager Commands 85
• The retention time set during configuration time serves as the default value all Virtual Copies
created thereafter.
• The retention time can be specified during a Virtual Copy creation to overwrite the retention
value set during the Recovery Manager for Oracle configuration.
• The retention time can be modified but it can not be lower than the original setting.
• The retention time can be specified in hours or days.
• The minimum value for retention time is 1 hour and the maximum value is 43800 hours (1825
days or 5 years).
• The retention time can be set to 0 indicating that a database Virtual Copy has no retention
time and can be removed immediately.
• If the original database volumes do not belong to any domain, then the retention time can not
exceed the system’s VVRetentionTimeMax if set.
• If the original database volumes belong to a domain, then the retention time cannot exceed
the domain’s maximum retention time if set.
• The database Virtual Copies with retention time cannot be removed until the end of the retention
time period. Recovery Manager for Oracle relies on the HP 3PAR Operating System Software
to enforce this restriction.
OPTIONS
-s <oracle_sid>
The Oracle SID of the database instance. For Real Application Cluster (RAC) database, an Oracle
SID of any RAC instance can be specified.
-p <db_server>
The corresponding hostname of the database server, where the specified Oracle database instance
is running. The value of the database server name must match the output of the hostname
command.
-t <timestamp>
The name <timestamp> of a Virtual Copy which retention time will be changed. The Virtual Copy
name can be obtained using rmora_display command.
-r <time>{d|D|h|H}
Specifies the amount of time, relative to the current time, that the Virtual Copy will be set. <time>
is a positive integer value and in the range of 1 to 43800 hours (1825 days). d|D means days.
h|H means hours. A value of 0 indicating that the Virtual Copy will have no retention time.
-e <time>{d|D|h|H}
Specifies the relative time from the current time that volume will expire. <time> is a positive integer
value and in the range of 1 to 43,800 hours (1825 days). d|D means days. h|H means hours.
If the -r option is used, the expiration time must be equal to or longer than the retention time.
-v
Runs the command in verbose mode.
-f
Force to set or extend the specified Virtual Copy with a new retention time. If retention time is
specified through the -r option, this option must be specified.
86 Using the Recovery Manager Command Line Interface
rmora_umount
SYNTAX
rmora_umount -s <oracle_sid> -p <db_server> -t <timestamp> [-f] [-v]
DESCRIPTION
The rmora_umount command unmounts a mounted database Virtual Copy, which was previously
mounted using the rmora_mount command. The Virtual Copy must have Mounted or
Mounted(P) status in order to be unmounted. The Virtual Copy unmounting process only removes
the read-write Virtual Copy; the read-only Virtual Copy remains intact.
Unmounting a database Virtual Copy is typically the reverse of mounting a database Virtual Copy,
and involves the following actions:
• For an ASM-managed database, if the ASM version on the backup server is 10.2.0.5 or
11.1.0.7 or above, unmounting the Virtual Copy drops the ASM diskgroups that are contained
in the Virtual Copy and cleans up the ASM disks.
• If the ASM version on the backup is lower than those listed in the previous bullet, unmounting
shuts down the ASM instance and cleans up ASM disks.
• Unmounts all snapshot file systems if the database files reside on file systems.
• Destroys all snapshot VxVM disk groups and their VxVM volumes if the database files reside
on VxVM volumes.
• Destroys all snapshot LVM volume groups and their volumes if the database files reside on
LVM volumes.
• Deports the read-write Virtual Copy from the backup server.
• Removes the read-write Virtual Copy.
You must run this command as a super user or Oracle owner user from the backup server. To allow
the Oracle Database Administrator (Oracle owner) to run this command, an identical Oracle
Database Administrator user must exist on backup server. In addition, permission on the Recovery
Manager for Oracle Installation and Repository directories must be changed appropriately.
OPTIONS
The following options are supported:
-s <oracle_sid>
The Oracle SID of the database instance. For Real Application Cluster (RAC) database, an Oracle
SID of any RAC instance can be specified.
-p <db_server>
The corresponding host name of the database server where the specified Oracle database instance
is running. The value of the database server name must match the output of the hostname
command.
-t <timestamp>
The timestamp of a Virtual Copy to be unmounted. The Virtual Copy name can be obtained using
the rmora_display command.
-f
Forcibly unmounts a database Virtual Copy. Using this option can corrupt the corresponding
read-write Virtual Copy. However, the read-only Virtual Copy remains intact. This option is useful
in cases where the Virtual Copy is partially mounted due to mounting failure.
-v
Runs the command in verbose mode.
Recovery Manager Commands 87
5 Using the Recovery Manager for Oracle Graphical User
Interface
The following section describes how to use the GUI to perform specific operations relating to the
maintenance of existing databases. For more information about using the CLI utilities, refer to
“Using the Recovery Manager Command Line Interface” (page 54).
Starting and Stopping the Recovery Manager for Oracle GUI
The Recovery Manager for Oracle Graphical User Interface (GUI) is installed when the RMOra
package is installed.
Before launching the GUI, the following packages must be installed on Linux:
libX11-1.3-2.el6.i686.rpm*
libXext-1.1-3.el6.i686.rpm*
libXau-1.0.5-1.el6.i686.rpm*
libXtst-1.0.99.2-3.el6.i686.rpm*
libXi-1.3-3.el6.i686.rpm*
Starting the GUI
To start the Recovery Manager for Oracle GUI:
1. Ensure that the DISPLAY environment variable is set.
2. Verify that the X11 server is running on the destination host where the GUI is displayed. If the
X11 server is not running, enter the following command:
For Solaris:
/usr/openwin/bin/xhost +
For Linux:
a. Verify you have the xorg-x11-server-utils package. This package is required to
run the X11 server.
b. Verify you have the libXtst and libXrender packages (both i386 and x64). These
packages are required to run the Oracle GUI.
c. Enter:
/usr/X11R6/bin/xhost +
For HP UX:
/usr/X11/bin/xhost +
3. Type the following command in an open terminal:
/opt/3PAR/RMOra/bin/rmoragui
88 Using the Recovery Manager for Oracle Graphical User Interface
4. Press ENTER.
NOTE: It is a known issue that the mouse events are not captured correctly on the cygwin
x-server for Java6.
Stopping the GUI
To stop the Recovery Manager for Oracle GUI, select either Exit in the top left hand corner of the
console window, or select the Exit menu item under the Console drop-down menu.
Creating Configuration Files
Recovery Manager for Oracle relies on configuration files for most of its operations. There are two
types of configuration files: Recovery Manager for Oracle with Remote Copy and Recovery Manager
for Oracle without Remote Copy. The Recovery Manager for Oracle repository is located in the
/etc/3par/solutions/<db_server>.ora.<oracle_sid> directory on the backup server.
For additional details on creating configuration files with or without the Remote Copy feature, see
“Recovery Manager for Oracle Configuration Files” (page 44).
NOTE: The configuration file cannot be recreated if it already exists in the repository. You can
modify the configuration as needed, or remove the configuration before a new one can be created.
Modifying Configuration Files
Configuration files can only be modified from the host node level. Modifications are made in the
config and config_exp.sh files in the repository.
Removing Configuration Files
Configuration files can be removed if the Virtual Copies do not exist in the repository. When
configuration files are removed, the entire repository is also removed.
Configuring Email
In order to receive email notification for the completion of scheduled tasks, you must configure
email settings before scheduling tasks.
1. Right-click a database in the navigation tree and select Email Configuration.
The Email Configuration dialog box appears.
2. Enter the requested information.
3. Select Test Connection to send a test email message to confirm the email is properly configured.
4. Select Finish after successfully receiving the test email message.
Creating a Virtual Copy
This feature supports backup for online, offline, datafile, and archive log destinations.
Creating a Virtual Copy requires the database server name and the Oracle SID. Perform this
function through the menu, tool bar, and popup menu.
To create a Virtual Copy, perform the following procedure:
1. Right-click Virtual Copy Management from the navigation tree under the database you wish
to create the Virtual Copy.
2. Select Create Virtual Copy.
The Create Virtual Copy wizard appears.
Creating Configuration Files 89
3. Select the desired options from the Backup Method group box.
• Online (Hot) backup - The involved database instance must be open for this operation.
The database is put in backup mode before the Virtual Copy is created. After the Virtual
Copy creation is completed, the database is taken out of backup mode.
• Offline (Cold) backup - The involved database instance must be shut down normally for
this operation.
• Datafile only - The involved database instance must be open for this operation. The
database is put in backup mode before the Virtual Copy is created. After the Virtual Copy
creation is completed, the database is taken out of backup mode. This backup only takes
a Virtual Copy for all datafiles and not for the archive logs. A Virtual Copy created with
this option is only useful when archive logfiles generated during the creation of the Virtual
Copy are also available. You may want to create separate Virtual Copies using the
Archive log destination only option.
• Archive log destination only - The involved database instance must be open for this
operation. The database is forced to switch logs before a Virtual Copy of archive logs is
created.
4. (Optional) Select the Virtual Copy’s Expiration Time and/or Retention Time by selecting the
unit of measure (Days or Hours) and entering a numeric value from 1 to 1,825 (days) or 1 to
43,800 (hours). Deselecting the checkbox indicates there is no expiration and/or retention
time.
5. Click Next.
6. (Optional) If you wish to schedule a task for the Virtual Copy, perform the following:
NOTE: If you are using HP UX; before you can schedule tasks, the system administrator must
add your user name to the relevant permissions file:
/usr/lib/cron/cron.allow
a. Select Schedule task.
b. (Optional) Select Email result to recipient when task is finished for Email notification.
NOTE: In order to receive an Email notification, you must have previously configured
an Email address, as described in “Configuring Email” (page 89).
c. Select a Start Time from the drop-down list, or enter a start time.
d. Select a task duration of Hourly, Daily, Weekly, or Monthly.
e. Select the task interval.
f. Click Finish.
NOTE: If you are using HP UX, the system might display the following message:
commands will be executed using /usr/bin/sh
This message is a generic warning from the OS and can be ignored.
For more information about using the CLI to create a Virtual Copy, see “rmora_create” (page
63).
Setting up a Time-Based Virtual Copy Policy
This feature allows you to set the days or hours that a Virtual Copy is kept relative to the creation
time of a Virtual Copy before it is automatically removed. It also allows you to set the number of
days or hours a Virtual Copy is retained.
90 Using the Recovery Manager for Oracle Graphical User Interface
NOTE: You can configure the Virtual Copy policy by using either a time or numeric-based policy.
HP recommends using a time-based policy instead of a numeric-based policy. The numeric-based
policy will not be supported in a future release.
To create a time-based Virtual Copy policy:
1. Right-click the database on which you will create the Virtual Copy policy from the navigation
tree and select Modify Configuration.
The Modify Recovery Manager Configuration Properties wizard appears.
2. Click Next until you reach the Recovery Manager Policy in the wizard.
3. Select Default expiration time and/or Default retention time.
4. Select the unit of measure for the Default expiration time and/or the Default retention time as
Days or Hours.
5. Enter a numeric value from 1 to 1,825 (days) or 1 to 43,800 (hours) in the adjacent fields.
6. Click Next and then Finish.
To update a time-based Virtual Copy policy:
1. Right-click Virtual Copy Management under the database on which you wish to create the
Virtual Copy policy from the navigation tree and select Policy.
The Recovery Manager Policy dialog box appears.
2. Select Default expiration time and/or Default retention time.
3. Select the unit of measure for the Default expiration time and/or the Default retention time as
Days or Hours.
4. Enter a numeric value from 1 to 1,825 (days) or 1 to 43,800 (hours) in the adjacent fields.
5. Click Finish.
NOTE: The Virtual Copy policy is effective immediately and only applies to newly created
Virtual Copies and not to existing ones.
Setting up a Numeric-Based Virtual Copy Policy
This feature allows you to control of the number of Virtual Copies on an HP 3PAR StoreServ Storage
system using a numeric-based policy. When the maximum number of Virtual Copies is reached,
the oldest copy is removed unless it is retained. If the oldest copy is retained, you cannot create
new Virtual Copies.
NOTE: You can configure the Virtual Copy policy by using either a time or numeric-based policy.
HP recommends using a time-based policy instead of a numeric-based policy. The numeric-based
policy will not be supported in a future release.
To create a numeric-based Virtual Copy policy:
1. Right-click the database on which you will create the Virtual Copy policy from the navigation
tree and select Modify Configuration.
The Modify Recovery Manager Configuration Properties wizard appears.
2. Click Next until you reach the Recovery Manager Policy in the wizard.
3. Select Maximum Virtual Copies.
4. Enter the maximum number of Virtual Copies to be kept in the text field.
5. If you want to remove the oldest Virtual Copy, select Remove the oldest Virtual Copy, indicating
that when the maximum number of Virtual Copies is reached, the oldest Virtual Copy is removed
before a new Virtual Copy is created.
Setting up a Numeric-Based Virtual Copy Policy 91
6. (Optional) Select Default retention time and enter a numeric value from 1 to 1,825 (Days) or
1 to 43,800 (Hours) in the adjacent field to set the number of days or hours that a newly
created Virtual Copy must be retained before it becomes a candidate for removal.
7. Click Next and then Finish.
To update a numeric-based Virtual Copy policy:
1. Right-click Virtual Copy Management under the database on which you wish to create the
Virtual Copy policy from the navigation tree and select Policy.
The Recovery Manager Policy dialog box appears.
2. Select Maximum Virtual Copies.
3. Enter the maximum number of Virtual Copies to be kept in the text field.
4. If you want to remove the oldest Virtual Copy, select Remove the oldest Virtual Copy, indicating
that when the maximum number of Virtual Copies is reached, the oldest Virtual Copy is removed
before a new Virtual Copy is created.
5. (Optional) Select Default retention time and enter a numeric value from 1 to 1,825 (Days) or
1 to 43,800 (Hours) in the adjacent field to set the number of days or hours that a newly
created Virtual Copy must be retained before it becomes a candidate for removal.
6. Click Finish.
NOTE: The Virtual Copy policy is effective immediately and only applies to newly created
Virtual Copies and not to existing ones.
Extending Virtual Copy Expiration and Retention Time
To extend the expiration and retention times of an existing Virtual Copy:
1. Right-click the Virtual Copy you wish to edit under Virtual Copy Management in the navigation
tree and select Edit Time Constraint.
The Edit Time Constraints dialog box appears.
2. Select Expiration time and/or Retention time .
3. Select the unit of measure for the Expiration time and/or the Retention time as Days or Hours.
4. Enter a numeric value from 0 to 1,825 (Days) or 0 to 43,800 (Hours) in the adjacent fields
for Expiration time. Enter 0 if you want to remove the expiration time. Enter a numeric value
from 1 to 1,824 (Days) or 1 to 43,800 (Hours) in the adjacent fields for Retention time.
Removing retention time is not allowed.
5. Click Finish. The expiration and retention date/time will be calculated from the current
date/time.
Refreshing Virtual Copy Information
You can refresh the Virtual Copy information such as Backup Type, Backup Key, Mount point and
Virtual Volume State. If a new Virtual Copy is created outside of the Recovery Manager for Oracle
GUI, the Virtual Copy is added to the navigation view.
1. Select Virtual Copy Management from the navigation view.
2. Select Refresh from the Virtual Copies drop-down menu.
You can also right-click (?) from the drop-down menu of the Virtual Copy Management tree
node or click Refresh at the top of the console window.
NOTE: The refresh process begins immediately and may last a few minutes depending on
the number of Virtual Copies in the Recovery Manager for Oracle repository.
92 Using the Recovery Manager for Oracle Graphical User Interface
Mounting a Virtual Copy
After a Virtual Copy is created, it can be mounted on the backup server where the Recovery
Manager for Oracle GUI is running.
To mount a Virtual Copy, perform the following procedure:
1. Right-click the Virtual Copy you wish to mount.
2. Click Mount.
A screen appears showing the Virtual Copy name, and creation time. You are prompted for
the mount point where you want the Virtual Copy to be mounted on the backup server. The
default mount point is:
/etc/3par/solutions/<db_server>.ora.<oracle_sid>/<timestamp>
3. Click Finish.
Recovery Manager for Oracle begins mounting all the file systems for you. When the mounting
of the file systems is complete, a screen displays the successful message.
4. Click OK.
In the Virtual Volume State column, Mounted should be displayed to indicate the Virtual Copy is
mounted on the backup server. The mount point is also displayed to indicate the location of the
mounted file systems.
After a Virtual Copy is in the Mounted state, a database instance can be created on the backup
server by cloning the database (see “Cloning a Database” (page 95)).
For more information about using the CLI to mount a Virtual Copy, see “rmora_mount” (page
72).
Unmounting a Virtual Copy
When a Virtual Copy is in the Mounted state, an unmount operation can be executed.
To unmount a Virtual Copy:
1. Right-click the Virtual Copy to unmount.
2. Click Unmount.
3. Click Finish.
A successful message shows on screen after it is finished.
4. Click OK.
The Virtual Volume State column for this Virtual Copy changes to Available.
For more information about using the CLI to unmount a Virtual Copy, see “rmora_umount” (page
87).
Rolling Back Using a Virtual Copy
To roll back the primary database to a Virtual Copy’s point-in-time image, perform the following:
1. Right-click the Virtual Copy you wish to roll back under Virtual Copy Management in the
navigation tree and select Rollback.
The Rollback Virtual Copy dialog box appears.
2. If the Virtual Copy is an online full backup, select Full Rollback, Rollback Archive Log, or
Rollback Datafile.
3. (Optional) Select Rollback using Read/Write Virtual Copy.
4. Click Finish.
For more information about using the CLI to rollback a database to a point-in-time, see
“rmora_rollback” (page 80).
Mounting a Virtual Copy 93
Viewing Rollback Status
It make take several minutes to rollback a Virtual Copy depending on its size.
To view a Virtual Copy’s rollback status:
1. Right-click the Virtual Copy you rolled back and select Rollback Status.
The Information dialog box appears displaying the status of the rollback operation.
2. Click OK to close the dialog box.
Removing a Virtual Copy
If the Virtual Volume State column displays Available, the Virtual Copy can be deleted.
CAUTION: Removing a Virtual Copy permanently removes the Virtual Copy from the system.
To remove a Virtual Copy:
1. Right-click the Virtual Copy to remove.
2. Click Remove Virtual Copy.
3. Click Yes to confirm the removal of the Virtual Copy.
A successful message shows on screen after it is finished.
4. Click OK.
The Virtual Copy is removed from the Virtual Copy management list.
Backing up a Virtual Copy
If a Virtual Copy is in the Available state, it can be backed up. If a Virtual Copy is in the Mounted
or Database state, the Virtual Copy needs to be to unmounted prior to being backed up.
NOTE: If Symantec NetBackup is used and the Virtual Copy is an archlog type, or if RMAN is
used and the Virtual Copy is not an archlog type, you can select Full, Incremental, or Cumulative
Incremental.
To backup a Virtual Copy:
1. Right-click the Virtual Copy to be backed up to media.
2. Click Backup to Media.
3. Select the Backup type if it is enabled.
4. Click Finish.
5. Click OK.
Removing a Virtual Copy Repository
Normally, when the Virtual Copy is removed, the repository is deleted. However, if you have
already backed up the repository, it is not automatically removed. It is kept to apply the restore
operations when necessary. After the Virtual Copy repository is removed, the Virtual Copies have
a status of Removed and all information related to this Virtual Copy set is lost.
For more information about the Virtual Copy Repository, refer to “About the Recovery Manager
for Oracle Repository” (page 7) and “The Virtual Copy Repository” (page 16).
1. Right-click the Virtual Copy name to be removed from the entire repository.
2. Click Remove Virtual Copy Repository.
3. Click Yes to confirm the removal of the repository.
The removed repository is no longer displayed on the Virtual Copy management screen.
94 Using the Recovery Manager for Oracle Graphical User Interface
Restoring Archive Log, Datafiles, and Tablespaces
NOTE: If Symantec NetBackup (NBU) is used to back up datafiles, NBU can be used to restore
datafiles to the database server, backup server, or any other hosts where the NBU clients for the
same NBU master server are configured. If the Virtual Copy is being backed up using NBU, the
backup key has the format: <oracle_sid>_<db_server>_<timestamp>.
To restore a datafile or tablespace:
1. Select Virtual Copy Management in the navigation tree.
2. In the viewing pane, right-click the desired Virtual Copy and select Restore.
The Restore Database from Media Backup dialog box appears.
3. In the Restore Destination group box, enter the Host Name, Oracle SID, Oracle Home, and
Mount Point (only for NBU) for restoring the datafiles or tablespace. If the Mount Point is left
blank, files are restored to their original paths on the database server.
4. If the Virtual Copy is an archlog type, you can only restore an archive log. Otherwise, in the
Restore Options group box select one of the following:
• Full Database - If selected, you can optionally Restore Database Control Files.
• TableSpace - If selected, select one or more tables to restore.
• Datafiles - If selected, select one or more datafiles to restore.
5. Click Finish.
Refreshing Database Information
Tablespace, datafile, archive log, and virtual volume information can be refreshed in the Recovery
Manager for Oracle GUI by performing the following:
1. Right-click Tablespace, Datafiles, Archive Log, or Virtual Volumes in the navigation tree.
2. Click Refresh.
Recovery Manager for Oracle retrieves all the information from the database.
All mappings are for informational purposes and cannot be modified. All mappings reflect the
current database and Virtual Copy information if the database is accessible.
Exporting a Virtual Copy to an Alternate Backup Server
After a Virtual Copy is created, it can be exported to an alternate backup server.
Export a Virtual Copy as follows:
1. Right-click the Virtual Copy you wish to export and click Export.
The Export Virtual Copy screen appears.
2. On the Export Virtual Copy screen, provide the following information:
• Alternate backup host name - the name of the backup server to which the Virtual Copy
is exported.
• Storage system SSH username - the storage system user name for the alternate backup
server.
• Backup server name in Storage System - the alternate backup server name defined in the
HP 3PAR StoreServ Storage system.
3. Click Finish to start exporting the Virtual Copy.
Cloning a Database
Each online Virtual Copy created by Recovery Manager for Oracle represents a point-in-time
database image. Recovery Manager for Oracle can use the Virtual Copy to help restore the
Restoring Archive Log, Datafiles, and Tablespaces 95
database, or to clone the database for testing, decision making, and report generating purposes.
The cloning capability takes the workload out of the database server and reduces performance
impact.
In order to create the cloned database from Virtual Copies, these Virtual Copies must be created
by Recovery Manager for Oracle with the online or offline database option.
The cloned database is created on the backup server.
To clone a database:
1. Select a Virtual Copy that has a status of Mounted.
2. Right-click the mounted Virtual Copy and click Create database.
3. Provide the new database ID and the Oracle home directory.
4. If an ascii control file is chosen to clone the database (this is default option), provide one or
more mount points on the backup server for the control files and the redo log files (control files
and redo log files are multiplexed across the mount points).
Example: If you provide /clone_directory1, /clone_directory2, +CLONE_DATA
notice combined ASM diskgroup and file systems are allowed in this operation, make sure
adequate permissions are granted for the user executing the clone utility. If the binary control
file is chosen to clone the database, the clone operation will use exactly the same structure
as that in the database. The Virtual Copy must be mounted at '/' before the database creation
operation starts in order to ensure the clone database has exactly the same structure for all
database files.
5. Click Finish.
After the cloned database operation has completed, the Virtual Volume column is changed
from Mounted to Database to indicate the cloned database is up and running.
6. Click OK.
Removing a Cloned Database
When a cloned database is no longer needed, it can be removed with the following procedure:
1. Select a Virtual Copy with a status of Database.
2. Right-click on the selected Virtual Copy and click Remove database.
3. Click Yes.
4. Click OK.
Periodic Database Synchronization
The periodic synchronization process is an asynchronous process. Synchronization takes minutes
to hours for the synchronized process to finish depending on data changes, network speed, and
load on the database server, backup server, primary/local and secondary/remote HP 3PAR
StoreServ Storage systems. When the synchronization completes, Recovery Manager for Oracle
creates a Virtual Copy on the remote (secondary) HP 3PAR StoreServ Storage system, updates the
navigation view, and sends notification to the user.
Starting Periodic Synchronization
To start periodic synchronization on a Remote Copy node:
1. Right-click a Remote Copy node on the navigation tree and click Initiate Sync.
The Periodic Synchronization Virtual Volumes screen appears.
2. Depending on the setup of your database, select either Online (Hot) Backup or Offline (Cold)
Backup.
3. (Optional) Select Expiration time and enter a numeric value from 1 to 1,825 (Days) or 1 to
43,800 (Hours) in the adjacent field.
96 Using the Recovery Manager for Oracle Graphical User Interface
4. (Optional) Select Retention time and enter a numeric value from 1 to 1,825 (Days) or 1 to
43,800 (Hours) in the adjacent field.
5. Click Finish.
After the periodic synchronization process is started, the command log view of the Recovery
Manager for Oracle GUI displays a status of started and then changes to Success when the
Virtual Copy is created.
Verifying the Periodic Synchronization Process
When starting periodic synchronization on a Remote Copy node, you may wish to verify that the
synchronization process is occurring.
• To verify the periodic synchronization on a Remote Copy node, right-click the Remote Copy
node where synchronization has started and click Periodic Sync Status.
A window appears displaying the status of the synchronization process.
Refreshing Remote Copy Information
After performing periodic synchronization on a Remote Copy node, you need to refresh the Recovery
Manager for Oracle GUI so that the most current information is displayed.
• To refresh Remote Copy information, right-click the Remote Copy node on which synchronization
was performed and click Refresh.
Backing Up a Database
When backing up a database, a Virtual Copy is created of the database and the database is then
backed up. Backing up a database is not supported on Remote Copy configurations, or if a Vendor
Backup Product is not selected in the configuration.
1. Right-click the database you wish to backup, and then select Backup to Media.
2. Select the Backup Method.
• Online (Hot) backup - The involved database instance must be open for this operation.
The database is put in backup mode before the Virtual Copy is created. After the Virtual
Copy creation is completed, the database is taken out of backup mode.
• Offline (Cold) backup - The involved database instance must be shut down normally for
this operation.
• Datafile only - The involved database instance must be up for this operation. The database
is put in backup mode before the Virtual Copy is created. This backup only takes a Virtual
Copy for all datafiles; not archive log destination. A Virtual Copy created with the this
option is only useful when archive logfiles generated during the creation of the Virtual
Copy are also available. You may want to create separate Virtual Copies using the
Archive Log Destination Only option. After the Virtual Copy creation is completed, the
database is taken out of backup mode.
• Archive Log Destination Only - The involved database instance must be open for this
operation. The database is forced to switch logs before a Virtual Copy of archive logs is
created.
Backing Up a Database 97
3. Select the Backup Type.
NOTE: Incremental backup of archive log using RMAN is not supported.
a. Full backup - Performs a full backup of a Virtual Copy. If Symantec NetBackup is selected
as the backup method, this option can be used with the -o archonly option to perform
full backup of an archonly Virtual Copy. If Oracle RMAN is selected as the backup
method, this option can be used to perform full backup of an online or offline Virtual
Copy.
b. Differential incremental backup - Performs an incremental backup of a Virtual Copy. If
Symantec NetBackup is selected as the backup method, this option can be used with the
Archive log Destinations Only option to perform incremental backup of an archive-only
Virtual Copy. If Oracle RMAN is selected as the backup method, this option can be used
to perform an incremental backup of an online or offline Virtual Copy.
c. Cumulative incremental backup - Performs a cumulative incremental backup of a Virtual
Copy. If Symantec NetBackup is selected as the backup method, this option can be used
with the Archive log Destinations Only option to perform a cumulative incremental backup
of an archonly Virtual Copy. If Oracle RMAN is selected as the backup method, this
option can be used to perform a cumulative incremental backup of an online or offline
Virtual Copy.
4. Click Next.
5. (Optional) Select Schedule task if you wish to schedule a backup task.
NOTE: If you are using HP UX, the system administrator must add your user name to the
/usr/lib/cron/cron.allow file before you can schedule tasks.
a. Select a Start Time from the drop-down list, or enter a start time.
b. Select a task duration of Hourly, Daily, Weekly, or Monthly.
c. Select the task interval (1 to 12 hours).
6. Click Finish.
NOTE: If you are using HP UX, the system might display the following message:
commands will be executed using /usr/bin/sh
This message is a generic warning from the OS and can be ignored.
Using the Task Manager
The Task Manager allows you to view, edit, and delete any Recovery Manager for Oracle tasks
or scripts.
1. To access the Task Manager, click Scheduled Tasks→Task Manager.
2. Select a task from the task window and then click Edit, Detail, or Delete. To refresh the list,
click Refresh.
3. When you have completed your task management activities, click OK.
Viewing Event Messages
To view error messages, their explanations, and appropriate troubleshooting actions, select
Help→Event Messages from the menu bar.
The event messages for Recovery Manager for Oracle appear in a web browser.
For more information about event messages, see “Troubleshooting” (page 140).
Viewing Online Help
To view online help for Recovery Manager for Oracle, select Help→Online Help.
98 Using the Recovery Manager for Oracle Graphical User Interface
Recovery Manager for Oracle Online Help appears in a web browser.
Using a Web Browser to Access Online Help and Event Messages
Recovery Manager for Oracle supports the latest versions of Firefox. If the Recovery Manager for
Oracle GUI is unable to launch online help or event messages in Firefox, it attempts to launch your
system’s default browser.
If the Recovery Manager for Oracle GUI is unable to launch a browser, it prompts you to install
Firefox as follows:
Firefox VersionOS
3.6.27 or greaterLinux
3.6.18 or greaterSolaris
3.5.09.00 or greaterHP-UX
To verify that the Recovery Manager for Oracle GUI can launch the installed browser, launch the
browser from the command line prompt you use to launch the Recovery Manager for Oracle GUI.
Additional Information about the Recovery Manager for Oracle GUI
The following sections provide additional information about the display elements of the Recovery
Manager for Oracle GUI.
RAC Databases
Recovery Manager for Oracle GUI displays information for all RAC database instances. When an
operation is performed on one RAC instance, the navigation tree is refreshed to update all
corresponding RAC instances.
Standby Databases
Standby databases are displayed in the Recovery Manager for Oracle navigation tree with a red
dot in front of their database icons.
Using a Web Browser to Access Online Help and Event Messages 99
6 Using the Recovery Manager Rollback Utility
Recovery Manager for Oracle provides a way to rollback a database to a point-in-time image by
promoting a read-only or read-write Virtual Copy back to the base (database) virtual volumes.
The base (database) virtual volume must not be exported to any host during the rollback process.
In other words, the database LUNs of the corresponding database virtual volumes must be removed
from the database server prior to the rollback process. Once the rollback process completes, the
database LUNs can be exported back to the database server.
NOTE: When using rollback utility with Remote Copy configuration. The Virtual Copy will rollback
on the secondary HP 3PAR StoreServ Storage system. Refer to the HP 3PAR Remote Copy Software
User’s Guide to reverse the Remote Copy configuration. If a Virtual Copy is a standby database,
the base virtual volumes of the standby database (not the primary database) is rolled back.
rmora_rollback Usage
Refer to “rmora_rollback” (page 80) for the syntax and available options for the
rmora_rollback command.
Syntax: rmora_rollback -s <oracle_sid> -p <primary_host> -t <timestamp>
[-o data|arch] [-v] [-w] [-f]
The purpose of this procedure is to rollback the database base volumes to the point in time when
the Virtual Copy was taken.
Rollback Using a Database Read-Only Virtual Copy
1. On the database server, shutdown the database. If the database is a Real Application Clusters
(RAC) database, all RAC instances must be shutdown.
2. On the database server, unmount all database file systems if they are on file systems.
Example for systems with VxFS:
# umount /oradata
3. On the database server, drop the database ASM disk groups if ASM is in use.
Example:
SQL>drop diskgroup <disk_group> including contents;
4. On the database server, deport the database VxVM disk groups if Symantec VxVM is in use.
Example:
# vxdg deport <diskgroup>
5. On the HP 3PAR StoreServ Storage system, remove the VLUNs for the database virtual volumes.
Example:
cli>removevlun Oracle_data1 101 pilot
6. Keep the list of the VLUNs, which are removed by the command above. The database virtual
volumes need to be exported to the same VLUNs.
100 Using the Recovery Manager Rollback Utility
Loading...