Hi,
I am trying to diagnose and resolve an intermittent problem on a remote customer's system. The reported problem is being unable to logon to the application that I support until they restart the system.
The logs from the application show a database call failing that is used as part of the application logon process. The error message from SQL Server is "Could not continue scan with NOLOCK due to data movement. [80040e14]".
The customer finds that it is not enough to just restart the application services. In order to resolve the issue they have been resorting to restarting the whole server, which includes restarting SQL Server. After a restart, the software works as expected for a few days before the problem re-occurs.
I've checked the code (and searched the entire code base), and cannot find any use of the query hint "NOLOCK", and there is also no signs of "SET ISOLATION LEVEL READ UNCOMMITTED".
The customer has run DBCC CHECKDB on the databases (including the tempdb), and has not found any issues. They were originally using SQL Server 2008 R2 with no service pack. They installed Service Pack 2 for SQL Server 2008 R2, but have experienced one further instance of this problem.
I have inspected the SQL Error logs from the site, and have not seen anything out of the ordinary in there. I simply see start up messages, backups of logs being taken, and nightly "DBCC CHECKDB"'s on the various databases.
The same software has been by other customers without having this issue, although on other customer's sites the database is locked down and access to the database is restricted.
Any thoughts of what else I can check? Is there some additional logging or diagnostic information that I could get from SQL Server as to what may be triggering the problem to occur? I looked for a trace flag that might be helpful, but didn't find one that appeared relevant.
I'm currently asking them to drop and recreate the stored procedures, just to make sure that the code on site is the same as what I am looking at. However, this is just something to try, since I have no reason to think that the stored procedures would have been changed in any way.
Thanks.
Geoff.