Percent Gathering Statistics with FND_STATS

Hi,
We gather statistics for the schemas and tables in our database using the FND_STATS package. Now we are running it with an 80% sample. Once we run it at 30 % and we had a lot of performance issues.
How can we determine the optimal value for percentage?
What percentage is usually used for E-Business suite?
Thanks in advance for your help.
Carlos

How Often Should Gather Schema Statistics Program be Run?
There is no set schedule for gathering schema statistics. On some systems the program should be run weekly. On other systems once per month will be often enough. The schedule will vary greatly depending on the amount and nature of the data and how often the data changes.
It will be necessary to try different schedules over time and monitor performance to determine the most effective schedule.
As a general rule, run Gather Schema Statistics under the following circumstances:
1. After there has been a significant change in data in either content or volume
2. After importing data
3. Any time end-users notice a deterioration in performance in routine day-to-day business transactions or when running concurrent programs

Similar Messages

Gathering Statistics in 10.7 NCA with 8i Database

In preparation for the 11i upgrade we are first migrating our database to 8i
(strongly recommended Category 1 pre-upgrade step 5).
I have contacted Oracle Support on whether it is recommended to gather
statistics in a 10.7 NCA environment (optimizer_mode remains RULE). Oracle
Support says NOT to gather statistics in a 10.7 environment.
This is contradictory information to several documents I have found.
Furthermore, Oracle has provided ADXANLYZ.sql and FND_STATS for the 10.7
environment.
The following sources recommend gathering statistics in a 10.7 environment:
1) 10.7 Installation Manual (A47542-1) page A-16
2) 11i Upgrade Manual (A69411-01) page 2-5
3) Metalink note 1065584.6
Can somebody please clarify? Your feedback is much appreciated.
Thank you,
Rich
null

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Rich Cisneros:
We will be running 10.7 NCA in a server partitioned mode for 6-8 month using 7.3.4.4 with 8.1.6.2.
Should I gather statistics as part of the 8i database upgrade (still 10.7) or part of the 11i Application upgrade?<HR></BLOCKQUOTE>
Rich,
Gather Statistics is only relevant to databases running with optimiser mode = COST or CHOOSE. Apps 10.7 runs with optimiser mode = RULE so you don't need to gather statistics until you start your actual upgrade to 11i, which will run with CBO.
Hope this makes it clear.
Steve

Best practices for gathering statistics in 10g

I would like to get some opinions on what is considered best practice for gathering statistics in 10g. I know that 10g has auto statistics gathering, but that doesn't seem to be very effective as I see some table stats are way out of date.
I have recommended that we have at least a weekly job that generates stats for our schema using DBMS_STATS (DBMS_STATS.gather_schema_stats). Is this the right approach to generate object stats for a schema and keep it up to date? Are index stats included in that using CASCADE?
Is it also necessary to gather system stats? I welcome any thoughts anyone might have. Thanks.

Hi,
Is this the right approach to generate object stats for a schema and keep it up to date? The choices of executions plans made by the CBO are only as good as the statistics available to it. The old-fashioned analyze table and dbms_utility methods for generating CBO statistics are obsolete and somewhat dangerous to SQL performance. As we may know, the CBO uses object statistics to choose the best execution plan for all SQL statements.
I spoke with Andrew Holsworth of Oracle Corp SQL Tuning group, and he says that Oracle recommends taking a single, deep sample and keep it, only re-analyzing when there is a chance that would make a difference in execution plans (not the default 20% re-analyze threshold).
I have my detailed notes here:
http://www.dba-oracle.com/art_otn_cbo.htm
As to system stats, oh yes!
By measuring the relative costs of sequential vs. scattered I/O, the CBO can make better decisons. Here are the data items collected by dbms_stats.gather_system_stats:
No Workload (NW) stats:
CPUSPEEDNW - CPU speed
IOSEEKTIM - The I/O seek time in milliseconds
IOTFRSPEED - I/O transfer speed in milliseconds
I have my notes here:
http://www.dba-oracle.com/t_dbms_stats_gather_system_stats.htm
Hope this helps. . . .
Don Burleson
Oracle Press author
Author of “Oracle Tuning: The Definitive Reference”
http://www.dba-oracle.com/bp/s_oracle_tuning_book.htm

Implications of not gathering statistics

Hi,
I have a scenario that is provoking vigorous debate in my workplace and may do so here.
We have a table with about 70 million rows in it. It grows at the rate of about 3-4 million rows a month, the rows being loaded daily rather than in one lot at the end of the month. Gathering statistics takes about 6 hours and takes a significant part of our 9 hour window for completion of various batch jobs, including loading the new rows.
The new rows do have quite different values in certain columns (some indexed) to the existing data. However, as these rows are processed over the course of a week they will come to look just like the existing rows.
The action that we're considering is to stop gathering statistics after every large data load and instead to do this every few months instead on the basis that the new data should not skew the balance of the existing data significantly. However, this has divided opinions.
The database is running on Oracle 10g R2.
Any thoughts?
Russell.

Oracle's default collection may or may not be the best for you given the size.
For a table this large you should have the partitioning option. If you do then you should write your own stats collection to only look at active partitions and, if possible, set archival data partition's tablespaces to READ ONLY.
Then with respect to collection ... do some research on what estimate percentage gives you stats good enough to support a good plan. In 10gR2 this may be a very high number. With 11g and above the default collection seems sufficiently improved you can trust it.
SB advises "let Oracle be Oracle" and I agree. Right up until doing that hurts performance and interferes with the primary purpose of the database: Supporting your organization and its customers.

How important is gathering statistics on SYS objects?

Hi,
How important is gathering statistics on Data dictionary tables and other X$ tables in SYS schema. Is it bad to keep the statistics. Recently our Sr.DBA has deleted all the SYS schema stats telling that it will inversely affect the DB performance. Is it true?
Regards
Satish

Hi Satish,
*10g:*
A new DBA task in Oracle Database 10g is to generate statistics on data dictionary objects which are contained in the SYS schema. The stored procedures dbms_stats.gather_database_stats and dbms_stats.gather_schema_stats can be used to gather the SYS schema stats. Here is an example of using dbms_stats.gather_schema_stats to gather data dictionary statistics:
EXEC dbms_stats.gather_schema_stats(’SYS’);
*9i*
While it is supported in 9.2 to gather statistics on the data dictionary and fixed views, doing so isn't the norm.
There is a bug fixed only in 10gR2 (not expected to be back-ported to 9.2) that caused this error. The fix is – don’t generate statistics against SYS – especially not the Fixed tables.
For this query, let's see if we can get a better plan by removing statistics or by getting better statistics, or if we need to do something else to tune it. Take the SYS statistics as before, but with gather_fixed => false.
I would like for you to test first by deleting the statistics on these two X$ tables and see how the query runs (elapsed time, plan).
delete_table_stats('SYS','X$KQLFXPL');
delete_table_stats('SYS','X$KGLOB');
Then you can take statistics on them using gather_table_stats and check again (elapsed time, plan).
gather_table_stats('SYS','X$KQLFXPL');
gather_table_stats('SYS','X$KGLOB');
The issue with this is that the contents of these fixed views, particularly x$kqlfxpl, can change dramatically. Gathering fixed object statistics may help now and cause problems later as the contents change.
Warning, this is a bit dangerous due to latch contention, see the following note. I've supported a couple of very busy systems that were completely halted for a time due to latch contention on x$kglob due to monitoring queries (particularly on v$open_cursors).
Note.4339128.8 Ext/Pub Bug 4339128 - Heavy latch contention from queries against library cache views.
Hope this answers your question . . .
Donald K. Burleson
Oracle Press author
Author of "Oracle Tuning: The Definitive Reference":
http://www.dba-oracle.com/bp/s_oracle_tuning_book.htm

Gathering statistics on interMedia indexes and tables

Has anyone found any differences (like which one is better or worse) between using the ANALYZE sql command, dbms_utility package, or dbms_stats package to compute or estimate statistics for interMedia text indexes and tables for 8.1.6? I've read the documentation on the subject, but it is still unclear as to which method should be used. The interMedia text docs say the ANALYZE command should be used, and the dbms_stats docs say that dbms_stats should be used.
Any help or past experience will be grateful.
Thanks,
jj

According to the Support Document "Using statistics with Oracle Text" (Doc ID 139979.1), no:
Q. Should we gather statistics on the underlying DR$/DR# tables? If yes/no, why?
A. The recommendation is NO. All internal recursive queries have hints to fix the plans that are deemed most optimal. We have seen in the past that statistics on the underlying DR$ tables may cause query plan changes leading to serious query performance problems.
Q. Should we gather statistics on Text domain indexes ( in our example above, BOOKS_INDEX)? Does it have any effect?
A: As documented in the reference manual, gathering statistics on Text domain index will help CBO to estimate selectivity and costs for processing a CONTAINS() predicate. If the Text index does not have statistics collected, default selectivity and cost will be used.
So 'No' on the DR$ tables and indexes, 'yes' on the user table being indexed.

Relation between computing and gathering statistics

Hi gurus,
What is the relation between computing and gathering statistics for a database object.Are they mutually dependent or one doesn't have anything to do with the other?How they affect performance of a database??
plz dont redirect..just bottom lines are expected(be specific)
Thanks in advance
anirban

computing term used to collect 100% statistics along with analyze command.
gather stats is a new package provided by the oracle, also recommend to use this instead of analyze. You can also take 100% stats, like compute with analyze command, in gather stats pacakge, parameter estimate_percent=>null.
exec dbms_stats.gather_table_stats('SCHEMA',TABLE',cascade=>true,estimate_percent=>NULL);
Jaffar

Gathering statistics manually in 10g !!

Hi, all.
The database is 2 node RAC 10.2.0.2.0.
By default, 'GATHER_STATS_JOB' job is enabled and it takes statistics of
"ALL objects in a database" every 22:00 on a daily basis.
(objects that have changes more than 10% of the rows).
I found that the default job is causing library cache lock wait event by
invalidating objects too frequently in the shared pool
( especially in a RAC environment).
Therefore, I am considering taking statistics only for application schema
on a weekly basis by using "DBMS_STATS.GATHER_SCHEMA_STATS" procedure.
"EXECUTE DBMS_STATS.GATHER_SCHEMA_STATS('NMSUSER',DBMS_STATS.AUTO_SAMPLE_SIZE);"
takes statistics of all objects of NMSUSER schema.
I would like to take statistics for objects that have more than "10% changes"
of rows.
What is the option for that??
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_stats.htm#sthref8115
Thanks and Regards.
Message was edited by:
user507290

Be very careful taking statistics with default setting of method_opt => 'FOR ALL COLUMNS SIZE AUTO' in 10g.
Check the number of histograms you have (dba_tab_columns and dba_tab_histograms).
The results may not be what you expect ...
And they may be playing a part in your latch issues.
Cheers
Richard Foote

AWR snapshot not generatedand how to compare statistics with a baseline

01. AWR snapshot not being generated even after setting looks fine
02. compare a captured set of statistics with a baseline.
i m not much clear on this, please help as i have this requirement at hand.
Thanks a lot in advance.

01.
SQL> show parameter statis
NAME TYPE VALUE
statistics_level string TYPICAL
I explicitly run and did cntl^C as it looks running endless... (waited almost 2-3 hours).
SQL> exec dbms_workload_repository.create_snapshot;
^CBEGIN dbms_workload_repository.create_snapshot; END;
ERROR at line 1:
ORA-01013: user requested cancel of current operation
looks like job_name is enabled.
GATHER_STATS_JOB TRUE WEEKNIGHT_WINDOW
freq=daily;byday=MON,TUE,WED,THU,FRI;byhour=22;byminute=0; bysecond=0
GATHER_STATS_JOB TRUE WEEKEND_WINDOW
freq=daily;byday=SAT;byhour=0;byminute=0;bysecond=0
anything else can be checked, i dont have access to OEM..must be done at SQL prompt.
02. thanks for info. i understand.. how do we compare set of snapshots with baseline(which is actually pair/range of snapshot kept for further comparison)
no access to OEM. must be done at SQL prompt.
please help in both. thanks ...

Gathering statistics on partitioned and non-partitioned tables

Hi all,
My DB is 11.1
I find that gathering statistics on partitioned tables are really slow.
TABLE_NAME                       NUM_ROWS     BLOCKS SAMPLE_SIZE LAST_ANALYZED PARTITIONED COMPRESSION
O_FCT_BP1                        112123170     843140    11212317 8/30/2011 3:5            NO                    DISABLED
LEON_123456                      112096060     521984    11209606 8/30/2011 4:2           NO                   ENABLED
O_FCT                           115170000     486556      115170 8/29/2011 6:3            YES
SQL> SELECT COUNT(*) FROM user_tab_subpartitions
2 WHERE table_name =O_FCT'
3 ;
COUNT(*)
       112I used the following script:
BEGIN
DBMS_STATS.GATHER_TABLE_STATS(ownname          => user,
                                tabname          => O_FCT',
                                method_opt       => 'for all columns size auto',
                                degree           => 4,
                                estimate_percent =>10,
                                granularity      => 'ALL',
                                cascade          => false);
END;
/It costs 2 mins for the first two tables to gather the statistics respectively, but more than 10 mins for the partitioned table.
The time of collecting statistics accounts for a large part of total batch time.
And most jobs of the batch are full load in which case all partitions and subpartitions will be affected and we can't just gather specified partitions.
Does anyone have some experiences on this subject? Thank you very much.
Best regards,
Leon
Edited by: user12064076 on Aug 30, 2011 1:45 AM

Hi Leon
Why don't you gather stats at partition level? If your partitions data is not going to change after a day (date range partition for ex), you can simply do at partition level
GRANULARITY=>'PARTITION' for partition level and
GRANULARITY=>'SUBPARTITION' for subpartition level
You are gathering global stats every time which you may not require.
Edited by: user12035575 on 30-Aug-2011 01:50

Urgent Help Needed - Associating Statistics with User-Defined Functions

Hello,
We have an appication uses cost-based optimizer and uses a lot of TO_DATE and SYSDATE calls in FROM and WHERE clauses. For certain reasons, every call to TO_DATE and SYSDATE has been replaced by MY_TO_DATE and MY_SYSDATE respectively (which in turn call built-in functions). However, cost based optimizer is behaving strangely, which is understanble, based on the lack of user-defined functions statistics. I am under the impression that I should use something like:
ASSOCIATE STATISTICS WITH FUNCTIONS my_to_date DEFAULT SELECTIVITY ?;
ASSOCIATE STATISTICS WITH FUNCTIONS my_to_date COST (?,?,?);
ASSOCIATE STATISTICS WITH FUNCTIONS my_sysdate DEFAULT SELECTIVITY ?;
ASSOCIATE STATISTICS WITH FUNCTIONS my_sysdate COST (?,?,?);
but what should the values (?) be?. I guess I want to replicate TO_DATE and SYSDATE values, but how would I find out what they are? Thanks in advance...
P.S. I am also looking for workarounds (I cannot create a synonym for TO_DATE right?), so any help is welcome!!!

Hi emmalou69 ,
You told your actual parameter is
5, 5, 7.3 and 'z'
so change your method like
public static int test(int x, int y, double d, char ch)
because 5 - int; 7.3- float or double; z is char.
your method returns
public static int.
so you should return only int variable. but in your code you mentioned double. it's not correct.
The original code should look like
public class rubbish
     public static void main(String args[]){
          rubbish f = new rubbish();
          f.test(5, 5, 7.3 ,'z');
     public static int test(int x, int y, double d, char ch)
          int value;
          x = 5;
          y = 5;
          d= 7.3;
          ch = 'z';
          value =((int) d + x + y + ch);
          System.out.println( x + ch + d + y);
          return value;
}//here int value of z is 122.
and int(7.3) is 7
so 7+5+5+122 = 139.3
but value =((int) d + x + y + ch); returns 139. because you convert double to int that is 7.3 to 7
If it is useful, rate me duke dollars,
Thanks

Gathering table only statistics with DBMS_SCHEDULER

Version:10gR2
I have statistics gathering sql file called gather_emp_stats.sql whose contents are as follows
begin
dbms_stats.gather_table_stats('SCOTT', 'EMP',
estimate_percent=>100,
no_invalidate=>FALSE,
degree => DBMS_STATS.DEFAULT_DEGREE,
cascade=>TRUE);
end;How can i run the above .sql script every five minutes using DBMS_SCHEDULER?
begin
dbms_scheduler.create_job(
      job_name => 'gather_emp_statistics'
     ,job_type => 'PLSQL_BLOCK'
     ,job_action => '??----??'
     ,start_date => sysdate
     ,repeat_interval => 'FREQ=MINUTELY;INTERVAL=5'
     ,enabled => TRUE
     ,comments => 'Gathering stats for EMP table.');
end;

If you don't insist of using a file (I think scheduler can do files too, but I don't know the syntax currently).
Simply put the command in one line and use it as parameter
begin
dbms_scheduler.create_job(
      job_name => 'gather_emp_statistics'
     ,job_type => 'PLSQL_BLOCK'
     ,job_action => 'dbms_stats.gather_table_stats(''SCOTT'', ''EMP'', estimate_percent=>100, no_invalidate=>FALSE, degree => DBMS_STATS.DEFAULT_DEGREE, cascade=>TRUE);'
     ,start_date => sysdate
     ,repeat_interval => 'FREQ=MINUTELY;INTERVAL=5'
     ,enabled => TRUE
     ,comments => 'Gathering stats for EMP table.');
end;
/

Affect of Gathering Statistics on Performance........

Hello All,
When schema/table statistics need to gathered and why ?
In Pick business time or in non business hour

With SQL Plan Management, I found that it can really screw up your database performance if you have queries which don't make use of the bind variables.
I found this out when I enabled it for our Production Exadata machine: most of the queries are well-coded, boxed queries which make use of bind variables perfectly.
However, there was one application (a .NET one) which simply refused to use them. Every time it executed (and it executed a LOT), it would use dynamic statements with literal values. This caused the Plan Management to BALLOON from something reasonable to 600 billion rows. At the start, no-one noticed and people liked the plan stability, but then the whole database started to crawl because every statement referenced the HUGE table.
Needless to say, the coders of the application wouldn't budge from their insistence on literal values because THEIR code was dynamically generated from a 'core' which had no understanding of them. I was very disappointed when I had to turn it off as it's a great feature. Bad coding beats great features anytime, though.
As for gathering stats, I've found that the automated job which runs in the maintenance window does a fairly good job. We haven't change the estimate_percent defaults and sometimes we have to compute statistics on a couple of awkward tables (i.e. estimate_percent at 100) manually. But it's pretty solid.
If you wanted to know what tables have 'stale' stats, you can query dba_tab_statistics and look for the stale_stats column.
Mark

Gathering statistics in 8.1.7.4

Hi
I 10g there is a default job to collect statistics
can somebody refer me to code that can do the same on 8.1.7.4
in 8.1.7.4
also is the "bytes" column in the dba_tables is updated automatically , when rows inserted and deleted.
or we need to dbms_stats.gather_table_statistics() , same as in 10g
Thanks

thanks very much
bytes.dba_tables look need gathering the statistics
but
bytes.dba_segments look DOES NOT need gathering the statistics
i tested it , so i think i can rely on that
also
SQL> sho parameter opt
NAME TYPE VALUE
object_cache_optimal_size integer 102400
optimizer_features_enable string 8.1.7
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_max_permutations integer 80000
optimizer_mode string CHOOSE
optimizer_percent_parallel integer 0

Changing battery symbol to percent and playing with Jambox

Hi,
Two questions:
1. Can I change the battery icon on top of my iPod touch 4g from battery symbol to one with percent like I have on my iPad 2?
2. Does playing music with Jambox will drain my iPod battery more quickly the iPod earphones?
Thanks,
Amnon

1. No.
2. Check with Jawbone on this one. They should be able to provide you with a clear answer.
B-rock

Percent Gathering Statistics with FND_STATS

Similar Messages

Maybe you are looking for