Summary: Question about the best configuration of mass storage for Sybase
Keywords: Disk Sybase
Sender: news@ucc.su.OZ.AU
Nntp-Posting-Host: extro.ucc.su.oz.au
Organization: Sydney University Computing Service, Sydney, NSW, Australia
Date: Tue, 24 Nov 1992 00:04:44 GMT
Lines: 31
I am currently making reccomendations for machine configurations for Sybase
SQL server. According to theory, it is far better to have a number of smaller
disks than it is to use one large disk e.g. 4 * 250 Mb drive on 2 different
controllers with disk 1 for the operating system, and log device, disk 2 for
all non clustered indexes, and disk 3 & 4 (on the second controller) used for
data, instead of 1 1.2 Gb disk.
At the moment my primary concern is performance (I am already convinced about
the benefits from a reliability viewpoint).
According to theory the more drive heads you distribute the data across the
better your performace, however the 250 Mb drives I was looking at only had 4
heads (multiplied by four disks for a total of 16 heads) compared to the 1Gb
drive's 14 heads. On top of this the data transfer rates, average seek times
etc on the 1Gb drive were much better than the seek times etc for the 250Mb
drive. As Sybase was written when disk drives were much smaller, does the
"distribute across more drives = better perormance" theory still hold ?
The second question I have concerns RAID, and it's disk striping. I have heard
that this feature is great if you are grabbing large sequential chunks of data, however for random reads and writes (which is exactly the sort of thing we are
doing), the improvment is not as noticeable.
The third question I have has to do with disk caching mechanisms. Given that
Sybase looks after it's own data cache, and uses asynchronous disk I/O, is
there a significant advantage to having caching on the disk controller(s).
