יום חמישי 29 מרץ 2012 09:16
For general scenarios there is recommendation, that Content Databese should not be larger thant 200 GB.
In our deployment scenario we will have a 150GB increase per year (mostly documents).
We would like to setup up Sharepoint 2010 in way, that he would create new content database for each year.
We want to achive more content databeses for the same content, so the content DB would not be larger than 200GB.
Example: We have content DB „MyContentDB“ with size 150 GB. Next year it would be 300GB.
So we want to create for each year a new Content Database: „MyContentDB_2012“, „MyContentDB_2013“, MyContentDB_2014“ and so on...
Has sharepoint 2010 some nice solution for this?
יום חמישי 29 מרץ 2012 12:56
Not sure if SharePoint has an OOB solution to handle this scenario. Based on the information provided by you, I suggest you to change the approach you are looking for. Each site collection can correspond to only 1 content DB, while each content DB can correspond to more that 1 site collection. In the scenario explained above, it sounds like you are going to create a new content DB for the same site collection year on year. So on a given year, there will be only 1 content DB active for the site collection. What about the data in different (or previous year's) content DB, in case user wants to access them?
You may need to do a thorough analysis on the increase in size of content DB based on quarter and change the above approach. One recommendation would be to have the main site collection (that user will access across years) with a single content DB and multiple archival site collections with different content DB per site collection. There should be an archival mechanism (thru workflow etc.) on the main site collection that keeps pushing the site content after a certain expiration period.
יום חמישי 29 מרץ 2012 15:24We would like that users could access the previous content / different years. Could you please explain your suggested approach? How can be made a main collection (across years) and multiple archival site collections with different content DB?
יום שישי 30 מרץ 2012 05:48
As you know that we can have multiple site collections under a single web application - one of the site collections will be the main site accessed by users while all others should be archival sites. There may be a few or lot of customization required here. As you have not given detailed business requirement, I'm just summarizing my thought on the suggested approach below:
(a) Create a main site collection under SharePoint web application. This site collection will be used by the users across years.
(b) Create multiple archival site collections (each with a different content DB) under the same web application. Note that each of this archival site will basically hold the same structure as the main site collection, but will correspond to an year or quarter. For example, 2012, 2013 etc. or 2012Q1, 2012Q2, etc. The main site collection and the archival site collections should be based on the same template.
(c) I'm assuming that users will be mostly uploading documents in the main site collection or editing the existing documents. So all the libraries that will hold the user uploaded or editable data will require a custom workflow or timer job. The responsibility of this custom workflow/ job is to move the content (documents) from the main site collection library to the corresponding library in the archival site, based on certain expiration period or state change.
(d) One of the challenges you might face here is to display the content from archival site to the user in the main site collection (as the users may have access only to the main site collection depending on your business requirement). This could be done in 2 ways -
(i) Give users access to the archival site and links on the main site that will redirect them to required archival site. (ii) Make use of custom display page/ custom web parts that summarize, group and display the content from the archival site on the main site collection. This ways user will be able to access the old content across years. Custom display page or web part should have all the features like grouping, filtering, search etc. owing to the huge content size. You may check if any third party web parts that could help you here.
(e) One of the major challenge that you may face here is to implement efficient search across multiple site collection content.
(f) Also, you may need to decide the farm architecture and security of the site collections upfront.
Alternative to the approach given above, I guess SharePoint Record management may also suffice your business needs, but I doubt if it handles such large content DB size increase and efficient archival process. However, I've not done extensive research on the record management front.