Partitions on RAID Array

We have a 12 disk 2.4TB Raid 10 Array, where we have 3 large database data
files, theres been a suggestion that we split the physical drive into 3
partitions so if we have to grow the files in future the files will stay
contiguous on the disk.. ..I'm not worried about splitting the array into
three from a size point of view we have bags of space for future growth..
...I'm aware the databases should be sized properly so they don't autogrow and
that minimal fragmentation at the os level will have little to no impact on
the performance... ...however for sake of argument will splitting the RAID
array into the 3 partitions keep the database files contiguous on the disks,
and would there be any performance hit on the array by splitting it into 3
volumes?
Thanks in advance
Ben
I'd be inclined to not create three logical partitions. I don't have any
current empirical data to back me up on this. But I do remember a Compaq
study a few years ago on using a single partition vs. multiple logical
partitions on a physical device, and the single partition configuration came
out better performance wise. I'm not claiming that the Compaq study is still
relevant. But then I don't see any substantial benefit of creating three
logical partitions.
The practice I follow has always been: single physical device (as presented
to the OS) -> single partition -> single NTFS volume.
Do note that if you have files on the same volume, moving a file to another
place on that same volume is a filesystem metadata operation. Moving a file
across volumes, however, must move data. If you don't plan to move your
files, this is not an issue.
Linchi
"Ben UK" wrote:

> We have a 12 disk 2.4TB Raid 10 Array, where we have 3 large database data
> files, theres been a suggestion that we split the physical drive into 3
> partitions so if we have to grow the files in future the files will stay
> contiguous on the disk.. ..I'm not worried about splitting the array into
> three from a size point of view we have bags of space for future growth..
> ..I'm aware the databases should be sized properly so they don't autogrow and
> that minimal fragmentation at the os level will have little to no impact on
> the performance... ...however for sake of argument will splitting the RAID
> array into the 3 partitions keep the database files contiguous on the disks,
> and would there be any performance hit on the array by splitting it into 3
> volumes?
> Thanks in advance
> Ben

Partitions on RAID Array

We have a 12 disk 2.4TB Raid 10 Array, where we have 3 large database data
files, theres been a suggestion that we split the physical drive into 3
partitions so if we have to grow the files in future the files will stay
contiguous on the disk.. ..I'm not worried about splitting the array into
three from a size point of view we have bags of space for future growth..
..I'm aware the databases should be sized properly so they don't autogrow a
nd
that minimal fragmentation at the os level will have little to no impact on
the performance... ...however for sake of argument will splitting the RAID
array into the 3 partitions keep the database files contiguous on the disks,
and would there be any performance hit on the array by splitting it into 3
volumes?
Thanks in advance
BenI'd be inclined to not create three logical partitions. I don't have any
current empirical data to back me up on this. But I do remember a Compaq
study a few years ago on using a single partition vs. multiple logical
partitions on a physical device, and the single partition configuration came
out better performance wise. I'm not claiming that the Compaq study is still
relevant. But then I don't see any substantial benefit of creating three
logical partitions.
The practice I follow has always been: single physical device (as presented
to the OS) -> single partition -> single NTFS volume.
Do note that if you have files on the same volume, moving a file to another
place on that same volume is a filesystem metadata operation. Moving a file
across volumes, however, must move data. If you don't plan to move your
files, this is not an issue.
Linchi
"Ben UK" wrote:

> We have a 12 disk 2.4TB Raid 10 Array, where we have 3 large database data
> files, theres been a suggestion that we split the physical drive into 3
> partitions so if we have to grow the files in future the files will stay
> contiguous on the disk.. ..I'm not worried about splitting the array into
> three from a size point of view we have bags of space for future growth..
> ..I'm aware the databases should be sized properly so they don't autogrow
and
> that minimal fragmentation at the os level will have little to no impact o
n
> the performance... ...however for sake of argument will splitting the RAID
> array into the 3 partitions keep the database files contiguous on the disk
s,
> and would there be any performance hit on the array by splitting it into 3
> volumes?
> Thanks in advance
> Ben|||Hi Ben,
I tend to agree with Linchi, that splitting it up might not give you
much in term of performance. If you should gain from splitting the files
up, you should split them up on physical different spindles and best of
all on seperate disk controllers. If you go down that route, you should
at the same time add some more spindles to each array - otherwise I
don't think you'll gain anything from the change.
You can also try to look at www.storageperformance.org to see if you can
find some usefull info in there.
Regards
Steen Schlüter Persson
Database Administrator / System Administrator
Ben UK wrote:
> We have a 12 disk 2.4TB Raid 10 Array, where we have 3 large database data
> files, theres been a suggestion that we split the physical drive into 3
> partitions so if we have to grow the files in future the files will stay
> contiguous on the disk.. ..I'm not worried about splitting the array into
> three from a size point of view we have bags of space for future growth..
> ..I'm aware the databases should be sized properly so they don't autogrow
and
> that minimal fragmentation at the os level will have little to no impact o
n
> the performance... ...however for sake of argument will splitting the RAID
> array into the 3 partitions keep the database files contiguous on the disk
s,
> and would there be any performance hit on the array by splitting it into 3
> volumes?
> Thanks in advance
> Ben

Partitions as SQL Server Resources in Clustering Services

I've got 2 Arrays on my SAN.
Array 1 is 66 gb.
Array 2 is 230 gb.
I've partitioned the drives in MS2003 this way:
Array 1, Drive Q: (Quarum) 2gb
Array 1, Drive S: 64gb
Array 2, Drive R: 230gb.
I installed SQL Server after setting up MSCS.
Everything went fine.
Now I want to add the Drive S: as a resource in MSCS, so I can store
my transaction logs on it.
MSCS seems to look for a Physical Disk.
Is this possible?
Oh its possible all right. MSCS has to have a Physical disk, as you have
noticed. You have two to the OS> 1 - 66 GB, 1 230 GB.
Cheers,
Rod
"Travis" <twillard@.generasystems.com> wrote in message
news:bc4cf00.0406161203.1b035e4a@.posting.google.co m...
> I've got 2 Arrays on my SAN.
> Array 1 is 66 gb.
> Array 2 is 230 gb.
> I've partitioned the drives in MS2003 this way:
> Array 1, Drive Q: (Quarum) 2gb
> Array 1, Drive S: 64gb
> Array 2, Drive R: 230gb.
> I installed SQL Server after setting up MSCS.
> Everything went fine.
> Now I want to add the Drive S: as a resource in MSCS, so I can store
> my transaction logs on it.
> MSCS seems to look for a Physical Disk.
> Is this possible?
|||Sorry, I'm probably not being clear.
Cluster Group has 1 physical disk, Q:
SQL Server has 1 physcial disk, R:
I've broken the cluster's physical disk into two partitions: Q and S.
How can I get my SQL Sever group to see the S partition as a resource,
so i can store my logs there?
When I try to add it as a physical drive, it of course doesn't show up.
Is there another resource type that allows me to see the partition?
*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!
|||Ok, so here is my trouble.
When i go into add a resource as a phyical dive, no drive letter shows
up.
How do I add the S: drive so that the SQL Cluster can see it?
*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!
|||You have all 3 drive letters already in the cluster. Double click on the Q
drive and look at parameters, notice it says Q & S. That is because
clustering goes by the physical disk and not partitions.
You add another array or have your logs and quorum on the same physical
disk, but different partitions of it.
Cheers,
Rod
"Travis Willard" <twillard@.generasystems.com> wrote in message
news:e2%23Tjs%23UEHA.1656@.TK2MSFTNGP09.phx.gbl...
> Sorry, I'm probably not being clear.
> Cluster Group has 1 physical disk, Q:
> SQL Server has 1 physcial disk, R:
> I've broken the cluster's physical disk into two partitions: Q and S.
> How can I get my SQL Sever group to see the S partition as a resource,
> so i can store my logs there?
> When I try to add it as a physical drive, it of course doesn't show up.
> Is there another resource type that allows me to see the partition?
> *** Sent via Devdex http://www.devdex.com ***
> Don't just participate in USENET...get rewarded for it!
|||See my other reply
Cheers,
Rod
"Travis Willard" <twillard@.generasystems.com> wrote in message
news:%23dkIms%23UEHA.1656@.TK2MSFTNGP09.phx.gbl...
> Ok, so here is my trouble.
> When i go into add a resource as a phyical dive, no drive letter shows
> up.
> How do I add the S: drive so that the SQL Cluster can see it?
>
> *** Sent via Devdex http://www.devdex.com ***
> Don't just participate in USENET...get rewarded for it
|||Hi Travis,
It depends on how exactly the drives have been configured in Array 1. If Q:
and S: are file system partitions on the same 'disk' (LUN in the array) then
you will not be able to add a new Physical Disk resource. If they are single
partitions each on their own 'disk' (LUN in the array) then you will be able
to if you first set the disk up for the o/s, basically by creating and
formatting the 64 GB NTFS partition (if you don't use NTFS the disk won't
appear in the GUI when you try to add the resource).
The Cluster Administrator GUI to add a physical disk resource queries the
Clusdisk key in HKLM\System\CCS\Services and looks for disk signatures (4
byte ID numbers generated by the o/s). These signatures are created and
written to the disk's master boot record (defined as first sector on the
disk, before the file system partitions begin, but remember in an array this
all virtualised) when you first use the Disk Management snap-in on a disk in
Computer Management.
Upshot of this is after you have configured the LUNs in the array you have
to configure the disk in Disk Management for it to be visible to the
clusdisk driver and therefore appear in the GUI to add a Physical Disk
resource.
Hope this helps.
"Travis" <twillard@.generasystems.com> wrote in message
news:bc4cf00.0406161203.1b035e4a@.posting.google.co m...
> I've got 2 Arrays on my SAN.
> Array 1 is 66 gb.
> Array 2 is 230 gb.
> I've partitioned the drives in MS2003 this way:
> Array 1, Drive Q: (Quarum) 2gb
> Array 1, Drive S: 64gb
> Array 2, Drive R: 230gb.
> I installed SQL Server after setting up MSCS.
> Everything went fine.
> Now I want to add the Drive S: as a resource in MSCS, so I can store
> my transaction logs on it.
> MSCS seems to look for a Physical Disk.
> Is this possible?
|||Thanks Peter,
I was able to solve the problem with a little trail and error. I added a
new Array and then created a new partition and was able to add it as a
physical disk resource. Great! SQL Server would still not see it! So
finally after beating my head on the wall, I figured out that you need
to add the physical disk as a dependency of the SQL Server resource.
Problem solved!
I've not got an array that is raid 1, for my quorum and some space for
backing up. 1 array for my data (raid 5) and another for my logs (raid
5).
Thanks for responding!
*** Sent via Devdex http://www.devdex.com ***
Don't just participate in USENET...get rewarded for it!