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

Similar Messages

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

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

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

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

Automatic Gathering Statistics Script

Hi,
We must to schedule in our database some kind of job in order to monitoring the database and regularly gathering statitics of database objects (nowadays most of tables have been never analyzed). We have read the Oracle documentation in order to use the DBMS_STATS package but we are a bit confused about the enormous possibilities (gather_schema_stats, gather_table_stats,...=
Could some one provide us some kind of help about the basics steps that should contain a simple script that could be scheduled daily in order to mantain fresh table statistics on database?
Thanks

Mmm. this docs refers to 10g version.
We have 9.2.0.7 Standard EdtionYou neglected to mention that in your original post so one must assume that you are on a 'supported release' of oracle - which you aren't:
http://download.oracle.com/docs/cd/B10501_01/appdev.920/a96612/d_stats2.htm#1012974.

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

Need info abt gathering statistics

Hi,
We are using 8.0.6 database and have around 90GB data in our database. Since we are adding lot of data daily, I wanted to know, Do we need to gather/update statistics of all the tables in our database?
1) How gathering/updating statistics will help improve my database.
2) Do i need to have dba priviliges to gather these stats.
3) Do i need to update the stats daily.
4) Do i need to update stats for SYS? I heard it slows down the system.
5) What are the methods in 8.0.6 to gather statistics
Regards,
Ateeq

ateeqrahman wrote:
Hi,
We are using 8.0.6 database and have around 90GB data in our database. Since we are adding lot of data daily, I wanted to know, Do we need to gather/update statistics of all the tables in our database?
1) How gathering/updating statistics will help improve my database.Yes ...
2) Do i need to have dba priviliges to gather these stats.Not Necessary. You should have analyze any table privilege or execute permission on DBMS_STATS.
3) Do i need to update the stats daily.Depends on change in data
4) Do i need to update stats for SYS? I heard it slows down the system.
5) What are the methods in 8.0.6 to gather statisticsPlease read
http://www.oracle-base.com/articles/8i/RefreshingStaleStatistics8i.php
http://www.oracle-base.com/articles/8i/CostBasedOptimizerAndDatabaseStatistics.php
Regards
Rajesh

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

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

Question on gathering statistics in Enterprise Manager

When in EM, choose Server->Query Optimizer->Manage Optimizer Statistics->Gather Optimizer Statistics:
My question, when choosing the Object Type "Database": will this gather and optimize all of the other objects below database (i.e. Schemas,Tables,Indexes,etc.)? If I run the optimizer against a given schema, will this also compute statistics for all of the tables and indexes in the users schema?
I tried looking through the documentation set but it is not clear to me. Can someone break this down sesame street style for me?

934865 wrote:
When in EM, choose Server->Query Optimizer->Manage Optimizer Statistics->Gather Optimizer Statistics:
My question, when choosing the Object Type "Database": will this gather and optimize all of the other objects below database (i.e. Schemas,Tables,Indexes,etc.)? If I run the optimizer against a given schema, will this also compute statistics for all of the tables and indexes in the users schema?
yes
I tried looking through the documentation set but it is not clear to me. Can someone break this down sesame street style for me?http://www.oracle.com/pls/db111/search?word=dbms_stats&partno=

How to on -gathering statistics of how much a VM is actually used?

I have a SCVMM 2012 SP1 system managing a bunch of 2012 R2 host servers. What I am looking to do is to gather statistics and create a report that would tell me how often a system is being used.
I can figure out how to get uptime, but what I am looking to do is to weed out VMs that are no longer used, or seldom used over the course of a year. Even getting stats of when a VM was started or stopped would help me with this.

Jobs can give you start and stop details. But only those actions that were performed through SCVMM.
However, SCVMM is really not designed to track this type of audit history - the MSFT story is to use Operations Manager for that.
Or, you track over time - doing a dump of status to create your desired history then evaluate this history.
Trust me, you are not the first to ask. But it is not a core story of SCVMM. And it has never supported this type of history.
Brian Ehlert
http://ITProctology.blogspot.com
Learn. Apply. Repeat.

Gathering statistics in 8.1.7.4

Similar Messages

Maybe you are looking for