locked
Multiple Content Databases and PWA Sites RRS feed

  • Question

  • Hello,

    First of all thank you for those that helped me successfully install a Sharepoint Server 2010 and Project 2010 (farm).

    Now, I am thinking about the future PWA deployments and would like to know if it would be a bad practice to create multiple PWA sites in one Content Database.

    I have created a content database named ProjectServer_PWA and have a PWA site named Technology (For IT department).

    In the coming future new departments will want their own sites. Should I create a new PWA site under the same content database ProjectServer_PWA or would it be best to have a new content database for each department that will want a PWA site and workspaces for its members?

    Thank you all again!

    Wednesday, September 8, 2010 11:33 PM

Answers

  • Thinking this through....

    1) Don't forget that 2010 supports multiple departments.  From a deployment and management perspective, I would encourage you to try to accomodate all departments in a single instance of PWA.

    2) If a single instance absolutely won't do, you can definitely deploy to different content dbs.  This would perhaps alleviate scalability issues as you don't want any single db to exceed the 100-150 GB size.  At least, that was the guidance in 2007, and I haven't heard of it changing.

    3) That being said, each PWA site is its own Site Collection, and in theory, you are putting the workspaces in the same Site Collection as the PWA site.  Thus, it should be quite easy at some point in the future to extract a site collection from a single content db and place it into a second content db.  That was definitely possible in 2007, and I don't see that 2010 should be any different.

    4) So you're doing a bit of work to put everything in multiple dbs up front.  That increases scalability down the road, but it doesn't really save you that much effort, as you could have just split the content dbs later on as well.

    To me, I don't see a clear argument for or against.

    Thursday, September 9, 2010 12:02 AM

All replies

  • Thinking this through....

    1) Don't forget that 2010 supports multiple departments.  From a deployment and management perspective, I would encourage you to try to accomodate all departments in a single instance of PWA.

    2) If a single instance absolutely won't do, you can definitely deploy to different content dbs.  This would perhaps alleviate scalability issues as you don't want any single db to exceed the 100-150 GB size.  At least, that was the guidance in 2007, and I haven't heard of it changing.

    3) That being said, each PWA site is its own Site Collection, and in theory, you are putting the workspaces in the same Site Collection as the PWA site.  Thus, it should be quite easy at some point in the future to extract a site collection from a single content db and place it into a second content db.  That was definitely possible in 2007, and I don't see that 2010 should be any different.

    4) So you're doing a bit of work to put everything in multiple dbs up front.  That increases scalability down the road, but it doesn't really save you that much effort, as you could have just split the content dbs later on as well.

    To me, I don't see a clear argument for or against.

    Thursday, September 9, 2010 12:02 AM
  • in addition to Andrew's great answer would also look at the type of content PMO department are looking to store with the dedicated PWA content database and hence try to estimate the database size. The good thing is that you could move one department in the future to another content db if need be using standard powershell cmdlets (so you can start with one and go to multiple if need be).

    As usual monitor usage and perf counters carefully to be a step ahead of users and figure out the best config to meet their needs.


    Blog | Facebook | Twitter | Posting is provided "AS IS" with no warranties, and confers no rights.
    Project Server TechCenter | Project Developer Center | Project Server Help | Project Product Page
    Thursday, September 9, 2010 12:34 AM