Re: SQL Server for Oracle DBAs
From: DA Morgan <damorgan_at_psoug.org>
Date: Thu, 29 May 2008 09:55:33 -0700
Message-ID: <1212080145.352375@bubbleator.drizzle.com>
>
> I would guess because they didn't understand how to check if the
> bottleneck is controller or disk spindle contention, and wound up
> spreading myths beyond a configuration that happened to work for a
> specific contrived workload.
>
> It could make sense to do similar things in oracle, for example, if
> you're stuck with RAID5 and discover most of the random I/O is to undo
> and sequential writes to redo and archiving, and you can convince
> damagement to at least not stick you with RAID5 for the undo and
> archiving. This is kind of a roundabout demo that SAME is correct, as
> the essential point of SAME is to reduce administrative costs because
> it is difficult to really prove more complex administration will give
> better performance in general - but additional artificial constraints
> are added to such proof by way of the management decision to follow
> the salespersons advice of how great RAID5 is.
>
> Since the main point of SAME is that disks are cheap and
> administration is expensive, if you a priori don't accept that (as
> when coming up with a storage budget and dealing with the non-linear
> costs of going beyond a fully populated array, with a fixed staff),
> you won't believe SAME. There may also be the point that
> administrative tools have gotten cheaper since SAME was written,
> making it possible to beat SAME. I don't believe that, since the
> hardware sales folks tend not to understand that we db types need more
> spindles and controller bandwidth, not denser disks.
>
> It also helps to keep in mind that SAME was written when a lot of
> places still had a few internal disks and a couple of external disks
> and were considering going to SANs. I have the idea the vast majority
> of sql server installations have a C and D drive, and some number have
> a SATA array, and the person you are responding to probably ignores at
> least the former, and perhaps the latter. But I really wouldn't know.
>
> jg
Date: Thu, 29 May 2008 09:55:33 -0700
Message-ID: <1212080145.352375@bubbleator.drizzle.com>
joel garry wrote:
> On May 28, 10:14 pm, Mark Townsend <markbtowns..._at_sbcglobal.net>
> wrote:
>> > in SQL Server we don't do it that way >> >>> - we >>> put the logs on their own mirrored pair; we put the data on it's own >>> RAID 10 >>> array etc... >> Out of curiosity - why ?
>
> I would guess because they didn't understand how to check if the
> bottleneck is controller or disk spindle contention, and wound up
> spreading myths beyond a configuration that happened to work for a
> specific contrived workload.
>
> It could make sense to do similar things in oracle, for example, if
> you're stuck with RAID5 and discover most of the random I/O is to undo
> and sequential writes to redo and archiving, and you can convince
> damagement to at least not stick you with RAID5 for the undo and
> archiving. This is kind of a roundabout demo that SAME is correct, as
> the essential point of SAME is to reduce administrative costs because
> it is difficult to really prove more complex administration will give
> better performance in general - but additional artificial constraints
> are added to such proof by way of the management decision to follow
> the salespersons advice of how great RAID5 is.
>
> Since the main point of SAME is that disks are cheap and
> administration is expensive, if you a priori don't accept that (as
> when coming up with a storage budget and dealing with the non-linear
> costs of going beyond a fully populated array, with a fixed staff),
> you won't believe SAME. There may also be the point that
> administrative tools have gotten cheaper since SAME was written,
> making it possible to beat SAME. I don't believe that, since the
> hardware sales folks tend not to understand that we db types need more
> spindles and controller bandwidth, not denser disks.
>
> It also helps to keep in mind that SAME was written when a lot of
> places still had a few internal disks and a couple of external disks
> and were considering going to SANs. I have the idea the vast majority
> of sql server installations have a C and D drive, and some number have
> a SATA array, and the person you are responding to probably ignores at
> least the former, and perhaps the latter. But I really wouldn't know.
>
> jg
From my experience you are correct. Much of what we see in SQL Server shops is one large (500GB, 750GB) SATA drive. You won't find the likes of EMC, Hitachi, NetApp, and Pillar putting their efforts into more than a small number of the largest SQL Server shops: There's a reason.
-- Daniel A. Morgan Oracle Ace Director & Instructor University of Washington damorgan_at_x.washington.edu (replace x with u to respond) Puget Sound Oracle Users Group www.psoug.orgReceived on Thu May 29 2008 - 11:55:33 CDT