Hi All,
I need some help identifying the issue with this query I'm running, whenever I run a particular query using the below optimize for statement, it generate the error below and a dump file
(OPTIMIZE FOR (@p1 unknown, @p2 unknown, @p3=1, @p4 UNKNOWN, @p5 UNKNOWN, @p6 UNKNOWN, @p7 UNKNOWN, @p8 UNKNOWN, @p9 UNKNOWN, @p10 UNKNOWN))
Msg 0, Level 11, State 0, Line 0
A severe error occurred on the current command. The results, if any, should be discarded.
Msg 0, Level 20, State 0, Line 0
A severe error occurred on the current command. The results, if any, should be discarded.
If I change @P3 to unknown it works if I give any other the other parameters value it works it's only when I give @P3 a value.
I've used Windbg to get out the below
Call Site
sqlservr!COptExpr::PrepareTreeForQP
sqlservr!CRelOp_Query::PrepareQueryForQP
sqlservr!CQuery::PqoBuild
sqlservr!CStmtQuery::InitQuery
sqlservr!CStmtSelect::Init
sqlservr!CCompPlan::FCompileStep
sqlservr!CSQLSource::FCompile
sqlservr!CSQLSource::FCompWrapper
sqlservr!CSQLSource::Transform
sqlservr!CSQLSource::Execute
sqlservr!process_request
sqlservr!process_commands
sqlservr!SOS_Task::Param::Execute
sqlservr!SOS_Scheduler::RunTask
sqlservr!SOS_Scheduler::ProcessTasks
sqlservr!SchedulerManager::WorkerEntryPoint
sqlservr!SystemThread::RunWorker
sqlservr!SystemThreadDispatcher::ProcessWorker
sqlservr!SchedulerManager::ThreadEntryPoint
msvcr80!endthreadex
msvcr80!endthreadex
kernel32!BaseThreadInitThunk
ntdll!RtlUserThreadStart
I'm assuming the problem relates to getting the plan for this particular set of parameters. The problem started when I was investigating a problem with a cached planned causing this query to run for a very long time I thought I had identified the issue when I gave @P3 a value of 1 and the query started to take along time to run and we started to see the behaviour in the application that had started the investigation. Instead of letting the query run to a conclusion I killed the process now a have this issue. I've tried updating the statistics. my next thought were to run a dbcc checktable on the tables involved and rebuild the indexes but I need to do this out of hours.
Is this a bug or a corruption?
Thanks
James