Update table .... indexes ?

I am attempting to update , because of the addition of a new attribute, a table with about 13mil records. There is a primary key which is a combination of two attributes. The primary key combination forms the unique index on the table which is the only index on the table. Do I need to drop the indexes before I run the update? I have a very small load window to work in.. How should I proceed ?
TIA

You should specify the Oracle version you are currently working with. But in general terms you cannot drop an index associated with a primary key, unless you disable the primary key, and depending on the version you may or may not leave the index.
Adding an attribute, it is not a quite clear operation, are you adding a column to the table? Also, there were differences.
Please provide further details.
~ Madrid
http://hrivera99.blogstpot.com

Similar Messages

To Use Cursor or TYPE table Index by PLS_integer

Hi All,
Let's see if I have table with no. of records 19,26,20,000.
If I want to loop through all the records which will be a optimized way To Use Cursor or TYPE table Index by PLS_integer.
Please guide.
Thanks.

What is it you want to do to/with the rows you're looping through?
Ideally you want to avoid looping, as that's row by row (aka slow by slow) processing and it's expensive time-wise.
If you're doing DML (insert/update/delete) then you're best off doing it in one sql statement, rather than looping.

Creating a better update table statement

Hello,
I have the following update table statement that I would like to make more effecient. This thing is taking forever. A little background. The source table/views are not indexed and the larger of the two only has 150k records. Any ideas on making more effecient would be appreciate.
Thanks.
Ryan
Script:
DECLARE
V_EID_CIV_ID SBI_EID_W_VALID_ANUM_V.SUBJECT_KEY%TYPE;
V_EID_DOE     DATE;
V_EID_POE     SBI_EID_W_VALID_ANUM_V.POINT_OF_ENTRY%TYPE;
V_EID_APPR_DATE DATE;
V_CASE_CIV_ID     SBI_DACS_CASE_RECORDS.CASE_EID_CIV_ID%TYPE;
V_CASE_DOE     DATE;
V_CASE_POE SBI_DACS_CASE_RECORDS.CASE_CODE_ENTRY_PLACE%TYPE;
V_CASE_APPR_DATE           DATE;
V_CASE_DEPART_DATE           DATE;
V_SBI_UPDATE_STEP SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP%TYPE;
V_SBI_CIV_ID SBI_DACS_CASE_RECORDS.SBI_CIV_ID%TYPE;
CURSOR VALID_CIV_ID_FROM_EID IS
     SELECT EID.SUBJECT_KEY,
          TO_DATE(EID.PROCESS_ENTRY_DATE),
          EID.POINT_OF_ENTRY,
          TO_DATE(EID.APPREHENSION_DATE),
          DACS.CASE_EID_CIV_ID,
          TO_DATE(DACS.CASE_DATE_OF_ENTRY,'YYYYMMDD'),
          DACS.CASE_CODE_ENTRY_PLACE,
          TO_DATE(DACS.CASE_DATE_APPR,'YYYYMMDD'),
          TO_DATE(DACS.CASE_DATE_DEPARTED,'YYYYMMDD'),
          DACS.SBI_UPDATE_STEP,
          DACS.SBI_CIV_ID
     FROM SBI_EID_W_VALID_ANUM_V EID,
SBI_DACS_CASE_RECORDS DACS
WHERE DACS.CASE_NBR_A = EID.ALIEN_FILE_NUMBER;
     BEGIN
          OPEN VALID_CIV_ID_FROM_EID;
SAVEPOINT A;
          LOOP
               FETCH VALID_CIV_ID_FROM_EID INTO V_EID_CIV_ID, V_EID_DOE, V_EID_POE,V_EID_APPR_DATE,V_CASE_CIV_ID, V_CASE_DOE,V_CASE_POE,V_CASE_APPR_DATE,V_CASE_DEPART_DATE,V_SBI_UPDATE_STEP,V_SBI_CIV_ID;
DBMS_OUTPUT.PUT_LINE('BEFORE');
               EXIT WHEN VALID_CIV_ID_FROM_EID%FOUND;
DBMS_OUTPUT.PUT_LINE('AFTER');
          UPDATE SBI_DACS_CASE_RECORDS
SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_CASE_CIV_ID,
               SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 1
WHERE V_CASE_CIV_ID IS NOT NULL
AND V_CASE_CIV_ID <> 0;
UPDATE SBI_DACS_CASE_RECORDS
          SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
               SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 2
WHERE V_SBI_CIV_ID IS NULL AND V_SBI_UPDATE_STEP = 0
               AND V_EID_DOE = V_CASE_DOE
               AND V_EID_POE = V_CASE_POE
               AND V_EID_APPR_DATE = V_CASE_APPR_DATE
               AND V_EID_APPR_DATE = V_CASE_DEPART_DATE;
               UPDATE SBI_DACS_CASE_RECORDS
          SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
               SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 3
WHERE V_SBI_UPDATE_STEP = 0
               AND V_EID_DOE = V_CASE_DOE
               AND V_EID_POE = V_CASE_POE
               AND V_EID_APPR_DATE = V_CASE_APPR_DATE;
UPDATE SBI_DACS_CASE_RECORDS
          SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
               SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 4
WHERE V_SBI_UPDATE_STEP = 0
               AND V_EID_DOE = V_CASE_DOE
               AND V_EID_POE = V_CASE_POE
               AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) > -4
               AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) < 4 ;
     UPDATE SBI_DACS_CASE_RECORDS
          SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
               SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 5
WHERE V_SBI_UPDATE_STEP = 0
               AND V_EID_DOE = V_CASE_DOE
               AND V_EID_POE <> V_CASE_POE
               AND V_EID_APPR_DATE = V_CASE_APPR_DATE;
UPDATE SBI_DACS_CASE_RECORDS
          SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
               SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 6
WHERE V_SBI_UPDATE_STEP = 0
               AND V_EID_POE = V_CASE_POE
               AND V_EID_APPR_DATE = V_CASE_APPR_DATE;
UPDATE SBI_DACS_CASE_RECORDS
          SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
               SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 7
WHERE V_SBI_UPDATE_STEP = 0
     AND V_EID_APPR_DATE = V_CASE_APPR_DATE;
          UPDATE SBI_DACS_CASE_RECORDS
          SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
               SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 8
WHERE V_SBI_UPDATE_STEP = 0
AND V_EID_DOE = V_CASE_DOE
               AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) > -4
               AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) < 4;
               UPDATE SBI_DACS_CASE_RECORDS
          SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
               SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 9
WHERE V_SBI_UPDATE_STEP = 0
AND V_EID_DOE = V_CASE_DOE
               AND V_EID_POE = V_CASE_POE;
          UPDATE SBI_DACS_CASE_RECORDS
          SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
               SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 10
WHERE V_SBI_UPDATE_STEP = 0
AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) > -4
               AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) < 4;
          END LOOP;
          CLOSE VALID_CIV_ID_FROM_EID;
     COMMIT;
     END;
-----Thats it. Thanks for your help.
Ryan

Please use [ code] or [ pre] tags to format code before posing:
DECLARE
     V_EID_CIV_ID SBI_EID_W_VALID_ANUM_V.SUBJECT_KEY%TYPE;
     V_EID_DOE DATE;
     V_EID_POE SBI_EID_W_VALID_ANUM_V.POINT_OF_ENTRY%TYPE;
     V_EID_APPR_DATE DATE;
     V_CASE_CIV_ID SBI_DACS_CASE_RECORDS.CASE_EID_CIV_ID%TYPE;
     V_CASE_DOE DATE;
     V_CASE_POE SBI_DACS_CASE_RECORDS.CASE_CODE_ENTRY_PLACE%TYPE;
     V_CASE_APPR_DATE DATE;
     V_CASE_DEPART_DATE DATE;
     V_SBI_UPDATE_STEP SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP%TYPE;
     V_SBI_CIV_ID SBI_DACS_CASE_RECORDS.SBI_CIV_ID%TYPE;
     CURSOR VALID_CIV_ID_FROM_EID IS
          SELECT EID.SUBJECT_KEY,
           TO_DATE(EID.PROCESS_ENTRY_DATE),
           EID.POINT_OF_ENTRY,
           TO_DATE(EID.APPREHENSION_DATE),
           DACS.CASE_EID_CIV_ID,
           TO_DATE(DACS.CASE_DATE_OF_ENTRY,'YYYYMMDD'),
           DACS.CASE_CODE_ENTRY_PLACE,
           TO_DATE(DACS.CASE_DATE_APPR,'YYYYMMDD'),
           TO_DATE(DACS.CASE_DATE_DEPARTED,'YYYYMMDD'),
           DACS.SBI_UPDATE_STEP,
           DACS.SBI_CIV_ID
          FROM SBI_EID_W_VALID_ANUM_V EID,
           SBI_DACS_CASE_RECORDS DACS
          WHERE DACS.CASE_NBR_A = EID.ALIEN_FILE_NUMBER;
BEGIN
     OPEN VALID_CIV_ID_FROM_EID;
     SAVEPOINT A;
LOOP
     FETCH VALID_CIV_ID_FROM_EID INTO V_EID_CIV_ID, V_EID_DOE,
          V_EID_POE,V_EID_APPR_DATE,V_CASE_CIV_ID, V_CASE_DOE,
               V_CASE_POE,V_CASE_APPR_DATE,V_CASE_DEPART_DATE,V_SBI_UPDATE_STEP,V_SBI_CIV_ID;
     DBMS_OUTPUT.PUT_LINE('BEFORE');
     EXIT WHEN VALID_CIV_ID_FROM_EID%FOUND;
     DBMS_OUTPUT.PUT_LINE('AFTER');
     UPDATE SBI_DACS_CASE_RECORDS
      SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_CASE_CIV_ID,
       SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 1
     WHERE V_CASE_CIV_ID IS NOT NULL
      AND V_CASE_CIV_ID <> 0;
     UPDATE SBI_DACS_CASE_RECORDS
      SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
       SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 2
     WHERE V_SBI_CIV_ID IS NULL AND V_SBI_UPDATE_STEP = 0
      AND V_EID_DOE = V_CASE_DOE
       AND V_EID_POE = V_CASE_POE
        AND V_EID_APPR_DATE = V_CASE_APPR_DATE
         AND V_EID_APPR_DATE = V_CASE_DEPART_DATE;
     UPDATE SBI_DACS_CASE_RECORDS
      SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
       SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 3
     WHERE V_SBI_UPDATE_STEP = 0
      AND V_EID_DOE = V_CASE_DOE
       AND V_EID_POE = V_CASE_POE
        AND V_EID_APPR_DATE = V_CASE_APPR_DATE;
     UPDATE SBI_DACS_CASE_RECORDS
      SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
       SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 4
     WHERE V_SBI_UPDATE_STEP = 0
      AND V_EID_DOE = V_CASE_DOE
       AND V_EID_POE = V_CASE_POE
        AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) > -4
         AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) < 4 ;
     UPDATE SBI_DACS_CASE_RECORDS
      SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
       SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 5
     WHERE V_SBI_UPDATE_STEP = 0
      AND V_EID_DOE = V_CASE_DOE
       AND V_EID_POE <> V_CASE_POE
        AND V_EID_APPR_DATE = V_CASE_APPR_DATE;
     UPDATE SBI_DACS_CASE_RECORDS
      SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
       SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 6
     WHERE V_SBI_UPDATE_STEP = 0
      AND V_EID_POE = V_CASE_POE
       AND V_EID_APPR_DATE = V_CASE_APPR_DATE;
     UPDATE SBI_DACS_CASE_RECORDS
      SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
       SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 7
     WHERE V_SBI_UPDATE_STEP = 0
      AND V_EID_APPR_DATE = V_CASE_APPR_DATE;
     UPDATE SBI_DACS_CASE_RECORDS
      SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
       SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 8
     WHERE V_SBI_UPDATE_STEP = 0
      AND V_EID_DOE = V_CASE_DOE
       AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) > -4
        AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) < 4;
     UPDATE SBI_DACS_CASE_RECORDS
      SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
       SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 9
     WHERE V_SBI_UPDATE_STEP = 0
      AND V_EID_DOE = V_CASE_DOE
       AND V_EID_POE = V_CASE_POE;
     UPDATE SBI_DACS_CASE_RECORDS
      SET SBI_DACS_CASE_RECORDS.SBI_CIV_ID = V_EID_CIV_ID,
       SBI_DACS_CASE_RECORDS.SBI_UPDATE_STEP = 10
     WHERE V_SBI_UPDATE_STEP = 0
      AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) > -4
       AND (V_EID_APPR_DATE - V_CASE_APPR_DATE) < 4;
END LOOP;
CLOSE VALID_CIV_ID_FROM_EID;
COMMIT;
END;Peter D.

Oracle Table Indexes

Hello.
I'm in the process of putting some indexes on tables for performance improvement of queries run.
eg the foll query -
SELECT MPH_ENTITY_ID, MPH_PRICE_DT, MPH_STCK_EXCHNG_ID, BPT_BP_SHRT_NM, MPH_SEC_ID, SEC_SEC_NM, NMS_SEC_NUM, MPH_PRICE_TYP, MPH_MKT_PRC, MPH_VENDOR, MPH_PRICE_TIME, MPH_EXCHNG_RATE, MPH_DENOM_UNIT, MPH_LOCL_CNC_EQVU, MPH_INDCTV_PRC_IND, MPH_VLM_TRDD, MPH_MRKT_CPTL, MPH_MKT_PRICE_HSTRY_VER, BPT_BSNS_PRTNR_VER, SEC_SEC_MASTER_VER FROM MPH_MKT_PRICE_HSTRY left outer join NMS_NUM_SCHEME on NMS_SEC_ID=MPH_SEC_ID AND NMS_NUM_SCHM='CUSIP',BPT_BSNS_PRTNR,SEC_SEC_MASTER WHERE MPH_ENTITY_ID=BPT_ENTITY_ID AND MPH_STCK_EXCHNG_ID=BPT_BP_ID AND MPH_SEC_ID=SEC_SEC_ID ORDER BY MPH_SEC_ID DESC
The Explain plan in PL/SQL developer shows "Table Access Full" scan for 2 tables - BPT_BSNS_PRTNR AND MPH_MKT_PRICE_HSTRY.
I created the foll 2 indexes and now the explain plan shows "index fast full" scan on these tables -
1) create index mph_3 on mph_mkt_price_hstry(MPH_ENTITY_ID, MPH_PRICE_DT, MPH_STCK_EXCHNG_ID, MPH_SEC_ID, MPH_PRICE_TYP, MPH_MKT_PRC, MPH_VENDOR, MPH_PRICE_TIME, MPH_EXCHNG_RATE, MPH_DENOM_UNIT, MPH_LOCL_CNC_EQVU, MPH_INDCTV_PRC_IND, MPH_VLM_TRDD, MPH_MRKT_CPTL, MPH_MKT_PRICE_HSTRY_VER);
2) create index BPT_8 on bpt_bsns_prtnr(BPT_BP_SHRT_NM,BPT_BSNS_PRTNR_VER,BPT_ENTITY_ID,BPT_BP_ID);
My question here is that I have included columns in the select clause also in the indexes and the scan type has improved from table access full to index fast full scan. Is this correct ? Should select columns be also a part of indexes ? My take was that indexes contain columns in "where" clause or columns where joins are implemented and not select columns.
Please suggest.

An Index that includes all the columns of the SELECT clause with those of the WHERE clause is a "skinny table".
Using such an Index avoids accesses to the table entirely.
There are situations where the DBA or Designer may choose to create such an Index.
Downsides ?*
If there are too many columns in the Index, the Index itself may become too large. When the index is too large for Oracle to be able to cache blocks, Oracle may have to undertake multiple single block read calls to the OS if accessing many rows. This can make the index counter-productive.
Index maintenance overheads increase -- the probability that the index also has to be updated with every UPDATE statement on the table increases. Also, every INSERT and DELETE makes that much more effort updating the Index Leaf Blocks (ie the size of the update to the Index is larger, the Index Key being larger).
Some queries might be executed using Skip Scan Search of the index when, properly, it might have made more sense to put those query columns in a seperate index.

Group by in update and index

Hi All,
I was trying to run an update SQL statement as follows:
update tableA a set a.foo =
(select b.foo
from another_schema.tableB b
where b.bar = a.bar
group by b.bar,b.foo);
I have an index in tableA on the bar column (it is a number(10,0) type column), also in tableB there
are no more then 3 rows per unique bar column value. The update was taking more then 10 minutes (tableA has around 208K rows and tableB around 212K rows). I went into Enterprise Manager and looked at the performance analysis and run the Oracle advisor that recommended to create an index on tableB containing two segments bar,foo. I added this index and the update took 13 seconds. Why did this index help if oracle does the join first it only has to group up to 3 rows at a time also notice the there are only around 1000 joined rows where such case happens. Can someone explain this ?
thanks
Tal

Why do you use "group by" when you don't use an aggregate-function ?

SAP Table index size is greater than the size of the actual table

Hello Experts,
We are resolving an issue related to database performance. The present database size is 9 Terabytes. The analysis of response times through ST03N shows that the db time is 50% of the total response time. We are planning to reorganize the most updated tables (found from DB02old tx).
Here we see that the size of the index for a table is greater than the actual size of the table. Is this possible, if yes then how can we reorganize the index as it does not allow us to reorganize the index using brspace command.
Hope to hear from you soon, and if any additional activities you can suggest to improve the performance of the database will be appreciated.
Thank you

Hi Zaheer,
online redef may help you (for a little while) , but also check WHY the index became fragmented.
Improper settings can bring the index fragmented again and you have reoccuring reorg needs.
i.e.
check if PCT_INCREASE >0 if you are using Dictionary Managed Tablespaces or locally managed tablespaces that uses a "User" allocation policy. Set it to 0 to generate uniform next extents in the online reorg.
select
            SEGMENT_NAME,
            SEGMENT_TYPE,
            round((NEXT_EXTENT*BLOCKS)/(EXTENTS*BYTES))*(BYTES/BLOCKS),
            PCT_INCREASE
        from
            DBA_SEGMENTS
        where
            OWNER='SAPR3'
        and
            SEGMENT_TYPE in ('INDEX',
                            'TABLE')
        and
            PCT_INCREASE > 0
        and segment_name in ('Yourtable','Yourindex')
In the following cases, it may be worthwhile to rebuild the index:
     --> the percentage of the space used is bad - lower than 66%: PCT_USED
     --> deleted leaf blocks represent more than 20% of total leaf blocks: DEL_LF_ROWS
     --> the height of the tree is bigger than 3: HEIGHT or BLEVEL
select
name,
'----------------------------------------------------------'    headsep,
'height               '||to_char(height,     '999,999,990')     height,
'blocks               '||to_char(blocks,     '999,999,990')     blocks,
'del_lf_rows          '||to_char(del_lf_rows,'999,999,990')     del_lf_rows,
'del_lf_rows_len      '||to_char(del_lf_rows_len,'999,999,990') del_lf_rows_len,
'distinct_keys        '||to_char(distinct_keys,'999,999,990')   distinct_keys,
'most_repeated_key    '||to_char(most_repeated_key,'999,999,990') most_repeated_key,
'btree_space          '||to_char(btree_space,'999,999,990')       btree_space,
'used_space           '||to_char(used_space,'999,999,990')        used_space,
'pct_used                     '||to_char(pct_used,'990')          pct_used,
'rows_per_key         '||to_char(rows_per_key,'999,999,990')      rows_per_key,
'blks_gets_per_access '||to_char(blks_gets_per_access,'999,999,990') blks_gets_per_access,
'lf_rows      '||to_char(lf_rows,    '999,999,990')||'        '||+
'br_rows      '||to_char(br_rows,    '999,999,990')                  br_rows,
'lf_blks      '||to_char(lf_blks,    '999,999,990')||'        '||+
'br_blks      '||to_char(br_blks,    '999,999,990')                  br_blks,
'lf_rows_len '||to_char(lf_rows_len,'999,999,990')||'        '||+
'br_rows_len '||to_char(br_rows_len,'999,999,990')                  br_rows_len,
'lf_blk_len   '||to_char(lf_blk_len, '999,999,990')||'        '||+
'br_blk_len   '||to_char(br_blk_len, '999,999,990')                br_blk_len
from
index_stats where index_name = 'yourindex'
bye
yk

How to reduce time when updating table with join of anther table

Hi all,
I am update table Policy1 using another table from other scheme
Policy1 is in schema "TEST".
TRN_POLICY_RISK_GIS is in Schema "TEST2".
Now i am executing my query which is taking lot of time to update and make cpu utilization upto 45%.
update policy1 set total_si = (select total_is from (select pol_sys_id,
avg(nvl(pol_cvr_si,0)) total_si from TEST2.TRN_POLICY_COVER_GIS tpcg
group by pol_sys_id ) b where p.pol_sys_id = b.pol_sys_id)
Help to optimize to given query.

update policy1    A
    set total_si =
       (select avg(nvl(pol_cvr_si,0))
           from TEST2.TRN_POLICY_COVER_GIS    B
          where B.pol_sys_id = A.pol_sys_id
;hopefully there is an index on TEST2.TRN_POLICY_COVER_GIS (POL_SYS_ID)

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

ST04 -table index info.

Hi,
In ST04 I check the table index information for one table there I noticed that Last statistics date is 02.01.2006 and CHAIN COUNT is 1850 also the table is having a large no of records so will it affect the performance of the table. if so then what is the necessary action we should take and what is the ideal conditions for this or is there any rule set by SAP .
Please help.
With Regards
Vinayak

Hi Vinayak,
what database version are you using and/or how are you updating your statistics (dbms_stats/ analyze)?
CHAIN COUNT 1850
first of all, CHAIN COUNT is only determined with analyze, not with dbms_stats.
This means your value of 1850 is as of the last statistics date done with analyze.
If you switched to dbms_stats (which was recommended) your chain count remains
on that value but your last statistics date is changed with each following dbms_stats run.
Your chain count value therefore might be much older than the last analyzed date if you
are using dbms_stats since then.
So if your are using dmbs_stats, get the current chain count with analyze.
If the number is still high check the row length if < 8kb and nr. of fields < 255 a reorganization
could eliminate your chained rows. (If you have records that are longer than 8kb and/or more
than 256 fields a reorganization could decrease the chained rows as well, for those records
that are <8kb and spanning over more than one block, but chained count will not be zero).
Generally speaking reducing chain count could reduce I/O (logical/physical).
Get in contact with your DBA in order to get the current chain count and dependent on
that reorganizing your table.
Kind regards,
Hermann

Drop Partition update Global Indexes

hello Gurus,
what will happen internally when issue a command
alter table tab_name drop partition part_name update global indexes;
why my insert statement waiting to complete this task on " cursor: pin S wait on X "
thanks in advance ..

Several times i also noticed that wait event for some jobs on 10 2 0 4 on hpux.
I didn't found out what was the reason.
It seems this wait event can be easly related to some bugs.
http://karenmorton.blogspot.com/2008/08/strange-parsing-behavior.html
http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/waitevents003.htm#sthref3012

How to get updated table values from objectlistdataproviders

how to get updated table values from objectlistdataproviders

Hi,
Here is a sample code
start-of-selection.
*Select the data you need into an internal table
loop at it_mara into wa_mara.
data that needs to be displayed in the output list
    write:/ box as checkbox,
            wa_mara-matnr under text-001,
            wa_mara-maktx under text-002,
            wa_mara-lgort under text-003.
Hide the data that needs to moved to internal table
    hide:wa_mara-matnr, wa_mara-maktx, wa_mara-lgort.
endloop.
clear wa_mara.
end-of-selection.
lines = sy-linno.
at line-selection.
clear:it_matnr.
do lines times.
    check sy-index > 1.
    box = space.
    read line sy-index field value box.
    if box = 'X'.
*data selected using check box is moved to internal table
      append wa_mara to it_matnr.
    endif.
enddo.
Regards,
Jisha.

Bad update table?

Hi
I have in FORM code:
UPDATE Z_TABLE SET COL1 = 'value' WHERE COL2 = var
And in this program is also many inserts and BDC codes.
After execute all PERFORM is command COMMIT WORK AND WAIT.
Problem is only in update table Z_TABLE. Some rows in database don't have updated
values.
It is possible that this error exists because FORM is executed many times ?
If I change this code to the one command: UPDATE Z_TABLE from itab, this repaire
my all updates or maybe this is work the same like single record UPDATE?

UPDATE dbtab - source
Syntax
... { {SET set_expression [WHERE sql_cond]}
    | {FROM wa|{TABLE itab}} }.
Alternatives:
1. ... SET set_expression [WHERE sql_cond]
2. ... FROM wa
3. ... FROM TABLE itab
Effect
The specifications in source define which rows and columns are changed. Either individual columns are changed using the addition SET or entire rows are overwritten using the addition FROM.
After FROM, either a non-table-type data object wa or an internal table itab can be specified. The content of these objects determines - on the one hand - which row(s) is/are changed, and
- on the other hand - which values are used to overwrite the row(s).
Alternative 1
... SET set_expression [WHERE sql_cond]
Effect
After the addition SET, the changes are specified in a list of change expressions in set_expression.
The addition WHERE uses a logical expression sql_cond to define in which rows of the database table the changes are executed. For the logical expression sql_cond, the same applies as for the WHEREcondition of the statement SELECT, with the exception that no subqueries are to be evaluated in the database table to be changed. If no WHERE condition is specified, all the rows in the database table are changed. If a column of the type STRING or RAWSTRING is changed, the primary key must be fully specified in the WHERE condition.
The content of primary key fields can only be changed if the respective database table is not linked with a search help and if pool and cluster tables are not accessed. If a link was to be created through the changes and this row would cause double entries in the primary key or a unique secondary index of the database table, no row is changed and sy-subrc is set to 4.
Notes
Before release 6.10, SET could only be specified for static specification of the database table.
Before release 6.10, no dynamic logical expressions could be used in the WHERE condition of the statement UPDATE.
Example
Dynamic conversion of the content of an arbitrary column in an arbitrary database table of a previous currency in Euro.
PARAMETERS: table    TYPE c LENGTH 30,
            column   TYPE c LENGTH 30,
            old_curr TYPE sycurr.
DATA: set_expr TYPE string,
      condition TYPE string.
CONCATENATE column ` = 'EUR'`
            INTO set_expr.
CONCATENATE column ` = old_curr`
            INTO condition.
TRY.
    UPDATE (table)
    SET    (set_expr)
    WHERE (condition).
CATCH cx_sy_dynamic_osql_error.
    MESSAGE `Error in update!` TYPE 'I'.
ENDTRY.
Alternative 2
... FROM wa
Effect
If you specify a non-table-type work area wa, the system will search for a row in the database table which, in its primary key, has the same content as the respective beginning part of the work area. The content of the work area is interpreted in its non-converted form and in accordance with the structure of the database table or the view. The content of the work area is assigned to this row. The assignment takes place without conversion from the left to the right in accordance with the structure of the database table or the view. The work area must fulfill the prerequisites for use in Open SQL statements.
If there is no row with the same content for the primary key in the database or if the change would lead to a double entry in a unique secondary index, the line is not changed and sy-subrc is set to 4.
Notes
The work area wa should always be declared in relation to the database table or the view in the ABAP Dictionary.
If you have a static specification of the database table or the view, the specification of the work area using FROM wa can be omitted outside of classes - provided a table work area dbtab for the respective database table or the view is declared using the statement TABLES. The system expands the UPDATE statement implicitly to include the addition FROM dbtab.
Alternative 3
... FROM TABLE itab
Effect
When an internal table itab is specified, the system processes all the rows of the internal table in accordance with the rules for the work area wa. The row type of the internal table must meet the requirements for use in Open-SQL statements.
If, in the database, there is no row with the same content of the primary key for a row in the internal table, or if the change would lead to a double entry in a unique secondary key, the respective row is not changed and sy-subrc is set to 4. If the internal table is empty, sy-subrc is set to 0. The system field sy-dbcnt is always set to the number of rows actually inserted.
Example
Reduction of the flight cost for all of today's flights of an airline carrier in the database table SFLIGHT by the percentage percent. The calculation of the new price is always done in an internal table sflight_tab and the database table is changed accordingly.
PARAMETERS: p_carrid TYPE sflight-carrid,
            percent TYPE p LENGTH 1 DECIMALS 0.
DATA sflight_tab TYPE TABLE OF sflight.
FIELD-SYMBOLS <sflight> TYPE sflight.
SELECT *
       FROM sflight
       INTO TABLE sflight_tab
       WHERE carrid = p_carrid AND
             fldate = sy-datum.
IF sy-subrc = 0.
LOOP AT sflight_tab ASSIGNING <sflight>.
    <sflight>-price =
      <sflight>-price * ( 1 - percent / 100 ).
ENDLOOP.
ENDIF.
UPDATE sflight FROM TABLE sflight_tab.

"Error in updating Table J_1iexchdr"

Hi ,
When I am creating the excise invoice, It's terminated the program and gives the following error
"Error in updating Table J_1iexchdr"
What can be the reason?
Regards
Prem

Hi prem
Look if these threads can help
RG23C Update Problem
Problem in SAP Script
billing document not creating
return delivery
************Reward points if usefull**************

Error in updating table J_1PART2

Hi,
I am getting an error while saving the excise invoice as 'error in updating table J_1PART2'.
What would have gone wrong?????? please help!!!
Thanks ,
Ramya

Discussion moved from SAP ERP Sales and Distribution (SAP SD) to Internationalization and Unicode
Please use Internationalization and Unicode for you CIN related queries

Error in updating table J_1IEXCHDR,J_1IEXCDTL in tcode J1IJ

Hi,
while cancelling excise invoice in Tcode J1IJ ,
we are getting 'error in updating table J_1IEXCHDR,J_1IEXCDTL'.
what is missing or tell the procedure to resolve the issue.
Regards,

Discussion moved from SAP ERP Sales and Distribution (SAP SD) to Internationalization and Unicode
Please use Internationalization and Unicode for you CIN related queries

How to obtain the table index in word use LabVIEW Report Generation Toolkit for Microsoft Office

I created a word templete and it had several tables. When I use the "Word Edit Cell" function in LabVIEW Report Generation Toolkit for Microsoft Office, the function need "table index", and I didn't find any function to get or set the table index in word document. How can I achieve my attention to write value to specified table cell using the "Word Edit Cell" function?
Thanks for reply!
YangAfreet

Hi yangafreet
You do not need to get the table index for the word edit cell.vi from anywhere. LabVIEW will automatically index all the tables in the document. See the attatched vi for an example.
Rich
Attachments:
Table Edit.vi ‏23 KB

Update table .... indexes ?

Similar Messages

Maybe you are looking for