COMPUTE INDEX vs. SYS.DBMS_STATS.GATHER_INDEX_STATS

Hi,
I've got an Oracle 9 database.
I am creating an index. I had created this index using the following syntax:
CREATE INDEX index1. . . . . . COMPUTE STATISTICS;
One of my colleagues tells me that I should scrap 'COMPUTE STATISTICS' and instead make this a two step process:
(1) CREATE INDEX index1. . . . .
(2) SYS.DBMS_STATS.GATHER_INDEX_STATS
OwnName => 'schema'
,IndName => 'index_name'
,Estimate_Percent => 10
,Degree => 4
,No_Invalidate => FALSE);
Is there any advantage to using SYS.DBMS_STATS.GATHER_INDEX_STATS instead of 'COMPUTE STATISTICS'?
Thanks,
Tom

9i references<br>
In particular...<br>
Deprecated at 10<br>

Similar Messages

Error while running: SYS.DBMS_STATS Package.

when i am trying to execute the DBMS_STATS Package inside a procedure, getting the error.
ORA-12805: parallel query server died unexpectedly
ORA-06512: at "SYS.DBMS_STATS", line 9643
ORA-06512: at "SYS.DBMS_STATS", line 10137
ORA-06512: at "SYS.DBMS_STATS", line 10324
ORA-06512: at "SYS.DBMS_STATS", line 10378
ORA-06512: at "SYS.DBMS_STATS", line 10355
ORA-06512: at line 2
Can anyone help me out.I dont know much of the DBA stuff.

Hi,
Try setting the following parameters in init.ora:
dbhandles_cached = 0
hash_join_enabled=false
timed_statistics = false
If the problem still reproduces then try increasing your SORT_AREA_SIZE of your session to a larger value.
When a ORA-12805 occurs in most cases it is accompanied with a ORA-600 or a ORA-7445. Hence please check your alert.log if such errors are reported there.
Verify the files of the temporary tablespace of type TEMPORARY are in a full file system ( no free space available).
Nicolas.

Gather Stats on Newly Partitioned Table

I partitioned an existing table containing 92 million rows. The method was using dbms_redefinition, whereby I started the redef and then added the indexes and constraints last. After partitioning, I did not gather stats on any of the partitions that were created and I did not analyze any of the indexes. Then I loaded an additional 4 million records into on of the partitions of the newly partitioned table. I ran dbms gather stats on this particular partition and it took over 15 hours. Normally it only takes 4 hours to run dbms gather stats on the individual partitions, so I stopped it after 15 hours. When I monitored it while it was running, it looked like it was taking a really long time gathering stats on the indexes. Is this normal for a newly partitioned table? Is there something I can to prevent it from taking so long when I run gather stats? Oracle Version 10.2.0.4

-- Gather PARTITION Statistics
SYS.DBMS_STATS.gather_table_stats(ownname => upper(v_table_owner), tabname => upper(v_table_name),
partname =>v_table_partition_name, estimate_percent => 20, cascade=> FALSE,granularity => 'PARTITION');
-- Gather GLOBAL INDEX Statistics
for i in (select * from sys.dba_indexes where table_owner = upper(v_table_owner)
and table_name = upper(v_table_name) and partitioned = 'NO'
order by index_name)
loop
SYS.DBMS_STATS.gather_index_stats(ownname => upper(v_table_owner), indname => i.index_name,
estimate_percent => 20, degree => NULL);
end loop;
-- Gather SUB-PARTITION Statistics
SYS.DBMS_STATS.gather_table_stats(ownname => upper(v_table_owner), tabname => upper(v_table_name),
partname =>v_table_subpartition_name, estimate_percent => 20, cascade=> TRUE,granularity => 'ALL');

INVALID SYS INDEX

runiny this query
Select * From dba_indexes i
Where i.status!='VALID'
i am getting many sys index with status =N/A
all the index start whit WRH$_
is it possible to run rebuild index for sys index

Hi
You have not posted the version of ORACLE. ??
I hope you are using 10g versions series. Did you check any alert messages in your alert log file with respect to these indexes which you have pointed out. ??
See, you can ignore the indexs which are not valid with respect to you "WRH$_". this happens when AWR runs or executes space management routine with help of "dbms_workload_repository" package due to which some of the workload repositorty tables are moved to sysaux tablespace that is the backend functionality or say routine job carried out by oracle, in turn that indexs get invalidated.
HTH
- Pavan Kumar N

How to tell a select statement to ignore an index?

Dear All,
I have a big query that uses many indexes, but when i create a new index on the table accessed by the query, the query will try to use that additional index and so it performs badly. Can you tell me how to tell this query to ignore this index, because I need the index in other queries and I can't drop it.
Regards
Wassim

As Tubby already said, you need to create the index with statistics or at least analyze it just after the creation.
Else the CBO will think that the index is much smaller than all the other indices.
And therefore it will prefere the new index.
exec dbms_stats.gather_index_stats('mySchemaName','myIndexName',null, 100); You could also add "COMPUTE STATISTICS" to the create index command.
Sometimes it is useful to analyze the indexed column, but only if you have an uneven data distibution.
Edited by: Sven W. on Nov 6, 2008 10:02 AM

"analyze index" vs "rebuild index"

Hi,
I don't undestand the difference between "analyze index" and "rebuild index".
I have a table where I do a lot of "insert" and "update" and "query", What is the best thing to do ??
thanks
Giordano

When you use dbms_stats.gather_schema_stats package with cascade=>true option, you are also collecting stats for the indexes, no need to collects stats separately using dbms_stats.gather_index_stats.Of course, but I refered to the rebuild index question. Therefore I only mentioned the GATHER_INDEX_STATS.
Auto_sample_size has many problems/bugs in 9iOk didn't know that - I'm using 10gR2.
But this discussion made me curious. So I tried something (10gR2):
CREATE TABLE BIG NOLOGGING AS
WITH GEN AS (
SELECT ROWNUM ID FROM ALL_OBJECTS WHERE ROWNUM <=10000)
SELECT V1.ID,RPAD('A',10) C FROM GEN V1,GEN V2
WHERE ROWNUM <=10000000;
SELECT COUNT(*) FROM BIG;
COUNT(*)
10000000
So I had a Table containing 10 Million rows. Now I indexed ID:
CREATE INDEX BIG_IDX ON BIG(ID)
I tested two different methods:
1.) GATHER_TABLE_STATS with estimate 10%
EXEC DBMS_STATS.GATHER_TABLE_STATS(TABNAME=>'BIG',OWNNAME=>'DIMITRI',CASCADE=>TRUE,ESTIMATE_PERCENT=>10);
It took about 6 seconds (I only set timing on in sqlplus, no 10046 trace) Now I checked the estimated values:
SELECT NUM_ROWS,SAMPLE_SIZE,ABS(10000000-NUM_ROWS)/100000 VARIANCE,'TABLE' OBJECT FROM USER_TABLES WHERE TABLE_NAME='BIG'
UNION ALL
SELECT NUM_ROWS,SAMPLE_SIZE,ABS(10000000-NUM_ROWS)/100000 VARIANCE,'INDEX' OBJECT FROM USER_INDEXES WHERE INDEX_NAME='BIG_IDX';
NUM_ROWS SAMPLE_SIZE VARIANCE OBJEC
9985220 998522 ,1478 TABLE
9996210 999621 ,0379 INDEX
2.) GATHER_TABLE_STATS with DBMS_STATS.AUTO_SAMPLE_SIZE
EXEC DBMS_STATS.DELETE_TABLE_STATS(OWNNAME=>'DIMITRI',TABNAME=>'BIG');
EXEC DBMS_STATS.GATHER_TABLE_STATS(TABNAME=>'BIG',OWNNAME=>'DIMITRI',CASCADE=>TRUE,ESTIMATE_PERCENT=>DBMS_STATS.AUTO_SAMPLE_SIZE);
It took about 1,5 seconds. Now the results:
NUM_ROWS SAMPLE_SIZE VARIANCE OBJEC
9826851 4715 1,73149 TABLE
10262432 561326 2,62432 INDEX
The estimate 10% was more exact - also a 1,7 and 2,6 percent variance is still ok. It's also very interesting, that using AUTO_SAMPLE_SIZE
causes oracle to execute a estimate 5% for the index and a estimate 0.5 for the table.
I tried again with a table containing only 1 Million records and oracle did an estimate with 100% for the index.
So for me I will continue using AUTO_SAMPLE_SIZE. Its very flexible, fast and accurate.
Dim
PS: Is there a way to format code like one can do in HTML using <code> or <pre>?

Index not used on view when table stats exist

Hello,
I would be grateful if someone comes with ideas on the following problem I'm currently facing.
I have a table with XMLTYPE data type column:
sql-->desc ACFBNK_STMT008
RECID NOT NULL VARCHAR2(200)
XMLRECORD XMLTYPE
I have a view V_ACFBNK_STMT008 on that table, in which the view columns are defined as extracted tags values from the XMLTYPE field, e.g. for the view field N_BOOKING_DATE:
numcast(extractValue(xmlrecord,'/row/c25')) "N_BOOKING_DATE"
(note: numcast is just a simple function that returns TO_NUMBER of its input argument)
I have also a function-based index on this field of the table:
CREATE INDEX train4.NIX_ACFBNK_STMT008_C25
ON train4.ACFBNK_STMT008("TRAIN4"."NUMCAST"(extractValue(xmlrecord,'/row/c25')))
And so, I'm executing on the view the following SQL statement:
SELECT RECID FROM V_ACFBNK_STMT008 WHERE (N_BOOKING_DATE > TO_NUMBER('20070725'));
Now, the problem comes: when statistics exist on the view base table (that is ACFBNK_STMT008) then the above statement is not using the index and is making a "table access full". When I delete the statistics for the table then the SQL runs fast with an "index range scan".
Which is further strange - when I change the ">" operand with a "=" the SQL statement correctly captures the index regardless of whether or not statistics exist.
I've tried to manually rewrite the SQL and include the "numcast" function in it:
SELECT RECID FROM TRAIN4.V_ACFBNK_STMT008 WHERE ( N_BOOKING_DATE>train4.numcast(TO_NUMBER( '20010725' ) ));
And in this way the index is used OK even with statistics existing!
But regretfully I don't have a way to change the application and the SQL, so the only things I can change is the view and/or the index.
Thank you in advance,
Evgeni
P.S.
I've tried gathering statistics in both the following ways but still the problem persists:
sql-->analyze table train4.ACFBNK_STMT008 compute statistics;
sql-->exec dbms_stats.gather_table_stats(ownname=>'TRAIN4', tabname=>'ACFBNK_STMT008', CASCADE=>TRUE, partname=>NULL);

Oh, and I forgot to mention: I cannot change the view definition as well (for example, to remove the "numcast"), since every now and then the application would recreate it automatically with the same code. :(

Performance issue with drop and re-create index

My database table has about 2 million records. The index in the table was not optmized, so we created a new index lets call it index2. So this table now was the original index (index1) and the index2. We then inserted data into this table from the other box. It was running for a few weeks.
Suddenly we noticed that a query which used to take a few seconds now took more than a minute. The execution plan was using the index2 which technically should be faster. We checked if the statistics were upto date and it was. So then we dropped the new index, re-ran the query and it completed in 10 sec's. It was usign the old index. This puzzled me since the point of the index2 was to make it better. So then we re-created index2 and genrated stats for the index. Re-ran the query and it completed in 5 sec's.
Everytime we timed to run the query, I shutdown and restarted the box to clear all cache's. So all the time I have specified are pure time's and not cached. The execution plan using index2 taking 1 min and 5 sec's are nearly the same, with very minior difference in cost and cardnitality. Any ideas why index2 took 1 min before and after drop and create again takes only 5 sec.
The reason I want to find the cause is to ensure that this doesn't happen again, since its impossible for me to re-create the index everytime I see this issue. Any thoughts would be helpful.

Firstly the indexes are different index1 is only on the time column, where as index2 is a composite index consisting of 3 columns.
Here are the details. The test that I did were last friday, 3/31. Yesterday and today when I executed the same query I get more increased times, yesterday it took 9 sec amd today 17 sec. The stats job kicked in on both days and is upto date. This table, nothing gets deleted. Only added.
3/31
Original
Elapsed: 00:01:02.17
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=6553 Card=9240 Bytes
=203280)
1 0 SORT (UNIQUE) (Cost=6553 Card=9240 Bytes=203280)
2 1 INDEX (FULL SCAN) OF 'EVENT_NA_TIME_ETYPE' (NON-UNIQ
UE) (Cost=15982 Card=2306303 Bytes=50738666)
drop index EVENT_NA_TIME_ETYPE
Elapsed: 00:00:11.91
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=7792 Card=9275 Bytes
=204050)
1 0 SORT (UNIQUE) (Cost=7792 Card=9275 Bytes=204050)
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'EVENT' (Cost=2092
Card=2284254 Bytes=50253588)
3 2 INDEX (RANGE SCAN) OF 'EVENT_TIME_NDX' (NON-UNIQUE
) (Cost=6740 Card=2284254)
create index EVENT_NA_TIME_ETYPE ON EVENT(NET_ADDRESS,TIME,EVENT_TYPE);
BEGIN
SYS.DBMS_STATS.GENERATE_STATS('USER','EVENT_NA_TIME_ETYPE',0);
end;
Elapsed: 00:00:05.14
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=6345 Card=9275 Bytes
=204050)
1 0 SORT (UNIQUE) (Cost=6345 Card=9275 Bytes=204050)
2 1 INDEX (FULL SCAN) OF 'EVENT_NA_TIME_ETYPE' (NON-UNIQ
UE) (Cost=12878 Card=2284254 Bytes=50253588)
4/3
Elapsed: 00:00:09.70
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=6596 Card=9316 Bytes
=204952)
1 0 SORT (UNIQUE) (Cost=6596 Card=9316 Bytes=204952)
2 1 INDEX (FULL SCAN) OF 'EVENT_NA_TIME_ETYPE' (NON-UNIQ
UE) (Cost=11696 Card=2409400 Bytes=53006800)
Statistics
0 recursive calls
0 db block gets
11933 consistent gets
9676 physical reads
724 redo size
467 bytes sent via SQL*Net to client
503 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
3 rows processed
4/4
Elapsed: 00:00:17.99
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=6681 Card=9421 Bytes
=207262)
1 0 SORT (UNIQUE) (Cost=6681 Card=9421 Bytes=207262)
2 1 INDEX (FULL SCAN) OF 'EVENT_NA_TIME_ETYPE' (NON-UNIQ
UE) (Cost=12110 Card=2433800 Bytes=53543600)
Statistics
0 recursive calls
0 db block gets
12279 consistent gets
9423 physical reads
2608 redo size
467 bytes sent via SQL*Net to client
503 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
3 rows processed
SQL> select index_name,clustering_factor,blevel,leaf_blocks,distinct_keys from u ser_indexes where index_name like 'EVENT%';
INDEX_NAME CLUSTERING_FACTOR BLEVEL LEAF_BLOCKS DISTINCT_KEYS
EVENT_NA_TIME_ETYPE 2393170 2 12108 2395545
EVENT_PK 32640 2 5313 2286158
EVENT_TIME_NDX 35673 2 7075 2394055

OracleText problematic CONTEXT index

Hello,
Please take a look at the definition bellow:
CREATE INDEX SCHEMA.prs_names_ldx ON SCHEMA.PERSON(NAMES_XML) INDEXTYPE IS CTXSYS.CONTEXT
parameters ('LEXER cust_lexer SYNC (ON COMMIT) filter ctxsys.null_filter section group ctxsys.auto_section_group') ONLINE;
ctxsys.ctx_ddl.create_preference ('cust_lexer','BASIC_LEXER');
ctxsys.ctx_ddl.set_attribute ('cust_lexer','base_letter','YES'); -- removes diacritics
ctx_ddl.set_attribute('cust_lexer', 'alternate_spelling', 'GERMAN');
The person table has about 11.000.000 records.
The fact is that about two months after the index was created, the search got slower and slower. I tried to SYS.DBMS_STATS.GATHER_TABLE_STATS and to rebuild the index, but neither worked. The only solution that solved the issue was to drop and recreate the index.
And this happens every 1-2 months after the index is recreated.
I'm planning to create a job that will recreate the index before the operators can complain (in a shorter time span). This is just a dirty workaround, I know, but for now I don't have any other ideas.
Regarding this situation, I have two questions.
1. Is there any nasty implication about automatizing the index recreate procedure?
2. Do you have any suggestions about how I can further investigate the index degradation problem in time?
Thank you.
Kind regards,
Adrian

Do you optimize the index at all?
How frequently is the table updated?
With "sync(on commit)" your index will get more and more fragmented as each new record is sync'd.
You need to run ctx_ddl.optimize_index on a regular basis to remove this fragmentation. If you do that, you shouldn't need to recreate the index regularly.
A typical optimzation regime is to run it in "FULL" mode nightly, and then run "REBUILD" mode once a week, or once a month.

Error while using DBMS_STATS.GATHER_schema_STATS

Hi All,
My database just got upgraded from Oracle 9i to Oracle 11g.
While everything else is working fine post upgrade Oracle, the DBMS_STATS.GATHER_schema_STATS with METHOD_OPT => 'FOR COLUMNS SIZE ALL' , which was working fine in Oracle 9i is throwing error after upgarde.
Below is the error I received:
SQL> execute DBMS_STATS.GATHER_schema_STATS ('cins_dm', METHOD_OPT => 'FOR COLUMNS SIZE AUTO');
BEGIN DBMS_STATS.GATHER_schema_STATS ('cins_dm', METHOD_OPT => 'FOR COLUMNS SIZE AUTO'); END;
ERROR at line 1:
ORA-20001: method_opt should follow the syntax "[FOR ALL [INDEXED|HIDDEN] COLUMNS [size_caluse]]" when gathering statistics on a group of tables
ORA-06512: at "SYS.DBMS_STATS", line 9641
ORA-06512: at "SYS.DBMS_STATS", line 9716
ORA-06512: at "SYS.DBMS_STATS", line 10048
ORA-06512: at "SYS.DBMS_STATS", line 18939
ORA-06512: at "SYS.DBMS_STATS", line 19132
ORA-06512: at "SYS.DBMS_STATS", line 19088
ORA-06512: at line 1
OS Details:
Has this option got obsolete in Oracle 11g?
What is the alternative to this?
OS and Databse Details*
OS:
scrbbiddkbry002:sas# uname -a
SunOS scrbbiddkbry002 5.9 Generic_122300-51 sun4u sparc SUNW,Sun-Fire-V240
Oracle Client:
SQL*Plus: Release 9.2.0.1.0 - Production
Oracle Server:
SQL> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
PL/SQL Release 11.1.0.7.0 - Production
CORE 11.1.0.7.0 Production
TNS for Solaris: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - Production
Edited by: user13071592 on Aug 3, 2010 2:38 AM

Hi,
While going through the link, it seems that METHOD_OPT => 'FOR COLUMNS SIZE AUTO' is obsolete in Oracle 11g and I will have to use METHOD_OPT => 'FOR ALL COLUMNS SIZE AUTO' instead of that. But the option METHOD_OPT => 'FOR COLUMNS SIZE AUTO' used to take just 5 minutes to complete while METHOD_OPT => 'FOR ALL COLUMNS SIZE AUTO' is taking 1 hour.
I want it to take time (5-6 minutes) which the original METHOD_OPT => 'FOR COLUMNS SIZE AUTO' was taking.

Index issue - dont understand the cost

Hello
I have a 112mil row table that I have copied to a new tablespace, which worked fine
I'm then adding indexes to the copied table, but gets huge costs in the plans when trying to do a query using the new index, compared to quirying the original table/indexes
To begin with I tired changing my main index to another tablespace and bigger initial extend, but even if I remove all this, and put it in the same tablespace as the original index and created the same way, I get the same huge difference.
In most om my system queries this will cause that the CBO doesn't use the index, and the queries get very slow. If I do a simple select and the index is actually chosen, even though the cost is huge, the actual query time is the same as the origibal table/query. I cant get the index cost to change by trying different dbms_stats.gather_index_stats settings
Can anybody tell me why this new index comes up with such a huge cost, and what I can do to bring the cost down, so that the index actually gets chosen?
Here are the basic information:
It's on Oracle 10gR2 (10.2.0.4) EE
The simplyfied create statement for both the original and the new index:
CREATE INDEX IDX_POS_DATE ON FMC_POS
("UTC_DATE" DESC, FMC_LOGVES_ID)
CREATE INDEX IDX_POS_DATE_P2 ON FMC_POS_p2
("UTC_DATE" DESC, FMC_LOGVES_ID)
The two indexes in dba_indexes:
Original:
OWNER: VTRACK
INDEX_NAME: IDX_POS_DATE
INDEX_TYPE: FUNCTION-BASED NORMAL
TABLE_OWNER: VTRACK
TABLE_NAME: FMC_POS
TABLE_TYPE: TABLE
UNIQUENESS: NONUNIQUE
COMPRESSION: DISABLED
PREFIX_LENGTH:
TABLESPACE_NAME: USERS
INI_TRANS: 2
MAX_TRANS: 255
INITIAL_EXTENT: 65536
NEXT_EXTENT:
MIN_EXTENTS: 1
MAX_EXTENTS: 2147483645
PCT_INCREASE:
PCT_THRESHOLD:
INCLUDE_COLUMN:
FREELISTS:
FREELIST_GROUPS:
PCT_FREE: 10
LOGGING: YES
BLEVEL: 3
LEAF_BLOCKS: 439239
DISTINCT_KEYS: 108849202
AVG_LEAF_BLOCKS_PER_KEY: 1
AVG_DATA_BLOCKS_PER_KEY: 1
CLUSTERING_FACTOR: 79021005
STATUS: VALID
NUM_ROWS: 110950137
SAMPLE_SIZE: 2177632
LAST_ANALYZED: 09-05-2011 23:38:15
DEGREE: 1
INSTANCES: 1
PARTITIONED: NO
TEMPORARY: N
GENERATED: N
SECONDARY: N
BUFFER_POOL: DEFAULT
USER_STATS: NO
DURATION:
PCT_DIRECT_ACCESS:
ITYP_OWNER:
ITYP_NAME:
PARAMETERS:
GLOBAL_STATS: YES
DOMIDX_STATUS:
DOMIDX_OPSTATUS:
FUNCIDX_STATUS: ENABLED
JOIN_INDEX: NO
IOT_REDUNDANT_PKEY_ELIM: NO
DROPPED: NO
New:
OWNER: VTRACK
INDEX_NAME: IDX_POS_DATE_P2
INDEX_TYPE: FUNCTION-BASED NORMAL
TABLE_OWNER: VTRACK
TABLE_NAME: FMC_POS_P2
TABLE_TYPE: TABLE
UNIQUENESS: NONUNIQUE
COMPRESSION: DISABLED
PREFIX_LENGTH:
TABLESPACE_NAME: USERS
INI_TRANS: 2
MAX_TRANS: 255
INITIAL_EXTENT: 65536
NEXT_EXTENT:
MIN_EXTENTS: 1
MAX_EXTENTS: 2147483645
PCT_INCREASE:
PCT_THRESHOLD:
INCLUDE_COLUMN:
FREELISTS:
FREELIST_GROUPS:
PCT_FREE: 10
LOGGING: YES
BLEVEL: 3
LEAF_BLOCKS: 408128
DISTINCT_KEYS: 111888565
AVG_LEAF_BLOCKS_PER_KEY: 1
AVG_DATA_BLOCKS_PER_KEY: 1
CLUSTERING_FACTOR: 88607794
STATUS: VALID
NUM_ROWS: 112757727
SAMPLE_SIZE: 112757727
LAST_ANALYZED: 23-06-2011 07:57:14
DEGREE: 1
INSTANCES: 1
PARTITIONED: NO
TEMPORARY: N
GENERATED: N
SECONDARY: N
BUFFER_POOL: DEFAULT
USER_STATS: NO
DURATION:
PCT_DIRECT_ACCESS:
ITYP_OWNER:
ITYP_NAME:
PARAMETERS:
GLOBAL_STATS: NO
DOMIDX_STATUS:
DOMIDX_OPSTATUS:
FUNCIDX_STATUS: ENABLED
JOIN_INDEX: NO
IOT_REDUNDANT_PKEY_ELIM: NO
DROPPED: NO
The simple selects and costs:
Original table/index:
select * from fmc_pos where utc_date>sysdate-10
Plan:
SELECT STATEMENT ALL_ROWS
Cost: 5 Bytes: 5.350 Cardinality: 50
2 TABLE ACCESS BY INDEX ROWID TABLE VTRACK.FMC_POS
Cost: 5 Bytes: 5.350 Cardinality: 50
1 INDEX RANGE SCAN INDEX VTRACK.IDX_POS_DATE
Cost: 4 Cardinality: 1
Original table/index:
select * from fmc_pos_p2 where utc_date>sysdate-10
Plan:
Plan
SELECT STATEMENT ALL_ROWS
Cost: 3.067 Bytes: 2.708.856 Cardinality: 25.082
2 TABLE ACCESS BY INDEX ROWID TABLE VTRACK.FMC_POS_P2
Cost: 3.067 Bytes: 2.708.856 Cardinality: 25.082
1 INDEX RANGE SCAN INDEX VTRACK.IDX_POS_DATE_P2
Cost: 2.927 Cardinality: 177

KlausMogensen wrote:
You are exactly right. The plan for the original table is to good to be true when searching for recent dates, because the statistics are outdated. If I do searches for older data, I get the same cost for both selects
The funny part is that the outdated to good to be true statistics gives me the better performance for the more complex selects in the system, because the index always gets chosen. I guess I will have to use hints in my complex selects
It's possible that the clustering_factor of the index is not a good model of how well the data really is clustered. The method the optimizer uses to calculate this figure is very naive and can easily be much too high if the data has even a fairly small degree of scatter (relative to the index). You may find that modifying the clustering_factor in a realistic way will solve the problem. Since the optimizer is also pessimistic about branch block caching in nested loops and in-list iterators you could also consider reducing the blevel by 1 or 2 to encourage it to use a good index.
There's a note on my blog about adjusting index stats: http://jonathanlewis.wordpress.com/2010/01/06/copy-stats/
Regards
Jonathan Lewis

Need help in DBMS_STATS - Oracle 10.1.0.5

Folks, when I ran SCHEMA STATS using DBMS_STATS in my Oracle 10.1.0.5 db, I got error message. Pl help..
Lily,
===================================================
SQL> EXEC DBMS_STATS.CREATE_STAT_TABLE ('IDIS_DBA','IDISDBA_STATTAB','IDIS_REFERENCE_D');
PL/SQL procedure successfully completed.
SQL> rem -running table monitoring now
SQL> EXEC DBMS_STATS.ALTER_SCHEMA_TAB_MONITORING (ownname=>'IDIS_DBA',monitoring=>TRUE);
PL/SQL procedure successfully completed.
SQL> EXEC DBMS_STATS.GATHER_SCHEMA_STATS(ownname=>'IIS_DBA',options=>'GATHER AUTO');
BEGIN DBMS_STATS.GATHER_SCHEMA_STATS(ownname=>'IIS_DBA',options=>'GATHER AUTO'); END;
ERROR at line 1:
ORA-12801: error signaled in parallel query server P015
ORA-00904: : invalid identifier
ORA-06512: at "SYS.DBMS_STATS", line 12887
ORA-06512: at "SYS.DBMS_STATS", line 13181
ORA-06512: at "SYS.DBMS_STATS", line 13289
ORA-06512: at "SYS.DBMS_STATS", line 13249
ORA-06512: at line 1
Elapsed: 00:00:06.55
===========================BUT when I ran table level schema, It got thru....
SQL>
SQL>
SQL>
SQL> exec DBMS_STATS.GATHER_TABLE_STATS ('IDIS_DBA','BI_CLNT2',NULL, 20, FALSE, 'FOR ALL INDEXED COL
UMNS SIZE 75', NULL, 'DEFAULT', TRUE);
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.10
SQL>

If the data never changes, there would be no reason to gather statistics.
If the data changes, there may or may not be a reason to gather statistics. There is some risk to gathering statistics because that can cause query plans to change and you could find that a query that was working fine yesterday is running very slowly today. Failing to gather statistics, though, can have the same effect-- if a histogram on a column indicates that the maximum value of a date field is December 1, 2006 because you haven't updated statistics in a few days, the CBO may conclude that a query this column with a value of December 4 would return very few row, rather than the many rows that are really there, causing Oracle to use a different query plan. Oracle tends to believe that the latter risk is more of a concern than the former and in 10g regularly and automatically gathers statistics unless you susped that job. Some DBAs disagree with Oracle and prefer less frequent, more controlled statistics gathering.
If you GATHER AUTO, assuming your tables are set to MONITORING, Oracle gathers statistics on every table that has had more than some cutoff percentage of rows changed since statistics were last gathered. This cutoff is generally pretty reasonable, though ideally you'd probably want to gather statistics more frequently on smaller tables (adding 30 new rows to a 100 row table is probably more significant from a query plan perspective than adding 3 million rows to a 10 million row table) and less frequently on larger tables, more frequently on tables that have volatile data distributions (i.e. our DATE table) and less frequently on tables whose data distribution is relatively constant.
Justin

After rebuild a index need do more something?

If i move the indexes of "TESTE" schema to other tablespace and that indexes have been access for user "TESTEC" i will need to grant and recriate sinonym again for the that user?
O will use:
select     'alter index "'||owner||'"."'||index_name||'" rebuild tablespace "'||tablespace_name||'" ;' cmd
from     dba_indexes
where     owner = 'TESTE'
TKS,
ELBER.

I usually do the following
1) set sort area big:
-- Check the available memory on the OS with top.
-- If you go overboard on the memory allocation, sar –g will show paging
-- I usually set the sort_area_size some where between 200 and 900 meg to speed up index rebuilds
alter session set workarea_size_policy='MANUAL';
alter session set sort_area_size=900000000;
alter session set sort_area_retained_size=900000000;
2) use the following to rebuild each index so I can control the parallelism:
-- can also use online compress parallel 8
alter index "&1"."&2" rebuild parallel 8 nologging tablespace &3;
alter index "&1"."&2" noparallel;
execute dbms_stats.gather_index_stats('&1','&2',estimate_percent=>3)
3) You can also control the parallelism by setting:
parallel_min_percent=25
parallel_min_servers=10
parallel_max_servers=100

How to Gather Statistics of Tables and Indexes

Hi all,
Plz help me in Gathering Statistics of Tables and Indexes.
Thanks

for tables
exec dbms_stats.gather_table_stats('SCOTT', 'EMPLOYEES');
for indexes
exec dbms_stats.gather_index_stats('SCOTT', 'EMPLOYEES_PK');
check this link for detail
http://nimishgarg.blogspot.com/2010/04/oracle-dbmsstats-gather-statistics-of.html

PPS Tuning Advisory – Missing OOTB Index On s_audit_item In 8.x

Hi All,
We have had to add this missing OOTB index at several of our accounts so I wanted to pass this along. It is missing on deletes such as deleting of quotes.
-- azgpf8ju1yj6s
ALTER SESSION SET OPTIMIZER_MODE = FIRST_ROWS_10 ;
ALTER SESSION SET "_OPTIMIZER_SORTMERGE_JOIN_ENABLED" = FALSE ;
ALTER SESSION SET "_OPTIMIZER_JOIN_SEL_SANITY_CHECK" = TRUE;
ALTER SESSION SET "_HASH_JOIN_ENABLED" = FALSE;
DELETE FROM SIEBEL.S_QUOTE_ITM_SPA WHERE ROW_ID IN
(SELECT TBL_RECORD_ID FROM SIEBEL.S_AUDIT_ITEM WHERE GROUP_NUM = :B1)
DROP INDEX SIEBEL.S_AUDIT_ITEM_CUSTOM01_X;
CREATE INDEX SIEBEL.S_AUDIT_ITEM_CUSTOM01_X ON SIEBEL.S_AUDIT_ITEM
GROUP_NUM
NOLOGGING
TABLESPACE SIEBEL1D
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 8M
NEXT 8M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
PARALLEL 6;
alter INDEX SIEBEL.S_AUDIT_ITEM_CUSTOM01_X
NOPARALLEL
LOGGING
begin
DBMS_STATS.GATHER_INDEX_STATS(
ownname => 'SIEBEL',
indname => 'S_AUDIT_ITEM_CUSTOM01_X',
estimate_percent => 100,
degree => DBMS_STATS.AUTO_DEGREE
end;
Robert Ponder
Lead Architect and Director
Ponder Pro Serve
cell: 770.490.2767
fax: 770.412.8259
email: [email protected]
web: www.ponderproserve.com
Edited by: Robert Ponder on Sep 13, 2010 7:18 PM

Hi,
it's a known issue (at least for me :)). DBMS_LOB is a special interface used by clients to operate with LOBs. When it is used to manipulate with LOB data, SQL engine is bypassed (OK, it's my speculation about that - actually it can't be bypassed), which results in accounting wait events to non-existent cursor (not parsed & executed) in the 10046 trace. Usually it's the first "available" cursor number in trace (I haven't seen another behavior). TKPROF will show all waits accounted for DBMS_LOB activities to OVERALL section, OraSRP would show it under 'unaccaunted for' section.
So that's the first part: DBMS_LOB actions are not accounted to a particular cursor in the trace.
There's second thing to remember: [direct path write|http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/waitevents.htm#sthref3038]
During Direct Path operations, the data is asynchronously written to the database filesand [direct path write and direct path write temp|http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/instance_tune.htm#i16292]
Like direct path reads, the number of waits is not the same as number of write calls issued if the I/O subsystem supports asynchronous writes
it means that the time for direct path operations is not real wall-clock time, it's just a time to submit an IO request if IO subsystem supports asynchronous IO. And that's explains "lost" wait time.
Also, parameters to that events are:
P1 - File_id for the write call
P2 - Start block_id for the write call
P3 - Number of blocks in the write callso P2 is not object id, nor data object id. Usually such cases are identified based on the number of 'direct path' events and looking at the raw trace file.

COMPUTE INDEX vs. SYS.DBMS_STATS.GATHER_INDEX_STATS

Similar Messages

Maybe you are looking for