Microsoft SharePoint Content Database Policies in DocAve Governance Automation Service Pack 5
![author](/_image?href=https%3A%2F%2Fassets.avepoint.com%2Fupload%2Fblog%2Fauthor-headshot%2Fjohn-p-150x150.jpg&w=70&h=70&q=90&f=avif)
By John Peluso
![feature image](https://assets.avepoint.com/upload/blog/featured-image/default-feature-image.png)
As we have seen from previous posts in this series, many enhancements in DocAve Governance Automation Service Pack (SP) 5 are visible to and especially useful for SharePoint end users. Today, in the final post of the series, we will focus on a new feature that end users will never see, but SharePoint administrators will find quite valuable: Content Database Policies.
The Problem: Managing SharePoint Content Databases Using Native Tools
Every new site collection created in SharePoint stores user and system content (documents, pages, icons etc.) within a Microsoft SQL Server database. This database is referred to as the content database. Every SharePoint web application has one or more content database defined in the web application settings. If only one content database is registered, then all site collections created in the web application will go into that same content database. If more than one database is defined in the web app, SharePoint will automatically place the newly created site collection in a content database – a decision based primarily on which of the registered content databases has the biggest difference between the number of site collections currently in the database, versus the configured maximum number of site collections allowed in the database.
Unfortunately, this native process of locating site collections into databases has two big problems for many organizations. First, it lacks the ability to define a maximum size that a given content database can grow. Large content databases can present organizations with many potential problems – they take longer to back up and restore, they take longer to update during a SharePoint version upgrade, and, by putting many site collections into a single database, lack of access to the database (caused by maintenance or failure) means that large scopes of users are unable to access their site collections. Smaller content databases are often preferred because they solve the problems above – yet, natively, SharePoint only looks at the number of site collections when making a decision about where to place the next site collection, not the size of the databases.
The second potential issue with SharePoint’s native content database management capabilities is lack of flexibility – either you tell SharePoint which content database to use when you create the site collection or you let SharePoint put the site collection where it wants. There is no capacity to ensure that sites of a particular type will always exist in a particular database (this has benefits if you want to define your backup Service Level Agreements by site type or if you want to make sure that all of a department’s sites are migrated to a new SharePoint version at once) unless you choose to do so for every individual site collection created.
As is often the case, the lack of tooling in SharePoint to allow administrators to address these concerns means that policies around maximum database size and site collection placement require inefficient, manual efforts to enforce. Administrators have to be deliberate when creating new site collections and also need to closely monitor the size of ever-growing databases to ensure compliance with their defined policies.
The Solution: Governance Automation Content Database Policies
In Governance Automation SP 5, we are introducing the Content Database Policy as a way to automate the placement and maximum size of your SharePoint content databases. Content database policies will not only ensure that size and placement requirements are met, but they also allow for the automatic creation of new content databases as needed to ensure the databases stay in compliance with your sizing requirements as new site collections are created.
[caption id="attachment_3573" align="alignnone" width="629"]
Content Database Policy settings in DocAve Governance Automation.[/caption]
These new policies are fairly easy to understand, yet extraordinarily powerful. A Content Database policy has a few simple elements:
Mapping a Content Database Policy to a Site Collection Policy in DocAve Governance Automation.[/caption]
Governance Automation’s purpose is to automate the enforcement of defined governance policies, reducing the risk of human error and maximizing administrative efficiency. As you can see, this concept is embodied by the new Content Database Policies in Governance Automation SP 5. We have taken a stated risk – content databases that are too big – and created a fully automated and managed process for ensuring that the policies formulated to mitigate that risk can be efficiently and proactively enforced.
I hope you have enjoyed this blog series on some of the most exciting new features of Governance Automation SP5. There are many more new features and enhancements in this release, so I encourage you to check out the release notes and user guide to learn more. Additionally, please be sure to visit our Governance Automation product page for more information as well as a 30 day free trial of the product.
![Content Database Policy settings in DocAve Governance Automation.](https://assets.avepoint.com/upload/blog/2014/09/Figure-1.png)
- Do you want to set a maximum size for the content database?
- Do you want to set a maximum density (e.g. number of site collections) for the database?
- How do you want to name the content databases that are created as a result of this policy? (This allows you to easily identify groups of databases that belong together for backup and upgrade purposes.)
![Mapping a Content Database Policy to a Site Collection Policy in DocAve Governance Automation.](https://assets.avepoint.com/upload/blog/2014/09/Figure-2.png)
![author](/_image?href=https%3A%2F%2Fassets.avepoint.com%2Fupload%2Fblog%2Fauthor-headshot%2Fjohn-p-150x150.jpg&w=70&h=70&q=90&f=avif)
By John Peluso
John Peluso is AvePoint’s Chief Technology Officer. In this role, he aligns the Company’s technology and product roadmaps to grow AvePoint’s market share, and accelerate the ideation, development, and launch of innovative software products tailored to anticipate customer needs. Prior to this role, John held multiple leadership roles over his 13-year tenure at AvePoint, including Chief Product Officer, SVP of Product Strategy, Director of Education, and Chief Technology Officer, Public Sector.
Before joining AvePoint, John served in a variety of technology and business roles at New Horizons Northeast and New Horizons of Central and Northern NJ. He earned his undergraduate degree from The New School.
View all posts by John Peluso