Home > Index Fragmentation > SQL Server Index Fragmentation and Its Resolution

SQL Server Index Fragmentation and Its Resolution

It’s really easy to answer the interviewer question “How to know index fragmentation?” and “what you will do to resolve the issue?”

It’s always a situation with Production DBA’s how to find index fragmentation and in case they are lucky enough to find out they are confused its internal fragmentation or external fragmentation. What to do to reduce   index fragmentation it should be Index Organize or Rebuild is a big challenge.

DBA don’t put much effort that rebuilding the indexes can be more expensive in an OLTP environment and affect the system inadequately. Fragmentation can cause serious performance issues and it’s vital to understand how it affects the performance.

Fragmentation can cause queries run slower due to more disk IO because of data page splitting

If the table size is too large and you decide to rebuild the index (online or offline), it can be a expensive decision as rebuilding index will make the system more slow while rebuilding of index is in progress.

In SQL Server there are two types of index fragmentation internal fragmentation and external fragmentation.

Internal Fragmentation: Occurs if the percentage of free space in index pages is below 75%.
This doesn’t mean that index which have fill factor or more then 80% doesn’t come in this category.

External Fragmentation: External fragmentation occurs when an index leaf page is not in logical order. When an index is created, the index keys are placed in a logical order on a set of index pages. As new data is inserted into the index, it is possible for the new keys to be inserted in between existing keys. This may cause new index pages to be created to accommodate any existing keys that were moved so that the new keys can be inserted in correct order.

First we will figure out the indexes on tables or on all objects of a database.

SELECT id,indid,dpages,OrigFillFactor,name Ind_Name FROM sys.sysindexes

WHERE  id=OBJECT_ID(‘__DROPRO’)

————————————————————————————————

id indid dpages OrigFillFactor Ind_Name
518565927 1 0 0 Colid_Clu
518565927 2 0 0 NonClustered_CheckFrag

At the movement there are no records associated with the table. So, there will not be any fragmentation.

DECLARE @IndexFrag TABLE 

(

ObjectName varchar(MAX),

ObjectIndex varchar(max),

Avg_fragmentation_in_percent decimal,

avg_page_space_used_in_percent decimal

)

INSERT INTO @IndexFrag

(

ObjectName,ObjectIndex,Avg_fragmentation_in_percent,avg_page_space_used_in_percent)

SELECT object_name(dt.object_id)ObjectName,si.name IndexName,

dt.avg_fragmentation_in_percent,dt.avg_page_space_used_in_percent

from

(

SELECT    object_id,index_id,avg_fragmentation_in_percent,avg_page_space_used_in_percent

FROM sys.dm_db_index_physical_stats(DB_ID(),NULL,NULL,NULL,’DETAILED’) where index_id<>0

)dt INNER JOIN

sys.indexes si ON si.object_id=dt.object_id and si.index_id=dt.index_id

Order By dt.avg_fragmentation_in_percent asc

SELECT * FROM @IndexFrag where ObjectName=’__DROPRO’ order by ObjectIndex

 

As u can see the empty table doesn’t have fragmentation and no data pages associated with it.

I have done few hundreds of transaction on the table with insert, update and delete.

Checking fragmentation after the transactions

SELECT id,indid,dpages,OrigFillFactor,name Ind_Name FROM sys.sysindexes

WHERE  id=OBJECT_ID(‘__DROPRO’)

id Indid dpages OrigFillFactor Ind_Name
518565927 1 666 0 Colid_Clu
518565927 2 554 0 NonClustered_CheckFrag

DBCC SHOWCONTIG(‘__DROPRO’)

DBCC SHOWCONTIG scanning ‘__DROPRO’ table…

Table: ‘__DROPRO’ (518565927); index ID: 1, database ID: 7

TABLE level scan performed.

– Pages Scanned…………………………..: 666

– Extents Scanned…………………………: 89

– Extent Switches…………………………: 347

– Avg. Pages per Extent……………………: 7.5

– Scan Density [Best Count:Actual Count]…….: 24.14% [84:348]

– Logical Scan Fragmentation ………………: 99.85%

– Extent Scan Fragmentation ……………….: 66.29%

– Avg. Bytes Free per Page…………………: 2336.0

– Avg. Page Density (full)…………………: 71.14%

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Avg_fragmentation_in_percent has increased above 15 %( A value between 5-30% indicates moderate fragmentation, while any value over 30% indicates high fragmentation) it means the physical order of the index pages is not matching with the logical order.

The Avg_page_space_used_in_percent is another value that it is worth to look closely. This value represents the amount of spaced used in the indexes. A value below 75% is usually associated to internal fragmentation.

Reference Values (in %) Action SQL statement
Avg_fragmentation_in_percent > 5 AND < 30 Reorganize Index ALTER INDEX REORGANIZE
Avg_fragmentation_in_percent > 30 Rebuild Index ALTER INDEX REBUILD

As we can see the Avg_fragmentation_in_percentage is more than 30% we will go for Rebuilding of indexes

USE [vcvcxvcx]

GO

ALTER INDEX [Colid_Clu] ON [dbo].[__DROPRO] REBUILD PARTITION = ALL

WITH

(

PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, ALLOW_ROW_LOCKS  = ON,

ALLOW_PAGE_LOCKS  = ON, ONLINE = ON, SORT_IN_TEMPDB = OFF

)

GO


Categories: Index Fragmentation
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: