Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

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

RE: tuning : file number translation table

From: Gogala, Mladen <MGogala_at_oxhp.com>
Date: Fri, 18 Jul 2003 10:45:46 -0400
Message-Id: <25956.338454@fatcity.com>


This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible.

------_=_NextPart_000_01C34D3B.45B5AFD0
Content-Type: multipart/alternative;

        boundary="----_=_NextPart_001_01C34D3B.45B5AFD0"

------_=_NextPart_001_01C34D3B.45B5AFD0
Content-Type: text/plain;

        charset="iso-8859-1"

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:mgogala_at_oxhp.com

-----Original Message-----
From: carol.legros_at_accenture.com [mailto:carol.legros_at_accenture.com] 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     

------_=_NextPart_001_01C34D3B.45B5AFD0
Content-Type: text/html;

        charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.00.3502.4856" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=968134414-18072003>Carol,
you have problems with the operating system, not oracle. Increase the parameter NINODE</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=968134414-18072003>for
your underlying OS. Inodes are being written to and from inode cache, thus causing waits.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<P><FONT face=Arial size=2>Mladen Gogala</FONT> <BR><FONT face=Arial
size=2>Oracle DBA</FONT> <BR><FONT face=Arial size=2>Phone:(203) 459-6855</FONT>
<BR><FONT face=Arial size=2>Email:mgogala_at_oxhp.com</FONT> </P>
<BLOCKQUOTE>

  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma   size=2>-----Original Message-----<BR><B>From:</B> carol.legros_at_accenture.com   [mailto:carol.legros_at_accenture.com]<BR><B>Sent:</B> Friday, July 18, 2003   11:09 AM<BR><B>To:</B> Multiple recipients of list ORACLE-L<BR><B>Subject:</B>   tuning : file number translation table<BR><BR></DIV></FONT><BR><FONT   face=sans-serif size=2>I'm hoping someone out there has experienced this   problem... I can't seem to find many posts</FONT> <BR><FONT face=sans-serif

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

------_=_NextPart_001_01C34D3B.45B5AFD0--

------_=_NextPart_000_01C34D3B.45B5AFD0
Content-Type: image/gif;

        name="ATT29161.gif"
Content-Disposition: attachment;

        filename="ATT29161.gif" Received on Fri Jul 18 2003 - 09:45:46 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US