[oracle-l] Re: Help With Veritas and my search for the Holy "I/O" Grail (testing with the tool from www.iozone.org)
- From: "Jonathan Lewis" <jonathan@xxxxxxxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Mon, 26 Jan 2004 07:15:11 -0000
Brian,
My thought was based on a memory of the time when
HP-UX had a problem with Oracle file opens, and the
resolution was an O_SYNC / O_DSYNC patch for the
o/s, which halved the number of writes because one call
syncs only the data in the file, and the other syncs the metadata
as well. (I think the O_DSYNC is data only, O_SYNC is
data and metadata - which includes timestamp information
in the directory - given your truss output). Given that Oracle
is using O_DSYNC, this makes my suggestion pointless.
However, given the wording in the iozone manual, I was
assuming that iozone wasn't using either option on the files
unless directed to do so, and this might give iozone far better
numbers than Oracle could get - which would leave you
trying to resolve a problem with no solution. Don't ask
me why it might make a difference - I'm not an expert
on O/S stuff - but I feel happier that tests are fair when
conditions are identical. Notwithstanding any comments
from Veritas about direct writes to disc, there may be
some difference in the way the calls are prepared and
monitored that makes a difference.
I assume the outputs from truss are the Oracle ones -
have you done the same with iozone to see if it uses
O_SYNC, O_DSYNC, or neither ? Unless iozone
and Oracle are using the same open, there's a gap
in the test which makes the results non-comparable.
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
The educated person is not the person
who can answer the questions, but the
person who can question the answers -- T. Schick Jr
Next public appearances:
Jan 29th 2004 UKOUG Unix SIG - v$ and x$
March 2004 Hotsos Symposium - The Burden of Proof
March 2004 Charlotte NC OUG - CBO Tutorial
April 2004 Iceland
One-day tutorials:
http://www.jlcomp.demon.co.uk/tutorial.html
Three-day seminar:
see http://www.jlcomp.demon.co.uk/seminar.html
____UK___February
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
----- Original Message -----
From: <Brian_P_MacLean@xxxxxxxxxx>
To: <oracle-l@xxxxxxxxxxxxx>
Cc: <jonathan@xxxxxxxxxxxxxxxxxx>
Sent: Monday, January 26, 2004 3:45 AM
Subject: [oracle-l] Re: Help With Veritas and my search for the Holy "I/O"
Grail (testing with the tool from www.iozone.org)
No, I can't say that we did. Our testing has also involved benchmarking
the application, creating of 10gig tablespaces, redo log switches, and 8
gig partitioned table index creation. All tests give the same time or
worse with the aforementioned Veritas options. The Veritas options we
tested with included the recommendations from Steve Adams site, Veritas
documentation, MetaLink forums, and a support ticket with Veritas. One of
the reasons I did not test with the iozone option of "O_SYNC" is that from
what I can tell, that is not what Oracle uses to open tablespace datafiles.
I did a truss of an Oracle shadow process on Solaris and as you can see
below I grep'ed out the open call which shows that Oracle uses the O_DSYNC
option, not the O_SYNC. Regardless, per the Veritas documentation the
options we are using should force all opens to direct/no buffer mode with
direct write through to disk (or the disk array memory on machines that
have it).
I will test the "-o" option tomorrow but I'm not sure what it will get me.
BTW- The reason I use iozone is it's original author is an Oracle employee.
Anyway, thanks for taking the time to reply Jonathan.
24952:d99490@mkeux002> grep -i SYNC trs.out | grep dbf
8621: open("/t04/oracle/oradata/avsqa/TIF_IDX_01.dbf", O_RDWR|O_DSYNC) =
13
8621: open("/t05/oracle/oradata/avsqa/TIF_IDX_02.dbf", O_RDWR|O_DSYNC) =
13
Other related posts:
