Re: When many disks are involved in a physical database layout

On Sun, 27 May 2001 22:25:21 +0800, Dino Hsu <dino1_at_ms1.hinet.net> wrote:

>made, and this model would become less useful. Unfortunately, the
>current databases we have all reside on only one disk; control files,
>data files, online redo log files,... everything lives on the same
>disk.

Ay, that's not very good. But of course it depends on what you're doing with those db's.

> It seems (I might be wrong) that on Windows NT there seldom are
>more than 5 disks, and when there are, they could be combined into one
>by RAID. From the practical point of view, I have questions:
>1.Do you usually use 7 or more 'dedicated' disks for an Oracle
>database?

If I have them, yes. But read-on.

>2.Do you prefer the disks to be RAID'ed or not?

If the disks are in an EMC or equivalent, not much choice anyway. If not, then I'd rather have them in RAID0+1. But that's not always possible. Price being one of the determining factors.

>3.Do you DBA's get involvied in the matter of server purchase so that
>hardware spec. are good for the physical layout?

Pah! I wish...

>4.The issue of file sizes is not really taken into account in the
>decisions about which tablespaces should be placed on which disks by
>the author. He focuses on reducing and balancing the contentions most
>of the time. This might imply there are a lot of wasted disk space on
>disks where data are small, and because disks must be dedicated to the
>database (rule 9), they will not be used to accomodate other files.
>

One "principle" thing here: lesser disks of larger capacity are not necessarily the best way to go. It's better to go for smaller disks, more of them. For obvious reasons: you waste less space (it's not always possible to come up with an optimal strategy for file placement) and you end up spreading the load more.

This is however not always possible: modern disk makers seem to match higher disk speeds with higher capacities, which is not the best way to go for databases.

But there are other considerations here. In NT, you are in most cases limited by the number of disk controllers you can have. If we're talking multiple disks, then we're talking most likely SCSI in one of its many flavours.

The problem here is that while SCSI controllers are very fast and can have multiple operations running, they are still essentially an arbitrated bus connection. If you put more than about 6 disks in the same controller (SCSI-III and higher) or three in older SCSI types, you get contention anyway for higher I/O rates.

In the UNIX world, the general rule-of-thumb when using dedicated controllers/disks is to reserve a controller for each 4 disks, max. Most large UNIX boxes are designed to connect well in excess of 16 controllers.

In the NT arena, you'll find that most boxes won't be able to be configured with more than three or four controllers. You're therefore quite limited in your options in terms of number of disks and their distribution across controllers. So all these "allocation strategies" become essentially useless.

All this to lead to the following conclusion: unless you're dealing with a very "customized" NT box, I'd stay away from all this multiple disk/controller rigmarole if at all possible.

If I/O is a concern and you want to stick with NT, I'd go for a solution involving one of those new disk-farm things. I mentioned EMC before, because that's the one I have more experience with. But there are quite a few others. You get a much more flexible system, a HUGE non-stop disk cache and almost no scalability problems.

Cheers
Nuno Souto
nsouto_at_bigpond.net.au.nospam
http://www.users.bigpond.net.au/the_Den/index.html Received on Mon May 28 2001 - 07:35:07 CDT