Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
SamC
White Water Yakist
3467 Posts |
Posted - 2005-01-03 : 12:07:00
|
Twice today, my web users were timing out when a stored proc was called that calculated statistics for the footer of the page. Each time, it was the same table that needed reindexing - 'dbo.LoginData' - the execution plan for the proc showed an index scan taking 230% of the plan execution time (yes 230%).Each time, DBCC REINDEX changed the execution plan to an index seek and it runs like a snap.There are only insertions in this table. No updates or deletes, 230,000 rows.CREATE TABLE [LoginData] ( [LoginID] [int] IDENTITY (1, 1) NOT NULL , [LoginDate] [datetime] NOT NULL CONSTRAINT [DF__LoginData__Login__3CA9F2BB] DEFAULT (getdate()), [LogoutDate] [datetime] NOT NULL CONSTRAINT [DF__LoginData__Logou__3D9E16F4] DEFAULT (convert(datetime,'')), [UserID] [int] NOT NULL , [CourseID] [int] NOT NULL , [Username] [varchar] (100) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL CONSTRAINT [DF_LoginData_Username] DEFAULT (''), [NotFound] [bit] NOT NULL CONSTRAINT [DF_LoginData_NotFound] DEFAULT (0), [RemoteIP] [varchar] (15) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL CONSTRAINT [DF__LoginData__Remot__3E923B2D] DEFAULT (''), [ResWidth] [smallint] NOT NULL , [ResHeight] [smallint] NOT NULL , [Browser] [varchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL , [BrowserType] [varchar] (100) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL CONSTRAINT [DF_LoginData_BrowserVendor] DEFAULT (''), [OSMake] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL CONSTRAINT [DF_LoginData_OS] DEFAULT (''), [OSModel] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL CONSTRAINT [DF_LoginData_OSModel] DEFAULT (''), [BrowserMake] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL CONSTRAINT [DF_LoginData_BrowserMake] DEFAULT (''), [BrowserVersion] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL CONSTRAINT [DF_LoginData_BrowserVersion] DEFAULT (''), CONSTRAINT [PK__LoginData__3BB5CE82] PRIMARY KEY CLUSTERED ( [LoginID] ) WITH FILLFACTOR = 80 ON [PRIMARY] ) ON [PRIMARY]GOOther than today, this table has been fine for over a year.Any ideas? Similar experiences? |
|
|
SamC
White Water Yakist
3467 Posts |
Posted - 2005-01-03 : 12:49:33
|
| Maybe the index wasn't lost? Perhaps statistics are tipping the execution plan to an index scan for some reason? |
 |
|
|
Kristen
Test
22859 Posts |
Posted - 2005-01-03 : 15:01:17
|
Why "FILLFACTOR = 80"? With a PK on an IDENTITY column wouldn't you be better off leaving it at the default(100%)?Are you using a "WITH FULLSCAN" when updating Statistics? Maybe the Auto Recalculate Statistics thing is getting triggered, and deciding that the index is out of wack to be any use?Stuff below may show you WHAT calculated the stats, and WHEN it happenedKristenCREATE PROC usp_ShowStatDate @tabmask sysname='%', @indmask sysname='%'AS SELECT [TableName] = LEFT(CAST(USER_NAME(uid)+'.'+o.name AS sysname), 30), [IndexName] = LEFT(i.name, 30), [Type] = CASE WHEN INDEXPROPERTY(o.id,i.name,'IsAutoStatistics')=1 THEN 'AutoStatistics' WHEN INDEXPROPERTY(o.id,i.name,'IsStatistics')=1 THEN 'Statistics' ELSE 'Index' END, [StatsUpdated] = STATS_DATE(o.id, i.indid), rowcnt, rowmodctr, [PercentModifiedRows] = ISNULL(CAST(rowmodctr/CAST(NULLIF(rowcnt,0) AS decimal(20,2))*100 AS int),0), [NoRecompute?] = CASE i.status & 0x1000000 WHEN 0 THEN 'No' ELSE 'Yes' END, i.status -- SELECT TOP 10 * FROM dbo.sysobjects o JOIN dbo.sysindexes i ON (o.id = i.id) WHERE OBJECTPROPERTY(o.id, 'IsUserTable') = 1 AND i.indid BETWEEN 1 AND 254 AND o.name LIKE @tabmask AND i.name LIKE @indmask ORDER BY StatsUpdated DESC, TableName, IndexName/* TEST RIGSELECT [ServerTime]=GetDate()EXEC usp_ShowStatDate*/GO |
 |
|
|
SamC
White Water Yakist
3467 Posts |
Posted - 2005-01-03 : 15:08:28
|
| Problem occured again. UPDATE STATISTICS dbo.LoginData WITH FULLSCANfixed the problem without reindexing. Is it necessary to run regular UPDATE STATISTICS when AUTO UPDATE is configured? |
 |
|
|
nr
SQLTeam MVY
12543 Posts |
Posted - 2005-01-03 : 17:32:48
|
| This article http://support.microsoft.com/default.aspx?scid=kb;en-us;195565says that statistics are updated when# of Changes >= 500 + (20% of Cardinality)Not sure if that's true (or stil true) but it's quite common for statistics to not be updated frequently enough as you are finding.I would schedule an update statistics during slow periods - usually overnight or after any large batch inserts==========================================Cursors are useful if you don't know sql.DTS can be used in a similar way.Beer is not cold and it isn't fizzy. |
 |
|
|
SamC
White Water Yakist
3467 Posts |
Posted - 2005-01-03 : 17:50:19
|
| I REINDEX every Sunday morning (3AM). Would you recommend updating statistics before or after the REINDEX or does it matter? |
 |
|
|
nr
SQLTeam MVY
12543 Posts |
Posted - 2005-01-03 : 17:53:04
|
| A reindex will rebuild the index and statistics.==========================================Cursors are useful if you don't know sql.DTS can be used in a similar way.Beer is not cold and it isn't fizzy. |
 |
|
|
Kristen
Test
22859 Posts |
Posted - 2005-01-05 : 23:51:33
|
| Nigel, I think I read somewhere that Reindex is NOT the same as Update Stats with FULL SCAN (i.e. it uses SAMPLE method or somesuch) - can you clarify that for me please?Sam: We rebuild indexes every night, but only for tables where the fragmentation is high enough (actually we DEFRAG tables that are "big" - i.e. where the ReIndex would take the table offline for too long. We rebuild statistics for all tables every night; databases statistics options are set to AUTO. Before we did the nightly Update Stats we found that the database would sometimes go into "manic mode" for anything up to 30 minutes, and we put this down to the automatic update of statistics.Kristen |
 |
|
|
SamC
White Water Yakist
3467 Posts |
Posted - 2005-01-06 : 08:38:26
|
| Thanks everyone for the feedback. I haven't had an episode since the 3rd occurance last Monday. Here's what I did:First, I reindexed the entire database after the first occurance Sunday night. On Monday another eposide (same table) occured around 10AM EST. I REINDEXED the one table after that episode, UPDATE STATS resolved the problem on the second episode at 12 noonish. I can't conclude that lack of REINDEXING was at the root of the problem. Database activity was very low until Monday afternoon. I haven't eliminated that these episodes might have been triggered because I'd never run a manual UPDATE STATS on the DB perhaps, but I don't think we'll know because:I changed the table to a different CLUSTERED INDEX structure that is more optimal overall. This change, and the nightly UPDATE STATS are new. Hope this problem never happens again.Thanks everyone... |
 |
|
|
|
|
|
|
|