SQL Server Reference Guide

Data Management Objects: Database Maintenance

Last updated Mar 28, 2003.

Are you one of those people who likes to clean? I have to admit, I'm a bit of a neat-freak. When I went into the military, I was the only one in basic training that already knew how to make hospital corners on my bunk.

I will allow, however, that there are people in the world who aren't quite so... "taken" with maintenance. While that's fine for your house or your cubicle, it's another matter for your SQL Server. For the professional DBA, maintenance is a must.

I've covered database maintenance techniques in other articles, and explained that the best thing to do if you encounter a system is to run the SQL Maintenance Wizard. This series of screens guides you through the three parts of database maintenance: make it go, back it up, and make it go fast.

There are times when the standard maintenance wizard isn't appropriate. Perhaps you want to space out the maintenance differently, or apply some settings to multiple databases but different settings for others. To solve those types of problems, you can learn the various maintenance commands, and run them from inside a T-SQL Script.

If you're delivering a product based on MSDE, or to provide a custom interface for maintenance, you could use the DMO library that we've been studying in our current series. In this installment of our series on SQL Data Management Object (SQL-DMO) programming articles I show you a complete program that performs basic maintenance.

This type of article is meant to be a tutorial. You don't necessarily want to plop this code onto your server as-is and run it. It's important to evaluate what the code is doing and how it works so that you can change it to be exactly what you want. After all, that's the point of going to the trouble of learning the process – so that you can make it your own.

The techniques I show here work in three areas: the server, the database, and various database objects. In this example, I show you how to back up a database, run table checks, and check the indexes. There are several other methods to which ou have access that perform finer-grained maintenance or work with other objects in the database.

Let's take a look at the complete code:

' DMOMaintenance.vbs
' Created:     1/10/04 - Buck Woody
' Change Log:  

' Variables
  Dim oServer    ' SQL Server object
  Dim oDatabase  ' Database object
  Dim oTable    ' Table object
  Dim oIndex    ' Index Object
  Dim ReturnVal  ' Object to hold the user's choice
  
'Provide feedback to the user, allow them to bail
  ReturnVal = MsgBox("Checking Databases, Tables and Indexes. " _
  & "Click Yes to continue, No to Cancel.", _
  VBYesNo, "DMO Maintenance")

If ReturnVal = VBYes then

  MsgBox "Maintenance has started." _
  & " You'll receive a confirmation when" _
  & " the maintenance is complete. Click" _
  & " OK to begin.", VBOK

  ' Create and connect to a server
    Set oServer = CreateObject("SQLDMO.SQLServer")
    oServer.LoginSecure = True
    oServer.Connect "(local)"

  ' Perform Server maintenance
  ' Place any server maintenance you want here.

  ' Perform database maintenance
  ' Get a database. Could prompt here or use a 
  ' collection to do them all.
    Set oDatabase = oServer.Databases("pubs") 

  ' Backup the database. Use an in-line
  ' Backup object method.
  Dim oBackup
  Set oBackup = CreateObject("SQLDMO.Backup")
  oBackup.Action = SQLDMOBackup_Database
  oBackup.Database = "pubs"
  oBackup.Files="c:\temp\pubs.bak"
  oBackup.SQLBackup oServer


  ' Perform Table maintenance
    oDatabase.CheckTables()
    oDatabase.UpdateIndexStatistics( )
    For each oTable in oDatabase.Tables 
      ' Don't really need this,
      ' since we did it three lines above.
      ' Just another method if you want
      ' to do it table by table.
      oTable.UpdateStatistics()

    ' Perform Index maintenance
      For each oIndex  in oTable.Indexes
        IndexList = IndexList & "Index Checked: " & oTable.Name & " - " & oIndex.Name & VBCRLF
        oIndex.CheckIndex()
      Next
    Next

  ' Notify the user you're done.
    MsgBox "Maintenance complete. See log file for results"
    ' Note that we didn't really make a log. We'll do that later.

  ' Clean up.
  Set oTable = Nothing
  Set oDatabase = Nothing
  Set oServer = Nothing

End If

If you've been following along with the previous articles in this series, most of the code looks familiar to you. I've followed my standard coding process of laying out the requirements, creating comments as pseudo-code, and then coded my comments.

The overall structure is what might be the most interesting part. Notice that it follows this basic outline:

1. Declare the variables

2. Offer the user a chance to leave the program

3. Connect to a server

4. Back up the database

5. Perform maintenance

• Server

• Database

• Objects

6. Close the objects

Note the progression here, because I think it's important. Before you get very far at all in a maintenance program, or any program that has the potential to materially affect a physical structure, offer the user the chance to leave the program. Anything less might leave you morally and perhaps legally liable.

Next, remember the physician's code: "First, do the patient no harm." I've learned (sometimes the hard way) that before you touch anything in the database you should make sure that the system is backed up properly. If that's not feasible, it's not a bad idea to include a "sign-off" process for the user to indicate that they've performed a backup, in which you query the operating system to determine the current user and stamp it in a file somewhere.

Unfortunately I've had the opportunity to exercise this CYA effort and that file was the only protection I had against a "he said, she said" event. Here's the full story.

At a client's site, the database was so large that a full backup each time the maintenance was run was not possible. The code I wrote warned the DBA that the maintenance might be destructive, and prompted the user to check a box to indicate that he or she had taken proper backups regularly. The user indicated he had (he hadn't) and during the maintenance the power failed to the unit. He had no power protection (mistake #2) and the maintenance left the database corrupted.

Instead of contacting me, he ran the maintenance program again, which caused even more damage. When he finally called we had no recourse but to restore the last backup – which he hadn't taken for three months. When the firm's management became involved, the blame was placed on the maintenance code until I pointed out that the program required a current backup. The DBA denied seeing that screen until I told them where to find the file with his logon name and sign-off in it, and that settled the matter.

So learn from this valuable lesson. Make sure you give the user as much information as you can to guarantee success. However, always take steps to protect yourself.

The next step is to begin the maintenance. Even though it isn't used, I've got a section marked out for server maintenance, and then I progress from the larger objects to the smallest.

You'll also notice two methods to perform a table check. You only need one, but the first performs a blanket check on all tables and the second provides a mechanism to exclude tables with an If oTable.Name "SomeName" Then... block.

If you run this code, it seems to "disappear" while the maintenance completes. This is due to a limitation with scripting, which you can avoid by using ASP or a full coding language such as Visual Basic to provide feedback to the user. With scripting, we don't have easy access to progress bars, information screens and the like.

For production code you'll want to add selection methods for the specific servers, databases, and objects you (or your users) want to deal with. In any event, the process is the same.

I mentioned in the comments that the user should check a logging file. This leaves a segue into my next article, in which I'll lay out this same code again, with the addition of a logging component. Scripting limitations will rear their ugly heads again, but I'll explain next time how you can create your own log files from your code. See you then!

Online Resources

The full documentation for the SQL Server Object Library can be found here.

InformIT Tutorials and Sample Chapters

If you're interested in learning more about programming, you should start with object-orientation. There's a great sample chapter called Software Architecture: Basic Training By Raphael Malveau and Thomas J. Mowbray that you can read for free here at InformIT.