次の方法で共有


SQL Server Index Maintenance

After working on a problem where the transaction logs for a large database were filling to sizes larger then the actual database every night it turned out to be a server maintenance plan that rebuilt and reorganized indexes every night.  While working on designing a custom plan that would only rebuild or reorganize when actually necessary I found many references out on the internet.  None of the scripts I found out there really accomplished what I was after.

Starting with finding the indexes that need maintenance done on them I eventually came up with this SQL:

 select 
     sch.name [schema_name]
     ,obj.name [table_name]
     ,idx.name [index_name]
     ,idx.type_desc [index_type]
     ,part.used_page_count*8 [used_kb] --each page is 8k
     ,part.row_count
     ,CONVERT(DECIMAL(9,2),frag.avg_fragmentation_in_percent) [fragmentation]
     from sys.dm_db_partition_stats part
         join sys.objects obj on part.object_id = obj.object_id
         join sys.schemas sch on obj.schema_id = sch.schema_id
         left join sys.indexes idx on part.object_id = idx.object_id and part.index_id = idx.index_id
         left join sys.dm_db_index_physical_stats(db_id(),null,null,null,null) frag on part.object_id = frag.object_id
             and part.index_id = frag.index_id
     where 
         obj.is_ms_shipped = 0
         and frag.page_count > 100
     order by [schema_name],[table_name],[index_name];
 .csharpcode, .csharpcode pre
{
  font-size: small;
   color: black;
   font-family: consolas, "Courier New", courier, monospace;
   background-color: #ffffff;
  /*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt 
{
   background-color: #f4f4f4;
  width: 100%;
    margin: 0em;
}
.csharpcode .lnum { color: #606060; }

This gave me a nice view to see how big the tables were, and where the fragmentation problems were.  We decided that if it's less800KB (based on frag.page_count) we didn't care about the fragmentation.

Armed with this info it was a matter of basically executing the rebuild or reorganize depending on your preference.  I decided to use a in memory table and just did a insert-select into it.  My temp table looked like:

 declare @IndexStatus table(
     schema_name varchar(250)
     ,table_name varchar(250)
     ,index_name varchar(250)
     ,index_type varchar(250)
     ,used_kb int
     ,row_count int
     ,fragmentation decimal(9,2));

From there I just took the results into a cursor and executed dynamic sql.  My logic was <10% fragmentation I didn't care, greater then 30 gets a rebuild, 10-30 gets a reorganize

 declare maintCursor cursor for
     select 'alter index ['+[index_name]+'] on ['+[schema_name]+'].['+[table_name]+']', fragmentation 
         from @IndexStatus 
         where fragmentation > 10;
  
 declare @stmt varchar(max);
 declare @frag float;
  
 open maintCursor
 fetch next from maintCursor into @stmt, @frag
 while @@fetch_status = 0
 begin
     if @frag > 30
         set @stmt = @stmt+' rebuild'; --if this is enterprise you can add 'with (online=on)'
     else
         set @stmt = @stmt+' reorganize';
     
     print (@stmt)
     exec (@stmt)
     fetch next from maintCursor into @stmt, @frag
 end
 close maintCursor
 deallocate maintCursor

Comments