rlro99@hotmail.com (Ralph) wrote in message news:<e2c49cae.0411300747.50aa4f3f@posting.google. com>...
> Oracle 9.2.0.4 (64-bit)
> Veritas version 1
> Solaris 9
>
>
> We have performed various tests on Oracle db_file_scattered_read
> performance in various combinations of:
>
> VxFS - with and without ODM
> VxVM partition - with and without ODM
> VTOC partition - with and without ODM
>
> and tried various combinations of db_block_size.
>
> Whilst we can get VxFS and any raw partition to perform IOs in
> db_file_multiblock_read_count * db_block_size requests, any use of ODM
> always results in the transfers being of db_block_size. This is
> clearly less effcient since more requests must be issued for this kind
> of read.
>
> This seems at odds with the documentation which claims that odm_io()
> will perform sequential reads/writes, direct read/writes, scattered
> reads, dbwr batch writes etc in the most efficient manner available.
>
> Is there any way that the behaviour of ODM can be influenced such that
> scattered reads are performed in db_file_multiblock_read_count *
> db_block_size requests?
>
>
> Cheers
>
> Ralph

Hi, Ralph,

I don't know the answer and I'm interested. But did you measure the
overall performance of using and not using Veritas ODM when you run a
batch job or a series of short transactions/queries? I'm reading
http://www.oracle.com/technology/dep.../nitin_ODM.pdf. They
seem to be proud of simplifying I/O-related system calls (by saving
the time to look up in the syscall dispatch table I think) and
eliminating filesystem-related overheard (write locks, going through
kernel page cache). In any case, overall performance comparison would
be more appropriate than looking at whether it transfers only one
db_block_size or not.

BTW, did you get that info by using ktrace, setting 10298 event or
other means? Can you post somewhere all your benchmark results?
Thanks.

Yong Huang



Hi,

Sorry about the splitting of the thread...google is behaving
strangely.

A summary of the results are available here

http://www.jorgensen.org.uk/odm.pdf

These were obtained by sar odmstat statspack etc.

We are only interested in the scattered read perfromance, rather than
the overall IO performance.

Cheers

Ralph

rlro99@hotmail.com (Ralph) wrote in message news:<e2c49cae.0412020318.25c0c2d5@posting.google. com>...
> rlro99@hotmail.com (Ralph) wrote in message news:<e2c49cae.0411300747.50aa4f3f@posting.google. com>...
> > Oracle 9.2.0.4 (64-bit)
> > Veritas version 1
> > Solaris 9
> >
> >
> > We have performed various tests on Oracle db_file_scattered_read
> > performance in various combinations of:
> >
> > VxFS - with and without ODM
> > VxVM partition - with and without ODM
> > VTOC partition - with and without ODM
> >
> > and tried various combinations of db_block_size.
> >
> > Whilst we can get VxFS and any raw partition to perform IOs in
> > db_file_multiblock_read_count * db_block_size requests, any use of ODM
> > always results in the transfers being of db_block_size. This is
> > clearly less effcient since more requests must be issued for this kind
> > of read.
> >
> > This seems at odds with the documentation which claims that odm_io()
> > will perform sequential reads/writes, direct read/writes, scattered
> > reads, dbwr batch writes etc in the most efficient manner available.
> >
> > Is there any way that the behaviour of ODM can be influenced such that
> > scattered reads are performed in db_file_multiblock_read_count *
> > db_block_size requests?
> >
> >
> > Cheers
> >
> > Ralph
>
> Hi, Ralph,
>
> I don't know the answer and I'm interested. But did you measure the
> overall performance of using and not using Veritas ODM when you run a
> batch job or a series of short transactions/queries? I'm reading
> http://www.oracle.com/technology/dep.../nitin_ODM.pdf. They
> seem to be proud of simplifying I/O-related system calls (by saving
> the time to look up in the syscall dispatch table I think) and
> eliminating filesystem-related overheard (write locks, going through
> kernel page cache). In any case, overall performance comparison would
> be more appropriate than looking at whether it transfers only one
> db_block_size or not.
>
> BTW, did you get that info by using ktrace, setting 10298 event or
> other means? Can you post somewhere all your benchmark results?
> Thanks.
>
> Yong Huang
>
>
>
> Hi,
>
> Sorry about the splitting of the thread...google is behaving
> strangely.
>
> A summary of the results are available here
>
> http://www.jorgensen.org.uk/odm.pdf
>
> These were obtained by sar odmstat statspack etc.
>
> We are only interested in the scattered read perfromance, rather than
> the overall IO performance.
>
> Cheers
>
> Ralph


No much response so far. Still for anybody else running 9i and ODM who
happen to notice their tablescan performance dropping through the
floor, Oracle got back to us with this....

unpublished bug 3241979

From the bug:
Multiblock reads issued by the cache layer are split into single db
block
reads, apparently by the odm interface.
I have observed this with netapp odm/dafs and veritas odm/qio
implementations.
Result is that we generate much more io operations hence scalability
is at
risk when workload has lots of big ios.

The guy is certainly a master of understatement "scability is at risk"

Fixed in 10g though apparently...

I am beginning to wonder if we are working in a parallel universe. We
discover this issue that anybody implementing ODM and oracle must run
into...and its a biggy. Yet there is nothing anywhere on metalink, the
internet, anywhere.

Maybe we are on our own....

rlro99@hotmail.com (Ralph) wrote in message news:<e2c49cae.0412020318.25c0c2d5@posting.google. com>...
> rlro99@hotmail.com (Ralph) wrote in message news:<e2c49cae.0411300747.50aa4f3f@posting.google. com>...
> > Oracle 9.2.0.4 (64-bit)
> > Veritas version 1
> > Solaris 9
> >
> > We have performed various tests on Oracle db_file_scattered_read
> > performance in various combinations of:
> >
> > VxFS - with and without ODM
> > VxVM partition - with and without ODM
> > VTOC partition - with and without ODM
> >
> > and tried various combinations of db_block_size.
> >
> > Whilst we can get VxFS and any raw partition to perform IOs in
> > db_file_multiblock_read_count * db_block_size requests, any use of ODM
> > always results in the transfers being of db_block_size. This is
> > clearly less effcient since more requests must be issued for this kind
> > of read.
> >
> > This seems at odds with the documentation which claims that odm_io()
> > will perform sequential reads/writes, direct read/writes, scattered
> > reads, dbwr batch writes etc in the most efficient manner available.
> >
> > Is there any way that the behaviour of ODM can be influenced such that
> > scattered reads are performed in db_file_multiblock_read_count *
> > db_block_size requests?
> >
> >
> > Cheers
> >
> > Ralph
>...
>
> A summary of the results are available here
>
> http://www.jorgensen.org.uk/odm.pdf
>
> These were obtained by sar odmstat statspack etc.
>
> We are only interested in the scattered read perfromance, rather than
> the overall IO performance.

Excellent test, Ralph. I suggest you open a Tar with Oracle and a
ticket with Veritas. Their partnership may assign one person from
Veritas and one from Oracle to handle your Tar.

Now I know that your observation of db_block_size used by ODM is
obtained by sar column blks/s divided by r+w/s. (I thought you were
saying using ODM, you don't see db_file_scattered_read events.) For my
curiosity, when you run full table scans in Oracle, does the Oracle
shadow process perform pread (or pread64) or readv? Is it different on
ODM and non-ODM? My guess is no difference; ODM hides the details
below the system call level.

Yong Huang

No, you are not alone. I too had noticed ODM IOs were always for the block
size. As a result read-ahead never seems to kick in and tablescan
performance under ODM is poor. But with the unpublished bug number (ie
acknowledgement of a bug), maybe we can get Oracle to backport the fix.
Thanks
Martin

No, you are not alone. I too had noticed ODM IOs were always for the block
size. As a result read-ahead never seems to kick in and tablescan
performance under ODM is poor. But with the unpublished bug number (ie
acknowledgement of a bug), maybe we can get Oracle to backport the fix.
Thanks
Martin

FYI for anyone interested.
Oracle are backporting this fix to 9i. It will be available as a fix to be
applied on top of 9.2.0.6 (64bit) and they have just agreed to do the same
for 9.2.0.5 (32bit and 64bit).
Martin