Error: Could not continue scan with nolock due to data movement, DBCC proccache will clear the probelm

Question

SQL Server: 2008 R2 SP2
Before describing my problem, I have gone via the forum, there is no view or functions inside my stored procedure
When running a particular stored procedure inside crystal report, the error " Could not continue scan with nolock due to data movement" comes once every few weeks. After I clear the query cache plan, it works again for few weeks and the problem
comes again. During these few weeks, there is no restart or query plan clearing.
If I run the stored procedure inside SSMS, where the SQL statement is copied and pasted from SQL profiler during crystal report run, there is no error.
I discovered running in SSMS and crystal report generate 2 different query plans even I copied the SQL from SQL profiler, I have actually saved the query plans. Unfortunately, this forum does not accept attachments, or otherwise I will post my query plans
here.
There is one thing I notice about the query plan is during nested loop operation, there is a warning "no join predicate". I don't use any views or UDF in the statement, nor did I use pre-1992 ANSI join syntax. However, I did use table variables.
My guess is whether this will cause " Could not continue scan with nolock due to data movement", after I clear the cache, I run crystal report again, and I look at the plan again, the "nested loop no join predicate" warning is gone.
Running this stored procedure took 1 second maximum, even when this error is popping up, it pop up within 1 second.
DBCC checkdb has been run
The same stored procedure running by crystal report in a SQL 2008 (non r2) live environment has no problems, so I am thinking this is R2 specific problems.
The "nested loop no join predicate" error SQL statment is below, no views, no udf, but table variables
INSERT @ChequeAccount
SELECT        PS.PaySummaryID, PS.EmployeeID, PS.CostCentreID,
            (PS.GrossPay    + PS.LumpSumA + PS.LumpSumB    + PS.LumpSumD+ PS.LumpSumE+ PS.ETP+ PS.PaymentsAfterTax    - PS.DeductionsAfterTax  
 - PS.Tax- PS.ETPTax    + PS.TaxRebate) * -1 AS Amount,
            CGLM.GLAccountID
FROM Pay_Summary PS JOIN Input_Sheet ISH ON PS.InputSheetID = ISH.InputSheetID  AND  ISH.PayrollID = @binPayrollID   
AND PS.PaySummaryID NOT IN (SELECT PaySummaryID FROM @ChequeAccount)
JOIN Payroll P ON P.PayrollID = ISH.PayrollID AND P.EmployerID = @binEmployerID
JOIN CustomGLFixMapping CGLM ON CGLM.EmployerID = P.EmployerID AND CustomGLFixMappingNameID = 1 AND CGLM.CostCentreID IS NULL

Answer 1

The error Could not continue scan with nolock due to data movement can occur when you use the NOLOCK table hint, or use the command SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED. That is, so-called dirty reads. The error is not related to the
query plan per se, but when scanning a table, the storage engine will use an IAM scan rather than following the clustered index. If there is simultaneous activity, the storage engine may detect this and abort the operation to avoid returning incorrect data.
Or it may not detect it, and return uncommitted data or fail to return committed data.
All of these effects are transitory and they will not show up when you are alone on the system, only when there is concurrent activity in one or more of the tables in the query.
Using dirty reads is a risky business for the reasons explained above, and it takes careful analysis to understand whether you can live with the errors you can get from a particular query. The error about data movement can be handled: trap the error and
resubmit the query. But what about spurious incorrect results?
If you believe locking to be a problem, you should consider setting the database to READ_COMMITTED_SNAPSHOT
and take out all use of READ UNCOMMITTED/NOLOCK. When the database is in READ_COMMITTED_SNAPSHOT, readers read from the snapshot and only see committed data without blocking writers. This has some other effects like requiring a bigger tempdb,
and there is a risk for other types of concurrency errors, but they tend to be smaller risks.
I discovered running in SSMS and crystal report generate 2 different query plans even I copied the SQL from SQL profiler,
This is because SSMS by default runs with SET ARITHABORT ON. I discuss this in more detail in this article on my web site:
http://www.sommarskog.se/query-plan-mysteries.html
However, as I said, this problem is not related to the query plan as such, although some query plans are more susceptible to this error than others. (All plans are suscpeitble to produce incorrect results).
Erland Sommarskog, SQL Server MVP, [email protected]