March 23, 2013 at 11:02 pm
Hi guys and girls, I hope you can help me.
I´m running SQL2005 since a couple of years on server, and receantly, with no reason, I´m having some kind of problem with query execution. I´m getting two kind of errors:
"Time-out occurred while waiting for buffer latch type 2 for page (3:210666), database ID 9." and
"Could not continue scan with NOLOCK due to data movement". That last message is showed when I use with (nolock) option.
Generally occurs when I use large size tables as the source.
Looking on system event log, everytime I get the SQL errore, I see a warning that says "Reset to device, \Device\RaidPort0, was issued". Could be a IO issue?
Any ideas? Thanks!
March 24, 2013 at 2:23 am
"Could not continue scan with NOLOCK due to data movement"
This one is mostly caused by using NoLock hints or the read uncommitted isolation level. If you're getting it a lot, remove Nolock from your queries (probably a good idea anyway considering the incorrect results it allows). If you need writers to not block readers, consider one of the snapshot isolation levels.
See - http://blogs.msdn.com/b/davidlean/archive/2009/04/06/sql-server-nolock-hint-other-poor-ideas.aspx
The timeout suggests IO contention or other problems, if the RAID controller is resetting frequently, then you may want to investigate that, see why and if it can be fixed.
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
March 24, 2013 at 6:22 am
Thanks GilaMonster, I´m aware about the nolock situation, and I know that removing that will solve that particular error. The thing is that the entire process (about 80 DTS) has that hint for about 5 years and never had problem. Actually is not a transactional database, so I could remove it, but the strange thing is why happend if there is no data movement at all.
I would understand it if someone insert o delete a lot of data, but nothing is happend on database at that moment! 🙁
We will check for IO problems...
March 24, 2013 at 10:14 am
DTS? What version of SQL Server are you on?
SELECT SERVERPROPERTY('Edition') AS Edition,
SERVERPROPERTY('ProductVersion') AS ProductVersion,
SERVERPROPERTY('ProductLevel') AS ProductLevel;
SQL 2000 issue? http://support.microsoft.com/kb/815008
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
March 24, 2013 at 11:09 am
opc.three (3/24/2013)
DTS? What version of SQL Server are you on?
Andres Zoppelletto (3/23/2013)
I´m running SQL2005 since a couple of years on server...
DTS runs fine on SQL 2005 and 2008. Deprecated, not removed.
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
March 24, 2013 at 11:11 am
GilaMonster (3/24/2013)
opc.three (3/24/2013)
DTS? What version of SQL Server are you on?Andres Zoppelletto (3/23/2013)
I´m running SQL2005 since a couple of years on server...DTS runs fine on SQL 2005 and 2008. Deprecated, not removed.
I know. But people post in the wrong Forum all the time.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
March 24, 2013 at 11:49 am
This is a SQL2005 issue, because the problem came up with the engine itself, not the etl (that yes, it´s actually a SLQ2000).
Our MSSQL server:
Enterprise Edition (64-bit)9.00.5292.00SP4
We launch ETLs process from DTS on SQL2000, pointing to our SQL2005 DWH. Even if we run manually some script we got those errors.
March 24, 2013 at 12:11 pm
Oh well. I thought it was worth checking, thanks for clarifying. So much for applying a patch in case you were in fact hitting a SQL2000 DB. Follow the advice Gail gave or maybe open a ticket with Microsoft.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
March 24, 2013 at 3:31 pm
Yeah, we already opened a case with Microsoft, but still waiting that our engineers come with the solution. About the suggestion of removing nolock hint, is not an option. Basically because this option works since 2007, and now, in the last week, we are having problems.
We belive that the IO issue is the responsible for the SQL errors, both appears exactly at the same time.
March 24, 2013 at 10:28 pm
I'd go with a disk problem, and ignore the NOLOCK part of the error message. That specific error can be thrown if there is a corrupt page encountered while running a query. Are there any 823 or 824 errors in the SQL error log? Is page 9:3:210666 OK?
DBCC TRACEON(3604);
DBCC PAGE(9,3,210666,1);
That should return with no errors. If there are errors, they may not be detected unless you have Torn Page Detection or Checksum set as the page-verify option for the database (checksum is highly preferred).
The corruption may exist on a different page, or it may be a case of the RAID controller intermittently failing.
Eddie Wuerch
MCM: SQL
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply