Auto Stats Gathering

Hi All,
In 10g, Oracle automatically collects the statistics between 10 to 6 night window. I am just curious about what estimate_percent it takes for this. I mean when we do manual stats gathering by following command, it takes 20 percent for estimation:
exec dbms_stats.gather_table_stats(ownname=>'scott',estimate_percent=>20, method_opt=>'FOR ALL INDEXED COLUMNS SIZE 1',degree=>7, cascade=>true,granularity=>'all');
I am gathering the stats by above command for some of my schemas. Now, I want to rely on auto stats gathering feature of Oracle 10g. So I want to know the estimate_percent taken by Oracle.
Thanks,
Api

14.3.1.1 Statistics Gathering Using Sampling
The statistics-gathering operations can utilize sampling to estimate statistics. Sampling is an important technique for gathering statistics. Gathering statistics without sampling requires full table scans and sorts of entire tables. Sampling minimizes the resources necessary to gather statistics.
Sampling is specified using the ESTIMATE_PERCENT argument to the DBMS_STATS procedures. While the sampling percentage can be set to any value, Oracle Corporation recommends setting the ESTIMATE_PERCENT parameter of the DBMS_STATS gathering procedures to DBMS_STATS.AUTO_SAMPLE_SIZE to maximize performance gains while achieving necessary statistical accuracy. AUTO_SAMPLE_SIZE lets Oracle determine the best sample size necessary for good statistics, based on the statistical property of the object. Because each type of statistics has different requirements, the size of the actual sample taken may not be the same across the table, columns, or indexes. For example, to collect table and column statistics for all tables in the OE schema with auto-sampling, you could use:
EXECUTE DBMS_STATS.GATHER_SCHEMA_STATS('OE',DBMS_STATS.AUTO_SAMPLE_SIZE);
When the ESTIMATE_PERCENT parameter is manually specified, the DBMS_STATS gathering procedures may automatically increase the sampling percentage if the specified percentage did not produce a large enough sample. This ensures the stability of the estimated values by reducing fluctuations.

Similar Messages

Auto stats gathering for partitioned table

Hi,
We are in 10gR2 in sun solaris. We are using auto stats gathering for our DB. Here is my question,
i know oracle gather statistics of the table, if the table changes more than 10%. How this work out for partitioned table? If the partition table changes more than 10% will last partition analyzed or the full table. We have partitioned based on insertion date.
Appreciate your responds.
Regards,
Satheesh Shanmugam
http://borndba.com

I hope it will be only current partition which has teh stale statistics will be gathered the stastics instead of full table.
Anil Malkai

Automatic stats gathering job log

Hi
we are auto stats gathering feature in ORACLE 10g.I want to know the following information Reg this.
For last one week,Start time and end time of this Job and any errors while gathering jobs.Where can i find this info
Thanks,
pramod

You can check from the following table
SQL> desc DBA_SCHEDULER_JOBS;
Name                            Null?    Type
OWNER                           NOT NULL VARCHAR2(30)
JOB_NAME                        NOT NULL VARCHAR2(30)
JOB_SUBNAME                              VARCHAR2(30)
JOB_CREATOR                              VARCHAR2(30)
CLIENT_ID                                VARCHAR2(64)
GLOBAL_UID                               VARCHAR2(32)
PROGRAM_OWNER                            VARCHAR2(4000)
PROGRAM_NAME                             VARCHAR2(4000)
JOB_TYPE                                 VARCHAR2(16)
JOB_ACTION                               VARCHAR2(4000)
NUMBER_OF_ARGUMENTS                      NUMBER
SCHEDULE_OWNER                           VARCHAR2(4000)
SCHEDULE_NAME                            VARCHAR2(4000)
SCHEDULE_TYPE                            VARCHAR2(12)
START_DATE                               UNDEFINED
REPEAT_INTERVAL                          VARCHAR2(4000)
EVENT_QUEUE_OWNER                        VARCHAR2(30)
EVENT_QUEUE_NAME                         VARCHAR2(30)
EVENT_QUEUE_AGENT                        VARCHAR2(30)
EVENT_CONDITION                          VARCHAR2(4000)
EVENT_RULE                               VARCHAR2(65)
END_DATE                                 UNDEFINED
JOB_CLASS                                VARCHAR2(30)
ENABLED                                  VARCHAR2(5)
AUTO_DROP                                VARCHAR2(5)
RESTARTABLE                              VARCHAR2(5)
STATE                                    VARCHAR2(15)
JOB_PRIORITY                             NUMBER
RUN_COUNT                                NUMBER
MAX_RUNS                                 NUMBER
FAILURE_COUNT                            NUMBER
MAX_FAILURES                             NUMBER
RETRY_COUNT                              NUMBER
LAST_START_DATE                          UNDEFINED
LAST_RUN_DURATION                        UNDEFINED
NEXT_RUN_DATE                            UNDEFINED
SCHEDULE_LIMIT                           UNDEFINED
MAX_RUN_DURATION                         UNDEFINED
LOGGING_LEVEL                            VARCHAR2(4)
STOP_ON_WINDOW_CLOSE                     VARCHAR2(5)
INSTANCE_STICKINESS                      VARCHAR2(5)
RAISE_EVENTS                             VARCHAR2(4000)
SYSTEM                                   VARCHAR2(5)
JOB_WEIGHT                               NUMBER
NLS_ENV                                  VARCHAR2(4000)
SOURCE                                   VARCHAR2(128)
DESTINATION                              VARCHAR2(128)
COMMENTS                                 VARCHAR2(240)
FLAGS                                    NUMBER

Partitioned Incremental Table - no stats gathered on new partitions

Dear Gurus
Hoping that someone can point me in the right direction to trouble-shoot. Version Enterprise 11.1.0.7 AIX.
Range partitioned table with hash sub-partitions.
Automatic stats gather is on.
dba_tables shows global stats YES analyzed 06/09/2011 (when first analyzed on migration of data) and dba_tab_partitions shows most partitions analyzed at that date and most others up until 10/10/2011 - done by the automatically by the weekend stats_gather scheduled job.
46 new partitions added in the last few months but no stats gathered on in dba_tab_partitions and dba_table last_analyzed says 06/09/2011 - the date it was first analyzed manually gathering stats rather than using auto stats gatherer.
Checked dbms_stats.get_prefs set to incremental and all the default values recommended by Oracle are set including publish = TRUE.
dba_tab_partitions has no values in num_rows, last_analyzed etc.
dba_tab_modifications has no values next to the new partitions but shows inserts as being 8 million approx per partition - no deletes or updates.
dba_tab_statistics has no values next to the new partitions. All other partitions are marked as NO in the stale column.
checked the dbms_stats job history window - and it showed that the window for stats gathering stopped within the Window automatically allowed.
Looked at Grid Control - the stats gather for the table started at 6am Saturday morning and closed 2am Monday morning.
Checked the recommended Window - and it stopped analyzing that table at 2am exactly having tried to analyze it since Saturday morning at 6am.
Had expected that as the table was in incremental mode - it wouldn't have timed out and the new partitions would have been analyzed within the window.
The job_queue_processes on the database = 1.
Increased the job_queue_processes on the database = 2.
Had been told that the original stats had taken 3 days in total to gather so via GRID - scheduled a dbms_scheduler (10.2.0.4) - to gather stats on that table over a bank holiday weekend - but asked management to start it 24 hours earlier to take account of extra time.
The Oracle defaults were accepted (and as recommended in various seminars and whilte papers) - except CASCADE - although I wanted the indexes to be analyzed - I decided that was icing on the cake I couldn't afford).
Went to work - 24 hours later - checked dba_scheduler_tasks_job running. Checked stats on dba_tab_stats and tba tablestats nothing had changed. I had expected to see partition stats for those not gathered first - but quick check of Grid - and it was doing a select via full table scan - and still on the first datafile!! Some have suggested to watchout for the DELETE taking along time - but I only saw evidence of the SELECT - so ran an AWR report - and sure enough full table scan on the whole table. Although the weekend gather stats job was also in operation - it wasn't doing my table - but was definitely running against others.
So I checked the last_analyzed on other tables - one of them is a partitioned table - and they were getting up-to-date stats. But the tables and partitions are ridiculously small in comparison to the table I was focussed on.
Next day I came in checked the dba_scheduler_job log and my job had completed within 24 hours and completed successfully.
Horrors of horrors - none of the stats had changed one bit in any view I looked at.
I got my excel spreadsheet out - and worked out whether because there was less than 10% changed - and I'd accepted the defaults - that was why there was nothing in the dba_tables to reflect it had last been analyzed when I asked it to.
My stats roughly worked out showed that they were around the 20% mark - so the gather_table stats should have picked that up and gathered stats for the new partitions? There was nothing in evidence on any views at all.
I scheduled the job via GRID 10.2.04 for an Oracle database using incremental stats introduced in 11.1.0.7 - is there a problem at that level?
There are bugs I understand with incremental tables and gathering statistics in 11.1.0.7 which are resolved in 11.2.0 - however we've applied all the CPU until April of last year - it's possible that as we are so behind - we've missed stuff?
Or that I really don't know how to gather stats on partitioned tables and it's all my fault - in which case - please let me know - and don't hold back!!!
I'd rather find a solution than save my reputation!!
Thanks for anyone who replies - I'm not online at work so can't always give you my exact commands done - but hopefully you'll give me a few pointers of where to look next?
Thanks!!!!!!!!!!!!!

Save the attitude for your friends and family - it isn't appropriate on the forum.
>
I did exactly what it said on the tin:
>
Maybe 'tin' has some meaning for you but I have never heard of it when discussing
an Oracle issue or problem and I have been doing this for over 25 years.
>
but obviously cannot subscribe to individual names:
>
Same with this. No idea what 'subscribe to individual names' means.
>
When I said defaults - I really did mean the defaults given by Oracle - not some made up defaults by me - I thought that by putting Oracle in my text - there - would enable people to realise what the defaults were.
If you are suggesting that in all posts - I should put the Oracle defaults in name becuause the gurus on the site do not know them - then please let me know as I have wrongly assumed that I am asking questions to gurus who know this suff inside out.
Clearly I have got this site wong.
>
Yes - you have got this site wrong. Putting 'Oracle' in the text doesn't enable people to realize
what the defaults in your specific environment are.
There is not a guru that I know of,
and that includes Tom Kyte, Jonathan Lewis and many others, that can tell
you, site unseen, what default values are in play in your specific environment
given only the information you provided in your post.
What is, or isn't a 'default' can often be changed at either the system or session level.0
Can we make an educated guess about what the default value for a parameter might be?
Of course - but that IS NOT how you troubleshoot.
The first rule of troubleshooting is DO NOT MAKE ANY ASSUMPTIONS.
The second rule is to gather all of the facts possible about the reported problem, its symptoms
and its possible causes.
These facts include determining EXACTLY what steps and commands the user performed.
Next you post the prototype for stats
DBMS_STATS.GATHER_TABLE_STATS (
ownname VARCHAR2,
tabname VARCHAR2,
partname VARCHAR2 DEFAULT NULL,
estimate_percent NUMBER DEFAULT to_estimate_percent_type
(get_param('ESTIMATE_PERCENT')),
block_sample BOOLEAN DEFAULT FALSE,
method_opt VARCHAR2 DEFAULT get_param('METHOD_OPT'),
degree NUMBER DEFAULT to_degree_type(get_param('DEGREE')),
granularity VARCHAR2 DEFAULT GET_PARAM('GRANULARITY'),
cascade BOOLEAN DEFAULT to_cascade_type(get_param('CASCADE')),
stattab VARCHAR2 DEFAULT NULL,
statid VARCHAR2 DEFAULT NULL,
statown VARCHAR2 DEFAULT NULL,
no_invalidate BOOLEAN DEFAULT to_no_invalidate_type (
get_param('NO_INVALIDATE')),So what exactly is the value for GRANULARITY? Do you know?
Well it can make a big difference. If you don't know you need to find out.
>
As mentioned earlier - I accepted all the "defaults".
>
Saying 'I used the default' only helps WHEN YOU KNOW WHAT THE DEFAULT VALUES ARE!
Now can we get back to the issue?
If you had read the excerpt I provided you should have noticed that the values
used for GRANULARITY and INCREMENTAL have a significant influence on the stats gathered.
And you should have noticed that the excerpt mentions full table scans exactly like yours.
So even though you said this
>
Had expected that as the table was in incremental mode
>
Why did you expect this? You said you used all default values. The excerpt I provided
says the default value for INCREMENTAL is FALSE. That doesn't jibe with your expectation.
So did you check to see what INCREMENTAL was set to? Why not? That is part of troubleshooting.
You form a hypothesis. You gather the facts; one of which is that you are getting a full table
scan. One of which is you used default settings; one of which is FALSE for INCREMENTAL which,
according to the excerpt, causes full table scans which matches what you are getting.
Conclusion? Your expectation is wrong. So now you need to check out why. The first step
is to query to see what value of INCREMENTAL is being used.
You also need to check what value of GRANULARITY is being used.
And you say this
>
Or that I really don't know how to gather stats on partitioned tables and it's all my fault - in which case - please let me know - and don't hold back!!!
I'd rather find a solution than save my reputation!!
>
Yet when I provide an excerpt that seems to match your issue you cop an attitude.
I gave you a few pointers of where to look next and you fault us for not knowing the default
values for all parameters for all versions of Oracle for all OSs.
How disingenous is that?

Updating LAST_ANALYZED with automatic stats gathering

I am looking at the last_analyzed column in dba_tables and it shows some tables have not been analyzed since early April last year. But the scheduler is running the stats gathering program nightly. What gives?

That's probably why. Here is the excerpt from Oracle Documentation regarding the job:
The GATHER_STATS_JOB job gathers optimizer statistics by calling the DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC procedure. The GATHER_DATABASE_STATS_JOB_PROC procedure collects statistics on database objects when the object has no previously gathered statistics or the existing statistics are stale because the underlying object has been modified significantly (more than 10% of the rows).The DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC is an internal procedure, but its operates in a very similar fashion to the DBMS_STATS.GATHER_DATABASE_STATS procedure using the GATHER AUTO option. The primary difference is that the DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC procedure prioritizes the database objects that require statistics, so that those objects which most need updated statistics are processed first. This ensures that the most-needed statistics are gathered before the maintenance window closes.

Auto Stats Collection on function based indexes

In 10g does AUTO Stats Collection job in the default weeknight / weekend window collect stats on "function based indexes".
Thank You
Message was edited by:
user449511
I got the reply in another similar post posted by me some time earlier.
Thank You
Message was edited by:
user449511

SELECT job_name, comments
FROM dba_scheduler_jobs;Then refine your search using the columns in the view.

Comments on "Auto" Stats collection practice in 10g

We going to implement auto stat collection practice in our production env. Can someone on this forum comment on the results / experiences ? As per Tom Kytes he is sceptical on going with this practice because it uses AUTO method_opt option which actually can result in different stats being collected based on column usage and data distribution.
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:52288431326913.
Thank You

Hi
Can someone on this forum comment on the results / experiences ?As for any "automatic feature" it works fine in many situations but not always. You have to test it to know if in your situation it is usable or not. IMHO it makes sense to give it a try...
can result in different stats being collected based on column usage
and data distribution.This is the purpose of AUTO. So, no news here.
HTH
Chris

Oracle E-Business 12.1.3/11.2.0.3 Stats Gathering

Hi forum
I am running schema stats (weekly) using the Gather Schema Stats Conc job.
This is done for all schema's as well as the custom schema we use.
Should I be running any additional stats gathering for SYS and SYSTEM tables / indexes?
Does anyone know what the best practice is?
Thanks

Please see (EBPERF FAQ - Collecting Statistics in Oracle EBS 11i and R12 (Doc ID 368252.1)).
Thanks,
Hussein

Stats gathering

Hi All,
oracle 11gr2
Linux
am new to database, how to gather statistics in oracle 11g? like database/schema/table wise?
what is the impact gathering stats daily basis? how to automate stats gathering database wise?
can anyone please suggest & explain with example if possible.
thanks,
Sam.

AUTO_SAMPLE_SIZE lets Oracle Database determine the best sample size necessary for good statistics, based on the statistical property of the object. Because each type of statistics has different requirements, the size of the actual sample taken may not be the same across the table, columns, or indexes.from the link posted before by Aman
If you ommited this clause, full scan will be done: (again in the document attached by Aman)
Gathering statistics without sampling requires full table scans and sorts of entire tables. Sampling minimizes the resources necessary to gather statistics

Exclude TAO tables from stat gathering

Hi,
on FSCM 9.1, Tools 8.52. on Windows 2008. DB Oracle 11g R2.
Automatic stat gathering, collects statistics for temporary tables PS_XXX_TAO. This distorts the Explain plans cardinality but if I delete the statistics :
dbms_stats.delete_table_stats(ownname=>'SYSADM',tabname=>'PS_XXX_TAO');
But it is not permanent and the stats are re collected during the night.
-how to ran a definite delete for that tables ? I mean delete one time but for a permanent result ?
or
-how to exclude these two tables from automatic stat gathering ?
Thanks.

thank you I applied :
exec dbms_stats.lock_table_stats('ADAM','B')
Any Poeplesoft recommendation in documentaries ?
Regards.

Is 11g auto stats collection automatic on? where can I find this job?

Is 11g auto stats collection automatic on?
I manually created a 11g database, but I did not see auto stats collection job. where can I find this job? or how could I verify this is on?
Thank you.

Found in Automated Maintenance Tasks.

Partition Maintenance and Stats gathering running together

Hi All,
I have a scenario in my production database wherein Partition Maintenance and Stats Gathering jobs begin at the same time (both are run weekly on Sundays only).
Partition Maintenance is a job which basically rebuilds indexes and creates new partitions on tables in the database. While Stats Gathering job gathers stats on database tables.
My question was based on the scenario if we consider - Maintenance job is rebuilding indexes on a table and at the same time Stats gathering job is trying to gather stats for that same table. So will there be any issue caused due to this scenario ??
I would like to know whether there is any issue with their running at the same time ?
Database version: Oracle 10 R2
Environment: Unix AIX version 5.3
Thanks in advance.

Sandyboy036 wrote:
Thanks for the reply.
Could you elaborate what effect could it have on the table or some issues if I were to run both at the same time please ?
Thanks.I would be concerned that statistics would not reflect reality.
A partition could be created and populated & the statistics would not reflect this recent activity.
why are you regularly rebuilding indexes?

Automatic stats gathering

Hi:
I am on 10.2.0.3 and use Automatic stats gathering with statistics_level=Typical, but some of my collegaues say that they "colud not trust Oracle to do this job". We are running PeopleSoft Finacials and HR (practically every module) and things seem fine.
I'd like to get a general feel on this issue. Do you guys us that or run your own scripts? Anybody knows some significant limitations of it?
TIA.

Most 10g databases run fine with automatic stats gathering and this works well 99% of the time.
If you have very specific performance requirements (e.g stock brokers can be fined if transactions don't complete in a certain time) then you cannot afford to have plans change just because the stats changed from an automated dbms_stats job that is not documented or 100% predictable. For these systems DBAs are generally very nervous of any change, and often lock the table stats, set the outline, or disable automatic stats and write their own job.
http://www.contractoracle.com

11g automatic stats gathering

hi *
would you confirm, please, if 11g doesn't have by default enabled automatic stats gathering as 10g has?
My 2nd question is then, what is the best way to set such an automatic job to gather stats on a regular basis? If you have any script/code, please share.

You're right I missed the answer, thanks for your hints.
I know the consequences of disabling stats.
But one should know that the default it's not always the best, e.g. open_cursors parameter.
P.S. Although you gave me the answer I dislike the way you contribute to this thread. You see, you're not my boss, you're not obliged to respond in my thread, so cool down, dear friend. Don't shout with exclamations signs, please.
Perhaps I have no time to do a deep research and need the solution fast, and I believe this forum is also for that reason.
So don't question people's questions, as there are always wrong answers, not questions. If you know the answer, just pass it.
Thanks to all of you,

Stats gathering pl/sql syntax

Hi All:
I'm trying to write PL/SQL to conditionally either run or delete table stats (I am on 10.2.0.3):
The table name is a variable, something like that:
exec dbms_stat.delete_table_stats('MYOWNER','v_table_name');
else
exec dbms_stat.gather_table_stats(ownname=>'MYOWNER',tabname=>'v_table_name',estimate_percent=>'20', method_opt=>'for all column size SKEWONLY');
Two questions:
- what is the syntax to include the variable into the parameter list?
- is there any way to include more than 1 method_opt: ALL INDEXED and SKEWONLY
Thanks!

As 10g is already automatically gathering statistics,.why doe this at all?
Apart from that you would only need
create or replace procedure foo(p_owner in varchar2, p_table_name in varchar2, p_percent in number, p_opt in varchar2) is
begin
-- dbms_stat.delete_table_stats(p_owner,p_table_name);
dbms_stat.gather_table_stats(ownname=>p_owner,tabname=>p_table_name,estimate_percent=>p_percent, method_opt=>p_opt);
end;
exec foo('MY_OWNER' etc..
Just standard PL/SQL!
You only don't need to delete statistics. gather stats will take care of it
Sybrand Bakker
Senior Oracle DBA

Auto Stats Gathering

Similar Messages

Maybe you are looking for