| Subject: |
RMAN: Configuring HP Omniback
with RMAN |
| |
Doc
ID: |
Note:77552.1 |
Type: |
BULLETIN |
| |
Last Revision Date: |
10-OCT-2005 |
Status: |
PUBLISHED |
PURPOSE
The purpose of this document is to act as a 'quick start' guide to configuring
HP Omniback integration with Oracle RMAN.
SCOPE & APPLICATION
This document is aimed at Support Personnel. It is not intended as a replacement
for detailed Omniback or RMAN documentation.
Omniback queries should be directed at the Omniback / Dataprotector Support Centre.
NOTE: This document describes a setup in a certain configuration and might
be bound to the used versions.
New versions of OmniBack / Dataprotector might have a different setup.
Contact your Omniback / Dataprotector Support Centre for more specific information.
RELATED DOCUMENTS
Note 50875.1 Getting started with Server-Managed Recovery (SMR) and RMAN
Note 73431.1 RMAN Compatibility Matrix
Oracle8i & 9i Server Backup & Recovery Guide
Omniback documentation
http://ovweb.external.hp.com/lpe/doc_serv
0. Introduction
===============
This Note can be used as a starting point when configuring Omniback with
RMAN. The examples in this Note used the following software:
i. HP Omniback 4.10 for HP-UX 11
ii. Oracle 8.1.7 (32 bit)
The Oracle commands are not specific to HP-UX. However, many of the Omniback
references may not be relevant to other operating systems (Omniback is also
available on NT and Solaris).
1. Create Recovery Catalog
==========================
Create a recovery catalog, as detailed in Note 50875.1.
The recovery catalog schema can be initially sized at 20MB.
2. Setup SQLNet Connectivity to Recovery Catalog
================================================
A TCP loopback test to the catalog should be performed.
% sqlplus rman/rman@catalog
where the SQL*Net alias for the catalog database is 'catalog'.
3. Setup SQLNet Connectivity to Target Database
===============================================
A user with SYSDBA privileges is required to connect to the target database.
i. set up remote logins to the target database
a. add the following to the init.ora:
remote_login_passwordfile=exclusive
b. create a password file
orapwd file=$ORACLE_HOME/dbs/orapw$SID password=oracle
ii. for the above changes to take affect, stop/start the target instance
iii. create a user, and grant SYSDBA priveleges
This step is optional, as the 'internal' could be used.
SVRMGR> create user targdba identified by targdba
temporary tablespace temp
default tablespace users quota unlimited on users;
SVRMGR> grant connect, resource to targdba;
SVRMGR> grant sysdba to targdba;
Note, if (i) and (ii) have not succeeded, this step will fail with
ORA 1994 - GRANT failed: cannot add users to public password file
iv. Do a loopback test as the SYSDBA user
% sqlplus targdba/targdba@target
or
% sqlplus internal/oracle@target
where the SQLnet alias for the target database is 'target'.
NB. Certain operations in the Omniback GUI require access to tables/views that
are not available to all users.
For example, expanding the 'database' icon into a list if tablespaces
requires access to DBA_TABLESPACES.
The targdba user given above does not have SELECT privilege on DBA_TABLESPACES.
For this reason, it may be preferable to use the internal/oracle example.
4. Enable Archiving
===================
Both the RMAN catalog and the target database may need to have archiving enabled.
eg, init.ora changes:
log_archive_dest = /oracle/OFA_base/app/oracle/admin/V817/arch/arch_
log_archive_format = _%s.arc
log_archive_start = true
SQL> startup mount
SQL> alter database archivelog;
SQL> alter database open;
5. Install Omniback
===================
Follow the Omniback documentation to install Omniback. A common problem is not
being able to find the Omniback API Library after installation. This is because
initial installation only installs the Oracle installation packet (referred to
as OB2-ORA). This installation packet needs to be pushed to the Oracle server
(in this context, Oracle servers are Omniback clients).
To do this, open the Omniback GUI, and choose clients. Choose the client that
has the Oracle server, and right click. Choose 'add components', and follow
the wizard.
After installation, Omniback creates the following base directories:
/var/opt/omni
/opt/omni
/etc/opt/omni
Omniback patches can be found at
http://support.openview.hp.com/patches/patch_index.jsp
6. Integrate RMAN with the Omniback API Library
===============================================
The instance (in fact, all instances with this ORACLE_HOME) need to be shutdown
prior to the following, and restarted after. This assumes the default location
of /opt/omni/lib for the Omniback library.
For 32 bit Oracle8i:
% cd $ORACLE_HOME/lib
% mv libobk.sl libob.sl.orig
% ln -s /opt/omni/lib/libob2oracle8.sl libobk.sl
For 64 bit Oracle8i
% cd $ORACLE_HOME/lib64
% mv libobk.sl libob.sl.orig
% ln -s /opt/omni/lib/libob2oracle8_64bit.sl libobk.sl
For Oracle 9i (on HP-UX, this is available as 64 bit only)
% cd $ORACLE_HOME/lib
% mv libobk.sl libob.sl.orig
% ln -s /opt/omni/lib/libob2oracle8_64bit.sl libobk.sl
To verify the relink was succesful,
% cd $ORACLE_HOME/bin
% chatr oracle
oracle:
shared executable
shared library dynamic path search:
SHLIB_PATH disabled second
embedded path disabled first Not Defined
shared library list:
dynamic /oracle2/OFA_base/app/oracle/product/8.1.7/lib/libjox8.sl
dynamic /oracle2/OFA_base/app/oracle/product/8.1.7/lib/libobk.sl
<...more output here...>
% ls -la /oracle2/OFA_base/app/oracle/product/8.1.7/lib/libobk.sl
lrwxr-xr-x 1 hpsupp support 30 Apr 29 12:48
/oracle2/OFA_base/app/oracle/product/8.1.7/lib/libobk.sl@ -> /opt/omni/lib/libob2oracle8.sl
Note that the Omniback API is now linked into the oracle 8i executable.
Note that for Oracle9i the libobk file is no longer linked in with the oracle
executable. The libobk is linked in at runtime by looking for the libobk in
the $ORACLE_HOME/lib directory or by setting RMAN allocate or configure channel
parameter SBT_LIBRARY.
7. Create the 'oracle' user in Omniback
=======================================
Start /opt/omni/bin/xomni as root
i. from the Omniback 'Main' window, choose 'Users' from dropdown list
ii. right click on 'operator' or 'admin' in 'Users' list, and choose 'Add Users...'
NB. The user must be in the admin or operator group
iii. 'Type' field is UNIX
'Name' field is the oracle software owner eg, oracle
'UNIX Group' is the UNIX group of the oracle software owner eg, dba
'Description' is some string that identifies this user
'Client' should be the host on which the target instance resides
NB. If text cannot be entered into the input boxes, choose '<Any>' from the
dropdown list of values, and edit user afterwards.
8. Register the Target Database via Omniback
============================================
This step uses a Omniback script to
a. tell Omniback about the target and catalog databases
b. register the target database with the catalog (if not already registered)
The simplest way to do this is to run 'Create New Backup' from the Omniback GUI.
If the target database is not already registered with Omniback, then Omniback
prompts for relevant parameters, and runs /opt/omni/lbin/util_oracle8.exe
transparently. The GUI can also be used to check the configuration.
Alternatively, run /opt/omni/lbin/util_oracle8.exe manually, as shown below.
i. run /opt/omni/lbin/util_oracle8.exe. The usage is:
/opt/omni/lbin/util_oracle8.exe -CONFIG \
<ORACLE_SID> <ORACLE_HOME> \
<TARGET DATABASE CONNECT STRING> \
<RECOVERY DATABASE CONNECT STRING>
ii. this will cause SQLNet connections to be established to the
catalog and target databases. Consequently, TNS_ADMIN must be set if
required.
For example, using the info from steps (2) and (3)
% export TNS_ADMIN=/oracle/TNS_ADMIN
% /opt/omni/lbin/util_oracle8.exe -CONFIG RMAN81T \
/oracle2/OFA_base/app/oracle/product/8.1.7 \
targdba/targdba@81targ \
rman/rman@81cat
This step creates the following files in the directory
/etc/opt/omni/integ/config/Oracle8
i. <machine name>%<ORACLE_SID of target>
- this contains encrypted logon info, ORACLE_HOME, ORACLE_VERSION
- replaces the following, found in previous releases of Omnniback
/etc/opt/omni/oracle8/<ORACLE_SID>
catconn - an encrypted catalog connect string
tgtconn - an encrypted target connect string
oracle_home - ORACLE_HOME for the target
ii. <machine name>%_OB2_GLOBAL
- global configuration file for Omniback
- contains a list of instances configured for Omniback
a list of Omniback global variables
Note that if TNS_ADMIN needs to be set in the environment, then the file
/etc/opt/omni/oracle8/<ORACLE_SID>/.profile
needs to be created to set TNS_ADMIN. The contents of this file need to
be of the form:
TNS_ADMIN=/oracle/TNS_ADMIN
export TNS_ADMIN
To check the config, run the following
%/opt/omni/lbin/util_oracle8.exe -CHKCONF <ORACLE_SID>
For a succesful configuration, the output is:
% /opt/omni/lbin/util_oracle8.exe -CHKCONF RMAN81T
*RETVAL*0
NB - any non-zero RETVAL is an error
9. Configure and Run an Omniback Backup
=======================================
This cannot be fully described in this Note. However, the main points encountered
during setup are documented here.
i. from the Omniback 'Main' window, click on 'Backup'
ii. from the 'Backup' Window menu, expand the 'Backup' tree to:
Backup
--> Backup Specification
--> Oracle8 Server (this is the case for Oracle9 also)
Right click on 'Oracle8 Server'. Choose 'Add Backup'
iii. Fill in the 'Client and 'Application Database' values from the list of values
given.
The list of 'Application Databases' is from /etc/oratab.
The 'User' and 'Group' are the UNIX user that will carry out the backup,
typically oracle/dba.
iv. Complete the remaining steps.
The RMAN script produced will be of the following form (assuming the script
is saved with as 'test_full'):
run {
allocate channel 'dev_0' type 'sbt_tape'
parms 'ENV=(OB2BARTYPE=Oracle8,OB2APPNAME=RMAN81T,OB2BARLIST=test_full)';
backup incremental level <incr_level> filesperset 1
format 'test_full<RMAN81T_%s:%t:%p>.dbf'
database
include current controlfile
;
}
This is saved as a Omniback script /etc/opt/omni/barlists/oracle8/test_full.
The script is referred to as the 'backup specification name'.
Note the ENV parameters in the 'allocate channel' command. These are Omniback
specific; the meanings are
OB2BARTYPE - this will be 'Oracle8' for RDBMS 8i and 9i
OB2APPNAME - this is the target database ORACLE_SID
OB2BARLIST - this is the name of the RMAN script
The 'rman' executable is called by the Omniback executable ob2rman.exe.
By default, Omniback will take an export of the RMAN Catalog (a user level export,
as 'rman' user), and backs that up to tape. The export is initially dumped in
/var/opt/omni/tmp.
Note: This section has omitted many steps, such as:
- setting the protection levels on the device
- setting concurrency on the device
- pre and post exec scripts (see below)
- reporting levels
The progress of a backup can be monitored with :
/opt/omni/bin/omnistat
Restrictions imposed on backup scripts are discussed below.
If the backup does not run, verify the integration as follows:
i. ensure the configuration has been checked (see Step (8))
ii. ensure the cell server name is correct in
/etc/opt/omni/cell/cell_server
Try replacing this with the IP address if hostname lookup is problematic
iii. verify Omniback internal data transfer. The following command will write
a very small amount of data to tape, simulating a backup
/opt/omni/bin/utilns/testbar -type:Oracle8 \
-appname:<ORACLE_SID> -bar:<backup specification name> -perform:backup
The Monitor window in the Omniback GUI will report any errors, which should
be followed accordingly.
10. Restoring an Omniback Backup
================================
Omniback does not have functionallity for a RMAN restore. The restore must be
carried out manually.
For example, using the connect info already provided in the note.
% rman catalog rman/rman@81cat target targdba/targdba@81targ
RMAN> run {
2> allocate channel c1 type 'sbt_tape' ;
3> restore database;
4> }
During the restore, the Omniback GUI 'Monitor' Window will track progress. This
info can also be found in sbtio.log (user_dump_dest).
To diagnose restore problems, Omniback provides 'omnidb' to interrogate the
Omniback database, and 'testbar' to simulate restore of identified backup sets.
omnidb is used to gather details about the backup that needs to be restored. This
also verifies that the object exists in the Omniback catalog.
For example
% omnidb -session -detail
- execute this if no details known about the backup
% omnidb -session -datalist "Oracle8 <backup specification name>"
- execute this to limit the output (if backup spec name known)
eg, omnidb -session -datalist "Oracle8 test_full"
Look through the output, and pick out the SessionID for the session that carried
out the backup. The SessionID wil be of the form "2002/05/15-7".
To obtain the names of Omniback Objects (backup sets), execute
% omnidb -session <SessionID>
eg, omnidb -session 2002/05/15-7
Note the "Object Name" values.
Armed with this info, call testbar to simulate a recovery session. This will
restore a small amount of data from the specified Object Name.
/opt/omni/bin/utilns/testbar -type:Oracle8 -appname:<ORACLE_SID> \
-perform:restore -object:"<object name>" \
-bar:<backup specification name> -version:<version>
where
<object name> is the ObjectName returned by omnidb (see above)
Do not inlcude the "hostname:" returned by omnidb
<version> is the SessionID given above
eg,
testbar -type:Oracle8 -appname:RMAN81T -perform:restore \
-object:"test_full<RMAN81T_33:461944988:1>.dbf" \
-bar:test_full -version:2002/05/15-7
The Monitor window in the Omniback GUI will report any errors, which should be
followed accordingly.
11. Log Files & Debugging
=========================
a. There are many log files in /var/opt/omni/log, notably
oracle8.log - oracle related messages
debug.log - Omniback system messages and unexpected errors
media.log - Omniback tape related messages
b. sbtio.log in user_dump_dest
c. Omniback Debugging
Most Omniback commands can take the -debug parameter. The format of the
debug switch is
-debug 1-200 XYZ "host"
where 1-200 is the debug range - HP should be able to advise on this
XYZ is the debug trc file suffix
host is where debug is to be turned on (optional)
Debug will cause many trace files to be created in /tmp, with names of the form
OBprogram_Host_OBPid_XYZ
From an Oracle perspective, turn on debugging by executing a command like:
/opt/omni/lbin/util_cmd -putopt Oracle8 RMAN81T OB2OPTS \
'-debug 1-200 debug_RMAN81T.txt' \
-sublist Environment
Turn the debugging off with :
/opt/omni/lbin/util_cmd -putopt Oracle8 RMAN81T OB2OPTS \
'' \
-sublist Environment
In the above RMAN81T is the ORACLE_SID
This updates /etc/opt/omni/integ/config/Oracle8/<host>%<ORACLE_SID> with an
entry in the Environment string, such as
Environment={
OB2OPTS='-debug 1-200 debug_RMAN81T.txt';
}
From now on, all Omniback commands for this instance will give debug output.
The debug filenames will of the form /tmp/*debug_RMAN81T.txt.
HP should be consulted before enabling Omniback debugging.
APPENDIX A - Miscellaneuos Omniback Commands
==========
% /opt/omni/lbin/util_cmd
util_cmd -getconf Oracle8 <ORACLE_SID>
- get config for an instance
util_cmd -putopt Oracle8 <ORACLE_SID> OB2OPTS \
'-debug 1-200 INSTANCE.txt' -sublist Environment
- set global environment (debugging in this case)
% /opt/omni/lbin/omnigetmsg
omnigetmsg <set number> <error number>
- get an error description for a given error in a given set
omnigetmsg 12 <error number>
- Oracle errors are in set 12
Note that the error descriptions tend to be high level
eg, [12:8324] This Oracle8 Server instance is not configured
% /opt/omni/bin/utilns/testbase -perform:checkuser
- verifies permissions of current user
should run as oracle/dba
% /opt/omni/lbin/util_oracle8.exe -CHKCONF <ORACLE_SID>
- check config of Oracle server
% /opt/omni/sbin/utilns/get_info
- gather Omniback system info, in preparation for submitting a Omniback
support call to HP
APPENDIX B - PRE-EXEC, POST-EXEC SCRIPTS
==========
When configuring a backup, pre-exec and post-exec scripts can be entered. These
are scripts/commands that are started on the Oracle server prior/post backup.
ob2rman.exe is called with arguments "-pre <script name> -post <script name>".
ob2rman.exe then calls the pre/post exec script, which runs as the user that
owns the backup specification (typically oracle/dba).
The full path name to the script should be entered, such as
/tmp/preexec
where this file contains (for illustrative purposes only):
#!/bin/ksh
export ORACLE_HOME=/oracle2/OFA_base/app/oracle/product/8.1.7
export ORACLE_SID=RMAN81T
$ORACLE_HOME/bin/sqlplus /nolog << EOF
connect sys/change_on_install as SYSDBA
shutdown
EOF
execute permission should be granted
%chmod +x /tmp/preexec
The script should set the ORACLE_HOME and ORACLE_SID environment variables. Also,
the full path to sqlplus is given.
NB. /tmp is not a sensible place for such scripts
APPENDIX C - backup script limitations/issues
==========
1. Channel definitions should always be of the form
parms 'ENV=(OB2BARTYPE=Oracle8,OB2APPNAME=<ORACLE_SID>,OB2BARLIST=<backup specification name>)';
2. Omniback limits filesperset to 1
filesperset=1
3. Omniback must have the backup file format as
format '<backup specification name><<ORACLE_SID>_%s:%t:%p>.dbf'
The %s:%t:%p substitution variables are mandatory. Other variables can be added.
4. Omniback supplied backup script templates
Users should use the supplied scripts with caution. The following are examples
of bad RMAN practise that have been noted in these scripts:
i. archive logs switched prior to backup of datafiles, rather than afterwards
(this seems to have been corrected in Omniback 4.1)
ii. current archive log not switched and backed up after database/archive
logs backup
iii. controlfile not backed up after datafiles and archivelogs, but included
in database backup instead
. |
