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.

Similar Messages

Exclude a table from time-based reduction

Hi,
Iu2019d like to exclude a table from time-based reduction. How can I do this ? Is there any manual how to do customizing in TDMS ?
Regards
p121848

Thank you Markus for your annotation.
AUFK is technically declared as an Master Data Table, but stores orders. Standard
TDMS provides a reduction of this file and in the client copies we did via TDMS a lot of records disappeared when we selected time-reduction.
Now we fond out that some Transactions as OKB9 or KA03 refer to old internal orders. So we would like to maintain the customizing, to exclude AUFK from reduction. But this is not possible in activity TD02P_TABLEINFO, because no changes can be done to the tables, which have got the transfer_status 1 = Reduce.
You can manipulate the Transfer-Status in file CNVTDMS_02_STEMP before getting to activity TD02P_TABLEINFO, but I wonder whether this is the way one should do.
Any idea ?
Regards p121848

Exclude a table from GATHER SCHEMA STATISTICS

Hello All,
How do you exclude a table from gather schema statistcs?
Thanks.
Gregg

hi,
it is explained here:--
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_stats.htm#i1043993
LOCK_TABLE_STATS Procedure
This procedure locks the statistics on the table.
Syntax
DBMS_STATS.LOCK_TABLE_STATS (
ownname VARCHAR2,
tabname VARCHAR2);
thanks.
Edited by: varun4dba on Dec 10, 2010 7:39 PM

How to exclude some tables from schema level replicatio????

Hi,
I am working on oracle10g stream replication.
My replication type is "Schema Based".
So can anyone assist me to undersatnd, how to exclude some tables from schema based replication.
Thanks,
Faziarain

You can use rules and include them in the rule set, lets say you dont want LCR to be queued for table_1 in schema SALES, write two rules one for DDL and another for DML with NOT logical condition.
DBMS_RULE_ADM.CREATE_RULE(
rule_name => 'admin.SALES_not_TALBE_1_dml', condition => ' (:dml.get_object_owner() = ''SALES'' AND NOT ' ||
' :dml.get_object_name() = ''REGIONS'') AND ' ||
' :dml.is_null_tag() = ''Y'' ');
DBMS_RULE_ADM.CREATE_RULE(
rule_name => 'admin.hr_not_regions_dlll',
condition => ' (:dml.get_object_owner() = ''SALES'' AND NOT ' ||
' :ddl.get_object_name() = ''table_!'') AND ' ||
' :dsl.is_null_tag() = ''Y'' ');
just go through this document once, http://download.oracle.com/docs/cd/B28359_01/server.111/b28321/strms_rules.htm#i1017376
Edited by: user8710159 on Sep 16, 2009 5:21 PM

Exclude MV Table from gather schema stats

Hey,
I am running the daily stats gathering procedure below.
But it is running at the same time with an MV that is refreshing,and it's failing due to that.
Is it possible to exclude the Materialized view from the below schema stats procedure?
BEGIN
dbms_stats.gather_schema_stats(ownname=>'SCOTT',estimate_percent=>dbms_stats.auto_sample_size,degree=>2);
END;
This is running on Oracle 10.2.1.0, on Linux env.

You could lock the statistics onto the tables you don't want to re-gather stats : dbms_stats.lock_table_stats
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_stats.htm#i1043993
Then run the mentioned command will not compute stats on those objects.
Nicolas.

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?

How do I exclude tables from Dataguard?

We are in the process of setting up Dataguard on an Oracle EE 12c RHEL 6 installation. Our primary database contains a set of tables that are used to send automatic email messages to our users. We do not want them to receive additional emails from the standby database as well. Is it possible to exclude these tables from Dataguard, or will we need a job to work against the standby database that will nullify these emails?
Cheers

>>Our primary database contains a set of tables that are used to send automatic email messages to our users.We do not want them to receive additional emails from the standby database as well. Is it possible to exclude these tables from Dataguard, or will we need a job to work against the standby database that will nullify these emails?
It depends on how have you got setup working.
If it is an OS level script or job sending email then you do not need to have the same script running on Standby database.
If it is running as a scheduler job, and your database is 11.1 above you can look into this note,
http://docs.oracle.com/cd/B28359_01/server.111/b28310/schedover010.htm#BGBJCFCB
Examples can be fount at - http://docs.oracle.com/cd/B28359_01/server.111/b28310/schedadmin006.htm#ADMIN12506
HTH,
Pradeep

How to exclude a table when doing dbcc checkdb

when running dbcc checkdb(mydb). it will go through all tables. Is it possible to exclude a table from dbcc checkdb?

Thanks, Mark. When I run dbcc checkdb(mydb), it across a table and take over 18 hours and still waiting.
the message is:
Checking mytable: Logical pagesize is 2048 bytes
The total number of data pages in this table is 1365692.
The total number of pages which could be garbage collected to free up some space is 2923.
then I stop it manually.
Possibly something wrong with the table. When I run dbcc checktable on this table, it' also keep me waiting and never end. then I can't finish dbcc checkdb because of this table. the size of this table is about 3G. How to resolve this problem?

How to exclude tables from default scheduled stats job in 10.2.0.4

I am using Oracle default stats job GATHER_STATS_JOB in my database. But i need to exclude stats gathering for few tables as part of my business requirement.

Welcome to the forums.
As I am sure you read the docs on DBMS_STATS at tahiti.oracle.com what was it about the method for addressing it in the docs that you don't think will work for you.
Hint: The correct answer to my question is not "I didn't read the docs because I thought someone here would read them for me." ;-)

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

Exclude GUID field from tables in tdms transfer.

Hi,
We have been asked chek whether it is possible to exclude GUID fileds from tables in TDMS ERP data transfer.
We ran data replication from ECC to CRM in out pre-prod system, replication populated the CRM GUIDs in ECC. We are going to use pre-prod as sender system for TDMS transfer. GUID field is part of the corresponding object table so the receiver system tables also populated with GUID. What we don't know is how replication behaves when the GUIDs are already populated.
As I know there is a way to set the GUID filed to NULL value in tdms transfer using scrambling rule. The only concern I am having is how this could affect the ISU data in other tables.
Please share your opinions on this.
Thanks
Praveen.

The "GUID fields" are used to normalize the data and is the key fields for all CRM applications. If you don't transfer those the system will be "empty" because data relations cannot be found.
Markus

Skip gather stats for a partition | table from the gather_stats_job in 10g

Hi all,
Can we skip gather statistics for a table or a partition in a partitioned-table from the GATHER_STATS_JOB in Oracle 10g ?
(cause that partition store in an offline-datafile, so GATHER_STATS_JOB had errors when running in sheduled).
Thanks.
Edited by: user8710247 on Nov 26, 2011 6:41 PM

GATHER_TABLE_STATS will default to GRANULARITY 'AUTO' which will include Global and Partition Statistics. Global Statistics have to be across all the Partitions -- so Oracle will attempt to read all the partitions for this !
You need to run GATHER_TABLE_STATS with GRANULARITY 'PARTITION' and naming the other Partitions --- i.e. run it for each of the online partitions.
See :
SQL> create table XYZ (col_1 number, col_2 varchar2(5))
2 partition by range (col_1)
3 (partition P1 values less than (10) tablespace HEMANT,
4 partition P2 values less than (100) tablespace USERS)
5 /
Table created.
SQL> insert into XYZ values (5,'Five');
1 row created.
SQL> insert into XYZ values (50,'Fifty');
1 row created.
SQL> exec dbms_stats.gather_table_stats('','XYZ',estimate_percent=>100,granularity=>'ALL');
PL/SQL procedure successfully completed.
SQL> select partition_name, tablespace_name , num_rows, sample_size from user_tab_partitions
2 where table_name = 'XYZ'
3 /
PARTITION_NAME                 TABLESPACE_NAME                  NUM_ROWS
SAMPLE_SIZE
P1                             HEMANT                                  1
          1
P2                             USERS                                   1
          1
SQL>
SQL> exec dbms_stats.lock_table_stats('','XYZ');
PL/SQL procedure successfully completed.
SQL> alter tablespace HEMANT offline;
Tablespace altered.
SQL> exec dbms_stats.gather_table_stats('','XYZ',estimate_percent=>100,granularity=>'ALL');
BEGIN dbms_stats.gather_table_stats('','XYZ',estimate_percent=>100,granularity=>'ALL'); END;
ERROR at line 1:
ORA-20005: object statistics are locked (stattype = ALL)
ORA-06512: at "SYS.DBMS_STATS", line 13159
ORA-06512: at "SYS.DBMS_STATS", line 13179
ORA-06512: at line 1
SQL>
SQL> exec dbms_stats.unlock_table_stats('','XYZ');
PL/SQL procedure successfully completed.
SQL> exec dbms_stats.lock_partition_stats('','XYZ','P1');
PL/SQL procedure successfully completed.
SQL> exec dbms_stats.gather_table_stats('','XYZ',estimate_percent=>100,granularity=>'ALL');
BEGIN dbms_stats.gather_table_stats('','XYZ',estimate_percent=>100,granularity=>'ALL'); END;
ERROR at line 1:
ORA-00376: file 2 cannot be read at this time
ORA-01110: data file 2:
'/usr/oracle/oradata/MONDB/datafile/o1_mf_hemant_7d6m8zkx_.dbf'
ORA-06512: at "SYS.DBMS_STATS", line 13159
ORA-06512: at "SYS.DBMS_STATS", line 13179
ORA-06512: at line 1
SQL>
SQL> exec dbms_stats.gather_table_stats('','XYZ',estimate_percent=>100,partname=>'P2');
BEGIN dbms_stats.gather_table_stats('','XYZ',estimate_percent=>100,partname=>'P2'); END;
ERROR at line 1:
ORA-00376: file 2 cannot be read at this time
ORA-01110: data file 2:
'/usr/oracle/oradata/MONDB/datafile/o1_mf_hemant_7d6m8zkx_.dbf'
ORA-06512: at "SYS.DBMS_STATS", line 13159
ORA-06512: at "SYS.DBMS_STATS", line 13179
ORA-06512: at line 1
SQL> exec dbms_stats.gather_table_stats('','XYZ',estimate_percent=>100,partname=>'P2',granularity=>'GLOBAL AND PARTITION');
BEGIN dbms_stats.gather_table_stats('','XYZ',estimate_percent=>100,partname=>'P2',granularity=>'GLOBAL AND PARTITION'); END;
ERROR at line 1:
ORA-00376: file 2 cannot be read at this time
ORA-01110: data file 2:
'/usr/oracle/oradata/MONDB/datafile/o1_mf_hemant_7d6m8zkx_.dbf'
ORA-06512: at "SYS.DBMS_STATS", line 13159
ORA-06512: at "SYS.DBMS_STATS", line 13179
ORA-06512: at line 1
SQL>
SQL> exec dbms_stats.gather_table_stats('','XYZ',estimate_percent=>100,partname=>'P2',granularity=>'PARTITION');
PL/SQL procedure successfully completed.
SQL>Hemant K Chitale

Is it possible to exclude white space from creating records using UNPIVOT

SELECT
        FROM
            Table1
            UNPIVOT EXCLUDE NULLS
                NEW_COLUMN
                FOR COLUMN_NAME IN
                   FIELD1, field2, --------------FIELD20
            )I don't want to create row for whitespace (empty value) in any of field1-field20 columns. Row should create for each of value present in any of FIELD1-FIELD20. Is it possible to exclude white space from creating records using UNPIVOT? I am just looking for syntax if there any. thanks

Hi,
Sorry, it's very unclear what you want.
Whenever you have a question, please post a little sample data (CREATE TABLE and INSERT statements, relevant columns only) for all the tables involved, and the results you want from that data.
Explain, using specific examples, how you get those results from that data.
Always say what version of Oracle you're using (e.g. 11.2.0.2.0).
See the forum FAQ {message:id=9360002}
Have you tried the the UNPIVOT EXCLUDE NULLS option? See the SQL Language manual for details.
It that doesn't do what you want, then you may need to UNPIVOT in a sub-query, generating more rows than you want, and use a WHERE clause in the main query to remove the unwanted rows.

Excluding slow table access in a UNION ALL view

Hi,
I have a view which unions three tables together.
One component of the view requires a table scan, as 90% of the records are required.
This view is then used in another outer select where these records are actually not required.
So I tagged each component with a code and excluded that in the outer select. However it still appears to access the table.
Is there any way I can exclude a component of the UNION ALL or do I need to explicitly split them?
example:
SELECT * FROM (
SELECT 'A' Q, JANUARY F FROM ENORMOUS.TABLE WHERE KEY = 'Non Selective Key' UNION ALL
SELECT 'B' Q, 1 F FROM DUAL UNION ALL
SELECT 'C' Q, 1 F FROM DUAL
) A
WHERE Q = 'B'
When I run the query plan without the WHERE it performs the table scan
When I include the WHERE it still performs the table scan but with a FILTER NULL IS NOT NULL afterwards.
So it appears that it is doing the table scan regardless and then throwing the records away - is that correct?
Any thoughts appreciated. I would prefer not the split this view out if possible as it is used everywhere.

In summary my question is: is The Oracle query planner smart enough to exclude a component from a load of stacked UNION ALL queries?
given this query:
CREATE VIEW TEST AS
SELECT Q, F
FROM
SELECT 'A' Q, JANUARY F FROM ENORMOUS.TABLE WHERE KEY = 'Non Selective Key' UNION ALL
SELECT 'B' Q, 1 F FROM DUAL UNION ALL
SELECT 'C' Q, 1 F FROM DUAL
) A;
-- 1. This one selects from all tables, including a table scan on the enormous table
SELECT * FROM TEST;
-- 2. This one selects from all tables, including a table scan on the enormous table
-- However the query plan has a FILTER after the table scan. Does it exclude this work?
SELECT * FROM TEST WHERE Q = 'B';When I run the query plan without the WHERE it performs the table scan
When I include the WHERE the query plan indicates it's doing the table scan but with a FILTER NULL IS NOT NULL afterwards.
So it appears that it is doing the table scan regardless and then throwing the records away - is that correct?
Any thoughts appreciated. I would prefer not the split this view out if possible as it is used everywhere.
Oracle version:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE 11.2.0.2.0 Production
TNS for 64-bit Windows: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production
Plan output for 1:
SELECT STATEMENT Optimizer Mode=ALL_ROWS (Cost=7166 Card=2 M Bytes=41 M)
1 VIEW (Cost=7166 Card=2 M Bytes=41 M)
2 1 UNION-ALL
3 2 TABLE ACCESS FULL PLANNING.BF_GEN_STATS_TRAN (Cost=7162 Card=2 M Bytes=72 M)
4 2 FAST DUAL (Cost=2 Card=1)
5 2 FAST DUAL (Cost=2 Card=1)
Plan output for 2:
SELECT STATEMENT Optimizer Mode=ALL_ROWS (Cost=2 Card=3 Bytes=48)
1 VIEW (Cost=2 Card=3 Bytes=48)
2 1 UNION-ALL
3 2 FILTER
4 3 TABLE ACCESS FULL PLANNING.BF_GEN_STATS_TRAN (Cost=7162 Card=2 M Bytes=72 M)
5 2 FAST DUAL (Cost=2 Card=1)
6 2 FILTER
7 6 FAST DUAL (Cost=2 Card=1)

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

Similar Messages

Maybe you are looking for