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,
SreekanthDoes 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
SteveThank 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,
JithinRandalf,
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". -
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. GarabedianGenerally, 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
UlliUlli,
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/ -
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,
NoobGATHER_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
-
How to make the new tabs to open the same URL as the startup page?
Hello! I was wondering if it's possible to configure the Firefox in such a way that the new tabs open exactly the same URL that is typed in the Options. I tried to set browser.newtab.url to about:home but it gives me Firefox Google custom page instea
-
Hello everyone I wonder if you can advice me. I got myself a Power PC G5 which is bluetooth enabled but has no bluetooth antenna. Can I still use a magic or mighty mouse with it? OR do I need an antenna? Many thanks
-
HT5557 Can I share books and movies purchased with Kindle Fire HD?
Can I share books and movies purchased in iTunes with my Kindle Fire HD?
-
I am new to apple computers and just bought a MacBook Pro - I have my print router set up on my HP notebook but when I go through the printer setup procedure on the MacBook, it kicks me out of the setup program - as a result, I have internet access b
-
How t o erase all 5 pc stations i had authorised in the past?
i would like to erase all 5 pc stations i had authorised in the past. All these pc stations are useless. pls advice