UNUSED EXISTING INDEXES / Index usage

We are using CRM 2007, Netweaver 7.0 with DB2 UDB v9.1 fixpack4 on AIX.
Is there a way to find out  UNUSED EXISTING INDEXES for tables ? We have close 12 indexes on the crmd_order_index table and want to find out if some of them can safely deleted. Is there any way to monitor index usage in SAP ? Is there any toold to aid this ?
Pls advise.
thank you
regards
Laxmi

Laxmi,
I am not aware of any such tools with DB2 9.1.  However, "last_used" columns are being added to various catalog tables in DB2 9.7.  Below is an excerpt from a slide presented in the  TLU2008A "DB2 LUW V9.7 Cobra u2013 Storage is Charmed" session.
The last reference time of an object will now be maintained in the LASTUSED column of
the corresponding catalog table for the object
u2013 SYSCAT.INDEXES.LASTUSED (prior to V9.7 db2pd u2013tcbstats indexes)
u2013 SYSCAT.TABLES.LASTUSED
u2013 SYSCAT.DATAPARTITIONS.LASTUSED
u2013 SYSCAT.PACKAGE.LASTUSED
The LASTUSED column is of type DATE (default value is 1/1/0001)
Use Cases:
u2013 Detach table partitions that are no longer actively used (esp. when not partitioned by time)
u2013 Determine inactive or infrequently used indexes
u2013 Easily identify tables which are no longer in use
u2013 Get rid of unused packages
The presenter said the code will begin populating these columns in an upcoming fixpack.
Regards,
Rick

Similar Messages

  • 1 of the field in existing secondary index

    hi,
    if in the existing secondary index, among the field in the index, for example field1, field2, field3, field4;
    if field3 is the only field that i need to define in the where clause in my program, do i need to create a new secondary index?
    thanks

    Are you executing your select clause with WHERE clause on only field 3?
    If so adding your field on an existing index with 3 fields already, will not solve your purpose, if it is performance that you are looking for. You need to create a new index, if you use the select clause with only field3, in any case
    That said, if you would use all field1, field2, field3, field4 in your query and the index does have only field1, field2, field4 as of now, still you should not insert field3 in the middles as all other queries dependent on previous index will now become partial key queries.
    So I would suggest you to go with a new index, if the SELECT query that you are talking about is performance critical.

  • Using UNUSABLE on Unique Index gives "initially in unusable state" error

    I am doing the following:
    1. Truncate table
    2 Alter PK Index Disable
    2. Alter Unique Index Unusable
    3. Insert /*+ APPEND NOLOGGING*/ into my table
    My problem is, I get an "ORA-26026: unique index ... initially in unusable state" error when I try to do the Insert. If I make the Unique index non-unique it isn't a problem. If I drop the index and recreate it its not a problem - so uniqueness doesn't appear to be the issue. Can you not use UNUSABLE with a Unique index, I couldn't find any reference to this in the 10g docs.
    I am using 10.1.0.4.
    Thanks
    Richard

    26026, 0000, "unique index %s.%s initially in unusable state"
    //* Cause: A unique index is in IU state (a unique index cannot have
    //* index maintenance skipped via SKIP_UNUSABLE_INDEXES).
    //* Action: Either rebuild the index or index partition, or use
    //* SKIP_INDEX_MAINTENANCE if the client is SQL*Loader.

  • InDesign Index - Indexing a book and having page links in PDF

    I am creating an index on a book made up from 30 indesign documents.  When I export the book to a PDF I want to be able to click on the index page numbers and have it go to that page.  The problem is that I can only get the index links in a PDF to work on the document that I have the index.  If I have my index in the last document and I create a index entry to the second page it creates it fine but once exported into a PDF the link doesn't work.  In CS4 I created small books like this with no problems.
    Any sugestions?
    Thanks,
    Josh

    Joshmon2003 wrote:
    Peter,
    The links that work look like this:
    The links that are not working look like this:
    for some reason indesign CS5 created the link differently when it is in a different document but in the same book.  Any ideas on how to fix this??  In CS4 this worked fine.
    Thanks,
    Josh
    Hi, Josh:
    You didn't mention the Tagged PDF and Buttons and Media settings. Not sure if they make a difference, but it helps to know as much as possible, sometimes.
    The failing link is looking for a PDF file on the H: drive, while the successful link doesn't specify a directory path. I haven't done much specifically in InDesign with exported multi-file books. However, from my Acrobat experience, I can see that the individual files of your InDesign multi-file book are being converted to individual PDF files, and their original paths are retained in the exported links.
    I don't know if the link paths are different if you export the book to PDF by deselecting all the individual InDesign book files by clicking in the blank area below the last title in the Book panel, and choose Export Book to PDF from the Book panel menu, or if you select all the titles and choose Export Selected Documents to PDF.
    As far as I know, there's no way to create a single PDF from a multi-file InDesign book document, though it's likely that the links would work because no pathname would be involved, as with your successful link.
    Are all the individual book files in a single folder (a single path), or scattered across multiple folders (multiple paths)?
    If you want your PDF book to be a collection of individual files, on thing you can try is to use Package Book for Print from the Book panel's menu. This copies everything that comprises all the individual book files, and their linked content, into one folder, with a single pathname. Exporting the book file created by the package should make all the link paths the same, so there's a good chance you'll get what you want.
    When you say that this worked in an earlier InDesign release, do you mean that the same set of project files worked in the past and are failing now in CS5? Or, is your current project a new one, with assets in multiple folders? Were all the component files and the linked stuff in your old successful project, all in one folder? 
    HTH
    Regards,
    Peter
    Peter Gold
    KnowHow ProServices

  • Exclude/Filter Filename from Index (Indexing SAP Offline Help)

    Hi All,
    I managed it to index the SAP Documentation DVD (aka SAP Library, aka SAP Help).
    Ok, now I can search for keywords. Now TREX searched all files; also the "frameset.htm" files.
    Basically only the "content.htm" files are important to the users... since frameset files dont't deliver any content "No document excerpt available".
    I think now you understand my issue: Is it possible only to index the "content.htm" files and to exclude/filter the "frameset.htm" files?
    Thanks in advance for any detailed hints and how-to's...
    Philipp

    Hi Philipp,
    Within your index, you have defined some (probable: standard) crawler. You can copy the standard crawler, use this copy instead, and activate some resource filter on it, scope filtering using URL Regular Expression.
    See http://help.sap.com/saphelp_nw2004s/helpdata/en/46/5d5040b48a6913e10000000a1550b0/frameset.htm for details.
    Hope it helps
    Detlev

  • Existing OracleAS licences usage

    Hello,
    We have OracleAS licenses (aquired before the acquisition of BEA) and we want to start new projects and migrate existing project in JDK 1.6
    -- Should we start our new projects with OracleWeblogic10.3 or OracleAS 11g?
    -- Should we migrate our existing projects with OracleWeblogic 10.3 or OracleAS 11g?
    Thank you for your answers
    Tatek

    Hi,
    That totally depends on the type of applications you have and the requirements of the applications.
    If the applications are enterprise type, service oriented and Web 2.0 oriented, High usage, transactional, you should go with Weblogic.
    Thanks
    Vishnu

  • Vlv indexing - indexing

    Hi All,
    I have Directory server 6.0. I want to do vlv indexing without restarting Directory Server. How should I do this? Can I do it by using DS console?
    I also wanted to do reindexing. I saw this option is available under ‘suffix’ tab. How safe is it to run indexing from DS console? Do I need a restart after reindexing?
    Thanks and Regards,
    -Shashank

    Cannot create vlv indices without stopping the instance. Doing it via dscc should give the same results as well. Reindexing (not vlv) can be done online and DS does not need to be restarted afterward.

  • Indexing Indexing Indexing!

    I just installed Leopard and it's indexing which is locking up my computer, how do I disable this? I have to shut down my computer manually because indexing is freezing up everything.

    I found my answer on this website: http://web.reed.edu/cis/help/disablespotlight.html
    According to this website, it says it's a bad idea to have spotlight indexing your backup drive.

  • How can I monitoring the usage of an index in oracle 8i

    Dear Gurus,
    I known the Oracle 9i have this new feature "Identifying Unused Indexes" via ALTER INDEX MONITORING USAGE, but how can I monitoring the index usage in the Oracle 8i?
    Regars

    You can't in 8i. However you can look at the SQL Text in the SGA looking for anything that matches the table name that the index is for and then look at the explain plan for the selects and updates. Pain in the xxx to do but it should give you the information.

  • Error in Update optimizer statistics - index is in unusable state

    Hello,
    we have this error in log Check and update optimizer statistics:
    12.02.2009     23:21:20     'BEGIN DBMS_STATS.GATHER_TABLE_STATS (OWNNAME => '"SAPPB1"', TABNAME => '"/BIC/FZPPC0002"', ESTIMATE_PERCENT => 10, METHOD_OPT =
    12.02.2009     23:21:20     ORA-20000: index "SAPPB1"."/BIC/FZPPC0002~010"  or partition of such index is in unusable state
    12.02.2009     23:21:20     ORA-06512: at "SYS.DBMS_STATS", line 13452
    12.02.2009     23:21:20     ORA-06512: at "SYS.DBMS_STATS", line 13472
    12.02.2009     23:21:20     ORA-06512: at line 1
    12.02.2009     23:21:20     BR0886E Checking/collecting statistics failed for table SAPPB1./BIC/FZPPC0002
    i can temporary fix this problem when i delete and recreate index via SE14,  but this help only for one next running update statistics, every next running update statistics has same error:  index "SAPPB1"."/BIC/FZPPC0002~010"  or partition of such index is in unusable state. Exist any definitive solution for this problem. Thanks

    Hi,
    Two methods for checking/repairing Indexing issues
    1)RSRV for a particular cube
    2)SAP_INFOCUBE_INDEXES_REPAIR report
    You can also use this sql to rebuild an Index.
    alter index <index name> rebuild online; Or you can rebuild Index by using ABAP report 'RSANAORA'.
    Please check below thread it may help you.
    /message/6483705#6483705 [original link is broken]
    https://forums.sdn.sap.com/click.jspa?searchID=12942068&messageID=2052264
    Thanks,
    Sushil

  • Index issue with or and between when we set one partition index to unusable

    Need to understand why optimizer unable to use index in case of "OR" whenn we set one partition index to unusable, the same query with between uses index.
    “OR” condition fetch less data comparing to “BETWEEN” still oracle optimizer unable to use indexes in case of “OR”
    1. Created local index on partitioned table
    2. ndex partition t_dec_2009 set to unusable
    -- Partitioned local Index behavior with “OR” and with “BETWEEN”
    SQL> CREATE TABLE t (
      2    id NUMBER NOT NULL,
      3    d DATE NOT NULL,
      4    n NUMBER NOT NULL,
      5    pad VARCHAR2(4000) NOT NULL
      6  )
      7  PARTITION BY RANGE (d) (
      8    PARTITION t_jan_2009 VALUES LESS THAN (to_date('2009-02-01','yyyy-mm-dd')),
      9    PARTITION t_feb_2009 VALUES LESS THAN (to_date('2009-03-01','yyyy-mm-dd')),
    10    PARTITION t_mar_2009 VALUES LESS THAN (to_date('2009-04-01','yyyy-mm-dd')),
    11    PARTITION t_apr_2009 VALUES LESS THAN (to_date('2009-05-01','yyyy-mm-dd')),
    12    PARTITION t_may_2009 VALUES LESS THAN (to_date('2009-06-01','yyyy-mm-dd')),
    13    PARTITION t_jun_2009 VALUES LESS THAN (to_date('2009-07-01','yyyy-mm-dd')),
    14    PARTITION t_jul_2009 VALUES LESS THAN (to_date('2009-08-01','yyyy-mm-dd')),
    15    PARTITION t_aug_2009 VALUES LESS THAN (to_date('2009-09-01','yyyy-mm-dd')),
    16    PARTITION t_sep_2009 VALUES LESS THAN (to_date('2009-10-01','yyyy-mm-dd')),
    17    PARTITION t_oct_2009 VALUES LESS THAN (to_date('2009-11-01','yyyy-mm-dd')),
    18    PARTITION t_nov_2009 VALUES LESS THAN (to_date('2009-12-01','yyyy-mm-dd')),
    19    PARTITION t_dec_2009 VALUES LESS THAN (to_date('2010-01-01','yyyy-mm-dd'))
    20  );
    SQL> INSERT INTO t
      2  SELECT rownum, to_date('2009-01-01','yyyy-mm-dd')+rownum/274, mod(rownum,11), rpad('*',100,'*')
      3  FROM dual
      4  CONNECT BY level <= 100000;
    SQL> CREATE INDEX i ON t (d) LOCAL;
    SQL> execute dbms_stats.gather_table_stats(user,'T')
    -- Mark partition t_dec_2009 to unusable:
    SQL> ALTER INDEX i MODIFY PARTITION t_dec_2009 UNUSABLE;
    --- Let’s check whether the usable index partition can be used to apply a restriction: BETWEEN
    SQL> SELECT count(d)
        FROM t
        WHERE d BETWEEN to_date('2009-01-01 23:00:00','yyyy-mm-dd hh24:mi:ss')
                    AND to_date('2009-02-02 01:00:00','yyyy-mm-dd hh24:mi:ss');
    SQL> SELECT * FROM table(dbms_xplan.display_cursor(format=>'basic +partition'));
    | Id  | Operation               | Name | Pstart| Pstop |
    |   0 | SELECT STATEMENT        |      |       |       |
    |   1 |  SORT AGGREGATE         |      |       |       |
    |   2 |   PARTITION RANGE SINGLE|      |    12 |    12 |
    |   3 |    INDEX RANGE SCAN     | I    |    12 |    12 |
    --- Let’s check whether the usable index partition can be used to apply a restriction: OR
    SQL> SELECT count(d)
        FROM t
        WHERE
        (d >= to_date('2009-01-01 23:00:00','yyyy-mm-dd hh24:mi:ss') and d <= to_date('2009-01-01 23:59:59','yyyy-mm-dd hh24:mi:ss'))
        or
        (d >= to_date('2009-02-02 01:00:00','yyyy-mm-dd hh24:mi:ss') and d <= to_date('2009-02-02 02:00:00','yyyy-mm-dd hh24:mi:ss'))
    SQL> SELECT * FROM table(dbms_xplan.display_cursor(format=>'basic +partition'));
    | Id  | Operation           | Name | Pstart| Pstop |
    |   0 | SELECT STATEMENT    |      |       |       |
    |   1 |  SORT AGGREGATE     |      |       |       |
    |   2 |   PARTITION RANGE OR|      |KEY(OR)|KEY(OR)|
    |   3 |    TABLE ACCESS FULL| T    |KEY(OR)|KEY(OR)|
    ----------------------------------------------------“OR” condition fetch less data comparing to “BETWEEN” still oracle optimizer unable to use indexes in case of “OR”
    Regards,
    Sachin B.

    Hi,
    What is your database version????
    I ran the same test and optimizer was able to pick the index for both the queries.
    SQL> select * from v$version;
    BANNER
    Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod
    PL/SQL Release 10.2.0.4.0 - Production
    CORE    10.2.0.4.0      Production
    TNS for 32-bit Windows: Version 10.2.0.4.0 - Production
    NLSRTL Version 10.2.0.4.0 - Production
    SQL>
    SQL> set autotrace traceonly exp
    SQL>
    SQL>
    SQL>  SELECT count(d)
      2  FROM t
      3  WHERE d BETWEEN to_date('2009-01-01 23:00:00','yyyy-mm-dd hh24:mi:ss')
      4              AND to_date('2009-02-02 01:00:00','yyyy-mm-dd hh24:mi:ss');
    Execution Plan
    Plan hash value: 2381380216
    | Id  | Operation                 | Name | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | SELECT STATEMENT          |      |     1 |     8 |    25   (0)| 00:00:01 |       |       |
    |   1 |  SORT AGGREGATE           |      |     1 |     8 |            |          |       |       |
    |   2 |   PARTITION RANGE ITERATOR|      |  8520 | 68160 |    25   (0)| 00:00:01 |     1 |     2 |
    |*  3 |    INDEX RANGE SCAN       | I    |  8520 | 68160 |    25   (0)| 00:00:01 |     1 |     2 |
    Predicate Information (identified by operation id):
       3 - access("D">=TO_DATE(' 2009-01-01 23:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
                  "D"<=TO_DATE(' 2009-02-02 01:00:00', 'syyyy-mm-dd hh24:mi:ss'))
    SQL>  SELECT count(d)
      2  FROM t
      3  WHERE
      4  (
      5  (d >= to_date('2009-01-01 23:00:00','yyyy-mm-dd hh24:mi:ss') and d <= to_date('2009-01-01 23:59:59','yyyy-mm-dd hh24:mi:ss'
      6  or
      7  (d >= to_date('2009-02-02 01:00:00','yyyy-mm-dd hh24:mi:ss') and d <= to_date('2009-02-02 02:00:00','yyyy-mm-dd hh24:mi:ss'
      8  );
    Execution Plan
    Plan hash value: 3795917108
    | Id  | Operation                | Name | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
    |   0 | SELECT STATEMENT         |      |     1 |     8 |     4   (0)| 00:00:01 |       |       |
    |   1 |  SORT AGGREGATE          |      |     1 |     8 |            |          |       |       |
    |   2 |   CONCATENATION          |      |       |       |            |          |       |       |
    |   3 |    PARTITION RANGE SINGLE|      |    13 |   104 |     2   (0)| 00:00:01 |     2 |     2 |
    |*  4 |     INDEX RANGE SCAN     | I    |    13 |   104 |     2   (0)| 00:00:01 |     2 |     2 |
    |   5 |    PARTITION RANGE SINGLE|      |    13 |   104 |     2   (0)| 00:00:01 |     1 |     1 |
    |*  6 |     INDEX RANGE SCAN     | I    |    13 |   104 |     2   (0)| 00:00:01 |     1 |     1 |
    Predicate Information (identified by operation id):
       4 - access("D">=TO_DATE(' 2009-02-02 01:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
                  "D"<=TO_DATE(' 2009-02-02 02:00:00', 'syyyy-mm-dd hh24:mi:ss'))
       6 - access("D">=TO_DATE(' 2009-01-01 23:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
                  "D"<=TO_DATE(' 2009-01-01 23:59:59', 'syyyy-mm-dd hh24:mi:ss'))
           filter(LNNVL("D"<=TO_DATE(' 2009-02-02 02:00:00', 'syyyy-mm-dd hh24:mi:ss')) OR
                  LNNVL("D">=TO_DATE(' 2009-02-02 01:00:00', 'syyyy-mm-dd hh24:mi:ss')))
    SQL> set autotrace off
    SQL>Asif Momen
    http://momendba.blogspot.com

  • Primary index does not exist in database but shows in SE14?

    I added a couple of key fields to a Z table and activated it. Every thing went well - adjusted it with SE14 also.
    When I checked the Runtime object - it is OK.
    When I checked Database Object, it is showing that the Primary Index does not exist in Database but SE14 says that the Priamry Index exists in Database.
    Please advise how to correct this. I saw another psoting when I searched per this error message: "Indexes: Inconsistent with DDIC source" . It tells to create this index at Database but need to know the steps.
    pl advise.
    (reposting here)
    Edited by: Venkatabby on Mar 26, 2008 4:05 PM

    hi,
    To create a index for a table,
    go to se11->click on Indexes tab and create  a primary index.
    Indexes speed up data selection from the database. They consist of selected fields of a table, of which a copy is then made in sorted order. If you specify the index fields correctly in a condition in the WHERE or HAVING clause, the system only searches part of the index (index range scan).
    The system automatically creates the primary index. It consists of the primary key fields of the database table. This means that for each combination of fields in the index, there is a maximum of one line in the table. This kind of index is also known as UNIQUE.
    If you cannot use the primary index to determine the result set because, for example, none of the primary index fields occur in the WHERE or HAVINGclauses, the system searches through the entire table (full table scan). For this case, you can create secondary indexes, which can restrict the number of table entries searched to form the result set.
    You create secondary indexes using the ABAP Dictionary. There you can create its columns and define it as UNIQUE.
    reward points if useful.
    regards
    sandhya

  • Too Many Index in a Table

    Dear Gurus,
    I´ve got some performance problems of an especific table called CC_FICHA_FINANCEIRA, the structure of the table is described below:
    NUMBER OF RECORDS: ABOUT 1.600.000
    NAME NULL TYPE
    CD_FUNDACAO NOT NULL VARCHAR2(2)
    NUM_INSCRICAO NOT NULL VARCHAR2(9)
    CD_PLANO NOT NULL VARCHAR2(4)
    CD_TIPO_CONTRIBUICAO NOT NULL VARCHAR2(2)
    ANO_REF NOT NULL VARCHAR2(4)
    MES_REF NOT NULL VARCHAR2(2)
    SEQ_CONTRIBUICAO NOT NULL NUMBER(5)
    CD_OPERACAO NOT NULL VARCHAR2(1)
    SRC NUMBER(15,2)
    REMUNERACAO NUMBER(15,2)
    CONTRIB_PARTICIPANTE NUMBER(15,2)
    CONTRIB_EMPRESA NUMBER(15,2)
    DIF_CONTRIB_PARTICIPANTE NUMBER(15,2)
    DIF_CONTRIB_EMPRESA NUMBER(15,2)
    TAXA_ADM_PARTICIPANTE NUMBER(15,2)
    TAXA_ADM_EMPRESA NUMBER(15,2)
    QTD_COTA_RP_PARTICIPANTE NUMBER(15,6)
    QTD_COTA_FD_PARTICIPANTE NUMBER(15,6)
    QTD_COTA_RP_EMPRESA NUMBER(15,6)
    QTD_COTA_FD_EMPRESA NUMBER(15,6)
    ANO_COMP NOT NULL VARCHAR2(4)
    MES_COMP NOT NULL VARCHAR2(2)
    CD_ORIGEM VARCHAR2(2)
    EXPORTADO VARCHAR2(1)
    SEQ_PP_PR_PAR NUMBER(10)
    ANO_PP_PR_PAR NUMBER(5)
    SEQ_PP_PR_EMP NUMBER(10)
    ANO_PP_PR_EMP NUMBER(5)
    SEQ_PP_PR_TX_PAR NUMBER(10)
    ANO_PP_PR_TX_PAR NUMBER(5)
    SEQ_PP_PR_TX_EMP NUMBER(10)
    ANO_PP_PR_TX_EMP NUMBER(5)
    I think that the indexes of this table can be the problem, there are too many. I will describe them below:
    INDEX COLUMNS
    CC_FICHA_FINANCEIRA_PK CD_FUNDACAO
    NUM_INSCRICAO
    CD_PLANO
    CD_TIPO_CONTRIBUICAO
    ANO_REF
    MES_REF
    SEQ_CONTRIBUICAO
    CD_OPERACAO
    ANO_COMP
    MES_COMP
    CC_FICHA_FINANCEIRA_IDX_002 CD_FUNDACAO
    NUM_INSCRICAO
    CD_PLANO
    CD_TIPO_CONTRIBUICAO
    ANO_COMP
    ANO_REF
    MES_COMP
    MES_REF
    SRC
    CC_FICHA_FINANCEIRA_IDX_006 CD_ORIGEM
    CC_FICHA_FINANCEIRA_IDX_007 CD_TIPO_CONTRIBUICAO
    CC_FICHA_FINANCEIRA_IDX2 CD_FUNDACAO
    ANO_REF
    MES_REF
    NUM_INSCRICAO
    CD_PLANO
    CD_TIPO_CONTRIBUICAO
    CONTRIB_EMPRESA
    CC_FICHA_FINANCEIRA_IDX3 CD_FUNDACAO
    ANO_REF
    MES_REF
    CD_PLANO
    CD_TIPO_CONTRIBUICAO
    SEQ_CONTRIBUICAO
    There are columns that have 4 indexes. Is it right? How is the better way to analyze those indexes?
    Regards...

    Hi,
    You can monitor index usage to know if it used by application.
    See metalink note 136642.1 Identifying Unused Indexes with the ALTER INDEX MONITORING USAGE Command
    Nicolas.

  • "UPDATE GLOBAL INDEXES"를 사용하여, DDL 처리와 동시에 GLOBAL INDEX를 자동 관리하는 방안

    제품 : ORACLE SERVER
    작성날짜 :
    "UPDATE GLOBAL INDEXES"를 사용하여, DDL 처리와 동시에 GLOBAL INDEX를 자동 관리하는 방안
    ==========================================================================================
    PURPOSE
    이 문서에서는 다음과 같은 사항을 기술한다.
    1. 새로 추가된 기능으로, 테이블 파티션에 대한 DDL 수행시
    지정 가능한 "UPDATE GLOBAL INDEXES" 절에 대한 설명
    2. UPDATE GLOBAL INDEXES를 사용하는 것 보다는 REBUILD INDEX를
    사용하여야 하는 성능상의 고려사항.
    SCOPE
    Oracle Partitioning Option은 8~10g Standard Edition에서는 지원하지
    않는다.
    Explanation
    테스트를 위해 먼저 4개의 테이블을 생성한다.
    1. RANGE partitioned table을 생성한 후 GLOBAL index를 만든다:
    SQL> create table orders (
    2 order_no number,
    3 part_no varchar2(40),
    4 ord_date date
    5 )
    6 partition by range (ord_date)
    7 (partition Q1 values less than (TO_DATE('01-APR-1999','DD-MON-YYYY')),
    8 partition Q2 values less than (TO_DATE('01-JUL-1999','DD-MON-YYYY')),
    9 partition Q3 values less than (TO_DATE('01-OCT-1999','DD-MON-YYYY')),
    10 partition Q4 values less than (TO_DATE('03-JAN-2000','DD-MON-YYYY'))
    11 );
    Table created.
    SQL> create index orders_global_idx
    2 on orders(ord_date)
    3 global partition by range (ord_date)
    4 (partition GLOBAL1 values less than (TO_DATE('01-APR-1999','DD-MON-YYYY')
    5 partition GLOBAL2 values less than (TO_DATE('01-SEP-1999','DD-MON-YYYY')
    6 partition GLOBAL3 values less than (TO_DATE('01-DEC-2000','DD-MON-YYYY')
    7 partition GLOBAL4 values less than (MAXVALUE)
    8 );
    Index created.
    SQL> select substr(index_name,1,20) index_name,
    2 substr(partition_name,1,20) part_name,
    3 status
    4 from dba_ind_partitions
    5 where index_name= 'ORDERS_GLOBAL_IDX' order by partition_name;
    INDEX_NAME PART_NAME STATUS
    ORDERS_GLOBAL_IDX GLOBAL1 USABLE
    ORDERS_GLOBAL_IDX GLOBAL2 USABLE
    ORDERS_GLOBAL_IDX GLOBAL3 USABLE
    ORDERS_GLOBAL_IDX GLOBAL4 USABLE
    SQL> insert into orders values (1,100,TO_DATE('02-FEB-1999','DD-MON-YYYY'));
    2. HASH partitioned table을 생성 한 후 GLOBAL index를 만든다:
    SQL> CREATE TABLE emp_hpart(
    2 empno NUMBER(4) NOT NULL,
    3 ename VARCHAR2(10),
    4 sal NUMBER(7,2))
    5 PARTITION BY HASH(sal)
    6 (PARTITION H1, PARTITION H2, PARTITION H3, PARTITION H4);
    Table created.
    SQL> CREATE INDEX emp_global_HASH_idx ON emp_hpart(ename)
    2 GLOBAL PARTITION BY RANGE (ename)
    3 (PARTITION p1 VALUES LESS THAN ('N') ,
    4 PARTITION p2 VALUES LESS THAN (MAXVALUE));
    Index created.
    SQL> select substr(index_name,1,20) index_name,
    2 substr(partition_name,1,20) part_name,status
    3 from dba_ind_partitions
    4 where index_name= 'EMP_GLOBAL_HASH_IDX' order by partition_name;
    INDEX_NAME PART_NAME STATUS
    EMP_GLOBAL_HASH_IDX P1 USABLE
    EMP_GLOBAL_HASH_IDX P2 USABLE
    SQL> insert into emp_hpart values (1,'AAA',100);
    3. COMPOSITE partitioned table을 생성한 후 GLOBAL index를 만든다:
    SQL> CREATE TABLE emp_composite(
    2 empno NUMBER(4) NOT NULL,
    3 ename VARCHAR2(10),
    4 sal NUMBER(6))
    5 PARTITION BY RANGE(empno)
    6 SUBPARTITION BY HASH(sal) SUBPARTITIONS 4
    7 (PARTITION p1 VALUES LESS THAN (50),
    8 PARTITION p2 VALUES LESS THAN (100),
    9 PARTITION p3 VALUES LESS THAN (150),
    10 PARTITION p4 VALUES LESS THAN (MAXVALUE));
    Table created.
    SQL> CREATE INDEX emp_global_composite_idx ON emp_composite(ename)
    2 GLOBAL PARTITION BY RANGE (ename)
    3 (PARTITION p1 VALUES LESS THAN ('N') ,
    4 PARTITION p2 VALUES LESS THAN (MAXVALUE));
    Index created.
    SQL> select substr(index_name,1,20) index_name,
    2 substr(partition_name,1,20) part_name,status
    3 from dba_ind_partitions
    4 where index_name= 'EMP_GLOBAL_COMPOSITE_IDX' order by
    partition_name;
    INDEX_NAME PART_NAME STATUS
    EMP_GLOBAL_COMPOSITE P1 USABLE
    EMP_GLOBAL_COMPOSITE P2 USABLE
    SQL> insert into emp_composite values (1,'AAA',100);
    4. LIST partitioned table을 생성 한 후 GLOBAL index를 만든다:
    SQL> CREATE TABLE locations (
    2 location_id NUMBER, street_address VARCHAR2(80), postal_code
    CHAR(12),
    3 city VARCHAR2(80), state_province CHAR(2), country_id
    VARCHAR2(20))
    4 PARTITION BY LIST (state_province)
    5 (PARTITION region_east
    6 VALUES ('MA','NY','CT','NH','ME','MD','VA','PA','NJ'),
    7 PARTITION region_west
    8 VALUES ('CA','AZ','NM','OR','WA','UT','NV','CO'),
    9 PARTITION region_south
    10 VALUES ('TX','KY','TN','LA','MS','AR','AL','GA'),
    11 PARTITION region_central
    12 VALUES ('OH','ND','SD','MO','IL','MI',NULL,'IA'));
    Table created.
    SQL> create index loc_global_idx
    2 on locations (state_province)
    3 global partition by range (state_province)
    4 (partition p1 values less than ('NV'),
    5 partition p2 values less than (maxvalue));
    Index created.
    SQL> INSERT INTO locations VALUES
    2 ( 1000,'1297 Via Cola di Rie','00989','Roma',NULL,'IT');
    1 row created.
    SQL> select substr(index_name,1,20) index_name,
    substr(partition_name,1,20)
    2 part_name , status
    3 from dba_ind_partitions
    4 where index_name= 'LOC_GLOBAL_IDX' order by partition_name;
    INDEX_NAME PART_NAME STATUS
    LOC_GLOBAL_IDX P1 USABLE
    LOC_GLOBAL_IDX P2 USABLE
    *** 오라클 8/8i : UPDATE GLOBAL INDEXES 절을 사용하지 않았을 때
    SQL> select substr(index_name,1,20) index_name,
    2 substr(partition_name,1,20) part_name,status
    3 from dba_ind_partitions
    4 where index_name= 'ORDERS_GLOBAL_IDX' order by partition_name;
    INDEX_NAME PART_NAME STATUS
    ORDERS_GLOBAL_IDX GLOBAL1 USABLE
    ORDERS_GLOBAL_IDX GLOBAL2 USABLE
    ORDERS_GLOBAL_IDX GLOBAL3 USABLE
    ORDERS_GLOBAL_IDX GLOBAL4 USABLE
    SQL> ALTER TABLE orders DROP PARTITION q2;
    Table altered.
    SQL> select substr(index_name,1,20) index_name,
    substr(partition_name,1,20)
    2 part_name, status
    3 from dba_ind_partitions
    4 where index_name= 'ORDERS_GLOBAL_IDX' order by partition_name;
    INDEX_NAME PART_NAME STATUS
    ORDERS_GLOBAL_IDX GLOBAL1 UNUSABLE
    ORDERS_GLOBAL_IDX GLOBAL2 UNUSABLE
    ORDERS_GLOBAL_IDX GLOBAL3 UNUSABLE
    ORDERS_GLOBAL_IDX GLOBAL4 UNUSABLE
    => Oracle 9i 이전 버젼에서는, partitioned table의 특정 파티션에 대해
    DDL을 수행하면, 해당 파티션이 비어있는 상태가 아니라면,
    GLOBAL index에 대한 상태를 invalidate 시킨다.
    => Oracle 9i에서 UPDATE GLOBAL INDEXES 절을 수행하면, 테이블의
    파티션에 대한 DDL 작업을 수행하는 동안 GLOBAL INDEX에
    대한 관리 작업을 자동으로 수행하게 된다.
    그러나 일부 작업에 대해서는, 위와 같은 작업이 허용되지
    않는다.
    *** UPDATE GLOBAL INDEXES 절과 ADD PARTITION 절의 동시 사용
    1. RANGE partitioned table:
    SQL> ALTER TABLE orders ADD PARTITION q5
    2 values less than (TO_DATE('03-JUN-2000','DD-MON-YYYY'))
    3 UPDATE GLOBAL INDEXES;
    ALTER TABLE orders ADD PARTITION q5
    ERROR at line 1:
    ORA-30564: Index maintainence clause not allowed for ADD partition to
    RANGE
    partitioned tables
    UPDATE GLOBAL INDEXES 절은 다음 경우에만 사용할 수 있다.
    => HASH partitioned table에 partition 추가
    => Composite partitioned table에 subpartition 추가
    | RANGE partitioned table에 일반적인 방식으로 작업 수행 |
    SQL> ALTER TABLE orders ADD PARTITION q5
    2 values less than (TO_DATE('03-JUN-2000','DD-MON-YYYY'));
    Table altered.
    SQL> @sel
    INDEX_NAME PART_NAME STATUS
    ORDERS_GLOBAL_IDX GLOBAL1 USABLE
    ORDERS_GLOBAL_IDX GLOBAL2 USABLE
    ORDERS_GLOBAL_IDX GLOBAL3 USABLE
    ORDERS_GLOBAL_IDX GLOBAL4 USABLE
    2. HASH partitioned table:
    | UPDATE GLOBAL INDEXES절을 HASH partitioned table 에서 사용 |
    | 하지 않을 경우 global index가 UNUSABLE 상태로 남음 |
    SQL> ALTER TABLE emp_hpart ADD PARTITION q5
    2 UPDATE GLOBAL INDEXES;
    Table altered.
    SQL> @sel
    INDEX_NAME PART_NAME STATUS
    EMP_GLOBAL_HASH_IDX P1 USABLE
    EMP_GLOBAL_HASH_IDX P2 USABLE
    3. COMPOSITE partitioned table:
    | UPDATE GLOBAL INDEXES 절을 COMPOSITE partitioned table에서 사용 |
    | 하지 않을 경우 global index가 UNUSABLE 상태로 남음 |
    SQL> ALTER TABLE emp_composite MODIFY PARTITION p1 add subpartition h5
    2 UPDATE GLOBAL INDEXES;
    Table altered.
    SQL> @sel
    INDEX_NAME PART_NAME STATUS
    EMP_GLOBAL_COMPOSITE P1 USABLE
    EMP_GLOBAL_COMPOSITE P2 USABLE
    4. LIST partitioned table
    | LIST partitioned table에 대해서는 일반적인 방법 사용 |
    SQL> alter table locations ADD
    2 partition nomansland values ('XX');
    Table altered.
    SQL> @sel
    INDEX_NAME PART_NAME STATUS
    LOC_GLOBAL_IDX P1 USABLE
    LOC_GLOBAL_IDX P2 USABLE
    *** UPDATE GLOBAL INDEXES 절과 DROP PARTITION절의 동시사용
    1. RANGE partitioned table:
    | UPDATE GLOBAL INDEXES를 RANGE partitioned table에서 사용 |
    | 하지 않을 경우 global index가 UNUSABLE 상태로 남음 |
    SQL> ALTER TABLE orders DROP PARTITION q2 UPDATE GLOBAL INDEXES;
    Table altered.
    2. HASH partitioned table:
    HASH partitioned table에서는 DROP 명령을 수행할 수 없으며,
    COALESCE를 대신 사용함 (문서 마지막 부분을 참조)
    3. COMPOSITE partitioned table:
    | UPDATE GLOBAL INDEXES를 COMPOSITE partitioned table에서 사용하지|
    | 않을 경우 global index가 UNUSABLE 상태로 남음 |
    SQL> ALTER TABLE emp_composite DROP PARTITION p2
    2 UPDATE GLOBAL INDEXES;
    Table altered.
    4. LIST partitioned table:
    | UPDATE GLOBAL INDEXES를 LIST partitioned table에서 사용하지 |
    | 않을 경우 global index가 UNUSABLE 상태로 남음 |
    SQL> alter table locations DROP PARTITION
    2 region_south
    3 UPDATE GLOBAL INDEXES;
    Table altered.
    *** UPDATE GLOBAL INDEXES 절과 SPLIT PARTITION 절의 동시 사용
    1. RANGE partitioned table
    | UPDATE GLOBAL INDEXES를 RANGE partitioned table에서 사용 |
    | 하지 않을 경우 global index가 UNUSABLE 상태로 남음 |
    SQL> ALTER TABLE orders SPLIT PARTITION q3 AT
    2 (TO_DATE('15-SEP-1999','DD-MON-YYYY'))
    3 INTO (PARTITION q3_1, PARTITION q3_2)
    4 UPDATE GLOBAL INDEXES;
    Table altered.
    2. HASH partitioned table
    HASH partitioned table에서는 SPLIT 명령을 수행할 수 없으며,
    ADD를 대신 사용함 (윗 부분에 기술하였음)
    3. COMPOSITE partitioned table
    | UPDATE GLOBAL INDEXES를 COMPOSITE partitioned table에서 사용하지|
    | 않을 경우 global index가 UNUSABLE 상태로 남음 |
    SQL> ALTER TABLE emp_composite SPLIT PARTITION p2 AT (80)
    2 INTO (PARTITION p2_1, PARTITION p2_2)
    3 UPDATE GLOBAL INDEXES;
    Table altered.
    4. LIST partitioned tables:
    | UPDATE GLOBAL INDEXES를 LIST partitioned table에서 사용하지 |
    | 않을 경우 global index가 UNUSABLE 상태로 남음 |
    SQL> alter table locations SPLIT PARTITION region_east
    2 VALUES ('MA','NJ')
    3 INTO (PARTITION region_east_1, PARTITION region_east_2)
    4 UPDATE GLOBAL INDEXES;
    Table altered.
    *** UPDATE GLOBAL INDEXES 절과 MERGE PARTITION 절의 동시 사용
    1. RANGE partitioned table
    | UPDATE GLOBAL INDEXES를 RANGE partitioned table에서 사용 |
    | 하지 않을 경우 global index가 UNUSABLE 상태로 남음 |
    SQL> ALTER TABLE orders MERGE PARTITIONS q2, q3 INTO PARTITION q3
    2 UPDATE GLOBAL INDEXES;
    Table altered.
    2. HASH partitioned table
    HASH partitioned table에서는 MERGE 명령을 수행할 수 없으며,
    COALESCE를 대신 사용함 (문서 마지막 부분을 참조)
    3. COMPOSITE partitioned table
    | UPDATE GLOBAL INDEXES를 COMPOSITE partitioned table에서 사용하지|
    | 않을 경우 global index가 UNUSABLE 상태로 남음 |
    SQL> ALTER TABLE emp_composite MERGE PARTITIONS p1, p2
    2 INTO PARTITION p2
    3 UPDATE GLOBAL INDEXES;
    Table altered.
    4. LIST partitioned table:
    | UPDATE GLOBAL INDEXES를 LIST partitioned table에서 사용하지 |
    | 않을 경우 global index가 UNUSABLE 상태로 남음 |
    SQL> alter table locations MERGE PARTITIONS region_east,region_west
    2 INTO PARTITION region_north
    3 UPDATE GLOBAL INDEXES;
    Table altered.
    *** UPDATE GLOBAL INDEXES 절과 EXCHANGE PARTITION 절의 동시사용
    1. RANGE partitioned tables
    | UPDATE GLOBAL INDEXES를 RANGE partitioned table에서 사용 |
    | 하지 않을 경우 global index가 UNUSABLE 상태로 남음 |
    SQL> ALTER TABLE orders EXCHANGE PARTITION q3 WITH TABLE t_orders
    2 UPDATE GLOBAL INDEXES;
    Table altered.
    If GLOBAL indexes exist on the TABLE of exchange, they are left UNUSABLE:
    SQL> create index t_orders_global_idx
    2 on t_orders(ord_date)
    3 global partition by range (ord_date)
    4 (partition GLOBAL1 values less than (TO_DATE('01-APR-1999','DD-MON-YYY
    Y')),
    5 partition GLOBAL2 values less than (TO_DATE('01-SEP-1999','DD-MON-YYY
    Y')),
    6 partition GLOBAL3 values less than (TO_DATE('01-DEC-1999','DD-MON-YYY
    Y')),
    7 partition GLOBAL4 values less than (MAXVALUE) );
    Index created.
    SQL> ALTER TABLE orders EXCHANGE PARTITION q3 WITH TABLE t_orders
    2 UPDATE GLOBAL INDEXES;
    Table altered.
    SQL> @sel
    INDEX_NAME PART_NAME STATUS
    T_ORDERS_GLOBAL_IDX GLOBAL1 UNUSABLE
    T_ORDERS_GLOBAL_IDX GLOBAL2 UNUSABLE
    T_ORDERS_GLOBAL_IDX GLOBAL3 UNUSABLE
    T_ORDERS_GLOBAL_IDX GLOBAL4 UNUSABLE
    ORDERS_GLOBAL_IDX GLOBAL1 USABLE
    ORDERS_GLOBAL_IDX GLOBAL2 USABLE
    ORDERS_GLOBAL_IDX GLOBAL3 USABLE
    ORDERS_GLOBAL_IDX GLOBAL4 USABLE
    2. HASH partitioned tables
    | UPDATE GLOBAL INDEXES를 HASH partitioned table에서 사용하 |
    | 지 않을 경우 global index가 UNUSABLE 상태로 남음 |
    SQL> ALTER TABLE emp_hpart EXCHANGE PARTITION H1 WITH TABLE t_emp_hpart
    2 UPDATE GLOBAL INDEXES;
    Table altered.
    3. COMPOSITE partitioned tables
    SQL> ALTER TABLE emp_composite EXCHANGE PARTITION p1 WITH TABLE t_emp_composi
    te;
    ALTER TABLE emp_composite EXCHANGE PARTITION p1 WITH TABLE t_emp_composite
    ERROR at line 1:
    ORA-14291: cannot EXCHANGE a composite partition with a non-partitioned table
    | UPDATE GLOBAL INDEXES를 COMPOSITE partitioned table에서 사용하지|
    | 않을 경우 global index가 UNUSABLE 상태로 남음 |
    SQL> ALTER TABLE emp_composite EXCHANGE SUBPARTITION SYS_SUBP286
    2 WITH TABLE t_emp_composite
    3 UPDATE GLOBAL INDEXES;
    Table altered.
    4. LIST partitioned tables:
    | UPDATE GLOBAL INDEXES를 LIST partitioned table에서 사용하지 |
    | 않을 경우 global index가 UNUSABLE 상태로 남음 |
    SQL> ALTER TABLE locations EXCHANGE PARTITION region_east
    2 WITH TABLE t_locations
    3 UPDATE GLOBAL INDEXES;
    Table altered.
    *** UPDATE GLOBAL INDEXES절과 MOVE PARTITION 절의 동시사용
    1. RANGE partitioned table
    | UPDATE GLOBAL INDEXES를 RANGE partitioned table에서 사용 |
    | 하지 않을 경우 global index가 UNUSABLE 상태로 남음 |
    SQL> ALTER TABLE orders MOVE PARTITION q3 TABLESPACE example
    2 UPDATE GLOBAL INDEXES;
    Table altered.
    2. HASH partitioned table
    | UPDATE GLOBAL INDEXES를 HASH partitioned table에서 사용 |
    | 하지 않을 경우 global index가 UNUSABLE 상태로 남음 |
    SQL> ALTER TABLE emp_hpart MOVE PARTITION H1 TABLESPACE example
    2 UPDATE GLOBAL INDEXES;
    Table altered.
    3. COMPOSITE partitioned table
    SQL> ALTER TABLE emp_composite MOVE PARTITION p1 TABLESPACE example;
    ALTER TABLE emp_composite MOVE PARTITION p1 TABLESPACE example
    ERROR at line 1:
    ORA-14257: cannot move partition other than a Range or Hash partition
    SQL> ALTER TABLE emp_composite MOVE PARTITION p1 TABLESPACE example
    2 UPDATE GLOBAL INDEXES;
    ALTER TABLE emp_composite MOVE PARTITION p1 TABLESPACE example
    ERROR at line 1:
    ORA-14257: cannot move partition other than a Range or Hash partition
    4. LIST partitioned table
    | UPDATE GLOBAL INDEXES를 LIST partitioned table에서 사용하지 |
    | 않을 경우 global index가 UNUSABLE 상태로 남음 |
    SQL> ALTER TABLE locations MOVE PARTITION region_east
    2 TABLESPACE TS_DATA1
    3 UPDATE GLOBAL INDEXES;
    Table altered.
    *** UPDATE GLOBAL INDEXES 절과 TRUNCATE PARTITION 절의 동시 사용
    1. RANGE partitioned tables
    | UPDATE GLOBAL INDEXES를 RANGE partitioned table에서 사용 |
    | 하지 않을 경우 global index가 UNUSABLE 상태로 남음 |
    SQL> ALTER TABLE orders TRUNCATE PARTITION q3
    2 UPDATE GLOBAL INDEXES;
    Table truncated.
    2. HASH partitioned tables
    | UPDATE GLOBAL INDEXES를 HASH partitioned table에서 사용 |
    | 하지 않을 경우 global index가 UNUSABLE 상태로 남음 |
    SQL> ALTER TABLE emp_hpart TRUNCATE PARTITION H1
    2 UPDATE GLOBAL INDEXES;
    Table truncated.
    3. COMPOSITE partitioned table
    | UPDATE GLOBAL INDEXES를 COMPOSITE partitioned table에서 사용하지|
    | 않을 경우 global index가 UNUSABLE 상태로 남음 |
    SQL> ALTER TABLE emp_composite TRUNCATE PARTITION p1
    2 UPDATE GLOBAL INDEXES;
    Table truncated.
    4. LIST partitioned table
    | UPDATE GLOBAL INDEXES를 LIST partitioned table에서 사용하지 |
    | 않을 경우 global index가 UNUSABLE 상태로 남음 |
    SQL> ALTER TABLE locations TRUNCATE PARTITION region_east
    2 UPDATE GLOBAL INDEXES;
    Table truncated.
    *** UPDATE GLOBAL INDEXES 절과 COALESCE PARTITION 절의 동시사용
    1. RANGE partitioned table
    Range partitioned table에는 coalesce 기능이 지원되지 않음.
    2. HASH partitioned table
    | UPDATE GLOBAL INDEXES를 HASH partitioned table에서 사용 |
    | 하지 않을 경우 global index가 UNUSABLE 상태로 남음 |
    SQL> ALTER TABLE emp_hpart COALESCE PARTITION
    2 UPDATE GLOBAL INDEXES;
    Table altered.
    3. COMPOSITE partitioned table
    Composite partitioned table에 대해서는 coalesce 기능이 지원되지 않음.
    4. LIST partitioned table
    List partitioned table에 대해서는 coalesce 기능이 지원되지 않음.
    *** 성능상의 문제로 인해 UPDATE GLOBAL INDEXES 절을 사용하는 대신
    *** REBUILD INDEX를 사용하여야 할 경우
    UPDATE GLOBAL INDEXES절을 사용할 경우
    1 이전 버전에서는 단순히 invalid 상태로 표시하고 종료되었던 작업이
    인덱스 관리 작업까지 병행해 수행 되므로 partition DDL operation
    작업 수행 시간이 더 오래 걸린다.
    2 DROP, TRUNCATE, EXCHANGE 작업이 더 오래 걸린다. 이전에는 데이터
    딕셔너리상의 정보만을 갱신하는데 반해, UPDATE GLOBAL INDEXES절을
    사용할 경우, partition 내의 모든 row에 대한 scan 작업이 수행
    되기 때문이다.
    3 GLOBAL INDEX에 대한 갱신 작업을 통한 변경 사항이 redo log 및 rollback에
    남게 된다.
    4 row의 갯수가 작을 경우, update global index절을 사용하여 작업하는 것이
    편리하다.
    5 인덱스를 수동으로 rebuild 할 때 까지 애플리케이션 응답 속도가 현격
    하게 저하되는 것을 피할 수 있다.
    INDEX REBUILD를 사용할 경우
    1 전체 인덱스를 rebuild 하면, index가 좀더 효과적으로 구성된다.
    2 인덱스를 rebuild 하면, 사용자가 인덱스에 대한 구성을 수동으로
    변경할 수 있다.
    Example
    Reference Documents
    <Note:139707.1>

  • Can coalesce increase index size ?

    Hi,
    I'm trying to understand how space usage changes after coalesce of an index.
    I'm using Tom Kyte show_space procedure .
    DB is 9.2.0.8 .
    before Coalesce:
    Unformatted Blocks .....................               0
    FS1 Blocks (0-25)  .....................               0
    FS2 Blocks (25-50) .....................           1,811
    FS3 Blocks (50-75) .....................               0
    FS4 Blocks (75-100).....................               0
    Full Blocks        .....................           2,969
    Total Blocks............................           4,864
    Total Bytes.............................      39,845,888
    Total MBytes............................              38
    Unused Blocks...........................               0
    Unused Bytes............................               0
    Last Used Ext FileId....................             149
    Last Used Ext BlockId...................       2,979,081
    Last Used Block.........................             128
    After Coalesce
    Unformatted Blocks .....................               0
    FS1 Blocks (0-25)  .....................               0
    FS2 Blocks (25-50) .....................           4,142
    FS3 Blocks (50-75) .....................               0
    FS4 Blocks (75-100).....................               0
    Full Blocks        .....................             638
    Total Blocks............................           4,864
    Total Bytes.............................      39,845,888
    Total MBytes............................              38
    Unused Blocks...........................               0
    Unused Bytes............................               0
    Last Used Ext FileId....................             149
    Last Used Ext BlockId...................       2,979,081
    Last Used Block.........................             128Look like only two values changed:
    before:
    FS2 Blocks (25-50) ..................... 1,811
    after:
    FS2 Blocks (25-50) ..................... 4,142
    before
    Full Blocks ..................... 2,969
    after:
    Full Blocks ..................... 638
    So we got more blocks 25-50% free space
    and less full occupied blocks .
    And thats strange, how we can have less full blocks after coalescing ?
    Second question is there any reason my index can grow up after coalescing , when would this happen ?
    Please explain :).
    Regards
    GregG

    >
    SQL> select * from index_stats;
    HEIGHT     BLOCKS NAME                           PARTITION_NAME                    LF_ROWS    LF_BLKS LF_ROWS_LEN LF_BLK_LEN    BR_ROWS    BR_BLKS BR_ROWS_LEN BR_BLK_LEN DEL_LF_ROWS DEL_LF_ROWS_LEN DISTINCT_KEYS MOST_REPEATED_KEY BTREE_SPACE USED_SPACE   PCT_USED ROWS_PER_KEY BLKS_GETS_PER_ACCESS   PRE_ROWS PRE_ROWS_LEN OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
    3       4864 INDEX_NAME_1                                                    598311       4730     8622004       7348       4729         16       71606       8028      309286         4374735           593             93530    34884488    8693610         25   1008.95616           507.978078          0            0              1               23
    and after coalesce
    SQL> select * from index_stats;
    HEIGHT     BLOCKS NAME                           PARTITION_NAME                    LF_ROWS    LF_BLKS LF_ROWS_LEN LF_BLK_LEN    BR_ROWS    BR_BLKS BR_ROWS_LEN BR_BLK_LEN DEL_LF_ROWS DEL_LF_ROWS_LEN DISTINCT_KEYS MOST_REPEATED_KEY BTREE_SPACE USED_SPACE   PCT_USED ROWS_PER_KEY BLKS_GETS_PER_ACCESS   PRE_ROWS PRE_ROWS_LEN OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
    3       4864 INDEX_NAME_1                                                     289025        708     4247269       7996        707         16       10965       8028           0               0           347             67594     5789616    4258234         74   832.925072           419.962536          0            0              1               24It's a little hard to tell exactly what's happened based on summary statistics - but there are a couple of extra guesses we can make from these stats.
    The coalesce command won't try to coalesce blocks with active transactions (that't not a guess, by the way) - but when you hit a block which requires a lot of delayed block cleanout the recursive transaction for cleanout may make coalesce skip the block. You started with a lot of deleted leaf rows in the leaf blocks - so a lot of your "full" blocks may have been subject to cleanout, perhaps leaving them 25% free and bypassing a coalesce. You may find that if you issue the coalesce command a second time, right after the first, that Oracle manages to coalesce a lot more block.
    Apart from the 65,000 "most repeated key" you have an average of about 600 rows per key (that's indicated by doubling the blks_gets_per_access, after allowing for the single most repeated). Very repetitive keys can easily lead to space utilisation dropping to "below average" for b-trees, so 50% utilisation wouldn't be a surprise. Add to this the very repetitive key which could be a hot spot for concurrent inserts and the "ITL explosion" issue (see http://jonathanlewis.wordpress.com/category/oracle/indexing/index-explosion/ ) that halves the storage efficiency again. It's possible, though, that some of your performance overhead is simply the problem of fairly large range scans.
    Regards
    Jonathan Lewis

Maybe you are looking for