Slow performance remains after query rebuild only gets resolved after updting statistics ?

  • 1 of the query's of a colleague of mine has been slowing down recently.

    He looked to the execution plans and the index fragmentation and found a fragmented index, which he then rebuild.

    No resolve, fragmentation was gone but the performance remained slow.

    He then did an update statistics which resolved it.

    Now I'm confused,and the the things I found searching about it are contradicting.

    If you rebuild an index the statistics get updated,is this the case or not.

    I've requested more info on the table and query.

    But anyone who can tell me why you would need an update statistics after an index rebuild please do.

    Is there a way to check all statistics of a table

  • USE AdventureWorks2012;

    DECLARE @schema_name SYSNAME,

    @table_name SYSNAME;

    SELECT @schema_name = N'HumanResources',

    @table_name = N'Department';

    SELECT st.name AS StatsName,

    STATS_DATE(st.object_id, st.stats_id) AS [LastUpdated]

    FROM sys.objects AS tbl

    INNER JOIN sys.stats st ON st.object_id = tbl.object_id

    WHERE tbl.name = @table_name

    AND SCHEMA_NAME(tbl.schema_id) = @schema_name;

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato

  • It wasn't the statistics that fixed the issue, it was the query plan being invalidated and recompiled (ie. new plan).

    From BOL:

    http://msdn.microsoft.com/en-us/library/ms187348%28v=sql.105%29.aspx

    Updating statistics ensures that queries compile with up-to-date statistics. However, updating statistics causes queries to recompile. We recommend not updating statistics too frequently because there is a performance tradeoff between improving query plans and the time it takes to recompile queries.

    Also see

    http://www.sqlskills.com/blogs/kimberly/what-caused-that-plan-to-go-horribly-wrong-should-you-update-statistics/

  • foxxo (1/16/2013)


    It wasn't the statistics that fixed the issue, it was the query being recompiled (ie. new plan).

    From BOL:

    http://msdn.microsoft.com/en-us/library/ms187348.aspx

    Updating statistics ensures that queries compile with up-to-date statistics. However, updating statistics causes queries to recompile. We recommend not updating statistics too frequently because there is a performance tradeoff between improving query plans and the time it takes to recompile queries.

    rebuilding an index automatically rebuilds the statistics on that index

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato

  • Could well be that the stats that the query depends on are column stats, not index stats. REbuilding an index only updates the stats associated with that index (and invalidates any plans that use it)

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • Column stats is the likely reason given the info.

    There are no special teachers of virtue, because virtue is taught by the whole community.
    --Plato

  • GilaMonster (1/16/2013)


    Could well be that the stats that the query depends on are column stats, not index stats. REbuilding an index only updates the stats associated with that index (and invalidates any plans that use it)

    opc.three (1/16/2013)


    Column stats is the likely reason given the info.

    From the data I have and I've requested more an out of date statistic that is not part of the index he rebuild is the most likely cause of the problems. (I've came to the conclusion of this yesterday)

Viewing 7 posts - 1 through 6 (of 6 total)

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