January 15, 2013 at 8:32 am
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
January 16, 2013 at 12:23 am
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
January 16, 2013 at 12:39 am
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
January 16, 2013 at 12:42 am
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
January 16, 2013 at 12:44 am
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
January 16, 2013 at 12:48 am
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
January 16, 2013 at 1:19 am
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