I'm trying to design a storage plan for a new SQL Server 2008 R2 Data Warehouse under Hyper-V, initially at least I'm having to use an existing SAN that wasn't built with SQL in mind and (for now) can't be reconfigured. I'm going to be getting 2TB
of storage that's carved out of one single giant array of disks on the SAN (not sure of the RAID level but again, we can't change that), the space would be carved-up on the SAN and presented to the host as separate logical drives (i.e. not VHDs).
Unfortunately this means that I can't do the usual thing of isolating TempDB, Transaction Logs and Data Files on physically separate spindles. My plan (roughly speaking) was going to be to separate as follows:
- TempDB: 32GB
- Staging Area: 96GB (text files and some databases)
- Transaction Logs: 256GB
- User DB Partition 1: 512GB
- User DB Partition 2: 512GB
- User DB Partition 3: 512GB
Thus, my question is - in this scenario is there any benefit in separating the files at all? Given that the data could be sourced from the same spindles there's not a great deal I can do about it from a performance level.
Also, on a side note - even if there aren't any performance benefits, would this be a suitable storage plan to use if I were to later migrate to a different SAN?&n
View Complete Post