Optimize Siebel Repository Import in Oracle Database

It was noticed during siebel repository import in an Oracle Database 11.2.0.3, most of database wait time was log file switch.

srvrupgwiz /m master_imprep.ucf

It took 163 minutes for 3,639,432 rows (98% waits log file switch).

2012-11-18 09:53:02     TOTAL TABLES: 328
2012-11-18 09:53:02     TOTAL ROWS  : 3639432
2012-11-18 09:53:02     Cleaning up, disconnecting from the database.
2012-11-18 09:53:02     Elapsed time: 163 min 28 sec.

The database session did ~730.000 commits (meaning 1 commit every 5 rows).

repimexp /a I /G ENU /u sadmin /p ***** /c siebelpro_DSN /d siebel /r "Siebel Repository" /Z 5000 /h 5000 /f siebel_rep.data /l imprep_prim.log

If the /Z and /h option are used (with 5000 as argument) the time is less than 10 minutes for the same  repository.

2013-01-27 11:34:35     Verified successfully.
2013-01-27 11:34:35     TOTAL TABLES: 328
2013-01-27 11:34:35     TOTAL ROWS  : 3928282
2013-01-27 11:34:35     Cleaning up, disconnecting from the database.
2013-01-27 11:34:35     Elapsed time: 9 min 46 sec.

There is no way (until Dec 2012) to put /Z or /h in ucm file, so the only solution is to use the command line interface (Oracle support replied that is a product defect).

Reference from Oracle documentation:
Importing a Siebel Repository

NOTE:  When you import data into the Siebel Repository tables, a commit is performed once for each table into which repository data is imported. Alternatively, the commit frequency can be set to a specified number of rows by including the command-line option /h num_rows_per_commit when the repimexp.exe utility is invoked.
 /H [number]        (Optional) Number of rows per commit
 /Z [number]        (Optional) Array Insert Size (Default: 5)

Custom scripts to monitor Siebel using OMS user defined metrics

In this post, I describe how to create user defined metrics in hosts.
The following scripts will raise alerts, whenever something's wrong.

IBM HTTP Server:

#!/bin/sh
PS=`ps -ef|grep "HTTPServer -k start"|grep -v grep|wc -l`

echo em_result=$PS
if test $PS -lt 4
then
echo em_message='Apache is down. Processes='$PS
else
echo em_message='Apache is up. Processes='$PS
fi

Oracle BI Publisher:

#!/bin/sh
PS=`ps -ef|grep oc4j_bi|grep java|grep -v grep|wc -l`

echo em_result=$PS
if test $PS -ne 1
then
echo em_message='BI Publisher is down. Processes='$PS
else
echo em_message='BI Publisher is up. Processes='$PS
fi

Gateway Server:

#!/bin/sh
PS=`ps -ef|grep gtwyns|grep -v grep|wc -l`

echo em_result=$PS
if test $PS -ne 1
then
echo em_message='Gateway is down. Processes='$PS
else
echo em_message='Gateway is up. Processes='$PS
fi

Siebel Server:
server.cfg:

spool server.lst
list server show SBLSRVR_NAME,HOST_NAME,SBLSRVR_STATE,START_TIME,END_TIME
exit

Main script [Insert your env. variables' values]:

export SIEBEL_HOME=

export SIEBGATE=
export SIEBENT=
export SADMINPWD=
export WORKDIR=
export HOST_NAME=

. $SIEBEL_HOME/siebenv.sh

cd $WORKDIR

cat /dev/null>server.lst

srvrmgr /g $SIEBGATE /e $SIEBENT /u sadmin /p $SADMINPWD /s $HOST_NAME /i server.cfg 1>/dev/null

GREP=`grep Running server.lst |wc -l`
echo em_result=$GREP

if test $GREP -lt 1
    then
                echo em_message='Siebel Server is down.'
        else
                echo em_message='Siebel Server is up.'
fi

Siebel Components:

comp.cfg:

spool comp.lst
list comp show SV_NAME,CC_ALIAS,CC_NAME,CP_DISP_RUN_STATE,CP_START_TIME,CP_END_TIME
exit

Main script [Insert your env. variables' values]:

export SIEBEL_HOME=
export SIEBGATE=
export SIEBENT=
export SADMINPWD=
export WORKDIR=
export HOST_NAME=

. $SIEBEL_HOME/siebenv.sh

cd $WORKDIR

cat /dev/null>comp.lst

srvrmgr /g $SIEBGATE /e $SIEBENT /u sadmin /p $SADMINPWD /s $HOST_NAME /i comp.cfg 1>/dev/null

GREP=`egrep '(Unavailable|Shutdown)' comp.lst |wc -l`
echo em_result=$GREP

if test $GREP -gt 0
    then
                echo em_message=$GREP' Components down.'
        else
                echo em_message='Components are OK.'
fi

You may use OMS 11g preinstalled Siebel plugin, instead, although I haven't seen anything about components' status. You only get informed, if gateway or Siebel servers are up or down.
If you choose to use this plugin, make sure agent's OS user has the same primary group as Siebel's OS user. Oracle had to open Bug 13849748 for me, until I discovered that this was needed, since it is not mentioned in any documentation.
Also agent messes with /tmp/regss* files, taking their ownership and crashing, sometimes, the gateway server. Remove "${MWHOME}/bin/regautobackup -off" from your siebenv.sh files to correct this.

Grid 11g:"Siebel Discovery Agent is not installed at one or more hosts" trying to discover Siebel topology

We installed agents in all our 4 Siebel servers, let's say named sappl1, sappl2, sappl3 and sappl4.
Under Hosts Tab we see they are up.
When we tried to discover Siebel topology, we got errors:

Discovery Summary
Add Enterprise operation is not successful.  Resolve the error messages and then try again

Error Messages
     Siebel Discovery Agent is not installed at one or more hosts
     Discovery From Gateway Server Failed

Trace Messages
     Discovered the Siebel topology from Gateway Server

In our OMS server, in ../gc_inst/em/EMGC_OMS1/sysman/log/emoms.trc, there were these entries:

2012-02-23 09:12:26,891 [Thread-114] ERROR enterprise.TDProcConfig log.625 - doConfiguration: There are some issues with respect to Agents.
2012-02-23 09:12:26,891 [Thread-114] ERROR enterprise.TDProcConfig log.625 - doConfiguration: Agent erros out for host  sapp3 with message : .Siebel Discovery Agent is not installed at one or more hosts
2012-02-23 09:12:26,891 [Thread-114] ERROR enterprise.TDProcConfig log.625 - doConfiguration: Agent erros out for host  sapp2 with message : .Siebel Discovery Agent is not installed at one or more hosts
2012-02-23 09:12:26,891 [Thread-114] ERROR enterprise.TDProcConfig log.625 - doConfiguration: Agent erros out for host  sapp4 with message : .Siebel Discovery Agent is not installed at one or more hosts

Names sapp2, sapp3, sapp4 were not correct.
OMS had discovered the servers as "sapplX".
In Siebel servers' /etc/hosts file the entries were:

10.101.1.17    sapp1        sappl1
10.101.1.18    sapp2        sappl2
10.101.1.19    sapp3        sappl3
10.101.1.20    sapp4        sappl4

We changed the order:

10.101.1.17    sappl1        sblapp1
10.101.1.18    sappl2        sblapp2
10.101.1.19    sappl3        sblapp3
10.101.1.20    sappl4        sblapp4

Discovery will succeed this time.