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, [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/18/2003 11:44 AM Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> 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 Email:[EMAIL PROTECTED] -----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 fatcity.com 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 [EMAIL PROTECTED] for clarification.
-- Mladen Gogala Oracle DBA -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Mladen Gogala INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
