Jason Medero SharePoint MVP: SharePoint Space for all things SharePoint, OCS, RMS, InfoPath, and Office

td {
font-family: Arial, Helvetica, sans-serif;
font-size: 10pt;
}

Have you ever wondered how you should plan on setting up your content database for your MOSS/WSS farm?  Questions such as:  Should I pre-create my content databases before bringing up my farm?  Is it best to start with just one content database for my web applications?  How do these content databases fill up?  Does the first content database grow until it reaches its site warning or max limit and then SharePoint begins creating sites in the next content database inline?  If you have three content DBs attached to your web application how do they fill up and in what order?   Well today I decided to write up this blog article to describe the process and the logic behind your web applications content databases  It seems that they fill up evenly across all of the content DBs.  Lets jump right into an example as this is the best way to explain this topic.  For example, if you have three content DB's all set to a warning of 5 sites and a max of 10 sites then SharePoint is going to evenly add sites to each of the content DB's. 

So you have content DB's named:

- Site A

 -Site B

 -Site C

Each are set to the aforementioned warning and max limits (5 site warning and 10 site max).  You then create three sites one by one and then have a look.  You should now see that one site has been created in each of the content DB's.    This occurs because each site has been set to the same exact dimensions in regards to site warning limit and max site limit.   Now consider this scenario:

If an administrator was to create a site, which content database do you think SharePoint will create the site in?  If you guessed Site C you are correct!  SharePoint will create the site in the content database that is farthest away from its site warning limit.  Essentially SharePoint will try its best to keep the site count to site warning limit between all content databases as even as possible.  This meaning that if you were to pre-create three content databases before you began creating sites all of your sites/site collections would be spread throughout those three databases evenly.   I thought this was very interesting because even though this approach makes sense logically it makes it more difficult to pin point what content database a certain site might belong to.  Luckily enough we now have the option to move and split our content databases up via this new STSADM command line.  What I usually recommend to clients is to start with one content database and have the processes in place (site collection quotas, quota templates) to make sure that your content databases are manageable from a disaster recovery's perspective.  The one content database at a time approach provides the ability (not the greatest of control) at a basic level to know what sites were created within what content database.  If current records are kept of when content databases are turned offline then this ability can become more accurate. Hope this helps!

Cheers,

This entry was posted on Monday, April 7th, 2008 at 6:34 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

td {
font-family: Arial, Helvetica, sans-serif;
font-size: 10pt;
}

Have you ever wondered how you should plan on setting up your content database for your MOSS/WSS farm?  Questions such as:  Should I pre-create my content databases before bringing up my farm?  Is it best to start with just one content database for my web applications?  How do these content databases fill up?  Does the first content database grow until it reaches its site warning or max limit and then SharePoint begins creating sites in the next content database inline?  If you have three content DBs attached to your web application how do they fill up and in what order?   Well today I decided to write up this blog article to describe the process and the logic behind your web applications content databases  It seems that they fill up evenly across all of the content DBs.  Lets jump right into an example as this is the best way to explain this topic.  For example, if you have three content DB's all set to a warning of 5 sites and a max of 10 sites then SharePoint is going to evenly add sites to each of the content DB's. 

So you have content DB's named:

- Site A

 -Site B

 -Site C

Each are set to the aforementioned warning and max limits (5 site warning and 10 site max).  You then create three sites one by one and then have a look.  You should now see that one site has been created in each of the content DB's.    This occurs because each site has been set to the same exact dimensions in regards to site warning limit and max site limit.   Now consider this scenario:

If an administrator was to create a site, which content database do you think SharePoint will create the site in?  If you guessed Site C you are correct!  SharePoint will create the site in the content database that is farthest away from its site warning limit.  Essentially SharePoint will try its best to keep the site count to site warning limit between all content databases as even as possible.  This meaning that if you were to pre-create three content databases before you began creating sites all of your sites/site collections would be spread throughout those three databases evenly.   I thought this was very interesting because even though this approach makes sense logically it makes it more difficult to pin point what content database a certain site might belong to.  Luckily enough we now have the option to move and split our content databases up via this new STSADM command line.  What I usually recommend to clients is to start with one content database and have the processes in place (site collection quotas, quota templates) to make sure that your content databases are manageable from a disaster recovery's perspective.  The one content database at a time approach provides the ability (not the greatest of control) at a basic level to know what sites were created within what content database.  If current records are kept of when content databases are turned offline then this ability can become more accurate. Hope this helps!

Cheers,

This entry was posted on Monday, April 7th, 2008 at 6:34 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.