views:

651

answers:

5

My database query has been running very fast until it changed to very slow recently. No changed have occurred in the database apart from normal data growth.

I have noticed that the database statistics have "never" been updated.

Is there an easy way that I can update these statistics across my entire database so I can see if that is the problem?

I am using SQL Server 2000 Sp4.

A: 

Try here

This should speed up your indices and key distribution. Re-analyzing table statistics optimises SQL Server's choice of index for queries, especially for large datasets

Chaos
A: 

Definitely make yourself a weekly task that runs automatically to update the database's statistics.

p.campbell
+2  A: 

You can use this

CREATE PROC usp_UPDATE_STATISTICS
(@dbName sysname, @sample int)
AS

SET NOCOUNT ON

DECLARE @SQL nvarchar(4000)
DECLARE @ID int
DECLARE @TableName sysname
DECLARE @RowCnt int

CREATE TABLE ##Tables
(
 TableID INT IDENTITY(1, 1) NOT NULL, 
 TableName SYSNAME NOT NULL
)

SET @SQL = ''
SET @SQL = @SQL + 'INSERT INTO ##Tables (TableName) '
SET @SQL = @SQL + 'SELECT [name] '
SET @SQL = @SQL + 'FROM ' + @dbName + '.dbo.sysobjects ' 
SET @SQL = @SQL + 'WHERE xtype = ''U'' AND [name] <> ''dtproperties'''

EXEC sp_executesql @statement = @SQL

SELECT TOP 1 @ID = TableID, @TableName = TableName
FROM ##Tables
ORDER BY TableID

SET @RowCnt = @@ROWCOUNT

WHILE @RowCnt <> 0
BEGIN

 SET @SQL = 'UPDATE STATISTICS ' + @dbname + '.dbo.[' + @TableName + '] WITH SAMPLE ' + CONVERT(varchar(3), @sample) + ' PERCENT'

 EXEC sp_executesql @statement = @SQL

 SELECT TOP 1 @ID = TableID, @TableName = TableName
 FROM ##Tables
 WHERE TableID > @ID
 ORDER BY TableID

 SET @RowCnt = @@ROWCOUNT

END

DROP TABLE ##Tables


GO

This will update stats on all the tables in the DB. You should also look at indexes and rebuild / defrag as nexessary

Raj

Raj
A: 

Normal Data Growth is good enough as a reson to justify a slowdown of pretty much any not optimized query.

Scalability issues related db size won't manifest till the data volume grows.

Post your query + rough data volume and we'll help you to see what's what.

JohnIdol
A: 

We've had a very similar problem with MSSQL 2005 and suddenly slow running queries.

Here's how we solved it: we added (nolock) for every select statement in the query. For example:

select count(*) from SalesHistory with(nolock)

Note that nolock should also be added to nested select statements, as well as joins. Here's an article that gives more details about how performance is increased when using nolock. http://www.mollerus.net/tom/blog/2008/03/using_mssqls_nolock_for_faster_queries.html

Don't forget to keep a backup of your original query obviously. Please give it a try and let me know.

Wadih M.
You will have to add (NOLOCK) to each and evry table in your from and join statements and you are risking dirty reads. If you are ok with dirty reads, you might want to try READ UNCOMMITTED instead
Raj
That's right, if your web application makes heavy use of transactions, you might have some slightly outdated data for some cells (if you select before transaction is committed, etc). It wasn't a problem in our case, and the speedup was most important. I'd also like to note that we never encountered big descrepancies because of using (nolock).
Wadih M.
Downvoter? Please explain.
Wadih M.
-1 ; seems like it would be better to find the cause of the problem and/or do some redesign if necessary. Tables with proper indexes and maintained statistics should scale and perform predictably.
SqlACID
Don't blame me for their bad design db problems. I just offered a working solution that can make very serious sense in many contexts and environments out there.
Wadih M.
Everybody doesn't have time to go through thousand lines of stored procedures written by previous programmers to make proper indexes. Sometimes you have to live with a bad design until further notice, and for those cases the solution proposed is valid.
Wadih M.
I think the point was that it was running fast, then it slowed down all of a sudden, not that there was necessarily any inherit design problems.
GordyII
We had the same symptoms and that was our solution. SqlACID downvoted because he thinks quick and easy ways aren't good, and that redesign should be done: "seems like it would be better to find the cause of the problem and/or do some redesign if necessary.".
Wadih M.
Sometimes, you don't have time to study the design of thousands of tables and sp's created by previous programmers over several years to understand why it slowed down suddenly. Maybe it doesn't apply to your case either, but nonetheless his reason for downvoting is weak, and my post is still a solution that worked for us, and might work for others.
Wadih M.