Index coalesce

hi masters.,
this is egarding index management. i am facing the problem regarding one sql query with union and order by clause.
when i remove order by clause, the query runs faster,than with order by clause.
is this the problem regarding index????
i know that indexes rarely need rebuild,thats why i am thinking of coalesce.is this the right decision??
what may be the problem else????
i am using oracle 9i. and i dont have statpack report coz the client is offshore.\
thanks and regards
VD

Vikrant,
Index is not picked by order by clause. Index entries are already sorted. See here a demo where I have used the index in a column.If I give order by clause, I explicitly get a Sort Order By in the plan.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining,
Oracle Database Vault and Real Application Testing options
SQL> create table sampletable as select * from scott.emp;
Table created.
SQL> create index idx on sampletable(empno);
Index created.
SQL> exec dbms_stats.gaher_table_stats(
BEGIN dbms_stats.gaher_table_stats(; END;
ERROR at line 1:
ORA-06550: line 1, column 36:
PLS-00103: Encountered the symbol ";" when expecting one of the following:
( ) - + case mod new not null <an identifier>
<a double-quoted delimited-identifier> <a bind variable>
table continue avg count current exists max min prior sql
stddev sum variance execute multiset the both leading
trailing forall merge year month day hour minute second
timezone_hour timezone_minute timezone_region timezone_abbr
time timestamp interval date
<a string literal with character set specification>
SQL> exec dbms_stats.gaher_table_stats('AMAN','SAMPLETABLE');
BEGIN dbms_stats.gaher_table_stats('AMAN','SAMPLETABLE'); END;
ERROR at line 1:
ORA-06550: line 1, column 18:
PLS-00302: component 'GAHER_TABLE_STATS' must be declared
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored
SQL> exec dbms_stats.gather_table_stats('AMAN','SAMPLETABLE');
PL/SQL procedure successfully completed.
SQL> set autot trace exp
SQL> select * from sampletable order by empno;
Execution Plan
Plan hash value: 5644182
| Id  | Operation          | Name        | Rows  | Bytes | Cost (%CPU)| Time
|
|   0 | SELECT STATEMENT   |             |    14 |   504 |     4  (25)| 00:00:01
|
|   1 |  SORT ORDER BY     |             |    14 |   504 |     4  (25)| 00:00:01
|
|   2 |   TABLE ACCESS FULL| SAMPLETABLE |    14 |   504 |     3   (0)| 00:00:01
|
SQL> select * from sampletable order by empno where empno in (7369,7422);
select * from sampletable order by empno where empno in (7369,7422)
ERROR at line 1:
ORA-00933: SQL command not properly ended
SQL> select * from sampletable  where empno in (7369,7422);
Execution Plan
Plan hash value: 3966318501
| Id  | Operation                    | Name        | Rows  | Bytes | Cost (%CPU)
| Time     |
|   0 | SELECT STATEMENT             |             |     2 |    72 |     1   (0)
| 00:00:01 |
|   1 |  INLIST ITERATOR             |             |       |       |
|          |
|   2 |   TABLE ACCESS BY INDEX ROWID| SAMPLETABLE |     2 |    72 |     1   (0)
| 00:00:01 |
|*  3 |    INDEX RANGE SCAN          | IDX         |     2 |       |     0   (0)
| 00:00:01 |
Predicate Information (identified by operation id):
   3 - access("EMPNO"=7369 OR "EMPNO"=7422)
SQL> select * from sampletable  where empno in (7369,7422) order by empno;
Execution Plan
Plan hash value: 3966318501
| Id  | Operation                    | Name        | Rows  | Bytes | Cost (%CPU)
| Time     |
|   0 | SELECT STATEMENT             |             |     2 |    72 |     1   (0)
| 00:00:01 |
|   1 |  INLIST ITERATOR             |             |       |       |
|          |
|   2 |   TABLE ACCESS BY INDEX ROWID| SAMPLETABLE |     2 |    72 |     1   (0)
| 00:00:01 |
|*  3 |    INDEX RANGE SCAN          | IDX         |     2 |       |     0   (0)
| 00:00:01 |
Predicate Information (identified by operation id):
   3 - access("EMPNO"=7369 OR "EMPNO"=7422)
SQL>The point that I was making is that it may be happening that you are doing an over sort sort of thing which is causing the query to be slow. Using index for returning rows in the ordered manner is not a good thing as Oracle always say that for a guaranteed ordered result, one must use an order by clause. So either you can choose to remove the order by clause or can choose to rewrite the query without using the Union operator.
But these all are just guess works. Its not possible to say what's happening specifically in your case as long as you don't post the plan for your query both,with and without the use of index.
HTH
Aman....

Similar Messages

  • Alter index coalesce nologging

    Hi,
    Is nologging superfluous when used with index coalesce?
    Thanks for help

    the link is about create/rebuild index, my question was about coalesce with nologging,
    I experienced that nologging with coalesce will create a lot of redo logs
    Thanks

  • ORACLE8I - COALESCING INDEXES

    제품 : ORACLE SERVER
    작성날짜 : 2004-08-16
    [ORACLE8I] COALESCING INDEXES
    ==============================
    PURPOSE
    이 문서는 Oracle 8i의 new feature인 coalescing indexes에 대해 기술한다.
    SCOPE
    8i~10g Standard Edition 에서는 Index coalesce 기능을 지원하지 않는다.
    Explanation
    1. Index coalesce 개관
    index fragmentation은 index rebuild나 coalesce로 조정 할 수 있다.
    Oracle 8i의 신기능가운데 index를 rebuild 하는 대신
    coalesce하는 기능이 추가되었다.
    B-tree 형태의 인덱스를 사용할 경우 free 상태가 된
    leaf block 들을 ALTER INDEX 명령의 coalesce옵션을
    사용하여 병합할 수 있다.
    2. 예제
    ALTER INDEX SCOTT.EMP_IDX COALESCE;
    ALTER INDEX 명령에서 coalesce는 병합 가능한 block중에서
    기존에 사용중이던 index block의 내용을 병합할 수 있을
    경우에만 적용된다.
    3. COALESCE 옵션의 장단점
    단점 : INDEX를 다른 tablespace로 옮길 수 없다.
    장점 : 추가 disk 공간을 필요로 하지 않는다.
    Tree의 동일한 branch상의 leaf block들만을 병합한다.
    Leaf block을 신속하게 사용가능한 상태로 만든다.
    4. REBUILD 옵션의 장단점
    단점 : 추가 disk 공간이 필요하다. (내부적으로 지정된 tablespace에
    create후 기존의 index를 drop하므로)
    기존에 사용하던 index를 사용하는 것이 아니라
    새로운 index를 생성한다.
    장점 : 인덱스를 신속하게 다른 tablespace로 옮길수 있다.
    Index를 drop시키지 않고도 storage나 tablespace관련
    parameter를 변경할 수 있다.
    Reference Ducumment
    Note:99618.1
    Oracle 8i Administrator's Guide Chapter 16

    Can you post the exact error message? I thought function-based indexes were enabled by default, but it's probably a parameter in init.ora and the error might give us a clue about which one.
    --> Steve
    (My Oracle on Linux Installation HOWTO at www.zx81.org.uk)

  • Index in Query inside Stored procedure

    How to put a index on Select query inside a stored procedure.Please help me on below to write a index
    Coalesce ((select sum (ICD.mAmount)
    from ItemCommonData ICD (Index(PK_ItemCommonData))
    Join ItemsInBundle IIBun on
    (ICD.iBundleDocId = IIBun.iBundleDocId) and
    (ICD.iDocId = IIBun.iDocId)
    Join ItemsInBlock IIB (Index(ItemsInBlockbyBlockDoc)) on
    (ICD.iDocId = IIB.iDocId)
    where (Bundles.iDocId = ICD.iBundleDocId
    and IIBun.fDeleted = False
    and IIB.iBlockId = iBlockId)),

    Are you migrating to Oracle SQL and PL/SQL?
    Anyway, you don't define an Index on the fly in Oracle. You create them ahead of time on the table. You can use hints to manipulate the query into using a certain execution path.

  • Fragmentation in tables and indexes with 9.2.0.5

    Hi guys ,
    I need of query to identified fragmentation in tables and indexes using Oracle 9i,someone could help me send that's querys
    tks
    spaulonci

    Fragmentation by itself at the tablespace level doesn't mean any thing from the performance point of view, only from the storage capacity perspective, and this just in case fragments are not necessarily the same size as in the case of dictionary manged tablespaces.
    You may be concerned about block density, which actually could lead to performance degradation. I suggest you to consider using coalesce instead of rebuilding in the case of indexes, and in the case of tables you should perform a segment reorganization. In the case of 9iR2 the coalesce command for table segments is not available so you will have to perform another segment reorganization strategy. If there are meaningful differences with the high water mark, average number of rows per block and chained rows then you will notice performance differences.
    I suggest you to take metrics for block usage prior to perform an index coalesce operation, as well as prior to perform a data segment reorganization to assess if the reorganization effort is useful.
    ~ Madrid
    http://hrivera99.blogspot.com/

  • "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>

  • Leaf nodes and Blevel in an index

    Hi,
    Can someone please clarify my doubt
    1. If there are many leaf nodes does it mean the index has undergone a lot of updates.
    2.if the blevel is greater than 4 ,does it mean the index has undergone a lot of updates and it requires rebuilding
    Please help

    Hi Steve,
    Before we start WWIII, let's make it clear that I DO NOT advocate rebuilding unless it is necessary. I charge by the hour; and I will not waste my client's money doing something that is not necessary.
    Also, note that Index rebuilding has been automated within OEM, it's right here in Oracle Magazine:
    http://www.oracle.com/technology/oramag/oracle/05-may/o35tuning.html
    Remember, there are TWO reasons for index rebuilding:
    - Saving Space -
    - Improving the performance of multi-block reads (index range scans, index FFS)
    what control do we,as mere mortals in the presence of the great and mysterious Oz-acle, have over the depth?- Rebuild the index, coalesce, shrink space, that's it. At the data block level, Oracle does not re-balance the index in real-time, it would be too time-consuming.
    what control do we have over what Oracle decides to use for depth? Well, the index blocksize makes a big difference in the number of levels, and that's one reason that some shops implement a 32k blocksize, just for indexes that experience multi-block reads:
    http://www.dba-oracle.com/t_multiple_blocksizes_summary.htm
    Steve, some people make sweeping over-generalizations (it's RARE or UNCOMMON), but that's all doo-doo. Rebuilding depends SOLELY on the volatility of your index.
    Don't trust anyone who makes statements like "It's never needed", or "you rarely rebuild indexes". Like evrything in Oracle, "it depends".
    For example, in high DML systems like Clintrial, you have to rebuild Oracle index nightly to maintain any decent performance! Other applications NEVER need index rebuilding . . . .
    It depends . . . . .
    When I charge my clients to rebuild indexes, I don't guess. I measure, test and show them proof that the rebuild reduced I/O.
    You want to see too-many-levels in an index simply insert a zillion rows in one part of the index, then delete 20% of the index in another sequence, and repeat 100 times . . . . .
    Kim Floss said it well:
    http://searchoracle.techtarget.com/generic/0,295582,sid41_gci1050448,00.html
    There are many myths and legends surrounding the use of Oracle indexes, especially the ongoing debate about rebuilding of indexes for improving performance. Some experts claim that periodic rebuilding of Oracle b-tree indexes greatly improves space usage and access speed, while other experts maintain that Oracle indexes should "rarely" be rebuilt. Interestingly, Oracle reports that the new Oracle10g Automatic Maintenance Tasks (AMT) will automatically detect indexes that are in need of re-building. Here are the pros and cons of the issue:
    Arguments for Index Rebuilding. Many Oracle shops schedule periodic index rebuilding, and report measurable speed improvements after they rebuild their Oracle b-tree indexes.
    Arguments against Index Rebuilding. Some Oracle in-house experts maintain that Oracle indexes are super-efficient at space re-use and access speed and that a b-tree index rarely needs rebuilding. They claim that a reduction in Logical I/O should be measurable, and if there were any benefit to index rebuilding, someone would have come up with "provable" rules.
    She goes on to note some index rebuilding criteria:
    "The short answer is no, there is no 100% complete, definitive list. But, here are some things to start with:
    - Index levels > 3
    - Pct_used < 75%
    - More than 20% of the rows have been deleted (space is not automatically reused)
    - Index is becoming unclustered, and performance is degrading (causing increases in number of blocks to be read) – while unloading, resorting, and reloading the data in a table may provide better performance, this is an additional maintenance activity that needs to be performed, and can be difficult to keep the rows in their proper sequence, if the table gets a lot of insert/update/delete activity. "

  • How to find fragmentation in INDEX segments

    Dear All,
    Please tell me the solution for how to find fragmentation in index segments.
    Waiting for your reply.
    Regards,
    .......................

    To minimize tablespace fragmentation is to use Locally Managed Uniform Sized Tablespaces. With Oracle 10g, even your system tablespace can now be LMT.
    The best way to remove fragmentation of a table or index is to re-create or rebuild it. The same can be accomplosihed this is to use the ALTER TABLE MOVE and ALTER INDEX REBUILD statements.
    Alter Table Tab1 move tablespace NEW_LMT_TS;
    Alter Index Ind1 rebuild tablespace NEW_LMT_TS;
    Even with LMT, indexes can sometimes become fragmented over time due to inserts and deletes of rows in the index leaf pages.
    Run an analyze index validate structure on your indexes.
    Query the index_stats table. If the percentage of deleted leaf rows to total leaf rows (DEL_LF_ROWS/LF_ROWS) is greater than 20%; then, the index probably should be rebuilt. but sometimes these may be a wrong.
    How to remove index fragmentation?
    There are two way to remove fragmentation.
    1. index coalesce
    2. index rebuild

  • Indexes stats have no data

    Hi,
    I have following settings in a database
    How to interpret this info regarding INDEX:
    SQL> select * from index_stats
    no rows selected
    statistics_level                     string      TYPICAL
    timed_os_statistics                  integer     0
    timed_statistics                     boolean     TRUE
    db_block_size                        integer     8192
    10g Enterprise Edition Release 10.2.0.2.0 - 64biindex good / fragmented /or ..
    Thanks a ton

    Hi,
    shall i rebuild this index or not...When done properly, rebuilding or coaleseing an index is 100% safe.
    Have you considered an index coalesce instead?
    But first, what is your motive?
    - To reclaim disk space after a major delete?
    - To improve performance?
    - Some other reason?
    Please read this carefully, it explains the issues:
    http://www.dba-oracle.com/t_index_rebuilding_issues.htm
    Article is talking about index_statsYes, index_stats collects addiitonal details about an index when using the validate index command.
    This is used mostly for justifying an index rebuild, and it's dangerous because it consumes mucho resources and may cause lock issues . . .
    BTW, that link is just part one of a 4 part series, make sure to read the other parts:
    http://jonathanlewis.wordpress.com/2009/09/15/index-explosion-4/#comment-34512
    Hope this helps . . .
    Donald K. Burleson
    Oracle Press author
    Author of "Oracle Tuning: The Definitive Reference"
    http://www.rampant-books.com/t_oracle_tuning_book.htm
    "Time flies like an arrow; Fruit flies like a banana".

  • Oracle Versions Related Queries

    Partiton,Parallel DML,Parallel Query is used in Oracle 9i Enterprise Edition.
    Can Partiton,Parallel DML,Parallel Query be used in Oracle 9i Standard Edition???
    I have a requirement where I have to use Oracle 9i Standard Edition and I want the features of Partiton,Parallel DML,Parallel Query to incorporate in the Standard Edition.
    Can Anyone help the Usage Difference between Oracle 9i Standard Edition and
    Oracle 9i Enterprise Edition.
    Regards

    Thanks friend for the input.
    I have a query where i have to use Oracle 9i Standard Edition and whether i can incorporate the substitutional features of Oracle 9i Enterprise Edition.
    The below features are not supported in Oracle 9i Standard Edition:
    Oracle Partitioning
    Oracle OLAP
    Oracle data Guard
    Online Index Build
    Online index Coalesce
    Oracle real application clusters
    Virtual Private database
    Fine Grain Auditing
    Duplexed Backup Sets
    Database Resource Manager
    Oracle Data Mining
    Bitmapped Index and Bitmapped Join Index
    Parallel DML
    Parallel Query
    Export/import Transportable Tablespace
    Can you please guide me in place of above non-featured in Oracle 9i Standard Edition what features i can incorporate to use for benefitial in Application Design,Storage/Size,Performance.
    Regards

  • Pausing the Shrink Command

    Hello ALL,
    We have recently purged some of the data on a huge table and right now the unused space is upto 350 GB. We need to reclaim the space.It's a 10 G database. But, since it's a resource intensive operation we have a requirement from the business that it should be stopped at the start of business day and commence it at the EOB.
    Do you think we should kill the Shrinking operation at the EOB. does Oracle satrt the Shrinking operation where it stopped from.
    P.S. this table has all LOB columns, LONG type columns. so, there is no possibility of expdp/MOVE.
    Please throw your valuable inputs.
    Thanks,

    790658 wrote:
    Hello ALL,
    We have recently purged some of the data on a huge table and right now the unused space is upto 350 GB. We need to reclaim the space.It's a 10 G database. But, since it's a resource intensive operation we have a requirement from the business that it should be stopped at the start of business day and commence it at the EOB.
    Do you think we should kill the Shrinking operation at the EOB. does Oracle satrt the Shrinking operation where it stopped from.
    P.S. this table has all LOB columns, LONG type columns. so, there is no possibility of expdp/MOVE.
    I thought that the shrink command was executed as a series of fairly small transactions - similar to the "index coalesce" mechanism.
    I've just checked on a test I created some time ago, though, and in 11.1.0.6 I found that when the shrink command had to move 5,000,000 rows it ran the entire command as a single large transaction (500MB of undo, 1.1GB of redo).
    This makes it look as if you cannot interrupt a shrink command - and if you did then you could have a massive rollback running for ages.
    Have you looked at the dbms_redefinition package as an alternative.
    Regards
    Jonathan Lewis

  • Coalesce or compress this index? what is the best solution in this case?

    BANNER
    Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64biI have executed the following query on a specific index that I suspected to be smashed and got the following result
    select
        keys_per_leaf, count(*) blocks
    from (  
          select   sys_op_lbid (154813, 'L', jus.rowid) block_id,
                 count (*)                            keys_per_leaf
          from xxx_table jus
           where jus.id is not null
                  or jus.dat is not null
          group by sys_op_lbid (154813, 'L', jus.rowid)
    group by keys_per_leaf
    order by keys_per_leaf;
    keys_per_leaf     blocks 
    1     80       
    2     1108       
    3     2816       
    4     3444       
    5     3512       
    6     2891       
    7     2579       
    8     2154       
    9     1943       
    10     1287       
    11     1222       
    12     1011       
    13     822       
    14     711       
    15     544       
    16     508       
    17     414       
    18     455       
    19     425       
    20     417       
    21     338       
    22     337       
    23     327       
    24     288       
    25     267       
    26     295       
    27     281       
    28     266       
    29     249       
    30     255       
    31     237       
    32     259       
    33     257       
    34     232       
    35     211       
    36     209       
    37     204       
    38     216       
    39     189       
    40     194       
    41     187       
    42     200       
    43     183       
    44     167       
    45     186       
    46     179       
    47     179       
    48     179       
    49     171       
    50     164       
    51     174       
    52     157       
    53     181       
    54     192       
    55     178       
    56     162       
    57     155       
    58     160       
    59     153       
    60     151       
    61     133       
    62     177       
    63     156       
    64     167       
    65     162       
    66     171       
    67     154       
    68     162       
    69     163       
    70     153       
    71     189       
    72     166       
    73     164       
    74     142       
    75     177       
    76     148       
    77     161       
    78     164       
    79     133       
    80     158       
    81     176       
    82     189       
    83     347       
    84     369       
    85     239       
    86     239       
    87     224       
    88     227       
    89     214       
    90     190       
    91     230       
    92     229       
    93     377       
    94     276       
    95     196       
    96     218       
    97     217       
    98     227       
    99     230       
    100     251       
    101     266       
    102     298       
    103     276       
    104     288       
    105     638       
    106     1134       
    107     1152     
    229     1       
    230     1      This is a 5 columns unique key index on (id number, dat date, id2 number, dat2 date type number).
    Furthermore, a space analysis of this index using dbms_space.space_usage gives the following picture
    Number of blocks with at least 0 to 25% free space            = 0                   -------> total bytes = 0
    Number of blocks with at least 25-50% free space              = 75                 -------> total bytes = ,5859375
    Number of Blocks with with at least 50 to 75% free space  = 0                   -------> Total Bytes = 0
    number of blocks with at least 75 to 100% free space        = 0                   -------> total bytes = 0
    Number of full blocks with no free space                              = 99848           -------> total bytes = 780,0625
    Total blocks ______________________________
    99923
    Total size MB______________________________
    799,384It seems for me that this index needs to be either coalesced or compressed.
    Then, what would be the best option in your opinion?
    Thanks in advance
    Mohamed Houri
    Edited by: Mohamed Houri on 12-janv.-2011 1:18

    So let me continue my case
    I first compressed the index as follows
    alter index my_index rebuild compress 2;which immediately presents two new situations
    (a) index space
    Number of blocks with at least 0 to 25% free space    = 0                -------> total bytes = 0
    Number of blocks with at least 25-50% free space      = 40              -------> total bytes =, 3125
    Number of Blocks with at least 50 to 75% free space   = 0                -------> total Bytes = 0
    Number of blocks with at least 75 to 100% free space  = 0                -------> total bytes = 0
    Number of full blocks with no free space                = 32361           -------> total bytes = 252, 8203125
    Total blocks ______________________________
    32401
    Total size Mb______________________________
    259,208meaning that the compress command freed up 67487 leaf blocks and reduced the size of the index from to 799,384 MB to 259,208 MB.
    It also shows a relative nice pictue of number of keys per leaf block (when compared to the previous situation)
    (b) on the number of key per leaf block
    KEYS_PER_LEAF     BLOCKS       
    4     1       
    6     1       
    13     1       
    15     1       
    25     1       
    62     1       
    63     1       
    88     1       
    97     1       
    122     1       
    123     3       
    124     6       
    125     4       
    126     2     
    289     4489       
    290     3887       
    291     3129       
    292     2273       
    293     1528       
    294     913       
    295     442       
    296     152       
    297     50       
    298     7       
    299     1      In a second step, I have coalesced the index as follows
    alter index my_index coalesce;which produces the new figure
    Number of blocks with at least 0 to 25% free space     = 0          -------> total bytes = 0
    Number of blocks with at least 25-50% free space      = 298        -------> total bytes = 2,328125
    Number of Blocks with at least 50 to 75% free space   = 0           -------> Total Bytes = 0
    Number of blocks with at least 75 to 100% free space = 0            -------> total bytes = 0
    Number of full blocks with no free space = 32375                    -------> total bytes = 252, 9296875
    Total blocks ______________________________
    32673
    Total size MB______________________________
    261,384meaning the the coalesce command has made
    (a)     298-40 = 258 new blocks with 25-50% of free space
    (b)     32375-32361 = 14 new additional blocks which have been made full
    (c)     The size of the index increased by 2,176MB (261,384-259,208)
    While the number of key per leaf block keeps in the same situation
    KEYS_PER_LEAF     BLOCKS       
    4     2       
    5     3       
    9     1       
    10     2       
    12     1       
    13     1       
    19     1       
    31     1       
    37     1       
    61     1       
    63     1       
    73     1       
    85     1       
    88     1       
    122     1       
    123     4       
    124     4       
    125     3       
    126     1     
    289     4492       
    290     3887       
    291     3125       
    292     2273       
    293     1525       
    294     913       
    295     441       
    296     152       
    297     50       
    298     7       
    299     1      Could you please through some light on the difference between the compress and the coalesce on the effect they have made on
    (a) the number of keys per leaf blocks within my index
    (b) the space and size of my index?
    Best regards
    Mohamed Houri

  • 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

  • Performance Problems - Index and Statistics

    Dear Gurus,
    I am having problems lossing indexes and statistics on cubes ,it seems my indexes are too old which in fact are not too old just created a month back and we check indexes daily and it returns us RED on the manage TAB.
    please help

    Dear Mr Syed ,
    Solution steps I mentioned in my previous reply itself explains so called RE-ORG of tables;however to clarify more on that issue.
    Occasionally,ORACLE <b>Cost-Based Optimizer</b> may calculate the estimated costs for a Full Table Scan lower than those for an Index Scan, although the actual runtime of an access via an index would be considerably lower than the runtime of the Full Table Scan,Some Imperative points to be considered in order to perk up the performance and improve on quandary areas such as extensive running times for Change runs & Aggregate activate & fill ups.
    Performance problems based on a wrong optimizer decision would show that there is something serious missing at Database level and we need to RE_ORG  the degenerated indexes in order to perk up the overall performance and avoid daily manual (RSRV+RSNAORA)activities on almost similar indexes.
    For <b>Re-organizing</b> degenerated indexes 3 options are available-
    <b>1) DROP INDEX ..., and CREATE INDEX …</b>
    <b>2)ALTER INDEX <index name> REBUILD (ONLINE PARALLEL x NOLOGGING)</b>
    <b>3) ALTER INDEX <index name> COALESCE [as of Oracle 8i (8.1) only]</b>
    Each option has its Pros & Cons ,option <b>2</b> seems to be having lot of advantages to
    <b>Advantages- option 2</b>
    1)Fast storage in a different table space possible
    2)Creates a new index tree
    3)Gives the option to change storage parameters without deleting the index
    4)As of Oracle 8i (8.1), you can avoid a lock on the table by specifying the ONLINE option. In this case, Oracle waits until the resource has been released, and then starts the rebuild. The "resource busy" error no longer occurs.
    I would still leave the Database tech team be the best to judge and take a call on these.
    These modus operandi could be institutionalized  for all fretful cubes & its indexes as well.
    However,I leave the thoughts with you.
    Hope it Helps
    Chetan
    @CP..

  • How to get the columns from SYS.ALL_COLUMNS and use it in COALESCE() Function.

    Hi,
    I have table called Employe. And the Columns are Emp_ID,EMP_NAME,SRC_SYS_CD,DOB
    I have Query like
    Select
    COALESCE(MAX(CASE WHEN src_sys_cd='1' THEN Emp_id END), MAX(CASE WHEN src_sys_cd='2' THEN Emp_Id END))Emp_Id,
    COALESCE(MAX(CASE WHEN src_sys_cd='1' THEN Emp_name END), MAX(CASE WHEN src_sys_cd='2' THEN Emp_Name END))Emp_name,
    COALESCE(MAX(CASE WHEN src_sys_cd='1' THEN dob END), MAX(CASE WHEN src_sys_cd='2' THEN dob END))dob ,
    from Employe
    group by dob.
    I want to generalize the query like get the columns from SYS.ALL_COLUMNS table for that table name and want to pass it to COALEACE() function. I tried with Cursor. But i didnt get the appropriate results.
    Is there any way to achieve this? Please help me out in this regard.
    Thanks,

    Is this the kinda thing you're after?
    Add a filter to the queries to get just a single table/
    WITH allCols AS (
    SELECT s.name as sName, o.name AS oName, c.name AS cName, column_id,
    CASE WHEN st.name in ('float','bigint','tinyint','int','smallint','bit','datetime','money','date','datetime2','uniqueidentifier','sysname','geography','geometry') THEN st.name
    WHEN st.name in ('numeric','real') THEN st.name + '('+CAST(c.scale AS VARCHAR)+','+CAST(c.precision AS VARCHAR)+')'
    WHEN st.name in ('varbinary','varchar','binary','char','nchar','nvarchar') THEN st.name + '(' + CAST(ABS(c.max_length) AS VARCHAR) + ')'
    ELSE st.name + ' unknown '
    END + ' '+
    CASE WHEN c.is_identity = 1 THEN 'IDENTITY ' ELSE '' END +
    CASE WHEN c.is_nullable = 0 THEN 'NOT ' ELSE '' END + 'NULL' AS bText,
    f.name AS fileGroupName
    FROM sys.columns c
    INNER JOIN sys.objects o
    ON c.object_id = o.object_id
    AND o.type = 'U'
    INNER JOIN sys.systypes st
    ON c.user_type_id = st.xusertype
    INNER JOIN sys.schemas s
    ON o.schema_id = s.schema_id
    INNER JOIN sys.indexes i
    ON o.object_id = i.object_id
    AND i.index_id = (SELECT MIN(index_id) FROM sys.indexes WHERE object_ID = o.object_id)
    INNER JOIN sys.filegroups f
    ON i.data_space_id = f.data_space_id
    ), rCTE AS (
    SELECT sName, oName, cName, column_id, CAST(cName + ' ' + bText AS VARCHAR(MAX)) as bText, CAST(cName AS VARCHAR(MAX)) AS colList, fileGroupName
    FROM allCols
    WHERE column_id = 1
    UNION ALL
    SELECT r.sName, r.oName, r.cName, c.column_id, CAST(r.bText +', ' + c.cName + ' ' +c.bText AS VARCHAR(MAX)), CAST(r.colList+ ', ' +c.cName AS VARCHAR(MAX)), c.fileGroupName
    FROM allCols c
    INNER JOIN rCTE r
    ON c.oName = r.oName
    AND c.column_id - 1 = r.column_id
    ), allIndx AS (
    SELECT 'CREATE '+CASE WHEN is_unique = 1 THEN ' UNIQUE ' ELSE '' END+i.type_desc+' INDEX ['+i.name+'] ON ['+CAST(s.name COLLATE DATABASE_DEFAULT AS NVARCHAR )+'].['+o.name+'] (' as prefix,
    CASE WHEN is_included_column = 0 THEN '['+c.name+'] '+CASE WHEN ic.is_descending_key = 1 THEN 'DESC' ELSE 'ASC' END END As cols,
    CASE WHEN is_included_column = 1 THEN '['+c.name+']'END As incCols,
    ') WITH ('+
    CASE WHEN is_padded = 0 THEN 'PAD_INDEX = OFF,' ELSE 'PAD_INDEX = ON,' END+
    CASE WHEN ignore_dup_key = 0 THEN 'IGNORE_DUP_KEY = OFF,' ELSE 'IGNORE_DUP_KEY = ON,' END+
    CASE WHEN allow_row_locks = 0 THEN 'ALLOW_ROW_LOCKS = OFF,' ELSE 'ALLOW_ROW_LOCKS = ON,' END+
    CASE WHEN allow_page_locks = 0 THEN 'ALLOW_PAGE_LOCKS = OFF' ELSE 'ALLOW_PAGE_LOCKS = ON' END+
    ')' as suffix, index_column_id, key_ordinal, f.name as fileGroupName
    FROM sys.indexes i
    LEFT OUTER JOIN sys.index_columns ic
    ON i.object_id = ic.object_id
    AND i.index_id = ic.index_id
    LEFT OUTER JOIN sys.columns c
    ON ic.object_id = c.object_id
    AND ic.column_id = c.column_id
    INNER JOIN sys.objects o
    ON i.object_id = o.object_id
    AND o.type = 'U'
    AND i.type <> 0
    INNER JOIN sys.schemas s
    ON o.schema_id = s.schema_id
    INNER JOIN sys.filegroups f
    ON i.data_space_id = f.data_space_id
    ), idxrCTE AS (
    SELECT r.prefix, CAST(r.cols AS NVARCHAR(MAX)) AS cols, CAST(r.incCols AS NVARCHAR(MAX)) AS incCols, r.suffix, r.index_column_id, r.key_ordinal, fileGroupName
    FROM allIndx r
    WHERE index_column_id = 1
    UNION ALL
    SELECT o.prefix, COALESCE(r.cols,'') + COALESCE(', '+o.cols,''), COALESCE(r.incCols+', ','') + o.incCols, o.suffix, o.index_column_id, o.key_ordinal, o.fileGroupName
    FROM allIndx o
    INNER JOIN idxrCTE r
    ON o.prefix = r.prefix
    AND o.index_column_id - 1 = r.index_column_id
    SELECT 'CREATE TABLE ['+sName+'].[' + oName + '] ('+bText+') ON [' + fileGroupName +']'
    FROM rCTE r
    WHERE column_id = (SELECT MAX(column_id) FROM rCTE WHERE r.oName = oName)
    UNION ALL
    SELECT prefix + cols + CASE WHEN incCols IS NOT NULL THEN ') INCLUDE ('+incCols ELSE '' END + suffix+' ON [' + fileGroupName +']'
    FROM idxrCTE x
    WHERE index_column_id = (SELECT MAX(index_column_id) FROM idxrCTE WHERE x.prefix = prefix)

Maybe you are looking for

  • Where can I buy a iPhone 4s car charger at Bangalore

    Where can I buy a car charger for iPhone 4s charger at Bangalore and how much does it cost

  • App World Errors

    Hello! I'm not English, but I can't find any solutions for this problem in other sites. So, certainly I will do a lot of mistakes, but don't worry about it.  Anyway, I have a BlackBerry Curve 8520 that can't connect to the App World and I don't know

  • How to Add Stamp in to Pdf..

    hi i'm new to Acrobat scripting. colud please help me in this regrad.. How to add Stamp to Pdf and Review Status is Completed & stamp color changed to red.. Thanks in Advance.. - yajiv

  • Urgent!Help! about PoolMan

    Hi, experts, I am trying to create two conneciton pool, but it seems only the first one is working. I always get null from the second connection pool. SQLManager sqlManager1 =SQLManager.getInstance(properties1); SQLManager sqlManager2 =SQLManager.get

  • Error Invalid field format (screen error) in module pool

    Hi experts i am doing module in whichi had many check boxes on screen and each check box has function code means i want to do some thing else . but as i click the first or any other check box i get a error message INVALID FIELD FORMAT (SCREEN ERROR).