Kind of interesting non-bug:

http://metalink.oracle.com/metalink/...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.")

Moral: Don't expect miracles from SAME. Don't even expect Oracle
code to work with it rationally.

jg
--
@home.com is bogus.
"Everyone wants to be Cary Grant. Even I want to be Cary Grant." -
Archibald Leach, AKA Cary Grant.

Joel Garry wrote:
>
> Kind of interesting non-bug:
>
> http://metalink.oracle.com/metalink/...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.")
>
> Moral: Don't expect miracles from SAME. Don't even expect Oracle
> code to work with it rationally.
>
> jg
> --
> @home.com is bogus.
> "Everyone wants to be Cary Grant. Even I want to be Cary Grant." -
> Archibald Leach, AKA Cary Grant.

Direct IO I think resolves the inode issue - maybe this is just Solaris
though. Maybe a repeat of the test with the file system mounted for
direct IO might provide proof either way.

Cheers
Connor
--
Connor McDonald
Co-author: "Mastering Oracle PL/SQL - Practical Solutions"
ISBN: 1590592174

web: http://www.oracledba.co.uk
web: http://www.oaktable.net
email: connor_mcdonald@yahoo.com

Coming Soon! "Oracle Insight - Tales of the OakTable"

"GIVE a man a fish and he will eat for a day. But TEACH him how to fish,
and...he will sit in a boat and drink beer all day"

------------------------------------------------------------

joel-garry@home.com (Joel Garry) wrote:

>Kind of interesting non-bug:
>
>http://metalink.oracle.com/metalink/...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


----------
Inode locks

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