SQL volume

[bublik]

What is the best practices to allocate the disks for SQL 2005 on windows 2003, thin or thick provisioned?

[Emilo]

With Saniq dont get to hung up on weather a volume is full or thinnly provisioned. When a volume is full provisioned its space is allocated only for that volume. When it is thinnly provisioned it allocates the space on a as needed basis.  If you feel that you will be growing the volme quite a bit then it could save some administrative cycles as the space will not need to be allocated as the data continues to occupy real space. Many people like the thin provisioning this way they could use the space for other purposes and when space is needed purchase more SANS.

[Steve Burkett]

There's a Best Practices for SQL 2005 and Lefthand Networks document on the HP site here.

It pretty much says seperate your data, log and temp files out to seperate volumes/LUNs, thin Provision your data LUN, thick provision the log and temp LUNs.

[bublik]

If I have multiple databases on the SQL cluster is it a good practice to create a different volume for each database and than one volume for tempdb and one volume for logs?

[Steve Burkett]

Yes as Windows can more efficiently queue up disk operations across all the multiple volumes which can then work in parallel, rather then just have one big queue on one volume.

We took our main applications that had the higher I/O requirements and gave them their own data volumes, and then had one volume that held all the remaining small, not used very often DBs.

If you're using SAN snapshotting, you might want to consider your volumes for that as well. If you have all your DBs on the one volume, you can't revert one DB back to the way it was when the snapshot was taken without also reverting the other DBs.

[bublik]

Does anyone have ideas on how to migrate all databases from one large to their own volumes and minimize downtime. I guess I can always use log shipping or mirroring but hoping to use SAN technology instead. 20 minutes of downtime is acceptable.