The Problem

SQL Sam strolled into the war room of MegaCorp, Inc., and was immediately accosted by Fred, the head of the Do-It-All project. “Sam, I’m glad you’re here,” he said, sweat beading up on his brow. “We’ve got big problems.”

“What’s up?” said SQL Sam.

“As you know, we have two identical servers running the Do-It-All application, Beanie and Cecil. They’re identical hardware, identical software, identical service packs, identical software configuration- exact twins. But not any more!” Fred threw his arms up in desparation. “Something has happened to Cecil. It’s taking much longer to run the exact same query!”

“Hmmm… a twin gone bad,” said Sam. “How do you know it’s taking longer to run the query?”

“As you know, our servers process the exact same data in parallel. Beanie’s keeping up, but Cecil isn’t. I’ve played with the task priority of the application, tried stopping some other services… nothing helped. Do you think we should reinstall SQL Server? Should I get the hardware manufacturer out here? What about…”

“Hang on, hang on,” said Sam. “First, let’s verify what you are seeing.”

“Okay,” agreed Fred. “Our application does several things, but the one thing that it does most often is call the stored procedure sp_FindProducts. That procedure takes some parameters, and returns a result set of the products most likely to match the request.”

“Okay,” said Sam. “Let’s do a SQL Trace on both machines and see what we get.”