Stale statistics

Hi,
Oracle 10.2.0.1
Windows xp
SYS> select owner,table_name from dba_tab_statistics
  2  where stale_stats='YES'
  3  /
OWNER                          TABLE_NAME
SYS                            CON$
SYS                            UNDO$
SYS                            IND$
210 rows selected.
SYS> ed
Wrote file afiedt.buf
  1  declare
  2  objlist   DBMS_STATS.objecttab;
  3  BEGIN
  4  DBMS_OUTPUT.ENABLE (500000000);
  5  dbms_stats.gather_database_stats(OPTIONS=>'GATHER STALE', CASCADE => TRUE, OBJLIST=>objlist);
  6  IF (objlist.COUNT = 0)
  7        THEN
  8           DBMS_OUTPUT.put_line ('No objects to analyze.');
  9        ELSE
10           FOR i IN 1 .. objlist.COUNT
11           LOOP
12              DBMS_OUTPUT.put_line (   objlist (i).objtype
13                                    || ' '
14                                    || objlist (i).ownname
15                                    || '.'
16                                    || objlist (i).objname
17                                    || ', partition:'
18                                    || objlist (i).partname
19                                    || ', sub part.:'
20                                    || objlist (i).subpartname
21                                   );
22           END LOOP;
23        END IF;
24*    END;
SYS> /
PL/SQL procedure successfully completed.
SYS> select owner,table_name from dba_tab_statistics
  2  where stale_stats='YES'
  3  /
OWNER                          TABLE_NAME
SYS                            WRH$_FILESTATXS
SYS                            WRH$_SQLSTAT
SYS                            WRH$_SYSTEM_EVENT
SYS                            WRH$_WAITSTAT
SYS                            WRH$_LATCH
SYS                            WRH$_LATCH_MISSES_SUMMARY
SYS                            WRH$_DB_CACHE_ADVICE
SYS                            WRH$_ROWCACHE_SUMMARY
SYS                            WRH$_SGASTAT
SYS                            WRH$_SYSSTAT
SYS                            WRH$_PARAMETER
OWNER                          TABLE_NAME
SYS                            WRH$_SEG_STAT
SYS                            WRH$_SERVICE_STAT
SYS                            WRH$_ACTIVE_SESSION_HISTORY
SYS                            WRH$_TABLESPACE_STAT
SYS                            WRH$_OSSTAT
SYS                            WRH$_SYS_TIME_MODEL
SYS                            WRH$_SERVICE_WAIT_CLASS
18 rows selected.My question is why these objects are still in stale statistics, even though i have just run dbms_stats.gather_database_stats(OPTIONS=>'GATHER STALE'....) command.
Thanks,
regards.

I am sorry for mis-interpretation of your question. Here is output of below command :
SYS> select table_name,last_analyzed
  2  from dba_tables
  3  where owner='SYS'
  4  and table_name like 'WRH$%'
  5  order by 2;
TABLE_NAME                     LAST_ANALYZED
WRH$_ACTIVE_SESSION_HISTORY_BL 09-aug-2010 15:32:33
WRH$_BUFFERED_QUEUES           09-aug-2010 15:32:33
WRH$_BUFFERED_SUBSCRIBERS      09-aug-2010 15:32:34
WRH$_COMP_IOSTAT               09-aug-2010 15:32:34
WRH$_CR_BLOCK_SERVER           09-aug-2010 15:32:34
WRH$_CURRENT_BLOCK_SERVER      09-aug-2010 15:32:34
WRH$_DLM_MISC_BL               09-aug-2010 15:32:35
WRH$_DLM_MISC                  09-aug-2010 15:32:35
WRH$_DB_CACHE_ADVICE_BL        09-aug-2010 15:32:35
WRH$_FILEMETRIC_HISTORY        09-aug-2010 15:32:36
WRH$_FILESTATXS_BL             09-aug-2010 15:32:36
TABLE_NAME                     LAST_ANALYZED
WRH$_EVENT_NAME                09-aug-2010 15:32:36
WRH$_INST_CACHE_TRANSFER_BL    09-aug-2010 15:32:37
WRH$_INST_CACHE_TRANSFER       09-aug-2010 15:32:37
WRH$_LATCH_CHILDREN_BL         09-aug-2010 15:32:39
WRH$_LATCH_BL                  09-aug-2010 15:32:39
WRH$_LATCH_CHILDREN            09-aug-2010 15:32:39
WRH$_LATCH_NAME                09-aug-2010 15:32:40
WRH$_LATCH_PARENT_BL           09-aug-2010 15:32:40
WRH$_LATCH_PARENT              09-aug-2010 15:32:40
WRH$_LATCH_MISSES_SUMMARY_BL   09-aug-2010 15:32:40
WRH$_METRIC_NAME               09-aug-2010 15:32:41
TABLE_NAME                     LAST_ANALYZED
WRH$_OSSTAT_NAME               09-aug-2010 15:32:42
WRH$_OSSTAT_BL                 09-aug-2010 15:32:42
WRH$_PARAMETER_BL              09-aug-2010 15:32:43
WRH$_PARAMETER_NAME            09-aug-2010 15:32:44
WRH$_ROWCACHE_SUMMARY_BL       09-aug-2010 15:32:46
WRH$_SEG_STAT_BL               09-aug-2010 15:32:50
WRH$_SESSMETRIC_HISTORY        09-aug-2010 15:32:53
WRH$_SERVICE_STAT_BL           09-aug-2010 15:32:53
WRH$_SERVICE_WAIT_CLASS_BL     09-aug-2010 15:32:53
WRH$_SGASTAT_BL                09-aug-2010 15:32:54
WRH$_SQLSTAT_BL                09-aug-2010 15:32:57
TABLE_NAME                     LAST_ANALYZED
WRH$_STREAMS_CAPTURE           09-aug-2010 15:33:01
WRH$_SYSMETRIC_HISTORY         09-aug-2010 15:33:01
WRH$_STREAMS_APPLY_SUM         09-aug-2010 15:33:01
WRH$_STAT_NAME                 09-aug-2010 15:33:01
WRH$_SYSSTAT_BL                09-aug-2010 15:33:05
WRH$_SYSTEM_EVENT_BL           09-aug-2010 15:33:06
WRH$_SYS_TIME_MODEL_BL         09-aug-2010 15:33:07
WRH$_TABLESPACE_STAT_BL        09-aug-2010 15:33:08
WRH$_WAITSTAT_BL               09-aug-2010 15:33:12
WRH$_ACTIVE_SESSION_HISTORY    17-aug-2010 12:42:35
WRH$_BUFFER_POOL_STATISTICS    17-aug-2010 12:42:37
TABLE_NAME                     LAST_ANALYZED
WRH$_DATAFILE                  17-aug-2010 12:42:37
WRH$_DB_CACHE_ADVICE           17-aug-2010 12:42:38
WRH$_ENQUEUE_STAT              17-aug-2010 12:42:38
WRH$_FILESTATXS                17-aug-2010 12:42:38  <<--- I do'nt know how it came i.e. from
WRH$_JAVA_POOL_ADVICE          17-aug-2010 12:42:39        Analyzed command or by dbms_stats --->>
WRH$_INSTANCE_RECOVERY         17-aug-2010 12:42:39
WRH$_LATCH                     17-aug-2010 12:42:39
WRH$_LOG                       17-aug-2010 12:42:40
WRH$_OPTIMIZER_ENV             17-aug-2010 12:42:40
WRH$_MTTR_TARGET_ADVICE        17-aug-2010 12:42:40
WRH$_LIBRARYCACHE              17-aug-2010 12:42:40
TABLE_NAME                     LAST_ANALYZED
WRH$_OSSTAT                    17-aug-2010 12:42:40
WRH$_LATCH_MISSES_SUMMARY      17-aug-2010 12:42:40
WRH$_PARAMETER                 17-aug-2010 12:42:41
WRH$_PGA_TARGET_ADVICE         17-aug-2010 12:42:41
WRH$_PGASTAT                   17-aug-2010 12:42:41
WRH$_RULE_SET                  17-aug-2010 12:42:42
WRH$_RESOURCE_LIMIT            17-aug-2010 12:42:42
WRH$_PROCESS_MEMORY_SUMMARY    17-aug-2010 12:42:42
WRH$_ROWCACHE_SUMMARY          17-aug-2010 12:42:42
WRH$_SEG_STAT                  17-aug-2010 12:42:43
WRH$_SEG_STAT_OBJ              17-aug-2010 12:42:44
TABLE_NAME                     LAST_ANALYZED
WRH$_SERVICE_NAME              17-aug-2010 12:42:45
WRH$_SERVICE_STAT              17-aug-2010 12:42:45
WRH$_SESS_TIME_STATS           17-aug-2010 12:42:46
WRH$_SGASTAT                   17-aug-2010 12:42:46
WRH$_SERVICE_WAIT_CLASS        17-aug-2010 12:42:46
WRH$_SGA                       17-aug-2010 12:42:46
WRH$_SGA_TARGET_ADVICE         17-aug-2010 12:42:47
WRH$_SHARED_POOL_ADVICE        17-aug-2010 12:42:47
WRH$_SQLSTAT                   17-aug-2010 12:42:47  <<--- But why it is in stale statistics. 
WRH$_SQLTEXT                   17-aug-2010 12:42:48        Due to, i issued
WRH$_SQL_PLAN                  17-aug-2010 12:42:49        "exec DBMS_STATS.FLUSH_DATABASE_MONITORING_INFO;" ?  --->>
TABLE_NAME                     LAST_ANALYZED
WRH$_SQL_BIND_METADATA         17-aug-2010 12:42:49
WRH$_SQL_SUMMARY               17-aug-2010 12:42:50
WRH$_STREAMS_POOL_ADVICE       17-aug-2010 12:42:50
WRH$_SYSTEM_EVENT              17-aug-2010 12:42:51
WRH$_SYSMETRIC_SUMMARY         17-aug-2010 12:42:51
WRH$_SYSSTAT                   17-aug-2010 12:42:51
WRH$_TABLESPACE_SPACE_USAGE    17-aug-2010 12:42:52
WRH$_SYS_TIME_MODEL            17-aug-2010 12:42:52
WRH$_THREAD                    17-aug-2010 12:42:53
WRH$_TEMPSTATXS                17-aug-2010 12:42:53
WRH$_TEMPFILE                  17-aug-2010 12:42:53
TABLE_NAME                     LAST_ANALYZED
WRH$_TABLESPACE_STAT           17-aug-2010 12:42:53
WRH$_WAITSTAT                  17-aug-2010 12:42:54
WRH$_WAITCLASSMETRIC_HISTORY   17-aug-2010 12:42:54
WRH$_BG_EVENT_SUMMARY          17-aug-2010 14:58:48
WRH$_SQL_WORKAREA_HISTOGRAM    17-aug-2010 14:58:49
WRH$_UNDOSTAT                  17-aug-2010 14:58:49
SYS>Probably, i have left today my daily external readings and by mistake entered into Oracle's internal path....!
regards.

Similar Messages

  • Oracle 11g upgrade: How to update stale statistics for sys and sysman?

    Hi,
    I am in the process of testing Oracle 11g upgrade from Oracle 10.2.0.3. I have run utlu111i.sql on the 10g database.
    The utility utlu111i.sql reports about the stale statistics for SYS and SYSMAN components.
    I executed dbms_stats.gather_dictionary_stats; dbms_stats.gather_schema_stats('SYS'); and dbms_stats.gather_schema_stats('SYSMAN');
    After that the utlu111i.sql still reports the stale statistics for sys and sysman. Does anyone know how to get rid off this warning successfully?
    Thanks,
    Sreekanth

    Does anyone know how to get rid off this warning successfully?Just ignore the warnings. Check The Utlu111i.Sql Pre-Upgrade Script Reports Stale Sys Statistics - 803774.1 from Metalink.

  • Optimizer Statitics Gathering Task is not updating stale statistics

    Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production PL/SQL Release 11.2.0.2.0 - Production
    ******************** List stale statistics for Schema IGR using dbms_stats.gather_database_stats **************************
    DECLARE
    ObjList dbms_stats.ObjectTab;
    BEGIN
    dbms_stats.gather_database_stats(objlist=>ObjList, options=>'LIST STALE');
    FOR i in ObjList.FIRST..ObjList.LAST
    LOOP
    IF ObjList(i).ownname = 'IGR' THEN
    dbms_output.put_line(ObjList(i).ownname || '.' || ObjList(i).ObjName || ' ' || ObjList(i).ObjType || ' ' || ObjList(i).partname);
    END IF;
    END LOOP;
    END;
    IGR.USER_INFO TABLE 189 < --------------------- 189 Tables with stale statistics
    PL/SQL procedure successfully completed.
    **************************** Check date IGR Table(s) last analyzed ***********************************************
    SELECT MAX(last_analyzed) last_analyzed
    FROM dba_tables
    WHERE owner = 'IGR'
    LAST_ANALYZED
    14-DEC-11
    *************************** Check status of Task 'auto optimizer stats collection' **********************************
    SELECT client_name, job_name, job_status, job_start_time
    FROM dba_autotask_job_history
    WHERE client_name = 'auto optimizer stats collection'
    ORDER BY job_start_time
    CLIENT_NAME JOB_NAME JOB_STATUS JOB_START_TIME
    auto optimizer stats collection ORA$AT_OS_OPT_SY_11952 SUCCEEDED 12-FEB-12 10.07.23.059313 AM EUROPE/LONDON
    auto optimizer stats collection ORA$AT_OS_OPT_SY_11955 SUCCEEDED 12-FEB-12 02.07.33.879238 PM EUROPE/LONDON
    auto optimizer stats collection ORA$AT_OS_OPT_SY_11958 SUCCEEDED 12-FEB-12 06.07.43.783262 PM EUROPE/LONDON
    auto optimizer stats collection ORA$AT_OS_OPT_SY_11961 SUCCEEDED 12-FEB-12 10.07.54.206488 PM EUROPE/LONDON
    Any suggestions welcome
    Thanks
    Steve

    Thank you for the feedback.
    I have manually updated the statistics on a single Table successfully and the Table has been removed from the list of stale statistics. So this is further evidence the daily Task "Optimizer Statistics Gathering Task" is failing to update stale statistics.
    Any further comment or suggestion welcome
    Thanks
    Steve
    SQL> SELECT owner, table_name, last_analyzed, num_rows
    FROM dba_tables
    WHERE owner = 'IGR' AND table_name = 'SYSAUDIT';
    OWNER TABLE_NAME LAST_ANAL NUM_ROWS
    IGR SYSAUDIT 14-DEC-11 59036
    1 begin
    2 dbms_stats.gather_table_stats(
    3 ownname=> 'IGR',
    4 tabname=> 'SYSAUDIT',
    5 estimate_percent=> 100,
    6 cascade=> DBMS_STATS.AUTO_CASCADE,
    7 degree=> null,
    8 no_invalidate=> DBMS_STATS.AUTO_INVALIDATE,
    9 granularity=> 'AUTO',
    10 method_opt=> 'FOR ALL COLUMNS SIZE AUTO');
    11* end;
    PL/SQL procedure successfully completed.
    SQL> /
    OWNER TABLE_NAME LAST_ANAL NUM_ROWS
    IGR SYSAUDIT 13-FEB-12 104970

  • Partition Gurus - Another help on Stale Statistics

    Hi All,
    A simple question for all gurus here.
    MY DBA was saying I dont need to ANALYZE TABLE COMPUTE STATISTICS on all tables every night. He said the CBO will collect STALE STATISTICS every night. I Only need to ANALYZE INDEX COMPUTE STATISTICS every night.
    IS this true? what exactly is stale stats?
    Thanks and Regards,
    Saff

    - What version of Oracle are we talking about?
    - Assuming 10g or later, is the default GATHER_STATS_JOB running?
    - If so, have any of the defaults been changed?
    - The ANALYZE command has been deprecated for quite some time as a means of gathering statistics for the optimizer. Unless you're on 8.1.5 or something, you should always be using DBMS_STATS rather than ANALYZE to gather optimizer statistics.
    Assuming you are on 10g or later and that the default GATHER_STATS_JOB is running, there would normally be no need to manually gather statistics on tables or indexes.
    Justin

  • CBO behaviour with stale statistics

    Hi,
    our company sells an application based on an Oracle database. One of our customers has reported what I regard as odd behaviour from the CBO. I wonder if anyone here can confirm my understanding of how the CBO uses statistics to determine the optimal execution plan.
    The reported issue is this:
    There are a number of large (100 million rows+) tables in the application, these are partitioned by date and are subject to both inserts and updates although and although theoretically any date could be the subject of a change, these tend to concentrated towards the most recent dates. The customer analyses the tables with a sample size of 25% every few days. They claim that if they do not do this then the CBO starts choosing very non-optimal plans and this gets worse the longer that they leave it.
    As I understand it the CBO will use the statistics on a table. Even if those statistics are stale it does not have anything better to base a decision on so it must use the statistics that are there. In which case even though a plan may be chosen that is non-optimal given a new set of data, it should choose the same plan each time given the same query and the same set of statistics.
    Any thoughts?

    qwe10730 wrote:
    As I understand it the CBO will use the statistics on a table. Even if those statistics are stale it does not have anything better to base a decision on so it must use the statistics that are there. In which case even though a plan may be chosen that is non-optimal given a new set of data, it should choose the same plan each time given the same query and the same set of statistics.
    This could be a case of the query only looking the same. As you said, most of the action is about the last few days.
    If they only collect statistics every few days then as time passes they are going to be running queries about data that doesn't appear to exist.
    If you have queries for a single recent partition, then Oracle could produce a plan based on its expectation of a complete absence of data. If you have queries for yesterday's data when the statistics haven't been updated since last week Oracle will produce a plan based on the fact that the volume of data is probably less than it would have been a week ago. (etc.....)
    Doug Burns has started an interesting series of posts on partitioned tables and statistics - it may not cover all the details you need at present (he's only published 5 of a possible 10 posts so far). I've listed them here: http://jonathanlewis.wordpress.com/2010/03/17/partition-stats/ but the first one is here: http://oracledoug.com/serendipity/index.php?/archives/1562-Statistics-on-Partitioned-Tables-Part-1.html
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
    There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)
    +"Science is more than a body of knowledge; it is a way of thinking"+
    +Carl Sagan+                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

  • Oracle Statistics - Best Practice?

    We run stats with brconnect weekly:
    brconnect -u / -c -f stats -t all
    I'm trying to understand how some of our stats are old or stale.  Where's my gap?  We are running Oracle 11g and have Table Monitoring set on every table.  My user_tab_modifications is tracking changes in just over 3,000 tables.  I believe that when those entries surpass 50% changed, then they will be flagged for the above brconnect to update their stats.  Correct?
    Plus, we have our DBSTATC entries.  A lot of those entries were last analyzed some 10 years ago.  Does the above brconnect consider DBSTATC at all?  Or do we need to regularly run the following, as well?
    brconnect -u / -c -f stats -t dbstatc_tab
    I've got tables that are flagged as stale, so something doesn't seem to be quite right in our best practice.
    SQL> select count(*) from dba_tab_statistics
      2  where owner = 'SAPR3' and stale_stats = 'YES';
      COUNT(*)
          1681
    I realize that stats last analyzed some ten years ago does not necessarily mean they are no longer good but I am curious if the weekly stats collection we are doing is sufficient.  Any best practices for me to consider?  Is there some kind of onetime scan I should do to check the health of all stats?

    Hi Richard,
    > We are running Oracle 11g and have Table Monitoring set on every table.
    Table monitoring attribute is not necessary anymore or better said it is deprecated due to the fact that these metrics are controlled by STATISTICS_LEVEL nowadays. Table monitoring attribute is valid for Oracle versions lower than 10g.
    > I believe that when those entries surpass 50% changed, then they will be flagged for the above brconnect to update their stats.  Correct?
    Correct, if BR*Tools parameter stats_change_threshold is set to its default. Brconnect reads the modifications (number of inserts, deletes and updates) from DBA_TAB_MODIFICATIONS and compares the sum of these changes to the total number of rows. It gathers statistics, if the amount of changes is larger than stats_change_threshold.
    > Does the above brconnect consider DBSTATC at all?
    Yes, it does.
    > I've got tables that are flagged as stale, so something doesn't seem to be quite right in our best practice.
    The column STALE_STATS in view DBA_TAB_STATISTICS is calculated differently. This flag is used by the Oracle standard DBMS_STATS implementation which is not considered by SAP - for more details check the Oracle documentation "13.3.1.5 Determining Stale Statistics".
    The GATHER_DATABASE_STATS or GATHER_SCHEMA_STATS procedures gather new statistics for tables with stale statistics when the OPTIONS parameter is set to GATHER STALE or GATHER AUTO. If a monitored table has been modified more than 10%, then these statistics are considered stale and gathered again.
    STALE_PERCENT - Determines the percentage of rows in a table that have to change before the statistics on that table are deemed stale and should be regathered. The valid domain for stale_percent is non-negative numbers.The default value is 10%. Note that if you set stale_percent to zero the AUTO STATS gathering job will gather statistics for this table every time a row in the table is modified.
    SAP has its own automatism (like described with brconnect and stats_change_threshold) to identify stale statistics and how to collect statistics (percentage, histograms, etc.) and does not use / rely on the corresponding Oracle default mechanism.
    > Any best practices for me to consider?  Is there some kind of onetime scan I should do to check the health of all stats?
    No performance issue? No additional and unnecessary load on the system (e.g. dynamic sampling)? No brconnect runtime issue? Then you don't need to think about the brconnect implementation or special settings. Sometimes you need to tweak it (e.g. histograms, sample sizes, etc.), but then you have some specific issue that needs to be solved.
    Regards
    Stefan

  • Gather Schema Statistics - GATHER AUTO option failing to gather stats

    Hi ,
    We recently upgraded to 10g DB and 11.5.10 version of Oracle EBS. I want to employ GATHER AUTO option while running Gather Schema Statistics.
    To test the working, I created a test table with 1 million rows. Then, stats were gathered for this table alone by using Gather Table Stats. Now, I deleted ~12% of rows & issued commit. The table all_tab_statistics shows that the table has stale statistics (stale stats column = YES). After that I ran Gather Schema Stats for that particular schema. But the request did not pick the test table to be gathered.
    What is the criterion on which Oracle chooses which all tables to be gather statistics for under Gather Auto option? I am aware of the 10% change in data, but how is this 10% calculated? Is it only based on (insert + update + delete)?
    Also, what is the difference between Gather Auto and Gather Stale ?
    Any help is appreciated.
    Thanks,
    Jithin

    Randalf,
    FYI.. this is what happens inside the concurrent progarm call.. there are a few additional parameters for output/ error msgs:
    procedure GATHER_SCHEMA_STATS(errbuf out varchar2,
    retcode out varchar2,
    schemaname in varchar2,
    estimate_percent in number,
    degree in number ,
    internal_flag in varchar2,
    request_id in number,
    hmode in varchar2 default 'LASTRUN',
    options in varchar2 default 'GATHER',
    modpercent in number default 10,
    invalidate in varchar2 default 'Y'
    is
    exist_insufficient exception;
    bad_input exception;
    pragma exception_init(exist_insufficient,-20000);
    pragma exception_init(bad_input,-20001);
    l_message varchar2(1000);
    Error_counter number := 0;
    Errors Error_Out;
    -- num_request_id number(15);
    conc_request_id number(15);
    degree_parallel number(2);
    begin
    -- Set the package body variable.
    stathist := hmode;
    -- check first if degree is null
    if degree is null then
    degree_parallel:=def_degree;
    else
    degree_parallel := degree;
    end if;
    l_message := 'In GATHER_SCHEMA_STATS , schema_name= '|| schemaname
    || ' percent= '|| to_char(estimate_percent) || ' degree = '
    || to_char(degree_parallel) || ' internal_flag= '|| internal_flag ;
    FND_FILE.put_line(FND_FILE.log,l_message);
    BEGIN
    FND_STATS.GATHER_SCHEMA_STATS(schemaname, estimate_percent,
    degree_parallel, internal_flag, Errors, request_id,stathist,
    options,modpercent,invalidate);
    exception
    when exist_insufficient then
    errbuf := sqlerrm ;
    retcode := '2';
    l_message := errbuf;
    FND_FILE.put_line(FND_FILE.log,l_message);
    raise;
    when bad_input then
    errbuf := sqlerrm ;
    retcode := '2';
    l_message := errbuf;
    FND_FILE.put_line(FND_FILE.log,l_message);
    raise;
    when others then
    errbuf := sqlerrm ;
    retcode := '2';
    l_message := errbuf;
    FND_FILE.put_line(FND_FILE.log,l_message);
    raise;
    END;
    FOR i in 0..MAX_ERRORS_PRINTED LOOP
    exit when Errors(i) is null;
    Error_counter:=i+1;
    FND_FILE.put_line(FND_FILE.log,'Error #'||Error_counter||
    ': '||Errors(i));
    -- added to send back status to concurrent program manager bug 2625022
    errbuf := sqlerrm ;
    retcode := '2';
    END LOOP;
    end;

  • Oracle 11G Searching Issue : Statistics Corruption

    Hi,
    I guess their is some issue with oracle statistics for Text Indexing. Some times i got an issue regarding Text index searching, query throwing wrong results. and when i fire this command :-
    execute immediate 'analyze table ' ||' '||tablename ||' '||'delete statistics';
    for deleting statistics. the query returns the correct results.
    I guess this is the problem of "stale statistics" , Is their any way to sort out this problem ?
    Any help please ?

    Hi,
    I have Oracle Version - 11g Release 1 (11.1.0.6)
    Yes you are absolutely correct, Even i am not getting that why oracle is behaving like this. But i have shown this behaviour many times ( once in 2-3 months approximately )
    I know that we can provide hint in the queries but i cant give hints.
    Any Help please ?

  • PeopleSoft Database Update Statistics

    I am trying to find out what is the best practices for implementing the Update statistics on Psoft Database. Any help or documentation regarding will be a great help
    I am looking for
    what is the best practice for update statistics on oracle , Intervals , Tables , do we need to include any custom script to generate and include all big tables.

    I was the one who designed the pscbo_stats package to leverage the statistics collection techniques used in EBS and Seibel. (Mr. Sierra was the wizard who coded it.) I just noticed this thread and wanted to comment.
    If you are using the pscbo_stats, the gather_schema_stats() procedure will by default gather only stale statistics, so it can be run regularly. I suggest weekly. You can follow the contents of the pscbo_log table for historical data for all (non-dynamic) stats gathering activities.
    If you find there is a table that constantly stale and forcing you to think that the schema statistics should gathered more often, you may want to have two schedules - one weekly for schema, and one more often (daily?) to capture the more volatile objects excepting, of course, those that are already dynamically sampled.
    There may be objects that are volatile enough that they should be added to the Stage Table Exception table. (see the stage_table_ins() procedure) We added that feature to configure dynamic sampling to work on volatile table - tables that are not working storage for COBOL and App Engine but are so often stale that they should be dynamically sampled.
    I find that there are a few transactional tables that work well when dynamically sampled. For example, PSTREESELECT* tables can be problematic if they are dynamically rebuilt by a nVision report book - the end points can get stale quickly. They may be a good candidate for dynamic sampling.
    Lastly, I am very interested to know user experience with the pscbo_stats package. Please post your comments to the communities.oracle.com forum for "Install/Upgrade PSFT".

  • Gathering Statistics

    Hi
    I have 2 tables (master/detail), each day more than 500 records are inserted in the master table and 1500 in the detail, these are the min numbers. Deletes are very, very rare but there are updates.
    My question, what is the best way to gather statistics for best performance from these tables, Estimation? or full?.
    Thanks in Advance
    Tony S. Garabedian

    Generally, I recommand to recalculate statistics ... minimum once per weekThis is not what most people (including Oracle) would recommend. In general, if your statistics are already good enough and accurate enough then leave 'em alone! Constantly refreshing statistics is not a panacea for database ills. Indeed, it is a potentially de-stabilising activity.
    Consider. If your table has small incremental growth then re-calculating statistics is not going to change the performance, so why bother. On the other hand, if the table has experienced a dramatic change od size then recalculating statistics may result in improved performance. However it may make no difference, it may even degrade performance (the Optimimizer ain't that smart).
    The more usual recommendation is run statistics once. Then use MONITORING to see which tables may need to have their statistics refreshed. If tables with stale statistics coincide with tables that may be responsible for performance problems (measured by something sensible, like users grumbling) then by all means see what difference re-calculating the statistics makes.
    But don't take my word for it. Experiment. Truely when it comes to performance tuning the watchword is YMMV.
    Cheers, APC

  • How to find table/index statistics are outdated

    Hi guys,
    How can we find whether the statistics of a table or a index are outdated.
    thanks...

    You can use DBA_TAB_MODIFICATIONS view: please read "Determining Stale Statistics" http://download.oracle.com/docs/cd/E11882_01/server.112/e16638/stats.htm#PFGRF94738

  • AWR Statistics gathering is taking hours...

    Is it normal in 10g to have the following job run for hours?
    EXEC SYS.DBMS_SCHEDULER.RUN_JOB('GATHER_STATS_JOB');
    It takes like 4 hours sometimes to run - we run it once a day..Thank you!

    AWR is the automatic workload repository - which is similar in mechanism to statspack, taking regular snapshots of the dynamic performance views.
    The gather_stats_job has nothing to do with the operation of the AWR, beyond the fact that AWR data is stored in tables, so the gather_stats_job may decided to collect stats on those tables from time to time.
    The default action for gather_stats_job is to collect stats for all tables with missing or stale statistics. The sample size for each table is chosen automatically (effectively by trial and error starting with a very small sample. Histograms are also collected automatically, based on a check of which columns have been used historically for "where" clauses combined with a sample to check if such columns show skewed data patterns.
    If you do a lot of inserts, updates, and deletes on this particular database, you are more likely to end up with table statistics becoming stale more frequently, leading to longer lists of tables that need stats recalculated.
    You may find that Oracle is generating too many histograms, and histograms can take a long time to construct. If this is the case, then you could consider changing the default setting for stats collection to skip the automatic histogram generation and add code to build histograms only on the columns that you think need them.
    [addendum: you say you are running gather_stats_job daily - but it runs automatically every weekday at 10:00 pm and all weekend; did you disable the standard job, or did you mean that you were just letting the standard job).
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    "The greatest enemy of knowledge is not ignorance,
    it is the illusion of knowledge." Stephen Hawking.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

  • Autom. Gather Statistics Job

    Hello,
    i am facing following problem with the automatic gather statistics job which is running every night.
    The jobs starts when the weeknight/weekend_maintenance_windows opens, runs approx. 30 minutes and rebuilds statistics for around 270 objects. But when we check the status of objects next morning or immediate after jobrun, we still find hundrets of objects with stale statistics. We are not facing any heavy performance problems, but i want to know why we found stale statistics. The job uses 30 minutes of the 480 minutes window, so in my opinion there is plenty of time for all objects to create new statistics.
    Is this normal behaviour?
    Can't find anything in metalink.
    Systeminfo:
    Host: HP-UX 11.31
    DB: 10.2.0.4
    Regards
    Ulli

    Ulli,
    uwaldt wrote:
    Hello Randolf,
    we check if column stale_stats contains a 'YES'. The column 'last_analyzed' is filled with a date.OK, and the date corresponds to the latest run of the automatic statistics gathering job or is it outdated? What is the content of the corresponding TABMODIFICATIONS view in that case?
    After we check sthe SQL-script with the 'original' check via dbms_stats.gather_schema_stats, we see that there is a difference between all_tab/ind_statistics and the real value in tabmodifications.Apologies, but I'm not able to follow: What is the "difference between all_tab/ind_statistics and the real value in *_tab_modifications"? You mean to say that the list of objects marked as "STALE_STATS = YES" column differs from the output of the "LIST STALE" call?
    But what shows grid-control if we check there for stale stats?Good question, I can't answer since I seldom use the GUI tools.
    The next is, the developers in house argue with the all_tab/ind_statistics and blame the DBA's to do their housekeeping, especially if the users complain bad performance. I knew that the gather_job do his work, but we can't show it probable to the developers.This all sounds a bit odd. Two comments:
    1. It is possible in 10g to lock the statistics of tables, so that the automatic statistics collection job doesn't touch them. It's quite unlikely since you have to invoke it manually/explicitly using DBMS_STATS.LOCK_TABLE/SCHEMA_STATS, but may be you want to check the column STATTYPE_LOCKED in the TABSTATISTICS views for those objects in question, just to make sure.
    2. All the monitoring related information (*TABMODIFICATIONS/STALE_STATS column etc.) is usually only updated every three hours or if a call to DBMS_STATS.GATHER_STATS is performed. If you want to manually invoke the flush of the monitoring info, you can call DBMSSTATS.FLUSH_DATABASE_MONITORING_INFO to make sure that you look at the latest monitoring information available.
    Above point might explain that you can spot differences/inconsistencies before/after calling DBMS_STATS.GATHER_SCHEMA_STATS to list the stale objects.
    Regards,
    Randolf
    Oracle related stuff blog:
    http://oracle-randolf.blogspot.com/
    SQLTools++ for Oracle (Open source Oracle GUI for Windows):
    http://www.sqltools-plusplus.org:7676/
    http://sourceforge.net/projects/sqlt-pp/

  • Stale stats

    Hi ,
    database :Oracle 11g(11.2.0.2)
    OS:solaris
    one of my prod database is having huge number of stale statistics.am planning to gather stats using below one.
    EXEC DBMS_STATS.gather_schema_stats('COMMODITY', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE, cascade => TRUE);
    here my doubt is ..is it any performance degradation if I gather stats for stale stats? or any performance benefits? can any one please explain or suggest any docs/MOS docs etc...links if any...
    why statistics  are not collected while using ESTIMATE_PERCENT =>15? when db is has stale stats...why we go for DBMS_STATS.AUTO_SAMPLE_SIZE  any idea?
    thanks,
    Mike.

    Unless you have explicitly disabled it, an 11.2 database will be gathering statistics automatically using sensible defaults. To check if the job is enabled,
    select client_name,status from dba_autotask_client;
    If it is indeed disabled, then your questions becomes relevant. But in general, unless your users have a problem, do nothing. If they do have a problem, take a look at the problem to determine if stale statistics is the cause. Simply gathering statistics for no paricular reason may not be a good idea.
    John Watson
    Oracle Certified Master DBA

  • Object statistics - indexed not used (GATHER_STATS_JOB)

    hi all,
    I have few top SQL statements in my DB...which is very basic to me
    select ... from tab where user_id = 'xxx';
    User_id is indexed..
    Therefore, i run the few top SQL statement myself, and realize it is doing FTS.. even for result set of 1 row only.
    Therefore i do a simple DBMS_STATS
    and it started using the index on user_id.
    The optimizer cost drop from a 1000 to simple 13 to 14.
    My question is
    1st) i have value 10 for job_queue_processes
    2nd) i have GATHER_STATS_JOB scheduled and running successfully.
    q1) why do i have to do DBMS_STATS manually before it started to use the index again.
    This FTS has been on-going for about 2 weeks.
    Regards,
    Noob

    GATHER_STATS_JOB, if using default configuration, runs every night from 10 P.M. to 6 A.M. and all day on weekends, gather statistics on objects
    that have no previously gathered statistics, or if the existing statistic are staled, and by default configuration stale statistics are when more than 10% of the table's rows are changed.
    Table which you are mentioning seems to have less then 10% of the whole table rows changed, meaning condition/s for stats gathering with default configuration
    are not met, and therefore stats are not gathered.
    You can run select * from dba_scheduler_jobs where job_name='GATHER_STATS_JOB' to find additional details about the job.
    Official documentation can be good starting point to provide further explanations.

Maybe you are looking for