Quering sys.dm_db_index_physical_stats and sys.indexes has a negative impact on other queries running

  • I used DMV's to get some detailed information on indexes. Running the query resulted in significant overall performance degradation. Stopping the query immediately solved performance issues.

    The query used the following join construction:

    sys.dm_db_index_physical_stats

    (8

    ,NULL -- NULL to view all tables

    ,NULL -- NULL to view all indexes; otherwise, input index number

    ,NULL -- NULL to view all partitions of an index

    ,'DETAILED') --We want all information

    AS a

    INNER JOIN sys.indexes

    ON a.[object_id] = sys.indexes.[object_id]

    AND a.index_id = sys.indexes.index_id

    The question is:

    How can this query impact other queries in such a negative way?

    Kind regards,

  • Because of the parameter "DETAILED", it will perform like a dbcc updateusage with countrows....

    BOL states:

    .... The nonleaf levels of indexes are only processed when mode = DETAILED.

    ...

    The DETAILED mode scans all pages and returns all statistics

    ...

    So you may experience IO overhead, locking ( ? ) , ...

    Johan

    Learn to play, play to learn !

    Dont drive faster than your guardian angel can fly ...
    but keeping both feet on the ground wont get you anywhere :w00t:

    - How to post Performance Problems
    - How to post data/code to get the best help[/url]

    - How to prevent a sore throat after hours of presenting ppt

    press F1 for solution, press shift+F1 for urgent solution 😀

    Need a bit of Powershell? How about this

    Who am I ? Sometimes this is me but most of the time this is me

Viewing 2 posts - 1 through 1 (of 1 total)

You must be logged in to reply to this topic. Login to reply