Schema stats

i know the difference between schema stats and table stats but tell me
which is more beneficial schema stats or table stats or database stats?
and when a query is fired optimizer looks for what stats table stats or schema stats to execute the query?
what is the first stats preference of optimizer??

>
by the way tab is not any table
when we fire select * from tab;
aal the tables in a schema are displayed so can you further refine your answer for this query as there is no table called tab it is just used to display all the tables present in a particular schema
>
Thanks for clarifying that. That brings up an important point.
That 'tab' is a system view and provides information from the SYS.TAB$ table for the current user; i.e. information about the current users tables.
Those gather 'database/schema/table' stats methods don't gather stats for the system schema.
But sometimes want to collect statistics on the database dictionary tables.
For that you use DBMS_STATS.GATHER_DICTIONARY_STATS
See the 'Managing Optimizer Statistics' section of the Database Performance Tuning Guide
http://docs.oracle.com/cd/B28359_01/server.111/b28274/stats.htm
>
When you generate statistics for a table, column, or index, if the data dictionary already contains statistics for the object, then Oracle updates the existing statistics. The older statistics are saved and can be restored later if necessary. See "Restoring Previous Versions of Statistics".
When gathering statistics on system schemas, you can use the procedure DBMS_STATS.GATHER_DICTIONARY_STATS. This procedure gathers statistics for all system schemas, including SYS and SYSTEM, and other optional schemas, such as CTXSYS and DRSYS.
>
And that above section brings up another important point.
See the phrase 'updates the existing statistics' in the above quote. The 'old' set of stats can be recovered if they need to be.
See 'Restoring Previous Versions of Statistics' in the same doc
http://docs.oracle.com/cd/B28359_01/server.111/b28274/stats.htm#i41814
>
Whenever statistics in dictionary are modified, old versions of statistics are saved automatically for future restoration. Statistics can be restored using RESTORE procedures of DBMS_STATS package. These procedures use a time stamp as an argument and restore statistics as of that time stamp. This is useful in case newly collected statistics leads to some sub-optimal execution plans and the administrator wants to revert to the previous set of statistics.
There are dictionary views that display the time of statistics modifications. These views are useful in determining the time stamp to be used for statistics restoration.

Similar Messages

ORA-12801 ORA-08103 while running gather schema stats in R12

Hi All,
We have recently upgraded from 11.5.9 to R12.1.1 on RHEL 4.8
Database version is 10.2.0.5
We are running Gather schema stats on R12.1.1 but its Errored out with below messages.
ORA-12801: error signaled in parallel query server P006
GL.GL_JE_LINES
ORA-08103 : object no longer exists
Please advice if anybdy face this issue.
Thanks
RB

Please see (GATHER SCHEMA STATISTICS COMPLETED WITH ERROR WHEN RUNNING FOR GL SCHEMA. [ID 1068541.1]).
Thanks,
Hussein

How to gather schema stats in 11.5.9

Hi,
I am trying to gather schema stats for 11.5.9. But schemaname does not have the list of schemas. can i enter ALL.
Regards
Taher

Hi Taher,
You can either enter a schema name or even ALL should work.
If you refer the link Helios has referred, Gather schema statistics is run on the schemas or tables on where there is a change in data frequently. So if you enter ALL then it would gather statistics for all the schemas which might not be required. Since it is run on all the schemas it might take time to complete.
It is a good practice to run gather statistics at object level where there are lot of data growth or change.
Regards,
Mithun

Gather Schema Stat running long in R12

Hi:
I scheduled Gather Schema Stat (all with 10%) on two PROD instances last night. One completed about 2 hrs (this one normally has more activeties) while the other is still running since 12:00am. Please give me the steps and commands how I should troubleshoot. Is it still running? I have checked there is no block. BTW, I did one Gather Schema Stats for AP with 10% yesterday afternoon. It completed less than 2 min. They both are on 12.1.3 and 11.1.0.7 on Linux. Thank you in advance.

I guess I have to do one of these. Thank you.
Another question: Why some tables dont have date under last_analyzed? When I checked the all_tables and sorted on the last_analyzed, saw 1/3 of the tables with date blank. They are from all kinds of schemas, ex, two tables below. But some AR, or AP are analyzed.
AR_SUBMISSION_CTRL_GT
AP_PERIOD_CLOSE_EXCPS_GT

Gather schema stats not running for custom schema's in EBS 12.1.1

Hi All,
We are running Gather schema stats program periodically in our EBS system with Schama name as "ALL", but it is not generating the statistics for the custom schema. We have custom schema registered in our EBS application. Can you please let us know if there is any issue with our setup or this is standard behaviour of Gather schama stats concurrent program.
Thanks,

Hi,
At how much percent ur using with Gather schema stats program like 10%,20%(in Gather schema stats program form)...I think there are no updates on the tables of that custom schema thats why the gather schema progam ignored it..can u check were there updates?
Regards

Error while gather schema stats

Hi,
I am getting the error while gather schema stats
-1 - ORA-00001: unique constraint (APPLSYS.FND_STATS_HIST_U1) violated
Unable to correctly update the history table - fnd_stats_hist.
-1 - ORA-00001: unique constraint (APPLSYS.FND_STATS_HIST_U1) violated
-Sagar

Ariz,
The FND_STATS package provides procedures for gathering statistics for Oracle Applications database objects. It also provides procedures
for storing the current statistics in a table (FND_STATTAB) and restoring them back. This package also facilitates the gathering of some statistics in parallel. This package calls the DBMS_STATS package.
The FND_STATS package also has procedures to populate the FNDSTATS_HIST_* table to record the historical information of time taken for gathering the
statistics for the different types of objects.
Famy

How to execute "gather schema stats" in parallel?

Hi,
I've a 11.2 Standard Edition and I need to gather stats for about 20 schemas.
It's possible to execute with a plsql (or other) dbms_stats.gather_schema_stats in parallel?
I want to execute 4 schema stats at time, and when one finish another one starts.
It's possible?
Thanks

Mr.D. wrote:
Hi,
I've a 11.2 Standard Edition and I need to gather stats for about 20 schemas.
It's possible to execute with a plsql (or other) dbms_stats.gather_schema_stats in parallel?
I want to execute 4 schema stats at time, and one finish another one starts.
It's possible?
Thanks
yes it is possible by opening 4 different sessions
which system resource will be saturated first?

Many Gather Schema Stat CR on R12

Hi, gurus:
I saw today that there are many Gather Schema Stats CR completed these days. They all run "as soon as possible". Who/what fired them?
EBS: 12.1.3
OS: Linux
DB: 11.1.0.7
Thank you.

Hi,
Helping without politeness will not actually be termed as Help, isn't it?
You may find the request set of a particular concurrent request/program using query:
SELECT DISTINCT user_request_set_name
FROM FND_REQUEST_SETS_TL
WHERE request_set_id IN
          (SELECT request_set_id
             FROM FND_REQUEST_SET_PROGRAMS
            WHERE concurrent_program_id =
                     (SELECT CONCURRENT_PROGRAM_ID
                        FROM fnd_concurrent_programs_tl
                       WHERE upper(USER_CONCURRENT_PROGRAM_NAME) = upper( '&Enter_Prog_name')));
The above query was extracted from link:
http://orclapp.blogspot.com/2012/02/script-to-find-concurrent-programs-of.html
Hope this helps
Best Regards

Needed Script for Gather Schema Stats

Hi
Well i need a script that monitors Gather Schema Schema stats is scheduled for coming week
In EBS this would be a con current request scheduled that i need to get the information ..
that script will run once in week and tell us that a GSS is scheduled on or else if its not scheduled it will give an alert as it is not schedule
please let me know
Cheers

Hi Hussein,Alex
well thanks for your reply ....
but let me be more more clear what i need ...
below query
select ACTUAL_START_DATE, ACTUAL_COMPLETION_DATE,ROUND ( (ACTUAL_COMPLETION_DATE - ACTUAL_START_DATE)*1440) DURATION_MINS, REQUEST_ID, CONCURRENT_PROGRAM_ID from fnd_concurrent_requests where actual_start_date between to_date('4-Jun-12 00:00:00','dd-mon-yy hh24:mi:ss') and to_date('6-July-12 11:00:00','dd-mon-yy hh24:mi:ss')
and CONCURRENT_PROGRAM_ID in (select CONCURRENT_PROGRAM_ID from FND_CONCURRENT_PROGRAMS_TL where USER_CONCURRENT_PROGRAM_NAME LIKE 'Gather Schema Statistics') order by 5,1;
this give me output that between this date 4-june-12 to 6-July-12 is there any con current request ran for Gather Schema Stats...
this query will give me request_id,concurrent_program_id and all details...
like this i want to see that if any con current request is schedule in near future
let us for eg
this script will run on monday and it will pickup up the concurrent request telling for this week on this date GSS is schedule...
likewise i need ...
hope this give explanation what exact i need ..
Cheers........

Problem after collecting schema stats collection

Dear all,
10.2.0.4.0
Solaris10
I've scheduled one schema stats collection in DB
like
exec DBMS_STATS.GATHER_SCHEMA_STATS('USERNAME',DBMS_STATS.AUTO_SAMPLE_SIZE);
Once this is completed, data insertion into user table is not going properly.. users lost some of the privileges which are already assigned..
Am runinng this stats for more than 6 months, and I started getting this problem now only.
any idea what went wrong ?
Kai

exec DBMS_STATS.GATHER_SCHEMA_STATS('USERNAME',DBMS_STATS.AUTO_SAMPLE_SIZE);Why are you doing this. With V10.2 Oracle has its own job to keep statistics current.
Once this is completed, data insertion into user table is not going properly.. users lost some of the privileges which are already assigned..DBMS_STATS & problems are 100% unrelated
Am runinng this stats for more than 6 months, and I started getting this problem now only.DBMS_STATS & problems are 100% unrelated
any idea what went wrong ?No, because you've provided no useful details.

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.

SCHEMA STATS OR ANALYZE TABLE

Hi,
Can any one tell me what are the advantages of schema stats or table stats over analyzing the table.
Regards,
Umair

Hi,
Following are the advantages of using the DBMS_STATS to gather either table or schema or d/b stats
A. ANALYZE always runs serially. DBMS_STATS can run in serial or parallel.
Whenever possible, DBMS_STATS calls a parallel query to gather statistics with
the specified degree of parallelism; otherwise, it calls a serial query or the
ANALYZE statement. Index statistics are not gathered in parallel.
B. ANALYZE calculates global statistics for partitioned tables and indexes
instead of gathering them directly. This can lead to inaccuracies for some
statistics, such as the number of distinct values.
C. For partitioned tables and indexes, ANALYZE gathers statistics for the
individual partitions and then calculates the global statistics from the
partition statistics. DBMS_STATS can gather separate statistics for each
partition as well as global statistics for the entire table or index. Depending
on the SQL statement being optimized, the optimizer may choose to use either
the partition (or subpartition) statistics or the global statistics.
D. For composite partitioning, ANALYZE gathers statistics for the subpartitions
and then calculates the partition statistics and global statistics from the
subpartition statistics. DBMS_STATS can gather separate statistics for
subpartitions, partitions, and the entire table or index. Depending on the SQL
statement being optimized, the optimizer may choose to use either the partition
(or subpartition) statistics or the global statistics.
E. ANALYZE cannot overwrite or delete some of the values of statistics that were
gathered by DBMS_STATS.
F. ANALYZE can gather additional information that is not used by the optimizer,
such as information about chained rows and the structural integrity of indexes,
tables, and clusters. DBMS_STATS does not gather this information. DBMS_STATS
gathers statistics only for cost-based optimization; it does not gather other
statistics. For example, the table statistics gathered by DBMS_STATS include
the number of rows, number of blocks currently containing data, and average row
length but not the number of chained rows, average free space, or number of
unused data blocks.
G. DBMS_STATS does not call statistics collection methods associated with
individual columns. Use the ANALYZE statement to gather such information.

SCHEMA STATS SLOW SOME TIME

Hi All,
I generate stats on weekly basis and it completes in 6-8 hours but some time it takes 26-40 hours to complete the stats.
There is no speacial load on the database when it takes 26-40 hours.
===SQL STATEMENT====
exec dbms_stats.gather_schema_stats(ownname => 'schemaname', estimate_percent => 20, cascade => true, options => 'GATHER');
=====================
Any advices.
Regards,
Umair

Umair,
I would suggest you few options:
Why do you collect entire schema stats every week? Collect stats on objects which have heavy dml. Enable table monitoring to your schema, its default in 10g. You will have no performance impact by enabling table monitoring because it keeps the information in a separate area of memory that doesn't impact on the performance.
Once you enable table monitoring to entire schema, use gather_stale option with dbms_stats package to collect stale stats. For more, search in the metalink.
If the system is multi CPU, then, make use of DEGREE option with dbms_stats package.
Generally 10% estimation is acceptable. You are collecting 10% on very big tables, all small tables will collect 100% stats, dispite of your estimate percentage.
select table_name,num_rows,sample_size,(sample_size/num_rows*100) "%" from user_tables where num_rows > 0 and sample_size > 0
/

Find schema stats lock or unlock

Dear All,
How to find schema stats locked or unlocked?

SQL> exec dbms_stats.lock_schema_stats('K');
PL/SQL procedure successfully completed.
SQL> select STATTYPE_LOCKED from dba_tab_statistics where OWNER ='K';
STATT
ALL
1 row selected.
SQL> exec dbms_stats.unlock_schema_stats('K');
PL/SQL procedure successfully completed.
SQL> select STATTYPE_LOCKED from dba_tab_statistics where OWNER ='K';
STATT
1 row selected.

Stopping the schema stats gathering process

Hi,
I have a large schema in my DB (7 TBs) on which I had triggered a UNIX background job to compute the statistics on that schema. The SQL which i had used was:
EXEC DBMS_UTILITY.ANALYZE_SCHEMA('<<schema_name>>','COMPUTE');
However, since the size of the schema is quite big, this stats computation process is running since the last 7 hours and I am not sure about the time it would take to finish with this process.
My questions are as below:
1. Is there any method to determine the status of this stats computation process?
2. If I kill this background job because i now have to run other data loading jobs on the schema and I dont want them to error out because of the exclusive locks on those objects, will it affect the DB performance in any way?
3. If i kill this background process, will the entire stats computation process be rolled back or would it be stopped at the place from where it was halted?
Kindly advice.
Thanks in advance.

Hi,
Thanks for the prompt response. I agree that i should be using dbms_stats and estimate for computing the schema stats. I re-analyzed the tables under the schema yeterday and hence i hope i should not face the incorrect cardinality info problem now.
However, I am facing another problem with the DB now. As a result of the data loading operation on the table, i see that all the subsequent DML operations are now taking a long log time to complete, typically 30 mins for a 10 seconds operation earlier.
What do you suggest is causing the problem and needs rectification?
Thanks in advance.

Schema stats

Similar Messages

Maybe you are looking for