Performance Tuning Siebel Software on the Sun Platform

On the <strong>Siebel</strong> applications server, go into the Oracle client installation and delete (or
rename) the tnsnames.ora and sqlnet.ora files. You no longer need these as
Oracle now connects to the database by resolving the name from the /etc/hosts file.
As root edit the file /etc/hosts on the client machine (that is, the <strong>Siebel</strong> applications
server in this case) and add an entry like the following:
oramst.dbserver
The name oramst.dbserver should be whatever you have provided as the
GLOBAL_DBNAME in the listener .ora file. This becomes the connect string to connect to
this database from any client.
7.6.11 High I/O with Oracle Shadow Processes Connected to <strong>Siebel</strong>
The disk on which Oracle binaries were installed was close to 100% occupied during the
peak load of 1000 concurrent users. This problem was diagnosed to be the well-known
oraus.msb problem. On Oracle clients that make use of OCI (Oracle Call Interface), the
OCI driver makes thousands of calls to translate messages from the oraus.msb file.
This problem has been documented by Oracle under bug ID 2142623.
The Sun workaround for this problem is to cache the oraus.msb file in memory and
translate the file access and system calls to user calls and memory operations. The
caching solution is dynamic, and code changes are not needed. With <strong>Siebel</strong> this
workaround helped in reducing the calls. The 100% occupied I/O went away and a 4%
reduction in CPU was observed. also, the response times for transactions got a 11%
boost.
This problem is supposed to have been fixed in Oracle 9.2.0.4. Details on how to
implement the Sun workaround by LD_PRELOAD of an interpose library are available at
http://developers.sun.com/solaris/articles/oci_cache.html.
7.7 <strong>Siebel</strong> Database Connection Pooling
The database connection pooling feature built into the <strong>Siebel</strong> server software provides
better performance. A users:database connection ratio of 20:1 has been proven to
provide good results with <strong>Siebel</strong>7.5/Oracle9202. This reduced about 3% CPU at the
<strong>Siebel</strong> server, as fewer connections were made from <strong>Siebel</strong> server to database during a
2000 user Call Center test. <strong>Siebel</strong> memory/user was 33% lower and Oracle memory/user
was 79% lower, because 20 <strong>Siebel</strong> users share the same Oracle connection.
<strong>Siebel</strong> anonymous users do not use connection pooling. If the anonuser count is set
too high (that is, higher than the recommended 10 to 20%) you would end up wasting the
tasks, as MaxTasks is a number inclusive of real users. Also the anon sessions do not
<strong>Performance</strong> <strong>Tuning</strong> <strong>Siebel</strong> <strong>Software</strong> on the Sun Platform Page 54