A quick look at the Oracle Install Guide mentions NINODE for an HP
environment.
But I don't see what the comparable parameter would be in Solaris. (Or,
is it the same,
but the install guide just doesn't mention it.)

I'm hoping someone out there has experienced this problem... I can't seem
to find many posts
on MetaLink that discuss this.

My environment :

I am running a 500 Gig OLTP database in a Solaris environment. I have
some 0+1 disk
available, but mostly RAID5 (array) for the datafiles.

This is not in production yet, but we're doing some load testing, and so
far, I've had the
typical contentions with the "undo header" and "undo block" contention,
"segment header"
and so on. I've reduced these issues significantly, but now I think I may
have a problem
with "hot spots" and I/O.

The one latch that comes up with a high % (contention) is "file number
translation table".
Its at %15. All other latch miss percentages are below 0. Seems like the
access to the
files is being pounded.

Anyone had contention with this latch before ?

Another thing that make me feel this is possibly I/O related is that the
tablespace and datafiles show an uneven
amount of activity across all.... possibly because this app naturally does
tons of INSERTS and few UPDATES.
Maybe I need to use partitioning to even out the activity.

The top wait stats are related to dispatchers and MTS. I have a lot of
dispatchers and shared servers
(all are busy) but I suspect these wait stats are high because file access
may now be the issue.
Should I consider fewer dispatchers and shared servers ? This may relieve
the
"file number translation table" situation, but then I'm back to where I
started before (lower number of
concurrent sessions with a reasonable response time).

I am running a 500 Gig OLTP database in a Solaris environment. &nbsp;I have some 0+1 disk</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
available, but mostly RAID5 (array) for the datafiles.</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
This is not in production yet, but we're doing some load testing, and so far, I've had the <br>
typical contentions with the &quot;undo header&quot; and &quot;undo block&quot; contention, &quot;segment header&quot;</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
and so on. &nbsp;I've reduced these issues significantly, but now I think I may have a problem</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
with &quot;hot spots&quot; and I/O. &nbsp;</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
The one latch that comes up with a high % (contention) is &quot;file number translation table&quot;.</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
Its at %15. &nbsp;All other latch miss percentages are below 0. &nbsp;Seems like the access to the</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
files is being pounded. </font><font size=3 face="Times New Roman"><br>
</font><font size=2 face="sans-serif"><br>
Anyone had contention with this latch before ? &nbsp;</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
Another thing that make me feel this is possibly I/O related is that the tablespace and datafiles show an uneven <br>
amount of activity across all.... possibly because this app naturally does tons of INSERTS and few &nbsp;UPDATES.</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
Maybe I need to use partitioning to even out the activity.</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
The top wait stats are related to dispatchers and MTS. &nbsp;I have a lot of dispatchers and shared servers</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
(all are busy) but I suspect these wait stats are high because file access may &nbsp;now be the issue. &nbsp;</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
Should I consider fewer dispatchers and shared servers ? &nbsp;This may relieve the <br>
&quot;file number translation table&quot; situation, but then I'm back to where I started before (lower number of <br>
concurrent sessions with a reasonable response time).</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
Any advice or comments would be appreciated. &nbsp;Thanks in advance,</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
Carol</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
&nbsp; &nbsp;<br>
</font><font size=3 face="Times New Roman"><br></font><br><br>