Re: SQL File I/O in the Storage Engine
- From: "Mike H" <mike8675309@xxxxxxxxx>
- Date: 28 Nov 2006 10:47:02 -0800
lucm wrote:
Note the application I'm thinking of is an SQL Server accessing data
from a SAN that has 26 spindles in Raid 10 in it's one lun.
I wonder, how many SP do you have on your San? For 26 disks my guess is
that you have 2 SP and 2 DAE.
In which case you could get a better performance with two LUNs, one for
the database (dedicated RAID-10 array of 24 disks) and the other for
the transaction logs (dedicated RAID-1 array of 2 disks), defaulting to
different SPs. Also make sure to split the RAID-1 disks over the two
DAE to get your San as fault-tolerant as possible.
Believe it or not, such would not be the case in the specific
application I discussed. Maximum I/O tests showed that the
architecture of the SAN allowed for higher I/O by using the more
spindles even when testing using SQL storage patterns for logs and
data. Now if we could have made two luns, each with 26 spindles, that
story may have been a bit different. But for the san I studied, 1 lun
of 26 drives in a raid 10 array had greater maximum performance for SQL
Server than 2 luns, splitting up the drives. (Note the SAN was fully
redundant.)
But more to the point of the question, I'm trying to understand if
there is any benefit in the current storage engine to creating mutliple
files for a specific file group regardless of the disk hardware
configuration. I.E., Is the storage engine only able to take advantage
of some feature that improves I/O specifically due to having multiple
files.?
Everything I've seen says no. Yet there are microsoft documents that
hint at YES, but don't specifically show this. EMC is saying yes,
without any thing to back it up but this SQL Server 7.0 document that
discusses the benefits.
.
- Prev by Date: Re: Need to buy SQL Server 2000
- Next by Date: Re: How do you get "My Documents" onto the Open File dialog box?
- Previous by thread: How do you get "My Documents" onto the Open File dialog box?
- Next by thread: Silent install is not always silent
- Index(es):
Relevant Pages
|
