Sorry about the late reply – I sometimes lose sight of questions if I’ve let a batch of comments accumulate.

The answer to your question is that the CPUSPEEDNW doesn’t usually have a big impact on the total cost of a query – in most cases the majority of the cost comes from the I/O component. Unfortunately there are always exceptions, and sometimes even a very small change in total cost is enough to make the optimizer choose a different execution plan.

As a quick check, I just executed dbms_stats.delete_system_stats on a 10.2.0.3 database and the values for the three noworkload statistics all changed immediately – and bouncing the database didn’t make them change again. Then gathering system stats with the noworkload option changed only the CPUSPEEDNW. So I wouldn’t want to predict exactly what’s going to happen in your case if you delete the system stats and bounce the database.

One thought – rather than coping with the possibility of two separate changes in the values why don’t you just set the stats to values that match those from the most similar system that you’ve got. A piece of pl/sql like the following should be adequate (with serveroutput enabled):

declare
	m_value		number;
	m_status	varchar2(64);
	m_start		date;
	m_stop		date;
begin
	dbms_stats.get_system_stats(m_status, m_start, m_stop, 'CPUSPEEDNW', m_value);
	dbms_output.put_line('CPUSPEEDNW :' || m_value);
	dbms_stats.set_system_stats('CPUSPEEDNW',1800);

	dbms_stats.get_system_stats(m_status, m_start, m_stop, 'IOSEEKTIM', m_value);
	dbms_output.put_line('IOSEEKTIM  :' || m_value);
	dbms_stats.set_system_stats('IOSEEKTIM',4);

	dbms_stats.get_system_stats(m_status, m_start, m_stop, 'IOTFRSPEED', m_value);
	dbms_output.put_line('IOTFRSPEED :' || m_value);
	dbms_stats.set_system_stats('IOTFRSPEED',32768);

end;
/

I’ve not seen one (although I haven’t checked 11g yet). I would be a little surprised if it happened because it would mean invalidating the entire cursor cache, which could have a dire effect on the library cache and shared pool latches.

Since Oracle Oracle only invalidates dependent cursors over a period of time (5 hours, according to the hidden parameter _optimizer_invalidation_period) when you gather stats on an object, I don’t thnk it’s likely to do something this aggressive when you gather system stats.

Thanks,
Alon.

Many thanks!
Mark Teehan
Singapore

Best regards,
Edgar