'auto optimizer stats collection' in em12cr3

During installation of EM 12cR3 the OUI noted to 'disable stats gathering job', and indicated it would disable for me.
After installation I look at dba_auto_task and see that 'auto optimizer stats collection' is enabled.
The install docs Overview of the EM Prerequisite Kit also say to disable this for the install and upgrade.
What is not clear to me is: "is this only for the install/upgrade? should the collection be enabled after the install is complete?"

Hi Sherrie,
auto optimizer stats needs to be disable only during install and upgrade of 12c cloud control
Once its done you can enable the auto optimizer stats collection at Repos DB level
Regards,
Rahul

Similar Messages

Auto optimizer stats collection enabled, but not running and not showing up

I enabled auto optimizer stats collection days ago, but it never ran. DB version is 11gr2, OS is redhat 5. It shows enabled in dba_autotask_client, but not in autotask_task. Please help on this issue.
SQL> select client_name, status from dba_autotask_client;
CLIENT_NAME STATUS
auto optimizer stats collection ENABLED
auto space advisor DISABLED
sql tuning advisor ENABLED
SQL> select task_name, status, to_char(last_good_date, 'YYYY-MM-DD HH24:MI:SS') last_good_date, last_good_duration
from dba_autotask_task
where client_name = 'auto optimizer stats collection'; 2 3
no rows selected
SQL> select program_action, number_of_arguments, enabled
from dba_scheduler_programs
where owner = 'SYS'
and program_name = 'GATHER_STATS_PROG'; 2 3 4
PROGRAM_ACTION NUMBER_OF_ARGUMENTS ENABL
dbms_stats.gather_database_stats_job_proc 0 TRUE
SQL> select w.window_name, c.autotask_status, c.optimizer_stats, w.repeat_interval, w.enabled
-- , w.duration, w.last_start_date, w.next_start_date
2 from dba_autotask_window_clients c , dba_scheduler_windows w
3 4 where c.window_name = w.window_name
5 order by last_start_date desc;
WINDOW_NAME AUTOTASK OPTIMIZE REPEAT_INTERVAL ENABL
MONDAY_WINDOW ENABLED ENABLED freq=daily;byday=MON;byhour=22;byminute=0; bysecond=0 TRUE
SUNDAY_WINDOW ENABLED ENABLED freq=daily;byday=SUN;byhour=6;byminute=0; bysecond=0 TRUE
SATURDAY_WINDOW ENABLED ENABLED freq=daily;byday=SAT;byhour=6;byminute=0; bysecond=0 TRUE
FRIDAY_WINDOW ENABLED ENABLED freq=daily;byday=FRI;byhour=22;byminute=0; bysecond=0 TRUE
THURSDAY_WINDOW ENABLED ENABLED freq=daily;byday=THU;byhour=22;byminute=0; bysecond=0 TRUE
WEDNESDAY_WINDOW ENABLED ENABLED freq=daily;byday=WED;byhour=22;byminute=0; bysecond=0 TRUE
TUESDAY_WINDOW ENABLED ENABLED freq=daily;byday=TUE;byhour=22;byminute=0; bysecond=0 TRUE
7 rows selected.
SQL>

SQL> select max(last_analyzed) from all_tables where owner='ARAD';
MAX(LAST_
26-SEP-12

Auto optimizer stats collection interval

Hi,
I have a question about "auto optimizer stats collection" in 11gR2.
I see on the history, 1 execution of "auto optimizer stats collection" on Monday, Tuesday, Wenesday, Thursday and Friday and 5 executions on Saturday and Sunday.
I find the duration of each window (4 hours on Mon, Tue, Wen, Thu and Friday, 20 hours on Sat and Sun) and start date (22 hour Mon, Tue, Wen, Thur and Friday and 6h on Sat and Sun), but i don't find the interval between executions or frenquency of execution for each window.
Someone can tell me, if is it possible to change this and where ?
Regards,

Thank's for all reply, but it's not the answer of my question.
I know how disable/enable automatic task, i know to add/delete window, etc ... but where can i configure the frequency or interval of the "auto optimizer stats collection" task.
I try to explain what i want to know.
By defaut, on window Mon, Tue, Wen, Thu and Fri, the task start at 22:00 and run once, the window duration is 4 hours. Why one run ?
On window Sat and Sun, the task start à 6:00 and run 5 times ( 6:00, 10:00, 14:00, 18:00 and 22:00), the window duration is 20 hours. Why 5 runs ? or why 4 hours between 2 runs ?
Regards

Stats collection issue on 11.2

Hello all,
we have a oracle 11.2.0.3 enterprise edition database has auto optimizer stats collection is enabled
but does not collect any stats, I tried to disable and enable the task with same result,
database is been up for a month now,
no rows listed in DBA_AUTOTASK_CLIENT_HISTORY, DBA_AUTOTASK_schedule,DBA_AUTOTASK_TASK
statistics_level is set to typical,
is there anything else I could check,
Any help is appreciated,
Thanks,
Red

rred wrote:
Hello all,
we have a oracle 11.2.0.3 enterprise edition database has auto optimizer stats collection is enabled
but does not collect any stats, I tried to disable and enable the task with same result,
database is been up for a month now,
no rows listed in DBA_AUTOTASK_CLIENT_HISTORY, DBA_AUTOTASK_schedule,DBA_AUTOTASK_TASK
statistics_level is set to typical,
is there anything else I could check,
Any help is appreciated,
Thanks,
Red
SQL> show parameter queue
NAME TYPE VALUE
job_queue_processes integer 1000
SQL> select job_name from dba_scheduler_jobs;
JOB_NAME
XMLDB_NFS_CLEANUP_JOB
SM$CLEAN_AUTO_SPLIT_MERGE
RSE$CLEAN_RECOVERABLE_SCRIPT
FGR$AUTOPURGE_JOB
BSLN_MAINTAIN_STATS_JOB
DRA_REEVALUATE_OPEN_FAILURES
HM_CREATE_OFFLINE_DICTIONARY
ORA$AUTOTASK_CLEAN
FILE_WATCHER
PURGE_LOG
MGMT_STATS_CONFIG_JOB
JOB_NAME
MGMT_CONFIG_JOB
RLM$SCHDNEGACTION
RLM$EVTCLEANUP
POSPAY_CHECK_JOB
15 rows selected.
SQL>

Automatic Optimizer Statistics Collection Enabled still tables not analyzed

Hello,
We have Oracle 11g R1 database. Our automatic Optimizer Statistics Collection settings are enabled, still I don't see the tables being analyzed, any suggestions if I am missing any settings. All tables do get analyzed if I do manual statistics gathering.
SQL> select CLIENT_NAME ,STATUS from DBA_AUTOTASK_CLIENT;
CLIENT_NAME STATUS
auto optimizer stats collection ENABLED
auto space advisor ENABLED
sql tuning advisor ENABLED
Thanks,
SK

user599845 wrote:
Hello,
We have Oracle 11g R1 database. Our automatic Optimizer Statistics Collection settings are enabled, still I don't see the tables being analyzed, any suggestions if I am missing any settings. All tables do get analyzed if I do manual statistics gathering.
SQL> select CLIENT_NAME ,STATUS from DBA_AUTOTASK_CLIENT;
CLIENT_NAME STATUS
auto optimizer stats collection ENABLED
auto space advisor ENABLED
sql tuning advisor ENABLED
Thanks,
SK
still I don't see the tables being analyzed, post SQL & results that lead you to this conclusion.
realize that statistics can be "collected" without updating LAST_ANALYZED column.
if data within table does not change, the nothing would be gained by "updating" statistics to same values as now/before.

10g Automatic Stats Collection -- AUTO ( METHOD_OPT)

I have implememted Oracle 10g Auto Stats collection feature. To generate new stats on 10g optimizer I deleted the schema stats and then scheduled the DBMS_SCHEDULER to collect stats in AUTO method_opt.
I see that the new 10g optimizer is collecting stats differently in different databases eben through they have the same data.
For exampl I see that it collected Histograms on 10 columns in one table in one environment but it generatd histograms only on 9 columns in another env.
I am concerned that the stats difference will result in the execution plan getting changed across different instances.
Can someone please clarify the cause of the same. How can I make sure tha the 10g optimizer is collecting stats uniformly across different envs.
Thank You

You wrote:
"I am concerned that the stats difference will result in the execution plan getting changed across different instances."
and you should be concerned.
I would recommend not collecting stats the way you are but rather to use a nuanced approach where you collect only when they are stale or only when you know that changes have rendered old statistics invalid.

Auto Stats Collection on function based indexes

In 10g does AUTO Stats Collection job in the default weeknight / weekend window collect stats on "function based indexes".
Thank You
Message was edited by:
user449511
I got the reply in another similar post posted by me some time earlier.
Thank You
Message was edited by:
user449511

SELECT job_name, comments
FROM dba_scheduler_jobs;Then refine your search using the columns in the view.

Comments on "Auto" Stats collection practice in 10g

We going to implement auto stat collection practice in our production env. Can someone on this forum comment on the results / experiences ? As per Tom Kytes he is sceptical on going with this practice because it uses AUTO method_opt option which actually can result in different stats being collected based on column usage and data distribution.
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:52288431326913.
Thank You

Hi
Can someone on this forum comment on the results / experiences ?As for any "automatic feature" it works fine in many situations but not always. You have to test it to know if in your situation it is usable or not. IMHO it makes sense to give it a try...
can result in different stats being collected based on column usage
and data distribution.This is the purpose of AUTO. So, no news here.
HTH
Chris

Is 11g auto stats collection automatic on? where can I find this job?

Is 11g auto stats collection automatic on?
I manually created a 11g database, but I did not see auto stats collection job. where can I find this job? or how could I verify this is on?
Thank you.

Found in Automated Maintenance Tasks.

Auto stats collection in 11g

In 11g, automatic optimizer statistics collection is one of the automated maintenance tasks which is enabled by default. On the other hand, gather_stats_job shows 'disabled' in dba_scheduler_jobs. Does it mean that we do not need to enable the gather_stats_job as we did in 10g?

In 11g, automatic optimizer statistics collection is one of the automated maintenance tasks which is enabled by default. On the other hand, gather_stats_job shows 'disabled' in dba_scheduler_jobs. Does it mean that we do not need to enable the gather_stats_job as we did in 10g?

(10g) 자동 통계정보 수집(AUTOMATIC OPTIMIZER STATISTICS COLLECTION)

제품 : ORACLE SERVER
작성날짜 : 2006-07-21
PURPOSE
이 문서는 10g의 new feature인 자동 통계정보 수집(Automatic Optimizer
Statistics Collection)에 대한 소개와 기능에 대한 자료이다.
Explanation
1. 개요
Optimizer statistics는 GATHER_STATS_JOB에 의해서 자동으로
수집된다. 이 JOB은 SYS 소유로서 OBJECT_TYPE이 JOB이다.
이 JOB은 통계정보가 없거나 stale 상태의 통계정보를 갖는 DB 내의
모든 OBJECT들에 대한 통계정보들을 수집한다.
2. 자동 통계정보 수집을 위한 설정과 방식
1) STATISTICS_LEVEL = TYPICAL | ALL
2) 통계정보들은 predefined GATHER_STATS_JOB에 의해 수집된다.
3) JOB이 수행될 때 JOB은 다음과 같은 사항들을 결정한다.
- missing 또는 stale 상태의 통계정보를 갖는 object를 결정한다.
- 좋은 통계정보를 생성하기 위해 필요한 적당한 sampling percentage.
- histogram과 histogram의 사이즈를 요구하는 적절한 column.
- 통계정보 수집에 대한 parallelism의 degree.
- 어느 object에 대한 통계정보를 수집할지에 대한 우선순위
3. GATHER_STATS_JOB에 대한 설명
이 job은 데이타베이스 생성 시점에 생성되고 스케줄러에 의해 관리된다.
GATHER_STATS_JOB 은 DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC procedure를
call함으로써 통계정보를 수집한다.
이 프로시져는 'GATHER AUTO' 옵션을 사용한 DBMS_STATS.GATHER_DATABASE_STATS
procedure와 아주 유사한 형태로 동작한다. 이것과 다른 점은
GATHER_DATABASE_STATS_JOB_PROC procedure는 통계정보를 수집해야 할
Object에 대해 우선순위를 두고 순서대로 처리한다. 즉, 가장 많이
통계정보가 update가 되어야 할 object를 가장 먼저 처리하는 것이다.
이것은 maintenance window가 close되기 전에 가장 필요한 통계정보가
먼저 수집되도록 하기 위함이다.
4. Dictionary Objects에 대한 통계정보
1) Oracle Database 10g부터 최적의 performance 결과를 얻기 위해 dictionary
table들에 대한 통계정보도 수집할 수 있다.
언제라도, DBMS_STATS.GATHER_SCHEMA_STATS procedure를 사용하여
dictionary table들에 대한 통계정보를 수집하는 것이 가능하다.
이 때 GATHER_SYS argument는 TRUE로 셋팅되어 있어야 한다.
2) DBMS_STATS.GATHER_DICTIONARY_STATS라 하는 새로운 procedure도 사용
하는 것이 가능하다. 이것을 사용하기 위해서는 ANALYZE ANY DICTIONARY
라는 새로운 system privilege가 있어야 한다.
이 권한은 만약 어떤 user가 SYSDBA 권한이 없는 경우 dictionary object와
fixed object들을 analyze할 수 있도록 한다.
3) GATHER_DATABASE_STATS라는 프로시져는 GATHER_FIXED라 불리우는 새로운
argument를 가진다. 이 값은 default로 FALSE로 셋팅된다. 즉, 기본적으로
fixed table들에 대해서는 통계정보를 생성하지 않도록 한다.
전형적인 System WorkLoad가 있는 동안에는 fixed table들에 대하여
한번만 analyze하면 충분하다.
4) GATHER_FIXED_OBJECTS_STATS라는 procedure를 사용하여 fixed table들에
대한 통계정보를 모으는 것도 가능하다. 또한 모든 fixed table들에 대하여
통계정보를 delete하는 것도 가능하고, fixed table에 통계정보를
export 또는 import하는 것도 가능하다.
Example
none
Reference Documents
<Note:266040.1>

Hi,
Please see here,
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/stats.htm#i41448
If the table/s are changing very frequently than its better to gather the stats manually.This would lead teh volatile table coming up into the stats job again and again.
For the system stats and data dictionary stats,they are not collected by default.So there is no choice but to gather them manually.
Aman....

Optimizer Statistics collection after upgrade from 8i to 10R2

I just upgraded database from 8.1.7 to 10R2 .
What would the best approach for Optimizer Statistics collection. We would like to open database for test , but I afraid some quries going to run slow without latest stats. Should I run it manually or let Oracle run it’s default stats collection job later on.
Any suggestions?

user594143
You really need a strategy before an upgrade like this, but you have two options -
a) try to make the 10g stats collection identical to the 8i stats collection. Check the code you used to run, check the 8i default values for the parameters in your current dbms_stats() calls, and write them in explicitly when you run the code under 10g.
OR
b) do a full 10g conversion. Get rid of your own collection code, clear out most of the old settings you had in your parameter file for fiddling with the optimizer, do a 'gather_schema_stats' then leave 10g to do its default thing and fix any problems that appear.
If you have testing time on a non-production system, then (b) is the strategic option - although personally I think it tends to collect too many histograms and still needs some refinement; if you don't have any testing time and you're going straight into production then (a) is the least threatening option (and if someone's made you do that, you might also set the optimizer_features_enable to 8.1.7 until you can do some proper upgrade tests).
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk

Stats collection running long in 11g

Oracle11.2.0.1
Sun Solaris.
Stats collection running long for almost 12 hours from 6PM to 6AM daily and stats collection autotask is getting STOPPED after the window duration.
DBA_TABLES.last_analyzed is not getting updated after 2AM in the morning. I believe it is scanning some big tables, but not able to pin point the table/index.
And we've some a bunch of 100GB tables in the DB. Is there a way to find out which table it's gathering stats between 2AM and 6AM and not getting completed?
Thanks for your time!

moreajays wrote:
Hi,
I would suggest to find out those tables with huge Table & last_analyzed is Null , these tables would be possible tables responsible for long run.
Only AWR ot other SQL Hist stats tables can help you to get details.
To fix this issue you should run stats gathering manually in day time (not in maintenance window) either with auto stats or with little estimate_percent (10 or 5)
After getting first successful analyze (manually) , maintenance stats will pick up new incremental stats thereafter
Ajay,
I don't think that your statement that after the gathering the statistics manually, it would be next done incrmentally is correct. The incremental statistics are introduced only for partitioned tables AFAIK. Can you post a link from the documentation that your mentioned behavior exists?
Aman....

Runtime increased after stats collection

Hi,
Below is my SQL query
SELECT   wos.*,
               t.wo_status,
               t.wo_type
          FROM cscrpt_transactions t,
               (SELECT DISTINCT sb.sub_acct_no_sbb,
                                sb.vip_flg_sbb,
                                sb.res_name_sbb,
                                sb.home_phone_sbb,
                                sb.delq_1cyc_sbb,
                                sb.delq_2cyc_sbb,
                                sb.delq_3cyc_sbb,
                                sb.delq_4cyc_sbb,
                                sb.delq_5cyc_sbb,
                                sb.delq_stat_sbb,
                                sb.delq_amt_sbb,
                                sb.ls_pay_dte_sbb,
                                sb.ls_pay_amt_sbb,
                                sb.misc_sbb,
                                hb.misc_hse,
                                TRUNC(SYSDATE) - sb.start_delq_dte_sbb days_delq,
                                sb.prom_pays_days_sbb,
                                sb.start_delq_dte_sbb,
                                sb.prom_pays_dte_sbb,
                                ca.category_name,
                                ct.wo_key,
                                cc.customer_id
                           FROM sbb_base sb,
                                hse_base hb,
                                cscrpt_customers cc,
                                cscrpt_transactions ct,
                                cscrpt_categories ca
                          WHERE sb.ext_stat_sbb = ' '
                            AND sb.prin_sbb <> 3000
                            AND sb.prin_sbb <> 3100
                            AND sb.delq_stat_sbb NOT IN ('C', 'E', 'Z', 'W')
                            AND sb.delq_amt_sbb > 10.00
                            AND (   sb.delq_2cyc_sbb > 0.00
                                 OR sb.delq_3cyc_sbb > 0.00
                                 OR sb.delq_4cyc_sbb > 0.00
                                 OR sb.delq_5cyc_sbb > 0.00)
                            AND sb.sub_acct_no_sbb = hb.sub_acct_no_hse
                            AND sb.sub_acct_no_sbb = cc.csg_account_no
                            AND cc.customer_id = ct.customer_id
                            AND ct.category_id = ca.category_id) wos
         WHERE wos.wo_key = t.wo_key
           AND t.wo_key = (SELECT MAX(tr.wo_key)
                             FROM cscrpt_transactions tr
                            WHERE tr.customer_id = wos.customer_id)
      ORDER BY wos.start_delq_dte_sbb DESC,
               wos.delq_2cyc_sbb;Stats for the base tables of the views used
(v)sbb_base – 24,791,659 rows, stats 12/28/07
(v)hse_base – 25,270,280 rows, stats 12/28/07
(v)cscrpt_customers – 20,418,167 rows, stats 10/10/04
(v)cscrpt_transactions – same as for customers
(t)cscrpt_categories – 14,524 rows, stats 10/10/04(v)-View, (t)-table. Rowcount and last date when stats were collected.
Below is the execution plan:
4286 rows selected.
Elapsed: 01:02:39.07
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=236008 Card=1 Bytes=
          386)
   1    0   SORT (ORDER BY) (Cost=236001 Card=1 Bytes=386)
   2    1     FILTER
   3    2       FILTER
   4    3         NESTED LOOPS (OUTER)
   5    4           HASH JOIN (Cost=235998 Card=1 Bytes=365)
   6    5             VIEW (Cost=198149 Card=987557 Bytes=335769380)
   7    6               SORT (UNIQUE) (Cost=198149 Card=987557 Bytes=2
          24175439)
   8    7                 FILTER
   9    8                   HASH JOIN (Cost=181816 Card=987557 Bytes=2
          24175439)
10    9                     TABLE ACCESS (FULL) OF 'CSCRPT_CATEGORIE
          S' (Cost=6 Card=6803 Bytes=292529)
11    9                     FILTER
12   11                       HASH JOIN (OUTER)
13   12                         HASH JOIN (Cost=163701 Card=894900 B
          ytes=145868700)
14   13                           HASH JOIN (Cost=129012 Card=360796
           Bytes=49429052)
15   14                             HASH JOIN (Cost=68118 Card=32221
          6 Bytes=35121544)
16   15                               TABLE ACCESS (FULL) OF 'CSCRPT
          CUSTOMERSTAB' (Cost=9302 Card=317965 Bytes=6677265)
17   15                               TABLE ACCESS (FULL) OF 'SBB_BA
          SE_TAB' (Cost=55749 Card=2397901 Bytes=211015288)
18   14                             TABLE ACCESS (FULL) OF 'HSE_BASE
          _TAB' (Cost=48688 Card=23936080 Bytes=670210240)
19   13                           TABLE ACCESS (FULL) OF 'CSCRPT_TRA
          NSACTIONS_TAB' (Cost=17313 Card=35912894 Bytes=933735244)
20   12                         VIEW OF 'CSCRPT_CUSTOMERS_ALL_VW' (C
          ost=9302 Card=15978119 Bytes=335540499)
21   20                           TABLE ACCESS (FULL) OF 'CSCRPT_CUS
          TOMERS_TAB' (Cost=9302 Card=15978119 Bytes=335540499)
22    8                   COUNT (STOPKEY)
23   22                     TABLE ACCESS (BY INDEX ROWID) OF 'ACCOUN
          T_TYPE_SPA' (Cost=2 Card=1 Bytes=18)
24   23                       INDEX (RANGE SCAN) OF 'ACCOUNT_TYPE_SP
          A_UK01_I' (UNIQUE) (Cost=2 Card=1)
25    5             TABLE ACCESS (FULL) OF 'CSCRPT_TRANSACTIONS_TAB'
           (Cost=17313 Card=35912894 Bytes=897822350)
26    4           VIEW PUSHED PREDICATE OF 'CSCRPT_CUSTOMERS_ALL_VW'
           (Cost=1 Card=1 Bytes=21)
27   26             TABLE ACCESS (BY INDEX ROWID) OF 'CSCRPT_CUSTOME
          RS_TAB' (Cost=2 Card=1 Bytes=21)
28   27               INDEX (UNIQUE SCAN) OF 'CSCRPT_CUSTOMERS_PK' (
          UNIQUE) (Cost=2 Card=1)
29    2       SORT (AGGREGATE)
30   29         FILTER
31   30           NESTED LOOPS (OUTER)
32   31             TABLE ACCESS (BY INDEX ROWID) OF 'CSCRPT_TRANSAC
          TIONS_TAB' (Cost=5 Card=5 Bytes=110)
33   32               INDEX (RANGE SCAN) OF 'CSCRPT_TRANSACTIONS_N3'
           (NON-UNIQUE) (Cost=3 Card=5)
34   31             VIEW PUSHED PREDICATE OF 'CSCRPT_CUSTOMERS_ALL_V
          W' (Cost=1 Card=1 Bytes=21)
35   34               FILTER
36   35                 TABLE ACCESS (BY INDEX ROWID) OF 'CSCRPT_CUS
          TOMERS_TAB' (Cost=2 Card=1 Bytes=21)
37   36                   INDEX (UNIQUE SCAN) OF 'CSCRPT_CUSTOMERS_P
          K' (UNIQUE) (Cost=2 Card=1)
Statistics
       4519 recursive calls
          2 db block gets
   64793132 consistent gets
    2936560 physical reads
          0 redo size
     536683 bytes sent via SQL*Net to client
       2920 bytes received via SQL*Net from client
        287 SQL*Net roundtrips to/from client
         78 sorts (memory)
          0 sorts (disk)
       4286 rows processedI am in the process of getting stats for the ones which were collected in 2004.
I am thinking as the plan shows some FTS steps for those views (base tables for which stats were collected in 2004) and as there are indexes on those tables, the plan might change after stats collection.
I appreciate your inputs in this.
Thanks
Rajiv
Message was edited by:
RajivTx
Message was edited by:
RajivTx

I am trying the INDEX hint
INDEX(table [index]) Forces an index scan of the specified table using the specified index(s). If a list of indexes is specified, the optimizer chooses the one with the lowest cost. If no index is specified then the optimizer chooses the available index for the table with the lowest cost.
I am confused whether I need to use the above hint or
/*+ hint(view_name.table_in_view) */
as I have views in the FROM clause.
Thanks
Rajiv

Can we change GATHER_STATS_PROG (auto gather stat job) behavior

Hi All,
Is anyway we can change default oracle auto gather job ?
We know that oracle gather job (GATHER_STATS_JOB, below 11g) will trigger base on the Maintenance Window, we have few huge Production environment.
We're thinking to gather application schema stat by using our own scripts, thus would like to know is anyway we can still enable oracle auto gather stat
but exclude application schema?
Thanks in advance.
Regards,
Klnghau

Hi All,
Forgot to mention my oracle version is 10.2.0.4, and I think i find the solution from My Oracle support,
Oracle10g: New DBMS_STATS parameter AUTOSTATS_TARGET [ID 276358.1]
This is a new parameter in Oracle10g for the DBMS_STATS package.
According to the documentation for this package in file dbmsstat.sql
(under ORACLE_HOME/rdbms/admin):
This parameter is applicable only for auto stats collection.
The value of this parameter controls the objects considered for stats collection.
It takes the following values:
'ALL' -- statistics collected for all objects in system
'ORACLE' -- statistics collected for all oracle owned objects
'AUTO' -- oracle decides for which objects to collect stats
Default is AUTO, i think i can chenge to ORACLE in my environment.
Thanks

'auto optimizer stats collection' in em12cr3

Similar Messages

Maybe you are looking for