Timing can be critical – and performance “tuning” can sometimes be as simple as rescheduling.

Of course, there are times when collecting stats about what the data looked like yesterday just before loading today’s data can lead to odd execution plans in the morning ;)

It is certainly necessary to ensure that the statistics you have are a reasonable model of the data – but that doesn’t mean you have to allow the automatic stats collection job to run.

And if you do have the automatic job running, it’s probably a good idea to change the method_opt to avoid collecting histograms – and collecting histograms is (a) the most expensive bit and (b) the bit most liable to be sensitive to change.

My chapter in the second Oak Table compendium is all about statistics – and end with suggestions about the need (on larger, more complex systems) to devise a simple alternative to the automatic stats collection job.

A problem I have seen a couple of times and that I know others have, is that the default stats gathering window falls at the same time as the batch process window for many systems. A lot of Data warehouses have their busiest processing time preparing data overnight, in time for the users to look at it in the morning. Changing the schedular window to the ealry evening, so the stats gathering usually finishes before midnight can help.

An another alternative, which is very manual and a bit dirty, is you check for very large objects that have reached 8 or 9% changed and do a manual gather on the table and it’s indexes before the auto job picks it up. You can pick low values and parallel processing to get it done quickly. I did that “by hand” for a few weeks once :-)

I supplied the predicate:

job_name = ‘GATHER_STATS_JOB’

The view definition for column job_name is:

DECODE(INSTR(“E”.”NAME”,’”‘),0,”E”.”NAME”,SUBSTR(“E”.”NAME”,1,INSTR(“E”.”NAME”,’”‘)-1))

One day the optimizer may be able to handle the type of inference that you are suggesting – but it can’t do so at present.

DECODE(INSTR(“E”.”NAME”,’”‘),0,”E”.”NAME”,SUBSTR(“E”.”NAME”,1,INSTR(“E”.”NAME”,’”‘)-1))=’GATHER_STATS_JOB’

I wonder why it is not written as: “E”.”NAME” LIKE ‘GATHER_STATS_JOB%’

Not strictly the same, but at least an index wouldn’t have to be function-based to be useful.

I had a related problem last week, gather_schema_stats job running two days in my sqlplus session(oracle version 10.2.0.4), it was a request from client to collect stats for a schema at 10am on Monday morning, as they loaded 8m rows into a table which already got 10m rows, so to become 18m rows. Table is not partitioned.

From dba_scheduler_job_run_details automatic stats collection job status was ‘STOPPED’ for Monday and Tuesday night runs, as weekday window is from 22pm to 6am.

Wednesday afternoon i cancelled my sqlplus session, I was using gather_schema_stats with estimate_percent as auto sample size, method_opt_column size also auto. Then I tried the same with degree set to 7, server got 8 physical cpu’s, still no luck, it was taking hrs, there is problem sql reported in metalink for running gather_schema_stats with auto options, and I found same sql in my awr report.

finally I tried with sample size 1 and column size 1 (without histograms) in sqlplus, job finished within few minutes, and automatic stats collection job was successful from that night onwards. I didn’t change any auto option values using SET_PARAM procedure.

Regards,
Vineeth

select 
	operation, 
	start_time, 
	end_time - start_time
from 
	dba_optstat_operations
where
	operation = 'gather_database_stats(auto)'
order by 
	start_time desc
;sourcecode]

(Formatting left as exercise).

The only drawback is that this doesn’t give you a success/fail indicator – which the scheduler does.

I’ve seen a similar, but possibly funnier, example of your “stuck” statistics. Big batch load to enormous table causes Oracle to fail to collect stats every night for a week – finally succeeding on the big table at 8:00 pm Sunday night … just in time for the table to be dump and reloaded.

I see that you’ve got a mini-series on your blog about stats collection silently failing.

If you only want to know about the automatic stats collection job running, you can look at DBA_OPTSTAT_OPERATIONS, which itself looks at sys.WRI$_OPTSTAT_OPR. There is no index on this underlying table, but as it only hold information about statistic gathering operations that covered schemas, system, dictionary or everything (the automatic stats job) it contains relatively few records.

If you have a system with very large tables (hundreds of GB or even TB) it is very important to check how long the automatic stats job ran for. Under V10 at least, it can get “stuck”. It spends so long gathering stats on the very large table or tables that it never finishes, then tries to gather stats on the same table(s) the next night and fails again… and again…until the weekend when it gets more time to run.

If things get really bad, it will fail over the weekend too and, in effect, your automatic stats gathering stops. You are not warned about this by the system, you have to go and check!

Martin