- Community Home
- >
- Storage
- >
- Midrange and Enterprise Storage
- >
- StoreVirtual Storage
- >
- Re: SQL volume
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-06-2012 02:35 PM
03-06-2012 02:35 PM
SQL volume
What is the best practices to allocate the disks for SQL 2005 on windows 2003, thin or thick provisioned?
- Tags:
- SQL
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-06-2012 07:03 PM
03-06-2012 07:03 PM
Re: SQL volume
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-07-2012 06:58 AM
03-07-2012 06:58 AM
Re: SQL volume
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-08-2012 03:35 PM
03-08-2012 03:35 PM
Re: SQL volume
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-09-2012 01:25 AM
03-09-2012 01:25 AM
Re: SQL volume
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-09-2012 04:17 AM
03-09-2012 04:17 AM
Re: SQL volume
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.