Carol, you have problems with the operating system, not oracle. Increase the parameter NINODE
for your underlying OS. Inodes are being written to and from inode cache, thus causing waits.
 

Mladen Gogala
Oracle DBA
Phone:(203) 459-6855
Email:[EMAIL PROTECTED]

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, July 18, 2003 11:09 AM
To: Multiple recipients of list ORACLE-L
Subject: tuning : file number translation table


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).

Any advice or comments would be appreciated.  Thanks in advance,
Carol
   

<<attachment: ATT29161.gif>>

Reply via email to