DPMDB Maintenance Part 1: Database consistency check and your DPMDB

~ Chris Butcher| Senior Support Escalation Engineer

Hi folks, Chris Butcher here again with another DPM blog entry for you. I’ve had a few questions recently about upkeep on the DPM database, and while most of the time questions start about maintaining the size, once the conversation gets going it expands well beyond that. I have talked to several people and in the end, this really can be grouped into 4 distinct pieces, so I decided it was time we covered these pieces in depth.

To that end, I am writing a series of three blog posts to cover three areas and will point to an existing post for the final piece. This will be broken down into an approach that starts by checking the database consistency, followed by a look at fragmentation (or eliminating it) to optimize performance. Third, we make sure there is no extra growth and that it is sized optimally, and lastly, we talk about backing up the DPMDB in order to have a good copy available should it ever be needed.

I decided to cover this in separate posts because A) the great Mike Jacquet has already written a great article on protecting/backing up your DPMDB, and B) no one wants to read a 100 page blog post. It just makes more sense to put these into smaller consumable chunks, plus it also helps that each action can be done alone and none are dependent on any other steps.

So with all that said, we can tackle the first task in the chain and that is checking for corruption in the DPMDB. While this sounds super vital, and it can really cause issues, it oddly isn’t something we see too much of in the DPM world. So, this is to say it is not a big problem. That’s not to be confused with “It is not a problem.” I have seen instances where there was corruption in the database, it’s just that this is a very rare situation.

Regardless, if you want to run a database consistency check (DBCC) against your DPMDB, I will cover some options to do that. This is addressed from the angle of a person who is familiar with SQL, but far from DBA. Whether you simply want to manually check the database from time to time or set up a recurring job to run, the process is very similar. The difference will be called out in the steps below.

These operations will be done through the SQL Management Studio where your DPMDB resides. If you are not familiar, note that you may have to run SQL Management Studio as administrator. If you don’t do this, it may fail to connect to SQL because of permissions.

When SQL launches, it should automatically fill in the servername\instance name as shown below.

If this isn’t populated for you then you can open DPM to find out this information. By clicking on the About DPM button, it will open up and towards the bottom give you the name of the SQL server, the SQL instance name and the DPMDB name in the format: SQLServerName\SQLInstanceName\DPMDBName

To connect in SQL, you will simply need the SQLServerName\SQLInstanceName.

With a connection to SQL, we will now walk through the steps to run DBCC.

1. Expand your SQL instance and then expand Management until you see Maintenance Plans. Right click Maintenance Plans and select Maintenance Plan Wizard. This will walk us through what we need to simply run DBCC.

2. Once the Maintenance Plan Wizard opens you will first give this job a name that is easy to recognize. You then will decide if you want to have this run on a regular basis or manually run it on demand. To run on demand, just click Next. If you want to schedule it, click Change. Set the schedule according to what works best for you. I have a note on frequency at the bottom of the page.

3. On the next page, simply select the box to Check Database Integrity and then click Next on the next two screens.

4. To define the task, pull down the menu to <Select on or more>. This will bring up a new screen where you will select your DPMDB by name.

5. Finally, select the location where you want a report written. You will need to remember this, as running the DBCC itself will output all information to this file.

Now that the job is set up, you can either let the job run on schedule and check the log file after each run, or run it manually. To do this, simply expand the same Maintenance Plans item and right click on the job you created and choose Execute.

Either way, once it is run, be sure to review the log created as specified in step 5 above. If it shows any errors, you will then have to investigate accordingly to determine the next steps, as there is no way to cover all of the possible outcomes and their corresponding remedies.

The standard report will only report success and little else if there are no issues found.

Frequency

How often is the right amount to run this? That’s a great question with no real answer. This can be researched and set according to your comfort level but I will say this about DPMDB: From the support view of things, we very rarely have seen a call that was due to actual database corruption. So, for the suggestions which might say to do this daily, I think it is overkill for sure. When you factor in the process intensive nature of this, I think that using something along the line of a quarterly (minimum) to annual (maximum) schedule is probably where you should initially target things.

Finally, if you do schedule this to run automatically, it is ideal to avoid midnight to 3 AM. This is when DPM will have house cleaning jobs run. While it most likely will only affect performance of these jobs, it is best to stay away from this time frame to be sure we don’t run into any conflicts.

You can continue on to Part 2 in this series here.

Chris Butcher| Senior Support Escalation Engineer | Microsoft GBS Management and Security Division

Get the latest System Center news onFacebookandTwitter: