MCT USE ONLY. STUDENT USE PROHIBITED Planning for Performance and Capacity 3-47 Client Traffic Payload Office Web Apps High Medium PowerPoint Web broadcast High Low Microsoft Word 2010 and Microsoft PowerPoint® 2010 client applications Medium Low Microsoft OneNote® client application High High Outlook Social Connector Medium Medium Microsoft SharePoint Workspace 2010 High Medium In addition to planning capacity for SharePoint content storage, you must plan capacity for additional SQL Server requirements, such as transaction log storage. SQL Server creates and expands transaction logs as additional operations occur to content, such as adding new content or making changes to existing content. You can manage transaction logs in two different ways: • Change the database model from full to simple. The simple database model automatically limits transaction log size by reusing space from committed transactions. • Regularly back up the databases. During a SQL Server–aware backup task, transaction log data is backed up and the transaction log is truncated to free space on the transaction log disk. This option requires enough disk space to enable the transaction log to grow sufficiently between backups. Note: The database model also affects the recoverability of content databases and advanced features such as database mirroring. If you back up a database under the simple model, you can only restore the database to the time of the backup. If you back up a database under the full model, you have the capability to restore a database to the time of failure. The full model is required to support database mirroring. MCT USE ONLY. STUDENT USE PROHIBITED 3-48 Designing a Microsoft® SharePoint® 2010 Infrastructure How Capacity Planning Affects Farm Design Key Points After you have established the features that you want to provide in the solution and the dataset that you want to support, you must consider the business requirements from a capacity standpoint to make decisions about storage requirements. For database servers, you must decide on the number of databases that you require. Specific service applications, such as the Managed Metadata Service or the User Profile Service, require additional databases. In addition, your content databases are constrained by the following architectural limits in SharePoint 2010: • A single site collection should not be larger than 100 GB, unless it is the only site collection in a database. • A single content database should not be larger than 200 GB. • A site collection cannot span multiple databases. These limits will drive the choice that you make about the number of site collections and databases that you require, based on the quantity of storage that is required in SharePoint 2010. In addition, for management purposes, such as MCT USE ONLY. STUDENT USE PROHIBITED Planning for Performance and Capacity 3-49 backup and restore, you may choose to implement a larger number of smaller databases rather than a smaller number of large databases. You must also consider the storage hardware requirements. Your choice of RAID implementation will affect the quantity of disks that you require and the cost of your solution. If you plan a mirrored SQL Server implementation, you must duplicate your database and transaction log storage. If you plan to use SAN for storage, correctly size the SAN volumes, including transaction logs and configuration and service application databases where appropriate. Note: It is recommended that your plan includes sufficient free space to enable database growth over time. The recommended value of free space on the content database disks should be equal to the database size, after you populate the database with the planned content. After you have established your initial capacity requirements, create a baseline and monitor storage over time to identify trends in storage growth. Question: Why should database size typically be kept below 200 GB for each database? MCT USE ONLY. STUDENT USE PROHIBITED 3-50 Designing a Microsoft® SharePoint® 2010 Infrastructure Planning for Content Characteristics Key Points Different types of content and the requirements for that content storage in SharePoint can significantly increase the storage capacity requirement for a SharePoint solution. Documents Typically, documents take up the same amount of space in SharePoint 2010 that they take up in a traditional file share. However, additional feature requirements can significantly increase the storage burden for documents or digital assets. Digital Assets Previous versions of Microsoft Office SharePoint had few digital asset capabilities. With the improvements in SharePoint 2010, many organizations may consider storing digital assets in SharePoint content databases. Version History Document libraries can store historic versions of documents each time a user makes a change. Historic document versions take up an additional amount of MCT USE ONLY. STUDENT USE PROHIBITED Planning for Performance and Capacity 3-51 storage according to the historic version size. This means that a document with 10 versions that are all approximately 10 MB in size takes up 100 MB in the content database. Metadata Adding metadata to documents increases the size of the content database and the search properties database. If you do not know the quantity of metadata, for planning purposes, use an estimate of 10 KB for each item. Recycle Bin Behavior When you consider database file size, you must take account of the SharePoint 2010 Recycle Bin behavior. The second-stage Recycle Bin uses an additional percentage of the site collection quota. Therefore, for a database with a single site collection, if the second stage Recycle Bin is set to use 50 percent of the site collection quota and the site collection quota is set to 50 GB, the database file could grow to be 75 GB in size. MCT USE ONLY. STUDENT USE PROHIBITED 3-52 Designing a Microsoft® SharePoint® 2010 Infrastructure Lesson 4 Designing for Capacity You must plan the capacity targets and how you will achieve them for all SharePoint data storage. If you do not plan enough storage, including storage for growth, your SharePoint farm may not be able to manage user demands. In addition to calculating the storage requirements for content databases, this will include planning the capacity of configuration databases, databases for service applications, search-related databases, and index partitions. Objectives After completing this lesson, you will be able to: • Design capacity for configuration databases. • Design capacity for service application databases. • Design capacity for content databases. • Design capacity for search databases and index partitions. • Plan for remote BLOB storage for SharePoint 2010. MCT USE ONLY. STUDENT USE PROHIBITED Planning for Performance and Capacity 3-53 Designing Capacity for Configuration Databases Key Points There are two key configuration databases for a SharePoint 2010 server farm: • Configuration database. The configuration database holds the farm configuration data, such as number of Web applications, managed path configuration, and farm membership. The configuration database is typically less than 1 GB in size, but log file growth can be significant over time as you make more configuration changes to the farm. To mitigate the log growth, you should consider regular SQL Server backups of the configuration database or changing the database model to simple. The configuration database has a read- intensive usage profile. • Central Administration database. The Central Administration database holds the content for the Central Administration site collection. This is typically less than 1 GB in size, unless you deploy Microsoft PowerPivot in the farm. If you do this, the Central Administration database can grow significantly because of the PowerPivot data history settings. MCT USE ONLY. STUDENT USE PROHIBITED 3-54 Designing a Microsoft® SharePoint® 2010 Infrastructure Note: All SharePoint farms must have a configuration database and a Central Administration database. Note: PowerPivot tracks all of the information about who is using workbooks in SharePoint 2010 to provide a Workbook Activity chart. This information is stored in the Central Administration database; over time, this can grow to a significant volume. Additional Reading For more information about database types and descriptions in SharePoint 2010, see http://go.microsoft.com/fwlink/?LinkID=200861&clcid=0x409. For more information about databases used by SharePoint 2010 products, see http://go.microsoft.com/fwlink/?LinkID=201230&clcid=0x409. MCT USE ONLY. STUDENT USE PROHIBITED Planning for Performance and Capacity 3-55 Designing Capacity for Service Application Databases Key Points There are several service application databases, the size of which can range from small (less than 1 GB) to extra large (1 terabyte or larger). You must understand which of these databases can require large volumes of storage, and the reasons for the storage requirements, so that you can plan accordingly. The following table provides a brief description of these databases. Database Size guideline Read/write characteristics Description Usage and Health Data Collection 1 GB– more than 1 terabyte Very write-heavy This database stores health monitoring and usage data temporarily, and you can use it for reporting and diagnostics. MCT USE ONLY. STUDENT USE PROHIBITED 3-56 Designing a Microsoft® SharePoint® 2010 Infrastructure Database Size guideline Read/write characteristics Description Business Data Connectivity Less than 1 GB Very read-heavy This database stores external content types and related objects. Application Registry Service Less than 1 GB Read-heavy This database stores backward- compatible information for the Office SharePoint Server 2007 Business Data Catalog application programming interface (API). You typically only require this database in upgrade scenarios. Web Analytics Staging 1 GB–100 GB Variable This database temporarily stores unaggregated fact data, asset metadata, and queued batch data for the Web Analytics service application. Web Analytics Reporting 1 GB– more than 1 terabyte Variable This database stores aggregated standard report tables, fact data aggregated by groups of sites, date and asset metadata, and diagnostics information for the Web Analytics service application. User Profile Service Profile 1 GB–1 terabyte Read-heavy This database stores and manages users and associated information. It also stores information about a user's social network in addition to memberships of distribution lists and sites. User Profile Service Synchronization 1 GB–1 terabyte Approximately equal This database stores configuration and staging data when synchronizing profile data with directory services such as Active Directory. User Profile Service Social Tagging Up to 1 terabyte Read-heavy (approximate 50:1) This database stores social tags and notes that users create, along with their respective URLs. Managed Metadata 1 GB–100 GB Read-heavy (approximately 1,000:1) This database stores managed metadata and syndicated content types. . PROHIBITED 3-54 Designing a Microsoft SharePoint 2 010 Infrastructure Note: All SharePoint farms must have a configuration database and a Central Administration database. Note: PowerPivot tracks all. configuration databases for a SharePoint 2 010 server farm: • Configuration database. The configuration database holds the farm configuration data, such as number of Web applications, managed path. stores unaggregated fact data, asset metadata, and queued batch data for the Web Analytics service application. Web Analytics Reporting 1 GB– more than 1 terabyte Variable This database stores