Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: A performance reason to split up index data files.
joel-garry_at_home.com (Joel Garry) wrote:
>Kind of interesting non-bug:
>
>http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=BUG&p_id=3484607
>
>I wonder how much of this is due to inode locking (as Tanel, I think,
>described in a thread a while ago - Oracle trying to get segments all
>in the same file hitting itself in the nose), and how much is due to O
>coding that assumes non-interfering physical devices for a parallel
>architecture. I don't think the I/O contention explanation is
>correct, wouldn't the max wait be longer? Inode locking on the other
>hand would result in more retries. (I'm assuming there is a typo in
>the second "Index creation with multiple data files" that should have
>said "single data file.")
Take a look to the ixora web site:
http://www.ixora.com.au/q+a/io.htm
8 October 1999
In your tip, "Why Raw Datafiles", you refer to read/write locks on
datafiles. Are these the same as thing as the INODE lock waits shown
by glance under HP-UX? If so, I have been told that this is only an
HP-UX issue and does not affect Oracle on other platforms such as
Solaris or NT.
No, it is a generic issue. They are called inode locks under Unix, because that is where the lock is applied. Under NT, however, they are implemented as ERESOURCE locks on the File Control Block (FCB). The existence of inode locks under Solaris can easily be verified by checking the header files under /usr/include/sys.
I think they have a script to aliviate this problem.
Bye
Rick Denoire
Received on Sat Jun 19 2004 - 07:50:37 CDT