A valid point. A larger number of users would result in a global reduction of the PGA memory available for workarea operations.

This wouldn’t change the plan but, as you point out, could mean that at run-time a query might change from in-memory to one-pass, or from one-pass to multipass because of a global limit imposed by the target.

Certainly one of the pre-emptive measures is to ensure that any time you collect statistics, backup the old statistics. See http://jonathanlewis.wordpress.com/2006/12/03/saving-statistics/ for starters. Another ‘pre-emptive’ strategy is to accumulate a library of execution plans for every query – but since this is very labour intensive you may have to start with the more resource-intensive queries and work downwards. One low cost, but limited, strategy is to collect the sql_id (or hash_vlaue) and plan_hash_value for statements in the library cache on a fairly regular basis – and check on statements that show intermittent changes in plans.

lascoltodelvenerdi,
The “short table” that became a “long table” is a nice example – it only takes one row for the high water mark to move, although you would still have to update the statistics if they had been previously collected. See this as an example: http://jonathanlewis.wordpress.com/2007/07/29/nls/

Gary,
Obviously I’m not going to disagree with the “fix the problem that’s here now” – but what we’re talking about is really a minor change in emphasis. You may want to work out an efficient execution plan from scratch – if I find the documentation that describes what the execution path should be, or the listing of the last known good execution plan, then I have the chance of fixing the immediate problem much faster then someone working out a good plan from first principles.

Either way – I think we would both compare the resulting good plan with the bad plan to work out why the good plan didn’t appear automatically since the change may indicate an inherent instability that needs to be addressed more carefully.

lascoltodelvenerdi,
I remember working for at a company where one person wheeled a trolley loaded with computer print-out into the trading room at the start of each day, and another person wheeled it out to the shredder at the end of each day – and no-one looked at a single sheet of it during the entire day. There was a very easy option to improve the performance of the overnight batch run.

“where the 4.5 million rows of result set were going”

You pointed out a good one!

Many times we work in a multi-tier environment and stuck with the DB while the problem is elsewhere.

On the other hand, you can take a ‘here and now’ tuning approach and look at what the SQL is doing now, consider what alternatives are available and how they might be better. You don’t have different approaches for brand-new SQL (where you don’t have a history), SQL that has changed (where there was a history for the old SQL but you may not be able to find it), SQL that hasn’t changed where the plan has, or the plan is the same but there’s more IO waits, or the plan and IO is the same but there’s more idle waits…

PS. For the OP, I wonder where the 4.5 million rows of result set were going. Maybe the holdup was in the network, writing to a destination file….

And if you read “No change in database and other components” as “no news tables, index or any modification to the server”, you can cut-out some possibilities.

It looks like some data problems, i.e. the table was a “little table” but from last week it becomes a “big table”, so no more cache…

Another cause could be the indexes: perhaps they need rebuild, but in this case the table as grown and there was some huge update activity.

Bye.