[HPADM] SUMMARY: RMAN and Omniback 3.5

From: Tripathi, Ashish (ATripathi@us.infogrames.com)
Date: Mon Jul 08 2002 - 11:34:34 EDT


Thanks goes to Oscar Armanini, Tim Reed, Jim Turner,Ak Dev and Anil Rajapure
for their informative replies.Most of them pointed me to refer to following
URL
http://ovweb.external.hp.com/lpe/doc_serv/

But now I have a different kind of problem. My Oracle database(8.1.7) is on
a Compaq Tru64 Unix box running 5.1 and according to HP Openview supported
matrix web site ,RMAN on Compaq Tru64 is not supported. Is there anyone who
is using this configuration?

Below is the reply from Oscar Armanini which was the most descriptive.

Note:77552.1 Content Type: TEXT/PLAIN
Subject: RMAN: Configuring HP Omniback with RMAN Creation Date:
23-NOV-1999
Type: BULLETIN Last Revision Date: 12-JUN-2002
Status: PUBLISHED

--------------------------------------------------------------------
This article describes a solution that was used to resolve this
issue for another Oracle customer. As it relates to a third-party
product, Oracle does not guarantee that this resolution will work
for all customers using this or any other third-party product. The
appropriate third-party vendor should be contacted if there are any
questions or problems relating to this resolution or these errors.
--------------------------------------------------------------------

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 HP Response Centre.

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.
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/rdbms/lib
   % mv libobk.sl libob.sl.orig
   % ln -s /opt/omni/lib/libob2oracle8.sl libobk.sl

   For 64 bit Oracle8i
   % cd $ORACLE_HOME/rdbms/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/rdbms/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
.

#################################################

-----Original Message-----
From: Tripathi, Ashish [SMTP:ATripathi@us.infogrames.com]
Sent: Wednesday, July 03, 2002 3:57 PM
To: hpux-admin@dutchworks.nl
Subject: [HPADM] RMAN and Omniback 3.5

Hi Admins,
      We are planning to use RMAN with Omniback 3.5 to backup Oracle
Database(8.1.7).Can someone point me to some web sites which have
documentation on this or if someone can send me a doc on this.
TIA and I'll summarize.
Ashish Tripathi

-- 
             ---> Please post QUESTIONS and SUMMARIES only!! <--- 
        To subscribe/unsubscribe to this list, contact
majordomo@dutchworks.nl 
       Name: hpux-admin@dutchworks.nl     Owner:
owner-hpux-admin@dutchworks.nl 
  
 Archives:  ftp.dutchworks.nl:/pub/digests/hpux-admin       (FTP, browse
only) 
            http://www.dutchworks.nl/htbin/hpsysadmin   (Web, browse &
search)
-----Original Message-----
From: Tripathi, Ashish [mailto:ATripathi@us.infogrames.com] 
Sent: Wednesday, July 03, 2002 9:57 AM
To: hpux-admin@dutchworks.nl
Subject: [HPADM] RMAN and Omniback 3.5
Hi Admins,
      We are planning to use RMAN with Omniback 3.5 to backup Oracle
Database(8.1.7).Can someone point me to some web sites which have
documentation on this or if someone can send me a doc on this.
TIA and I'll summarize.
Ashish Tripathi
--
             ---> Please post QUESTIONS and SUMMARIES only!! <---
        To subscribe/unsubscribe to this list, contact
majordomo@dutchworks.nl
       Name: hpux-admin@dutchworks.nl     Owner:
owner-hpux-admin@dutchworks.nl
 
 Archives:  ftp.dutchworks.nl:/pub/digests/hpux-admin       (FTP, browse
only)
            http://www.dutchworks.nl/htbin/hpsysadmin   (Web, browse &
search)
--
             ---> Please post QUESTIONS and SUMMARIES only!! <---
        To subscribe/unsubscribe to this list, contact majordomo@dutchworks.nl
       Name: hpux-admin@dutchworks.nl     Owner: owner-hpux-admin@dutchworks.nl
 
 Archives:  ftp.dutchworks.nl:/pub/digests/hpux-admin       (FTP, browse only)
            http://www.dutchworks.nl/htbin/hpsysadmin   (Web, browse & search)


This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 11:02:15 EDT