• Think scalability and performance first!
    • Invest time performing an in-depth current content inventory of Records (are we looking at terabytes?)
    • What are your growth estimates for the size of your electronic record inventories?
  • Large collections of Records require careful planning on numbers and locations of content databases, site collections, sites and document libraries in relation to the file plan
  • Bottom Line: Invest time in planning the SharePoint Logical Architecture for your Records Center
  • Some more thoughts:
    • Try and limit the size of your content databases to 50 GB to 100 GB
    • For very large archives of records, organize your Records Center repositories as independent site collections rather sub-sites and document libraries (consider making a site collection per category in your file plan)
    • Consider RBS
    • Clearly think of your backup, restore and disaster recovery strategy


How SharePoint 2010 can help with scaling [1]

SharePoint 2010 has many features to make it easier to scale to massive archives such as:

  • Database query performance optimizations [2]
  • SQL 2008’s Remote Blob Storage (RBS) decreased size of content DB [3]
    • Basically takes binary data out of your content databases resulting in the binary data on the file systems themselves and the metadata in the databases reducing the database size and improving scalability and performance
  • Internal timer job processing improvements
  • Highly scalable search along with new database indexing strategies [4]
    • Compound indexing, index management, and content-by-query optimizations
    • SharePoint now supports multiple index servers
    • Content index can now be divided into multiple index partitions
    • Each index server can be configured to run multiple crawlers
    • Multiple crawlers can crawl content in parallel
    • Index servers are now stateless.  The crawlers build the content index and propagate directly to the query servers. 
    • multiple query servers benefits of redundancy and parallel performance can be made available
    • crawl management and property store data tables have been split into separate databases and multiple tables of this kind can be configured. 
  • List optimizations
    • Tens of millions of docs in a single list
  • Service Applications Architecture
  • New Send to connections allow moving of records instead of just copying
  • Multiple Records Center Site Collections
  • Internal database improvements (e.g. lock ordering, throttling, IOPS efficiency)
  • Background per-item processing throughput maximization
  • Content Organizer is able to organize your Records Repositories
  • Content Type Syndication allows central location to inherit and publish from


This allows:

  • Millions of records in a single Records Center
  • Multiple Records Centers! (new in SharePoint 2010, in 2007 you were only allowed 1)
  • A distributed archive allowing many Record Centers to bind together to act as one logical repository
  • Fast searching through your archives of records
  • An easy mechanism to move records to the archive of your choice and leave a reference to where it now exists

But this does not excuse you from planning your architecture for scalability and performance!!

Visit Microsoft’s Technet article called “SharePoint Server 2010 capacity management: Software boundaries and limits” [5] to see more of SharePoint 2010’s new boundaries, recommendations and thresholds that can help with scaling, capacity and performance for your Records Management Solution.  I have listed some here:


Limit Threshhold or Maximum
Zone 5 per Web application
Managed path 20 per Web application
Solution cache size 300 MB per Web application
Site collection 250,000 per Web application

Application pools 10 per Web server

Content database size (general usage scenarios) 200 GB per content database
Content database size (all usage scenarios) 4 TB per content database
Content database size (document archive scenario) No explicit content database limit
Content database items 60 million items including documents and list items
Site collections per content database 2,000 recommended, 5,000 maximum
Remote BLOB Storage (RBS) storage subsystem on Network Attached Storage (NAS) Time to first byte of any response from the NAS cannot exceed 20 milliseconds

Web site 250,000 per site collection
Site collection size Maximum size of the content database

List row size

8,000 bytes per row
File size 2 GB
Documents 30,000,000 per library
Major versions 400000 maximum
Items 30,000,000 per list
Rows size limit 6 table rows internal to the database used for a list or library item
Bulk operations 100 items per bulk operation
List view lookup threshold 8 join operations per query
List view threshold 5000 maximum
List view threshold for auditors and administrators 20000 maximum
Subsite 2,000 per site view
Coauthoring in Microsoft Word and Microsoft PowerPoint for .docx, .pptx and .ppsx files 10 concurrent editors per document
Security scope 1,000 per list

Web parts

25 per wiki or Web part page

Number of SharePoint groups a user can belong to

Users in a site collection 2 million per site collection
Active Directory Principles/Users in a SharePoint group 5,000 per SharePoint group
SharePoint groups 10,000 per site collection
Security principal: size of the Security Scope 5,000 per Access Control List (ACL)



The complete list of this series can be seen by the following links:

1. Introduction
2. Document IDs
3. Managed Metadata Service (Term Store)
4. In-Place Records Declarations
5. Site Collection Auditing
6. Content Organizer
7. Compliance Details
8. Hold and eDiscovery
9. Content Type Publishing Hubs
10. Multi-Level Retention
11. Virtual folders and metadata based navigation
12. Scaling
13. Send To…
14. Document Sets













Leave a Reply

Your email address will not be published. Required fields are marked *