OK, I see this is a perennial, but now it's hitting me!
It's a winapp, in C#, using connection pooling.
sys.dm_exec_sessions does not show any different settings, and what settings would matter anyway.
There is no blocking going on.
It's SQL Server 2008 R2 Standard on Windows Server 2008 R2 Standard, both 64 bit.
I run profiler and get the textdata from the slow run from the app, paste it into SSMS, and it runs fast against the same server, so it does not seem to be a matter of parameter sniffing.
It is not a matter of buffers, afaik, I can run the query fast from SSMS, then some random time later slow from the app.
The number of logical reads goes up by a factor of 1000 for the bad plan.
I can *see* the bad plan and the good plan, and they are unfortunately complex but I can quickly see in one place the good one uses merge joins instead of several layers of loops - but the question is, WHY ANY DIFFERENCES AT ALL given the same parameters? It is possible that some of the tables and statistics have changed *slightly* between runs, but nothing that should affect the plans, it's a fairly stable database.
Finally, plan guides - can I freeze an entire complex SP with one guide? All the examples seem to suggest that a guide only works for a statement or batch at a time. I guess I can feed it the entire SP as text?
Thanks,
Josh