Re: SAME methodology questions...

"Ana C. Dent" <anacedent_at_hotmail.com> wrote in message news:<7DuFa.78288$MJ5.2772_at_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.

I'm sure that is the case for most online type systems. Whether that is actually interfering with performance? Depends. The SAME people are arguing the net difference is small (IOW, the price is lower than you imply). I agree with them for many sites, and I agree with you for any specific testing done. Why is that not a conflict? Because SAME is an oversimplified methodology which often happens to work. Especially consider the case where you are bringing in way too much indexing data, which just happens to be an index you are are following. Don't underestimate the win of a predictive cache load, if just a few of those 1MB unrequests avoid a disk head movement, you gain an immense amount of performance. And sometimes those will coincide with a bright controller ordering the reading and writing to minimize head movement. And of course, not every performance bottleneck even on online systems is single gets, you have to get the information out and that means full table scans of one sort or another - do you change hardware tuning for those times (if you do all reporting off a clone, you are beyond SAME anyways)?

>
> >
> >
> >>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.

Exactly.

>
> >
> > jg
> > --
> > @home.com is bogus.
> > Think LUN=disk for the purposes of OFA.

jg

--
@home.com is bogus.
http://www.signonsandiego.com/news/uniontrib/tue/currents/news_1c10metside.html