jmsalvo wrote:

> Got the response from Sun Support here in Australia....
>
> The statement that I got from them is that, when using SDS mirroring,
> don't use raw devices but use instead ufs with concurrent direct I/O
> ... which will avoid the situation altogether.

Not only does that sound completely specious but it smells
bogus as well. Did they explain what they meant by "concurrent
direct I/O"?

> However, he did mention that to take great advantage of concurrent
> direct I/O, the database should use kaio instead of aio for
> performance.

The support contact you spoke to must be a newbie because he/she
doesn't have much of a clue. The kaio stuff only works with raw
devices.

> So that's what I have to do then ... forget about raw devices and use
> concurrent direct I/O on UFS.

I would ask for a second opinion. Like I said, it works fine
for me.

-am © 2003

Anthony Mandic wrote:
> jmsalvo wrote:
>
>
>>Got the response from Sun Support here in Australia....
>>
>>The statement that I got from them is that, when using SDS mirroring,
>>don't use raw devices but use instead ufs with concurrent direct I/O
>>... which will avoid the situation altogether.
>
>
> Not only does that sound completely specious but it smells
> bogus as well. Did they explain what they meant by "concurrent
> direct I/O"?

concurrent direct I/O has been part of Solaris 8 since Update 3 ( or was
that Maintenance Update 3 ). It is part of Solaris 9 as a standard.

I first read about it in the link that I mentioned in an earlier post in
this thread, but here is the link again:


http://de.sun.com/Partner/Softwarepa...on_Solaris.pdf

Yeah ... I know it is about Oracle, but the part there about Performance
, raw devices, direct I/O, asynchronous I/O, and concurrent direct I/O
would be true for any database.


http://www.google.com.au/search?q=ca...hl=en&ie=UTF-8
( The actual link in soldc.sun.com is no longer valid ... so you have to
use the google cache )

Here is also a link from Sun:

http://docs.sun.com/db/doc/806-7502/6jgce01t6?a=view


>
>
>>However, he did mention that to take great advantage of concurrent
>>direct I/O, the database should use kaio instead of aio for
>>performance.
>
>
> The support contact you spoke to must be a newbie because he/she
> doesn't have much of a clue. The kaio stuff only works with raw
> devices.
>
>
>>So that's what I have to do then ... forget about raw devices and use
>>concurrent direct I/O on UFS.
>
>
> I would ask for a second opinion. Like I said, it works fine
> for me.
>
> -am © 2003

The problem is ... it would be hard to detect this kind of problem. The
only manifestation that you could probably see of it is when you try to
perform the same read and get different results, even though they should
have the same results.

noone wrote:

> concurrent direct I/O has been part of Solaris 8 since Update 3 ( or was
> that Maintenance Update 3 ). It is part of Solaris 9 as a standard.

OK (I had to look it up. Hadn't heard of it before).

>http://www.google.com.au/search?q=ca...hl=en&ie=UTF-8
> ( The actual link in soldc.sun.com is no longer valid ... so you have to
> use the google cache )
>
> Here is also a link from Sun:
>
> http://docs.sun.com/db/doc/806-7502/6jgce01t6?a=view

Notice that the mount option is still forcedirectio. So its
rolled in (like with kaio and aio). Also note that that mount
option is affected by the write on write problem.

One thing to note, however, is that the Google link talks about
concurrent readers. Now, this part doesn't apply to Sybase ASE
since any data reading is read into the data cache once and ASE
connections read from there. Since ASE works from the data cache,
the I/O model is single reader/single writer for specific data
pages (it would make no sense to have multiple readers and writers
for a specific page on the I/O side of things).

> The problem is ... it would be hard to detect this kind of problem. The
> only manifestation that you could probably see of it is when you try to
> perform the same read and get different results, even though they should
> have the same results.

You could set up a test with a small database on a mirrored device.
Drop it after a lot of random writes. Drop the ASE device. Break
the SDS mirrors and read off the data with dd from each side of the
mirror and compare.

However, I'm still not convinced that this is an issue with ASE.
I've never seen any other mention of this before (and you would
think by now you would have). The only other recourse is to try
with Sybase Tech Support and ask them to escalate up to one of the
engineers at their Dublin HQ (or wherever they are). Those guys
will know. Come to think of it, if it was a problem it would
also be noted in the platform release notes.

-am © 2003

Anthony Mandic wrote:
> noone wrote:
>
>
>>concurrent direct I/O has been part of Solaris 8 since Update 3 ( or was
>>that Maintenance Update 3 ). It is part of Solaris 9 as a standard.
>
>
> OK (I had to look it up. Hadn't heard of it before).

Me too ... until just a few days ago.

>
>
>>http://www.google.com.au/search?q=ca...hl=en&ie=UTF-8
>>( The actual link in soldc.sun.com is no longer valid ... so you have to
>>use the google cache )
>>
>>Here is also a link from Sun:
>>
>>http://docs.sun.com/db/doc/806-7502/6jgce01t6?a=view
>
>
> Notice that the mount option is still forcedirectio. So its
> rolled in (like with kaio and aio).

There is no additional mount option to enable concurrent direct I/O.
With Solaris8 Update 3 and Solaris 9, the only thing you need to enable
concurrent direct I/O is to simply mount with the "forcedirectio" option.


Also note that that mount
> option is affected by the write on write problem.


This is where Sun support said that concurrent direct I/O does not ( but
traditional direct I/O does ) have the problem.

I did mention to support that the man pages for metainit says that
direct I/O has the same problem.

Let's see. Why not, you raise this same issue, file an inquiry through
your Sun support contract. Ask them if concurrent direct I/O avoids WOW
problem with SDS mirroring, but traditional direct I/O does NOT avoid
WOW problem with SDS mirroring ... and how / why ?


>
> One thing to note, however, is that the Google link talks about
> concurrent readers.

It mentioned both concurrent readers and writers.

Now, this part doesn't apply to Sybase ASE
> since any data reading is read into the data cache once and ASE
> connections read from there. Since ASE works from the data cache,
> the I/O model is single reader/single writer for specific data
> pages (it would make no sense to have multiple readers and writers
> for a specific page on the I/O side of things)
>
>
>>The problem is ... it would be hard to detect this kind of problem. The
>>only manifestation that you could probably see of it is when you try to
>>perform the same read and get different results, even though they should
>>have the same results.
>
>
> You could set up a test with a small database on a mirrored device.
> Drop it after a lot of random writes. Drop the ASE device. Break
> the SDS mirrors and read off the data with dd from each side of the
> mirror and compare.
>
> However, I'm still not convinced that this is an issue with ASE.
> I've never seen any other mention of this before (and you would
> think by now you would have). The only other recourse is to try
> with Sybase Tech Support and ask them to escalate up to one of the
> engineers at their Dublin HQ (or wherever they are).

I did ... and all I got was the usual "it's just another device as far
as ASE is concerned" and that "they do not make any specific
certifications for or against SDS".

Those guys
> will know. Come to think of it, if it was a problem it would
> also be noted in the platform release notes.
>
> -am © 2003

jmsalvo wrote:
> Anthony Mandic wrote:
>
>
> Let's see. Why not, you raise this same issue, file an inquiry through
> your Sun support contract. Ask them if concurrent direct I/O avoids WOW
> problem with SDS mirroring, but traditional direct I/O does NOT avoid
> WOW problem with SDS mirroring ... and how / why ?
>
>

If you get a different answer than that one I got ... give me your case
#, and I will give you my cae # so that they can get their answer straight.

jmsalvo wrote:
> Anthony Mandic wrote:
>
> Also note that that mount
>
>> option is affected by the write on write problem.
>
>
>
> This is where Sun support said that concurrent direct I/O does not ( but
> traditional direct I/O does ) have the problem.
>
> I did mention to support that the man pages for metainit says that
> direct I/O has the same problem.
>

Opened my work e-mail ... this is what Sun support said:

---------------
Using concurrent direct IO is the viable option here as the WOW problem
can only be encounterd on raw devices, when going through UFS (with
directio) the UFS buffer cache is bypassed for speed however the Solaris
page cache is not bypassed, retaining protection against WOW.

This is one of the reasons UFS with forcedirectio is popular on
databases using Disksuite or VxVM to mirror the data devices, instead of
using raw devices.
---------------

jmsalvo wrote:

> If you get a different answer than that one I got ... give me your case
> #, and I will give you my cae # so that they can get their answer straight.

I don't have any support contracts in my own right (I use my
clients' ones with their permission). So I've gone one better
and emailed someone at Sybase who should be able to sort it
out directly from the horse's mouth. I'll let you know when I
hear back.

-am © 2003

> jmsalvo wrote:
>
> > If you get a different answer than that one I got ... give me your case
> > #, and I will give you my cae # so that they can get their answer straight.

Here's the reply direct from the horse's mouth -

>We don't have this problem in ASE because we don't change
>the buffer while it is in writing. All readers are blocked
>until the WRITING bit is turned off after we get the successful
>completion of the I/O on that buffer.

So that resolves that issue. ASE doesn't have a problem with SDS's
wow problem when using raw devices and direct i/o (unlike some
other database product which shall not be named here but was
implicated at eBay).

-am © 2003

Anthony Mandic wrote:
>>jmsalvo wrote:
>>
>>
>>>If you get a different answer than that one I got ... give me your case
>>>#, and I will give you my cae # so that they can get their answer straight.
>
>
> Here's the reply direct from the horse's mouth -
>
>
>>We don't have this problem in ASE because we don't change
>>the buffer while it is in writing. All readers are blocked
>>until the WRITING bit is turned off after we get the successful
>>completion of the I/O on that buffer.
>
>
> So that resolves that issue. ASE doesn't have a problem with SDS's
> wow problem when using raw devices and direct i/o (unlike some
> other database product which shall not be named here but was
> implicated at eBay).
>
> -am © 2003

Thanks for that ... Sybase should make this public ( e.g. put it in
their Release Notes for Solaris ), as I am sure there are others who
have this same question.

John Salvo wrote:

> Thanks for that ... Sybase should make this public ( e.g. put it in
> their Release Notes for Solaris ), as I am sure there are others who
> have this same question.

Strangely enough, you were the first to raise it.

-am © 2003