We have a heavily used SP which I'm trying to optimize because it sometimes runs slow.
Yesterday on production it took 80 seconds and did 33m logical reads, according to profiler.
(btw, this is a long time, the data is not that large and the result set is only a few thousand rows)
Today on a copy of yesterday's production database on a dev server, the same query (same SP with the same parameters against the same data) takes 4 seconds in only 400k logical reads!
The only difference, AFAIK, is that the production server was busy with other stuff when it ran slow yesterday, and I have this dev system to myself.
But I don't see why that should affect the *logical* reads by 70x. Even if every logical read were converted to physical and somehow counted twice, that still wouldn't do it.
I've seen this kind of issue before, and I've seen others with similiar questions, for example:
But right now, I seem to have about the worst case of it ever.
Unfortunately I cannot compare plans. It's complex data and the plans should (should!) probably not change much by parameter values, and the overall statistics of the tables don't change much over time, but even with all that, I have a pretty fresh copy of the database from yesterday, that reports very different numbers now. It's very irritating.
Of course it's not just a bad report, the query really did take a huge extra amount of CPU as well, and it really did take a lot more clock time yesterday. So I guess I have to believe it used a different plan yesterday - perhaps it changed plan execution based on total server load? But hey, it sure changed it in the wrong direction, didn't it? We do seem to need more RAM on the server, that discussion is already in progress, but it has 10gb already, 64bit, 4 core system, SQL 2008R2.
Any ideas what I'm seeing, or what to do about it - other than add RAM?
Thanks.
Josh