[oracle-l] Re: Help With Veritas and my search for the Holy "I/O" Grail (testing with the tool from www.iozone.org)

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_at_eFunds.Com> To: <oracle-l_at_freelists.org> Cc: <jonathan_at_jlcomp.demon.co.uk> 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_at_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 Received on Mon Jan 26 2004 - 01:15:11 CST