SQL Server Performance

EMC & HP Storage Pooling & SQL Server - Does anyone have experience with this?

Discussion in 'SQL Server 2005 Performance Tuning for Hardware' started by DBADave, Oct 1, 2009.

  1. DBADave New Member

    We are looking to implement a new SAN, either an EMC CX400 or an HP EVA 6400. In either case we are considering a storage pool technology. EMC calls it virtual provisioning and I believe HP calls it storage pooling. Essentially you have one or two large pools of drives and from there your SQL Server installations are presented logical chunks of disk. It's even possible to have multiple arrays on the same drives. In HPs proposal we will have a pool of (58) 146GB drives. We can then present them to SQL Server as one drive letter or multiple drive letters.
    We are still trying to understand how this technology works. It clashes with the old practice of keeping your logs, data and tempdb on separate arrays in order to minimize seek time.
    We would love to hear from people who are using this technology. How well does it work for you? How big is your storage pool and did you carve it up into logical drive letters? Do you still use Perfmon to monitor disk performance? What problems does this present?
    Thanks, Dave
  2. FrankKalis Moderator

    Sorry no answer, but rather a reply to keep it on the active thread list. [:)]
  3. amilas New Member

    I am curious as if to you got any more information regarding this issue. I have a SQL2005 hpEVA install coming up and I have been scouring the internet for information regarding Data,log,tempdb placement in light of the vdisk,diskgroup dynamic that occurs in these virtual arrays. Essentially since I cannot discern the physical drives that are involved in the vdisks, the only way I can see to set this up right now is using a single disk group to maximize spindles avaiable to the vraid and then establishing 2 vdisksvdisk1 for vraid1 - logs,temdb,vdisk2 for vraid5 - data. however as I understand it these will be the only 2 drives exposed to the OS , therefore I am essentially putting the logs and tempdb on say E:, and the data on D: and then of course the binaries to the local C:. As of right now I don't see any inherent reason to create additional vdisks for file partitions for SQL server nor even to create an additional vdisk for tempdb. Not a great deal of documentation out there either as this type of logic flies in the face of traditional hitachi sans.
  4. satya Moderator

    Recently at one of my client's place we had issues in performance when any update/insert operation is ON due the shared disks, unless you have full control how the queries are managed I wouldn't suggest this.

Share This Page