topic Re: SQL volume in StoreVirtual Storage

SQL volume

bublik — Tue, 06 Mar 2012 22:35:30 GMT

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

Re: SQL volume

Emilo — Wed, 07 Mar 2012 03:03:27 GMT

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.

Re: SQL volume

Steve Burkett — Wed, 07 Mar 2012 14:58:09 GMT

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.

Re: SQL volume

bublik — Thu, 08 Mar 2012 23:35:11 GMT

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?

Re: SQL volume

Steve Burkett — Fri, 09 Mar 2012 09:25:15 GMT

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.

Re: SQL volume

bublik — Fri, 09 Mar 2012 12:17:17 GMT

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.