Measure Value	Numeric Value
Yes	1
No	0

Note:

By default, the measure reports the Measure Values listed in the table above to indicate the usage state of this content database. However, in the graph of this measure, the same will be represented using the numeric equivalents only.

Content databases of up to 4 TB are supported when the following requirements are met:

• Disk sub-system performance of 0.25 IOPs per GB. 2 IOPs per GB is recommended for optimal performance.
• You must have developed plans for high availability, disaster recovery, future capacity, and performance testing.

You should also carefully consider the following factors:

• Requirements for backup and restore may not be met by the native SharePoint Server backup for content databases larger than 200 GB. It is recommended to evaluate and test SharePoint Server solutions to determine the best solution for your specific environment.
• It is strongly recommended to have proactive skilled administrator management of the SharePoint Server and SQL Server installations.
• The complexity of customizations and configurations on SharePoint Server may necessitate refactoring (or splitting) of data into multiple content databases. Seek advice from a skilled professional architect and perform testing to determine the optimum content database size for your implementation. Examples of complexity may include custom code deployments, use of more than 20 columns in property promotion, or features listed as not to be used in the over 4 TB section below.
• Refactoring of site collections allows for scale out of a SharePoint Server implementation across multiple content databases. This permits SharePoint Server implementations to scale indefinitely. This refactoring will be easier and faster when content databases are less than 200 GB.
• It is suggested that for ease of backup and restore that individual site collections within a content database be limited to 100 GB.

Compare the value of this measure across content databases to identify that database which is eroding the disk space of the SQL server.

To curb this growth, you may want to consider the following measures:

• Use an ootb Record Center as an archive for old content: The users must manually send each document to the RC using e.g. move and leave a link; note that only the latest major version with metadata is kept - all version history is lost. The information management policies supported by SharePoint for retention and disposition can be used to automate the cleanup. As the RC has its own content databases, the live collaboration databases will grow slower or even shrink as outdated information is moved to the archive. Keeping the live databases small ensures shorter recovery time; while the recovery time for the archived content can be considerable, but not business critical. Search must be configured appropriately to cover both live and archived content.
• Use a third-party archiving solution for SharePoint. This has the same pros & cons as the previous option, but the functionality is probably better in relation to keeping version history and batch management of outdated content. Search must be configured appropriately to cover both live and archived content.
• Use a third-party remote blob storage (RBS) solution for SharePoint so that documents are registered in the database, but not stored there. This gives smaller content databases, but more complicated backup and recovery as the content now resides both in databases and on disk. Provided that you don't lose both at the same time, the recovery time should be shorter. Search will work as before, as all content is still logically in the “database”.
• Use powershell scripts or other code to implement the disposition of outdated content. The script can e.g. copy old documents to disk and delete old versions from the content database; the drawback being that all metadata will be lost and there is no link left in SharePoint. The databases size will shrink as data is actually deleted, and backup and recovery is more complicated as content is now both in the database and on disk (same as for option C). Search can be configured to also crawl and index the files on disk, but content ranking will suffer as the valuable metadata is lost.
• Use powershell scripts or other code to implement the disposition of outdated content. The script can e.g. copy old documents to disk and delete old versions from the content database; the drawback being that all metadata will be lost and there is no link left in SharePoint. The databases size will shrink as data is actually deleted, and backup and recovery is more complicated as content is now both in the database and on disk.Search can be configured to also crawl and index the files on disk, but content ranking will suffer as the valuable metadata is lost.

If the Growth_rate measure is increasing consistently, you may want to check the variations in the value of this measure over the same time period to figure out whether/not the existence of too many orphan sites is contributing to the growth in the size of the content database. If so, you may want to cleanup the orphan sites to right-size your database and to ensure optimum performance.

These limits relate to speed of upgrade. The larger the number of site collections in a database, the slower the upgrade with respect to both database upgrade and site collection upgrades.

The limit on the number of site collections in a database is subordinate to the limit on the size of a content database that has more than one site collection. Therefore, as the number of site collections in a database increases, the average size of the site collections it contains must decrease.

Exceeding the 5,000 site collection limit puts you at risk of longer downtimes during upgrades. If you plan to exceed 5,000 site collections, Microsoft recommends that you have a clear upgrade strategy to address outage length and operations impact, and obtain additional hardware to speed up the software updates and upgrades that affect databases.

When a user deletes an item, the item is automatically sent to the first-stage Recycle Bin. By default, when an item is deleted from the first-stage Recycle Bin, the item is sent to the second-stage Recycle Bin.

A high value for this measure could indicate that a large amount of deleted data resides in the second stage recycle bin, unnecessarily consuming disk space and increasing the size of the content database.

Every site collection has a second stage recycle bin and the size of this bin must not grow beyond 50 percent of the quota set for that site collection. You may want to reduce this percentage to ensure that the recycle bin does not grow too unwieldy and impact the size and performance of the content database.

Note: