Your situation looks like the increase in the number of CPUs has exacerbated the
latch contention. I have two experiments for you to try - both will probably
help, although you should really fix the problem that is causing the contention.
Firstly, try setting cpu_count = 1. Secondly, get the system admin to disable
(cfgadm -c unconfigure) some of the CPUs.


-----Original Message-----
Sent: Thursday, 31 August 2000 11:20


The main purpose of me contacting you is to run something by you which has
been frustrating me for a few days.  I know your time is precious, so if the
problem is not immediately obvious, please do not spend any time on it.  (I
am trying to avoid a human tennis match between sun and oracle, with me as
the ball).

The scenario is that we have a database have been moved wholesale from one
machine to another.  No changes have been made to the instance
configuration, and the disk layout was kept much the same.  The new machine
has a higher spec in every area (see below).  We expected to see a marked
improvement in performance all round.  We have not, infact the performance
from an application point of view has DECREASED.

What we have seen is a marked decrease in IOWait and system time since we
moved to new machine..this is consistent with expectations as the IO
subsystem is much faster with the cache. Iostat is showing low numbers for
service time and percent busy.

There is very little system cpu usage, oracle is using almost all of it.
What we have noticed is that there are 'latch free' waits for the
librarycache.  I am unsure whether this was the case previously, but either
way, if all the old problems were moved on to a higher spec machine, surely
the performance would improve even with those problems still there.

Whats going on, have I missed an obvious machine/memory config parameter
from the operating system side?  Any help/guidance would be much
appreciated, but as I say, if it is not immediately obvious, I will grind
down the SUN/ORACLE track and let you know the resolution (if any?!?!?)


Oracle
7.3.4.5.0

Old Machine, E450 with :
1Gb Ram
4 * 400MHz processors
All disks mirrored using SDS.

New Machine, E4500 with :
8Gb Ram
8 * 400MHz processors
All Oracle filesystems on 2* A1000's with 80Mb of cache in each.
Oracle data is on its own disks.
Redo logs are on their own seperate disks.


Shared memory and semaphore settings are as follows for new and old :

set shmsys:shminfo_shmmax=1073741824
set shmsys:shminfo_shmmin=100
set shmsys:shminfo_shmmni=200
set semsys:seminfo_semmap=40
set semsys:seminfo_semmns=600
set semsys:seminfo_semmni=135
set semsys:seminfo_semume=60
set semsys:seminfo_semmsl=2048