2

If I execute the following:

SELECT dbschemas.[name] as 'Schema', 
dbtables.[name] as 'Table', 
dbindexes.[name] as 'Index',
indexstats.alloc_unit_type_desc,
indexstats.avg_fragmentation_in_percent as avg,
indexstats.page_count
FROM sys.dm_db_index_physical_stats (DB_ID('dbname'), NULL, NULL, NULL, NULL) AS indexstats
INNER JOIN sys.tables dbtables on dbtables.[object_id] = indexstats.[object_id]
INNER JOIN sys.schemas dbschemas on dbtables.[schema_id] = dbschemas.[schema_id]
INNER JOIN sys.indexes AS dbindexes ON dbindexes.[object_id] = indexstats.[object_id]
AND indexstats.index_id = dbindexes.index_id
WHERE indexstats.database_id = DB_ID('dbname')
ORDER BY indexstats.avg_fragmentation_in_percent desc

It shows fragmentation level. I then ran Ola Hallengren's index optimise script which obviously reduces indexes.

If I run the query again it now shows high fragmentation in tables without an index e.g:

Schema  Table       Index   alloc_unit_type_desc   avg                 page_cont
dbo     tablename   NULL    IN_ROW_DATA            99.4362934362934    8176

Should I be concerned by these?

Anything I can do?

Anything I should be doing?

We are experiencing performance issues. I am aware that 2008 is not ideal and that is being addressed.

The datafile is also showing as 220gb but the actual space used is 140gb.

  • 3
    "Performance issues" is a huge area. Maybe you can pinpoint a specific query or table that's the problem and troubleshoot it. If it's the heap, then consider adding a clustered index in accordance to the queries and operations in which it's involved. – EzLo Apr 11 at 11:37
  • 1
    I recently had a case with a heap with lots and lots of empty space. Only some 6000 rows and a simple SELECT * without WHERE took several minutes. The problem was humongous amount of empty space. This is one of the downsides you can encounter with heaps. I just created a clustered index (on a suitable column) and all was normal. – Tibor Karaszi Apr 12 at 6:40
7

Ola Hallengren's index optimize script does not perform Heap defragmentation.

In other words table rebuilds are not happening when running the procedure and that is expected.

You could run ALTER TABLE dbo.tablename REBUILD; to remove the fragmentation.

This also rebuilds the nonclustered indexes on the heap.

Better option than rebuilding your heap tables

You do have to ask yourself or the application team why you can't add a clustered index to the table. as rebuilding the heap uses a lot of resources and is a temporary solution.

If you add a clustered index, that index is included in the Index Optimize script, and fragmentation will be removed when the script runs.

Another option is to add the clustered index and stop worrying about index fragmentation.


We are experiencing performance issues. I am aware that 2008 is not ideal and that is being addressed.

It could be that it is because of the forwarded records in the heap tables, but at 8167 pages I would say that that is not likely. A starting point could be looking at the queries being executed on your server.

SP_BlitzCache can help with finding your worst performing queries.


The datafile is also showing as 220gb but the actual space used is 140gb.

This should not be a problem. Apart from disk space you should not be too worried. You are not relying on autogrowth, which is a good thing.

  • 1
    Alter table <table> REBUILD is supported in SQL Server 2008 onwards so you can do that to rebuild the heap. Tibor Karaszi has a script here: karaszi.com/rebuild-all-fragmented-heaps that is of great help – Spörri Apr 11 at 16:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.