Re: SAME methodology questions...

From: Ana C. Dent <anacedent_at_hotmail.com>
Date: Tue, 10 Jun 2003 17:22:34 -0700
Message-ID: <7DuFa.78288$MJ5.2772@fed1read03>

Joel Garry wrote:
> "Ana C. Dent" <anacedent_at_hotmail.com> wrote in message news:<xIHEa.65564$MJ5.19024_at_fed1read03>...
>

>>Burton Peltier wrote:
>>
>>>I have no experience, but I am also curious about how others are doing this
>>>after recently reading about this because there are more people (in our
>>>company) recommending SAME.
>>>
>>>Sorry if I am creating a discussion you didn't want, but I would like to
>>>also hear from those who use SAME to explain a couple of things about their
>>>setup.
>>>
>>>SAME is suppose to "keep it simple" . It seems it does IF you configure the
>>>disks correctly, but the 1 thing I would still worry about is not
>>>multiplexing REDO to 2 different sets of disk spindles. Does anyone using
>>>SAME have a good explaination why this is not potentially a problem.
>>>
>>>Also, there are a couple of little details like the 1M stripe size and
>>>"using the outer edges of the disk platter for frequently accessed files" ,
>>>that are not so simple. Our SysAdmin didn't have any idea how to do the
>>>outer edges setup on Sun A1000 arrays. Does SAME require specific/expensive
>>>hardware?
>>>
>>
>>SAME does "keep it simple", but at what price?
>>
>>WRT the 1MB stripe size...
>>I state categorically that I've NEVER seen Oracle
>>ask for or get anything close to 1MB in a single I/O
>>request/operation.

>
>
> I'm not saying SAME is always a good price, but the win (or wash)
> comes from a series of I/O's that happen to already be buffered, one
> way or another. Worrying about single I/O requests misses the point
> of SAME, which is that it is not cost-effective to worry about them.

Or LOSS of bringing back 1MB when only 16K was requested; multiplied by millions of times per day.

The MAJORITY of the I/O requests on my PRODUCTION DB are SINGLE block (16KB) requests! If you wish to pay the price of bringing back almost 1MB of unrequested data, that is your choice; but not one I would choose.

>
>

>>What is the product of the Oracle block size times
>>Oracle multiblock read count?
>>Isn't this value the largest I/O request by Oracle?
>>
>>What problem are you really trying to solve?
>>What are the metrics & their values which will
>>confirm that you've really achieved the desired goal(s)?

>
>
> Those are the correct questions to ask. SAME, of course, says it is
> not cost-effective to worry too much about them. I think that my be
> valid for sites with very similar hardware to that in the paper, and
> there may be many of them. It is not OK for large or serious or
> every-disk-revolution-is-critical shops. I think SAME won't be valid
> over generations (with a generation being less than 2 years), and
> perhaps goes too far in generalizing which requirements it can cover.

I'll conceed that where no I/O bottleneck exists, SAME works (by definition).

When performance really matters, then other solutions are required.

>
> jg
> --
> @home.com is bogus.
> Think LUN=disk for the purposes of OFA.
Received on Tue Jun 10 2003 - 19:22:34 CDT