2

Running the following simple query in SSMS:

UPDATE tblEntityAddress SET strPostCode= REPLACE(strPostCode,' ','')

The update to the data (at least in memory) is complete in under a minute. I verified this by performing another query with transaction isolation level read uncommitted. The update query, however, continues to run for another 30 minutes. What is the issue here? Is this caused by a delay to write to disk?

TIA

Brian
  • 211
  • 1
  • 14
  • Looking at the logs, I'm seeing errors like: SQL Server has encountered 2336 occurrences of I/O requests taking longer than 15 seconds... A lot of these are to tempdb. Could this be caused by autogrowth being set to 1 MB? – Brian May 06 '10 at 16:43
  • possibly. 1mb is a pretty low icrement (and most dba's will yell at you for autogrowth anyway). on the database, right click and go to reports, and click the Disk Usage Report. on this report there is a section for autogrowth/shrink events. use this to see if you're getting a lot of these events. – DForck42 May 07 '10 at 15:22
  • This was corrected (and I agree on autogrowth. A higher up disagrees, unfortunately). The problem still persists. – Brian May 10 '10 at 17:26

3 Answers3

2

Most probably, you transaction is locked by another transaction which affected tblEntityAddress.

Run sp_lock and see if tblEntityAddress is locked by another process.

Quassnoi
  • 413,100
  • 91
  • 616
  • 614
  • See my comment on the question, above – Brian May 06 '10 at 16:44
  • @Brian: seems you have a problem with the disk subsystem indeed. See here: http://stackoverflow.com/questions/620626/what-is-pageiolatch-sh-wait-type-in-sql-server – Quassnoi May 06 '10 at 16:48
2

In a separate SSMS window, try running the following:

SELECT status, wait_type
FROM sys.dm_exec_requests
WHERE session_id = <SPID>

Just replaced with the SPID associated with your UPDATE query (number in brackets after your login name in the bottom bar).

Run the above a few times in succession and note what the wait_type is. There are numerous types of waits - see what that is (& let use know), it could highlight the cause.

Update: Quotes from this MS KB article:

IO_COMPLETION

This waittype indicates that the SPID is waiting for the I/O requests to complete. When you notice this waittype for an SPID in the sysprocesses system table, you must identify the disk bottlenecks by using the performance monitor counters, profiler trace, the fn_virtualfilestats system table-valued function, and the SHOWPLAN option to analyze the query plans that correspond to the SPID. You can reduce this waittype by adding additional I/O bandwidth or balancing I/O across other drives. You can also reduce I/O by using indexing, look for bad query plans, and look for memory pressure.

AdaTheDev
  • 142,592
  • 28
  • 206
  • 200
0

Another thing to consider is a slow running trigger.

HLGEM
  • 94,695
  • 15
  • 113
  • 186