Hi Folks, I've read everyting I could get my hands on relating to the setup of SQL 2008 for MOSS 2007. However, probably because I'm lacking the sufficent SQL know-how, I'm still not clear on the optimal layout of my storage. I envisage we are going to have a spread of 10 content databases to ensure our sites do not cause the databases to grow over 100GB. I have read that the databases should be on separate LUN's. My circumstances require me to be as efficient as possible with the utilisation of storage. As the databases will not be allowed to grow any bigger than 100GB and in the interests of not wasting SAN storage, should I create LUN's of just 100GB or thereabouts in size. Or alternatively would I be better advised to keep headroom just in case. If I should keep some headroom, is it a complete anethema to consider setting up bigger LUN's but with two to three DB's per LUN? This would cut my storage requirements somewhat by allowing me to share the required disk overhead amongst a number of databases. I realise a lot depends on the usage of the system and the hardware resources I have but I'd like to at least get some views on this. Thanks, Michael

Michael -- I've got to say, the approach of splitting each individual content database on to a separate LUN really seems like overkill to me. I've worked on some huge SharePoint systems in the past, and we never considered anything that extreme to guarantee SAN resources for the databases. My general approach, when possible, is to have four separate LUNs available to a SQL instance (this also assumes that you're using direct attached storage, or DAS, for your system drive), which we then map to drives and use for the following purposes: D: drive - for database data files L: drive - for log data files S: drive - for SYSDB files T: drive - for TEMPDB files This helps prevent disk I/O contention within SQL Server when its performing its operations, so that use of the SYSDB and TEMPDB resources don't impact usage of the actual databases or their logs. I think what you're proposing just creates too much stuff to manage, as well as a situation where you're more likely to have SQL break b/c a LUN ran out of space than the issues you're trying to avoid by creating all of them. If you have databases that have greater needs, high traffic content sites or maybe your Search database, it can make sense to break them out to a dedicated LUN on a case by case basis, but doing that up front feels like a solution for a problem you don't know if you even have. Out of curiousity, where did you read about databases needing to be on separate LUNs? Maybe we can take a look at that resource for you and help you interpret it properly, or at least see what its talking about and maybe get a handle on its context... JohnMCTS: WSS v3, MOSS 2007, and SCOM 2007 Now Available on Amazon - The SharePoint 2007 Disaster Recovery Guide.

Thanks John, I'm glad that you have given me that steer as it does seem a lot of storage to manage. The material I was referencing is 'Planning and Monitoring SQL Server 2008 Storage for SharePoint: Performance Recommendations and Best Practices' by Bill Baer. It states the following on page 12. · Ideally, place the tempdb, content databases, and SQL Server 2008 transaction logs on separate physical hard disks · Separate database data and transaction log files across different disks. If files must share disks because the files are too small to warrant a whole disk or stripe, or you have a shortage of disk space, put files that have different usage patterns on the same disk to minimize simultaneous access requests. · Allocate dedicated spindles for the search database. I've also listened to the TechNet webcast 'Considerations for Large-Scale SharePoint Server' recorded on June 4th 2009. This was given by Paul J. Learning. Paul stated the following "separate your database based on the disk I/O that's gonna be associated with that database" Slide 19. Paul elaborates on this point in slide 23 'Architectural Design Considerations'. Regards, Michael

Michael -- I've always read the statement on page 12 of that outstanding doc by Bill Baer as saying break them into 3 separate disks, not individual disks for each item. I think the second bullet point is stressing the importance of separating the data and log files more than it is advocating individual disks for each item in those groups. The recommendation for the search db is a good one, that DB does a lot of reads and writes if you're crawling a large amount of content and is going to need dedicated disk I/O to support that. I haven't listened to or viewed the June 4th webcast, but I think that's a nice suggestion in theory that is going to be very difficult to implement in practice. Are you able at this point in the process to identify site collections or databases that are going to have higher needs for disk I/O than most? If so, by all means isolate them as you can, so they perform well and so they don't impact other site collections or database. But in a lot of cases you aren't going to know that a given site collection or DB has these needs until they're making them very clear by causing problems. This is a good reason why it pays to have effective monitoring for your environment and are tracking I/O metrics for your storage, so you can identify candidates for a move to an isolated LUN in sync w/ what Paul is talking about. I just think that trying to do that from the outset is too difficult, unless you have identified specific instances that require this TLC based on measurable data. Does that make sense? JohnMCTS: WSS v3, MOSS 2007, and SCOM 2007 Now Available on Amazon - The SharePoint 2007 Disaster Recovery Guide.

John, Your advice is very practical and I intend to follow it. The webcast concerns the internal MS implementation and also some very large scale third party implementations. Even the referenced MS implementation was revised down because of storage constraints. They located a set of Temp DB's on the same LUN as a content database. As ever, I think there is a balance to be found between designing the optimal infrastructure and practicality. Regards, Michael