Viewing 15 posts - 361 through 375 (of 600 total)
for statistics - can I just run exec sp_updatestats?
not sure if this helps but I created same proc called myproc2...and ran that using same acount number and got the same...
October 25, 2010 at 12:24 pm
Not if the next time your run the proc, you use parameters that have better plans with scans... and then all other parameters are better off using seeks.
I cleared the...
October 25, 2010 at 10:03 am
wouldn't the dbcc freeproccache command clear out the cache
and therefore clear out any parameter sniffing issue?
October 25, 2010 at 9:29 am
thats the wierd thing there is no redical difference in hardware...
I've even tried restoring on to my sandbox (small client machine)...using the backup from the night before..and it takes two...
October 25, 2010 at 8:50 am
if this was parameter sniffing .
wouldn't I see scans in the execution plan?
I don't see scans...all seeks..the execution plan matches the one in stage which runs fast..
October 25, 2010 at 8:41 am
thanks for all your help
I haven't tried moving the variables yet...this particular proc has 24 input params and is kind of a bitch...(I didn't write it)... 🙂
October 25, 2010 at 8:38 am
I flushed the cache and re-ran the proc using same parameters..I can't make it run slowly on my stage server...I tried changing params and no matter which I choose it...
October 25, 2010 at 8:30 am
Not sure if this is really a parameter sniffing issue...
I added the 'with RECOMPILE' option to the end of my proc
Declare @nRC int, @rnSQLError int
exec @nRC = psp_x_hist_inq ...
October 25, 2010 at 8:14 am
okay...I setup a job to clear the cache lat tonight...
thanks for all your help...hope it works
October 22, 2010 at 12:52 pm
okay I ran this :
SELECT cp.plan_handle, st.[text]
FROM sys.dm_exec_cached_plans AS cp
CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS st
WHERE [text] LIKE N'%/* psp %';
and it found two plan handles...that look like my proc
now...
October 22, 2010 at 11:06 am
wierd thing is if I change to a different accoutn number then everything returns fast
same query in prod.. same everything..if I change the account number to someone elses it's fast...
October 22, 2010 at 10:35 am
yep checked for all those....doesn't seem to be waiting on anything..
and this prod server isn't heavily used...
I also tried
while (1=1)
select waitime,waittype,lastwaittype from sysprocesses where SPID=<the query SPID> where waittime...
October 22, 2010 at 10:33 am
Yeah sorry....the execution plans are identical on both stage and production...
but return times are 2 seconds on stage....3minutes in prod.
October 22, 2010 at 10:08 am
Didn't think about using plan guides....
I'll read up on it..
I have the plan from the stage server..can I force the prod server to use that plan?
Although the plans appear...
October 22, 2010 at 9:59 am
already used with recompile...no luck
can't drop cause it's in use..
I created a new proc (myproc_2) which was a copy of the existing query and then ran against that...still slow...
any other...
October 22, 2010 at 9:33 am
Viewing 15 posts - 361 through 375 (of 600 total)