Home > Articles > Databases > SQL Server

SQL Server Reference Guide

< Back Page 280 of 361 Next >

SharePoint 2007 and SQL Server, Part Three

Last updated Mar 28, 2003.

This is the third in a series on SharePoint and SQL Server. In this final article of the series, I’ll be building on the information I shared in the first and second articles, so if you haven’t had a chance to look those over, take a moment to do that now.

In this tutorial I’ll dig a little deeper into the steps you need to take for maintaining and monitoring the data layer for SharePoint 2007, and I’ll give you lots of references to go and learn more about the areas I’ve covered in this series and more.

Maintaining a SharePoint 2007 Database Server

SharePoint 2007 is an application, and as such should follow the basic principles of the maintenance that you would perform on any vendor’s database. Of course, that assumes you know how to maintain a vendor’s database, so let me stop here a moment and cover those basics.

General Steps for Maintaining a Vendor Database

The first step in maintaining a vendor database is to understand how the system works in general. You’ve been doing that for SharePoint 2007 by reading through these articles, and at the end of this article I’ll give you even more resources to read and understand. This is by far the most overlooked step in any shop that I see – the technical professionals understand their own technologies, but don’t take the time to read and understand how those technologies are implemented in the vendor’s architecture. SharePoint 2007 is no exception.

Once you understand how the vendor’s system works, you next need to understand the vendor’s recommendations for maintaining their database(s). If that material isn’t available, make a call, send an e-mail, contact the vendor any way you can. Even though it’s not your responsibility for their entire product, the data layer at your company is. So find out what you can, and read up on the documentation they make available.

In any vendor’s database, you should focus on at least these five areas:

Database Consistency
Statistics Updates
Index Optimizations
Backup Operations
Logging and automation

I have a series of articles on each of these here at InformIT, check the “Database Administration” links to learn more.

Specific Instructions for Maintaining a SharePoint 2007 Database

Beyond those general guidelines, SharePoint 2007 has various considerations for the maintenance of the database.

There is an excellent whitepaper here: http://technet.microsoft.com/en-us/library/cc262731(office.12).aspx. It lists just about everything you need to know to fully maintain your database system, so I won’t repeat the information here. However – before you read that information…

Understand that the SharePoint 2007 system is largely (although not completely) database-driven. Almost everything in the product is in some way stored in or tied to a database – recall that there are several types of databases SharePoint 2007 uses. That means that the maintenance is a holistic set of events. Let me explain why.

SharePoint 2007 is a combination of web pages, services, outside processes and database information. These are all tied together based on a timed event – in other words, when a user enters some data, makes a change to security, or administers the system one or all of these components might be altered. Whenever we think of backing up a system, it’s really a means to an end – the restore of that system. And to be consistent, that restore must be at a point-in-time.

This is the important part – simply backing up the database at a certain time interval isn’t enough. Unless the restoration of the backup is tied to the same timestamp as the backup of components like the web pages and outside processes, the system will be inconsistent.

Administrators of the SharePoint 2007 system have a web portal, PowerShell scripts as well as an administrative command they can use to defragment indexes and backup and restore the system. These are often “monolithic” (all at one time) type commands, which can severely lock and block the databases. So how do you resolve this issue?

You need to coordinate with them carefully. Understand how each function in their portal affects the database, and what needs to stay time-synched (such as the Config Database) and what can be backed up out-of-sequence with everything else (such as the Content Databases).

Maintaining the Indexes and Statistics should probably be under your control, and not the SharePoint 2007 administrator’s. This might be different in your shop, of course, and is less important if the databases are small, but in larger installations you should explain the locks and extra activity that might be taken by some types of Index maintenance, and work out the proper schedule for that between your teams.

As always – a full test restore of at least one Configuration and Content layout is essential. As I’ve said repeatedly, a DBA is only as good as their last successful restore.

As a final note for maintenance, Paul Randal and Kimberly Tripp have some great thoughts here as well: http://www.sqlskills.com/BLOGS/KIMBERLY/post/Database-Maintenance-Best-Practices-Part-I-e28093-clarifying-ambiguous-recommendations-for-Sharepoint.aspx.

Monitoring a SharePoint 2007 Database Server

For monitoring your SharePoint 2007 database, you have many options. You can use various third-party tools or the processes I describe in my Performance Tuning section of the guide on SharePoint databases.

The primary areas to focus on for monitoring SharePoint 2007 databases are:

Growth
I/O
Locks
TempDB

Your top performance issues in SharePoint 2007 database systems including out-of-band processes that might affect SQL Server are:

Indexing and Crawling
Backups
Profile Import
Timer Job (sync for users)
stsadm backup or restore ops
Heavy “list” operations (try to stay under 2000 items per container – use folders)
User Operations

Track all of these over time, and use the tools and processes I mentioned a moment ago to zero in on what you need to do to fix the issues you find. I’ll have more resources for you on Performance tuning in the References section below.

References for SharePoint 2007 and SQL Server

I normally don’t like to throw lots of “Link Lists” in these articles. I’d rather focus on distilling the information for you, but SharePoint 2007 is such a large, configurable product I’ll have to do that here. Hopefully you’ll be able to focus in on the areas that you are specifically interested in.