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
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
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 Copies7
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).
8Overview 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 RMAN9
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:
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.
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.
10Overview 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 Utilities11
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.
12Overview 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 Utilities13
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.
14Overview 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 Utilities15
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:
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.
16Overview 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 Copy17
•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.
18Overview 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 Tools19
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.
20Overview 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 ConceptsGuide 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 Database21
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.
22Overview 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-Fat23
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.
24Installing 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 RemoteCopy 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 Systems25
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.
26Installing 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.
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
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 Systems27
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.
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:
28Installing 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
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 Systems29
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.
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