Question

I have a stored procedure (sproc) called resetflags. It takes an int parameter. Another sproc editInspection calls it. Sproc editInspection is like this:

1. update a single row on a table (duration < 0.00 sec)
2. execute another sproc (duration < 0.00 sec)
3. execute sproc resetFlags (duration ~ 16 secs!!!)
4. select single row (duration < 0.00 sec)

If I comment out line 3 and run the sproc it finishes within 0 secs.
If I run line 3 by itself it finishes in 1 sec.
If I comment out line 1 and 2 the sproc takes 16 secs.

The database does not contain any trigger (I am a trigger-less happy person). There is no user-assigned transactions anywhere. I am using SQL 2008 Dev edition.

I have just timed it and some other test script using the profiler. Here are my findings:

Case 1: Ran the script to execute sproc editInspection with parameters. Took 16000 ms.

Case 2: Created a test script. Changed to code for sproc editInspection so that all params are local variables. Assigned values to those local vars, and then executed the code. Took around 16000 ms.

CASE 3: Commented out ‘exec resetflags’ from sproc editInspection and then ran something like the following:

execute editInspection param1,…param n
execute resetflags param1

So sproc resetflag is now running outside the sproc editInspection. This took 600-700 ms to finish.

Case 4: Took the test script from case 2. Commented out all except one variable declaraion and assignment. Commeneted out all other statements except execution of resetFlags. So the script is basically

declare param1 int
/*
commented out declare stmts
/
SET param1 = some value
/
commented out SET stmts
commented out SELECTs, UPDATE and EXECUTE
*/
execute resetFlags param1

This one took ~ 16000 ms.

Case 5: Copied the code from case 4 and pasted it on a new query window. Executed it, and it took around 700 ms! This is the strange part.

Case 6: Executed sproc resetFlags with value for the parameter. Took around 600 ms.

Any clue on what to look for will be much appreciated. I know I have not posted the code/table defintions and sample data. The defintions and code are quite large, and I am being lazy as well.

Answer 1

I would strongly suggest parameter sniffing as the culprit.