ORA-01502

I have truncated specifuic partitions of some of the tables of my databse.
While I was viewing the alert logs,I could see a lot of DBA jobs failing with the error,
ORA-12012: error on auto execute of job
ORA-01502: index or partition of such index is in unusable state
How is it possiblwe to identify all
index or index partition that has been marked unusable by a direct load or by a DDL operation.
What should be the workaround now and any potential issues that I should take care of.
Thanks in advance.

Kindly check the following links ->
http://ora-12012.ora-code.com/
http://www.dbasupport.com/forums/archive/index.php/t-53627.html
Finally,
http://www.google.co.in/search?source=ig&hl=en&rlz=1G1GGLQ_ENIN290&=&q=ORA-12012&btnG=Google+Search&meta=lr%3D
Regards.
Satyaki De.

Similar Messages

ORA-01502 : index SYS.I_PROCEDURE1 is in unusable state

Oracle EE 9.2.0.8 on Windows 2003 SP2
Some SYS tables where moved by mistake with statement : "alter table sys.xxx move tablespace system;"
This caused some unusable SYS indexes but I cannot rebuild them. Each time I get same error :
ORA-01502: index 'SYS.I_PROCEDURE1' or partition of such index is in unusable state
Tracing showed me that some recursive SQL is going on and that fails because of the unusable index I_PROCEDURE1
This is the recursive sql who fails :
SQL> select audit$,options from procedure$ where obj#=115;
ERROR at line 1:
ORA-01502: index 'SYS.I_PROCEDURE1' or partition of such index is in unusable state
How do get out of this situation ?
Have already tried without succes :
- alter session set skip_unusable_indexes=true;
- altered some parameters to favor full table scans (optimizer_mode, db_file_multi_block_read_count
- tried to drop index (same error)
Thanks.
Benny Derous

Are you saying that you cannot rebuild that particular index, or other indexes? It works for me:orcl> alter index sys.i_procedure1 rebuild;
Index altered.
orcl> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
PL/SQL Release 11.2.0.3.0 - Production
CORE 11.2.0.3.0 Production
TNS for 32-bit Windows: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
orcl>

ORA-01502: Index or Partition is in unusable status. while truncating table

Hi All,
One of our Devlopers compalined that he is getting ORA-01502 : Index or partition is unusable status while truncating the a table in our Dataware house production database. He is using the following commands.
Alter index <index_name> unusable;
Truncate table <table_name> ;
He is running a scripts to truncate each table and ecah time he is passing the table name as an input parameter to script. He is using same method to truncate four tables each having a BITMAP and a REGULAR index. For two tables every thing is working fine, but for other two tables the he is getting ORA-01502 for BITMAP indexes. It a weekly process and every week he is getting the same issue. I checkd the Index status, they are in valid status only.
For a work around I have created a table with BITMAP and regular index in our dev database. made the indexes unusable, checked their status. I truncated the table. Importent thing here is the Indexes are becoming vaild when I truncate the table.
I suspect that my devloper's Indexes were already in unusable status (before he use the command ALTER INDEX), when he truncated the table, oracle trying to validate the index and throwing the error ORA-01502 because the Indexes are in unusabel statsu for a while.
I tried searching for the mechanism of truncate table command and its effect on Indexes. But I did not find any luck, no one is speaking about index when truncating the table. Can any one please help me????
Sorry for lengthy post. Any help is greatly appriciated and I thank every one in advance.

DDL for Indexes getting ORA-01502 error
CREATE BITMAP INDEX DWHMGR.ACT_TXN_LN_STG_01_XN3 ON DWHMGR.ACCT_TXN_LINE_TERM_BAL_STG_01 (TERM_BAL_CD ASC) TABLESPACE "BALFD_INX_04" NOLOGGING PCTFREE 1 INITRANS 2 MAXTRANS 255 STORAGE
( INITIAL 8M NEXT 8M MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 BUFFER_POOL DEFAULT );
CREATE BITMAP INDEX DWHMGR.ACCT_TERM_BAL_STG_01_XN3 ON DWHMGR.ACCT_TERM_BAL_STG_01 TERM_BAL_CD ASC) TABLESPACE "BALFD_INX_04" NOLOGGING PCTFREE 1 INITRANS 2 MAXTRANS 255 STORAGE
( INITIAL 8M NEXT 8M MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 BUFFER_POOL DEFAULT );
Indexes that have no issues.
CREATE INDEX DWHMGR.ACCT_TERM_BAL_STG_01_XN2 ON DWHMGR.ACCT_TERM_BAL_STG_01 (ACCT_REF_NB ASC) TABLESPACE "BALFD_INX_04" NOLOGGING PCTFREE 1 INITRANS 2 MAXTRANS 255 STORAGE (INITIAL 8M
NEXT 8M MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 BUFFER_POOL DEFAULT );
CREATE BITMAP INDEX DWHMGR.ACCT_PRC_STG_01_XN1 ON DWHMGR.ACCT_PRC_STG_01 (ACCT_ORG_CD ASC) TABLESPACE "BALFD_INX_04" NOLOGGING PCTFREE 1 INITRANS 2 MAXTRANS 255 STORAGE ( INITIAL 8M
NEXT 8M MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 BUFFER_POOL DEFAULT );
Please look at the DDL of the indexes and let me know if you need any other information.

ORA-01502 error in case of unusable unique index and bulk dml

Hi, all.
The db is 11.2.0.3 on a linux machine.
I made a unique index unusable, and issued a dml on the table.
Howerver, oracle gave me ORA-01502 error.
In order to avoid ORA-01502 error, do I have to drop the unique index ,and do bulk dml, and recreate the index?
Or Is there any other solution without re-creating the unique index?
create table hoho.abcde as
select level col1 from dual connect by level <=1000
10:09:55 HOHO@PD1MGD>create unique index hoho.abcde_dx1 on hoho.abcde (col1);
Index created.
10:10:23 HOHO@PD1MGD>alter index hoho.abcde_dx1 unusable;
Index altered.
Elapsed: 00:00:00.03
10:11:27 HOHO@PD1MGD>delete from hoho.abcde where rownum < 11;
delete from hoho.abcde where rownum < 11
ERROR at line 1:
ORA-01502: index 'HOHO.ABCDE_DX1' or partition of such index is in unusable stateThanks in advance.
Best Regards.

Hi. all.
The following is from "http://docs.oracle.com/cd/E14072_01/server.112/e10595/indexes002.htm#CIHJIDJG".
Is there anyone who can show me a tip to avoid the following without dropping and re-creating an unique index?
•DML statements terminate with an error if there are any unusable indexes that are used to enforce the UNIQUE constraint.
Unusable indexes
An unusable index is ignored by the optimizer and is not maintained by DML. One reason to make an index unusable is if you want to improve the performance of bulk loads. (Bulk loads go more quickly if the database does not need to maintain indexes when inserting rows.) Instead of dropping the index and later recreating it, which requires you to recall the exact parameters of the CREATE INDEX statement, you can make the index unusable, and then just rebuild it. You can create an index in the unusable state, or you can mark an existing index or index partition unusable. The database may mark an index unusable under certain circumstances, such as when there is a failure while building the index. When one partition of a partitioned index is marked unusable, the other partitions of the index remain valid.
An unusable index or index partition must be rebuilt, or dropped and re-created, before it can be used. Truncating a table makes an unusable index valid.
Beginning with Oracle Database 11g Release 2, when you make an existing index unusable, its index segment is dropped.
The functionality of unusable indexes depends on the setting of the SKIP_UNUSABLE_INDEXES initialization parameter.
When SKIP_UNUSABLE_INDEXES is TRUE (the default), then:
•DML statements against the table proceed, but unusable indexes are not maintained.
•DML statements terminate with an error if there are any unusable indexes that are used to enforce the UNIQUE constraint.
•For non-partitioned indexes, the optimizer does not consider any unusable indexes when creating an access plan for SELECT statements. The only exception is when an index is explicitly specified with the INDEX() hint.
•For a partitioned index where one or more of the partitions are unusable, the optimizer does not consider the index if it cannot determine at query compilation time if any of the index partitions can be pruned. This is true for both partitioned and non-partitioned tables. The only exception is when an index is explicitly specified with the INDEX() hint.
When SKIP_UNUSABLE_INDEXES is FALSE, then:
•If any unusable indexes or index partitions are present, any DML statements that would cause those indexes or index partitions to be updated are terminated with an error.
•For SELECT statements, if an unusable index or unusable index partition is present but the optimizer does not choose to use it for the access plan, the statement proceeds. However, if the optimizer does choose to use the unusable index or unusable index partition, the statement terminates with an error.Thanks in advance.
Best Regards.

How to fix ORA-01502: index or partition of such index is in usable state?

Greetings,
I received the ORA-01502: index or partition of such index is in un-usable state from one of our Oracle forms, and the problem was caused by using SQL Loader w/ the "DIRECT" load option. As a result of that, the system won't allow any updates including insert/delete to the problematic table w/ the index in un-usable state. I am trying to fix the problem but so far no luck:
When I tried to delete the duplicate rows from the table, I received the ORA-01502: index or partition of such index is in un-usable state error message;
When I tried to rebuild the index by using the following command:
ALTER INDEX index_name REBUILD
I received the "ORA-01452: cannot CREATE UNIQUE INDEX; duplicate keys found
Any help, suggestions or advice on this would be greatly appreciated.
Thanks millions in advance!

The duplicate key rows were inserted to the database by using the DIRECT parameter of the sql loader to specify direct path loading which bypasses integrity constraints. Since the issue exists in our production database and I am primarily an A/P w/ some responsibilities of DBA , I could really use your help to fix our production problem. I would really appreciate if you or any other guru could review my plan and code below for the fixes followed w/ some questions and give me your feedback/comments/suggestions as soon as possible:
1 - Drop the offending index by using the following command:
DROP INDEX <offending index name>
2 - Run the following script to detect duplicate rows:
SELECT *
FROM <Table_Name> A
WHERE
A.rowid >
any(SELECT B.rowid FROM <Table_Name> B
WHERE
B.KEY1 = A.KEY1
and
B.KEY2 = A.KEY2
and
B.KEY3 = A.KEY3
and
B.KEY4 = A.KEY4
3. Run the following script to remove the duplicates:
DELETE
FROM <Table_Name> A
WHERE
A.rowid >
any(SELECT B.rowid FROM <Table_Name> B
WHERE
B.KEY1 = A.KEY1
and
B.KEY2 = A.KEY2
and
B.KEY3 = A.KEY3
and
B.KEY4 = A.KEY4
4 - Rebuild the index by using the following line command:
ALTER INDEX index_name REBUILDBut wait, how about data? Don't I need to back up and reload the data? Do I need to drop and recreate the table? Anything else I should be taking into considerations?
p.s. Although, we only have a total of 35,736 rows of data from this table, but I want to make sure I do it right the first time.
Thanks a lot and any/all the help!

ORA-1502

Hi all,
I got the following error plz resolve it
ORA-01502 INDEX 'pk_tbl_cdt_lat' or partition of such index is in unusable state
plz help me
Regards ...

Hi,
Every mid-night my application is rebuild all indexes , that time my tables is working fine, after 10 hours the error ORA-1502 index problem encounted this every day happend last two month's . plz help me how to resolve the problem.
Regards ....

ORA-29952 index_status=synchronize

I'm getting this error message ORA-29952: cannot issue DDL on a domain index partition marked as LOADING
When executing multiple threads of the statement below on different partitions simultaneously.
ALTER INDEX spatail_idx MODIFY PARTITION p3 PARAMETERS ('index_status=synchronize sdo_batch_size=500');
It works when executing one thread sequentially on the partitions.

DDL for Indexes getting ORA-01502 error
CREATE BITMAP INDEX DWHMGR.ACT_TXN_LN_STG_01_XN3 ON DWHMGR.ACCT_TXN_LINE_TERM_BAL_STG_01 (TERM_BAL_CD ASC) TABLESPACE "BALFD_INX_04" NOLOGGING PCTFREE 1 INITRANS 2 MAXTRANS 255 STORAGE
( INITIAL 8M NEXT 8M MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 BUFFER_POOL DEFAULT );
CREATE BITMAP INDEX DWHMGR.ACCT_TERM_BAL_STG_01_XN3 ON DWHMGR.ACCT_TERM_BAL_STG_01 TERM_BAL_CD ASC) TABLESPACE "BALFD_INX_04" NOLOGGING PCTFREE 1 INITRANS 2 MAXTRANS 255 STORAGE
( INITIAL 8M NEXT 8M MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 BUFFER_POOL DEFAULT );
Indexes that have no issues.
CREATE INDEX DWHMGR.ACCT_TERM_BAL_STG_01_XN2 ON DWHMGR.ACCT_TERM_BAL_STG_01 (ACCT_REF_NB ASC) TABLESPACE "BALFD_INX_04" NOLOGGING PCTFREE 1 INITRANS 2 MAXTRANS 255 STORAGE (INITIAL 8M
NEXT 8M MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 BUFFER_POOL DEFAULT );
CREATE BITMAP INDEX DWHMGR.ACCT_PRC_STG_01_XN1 ON DWHMGR.ACCT_PRC_STG_01 (ACCT_ORG_CD ASC) TABLESPACE "BALFD_INX_04" NOLOGGING PCTFREE 1 INITRANS 2 MAXTRANS 255 STORAGE ( INITIAL 8M
NEXT 8M MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 BUFFER_POOL DEFAULT );
Please look at the DDL of the indexes and let me know if you need any other information.

Execute Procedure

Hi,
I am having table like this:
tmp_pdf
ID NUMBER(9) PK
pdf BLOB NULLABLE
I wrote a procedure like insert_pdf. I am having SQL developer tool. I am using this statement to execute the procedure:
EXECUTE insert_pdf(1,NULL);
I am getting this error -
Error starting at line 1 in command:
EXECUTE insert_pdf(3,NULL);
Error report:
ORA-01502: index 'DBA_PDF3.TMP_PDF_PK' or partition of such index is in unusable state
ORA-06512: at "DBA_PDF3.INSERT_PDF", line 7
ORA-06512: at line 1
01502. 00000 - "index '%s.%s' or partition of such index is in unusable state"
*Cause: An attempt has been made to access an index or index partition
that has been marked unusable by a direct load or by a DDL
operation
*Action: DROP the specified index, or REBUILD the specified index, or
REBUILD the unusable index partition
Is this the right execution command?
Thanks
Edited by: user10679113 on Dec 17, 2008 3:37 PM

Hello,
If you got an OUT variable some cursor variable or some singleton (name or id ) in your procedure, you can use same block to execute. See following exmaple and it will be clear
CREATE OR REPLACE PACKAGE pkg_emp
IS
   TYPE emp_cur IS REF CURSOR;
   PROCEDURE findmechanic (mec_cursor OUT emp_cur);
   PROCEDURE findname (i_id IN number, name OUT varchar2);
END pkg_emp;
CREATE OR REPLACE PACKAGE BODY pkg_emp
IS
   PROCEDURE findmechanic (mec_cursor OUT emp_cur)
   IS
   BEGIN
      OPEN mec_cursor FOR
         SELECT *
         FROM mechanic
         ORDER BY id;
   END findmechanic;
   PROCEDURE findname (i_id IN number, name OUT varchar2)
   IS
   BEGIN
      SELECT distinct name
      INTO name
      FROM mechanic
      where id = i_id;
   END;
END pkg_emp;
Testcase how to use above procedure/pgk with in and out variables
DECLARE
   TYPE mech_rec
   IS
      RECORD (name                VARCHAR2 (30), id                  NUMBER);
   TYPE curtyp IS REF CURSOR
      RETURN mech_rec;
   TYPE emp_cur IS REF CURSOR
      RETURN mech_rec;
   mc_content   curtyp;
   crow         mech_rec;
   v_name       VARCHAR2 (30);
BEGIN
   pkg_emp.findmechanic (mc_content);
   LOOP
      FETCH mc_content INTO crow;
      EXIT WHEN mc_content%NOTFOUND;
      DBMS_OUTPUT.put_line (' Mechanic Name: ' || crow.name);
      DBMS_OUTPUT.put_line (' id: ' || crow.id);
   END LOOP;
   pkg_emp.findname (1, crow.name);
   DBMS_OUTPUT.put_line ('Mechanic Name = ' || crow.name);
END;Let me know if it clears all your doubt and if it does mark it answered or helpful so other can benefit
Regards
OrionNet

ASSERTION_FAILED when Activate a DTP

I got an error message when trying to activate a DTP. Does anyone know how to fix it? Thanks!
Runtime Errors         ASSERTION_FAILED
Date and Time          03/27/2007 14:29:57
Short dump has not been completely stored (too big)
Short text
     The ASSERT condition was violated.
What happened?
     In the running application program, the ASSERT statement recognized a
     situation that should not have occurred.
     The runtime error was triggered for one of these reasons:
     - For the checkpoint group specified with the ASSERT statement, the
       activation mode is set to "abort".
     - Via a system variant, the activation mode is globally set to "abort"
       for checkpoint groups in this system.
     - The activation mode is set to "abort" on program level.
     - The ASSERT statement is not assigned to any checkpoint group.
Error analysis
     The following checkpoint group was used: "No checkpoint group specified"
     If in the ASSERT statement the addition FIELDS was used, you can find
     the content of the first 8 specified fields in the following overview:
     " (not used) "
     " (not used) "
     " (not used) "
     " (not used) "
     " (not used) "
     " (not used) "
     " (not used) "
     " (not used) "
Trigger Location of Runtime Error
     Program                                 CL_RSAR_PSA===================CP
     Include                                 CL_RSAR_PSA===================CM006
     Row                                     152
     Module type                             (METHOD)
     Module Name                             UPDATEDIRECTORY_TABLES
Source Code Extract
Line SourceCde
122               i_uni_idc25       = l_codeid
123               i_program_class   = 'RSAR_ODS_MAINTAIN'
124             EXCEPTIONS
125               deletion_rejected = 2
126               OTHERS            = 3.
127         ENDIF.
128       ENDIF.
129       UPDATE rstsods SET tstpnm   = sy-uname
130                 timestmp = l_s_ods-timestmp
131                 userapp   = p_userapp
132                 userobj   = p_userobj
133                 maintprog = ''
134            WHERE odsname = l_s_odsfield-odsname
135            AND   version = l_s_odsfield-version.
136       IF sy-subrc = 0.
137         IF i_partitioned = rs_c_true.
138 *--   Entry could exist but includes no partition number,
139 *     because the PSA was not partitioned before
140           l_tablnm = p_psa_techname.
141
142           CALL FUNCTION 'RSDU_PARTITIONS_INFO_GET'
143             EXPORTING
144               i_tablnm              = l_tablnm
145             IMPORTING
146               e_ts_part_info        = l_ts_part_info
147             EXCEPTIONS
148               table_not_exists      = 1
149               table_not_partitioned = 2
150               OTHERS                = 3.
151
>>>           ASSERT sy-subrc = 0.
153
154           DESCRIBE TABLE l_ts_part_info LINES l_num_partitions.
155           READ TABLE l_ts_part_info INDEX l_num_partitions INTO l_s_part_info.
156           l_highest_partvalue = l_s_part_info-high_value.
157
158           UPDATE rstsods SET partno = l_highest_partvalue
159             WHERE odsname = l_s_odsfield-odsname
160             AND   version = l_s_odsfield-version.
161
162         ENDIF.
163       ELSE.
164 *       create new version
165         l_s_ods-odsname       = l_s_odsfield-odsname.
166         l_s_ods-version       = i_next_version.
167         l_s_ods-dateto        = rsods_c_dateto_01019999.
168         l_s_ods-datefrom      = rsods_c_datefrom_01011998.
169         l_s_ods-objstat       = rs_c_objstat-active.
170         l_s_ods-odsname_tech = p_psa_techname.
171         l_s_ods-progname      = i_progname.

I guess it is Notes 1012607.
Summary
Symptom
Note: This note is relevant only for 'ORACLE' and 'MSSQL' database systems. After you implement this note, you must also carry out some manual corrections (see 'Solution', below).
If you are working with database system DB2 or MSSQL, also implement Note 1022026.
When data is written or activated or when a DataStore object is activated, the following errors occur:
Similar errors may also occur for the DataSource and data transfer process (DTP).
ORA-01502: index 'SAPDAT./BIC/A*KE' or partition of such index is in unusable state
Column 'PARTNO' is partitioning column of the index '/BIC/A*KE'. Partition columns for a unique index must be a subset of the index key.
error #RSDU_TABLE_TRUNC_PARTITION_MSS: Error While Calling Module MSS_TRUNC_PARTITION_FROM_TABLE Message no. 0U534#.
<b>ASSERTION_FAILED in class 'CL_RSAR_PSA'.</b>
Error message D0 313 in the activation log. The message does not contain any text. In the activation log it is displayed as an empty line with a red traffic light.
Other terms
DBIF_RSQL_SQL_ERROR, D0 313, D0313
Reason and Prerequisites
Reason:
The partitioning logic of the persistent staging area (PSA) service does not recognize that the PARTNO field must not be deleted.
For write-optimized DataStore objects, the active table is created as a partitioned table, even though a global index is used to ensure uniqueness of data. This is not compatible with the 'drop of a partition'.
In the DataSource maintenance, you have the option to define key fields. For the first 16 key fields of the DataSource field list, a global index is also created.
If 'semantic groups' are used in the DTP, the error stack is created with a global index.
Solution
Implement the corrections by importing the Support Package or by implementing the advance correction. As a result, the 'range' partitioning is deactivated in the PSA service as soon as a global index is requested.
The error can occur for the objects: DataStore (only the write-optimized type), DataSource, and error stack of the DTP.
This note contains the 'RSAR_PSA_PARTITION_CHECK' program, which you can use to analyze the objects. Execute the program. Use the search strings listed in section 5), depending on whether you want to analyze individual objects or object types. If you do not make an entry in the PODSTECH field (technical name of the PSA), the system checks all existing PSA tables, which may take some time.
You can use transaction SLG1 to display the log for 'RSAR_PSA_PARTITION_CHECK'. Select the following:
           Object        = 'RSAR'
Subobject   = 'METADATA'
Ext. Identif. = 'RSAR_PSA_PARTITION_CHECK'
You must make different manual changes to repair each of the different object classes.
1) DataStore (write-optimized)
Incorrect DataStores are identified in the log of the check program with the PSA type 'FASTSTORE'. The name after 'Obj:' is the technical name of the corresponding DataStore object.
For a DataStore object of the 'write-optimized' type, a global index with relation to the semantic key is created if the 'Do Not Check Uniqueness of Data' indicator is not set.
Check if you need to ensure that data is unique in your scenario.
1. If you do not need the data to be unique:
                    Set the flag: 'Do Not Check Uniqueness of Data', and activate the DataStore object. The DataStore object is now consistent again.
2. If you need unique data:
In this case, you must departition and convert the table.
If the error occurred when you activate the DataStore itself or when you activate the data, you must activate the DataStore object after converting the active table. You need the technical name of the active table for the conversion. You can get this directly from the log of 'RSAR_PSA_PARTITION_CHECK'. If you know which DataStore contains errors, find the technical name of the active table in the Maintain DataStore screen by choosing:
           <Extras> ->
          'Information (logs/status)
Choose 'Dictionary DB status' to access the status POPUP. You can find the technical name in the 'Active table' field.
If the table does not contain any data according to the 'RSAR_PSA_PARTITION_CHECK' log, the table is automatically departitioned when you activate the DataStore.
If the table contains data, you must departition and convert the table as described in section 4.
After that, use the AdminWorkBench (transaction RSA1) to activate the DataStore object.
2) DataSource:
Incorrect DataSources are identified in the log of the check program with the PSA type 'NEW_DS'. The 'Obj:' indicator is followed by two additional character strings. The first is the technical name of the relevant DataSource. The second is the technical name of the source system.
PSA tables for DataSources with a key definition must be departitioned.
The name of the PSA table for the DataSource is contained directly in the 'RSAR_PSA_PARTITION_CHECK' log.
If the table does not contain any data according to the 'RSAR_PSA_PARTITION_CHECK' log, the table is automatically departitioned when you activate the DataStore.
If the table contains data, you must departition and convert the table as described in section 4.
Call transaction 'RSDS' and enter the technical name of the DataSource and the source system and activate the DataSource.
3) Error stacks for the DTP:
Incorrect Error Stacks are identified in the log of the check program with the PSA type 'ERRORSTACK'. The 'Obj:' indicator is followed by the technical name of the relevant DTP. There may be more than one error stack table for each DTP.
PSA tables for ErrorStack with a key definition must be departitioned.
The name(s) of the PSA Error Stack table(s) for the DTP is/are contained directly in the 'RSAR_PSA_PARTITION_CHECK' log.
If the table does not contain any data according to the 'RSAR_PSA_PARTITION_CHECK' log, the table is automatically departitioned when you activate the DTP.
If the table contains data, you must departition and convert the table as described in section 4.
Now call transaction RSDTP, enter the technical name of the DTP and activate the DTP.
4) Departitioning and converting
The following manual conversion using transaction SE14 is supported only for ORACLE database systems. Open a problem message under component BW-SYS-DB-MSS if you need to convert tables on a MSSQL database system.
Call transaction SE14 (Database Utility) for the tables you need to convert. Select 'Table', enter the technical name of the table and choose 'Edit'.
On the next screen, choose 'Storage Parameters' (Shift+F6).
On the next screen (Storage Parameters), choose 'For new creation' (F8).
In the dialog box that then appears, select 'Current database parameters' and copy it by choosing 'Enter'.
You now get an overview of the storage parameters <Tables>, <Indexes> and existing <Partitions>.
Under the 'Table' node, if the content of the 'TABLESPACE' field is initial, enter the value from the 'TABLESPACE' field of the first partition.
For the field 'PARTITIONED BY', choose the option 'No partitioning' and save your changes.
Exit the screen with the storage parameters.
On the next screen, ensure that the 'Save data' radio button after 'Activate and adjust database' is selected, then execute the conversion. You execute the conversion by choosing 'Force Conversion' in the <Extras> menu.
Next, you must correct the PARTNO indicator in table RSTSODS. To do this, call transaction RSRV and execute the test 'Consistency Between PSA Partitions and SAP Administration Information'. You can find this test in transaction RSRV under
<All Elementary Tests>
             -> <PSA Tables>
You can execute the RSRV test and repair for all converted tables at once. For further information about how to use transaction RSRV in this case, see the online documentation. You can call the online documentation by choosing the 'Info' icon.
5) Search strings:
a) Use the search string '/BI+/B*' to find the relevant entries for the DataSource, the change logs and the error stack.
b) Use the search string '/BI+/A*00' to find the relevant entries in the active tables for the DataSource objects.
SAP NetWeaver 2004s BI
           Import Support Package 13 for SAP NetWeaver 2004s BI (BI Patch 13 or SAPKW70013) into your BI system. The Support Package is available once Note 991093 "SAPBINews BI 7.0 Support Package 13", which describes this Support Package in more detail, has been released for customers.
In urgent cases, you can implement the correction instructions as an advance correction.
You must first implement Notes 932065, 935140, 948389, 964580, 969846, 975510, 983212 and 1000448, which provide information about transaction SNOTE. Otherwise, problems and syntax errors may occur when you deimplement certain notes.
To provide information in advance, the notes mentioned above may already be available before the Support Package is released. In this case, the short text of the note still contains the words "Preliminary version".
Before you implement an advance correction (if one exists and you want to implement it), see Note 875986. This contains notes regarding the SAP Note Assistant and these notes prevent problems during the implementation.

Skip_unusable_indexes and primary keys

Hi,
if have data for a big table splitted in multipe files which i want to load via sqlldr all in the same table as fast as possible. The indexes should be rebuild after the last file was loaded.
So I use SKIP_UNUSABLE_INDEXES=TRUE,SKIP_INDEX_MAINTENANCE=TRUE
I thougt sqlldr would proceed if an index is in unusable state. But if the index is of a primary key, it stops anyway with
SQL*Loader-951: Error calling once/load initialization
ORA-02373: Error parsing insert statement for table ....
ORA-01502: index 'MX_MARKET_DATA.MDB_PK' or partition of such index is in unusable state
in my workaround I rebuild the pk after every processed file. I could also merge the files to one single file in advance. But I would rather try to load some files in parallel.
Is there a way to load and skip the pk?
BR
Tobias

Hi,
>ORA-01502: index 'MX_MARKET_DATA.MDB_PK' or partition of such index is in unusable state
Please check following link:
ORA-01502: index or partition of such index is in usable state tips

Cannot post SD documents after upgrade to Oracle 11g

Dear Gurus,
Lately I have tried to upgrade database for SAP R/3 Enterprise 4.7 from Oracle 9i (9.2.0.7) to Oracle 11g (11.2.0.2). I have tried some of its features including table and index compression.
Right now my team is testing my server and find out some weird behaviour on its database. They try to create some sales order (VA01) and this action create SD document number. But when we try to check this created document number, SAP server replied weird message. It said that this SD document number is not on database and may have been archived.
When I check on ST22, it said "ORA-01502: index 'SAPWPR.VBAP~0' or partition of such index is in unusable state".
FYI, this index has been rebuild and compressed before.
I have tried to rebuild this index successfully, but still not help. I also have checked its status from SE11 and I cannot find this index on VBPA table.
Any suggestion ?
Ardhian
http://sapbasis.wordpress.com

Hi Orkun,
This is the log when I try from SE14 :
B-INDXVBPA0
Start background processing for object VBPA (INDX)
Request: Delete and recreate Index VBPA-0 (ADMIN/10.10.11/12:49)
Process: emaprd2ap_5
sql:
DROP INDEX "VBPA~0"
ORA-02429: cannot drop index used for enforcement of unique/primary ke
y
DDL time(___1): ...228.626 milliseconds
VBPA~0 could not be removed
Index VBPA-0 could not be deleted
Request for VBPA could not be executed
ardhian

INDEX GETTING UNUSABLE

Hello everybody,
I'm using Oracle 9i and I'm getting below error when I execute a anonymous block which runs through the cursor and updates the table.
ORA-01502: index 'ASAP.PK_STATUS_NO' or partition of such index is in unusable state
select query on the same table is executing fine but seems that update is getting troubled. And the status number column is declared to be primary key
Can anyone tell me what and where the problem might be ???
regards,
Rossy

From Oracle Metalink Note: 336195.1
Solution
There can be multiple causes of for the ORA-1502 ... all are expected behaviour and the index needs to be recreated in to resolve the error
Causes
1) The table was loaded using a direct load method (import ... sqlloader ... insert with the APPEND hint ... a direct write from a C program)
2) An ALTER INDEX ... REBUILD failed and left the index in an unusable state
3) The problem index was a global index on a partitioned table and an EXCHANGE PARTITION was done
4) The table was moved to a different location using ALTER TABLE ... MOVE
5) Per the Application developers guide:
If alter table command is used to change the underlying data of a column from LONG to CLOB or LONG RAW to BLOB. All indexes must be rebuilt
Regards, Gerwin
Edited by: Gerwin Hendriksen on May 29, 2009 11:45 AM

Unable to register one extract,but the other twos are ok.

Enviroment:
OS:Windows Server 2003 64bit
GG:
Oracle GoldenGate Command Interpreter for Oracle
Version 11.2.1.0.6 16211226 OGGCORE_11.2.1.0.6_PLATFORMS_130418.1829
Windows x64 (optimized), Oracle 11g on Apr 19 2013 17:38:40
There are three extract on the same server.Now I'd like to register for the three extracts.The other twos are ok,but there is a one extract,meet the below error message:
2013-12-22 21:43:50 ERROR OGG-01755 Cannot register or unregister EXTRACT E_
ZF_K because of the following SQL error: OCI Error ORA-00001: unique constraint
(SYSTEM.LOGMNR_SESSION_UK1) violated
ORA-06512: at "SYS.DBMS_CAPTURE_ADM_INTERNAL", line 453
ORA-06512: at "SYS.DBMS_CAPTURE_ADM", line 289
ORA-06512: at line 1 (status = 1). See Extract user privileges in the Oracle Gol
denGate for Oracle Installation and Setup Guide.
What should I do?And I also want to know the detailed cause of this error.Thanks in acvance!

Hi,
Ongoing DDL operations on the Oracle database do not allow the PL/SQL PackageDBMS_CAPTURE_ADM.BUILD to build the LogMiner Data Dictionary, as part of the GGSCI REGISTER EXTRACT command.
NOTE: The DBMS_CAPTURE_ADM.BUILD procedure is the same as the DBMS_LOGMNR_D.BUILD procedure.
exec dbms_goldengate_auth.grant_admin_privilege('USER_NAME');
Connect to the Oracle database as SYSDBA # sqlplus /nologin
SQL> connect / as sysdba
In the SYSDBA session, determine that there are no EXCLUSIVE DDL sessions.
(Summary) SQL> select mode_held, count(*) from dba_ddl_locks group by mode_held;
(In detail) SQL> select mode_held, name, type from dba_ddl_locks where mode_held = 'Exclusive' order by mode_held;
(To identify a specific user process) select l.name, l.type, l.mode_held, s.sid, s.program, s.username, p.spid, p.pidfrom dba_ddl_locks l, v$session s, v$process p where l.mode_held = 'Exclusive' and l.session_id = s.sid and s.paddr = p.addr;
When there are no EXCLUSIVE mode DDL locks, re-run the GGSCI REGISTER EXTRACT command.
In case this is not working then try for following steps,
1. turn on sql trace
2. identify SQL and its bind variables:
declare
extract_name varchar2(100) := :1;
source_global_name varchar2(4000) := :2;
firstScn number := :3;
outbound_server_name varchar2(30);
outbound_capture_name varchar2(30);
capture_queue_name varchar2(30);
queue_table_name varchar2(30);
outbound_comment varchar2(125);
BEGIN
dbms_xstream_gg_adm.wait_for_inflight_txns := 'n';
dbms_xstream_gg_adm.synchronization := 'none';
dbms_xstream_gg_adm.is_goldengate := true; /* Construct the queue table name */
queue_table_name := SUBSTR('OGG$Q_TAB_' || extract_name, 1, 30); /* Construct the capture queue name */
capture_queue_name := SUBSTR('OGG$Q_' || extract_name, 1, 30); /* create capture queue */
dbms_streams_adm.set_up_queue(queue_table => queue_table_name, queue_name => capture_queue_name); /* Construct the outbound capture name */
outbound_capture_name := SUBSTR('OGG$CAP_' || extract_name, 1, 30); /* create capture specifying the first scn */ DBMS_XSTREAM_GG.SET_GG_SESSION();
dbms_capture_adm.create_capture(queue_name => capture_queue_name,
capture_name => outbound_capture_name,
first_scn => firstScn,
source_database => source_global_name); /* Construct the outbound server name */
outbound_server_name := SUBSTR('OGG$' || extract_name, 1, 30); /* Construct the comment assosciated with this outbound server */ outbound_comment := extract_name || ' GoldenGate Extract';
DBMS_XSTREAM_GG_ADM.ADD_OUTBOUND(server_name => outbound_server_name,
capture_name=> outbound_capture_name,
source_database=> source_global_name,
committed_data_only => FALSE,
wait_for_inflight_txns => 'N',
synchronization => 'NONE',
start_scn => firstScn,
comment => outbound_comment);
DBMS_XSTREAM_GG.SET_GG_SESSION(FALSE);
END;
3. run the sql manually under sqlplus.
it hits:
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-01502: index 'SYS.I_WRI$_OPTSTAT_TAB_OBJ#_ST' or partition of such index is
in unusable state
ORA-06512: at "SYS.DBMS_STREAMS_ADM", line 746
ORA-06512: at line 16
4.
SQL> select owner,status from dba_indexes where index_name='I_WRI$_OPTSTAT_TAB_OBJ#_ST';
OWNER STATUS
SYS UNUSABLE
5.rebuild th index, but it did not help:
alter index I_WRI$_OPTSTAT_H_OBJ#_ICOL#_ST rebuild;
6. drop and recreate the index. Then the extract can be registered
Thanks,
GG Lover

DIRECT PATH LOAD의 개념 및 사용 방법

제품 : ORACLE SERVER
작성날짜 : 1998-11-27
매우 많은 양의 데이타를 빠른 시간 내에 load하고자하는 경우 direct path load를
사용할 수 있다. 여기에서 이러한 direct path load의 자세한 개념 및 사용방법,
사용 시 고려해야 할 점 등을 설명한다.
1. conventional path load
일반적인 sql*loader를 이용한 방법은 존재하는 table에 datafile 내의 data를
SQL의 INSERT command를 이용하여 insert시킨다. 이렇게 SQL command를
이용하기 때문에 각각의 데이타를 위한 insert command가 생성되어 parsing되는
과정이 필요하며, 먼저 bind array buffer (data block buffer) 내에 insert되는
데이타를 입력시킨 후 이것을 disk에 write하게 된다.
conventional path load를 사용하여야 하는 경우는 다음과 같다.
--- load 중에 table을 index를 이용하여 access하여야 하는 경우
direct load중에는 index가 'direct load state'가 되어 사용이 불가능하다.
--- load 중에 index를 사용하지 않고 table을 update나 insert등을 수행해야
하는 경우
direct load 중에는 table에 exclusive write(X) lock을 건다.
--- SQL*NET을 통해 load를 수행해야 하는 경우
--- clustered table에 load하여야 하는 경우
--- index가 걸려 있는 큰 table에 적은 수의 데이타를 load하고자 할 때
--- referential이나 check integrity가 정의되어 있는 큰 table에
load하고자 할 때
--- data field에 SQL function을 사용하여 load하고자 할 때
2. direct path load의 수행 원리
Direct Path Loads는 다음과 같은 특징들로 인하여 매우 많은 양의 데이타를
빠른 시간에 load하고자 할 때 이용하는 것이 바람직하다.
(1) SQL INSERT 문장을 generate하여 수행하지 않는다.
(2) memory 내의 bind array buffer를 이용하지 않고 database block의
format과 같은 data
block을 memory에 만들어 데이타를 넣은 후 그대로 disk에 write한다.
memory 내의 block buffer와 disk의 block은 그 format이 다르다.
(3) load 시작 시에 table에 lock을 걸고 load가 끝나면 release시킨다.
(4) table의 HWM (High Water Mark) 윗 부분의 block에 data를 load한다.
HWM는 table에 data가 insert됨에 따라 계속 늘어나고 truncate 외에는
줄어들게 하지 못한다.
그러므로, 항상 완전히 빈 새로운 block을 할당받아 data를 입력시키게 된다.
(5) instance failure가 발생하여도 redo log file을 필요로 하지 않는다.
(6) UNDO information을 발생시키지 않는다.
즉 rollback segment를 사용하지 않는다.
(7) OS에서 asynchronous I/O가 가능하다면, 복수개의 buffer에 의해서 동시에
data를 읽어서 buffer에 write하면서 buffer에서 disk로 write할 수 있다.
(8) parallel option을 이용하면 더욱 성능을 향상시킬 수 있다.
3. direct path load의 사용방법 및 options
direct path load를 사용하기 위한 view들은 다음 script에 포함어 있으며,
미리 sys user로 수행되어야 한다. 단 이 script는 catalog.sql에 포함되어 있어,
db 구성 시에 이미 수행되어진다.
@$ORACLE_HOME/rdbms/admin/catldr.sql
direct path load를 사용하기 위해서는 일반적인 sqlload 명령문에 DIRECT=TRUE를
포함시키기만 하면 된다. 다음과 같이 기술하면 된다.
sqlload username/password control=loadtest.ctl direct=true
이 direct path load를 사용 시에 고려할 만한 추가적인 option 및 control file
내에 기술 가능한 clause들을 살펴본다.
(1) ROWS = n
conventional path load에서 rows는 default가 64이며, rows에 지정된 갯수
만큼의 row가 load되면 commit이 발생한다. 이와 비슷하게 direct load
path에서는 rows option을 이용하여 data save를 이루며, data save가 발생하면
data는 기존 table에 포함되어 입력된 data를 잃지 않게 된다.
단 이 때 direct path load는 모든 data가 load된 다음에야 index가
구성되므로 data save가 발생하여도 index는 여전히 direct load state로
사용하지 못하게 된다.
direct path load에서 이 rows의 default값은 unlimited이며, 지정된 값이
database block을 채우지 못하면 block을 완전히 채우는 값으로 올림하여,
partial block이 생성되지 않도록 한다.
(2) PIECED clause
control file내에 column_spec datatype_spec PIECED 순으로 기술하는
것으로서 direct path load에만 유효하다. LONG type과 같이 하나의 data가
maximum buffer size보다 큰 경우 하나의 data를 여러번에 나누어 load하는
것이다. 이 option은 table의 맨 마지막 field
하나에만 적용가능하며, index column인 경우에는 사용할 수 없다.
그리고 load도중 data에 문제가 있는 경우 현재 load되는 data의 잘린 부분만
bad file에 기록되게 된다. 왜냐하면 이전 조각은 이미 datafile에 기록되어
buffer에는 남아있지 않기 때문이다.
(3) READBUFFERS = n (default is 4)
만약 매우 큰 data가 마지막 field가 아니거나 index의 한 부분인 경우
PIECED option을 사용할 수 없다. 이러한 경우 buffer size를 증가시켜야
하는데 이것은 readbuffers option을 이용하면 된다. default buffer갯수는
4개이며, 만약 data load중 ORA-2374(No more slots for read buffer
queue) message가 나타나면, buffer갯수가 부족한 것이므로 늘려주도록 한다.
단 일반적으로는 이 option을 이용하여 값을 늘린다하더라도 system
overhead만 증가하고 performance의 향상은 기대하기 어렵다.
4. direct path load에서의 index 처리
direct path load에서 인덱스를 생성하는 절차는 다음과 같다.
(1) data가 table에 load된다.
(2) load된 data의 key 부분이 temporary segment에 copy되어 sort된다.
(3) 기존에 존재하던 index와 (2)에 의해서 정렬된 key가 merge된다.
(4) (3)에 의해서 새로운 index가 만들어진다.
기존에 존재하던 index와 temporary segment, 그리고 새로 만들어지는 index가
merge가 완전히 끝날 때까지 모두 존재한다.
(5) old index와 temporary segment는 지워진다.
이와 같은 절차에 반해 conventional path load는 data가 insert될 때마다 한
row 씩 index에 첨가된다. 그러므로 temporary storage space는 필요하지 않지만
direct path load에 비해 index 생성 시간도 느리고, index tree의 balancing도
떨어지게 된다.
index생성 시 필요한 temporary space는 다음과 같은 공식에 의해 예측되어질 수
있다.
1.3 * key_storage
key_storage = (number_of_rows) * (10 + sum_of_column_sizes +
number_of_columns)
여기에서 1.3은 평균적으로 sort 시에 추가적으로 필요한 space를 위한 값이며,
전체 data가 완전히 순서가 거꾸로 된 경우에는 2, 전체가 미리 정렬된 경우라면
1을 적용하면 된다.
--- SINGLEROW clause
이와 같이 direct path load에서 index 생성 시 space를 많이 차지하는 문제점
때문에 resource가 부족한 경우에는 SINGLEROW option을 사용할 수 있다.
이 option은 controlfile 내에 다음과 같은 형태로 기술하며, direct path
load에만 사용 가능하다.
into tables table_name [sorted indexes...] singlerow
이 option을 사용하면 전체 data가 load된 뒤에 index가 구성되는 것이 아니라
data가 load됨에 따라 data 각각이 바로 index에 추가된다.
이 option은 기존에 미리 index가 존재하는 경우 index를 생성하는 동안
merge를 위해 space를 추가적으로 필요로 하는 것을 막고자 하는 것이므로
INSERT 시에는 사용하지 않고, APPEND시에만 사용하도록 하고 있다.
실제 새로 load할 data 보다 기존 table이 20배 이상 클 때 사용하도록 권하고
있다.
direct path load는 rollback information을 기록하지 않지만, 이 singlerow
option을 사용하면 insert되는 index에 대해 undo 정보를 rollback segment에
기록하게 된다.
그러나, 중간에 instance failure가 발생하면 data는 data save까지는 보존
되지만 index는 여전히 direct load state로 사용할 수 없게 된다.
--- Direct Load State
만약 direct path load가 성공적으로 끝나지 않으면 index는 direct load
state로 된다.
이 index를 통해 조회하고자 하면 다음과 같은 오류가 발생한다.
ORA-01502 : index 'SCOTT.DEPT_PK' is in direct load state.
index가 direct load state로 되는 원인을 구체적으로 살펴보면 다음과 같다.
(1) index가 생성되는 과정에서 space가 부족한 경우
(2) SORTED INDEXES clause가 사용되었으나, 실제 data는 정렬되어 있지 않은
경우
이러한 경우 data는 모두 load가 되고, index만이 direct load state로 된다.
(3) index 생성 도중 instance failure가 발생한 경우
(4) unique index가 지정되어 있는 컬럼에 중복된 data가 load되는 경우
특정 index가 direct load state인지를 확인하는 방법은 다음과 같다.
select index_name, status
from user_indexes
where table_name = TABLE_NAME';
만약 index가 direct load state로 나타나면 그 index는 drop하고 재생성
하여야만 사용할 수 있다. 단, direct load 중에는 모든 index가 direct
load state로 되었다가 load가 성공적으로 끝나면 자동으로 valid로 변경된다.
--- Pre-sorting (SORTED INDEX)
direct load 시 index구성을 위해서 정렬하는 시간을 줄이기 위해 미리 index
column에 대해서 data를 정렬하여 load시킬 수 있다. 이 때 control file 내에
SORTED INDEXES option을 다음과 같이 정의한다.
이 option은 direct path load 시에만 유효하며, 복수 개의 index에 대해서
지정가능하다.
into table table_name SORTED INDEXES (index_names_with_blank)
만약, 기존의 index가 이미 존재한다면, 새로운 key를 일시적으로 저장할 만큼
의 temporary storage가 필요하며, 기존 index가 없는 경우였다면, 이러한
temporary space도 필요하지 않다.
이와 같이 direct path load 시에 index 구성 시에는 기존 데이타가 있는 table에
load하는 경우 space도 추가적으로 들고, load가 완전히 성공적으로 끝나지 않으면
index를 재생성하여야 하므로, 일반적으로 direct path load 전에 미리 table의
index를 제거한 후 load가 모두 끝난 후 재생성하도록 한다.
5. Recovery
direct load는 기존 segment중간에 data를 insert하는 것이 아니라 완전히
새로운 block을 할당받아 정확히 write가 끝난 다음 해당 segment에 포함되기
때문에 instance failure시에는 redo log정보를 필요로 하지 않는다. 그러나
default로 direct load는 redo log에 입력되는 data를 기록하는데 이것은 media
recovery를 위한 것이다. 그러므로 archive log mode가 아니면 direct load에
생성된 redo log 정보는 불필요하게 되므로 NOARCHIVELOG mode시에는 항상
control file내에 UNRECOVERABLE이라는 option을 사용하여 redo log에 redo entry를 기록하지 않도록 한다.
data가 redo log 정보 없이 instance failure시에 data save까지는 보호되는데
반해 index는 무조건 direct load state가 되어 재생성하여야 한다. 그리고 data save이후의 load하고자 하는 table에 할당되었던 extent는 load된 data가
user에게 보여지지는 않지만 extent가 free space로 release되지는 않는다.
6. Integrity Constraints & Triggers
direct path load중 not null, unique, primary key constraint는 enable
상태로 존재한다. not null은 insert시에 check되고 unique는 load후 index를
구성하는 시점에 check된다.
그러나 check constraint와 referential constraint는 load가 시작되면서
disable상태로 된다. 전체 데이타가 load되고 난 후 이렇게 disable된
constraints를 enable시키려면 control file내에 REENABLE이라는 option을
지정하여야 한다. 이 reenable option은 각 constraint마다 지정할 수는 없으며
control file에 한번 지정하면 전체 integrity/check constraint에 영향을
미치게 된다. 만약 reenable되는 과정에서 constraint를 위배하는 data가
발견되면 해당 constraint는 enable되지 못하고 disabled status로 남게 되며,
이렇게 위배된 data를 확인하기 위해서는 reenable clause에 exceptions option을 다음과 같이 추가하면 된다.
reenable [exceptions table_name]
이 때 table_name은 $ORACLE_HOME/rdbms/admin/utlexcpt.sql을 다른
directory로copy하여 table이름을 exceptions가 아닌 다른 이름으로 만들어 수행시키면 된다.
insert trigger도 integrity/check constraint와 같이 direct load가 시작하는
시점에 disable되며, load가 끝나면 자동으로 enable된다. 단 enable되고 나서도
load에 의해 입력된 data에 대해 trigger가 fire되지는 않는다.

Sql loader direct path leaving indexes unusuable

10.2.0.3
redhat 4.5
temp tablespace 6.5 GB
datafile size 33k
I thought in version 10 you can do direct path loads without indexes going unusuable?
i saw this, but we have plenty of temp space.
http://dbasolve.com/OracleError/ora/ORA-01502.txt
Oracle Error:
ORA-01502 Oracle Index in Unusable State
Cause and Solution:
When trying to perform query on Oracle tables with select SQL statement, Oracle returns this error.
The error indicates an attempt has been made to access an index or index partition that has been marked unusable by a direct load or by a DDL operation.
The problem usually happens when using the Direct Path for the SQL*Loader, Direct Load or DDL operations. This requires enough temporary space to build all indexes of the table. If there is no enough space in TEMP tablespace, all rows will still be loaded and imported, but the indices are left with STATUS = 'INVALID'.
Invalid indexes can be checked with down SQL statement.
SQL>SELECT * from USER_INDEXES WHERE STATUS = 'INVALID';
Solution to this error is simple. You can:
1. Drop the specified index and/or recreate the index
2. Rebuild the specified index
3. Rebuild the unusable index partition
Generally, the following SQL manipulation language will be able to rebuild the unusable index:
SQL>ALTER INDEX index_name REBUILD online

Hi Alan,
How big is this table and what sort of indexes are they?
An index update using SQL*Loader unrecoverable direct path load is achieved by an isolated sort followed by a nologging merge of the old index and the new mini-index into a new index segment (this according to seminar notes by Jonathan Lewis). This will conceivably take a long time for a large table / large index.
Performance improvements? Are you loading all records into a new partition?
Cheers,
Colin

ORA-01502

Similar Messages

Maybe you are looking for