Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: tuning : file number translation table

Re: tuning : file number translation table

From: Mladen Gogala <>
Date: Fri, 18 Jul 2003 21:48:43 -0400
Message-Id: <>

Don't mention it. Information exchange is the purpose of this list. As for the Solaris, I confess that my databases are on HP-UX. I am sure that Solaris has means of tweaking the file cache parameters but I don't know the specifics. Try oracle support, they may be able to help you.

On 2003.07.18 12:54, wrote:
> Hi Mladen,
> Thanks for the advice. I *never* would've guessed this!
> 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.)
> Thanks again,
> Carol
> "Gogala, Mladen" <>
> Sent by:
> 07/18/2003 11:44 AM
> Please respond to ORACLE-L
> To: Multiple recipients of list ORACLE-L <>
> cc:
> Subject: RE: tuning : file number translation table
> 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
> -----Original Message-----
> Sent: Friday, July 18, 2003 11:09 AM
> To: Multiple recipients of list ORACLE-L
> 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
> The previous attachment was filtered out by the ListGuru mailing
> software at because binary attachments are not appropriate
> for mailing lists. If you want a copy of the attachment which was
> removed, contact the sender directly and ask for it to be sent to
> you by private E-mail.
> This warning is inserted into all messages containing binary
> attachments which have been removed by ListGuru. If you have questions
> about this message, contact for clarification.
Received on Fri Jul 18 2003 - 20:48:43 CDT

Original text of this message