DML on global partition

Similar Questions

• Global partitioned index hash

  Is it possible to create an index of global partitioned hash on the columns of the primary key of a table that is not partitioned itself?
  If a table has a PK constraint there an index generated automatically on the PK columns.
  Y at - it a syntax to make the overall index partitioned hash when creating the constraint of PK,.
  or syntax to MODIFY the indexes after the creation of the constraint?

  When you add a Pk to a table, you can choose a place already in the index. Something like

  alter table t1 add constraint T_PK primary key (col1) using index T_IDX;
  

  Create the partitioned index as you like with the same columns as the primary key and use the foregoing.

• DML using the partition.

  Hello
  
  10.2.0.1.0 Oracle
  
  Is it possible to have quickly DML operation using partitions. as the update, insert, delete.
  
  
  as we do in select * partition of course (2001_pg_courses);
  
  
  kindly help.

  You don't need to explicitly select a partition.

  A partition table has 'rules' about what data go where. For example, a range may partition table have a 'rule' for a partition by day - all the lines for a day (according to table column invoice_date for example), is in a single partition. Similarly, a partitioned table list will also have a "rule", stating that the lines go in which partition.

  You can explicitly reference the score via a SQL statement as follows to find all invoices for a customer:

  select * from invoices partition (day_20110101) where customer_id = :1;
  

  This SQL is however not very shareable under the partition name is hardcoded. If you want to find the Bills for another day, a new brand SQL statement is necessary with hardcoded score of the day in the SQL.

  Also consider what it does to the application. User PL/SQL code can no longer use the SQL statement as is - like it needs a new SQL statement to use depending on the day. So dynamic SQL must be used - an approach complex and often creates a security risk because of risk of SQL injection.

  Or you can implicitly reference the partition using this 'rule' as part of the predicate. For example

  select * from invoices where invoice_date = :0 and customer_id = :1;
  

  The CBO will see invoice_date is used and he will know that it is used as the "rule of the partition. The CBO can now decide which or the partitions to use.

  The SQL that is created is shareable. We will use the same SQL in the shared pool of Oracle over and over again for customers and different days - we are not a completely new SQL for a day of different invoice.

  The PL/SQL user can now use the SQL like it - no need to use SQL dynamically and inserting the name of partition in SQL. No threat of SQL injection.

  Best of all - the PL/SQL Developer didn't need to worry how partition works, how it is applied, that partition names and so on. Standard SQL is used - as it would have been the case if the invoice table is not partitioned, or a cluster or an index organized table or anything else. The CBO has the intelligence to translate SQL into an optimal execution plan that is the most appropriate for the physical implementation table, available indexes and so on.

  The developer must only be concerned about the logic of its SQL statement - and not by the complexity of the physical implementation of the database.

• with hash index global partition

  Hello

  I use SQL DEVELOPER DATA MODELER Version 4.0.0.833.

  In the database have an index with global hash partitions (11 g Enterprise Edition Release 11.2.0.2.0)

  When I sincronize with the database and the search for differences I find this tablespace in metadata comes from DDBB is null.

  Thank you for all.

  David

  Hi David,

  It seems that the storage space for the partitions of a partitioned index global hash is not currently imported from the database.

  I connected an enhancement request to support this feature.

  David

• Global partitioned index shows State N/A sqldeveloper

  Hi again,
  
  I tried to create a global index divided by 4 hash partitions to be used as the primary key.
  
  I think I understand the syntax for creating an index of global hash (using 4 partitions) that is used by the primary key constraint.
  Here's my response:
  
  ALTER table vehicle_data
  Add the constraint of KEY PRIMARY C_PK_ID
  (
  ID
  )
  USING INDEX
  HASH PARTITION (LWVD_ID)
  4. THE PARTITIONS
  ENABLE;
  
  What I don't understand is this:
  When I take the sqldeveloper, go to the table and select the tab 'index' index status is indicated by n/a. When I create the index without partitioning it shows valid.
  What is the problem that I forgot?
  
  Thanks again,
  Andreas

  You forgot that it is partitioned.

  If you look in ALL_IND_PARTITIONS for the State.

• Partitioned global index on partitioned table range, but the index partition does not work

  Hello:

  I was creating an index partitioned on table partitioned and partitioned index does not work.

  create table table_range)

  CUST_FIRST_NAME VARCHAR2 (20).

  CUST_GENDER CHAR (1),

  CUST_CITY VARCHAR2 (30),

  COUNTRY_ISO_CODE CHAR (2),

  COUNTRY_NAME VARCHAR2 (40),

  COUNTRY_SUBREGION VARCHAR2 (30),

  PROD_ID NUMBER NOT NULL,

  CUST_ID NUMBER NOT NULL,

  TIME_ID DATE NOT NULL,

  CHANNEL_ID NUMBER NOT NULL,

  PROMO_ID NUMBER OF NON-NULL,

  QUANTITY_SOLD NUMBER (10.2) NOT NULL,

  AMOUNT_SOLD NUMBER (10.2) NOT NULL

  )

  partition by (range (time_id)

  lower partition p1 values (u01 tablespace to_date('2001/01/01','YYYY/MM/DD')),

  lower partition (to_date('2002/01/01','YYYY/MM/DD')) tablespace u02 p2 values

  );

  create index ind_table_range on table2 (prod_id)

  () global partition range (prod_id)

  values less than (100) partition p1,

  lower partition p2 values (maxvalue)

  );

  SQL > select TABLE_NAME, SUBPARTITION_COUNT, HIGH_VALUE, nom_partition NUM_ROWS of user_tab_partitions;

  TABLE_NAME NOM_PARTITION SUBPARTITION_COUNT HIGH_VALUE NUM_ROWS

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

  TABLE_RANGE P2 0 TO_DATE (' 2002-01-01 00:00:00 ',' SYYYY-MM-DD HH24:MI:SS ',' NLS_CALENDAR = GREGORIA 259418)

  TABLE_RANGE P1 0 TO_DATE (' 2001-01-01 00:00:00 ',' SYYYY-MM-DD HH24:MI:SS ',' NLS_CALENDAR = GREGORIA 659425)

  SQL > select INDEX_NAME, NUM_ROWS nom_partition, HIGH_VALUE user_ind_partitions;

  INDEX_NAME NOM_PARTITION HIGH_VALUE NUM_ROWS

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

  P1 IND_TABLE_RANGE 100 479520

  IND_TABLE_RANGE P2 MAXVALUE 439323

  SQL > EXECUTE DBMS_STATS. GATHER_TABLE_STATS (USER, 'TABLE_RANGE');

  SQL > EXECUTE DBMS_STATS. GATHER_TABLE_STATS (USER, 'TABLE_RANGE', GRANULARITY = > 'PARTITION');

  SQL > EXECUTE DBMS_STATS. GATHER_INDEX_STATS (USER, 'IND_TABLE_RANGE');

  SQL > EXECUTE DBMS_STATS. GATHER_INDEX_STATS (USER, 'IND_TABLE_RANGE', GRANULARITY = > 'PARTITION');

  SQL > set autotrace traceonly

  SQL > alter shared_pool RAS system;

  SQL > changes the system built-in buffer_cache;

  SQL > select * from table_range

  where prod_id = 127;

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

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

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

  |   0 | SELECT STATEMENT |             | 16469 |  1334K |  3579 (1) | 00:00:43 |       |       |

  |   1.  RANGE OF PARTITION ALL THE |             | 16469 |  1334K |  3579 (1) | 00:00:43 |     1.     2.

  |*  2 |   TABLE ACCESS FULL | TABLE_RANGE | 16469 |  1334K |  3579 (1) | 00:00:43 |     1.     2.

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

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

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

  2 - filter ("PROD_ID" = 127)

  Statistics

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

  320 recursive calls

  2 db block Gets

  13352 consistent gets

  11820 physical reads

  0 redo size

  855198 bytes sent via SQL * Net to client

  12135 bytes received via SQL * Net from client

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

  61 sorts (memory)

  0 sorts (disk)

  15984 rows processed

  Once the sentence you say ' does not ' and then you go to paste plans that seem to show that it "works".

  What gives?

  In fact, if you look at the plans - think Oracle you have 16 k rows in the table and he'll be back k 12 rows for your select statement. In this case, Oracle is picking up the right plan - full scan 16 ranks of k is a lot less work to digitize the index lines k 12 followed by the research of rank k 12 rowid.

• Global and local index with respect to table partitioned

  Hello
  I am very confused about local and global index in a partitioned table.
  In addition, local index can be partitioned and unpartitioned.
  In addition, what is the difference between global partitioned and unpartitioned
  the index?
  
  As far as I know,
  If there is local index then there will be as many partitions as the partition table
  and local parition will index contains the index of only the lines of their corresponding scores.
  In addition, the local index maintananence is easier because drop us or create a partition, only index corresponding partition is affected then that in the case of the overall index,
  If we create a new partition of the table, to rebuild the global index.
  Am I wrong?
  
  Concerning

  Hello

  This means that when you add/drop/split/merge table any partition (maintaiance) lying below, its corresponding partition in index is automatically added/deleted/split/merged. Oracle takes care of it internally without user intervention.

  Concerning
  Anurag

• Local/Global index for OLTP

  In our application (OLTP), we have a rule on
  
  * "" on all the partitioned tables, we need to have just partitioned LOCAL index "... *"
  I think that this rule is valid, because when we had GLOBAL index partitioned on the table when concurrent transactions
  was going on, we got below error:
  ORA - 00054:resource busy and...
  We get this error when rebuild us all indexes not valid...
  
  When we changed all the GLOBAL partitioned index at the LOCAL level... we get this error...
  
  We use MEV for cloud computing (i.e. we have several tenants and a partition for each tenant)
  
  
  My doubt is, is the rule as mentioned above may be still valid, because it is at odds with what is mentioned in the Oracle
  Documentation (the concepts guide)...
  http://docs.Oracle.com/CD/B19306_01/server.102/b14220/partconc.htm#i461446
  
  '' In general, you should use an index for OLTP applications and local storage of data or applications of DSS ''
  
  We use oracle 10 g 2...

  In our case, research www.lesormes.com will not create several partitions, only one partition (we have a partition for each tenant).

  Local is even better for you.

  Thanks for suggesting to rebuild online (for global)... I'll try with that... .but he would have any problem of performance relative to the index LOCAL...

  I don't think abnd so there shouldn't be any performance impact, rather it improves performance in locaking not all the table exclusively for the index creaiton.

  NY suggestion/idea why Oracle recommends partitioned Global index for OLTP?

  Because normally we have much aprtition of drop/merger/split partition of things in OLTP type (these operations are important in DSS normally loading data).

  any suggestion/idea why Oracle recommends partitioned Global index for OLTP?

  Because they are the fastest to access a record of a table and OLTP, response time is what counts. If you compare your reports OLTP or transactions, to spawn multiple partitions (a small percentage could access only a single partition and rules are made for the majority of cases, not for the small number of cases) and global index are better in this scenario.
  at MAS, you always have a huge data and as partition operation may stop your work until the index is rebuilt (which can take several hours for the huge data) where oracle is recommended to have a local indexing policy.

  Salman

• How do I know it's global index or local index?

  Hi all
  
  How will I know if it's overall index or local index?
  
  Thank you!
  
  Dan.

  Salvation;

  Check defination of index? Overall index below has defination

  CREATE INDEX month_ix ON sales (sales_month)
  GLOBAL PARTITION BY RANGE (sales_month)

  For more information, please visit:

  http://download.Oracle.com/docs/CD/B13789_01/server.101/b10739/partiti.htm

  Respect of
  HELIOS

• Bad generation of DDL for indexes primary key partitioned - lost partitions

  Hello
  
  In our design of the database, we want to divide some tables and their indexes. The partition type is hash indexes must be local, also divided No problem affecting storage of the table partitions. Also no aucun probleme problem with the index partitions, not included the primary key.
  
  Our problem appears in the generation of DDL: partitions of tables and indexes are generated fine except the primary partitions it shows key - phrase-'alter table' primary key as if it was not partitioned.
  
  Apparently indexes primary keys must be generated as the other indices, is it not?
  
  Thanks in advance,
  
  Bernat Fabregat
  
  Published by: Berni 11/29/2010 12:37

  Hello Bernat,

  for local partitioning, you need to create indexes separated on column PK (if you do not already). Set partitioning for this index, and then in the dialog box for the primary key in the physical model:
  (1) in the 'Général' tab, clause "with the help of the index' - select 'by the name of the index.
  (2) in tab 'using Index' - 'Existing Index' drop-down list box - select defined index.

  Global partitioning can be created directly on the primary key in the physical model.

  Philippe

• Partitioned index not used in the query

  Hello
  
  Oracle 10.2.0.1
  Windows xp
  
  I'm confused why oracle did not use a partitioned below index:

  SQL> set line 200;
  SQL> SET AUTOTRACE TRACEONLY EXPLAIN;
  SQL> select * from MYTABLE where PROD like 'SOAP%';
  
  Execution Plan
  ----------------------------------------------------------
  Plan hash value: 2899783245
  
  -------------------------------------------------------------------------------------------------------
  | Id  | Operation              | Name         | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
  -------------------------------------------------------------------------------------------------------
  |   0 | SELECT STATEMENT       |              |  1852 |   115K|   992   (3)| 00:00:12 |       |       |
  |   1 |  PARTITION RANGE SINGLE|              |  1852 |   115K|   992   (3)| 00:00:12 |     8 |     8 |
  |*  2 |   TABLE ACCESS FULL    |      MYTABLE |  1852 |   115K|   992   (3)| 00:00:12 |     8 |     8 |
  -------------------------------------------------------------------------------------------------------
  
  Predicate Information (identified by operation id):
  ---------------------------------------------------
  
     2 - filter("PROD" LIKE 'SOAP%')
  
  SQL> desc MYTABLE;
   Name                                                                                  Null?    Type
   ------------------------------------------------------------------------------------- -------- -----------
   PROD_ID                                                                               NOT NULL VARCHAR2(7)
   PROD                                                                                  NOT NULL VARCHAR2(30)
   AREA                                                                                  NOT NULL VARCHAR2(30)
   SUB_AREA                                                                              NOT NULL VARCHAR2(30)
  
  SQL>

  But when I said something different; then it accesses the indexes:
  

  SQL> select count(*) from MYTABLE where PROD like 'SOAP%';
  
  Execution Plan
  ----------------------------------------------------------
  Plan hash value: 1393798969
  
  ----------------------------------------------------------------------------------------------------
  | Id  | Operation               | Name     | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
  ----------------------------------------------------------------------------------------------------
  |   0 | SELECT STATEMENT        |          |     1 |    16 |    18   (0)| 00:00:01 |       |       |
  |   1 |  SORT AGGREGATE         |          |     1 |    16 |            |          |       |       |
  |   2 |   PARTITION RANGE SINGLE|          |  1852 | 29632 |    18   (0)| 00:00:01 |     8 |     8 |
  |*  3 |    INDEX RANGE SCAN     | PROD_IDX |  1852 | 29632 |    18   (0)| 00:00:01 |     8 |     8 |
  ---------------------------------------------------------------------------------------------------
  
  Predicate Information (identified by operation id):
  ---------------------------------------------------
  
     3 - access("PROD" LIKE 'SOAP%')
         filter("PROD" LIKE 'SOAP%')
  
  SQL>

  How to create prod_idx:

  SQL> ED
  Wrote file afiedt.buf
  
    1  create index prod_idx ON mytable(prod)
    2  global partition by range(prod)
    3  (partition prod1 values less than ('A'),
    4  partition prod2 values less than ('B'),
    5  partition prod3 values less than ('C'),
    6  partition prod4 values less than ('D'),
    7  partition prod5 values less than ('E'),
    8  partition prod6 values less than ('F'),
    9  partition prod7 values less than ('G'),
   10  partition prod8 values less than ('H'),
   11  partition prod9 values less than ('I'),
   12  partition prod10 values less than ('J'),
   13  partition prod11 values less than ('K'),
   14  partition prod12 values less than ('L'),
   15  partition prod13 values less than ('M'),
   16  partition prod14 values less than ('N'),
   17  partition prod15 values less than ('O'),
   18  partition prod16 values less than ('P'),
   19  partition prod17 values less than ('Q'),
   20  partition prod18 values less than ('R'),
   21  partition prod19 values less than ('S'),
   22  partition prod20 values less than ('T'),
   23  partition prod21 values less than ('U'),
   24  partition prod22 values less than ('V'),
   25  partition prod23 values less than ('W'),
   26  partition prod24 values less than ('X'),
   27  partition prod25 values less than ('Y'),
   28  partition prod26 values less than ('Z'),
   29* partition prod27 values less than (MAXVALUE))
  SQL> /
  
  Index created.

  SQL> select count(*) from MYTABLE;
  
  Execution Plan
  ----------------------------------------------------------
  Plan hash value: 3323402158
  
  --------------------------------------------------------------------------------------------------------------
  | Id  | Operation                      | Name                | Rows  | Cost (%CPU)| Time     | Pstart| Pstop |
  --------------------------------------------------------------------------------------------------------------
  |   0 | SELECT STATEMENT               |                     |     1 |   311   (0)| 00:00:04 |       |       |
  |   1 |  SORT AGGREGATE                |                     |     1 |            |          |       |       |
  |   2 |   PARTITION RANGE ALL          |                     |    14M|   311   (0)| 00:00:04 |     1 |    27 |
  |   3 |    BITMAP CONVERSION COUNT     |                     |    14M|   311   (0)| 00:00:04 |       |       |
  |   4 |     BITMAP INDEX FAST FULL SCAN| MS_IDX_MYTABLE      |       |            |          |     1 |    27 |
  --------------------------------------------------------------------------------------------------------------

  Table is to have 14693792 lines.
  
  Why this is the case, please guide me to understand. Thank you.
  
  Published by: user12050217 on July 29, 2010 23:37
  
  Published by: user12050217 on July 29, 2010 23:38
  

• creating indexes on partitioned tables...

  Hi all
  I use 11g. creates a table with partition on transaction_dt. Now I have to create index based on the combination of the column below.
  can anyone suggest the best method to create the partioned indexes based on the underside of the columns?
  
  enjoyed the great suggestions...
  

  CREATE INDEX TB_PRCHS_SALE_TRANS_BASE_IDX1 ON TB_PRCHS_SALE_TRANS_BASE
  (TRANSACTION_DT, VENDOR_ACCT_NBR, VENDOR_SECURITY_NBR);
  
  
  CREATE INDEX TB_PRCHS_SALE_TRANS_BASE_IDX2 ON TB_PRCHS_SALE_TRANS_BASE
  (TRANSACTION_DT, ING_ACCT_NBR, ING_SECURITY_NBR);
  
  
  CREATE INDEX TB_PRCHS_SALE_TRANS_BASE_IDX3 ON TB_PRCHS_SALE_TRANS_BASE
  (TRADE_DT, SETTLEMENT_DT, VENDOR_ACCT_NBR, VENDOR_SECURITY_NBR);
  
  
  CREATE UNIQUE INDEX TB_PRCHS_SALE_TRANS_BASE_PK ON TB_PRCHS_SALE_TRANS_BASE
  (TRANS_CONTROL_ID);
  
  
  CREATE INDEX TB_PRCHS_SALE_TRANS_INDX3 ON TB_PRCHS_SALE_TRANS_BASE
  (OLD_TRANSACTION_ID);
  
  
  ALTER TABLE TB_PRCHS_SALE_TRANS_BASE ADD (
    CONSTRAINT TB_PRCHS_SALE_TRANS_BASE_PK
   PRIMARY KEY
   (TRANS_CONTROL_ID));
  
  
  Table
  ====================
  
  CREATE TABLE TB_PRCHS_SALE_TRANS_BASE
  (
    TRANSACTION_DT              DATE              NOT NULL,
    TRANS_CONTROL_ID            NUMBER            NOT NULL,
    VENDOR_CD                   CHAR(3 BYTE)      NOT NULL,
    ING_ACCT_NBR                NUMBER(10)        NOT NULL,
    ING_ACCT_TYPE_CD            CHAR(1 BYTE)      NOT NULL,
    ING_SECURITY_NBR            NUMBER(10)        NOT NULL,
    VENDOR_ACCT_NBR             VARCHAR2(10 BYTE) NOT NULL,
    VENDOR_ACCT_TYPE_CD         CHAR(1 BYTE)      NOT NULL,
    VENDOR_ACCT_CHCK_CD         CHAR(1 BYTE)      NOT NULL,
    VENDOR_SECURITY_NBR         VARCHAR2(10 BYTE),
    BUY_SELL_CD                 CHAR(1 BYTE)      NOT NULL,
    TRADE_DT                    DATE,
    SETTLEMENT_DT               DATE,
    CREATE_USER                 VARCHAR2(50 BYTE),
    UPDATE_TS                   DATE,
    UPDATE_USER                 VARCHAR2(50 BYTE),
    OLD_TRANSACTION_ID          NUMBER(10)
  partition by range (TRANSACTION_DT)
  interval (numtoyminterval(1,'YEAR'))
  (
     partition p001 values less than (date '2002-01-01'),
     partition p002 values less than (date '2003-01-01'),
     partition p003 values less than (date '2004-01-01'),
     partition p004 values less than (date '2005-01-01'),
     partition p005 values less than (date '2006-01-01'),
     partition p006 values less than (date '2007-01-01'),
     partition p007 values less than (date '2008-01-01'),
     partition p008 values less than (date '2009-01-01'),
     partition p009 values less than (date '2010-01-01'),
     partition p010 values less than (date '2011-01-01'),
    );
   

  CREATE INDEX TB_PRCHS_SALE_TRANS_INDX3 ON TB_PRCHS_SALE_TRANS_BASE
  (OLD_TRANSACTION_ID)
  LOCAL
  (
  partition p001,
  partition p002,
  partition p003,
  partition p004,
  partition p005,
  partition p006,
  partition p007,
  partition p008,
  partition p009,
  partition p010
  )
  /
  -- Since PK column set does not include partitioning colums
  -- you can't create LOCAL partitioned index.
  ALTER TABLE TB_PRCHS_SALE_TRANS_BASE ADD
   CONSTRAINT TB_PRCHS_SALE_TRANS_BASE_PK
  PRIMARY KEY
  (TRANS_CONTROL_ID)
  USING INDEX
  GLOBAL
  (
  partition p001,
  partition p002,
  partition p003,
  partition p004,
  partition p005,
  partition p006,
  partition p007,
  partition p008,
  partition p009,
  partition p010
  )
  /
  

  SY.

• Table partition and no partition indexes

  Hello
  
  I have the partition table that contains about 1 ml recods and he have daily score.
  This partition table have only a unique index that is a partition No.
  
  CREATE UNIQUE INDEX xxxxxx WE yyyyyy
  (ITEM_GUID, IMAGE_SIDE)
  LOGGING
  TABLESPACE zzzzzz
  PCTFREE 10
  INITRANS 2
  MAXTRANS 255
  STORAGE)
  INITIAL 170M
  ACCORDING TO 1 M
  MINEXTENTS 1
  MAXEXTENTS 2147483645
  PCTINCREASE 0
  DEFAULT USER_TABLES
  )
  NOPARALLEL;
  
  I drop very first partition of
  
  Fall of ALTER TABLE wwww.yyyyy SCORE PT_20080706;
  
  But this isn't my unique INVALID index.
  
  Is it normal to have a VALID unique index after the fall of any partition?
  
  Do I have to rebuild a unique index again?
  
  DB: oracle 10.2.0.3
  platform: solaris
  
  Thanks in advance

  According to the Oracle doc, if you drop the bulkhead with an overall index,.

  All index global, or all partitions of global partitioned indexes are marked UNUSABLE unless one of the following are true:

  You specify the UPDATE INDEX (cannot be specified for tables organized by index. Use GLOBAL updating INDEXES.)

  The dropped partition or its subparts are empty

  more info here
  http://download.Oracle.com/docs/CD/B19306_01/server.102/b14231/partiti.htm#sthref2751

  Check ALL_PART_INDEXES and ALL_INDEXES to check the State of your indexes.

• the question of the overall index was updated

  I have a partitioned table and the local partitioned indexes in 9i. In the past, when I add a new partition, partitioned indexes have become "unusable" so I have to rebuild the index to the "exploitable": State
  
  ALTER INDEX REBUILD PARTITION myindex TYPE my_partition nologging;
  
  I just found out that when you use the clause to UPDATE GLOBAL INDEXES, there is no need to rebuild the local index in the underlying table. It seems that updating the GLOBAL INDEX also update local index to the status of "exploitable".
  
  create tablespace you see
  
  ALTER TABLE my_table SPLIT PARTITION of VALUES 'TYPE_DEFAULT' ('new') INTO (PARTITION "TYPE_NEW" TABLESPACE "you see", "TYPE_DEFAULT" PARTITION) UPDATE GLOBAL INDEXES;
  
  I wonder if UPDATE GLOBAL INDEXES also update local indexes as it appears in this case. I thought that the UPDATE GLOBAL INDEXES only updated global index.
  
  Published by: user7435395 on March 8, 2013 14:33
  
  Published by: user7435395 on March 8, 2013 14:36
  
  Published by: user7435395 on March 8, 2013 15:15

  >
  I just found out that when you use the clause to UPDATE GLOBAL INDEXES, there is no need to rebuild the local index in the underlying table. It seems that updating the GLOBAL INDEX also update local index to the status of "exploitable".
  >
  Interesting! Can you post the DDL that you use for the table and index, so we can try to reproduce it?

  This seems to contradict what said documentation, but that would not be something new.

  See "Split of Partitions" in the Guide DBA 9i
  http://docs.Oracle.com/CD/B10501_01/server.920/a96521/partiti.htm#6736
  >
  Behavior of the index

  Regular (TAS)
  Oracle UNUSABLE brand new partitions (there are two) in each local index.

  Unless you specify GLOBAL INDEXES to UPDATE, all index global, or all partitions of global partitioned indexes are marked UNUSABLE and must be rebuilt
  >
  Also you not "add" a partition you split one and creates two new partitions, which both can have data. These two partitions of the local index must be rebuilt.

  When you "add" a partition it lacks all the data so there is not need to rebuild the local index for this 'new' partition.

• ORA - 02158 invalid index option create

  I create two indexes on a table. the following two welcomes:

  CREATE INDEX C_DATA.PDD_INDEX_2 ON  "C_DATA".PDD(SYS_ID, REPORT_ID, OUTPUT_TEMPLATE_ID, SECTION_ID, DP_ID, ROW_ID) LOCAL STORE IN ( C_DATA_IND_1,C_DATA_IND_2,C_DATA_IND_4, C_DATA_IND_5,C_DATA_IND_3);
  
  
  CREATE UNIQUE INDEX C_DATA.PDATA_ID_PK ON "C_DATA".PDD(PDATA_ID) GLOBAL STORE IN ( C_DATA_IND_1,C_DATA_IND_2,C_DATA_IND_4,C_DATA_IND_3);

  1 index was created successfully, but then a returned error ORA-02158 invalid create index option.
  
  I only am not able to understand why I am facing this error. Kindly help.
  Database version: 11.2.0.2

  For global partitioned index, you must specify the partition type.