Stats gathering on index.

Hi all

Why it is not possible to collect statistics on index in parallel, as mentioned in Metalink Note: 166215.1

What is different about the collection of statistics for tables and index? What is the internal mechanism for index stats collection using dbms_stats and why it is not possible to perform parallel to compare indexes in the table?

-Yasser.

Why it is not possible to collect statistics on index in parallel, as mentioned in Metalink Note: 166215.1

It is said, if DOP is not specified, the computer runs in the series or ANALYZE. If you specify dbms_default.degree, he returned to parallel as specified from your instance settings.

Object Stats========Number of rows in the tables being accessed Number of blocks allocated to the table Average table row length Number of distinct values for a column Number of nulls in a column Number of leaf blocks allocated to indexes Number of leveles in the B-Tree Clustering factor - how the order of the index matches the order of the table rows

Index statsNumber of leaf blocksLevelsClustering factor

Take a look at this note: How to switch from ANALYZE to DBMS_STATS - Introduction - 237293.1

Tags: Database

Similar Questions

Oracle E-Business 12.1.3/11.2.0.3 Stats gathering

Hi forum
I'm running stats of schema (per week) with the task of gathering Stats Conc schema.
This is done for all of the schema and the custom schema that we use.
Should I run any additional stats for SYS and SYSTEM tables / indexes?
Does anyone know what the best practice?
Thank you

Please see (FAQ EBPERF - collection of statistics in Oracle EBS 11i and R12 (Doc ID 368252.1)).

Thank you

Hussein

SELECT on a table in the INSERT statement uses the INDEX
Hello world

I have a strange problem with EA Oracle 10 g (64-bit) running on a Linux system. The situation is, I developed a Java program to migrate one client system to another. One of the steps in the migration fills a new table with the data from the old system. Given that the data on the old system structure is fundamentally different from that new, I have to check each time I read a line from the old system, if I have already created an entity on the new table, and if so, update certain attributes. The WHERE clause of this audit uses a key of the company indexed on the new table. The problem is now, that Oracle does not use the index on the key attribute of the company, but it makes table scans complete to select the line. As you can imagine, the lines first thousand or so go fast, but the amount increases, the program becomes slower and slower.

If I do a "scan" when executing the migration program, Oracle change the execution plan and use the index on the attribute key and everything works fast and smooth. However, if I do the analysis on the empty table first, nothing changes (which I understand it perfectly, since there is nothing to analyze, at this point). By integrating a hint of 'INDEX' (table) in the statement SELECT does not change the full implementation plan (also table scans).

Is it possible to change this behavior, in order to SELECT it uses the index of key business from the beginning?

Greetings from Cologne,

Thorsten.

Published by: thkitz on 13.03.2012 18:27
thkitz wrote:
```
SELECT STATEMENT  ALL_ROWSCost: 2  Bytes: 76  Cardinality: 2
     7 TABLE ACCESS BY INDEX ROWID TABLE AIDATINT.PRVVSSCHADENKORRESPONDENZ Cost: 2  Bytes: 76  Cardinality: 2
          6 BITMAP CONVERSION TO ROWIDS
               5 BITMAP OR
                    2 BITMAP CONVERSION FROM ROWIDS
                         1 INDEX RANGE SCAN INDEX AIDATINT.I_PRVVSSCHADENKORRESPONDENZ_1 Cost: 1
                    4 BITMAP CONVERSION FROM ROWIDS
                         3 INDEX RANGE SCAN INDEX AIDATINT.I_PRVVSSCHADENKORRESPONDENZ_2 Cost: 1  
```
I would have thought that as a plan as possible. It is not a concatenation, is a btree/bitmap conversion.
Allude to this plan you need / * + index_combine (table_alias index1 index2) * /.
For 10g and later the index can be specified by name or by description

I'm a bit puzzled why the plan changes after truncate - but maybe my comment about not cleared statistics is no longer true. It is easy enough to check if I'm right or wrong on your version of Oracle.

Concerning
Jonathan Lewis
http://jonathanlewis.WordPress.com
Author: core Oracle

Stats and new index

Hello
We have added a new index (global) range-hash partitioned table using oracle 11.2.0.3
My understanding is that thanks to new clues need not to collect statistics - generated instantly on the creation of index.
Is this correct?
Thank you

Yes because of Oracle 11 g Release 2 Administrators Guide Page 21-8: "these operations also collect index statistics.

State machine in queue with the producer consumer

Hello

I am trying to build a VI where the user allows some Boolean controls on the front panel.
VI uses a producer consumer in which based on Boolean values clicked architecture.
some States are queued one recorded in a table.
After the user is done by selecting, Boolean values should get disabled and the table of States
should be indexed one after the other.
It is an attempt to solve the review model car wash.
However, the VI does not generate the required results.
Can someone help me please understand what is the correct way to this implementation.

Thank you

Its because you have wired the consumer while loop the first stop. Remove and in your loop of consumer, make a comparison of the States that you receive and if it is equal to stop, stop the loop of the consumer.

[SQL] Tuning why he can't use indexes?

Here's a SQL that cannot use indexes

SELECT T.FID FID,

t.cfsignState SIGNSTATE,

T.FNUMBER WBNUMBER,

T1. CFCUSTOMERTRANSNUMBER CUNUMBER,

T2. CFCOMPANYNAME CUSTOMERNAME,

T.CFATTACHMENTFILE ATTFILE,

T.CFATTACHMENT ATT

OF CT_OPE_SIGNBILL T

LEFT OUTER JOIN CT_OPE_WAYBILL T1

ON T1. FID = T.CFWAYBILLID

LEFT OUTER JOIN T2 CT_MAR_CUSTOMER

ON T2. FID = T1. CFCUSTOMERID

WHERE ((T.FNUMBER ('1410582816' N)) OR (T1.) CFCUSTOMERTRANSNUMBER (N '1410582816')));

Elapsed time: 00:00:12.15

Execution plan

----------------------------------------------------------

Hash value of plan: 2925502694

------------------------------------------------------------------------------------------------------------------------

| ID | Operation | Name | Lines | Bytes | TempSpc | Cost (% CPU). Time | Pstart. Pstop |

------------------------------------------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT |                 |     2.   420.       | 48996 (3) | 00:01:16 |       |       |

|   1. NESTED EXTERNAL LOOPS |                 |     2.   420.       | 48996 (3) | 00:01:16 |       |       |

|* 2 |   FILTER |                 |       |       |       |            |          |       |       |

|* 3 |    EXTERNAL RIGHT HASH JOIN |                 |     2.   310.    67 M | 48995 (3) | 00:01:16 |       |       |

|   4.     RANGE OF PARTITION ALL THE |                 | 1241K |    53 M |       | 36422 (3) | 00:00:57 |     1.    63.

|   5.      TABLE ACCESS FULL | CT_OPE_WAYBILL | 1241K |    53 M |       | 36422 (3) | 00:00:57 |     1.    63.

|   6.     TABLE ACCESS FULL | CT_OPE_SIGNBILL |   907K |    95 M |       | 8217 (5) | 00:00:13 |       |       |

|   7.   TABLE ACCESS BY INDEX ROWID | CT_MAR_CUSTOMER |     1.    55.       |     1 (0) | 00:00:01 |       |       |

|* 8 |    INDEX UNIQUE SCAN | PK_MAR_CUSTOMER |     1.       |       |     1 (0) | 00:00:01 |       |       |

------------------------------------------------------------------------------------------------------------------------

Information of predicates (identified by the operation identity card):

---------------------------------------------------

2 - filter("T".") FNUMBER ' = U ' 1410582816 "OR 'T1'. '. CFCUSTOMERTRANSNUMBER '= U '1410582816')

3 - access("T1".") IDF"(+) ="T ". ("' CFWAYBILLID")

8 - access("T2".") IDF"(+) ="T1 ". ("' CFCUSTOMERID")

Statistics

----------------------------------------------------------

1 recursive calls

19 db block Gets

234698 compatible Gets

191546 physical reads

0 redo size

1035 bytes sent via SQL * Net to client

524 bytes received via SQL * Net from client

2 SQL * Net back and forth to and from the client

0 sorts (memory)

0 sorts (disk)

1 rows processed

but, if I rewrite it as below, it can use indexes

SELECT T.FID FID,

t.cfsignState SIGNSTATE,

T.FNUMBER WBNUMBER,

T1. CFCUSTOMERTRANSNUMBER CUNUMBER,

T2. CFCOMPANYNAME CUSTOMERNAME,

T.CFATTACHMENTFILE ATTFILE,

T.CFATTACHMENT ATT

OF CT_OPE_SIGNBILL T

LEFT OUTER JOIN CT_OPE_WAYBILL T1

ON T1. FID = T.CFWAYBILLID

LEFT OUTER JOIN T2 CT_MAR_CUSTOMER

ON T2. FID = T1. CFCUSTOMERID

WHERE ((T.FNUMBER (N '1410582816')))

Union

SELECT T.FID FID,

t.cfsignState SIGNSTATE,

T.FNUMBER WBNUMBER,

T1. CFCUSTOMERTRANSNUMBER CUNUMBER,

T2. CFCOMPANYNAME CUSTOMERNAME,

T.CFATTACHMENTFILE ATTFILE,

T.CFATTACHMENT ATT

OF CT_OPE_SIGNBILL T

LEFT OUTER JOIN CT_OPE_WAYBILL T1

ON T1. FID = T.CFWAYBILLID

LEFT OUTER JOIN T2 CT_MAR_CUSTOMER

ON T2. FID = T1. CFCUSTOMERID

WHERE ((T1. CFCUSTOMERTRANSNUMBER (N '1410582816')));

Elapsed time: 00:00:00.02

Execution plan

----------------------------------------------------------

Hash value of plan: 2215743926

-----------------------------------------------------------------------------------------------------------------------------------

| ID | Operation | Name                     | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |

-----------------------------------------------------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT |                          |     2.   420.    11 (64) | 00:00:01 |       |       |

|   1. UNIQUE FATE |                          |     2.   420.    11 (64) | 00:00:01 |       |       |

|   2.   UNION-ALL |                          |       |       |            |          |       |       |

|   3.    NESTED EXTERNAL LOOPS |                          |     1.   210 |     4 (0) | 00:00:01 |       |       |

|   4.     NESTED EXTERNAL LOOPS |                          |     1.   155.     3 (0) | 00:00:01 |       |       |

|   5.      TABLE ACCESS BY INDEX ROWID | CT_OPE_SIGNBILL |     1.   110.     2 (0) | 00:00:01 |       |       |

|* 6 |       INDEX RANGE SCAN | IDX_CT_OPE_SIGNBILL_IT01 |     1.       |     1 (0) | 00:00:01 |       |       |

|   7.      TABLE ACCESS BY INDEX ROWID | CT_OPE_WAYBILL | 1241K |    53 M |     1 (0) | 00:00:01 | ROWID | ROWID |

|* 8 |       INDEX UNIQUE SCAN | CPK_OPE_WAYBILLBP7 |     1.       |     1 (0) | 00:00:01 |       |       |

|   9.     TABLE ACCESS BY INDEX ROWID | CT_MAR_CUSTOMER | 25598 | 1374K |     1 (0) | 00:00:01 |       |       |

| * 10 |      INDEX UNIQUE SCAN | PK_MAR_CUSTOMER |     1.       |     1 (0) | 00:00:01 |       |       |

| 11.    NESTED LOOPS |                          |     1.   210 |     5 (0) | 00:00:01 |       |       |

| 12.     NESTED EXTERNAL LOOPS |                          |     1.   100.     4 (0) | 00:00:01 |       |       |

| 13.      TABLE ACCESS BY INDEX ROWID | CT_OPE_WAYBILL |     1.    45.     3 (0) | 00:00:01 | ROWID | ROWID |

| * 14 |       INDEX RANGE SCAN | IDX$ $_47CB0003 |     1.       |     2 (0) | 00:00:01 |       |       |

| 15.      TABLE ACCESS BY INDEX ROWID | CT_MAR_CUSTOMER |     1.    55.     1 (0) | 00:00:01 |       |       |

| * 16.       INDEX UNIQUE SCAN | PK_MAR_CUSTOMER |     1.       |     1 (0) | 00:00:01 |       |       |

| 17.     TABLE ACCESS BY INDEX ROWID | CT_OPE_SIGNBILL |     1.   110.     2 (0) | 00:00:01 |       |       |

| * 18.      INDEX RANGE SCAN | IDX$ $_47C30001 |     1.       |     1 (0) | 00:00:01 |       |       |

-----------------------------------------------------------------------------------------------------------------------------------

Information of predicates (identified by the operation identity card):

---------------------------------------------------

6 - access("T".") FNUMBER "= U '1410582816')

8 - access("T1".") IDF"(+) ="T ". ("' CFWAYBILLID")

10 - access("T2".") IDF"(+) ="T1 ". ("' CFCUSTOMERID")

14 - access("T1".") CFCUSTOMERTRANSNUMBER '= U '1410582816')

16 - access("T2".") IDF"(+) ="T1 ". ("' CFCUSTOMERID")

18 - access("T1".") IDF '=' T '. ("' CFWAYBILLID")

Statistics

----------------------------------------------------------

1 recursive calls

0 db block Gets

Gets 11 coherent

0 physical reads

0 redo size

1035 bytes sent via SQL * Net to client

524 bytes received via SQL * Net from client

2 SQL * Net back and forth to and from the client

1 sorts (memory)

0 sorts (disk)

1 rows processed

SQL >

My Question is why the first statement cannot use indexes? What is its mechanism?

as Maria Colgan explains in his commentary on https://blogs.oracle.com/optimizer/entry/or_expansion_transformation: "since OR expansion is a transformation focused on costs, it cannot always take place." It cannot take place, then it can be forced by using the indicator, USE_CONCAT. "Fundamentally OR expansion is

a transformation that can be used to optimize the disjunctive queries (queries that contain clauses of GOLD). The basic idea of in the expansion of the GOLD is to transform a query containing the disjunctions in the form of a query UNION ALL of two or more branches. This is done by dividing the disjunction in components and by associating each component with a branch of a query UNION all.

So, you can use the USE_CONCAT flag to check if OR expansion is an option at all for the optimizer in your example. The strategy itself is quite old and mentioned by Tom Kyte in https://asktom.oracle.com/pls/apex/f?p=100:11:0:P11_QUESTION_ID:921229345078.

Extremely slow synchronization of index of the substring

Oracle on RedHat Linux x 64 11.2.0.2 (5,7)
I created a partitioned CONTEXT index in a NOPOPULATE State. The index is defined on a column of a table partitioned using an attribute NULL_FILTER and SUBSTRING CLOB. I then used the following procedure to fill the files queued for indexing.
BEGIN
CTX_DDL. () POPULATE_PENDING
idx_name = > "CONTENT_VALUE_IDX"
part_name = > 'P_2012_12 '.
);
END;
/
This procedure seems to work for an appropriate period of time, but ended up with the following error:
ORA-20000: Oracle text error:
DRG-50857: error Oracle in drvddl. ProcessOnlinePending
ORA-20000: Oracle text error:
DRG-50857: error Oracle in textindexmethods. ODCIIndexDelete
ORA-20000: Oracle text error:
DRG-10607: index meta data are not ready yet for the DML queues
DRG-50857: error Oracle in drdmlpo
ORA-20000: Oracle text error:
DRG-10502: 1766 index does not exist
ORA-06512: at "CTXSYS. DRUE", line 160
ORA-06512: at "CTXSYS. DRVXMD', line 42
ORA-06512: at line 1
ORA-30576: dictionary of the context error loading Option
ORA-06512: at "CTXSYS. DRUE", line 160
ORA-06512: at "CTXSYS. CTX_DDL', line 1366
ORA-06512: at line 2
However, the number of records that have been entered in the DR$ PENDING corresponded with the same number of records in the table that is to be built on this index. So, I hope that this error can be ignored?
I then try to sync the lines on hold with the following text:
BEGIN
CTX_OUTPUT. START_LOG ('content_value.log');
END;
/
BEGIN
CTX_DDL. () SYNC_INDEX
idx_name = > "CONTENT_VALUE_IDX"
memory = > "2000 M",
part_name = > "P_2012_12"
parallel_degree = > 16
);
END;
/
The process begins in parallel 16 and logs show the documents being indexed. After about an hour or two, the paper then shows "Writing data index ($I) to the database." and then appears to process the data of the substring that the log shows "Substring writing data ($P) to the database." This is the point that the parallel process begins to go to series. Restraint begins to show in the data base. Blocking the session indicates an expectation of 'db file sequential read' event and the sessions that begin to queue have a wait state of ' enq: TX - line lock conflict.
$P TEXT table support is being filled and lines are deleted from the DR$ waiting for the table, then the process does work. The partition which was being indexed has only 27 lines, however the process lasted a few WEEKS before I finally killed the process.
There is a note on Metalink (parallel and series SYNC_INDEX text is slow when SUBSTRING_INDEX is enabled (Doc ID 840097.1)) which seems to solve this same scenario, but says that the problem should be solved in 11.2.0.2.
Another sync non-text substring index with no problems. The 'Oracle Text' option is valid in the data base and none of the CTXSYS objects are DISABLED.
Someone at - it ideas?

So, as you guessed correctly, the fundamental problem is that 16 parallel workers try to write to the table in the face of the claim and the substring by.

Our solution has been to change the parameter MAXTIME sync_index something very short - a half hour - so that the amount of data to write was a little smaller and the claim was broken up more quickly.

We did originally because we wanted more insight in the newspapers and the pace of progress in the indexing, but after testing with multiple values MAXTIME, we found that 30 minutes gave us the best overall in terms of indexed documents throughput / hour.

Your values will likely change, but with a bit of journaling, you should be able to find a practice, if a solution is not optimal.

How to create indexes on columns all - the flames begin

Yes read you it correctly.
Is it possible to create a procedure that will create an index on each column in a table without specifying the column names?
index_all_cols exec ('xxx', 'parallel');
You ask why? There is no reason that I can give you that will quench the flames coming my way. But, finally, it's because (1) I am tired of using excel to generate create statements of the index and (2) I want the speed at the expense of everything else, (3) I do not use a mouse... I know, I would hate first.
Jason
Oracle 10g
... at least I didn't to index every column in every table in my diagram!

Had, it works!

CREATE OR REPLACE PROCEDURE index_all_cols (pTABLENAME IN varchar2)

IS

CURSOR c1 IS SELECT distinct COLUMN_NAME FROM USER_TAB_COLS WHERE TABLE_NAME = pTABLENAME;

BEGIN

FOR c IN c1 LOOP

BEGIN EXECUTE IMMEDIATE 'create index X_ "| c.COLUMN_NAME |' WE ' | pTABLENAME | ' ('| c.COLUMN_NAME |') parallel logging ";

-EXCEPTION WHILE some other THEN NULL;

END;

END LOOP;

COMMIT;

END index_all_cols;

/

... and not even a flame

All parameter memory index for Oracle text indexes

Hi Experts,
I'm on Oracle 11.2.0.3 on Linux and have implemented Oracle Text. I'm not an expert in this area and need help on a question. I created the Oracle text index with the default setting. However, in a white paper of oracle, I read that the default setting is perhaps not good. Excerpt from the white paper by Roger Ford:
URL:http://www.oracle.com/technetwork/database/enterprise-edition/index-maintenance-089308.html
"(Part of this white paper below. )" ...)
Index memory as mentioned above, $I entries cached emptied out on the disk each time the indexing memory is exhausted. The default index to installing memory is a simple 12MB, which is very low. At the time of creating indexes, users can specify up to 50 MB, but it is still quite low.
This would be by a CREATE INDEX, something like statement:
```
 CREATE INDEX myindex ON mytable(mycol) INDEXTYPE IS ctxsys.context PARAMETERS ('index memory 50M');  
```
Allow index of the parameters of memory beyond 50 MB, the CTXSYS user must first of all increase the value of the MAX_INDEX_MEMORY parameter, like this:
```
 begin ctx_adm.set_parameter('max_index_memory', '500M'); end;  
```
The parameter memory must never be high point causes paging, because this will have a serious effect on indexing speed. The smallest of dedicated systems, it is sometimes advantageous to temporarily reduce the amount of memory consumed by the Oracle SGA (for example by reducing DB_CACHE_SIZE and/or SHARED_POOL_SIZE) during the index creation process. Once the index has been created, the size of the SGA can be increased again to improve query performance. & quot;
(End of the excerpt from the white paper)

My question is:
(1) to apply this procedure (ctx_adm.set_parameter) obliged me to log on as user CTXSYS. Is this fair? or can it be avoided and will be based on the application schema? The CTXSYS user is locked by default and I had to unlock it. Is this OK to do it in production?
(2) what value I should use for the max_index_memory there are 500 MB - my SGA is 2 GB in Dev / QA and / 3 GB in the production. Also in the creation of the index which is the value should I set for the parameter memory index - I had left to default, but how do I change now? Should it be 50 MB as shown in the example above?
(3) the white paper also refer to the reconstruction of an index to an interval like once a month: ALTER INDEX DR$ index_name$ X REBUILD online;
-Is this good advice? I would like to ask the experts once before doing this. We are on Oracle 11 g and the white paper was drafted in 2003.
Basically, while I read the book, I'm still not clear on many aspects and need help to understand this.
Thank you
OrauserN

Index entries are built in memory, and then flushed to disk, memory is exhausted. With a setting of high index memory will mean the index entries can be longer and less fragmented, which provides better performance of the query. Conversely, a small memory parameter index will mean emptied the disk pieces are smaller, so queries (especially on common words) will have to do a lot more e/s to extract several pieces of index for the words.

DBMS_STATS: What removed his stats?
Hi all

This is probably a stupid question, but I've searched high and low and have not found an adequate answer to the following: when deleted stats?

I read that his stats table and index deleted whenever truncate you a table, but the (minimal) tests, I did confirm this. "Essays", I mean that I tried to truncate a table and then export and view the statistics of table via DBMS_STATS. EXPORT_TABLE_STATS (and I said 'minimum')... The table statistics seem to have been ignored next truncation.

Table / index stats deleted when you truncate / drop / delete all records from a table? Or they not removed at all?
Hello

statistics on the table are deleted when you call dbms_stats.delete_table_stats or when you drop the table. Why you would think that Oracle would secretly remove its stats table behind your back unless you ask him to? If you have read somewhere you should post a link to that statement - we cannot judge him without the context, but these days there are a lot of stupid things posted on the internet, this could be one of them.

You should trust what you see (your own tests) on what you hear, especially from unknown people on the internet.

Best regards
Nikolai

reverse the primary key index
Hello

When we create a primary key, it automatically creates a unique index on it. He is sort can we give a clause to create a single inverted index on this subject?

We can of course more late the state change an index to Conversely, but how to do it at creation time?

Kind regards!
```
create table test_123(c1 number primary key using index  reverse)
```

issue of the index
Spfile/init.ora file parameter exists to force the CBO to do the path of execution of a given statement, use an index, even if the index scan may seem to be calculated in the form of more expensive?
883532 wrote:
Spfile/init.ora file parameter exists to force the CBO to do the path of execution of a given statement, use an index, even if the index scan may seem to be calculated in the form of more expensive?

It's not a good idea to change any parameter to force using the index, because changing the system can degrade the performance of the entire base.
So you should stick to as much as possible the default values.

However if you want your session with force scan restricted index to table scan the following parameter can be set to make cheap scan index. First parameter i.e. optimizer_index_cost_adj is considered when cacculating table scan vs. index scan and to lower the value would increase the cost of the limited index scan.

OPTIMIZER_INDEX_COST_ADJ (set it low, that is to say less than the 100)
optimizer_mode (all is first_rows)
optimizer_index_caching (increase from 0 to 100)
db_file_multiblock_read_count (decrease of current value)
Use as Index indicator / * + index (table_name, index) * /.
Please note that these setting should never tested on at the level of the system otherwise, there may be a performance impact.

Index of the question - do not include the cost
Hello

I have a table of 112mil lines that I copied to a new tablespace, which worked well
I am so adding indexes to the copied table, but gets enormous costs in plans by trying to make a request using the new index, similar to quirying the original table/index

First of all I tired to change my main index to an another initial tablespace more great extension, and even if I remove all cela and put it in the table space as well as the original index and created the same way, I get the same huge difference.

In most om my system this will cause queries that the CBO does not use the index, and applications get very slow. If I do a simple select statement, and the index is selected, even if the cost is enormous, the moment of the actual query is the same as the original table/query. I can't get the cost of the change index by trying different dbms_stats.gather_index_stats settings

Can someone tell me why this new index comes up with such a huge cost, and what I can do to lower the cost, so that the index gets actually chosen?

Here is some basic information:

It's about Oracle 10 g 2 (10.2.0.4) EA

The simplified create statement for the original and the new index:

CREATE INDEX IDX_POS_DATE ON FMC_POS
("UTC_DATE' DESC, FMC_LOGVES_ID)

CREATE the INDEX IDX_POS_DATE_P2 on FMC_POS_p2
("UTC_DATE' DESC, FMC_LOGVES_ID)

The two indices in dba_indexes:

Source language:
OWNER: VTRACK
INDEX_NAME: IDX_POS_DATE
INDEX_TYPE: BASED ON A NORMAL FUNCTION
TABLE_OWNER: VTRACK
TABLE_NAME: FMC_POS
TABLE_TYPE: TABLE
UNIQUENESS: NO SINGLE
COMPRESSION: DISABLED
PREFIX_LENGTH:
NOM_TABLESPACE: 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: 05/09/2011 23:38:15
DEGREE: 1
INSTANCES: 1
PARTITIONED: NO.
TEMPORARY: N
GENERATED: N
SCHOOL: N
USER_TABLES: 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.
ELIMINATED: NO.

New:
OWNER: VTRACK
INDEX_NAME: IDX_POS_DATE_P2
INDEX_TYPE: BASED ON A NORMAL FUNCTION
TABLE_OWNER: VTRACK
TABLE_NAME: FMC_POS_P2
TABLE_TYPE: TABLE
UNIQUENESS: NO SINGLE
COMPRESSION: DISABLED
PREFIX_LENGTH:
NOM_TABLESPACE: 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
SCHOOL: N
USER_TABLES: 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.
ELIMINATED: NO.

The simple selects and costs:

Original table / index:

Select * from fmc_pos where utc_date > sysdate-10
Plan:
ALL_ROWS SELECT STATEMENT
Cost: 5 bytes: 5,350 cardinality: 50
TABLE ACCESS BY INDEX ROWID VTRACK TABLE 2. FMC_POS
Cost: 5 bytes: 5,350 cardinality: 50
1 INDEX RANGE SCAN INDEX VTRACK. IDX_POS_DATE
Cost: cardinality 4: 1

Original table / index:

Select * from fmc_pos_p2 where utc_date > sysdate-10
Plan:
Plan
ALL_ROWS SELECT STATEMENT
Cost: 3,067 bytes: 2.708.856 cardinality: 25.082
TABLE ACCESS BY INDEX ROWID VTRACK TABLE 2. FMC_POS_P2
Cost: 3,067 bytes: 2.708.856 cardinality: 25.082
1 INDEX RANGE SCAN INDEX VTRACK. IDX_POS_DATE_P2
Cost: cardinality 2.927: 177
>
```
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
```
Look at the stats of the table, not the index statistics. Cardinalities are extremely different.
Specifically, what are the high and low values on the utc_date column.
(The old table statistics are probably days or weeks, obsolete).

Concerning
Jonathan Lewis

At the same time index rebuild...
OK, so I have a question that has puzzled me a bit. I think I understand the theory, but I am not convinced, so looking for 3xp3rt thoughts.

I have the following table with the indexes following:

Departments of instance name table Name Index
AWESOME_DETAIL 20 1 AWESOME_DETAIL_B8

The table itself has a DEGREE of 2 BODIES 1 value.

What is happening is when the following is executed:

ALTER INDEX REBUILD AWESOME_DETAIL_B8.

the table is read in series, despite the index with a DOP of 20. However, when we do the following:

ALTER INDEX REBUILD PARALLEL OF 20 AWESOME_DETAIL_B8

The table is read with the parallelism and the treatment is faster (no surprise on the second part).

When the index is rebuilt with the first statement, the degree of parallel remained unchanged at 20. If we run the second statement, and the index have had a degree of parallelism of the 2, then I expect the degree of parallelism of the index itself will be replaced by 20 (because I've seen this before).

Is this expected behavior? Is the first statement saying Oracle "Hey, this rebuild operation does not have parallel" and the second statement saying: 'Hey, I'm specifying options of storage here, my friend, do in parallel of 20'.

Essentially, the first statement is a pure DDL operation and the second statement is a DDL operation with storage options, where the change? And DDL operations ignore the declaration of principles on the subject, unlike, for example, a SELECT statement.

I tried with a DISPLACEMENT of ALTER TABLE and saw the same behavior: without specifying PARALLEL in my statement, it read the table in series. When I specified PARALLEL, it read the table in parallel.

Mark
When you specify PARALLEL creating / REBUILD / MOVE, the degree is used for the C/R/M. it is always "in place" for all the readings (and will be used in DML If ALTER SESSION ACTIVATE PARALLEL_DML has been paid).
However, the degree of PARALLEL set of the GET on the table / index is not automatically reused for the next RECONSTRUCTION/MOVE (although the degree that has been set remains!)

Is the first statement saying Oracle "Hey, this rebuild operation does not have parallel" and the second statement saying: 'Hey, I'm specifying options of storage here, my friend, do in parallel of 20'.

Yes, precisely.

See http://download.oracle.com/docs/cd/E11882_01/server.112/e17118/clauses006.htm#g1058315

NOPARALLEL
Specify NOPARALLEL for serial execution. It is the default value.

Hemant K Collette

Index on the primary table becomes UNUSABLE after Exchange of partition
Hello!

I am the scene changes to partition and somehow, I see that the partition that I Exchange eventually becomes "UNUSABLE".

The steps that I'm following:

1. creating the temporary table:

CREATE TABLE TEMP_TKTHEADER
AS SELECT * FROM T3TKTHEADER
WHERE 1 = 2

2. replacement of the partition

ALTER TABLE T3TKTHEADER
PART08Q1Q2 PARTITION EXCHANGE
WITH TABLE TEMP_TKTHEADER

After the Exchange is carried out and I ask the stats of the index on the primary table (T3TKTHEADER as in this case):

INDEX_NAME NOM_PARTITION STATUS
----------------------------------------------------------------------------------------------
XTKTHDR1 PART08Q1Q2 UNUSABLE
XTKTHDR10 PART08Q1Q2 UNUSABLE
XTKTHDR11 PART08Q1Q2 UNUSABLE
XTKTHDR12 PART08Q1Q2 UNUSABLE
XTKTHDR13 PART08Q1Q2 UNUSABLE
XTKTHDR14 PART08Q1Q2 UNUSABLE
XTKTHDR2 PART08Q1Q2 UNUSABLE
XTKTHDR3 PART08Q1Q2 UNUSABLE
XTKTHDR4 PART08Q1Q2 UNUSABLE
XTKTHDR5 PART08Q1Q2 UNUSABLE
XTKTHDR6 PART08Q1Q2 UNUSABLE
XTKTHDR7 PART08Q1Q2 UNUSABLE
XTKTHDR8 PART08Q1Q2 UNUSABLE
XTKTHDR9 PART08Q1Q2 UNUSABLE

This is normal behavior!
Is not swap Partition just supposed to change the pointer to the partition of the temporary table data and leave the rest of the table intact!

Thank you
AB007
Dear AB007,

Please see subpart of swap partition. I assumed that the version of your database is GR 11, 2;

http://download.Oracle.com/docs/CD/E11882_01/server.112/e10592/statements_3001.htm#BABHHAHF
```
INCLUDING | EXCLUDING INDEXES Specify INCLUDING INDEXES  if you want local index partitions or subpartitions to be exchanged with the corresponding table index (for a nonpartitioned table) or local indexes (for a hash-partitioned table).
Specify EXCLUDING INDEXES  if you want all index partitions or subpartitions corresponding to the partition and all the regular indexes and index partitions on the exchanged table to be marked UNUSABLE.
```
Hope that helps.

Ogan

Stats gathering on index.

Similar Questions

Maybe you are looking for