SQL Sam and the Evil Twin - Part 2
Environment: SQL Server 6.5, SP4
Sam and Fred examined the SQL Trace from both machines. "You're right, " said Sam. "On Beanie, sp_FindProducts is
averaging about 50 milliseconds. On Cecil, though, the query is taking around 250 milliseconds. It's taking 5 times as
"See?" said Fred. "Cecil's gone bad!"
"Let's take a look at your stored procedure," said Sam.
Fred brought the procedure up in Enterprise Manager. It looked something like this:
CREATE PROCEDURE sp_FindProducts
IF @TYPE = 'HOUSE'
SELECT * FROM products WHERE color = @ARG1
ELSE -- Must be of type 'BUSINESS'
SELECT * FROM products WHERE price < convert(money(8), @ARG1)
"Interesting," said Sam. "Why is the procedure constructed this way? How is ARG1 used?"
"Actually, it's pretty clever. We found that when people are looking for household products, the most
important option is the color. When people are looking for business products, the most important option
is the price. So, we combined the two into one procedure, passing either a color or a price as ARG1."
"Did you by any chance try this procedure on Cecil before starting the Do-It-All application?" asked Sam
yes," said Fred. "I wanted to make sure that the 'BUSINESS' products were working properly. Why?"
"I think I know what the problem is now," said Sam. "Let's check."
What did SQL Sam see? Go to the solution now!
Review SQL Sam and the Evil Twin - Part 1
Back to SQL Sam Cases