Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

The image url is: http://social.microsoft.com/Forums/getfile/57642/

I believe you are understanding the site collections and the sites from the above picture. [All site collections are using their own content databases]

SC6 is the main/big site collection in the diagram. It has 5 regions named Europe, Asia, East, West and Central. And there are "Department" sites in the same level as regions under the site collection.

The Department sites contains high level information which can be accessible by owners, managers etc. And each region also has department data which can be uploaded by the department users. Now, the requirement is all department owners able to see the department related data from a region directly in their department sites instead of going to the each region. And we have to write some custom logic to show the data from region sites in department sites.

Each region itself is very big and contains many sites in it.

And the questions are:

  1. If we use the above architecture then the site collection (SC6) size will grow around 500-600GB in one year. But there are limitations on site collection size 100GB and Content database size 200GB. If we Remote Blob Storage then there are some other issues [But not sure]

  2. We cannot create the region sites as site collections as the department users should be able to view the regions. [Implementation of permissions, security will be difficult]

So, how to resolve these kind of problems? Any suggestions will be greatly appreciated.

share|improve this question
    
Can you confirm that even if permissions would be mainly given using AD security groups (instead of SPGroups) and content from other locations would be displayed using SharePoint Search, you would need to have single SC6 Site Collection? –  Jussi Palo Jan 23 '12 at 18:39

3 Answers 3

I would recommend checking out AvePoint's whitepaper on RBS, this explains the sizing in more detail and will answer your question. Dan Holme, SharePoint MVP and Chief Evangelist at AvePoint, wrote this white paper: http://www.avepoint.com/assets/pdf/sharepoint_whitepapers/Optimize_SharePoint_Storage_with_BLOB_Externalization.pdf

share|improve this answer
    
Ho Jeremy Thake, thanks a lot for responding very quickly. I have checked the PDF document already. This is what I am confused whether to go with RBS or NOT. Many people are recommending RBS only for document archive and not for saving documents to file system to reduce content database size. I am really confused. A site collection can be > 300GB and a single content database size can grow upto 500GB? –  Rare Solutions Jan 23 '12 at 16:19
    
These 200GB and 4TB are recommendations, and with RBS, you will still be within these recommended limits: "If you are using Remote BLOB Storage (RBS), the total volume of remote BLOB storage and metadata in the content database must not exceed this [200 GB per content database] limit." –  Jussi Palo Jan 23 '12 at 18:46
    
@jeremy-thake thanx for your answer. Even though the whitepaper doesnt directly mention any AvePoint products, you should as a rule of thumb remember to mention your affiliation with AvePoint when you point to whitepapers created by/for your company. FAQ - promotion –  Anders Rask Jan 23 '12 at 19:34

RBS can be used both in an archiving scenario (where we offload documents from SharePoint that are rarely used or updated) but it is also very useful for ACTIVE content that is simply being stored outside the content databases... In these "collaborative" instances, we want to make sure that the external storage location where we store the BLOBs has good performance so that the user does not see performance suffer as the WFE retrieves the BLOB.

Microsoft's guidance about supported content DB size was recently and it can be somewhat confusing. Basically, Microsoft wants you to look at the size of the database as well as the externalized BLOBs and ensure that they do not exceed the updated supported limits. Their updated limits are support for "collaborative" content DBs of up to 4TB (again, include both the actual database as well as the external BLOBs) and "archive" content DBs of any size as long as they are housing sites based on Doc Center or Records Center site templates and are used only for non-active content. See all detail here: http://technet.microsoft.com/en-us/library/cc262787.aspx#ContentDB

One thing to make sure you look at (and Microsoft themselves mention it in the article)- you must think about backup and recovery as most database backups will not include your external BLOB store. There are many strategies for this. As you consider an RBS provider, you should have this conversation with them and see what functionality/process they have to incorporate RBS content into your data protection strategy. The doc Jeremy linked to above reviews AvePoint's approach and functionality in this area.

share|improve this answer
    
Thanks John. If we use RBS, then how the backup and restore works? Are there any great articles about these? I have posted the same article in MSDN forums and see the responses... social.msdn.microsoft.com/Forums/en-US/sharepoint2010general/… They are recommending to not go for RBS. –  Rare Solutions Jan 23 '12 at 17:15
    
With RBS in both SharePoint and SQL Server backups, BLOBs will be backed up normally in the backup file (blogs.msdn.com/b/opal/archive/2010/03/24/…). –  Jussi Palo Jan 23 '12 at 18:35

If you're going to be grabbing data from other sites (all within the same site collection) then SharePoint content query web part should do the trick. Only consideration there is permissions, make sure your users have at least read access to all content you want to roll up.

Using the CQWP you can keep the data in one place, without having to copy it all over the place.

regarding RBS, Check out my post http://davidlozzi.com/2011/08/12/storing-your-sharepoint-files-outside-of-the-database-rbs/, "Microsoft’s recommendations for database sizes in SharePoint will include the size of the database and the BLOB store, so you’re not escaping their size recommendation"

Check out http://www.microsoft.com/downloads/details.aspx?FamilyID=37B1333C-A8D9-45F9-BE78-9212C2CD3641&displaylang=e&displaylang=en, great whitepaper on managing terabyte databases with SharePoint.

share|improve this answer
    
You can effectively kill the system with too large CQWP queries in site collections of these sizes. So whatever you do, don't plan for using CQWP to show "latest 10 documents" of the whole SC6 :) –  Jussi Palo Jan 23 '12 at 18:43
    
Jussi, thanks, i'll keep that in mind! –  David Lozzi Jan 23 '12 at 18:45
    
Thanks David and Jussi for the great replies. Could you clarify me that when Microsoft says with the SP1 installation the database size supports upto 4TB, means a single content database with one site collection can grow that big???? –  Rare Solutions Jan 24 '12 at 2:14
    
Yeah, technically it can grow that large. God help you if it does... I can't imagine the maintenance headaches on that one ;) –  David Lozzi Nov 5 '12 at 14:59
    
After got good experience on storage related in SharePoint... I believe that the 4TB size Microsoft mentioned is only for the archive databases like one way users (only store/save and read, no edit, write etc). It's not valid for regular web applications/ site collections. For the regular sites the limitation still be 300GB. I see some scenarios where the content database grown > 300GB but sites all looks good including performance. I started working on 2013 since last year and I believe the storage is good compared to previous versions! –  Rare Solutions Aug 19 '13 at 6:07

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.