• subscribe
October 30, 2008 12:00 AM

Three-In-One Database Maintenance Solution

Back up databases, check their integrity, and optimize indexes
SQL Server Pro
InstantDoc ID #100178
Downloads
100178.zip

The IndexOptimize stored procedure incorporates these concepts into its logic. This stored procedure categorizes indexes into six groups based on their level of fragmentation (high, medium, or low) and whether LOB columns are present (LOB) or not (NonLOB). The parameters that represent these groups are as follows:

  • @FragmentationHigh_LOB represents indexes with a high fragmentation level and LOB columns.
  • @FragmentationHigh_NonLOB represents indexes with a high fragmentation level and no LOB columns.
  • @FragmentationMedium_LOB represents indexes with a medium fragmentation level and LOB columns.
  • @FragmentationMedium_NonLOB represents indexes with a medium fragmentation level and no LOB columns.
  • @FragmentationLow_LOB represents indexes with a low fragmentation level and LOB columns.
  • @FragmentationLow_NonLOB represents indexes with a low fragmentation level and no LOB columns.

IndexOptimize uses the avg_fragmentation_in_ percent column in the sys.dm_db_index_physical_ stats dynamic management view (DMV) to obtain the percentage of fragmentation in each index. Using the threshold limits you set in the @Fragmentation- Level1 (lower threshold) and @FragmentationLevel2 (upper threshold) parameters, it places each index in the appropriate group. Indexes with fragmentation levels higher than the upper threshold go into one of the high fragmentation groups. Indexes with fragmentation levels at or between the two thresholds go into one of the medium fragmentation groups. Indexes with fragmentation levels under the lower threshold go into one of the low fragmentation groups.

IndexOptimize can also place indexes in one of the low fragmentation groups based on their page count. Indexes under the size specified in the @Page- CountLevel parameter go into one of the low fragmentation groups.

For each group, you can select one of the following actions:

  • 'INDEX_REBUILD_ONLINE'—Tells the stored procedure to rebuild the indexes online. (You need to be running the Enterprise or Developer Edition of SQL Server 2008 or SQL Server 2005 to use this option.)
  • 'INDEX_REBUILD_OFFLINE'—Tells the stored procedure to rebuild the indexes offline.
  • 'INDEX_REORGANIZE'—Tells the stored procedure to reorganize the indexes.
  • 'INDEX_REORGANIZE_STATISTICS_ UPDATE'—Tells the stored procedure reorganize the indexes and update the statistics.
  • 'STATISTICS_UPDATE'—Tells the stored procedure to update the statistics.
  • 'NOTHING'—Tells the stored procedure to do nothing to the indexes.

So, for example, the EXECUTE statement in Listing 1 tells IndexOptimize to rebuild indexes that are more than 30 percent fragmented, online if possible (no LOBs). If these highly fragmented indexes have LOBs, an offline rebuild is to be done. Indexes with a fragmentation level between 5 percent and 30 percent are to be reorganized and have their statistics updated. Indexes that are less than 5 percent fragmented or have fewer than 1,000 pages aren’t to be touched. IndexOptimize uses T-SQL’s ALTER INDEX command to rebuild and reorganize indexes.

How to Check Databases’ Integrity
The DatabaseIntegrityCheck stored procedure uses T-SQL’s DBCC CHECKDB command to perform integrity checks. Using this stored procedure instead of the Database Maintenance Plan Wizard’s Check Database Integrity Task might mean that you don’t have to install the hotfix for bug 50001012. (The Check Database Integrity Task can lose database context under certain circumstances in SQL Server 2005 builds 3042 through 3158—see support.microsoft.com/kb/934458.)

The EXECUTE statement you use to run DatabaseIntegrityCheck is simple. You just need to specify the databases you want to check. For example, the statement

EXECUTE dbo.DatabaseIntegrityCheck
@Databases = 'USER_DATABASES'

checks the integrity of all user databases.

All Types of Information Are Readily Available
The DatabaseBackup, IndexOptimize, and Database- IntegrityCheck stored procedures have thorough logging and error handling. The start and end time, command text, and output are logged for each command in the stored procedures. Additional information is logged for the IndexOptimize’s ALTER INDEX command, as Figure 1 shows. All command information is immediately written to a log file. You can find information about how the stored procedures handle errors in MaintenanceSolution.sql’s documentation at http://ola.hallengren.com/Documentation.html. The documentation also includes information about how to use each stored procedure as well as answers to frequently asked questions.

 



ARTICLE TOOLS

Comments
  • BRIAN
    3 years ago
    Feb 02, 2009

    I work on a moderate size DB.
    • 12 million inserts and 10 million updates in a 12 hour workday.
    • 10 million deletes and Index maintenance at night.

    Our largest table ( 660,000,000 rows)
    • 8.5 million inserts
    • 8 million updates
    • 7.5 million deletes daily.
    • Organized by time.
    • Fragment about 2% daily.

    We were running an index maintenance regime like you propose.
    On the largest table, ran a index defrag each night, taking 6 hours.

    One day we ‘accidently’ did a offline rebuild. Took 30 minutes. Sweet.

    Funny thing all our queries got faster. I mean noticeable faster.

    We realized it was because the defrag only worked on leaf nodes. Over a period of two years the BTree index nodes got horrible unbalanced.

    Insert, update and select activity was occurring at the most recent entries and delete and the lest recent entries. These pages became 50% fragmented due to page splits, while daily table fragmentation was around 2%.

    We kept reducing the point at which we did a rebuild, till we found the point at which it made no difference in performance. 4%.

    We could have done the rebuild every three days, but decided to do it daily. If it failed for any reason, we had few days to fix it before customers noticed. A nice side effect is they stopped worrying when I’d want to take a few days off (I’m the only full time DBA here)

  • Karen
    4 years ago
    Dec 19, 2008

    I'm glad that you found the article useful. I'll pass along your comment to Ola. I'm sure he'll appreciate it!


    Karen Bemowski, senior editor
    SQL Server Magazine, Windows IT Pro

  • Alan
    4 years ago
    Dec 18, 2008

    probably learned more by reading this article than all the Microsoft help files on the subject, although I was glad I read them first - it gave me some background - but this really put things into my hands! Thanks! Very useful tool.

You must log on before posting a comment.

Are you a new visitor? Register Here