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.

Similar Messages

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

  • Raising ora-01426 error while truncating table

    Hi,
    We have a procedure which executes in the following process for few set of tabls
    1. disables the constraints
    2. truncating the tables
    3. enabling the constraints
    but after processing for 5 tables, while truncating the error throws
    BEGIN <procedure name >; END;
    ERROR at line 1:
    ORA-01426: numeric overflow
    ORA-06512: at "<procedurename> ", line 33
    ORA-06512: at line 1
    this line 33 point to execute immeidate 'truncate table < table name>
    Can i know what would be reason for throwing ' numeric overflow' error while truncating table..
    Thanks in advance

    user9080289 wrote:
    thanks.
    My oracle verision is 11gThen you could have the bug described there. Follow the instruction how to workaround (monitoring flush, set stats to low value) or apply the patch #8226471.
    Nicolas.

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

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

  • Party Merge ORA-29861: domain index is marked LOADING/FAILED/UNUSABLE

    Hi gurus,
    i am using 11.5.10.2 on linux.
    while running the party merge concurrent program , we are getting below error, please help.
    Errors in Merge :
    Application: Receivables_
    Error: Merge failed in Receivables (HZ_STAGED_PARTY_SITES ) with the following error message:
    This unexpected SQL error occurred during the merge process :
    ORA-29861: domain index is marked LOADING/FAILED/UNUSABLE
    The following record was being handled when the error occurred :
    Thanks
    RB

    Thanks Hussain, this is similer to the error i got, i will run the steps and get back to you, once again thanks for your prompt responce.
    Thx
    RB
    Edited by: R12DBA on Jul 23, 2010 4:36 PM
    Edited by: R12DBA on Jul 23, 2010 4:50 PM

  • ORA-00604 ORA-00904 When query partitioned table with partitioned indexes

    Got ORA-00604 ORA-00904 When query partitioned table with partitioned indexes in the data warehouse environment.
    Query runs fine when query the partitioned table without partitioned indexes.
    Here is the query.
    SELECT al2.vdc_name, al7.model_series_name, COUNT (DISTINCT (al1.vin)),
    al27.accessory_code
    FROM vlc.veh_vdc_accessorization_fact al1,
    vlc.vdc_dim al2,
    vlc.model_attribute_dim al7,
    vlc.ppo_list_dim al18,
    vlc.ppo_list_indiv_type_dim al23,
    vlc.accy_type_dim al27
    WHERE ( al2.vdc_id = al1.vdc_location_id
    AND al7.model_attribute_id = al1.model_attribute_id
    AND al18.mydppolist_id = al1.ppo_list_id
    AND al23.mydppolist_id = al18.mydppolist_id
    AND al23.mydaccytyp_id = al27.mydaccytyp_id
    AND ( al7.model_series_name IN ('SCION TC', 'SCION XA', 'SCION XB')
    AND al2.vdc_name IN
    ('PORT OF BALTIMORE',
    'PORT OF JACKSONVILLE - LEXUS',
    'PORT OF LONG BEACH',
    'PORT OF NEWARK',
    'PORT OF PORTLAND'
    AND al27.accessory_code IN ('42', '43', '44', '45')
    GROUP BY al2.vdc_name, al7.model_series_name, al27.accessory_code

    I would recommend that you post this at the following OTN forum:
    Database - General
    General Database Discussions
    and perhaps at:
    Oracle Warehouse Builder
    Warehouse Builder
    The Oracle OLAP forum typically does not cover general data warehousing topics.

  • EXCEPTION: ORA-29861: domain index is marked LOADING/FAILED/UNUSABLE

    Hello,
    I'm getting the exception when I go to run the following update statement (via PreparedStatement using JDBC):
    UPDATE my_table SET my_column_1 = ? WHERE my_column_ID = ?
    I searched google and couldn't determine the proper fix for this:
    http://ora-29861.ora-code.com/
    What I do know from SQL Developer:
    my_table has several indexes of which all have a status of "valid"
    my_column_ID has an index on it. the column type for this column is NUMBER(10,0)
    my_column_1 is a VARCHAR2(40 BYTE)
    So I'm uncertain where to go from here and any help would be great.
    Thanks,
    Jim
    Edited by: Jim Atharris on Jun 3, 2009 4:54 PM

    I guess its a problem with the index on my_table. I guess you can first drop the specific index using my_column_id and then try updating the table. After your updates are successful, you can create the index again. I may not be right, but just trying my hand.

  • Ora 14098 Index mismatch for tables  in Alter Exchange Partition

    Hi All,
    I want to exchange data from retek schema to CONV schema. Both the table have same partition, but there is no data in CONV table.
    So I'm populating the data from retek of one particular partition into one staging table and then I'm doing exchanging partition with staging table to CONV table.
    I have created the same index and constraints for staging as there are in CONV table.
    But When I'm doing exchange partition I'm getting error Index mismatch.
    v_parition_name:='mar 2012'
    v_stmt := 'create table staging_tab_st_hist as ( select * from retek.abc_st_hist partition(' ||
    v_parition_name || ') )';
    execute immediate v_stmt;
    v_stmt := ' alter table conv.abc_st_hist exchange partition ' ||
    v_parition_name ||
    ' with table staging_tab_st_hist
    including indexes without validation';
    execute immediate v_stmt;

    Welcome to the forum!
    Whenever you post provide your 4 digit Oracle version (result of SELECT * FROM V$VERSION).
    >
    Hi All,
    I want to exchange data from retek schema to CONV schema. Both the table have same partition, but there is no data in CONV table.
    So I'm populating the data from retek of one particular partition into one staging table and then I'm doing exchanging partition with staging table to CONV table.
    I have created the same index and constraints for staging as there are in CONV table.
    But When I'm doing exchange partition I'm getting error Index mismatch.
    v_parition_name:='mar 2012'
    v_stmt := 'create table staging_tab_st_hist as ( select * from retek.abc_st_hist partition(' ||
    v_parition_name || ') )';
    execute immediate v_stmt;
    v_stmt := ' alter table conv.abc_st_hist exchange partition ' ||
    v_parition_name ||
    ' with table staging_tab_st_hist
    including indexes without validation';
    execute immediate v_stmt;
    >
    I don't see any index creation on the staging table. You said this
    >
    I have created the same index and constraints for staging as there are in CONV table.
    >
    But you didn't create the indexes. When you do the CTAS (create table as select) it only creates the table with the same structure; it doesn't create ANY indexes.
    Add the code to create the necessary indexes after you populate the staging table.

  • Preserving Global indexes on partitioned tables

    Hello,
    we have a 24x7 application where a large number of client processes (around 200) loads details of transactions performed onto an historycal, date partitioned table - Clients are transactional, so they use INSERT + COMMIT for every row.
    We have the need to create an additional index with a unique constraint on a column where the partitioning key cannot be included, therefore this index has been declared global.
    When an old partition is dropped, the global index usually gets unusable, and client processes gets an ORA-01502.
    To avoid this, I have tried the following:
    LOCK TABLE ... IN EXCLUSIVE MODE to make the script wait until there are no pending COMMIT
    ALTER TABLE ... DROP PARTITION ... UPDATE GLOBAL INDEXES PARALLEL to avoin index to be marked UNUSABLE and release the table lock at the end of the operation.
    It seems working fine, as the clients gets locked on their INSERTs for a limited amount of time (apparently just the DROP time) and after that they go on on their activities while the global index is still USABLE and the index updates proceeds for some minutes.
    In the end, my perception is that the UPDATE GLOBAL INDEXES clause behave as an online rebuild, thus leaving other processes working on partition not affected by the DROP with the UNIQUE constraint still active.
    Is there anybody who can confirm me tha my idea is right, and this UPDATE clause is a SAFE way to achieve pratition drop without service interruption or index corruption for transactional clients?
    Many thanks,
    Riccardo

    Hi,
    In fact, only the UPDATE GLOBAL INDEXES clause is pertinent here. here's what happens when you're doign the LOCK/ALTER:
    LOCK TABLE ... IN EXCLUSIVE MODE
    You wait till you get a table lock. All "clients" are enqueued till you acquire the lock, and then stay enqueued till you release it.
    ALTER TABLE ... DROP PARTITION ... UPDATE GLOBAL INDEXES PARALLEL
    You start a DDL statement. So the first thing Oracle does is to COMMIT the current transaction, hence releasing the LOCK you previously acquired explicitly.
    The "clients" resume standard operations, meanwhile the partition is dropped and the global index updated. Once the drop is over, the DDL transaction is commited.Meaning simply: the explicit table locking is useless!
    Yoann.

  • Local index vs global index in partitioned tables

    Hi,
    I want to know the differences between a global and a local index.
    I'm working with partitioned tables about 10 millons rows and 40 partitions.
    I know that when your table is partitioned and your index non-partitioned is possible that
    some database operations make your index unusable and you have tu rebuid it, for example
    when yo truncate a partition your global index results unusable, is there any other operation
    that make the global index unusable??
    I think that the advantage of a global index is that takes less space than a local and is easier to rebuild,
    and the advantage of a local index is that is more effective resolving a query isn't it???
    Any advice and help about local vs global index in partitioned tables will be greatly apreciatted.
    Thanks in advance

    here is the documentation -> http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14220/partconc.htm#sthref2570
    In general, you should use global indexes for OLTP applications and local indexes for data warehousing or DSS applications. Also, whenever possible, you should try to use local indexes because they are easier to manage. When deciding what kind of partitioned index to use, you should consider the following guidelines in order:
    1. If the table partitioning column is a subset of the index keys, use a local index. If this is the case, you are finished. If this is not the case, continue to guideline 2.
    2. If the index is unique, use a global index. If this is the case, you are finished. If this is not the case, continue to guideline 3.
    3. If your priority is manageability, use a local index. If this is the case, you are finished. If this is not the case, continue to guideline 4.
    4. If the application is an OLTP one and users need quick response times, use a global index. If the application is a DSS one and users are more interested in throughput, use a local index.
    Kind regards,
    Tonguç

  • Index and partition not visible !!!

    Hello,
    I am creation a table with partition by range and primary key constraint like
    CREATE TABLE employees
    (employee_id NUMBER(4) NOT NULL,
    last_name VARCHAR2(10),
    department_id NUMBER(2),
    CONSTRAINT SUP_EMP_PK
    PRIMARY KEY
    (employee_id,department_id)
    PARTITION BY RANGE (department_id)
    (PARTITION employees_part1 VALUES LESS THAN (10) TABLESPACE DATA_003_P001_HUB3);
    but when I query the user_ind_partitions as
    select * from user_ind_partitions where partition_name='employee_part1';
    it returns nothing
    Why is this problem coming up?
    Help..
    Regards
    Abhinav

    Actually the problem statement is:
    I have table as :
    CREATE TABLE SUPERVISION_BPS
    ID NUMBER NOT NULL,
    servicetype NUMBER NOT NULL,
    type VARCHAR2(6 BYTE) NOT NULL,
    insertDate DATE NOT NULL,
    filename VARCHAR2(100 BYTE) NOT NULL,
    numberOK NUMBER NOT NULL,
    numberKO NUMBER NOT NULL,
    numberCRE NUMBER NOT NULL,
    numberUPD NUMBER NOT NULL,
    numberDEL NUMBER NOT NULL,
    CONSTRAINT SUP_BPS_PK
    PRIMARY KEY
    (ID, servicetype, type)
    using index local
    TABLESPACE DATA_003_P001_HUB3
    PARTITION BY RANGE (InsertDate)
    PARTITION "PARTITION_LAST" VALUES LESS THAN (MAXVALUE)
    create sequence seq_sup_bps start with 1 increment by 1;
    The problem is whenever I am deleting a partition as
    alter table &1 drop partition &2;
    and rebuilding the partition as:
    alter index &1 parallel;
    alter index &1 rebuild partition &2 compute statistics;
    alter index &1 noparallel;
    based on unused indexes
    select user_ind_partitions.index_name || '|' || user_ind_partitions.partition_name
    from user_indexes, user_ind_partitions
    where user_indexes.index_name=user_ind_partitions.index_name
    and user_ind_partitions.status='UNUSABLE'
    and upper(user_indexes.table_name)='&2';
    Now when the entry for the same primary key takes place, it gives an error putting the same value again.
    Kindly help
    Tried all bit have not found the solution.
    Note: have tried removing UNUSABLE check but how to get it done as per the need.
    Regards
    Abhinav
    Edited by: user8744860 on Jul 2, 2012 2:35 AM

  • Possible to create partitioned index one partition at a time?

    I have a really large partitioned table. Wanted to know if I can create the partitioned index, one partition at a time? Trying to limit the amount of resources required to throw at it. Note this is not a rebuild or reindex operation. This is a brand new index on a multi-terabyte table.
    .. just throwing this out there...
    Thanks for any insights..
    Daryl.

    Daryl E. wrote:
    I have a really large partitioned table. Wanted to know if I can create the partitioned index, one partition at a time? Trying to limit the amount of resources required to throw at it. Note this is not a rebuild or reindex operation. This is a brand new index on a multi-terabyte table.
    You can create the index "unusable", then alter each partition in turn to make it usable.
    The side effects on optimisation and DML may vary with version of Oracle and whether the index is unique or non-unique.
    Regards
    Jonathan Lewis

  • ORA-14314: resulting List partition(s) must contain atleast 1 value

    Hi,
    Using: Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production, Windows 7 Platform.
    I'm trying to understand Exchange Partition and Split (List) partitioning. Below is the code I'm trying to work on:
      CREATE TABLE big_table (
      id            NUMBER(10),
      created_date  DATE,
      lookup_id     NUMBER(10),
      data          VARCHAR2(50)
    declare
      l_lookup_id big_table.lookup_id%type;
      l_create_date date;
    begin
      for i in 1 .. 1000000 loop
        if mod(i,3) = 0 then
           l_create_date := to_date('19-mar-2011','dd-mon-yyyy');
           l_lookup_id := 2;
        elsif mod(i,2) = 0 then
           l_create_date := to_date('19-mar-2012','dd-mon-yyyy');
           l_lookup_id := 1;
        else
           l_create_date := to_date('19-mar-2013','dd-mon-yyyy');
           l_lookup_id := 3;
        end if;
        insert into big_table(id, created_date, lookup_id, data)
           values (i, l_create_date, l_lookup_id, 'This is some data for '||i);
      end loop;
      commit;
    end;
    alter table big_table add (
    constraint big_table_pk primary key (id));
    exec dbms_stats.gather_table_stats(user, 'BIG_TABLE', cascade => true);
    create table big_table2 (
    id number(10),
    created_date date,
    lookup_id number(10),
    data varchar2(50)
    partition by list (created_date)
    (partition p20991231 values (TO_DATE(' 2099-12-31 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')));
    alter table big_table2 add (
    constraint big_table_pk2 primary key(id));
    alter table big_table2 exchange partition p20991231
    with table big_table
    without validation
    update global indexes;
    drop table big_table;
    rename big_table2 to big_table;
    alter table big_table rename constraint big_table_pk2 to big_table_pk;
    alter index big_table_pk2 rename to big_table_pk;
    exec dbms_stats.gather_table_stats(USER, 'BIG_TABLE', cascade => TRUE);
    I'm trying to split the data by moving created_date=19-mar-2013 to new partition p20130319. I tried to run the below query but failed with error. Where am I doing it wrong?
    Thanks.
    alter table big_table
    split partition p20991231 values (to_date('19-mar-2013','dd-mon-yyyy'))
    into (partition p20130319
         ,partition p20991231
    Error report:
    SQL Error: ORA-14314: resulting List partition(s) must contain atleast 1 value
    14314. 00000 -  "resulting List partition(s) must contain atleast 1 value"
    *Cause:    After a SPLIT/DROP VALUE of a list partition, each resulting
               partition(as applicable) must contain at least 1 value
    *Action:   Ensure that each of the resulting partitions contains atleast
               1 value

    I stand corrected.
    Below are the steps I have gone through to understand:
    1. How to partition a table with data in it.
    2. Exchange partition.
    3. Split partition (List).
    4. Split data to more than 2 partitions.
    Please correct me if I'm missing anything.
    CREATE TABLE big_table
        id           NUMBER(10),
        created_date DATE,
        lookup_id    NUMBER(10),
        data         VARCHAR2(50)
    DECLARE
      l_lookup_id big_table.lookup_id%type;
      l_create_date DATE;
    BEGIN
      FOR i IN 1 .. 1000000
      LOOP
        IF mod(i,3)= 0 THEN
          l_create_date := to_date('19-mar-2011','dd-mon-yyyy');
          l_lookup_id   := 2;
        elsif mod(i,2)   = 0 THEN
          l_create_date := to_date('19-mar-2012','dd-mon-yyyy');
          l_lookup_id   := 1;
        ELSE
          l_create_date := to_date('19-mar-2013','dd-mon-yyyy');
          l_lookup_id   := 3;
        END IF;
        INSERT INTO big_table(id, created_date, lookup_id, data)
          VALUES(i, l_create_date, l_lookup_id, 'This is some data for '||i);
      END LOOP;
      COMMIT;
    END;
    ALTER TABLE big_table ADD
    (CONSTRAINT big_table_pk PRIMARY KEY (id));
    EXEC dbms_stats.gather_table_stats(USER, 'BIG_TABLE', CASCADE => true);
    CREATE TABLE big_table2
      ( id           NUMBER(10),
        created_date DATE,
        lookup_id    NUMBER(10),
        data         VARCHAR2(50)
      partition BY list(created_date)
      (partition p0319 VALUES
        (TO_DATE(' 2013-03-19 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN') ,TO_DATE(' 2012-03-19 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN') ,TO_DATE(' 2011-03-19 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    ALTER TABLE big_table2 ADD
    (CONSTRAINT big_table_pk2 PRIMARY KEY(id));
    ALTER TABLE big_table2 exchange partition p0319
    WITH TABLE big_table without validation
    UPDATE global indexes;
    DROP TABLE big_table;
    RENAME big_table2 TO big_table;
    ALTER TABLE big_table RENAME CONSTRAINT big_table_pk2 TO big_table_pk;
    ALTER INDEX big_table_pk2 RENAME TO big_table_pk;
    EXEC dbms_stats.gather_table_stats(USER, 'BIG_TABLE', CASCADE => TRUE);
    SELECT p.partition_name, p.num_rows
    FROM user_tab_partitions p
    WHERE p.table_name = 'BIG_TABLE';
    ALTER TABLE big_table split partition p0319 VALUES
    (TO_DATE(' 2013-03-19 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    INTO (partition p20130319, partition p0319);
    ALTER INDEX big_table_pk rebuild;
    EXEC dbms_stats.gather_table_stats(USER, 'BIG_TABLE', CASCADE => TRUE);
    SELECT p.partition_name, p.num_rows
    FROM user_tab_partitions p
    WHERE table_name = 'BIG_TABLE';
    SELECT DISTINCT created_date FROM big_table partition(p20130319);
    SELECT DISTINCT created_date FROM big_table partition(p0319);
    ALTER TABLE big_table split partition p0319 VALUES
    (TO_DATE(' 2012-03-19 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    INTO (partition p20120319, partition p20110319);
    ALTER INDEX big_table_pk rebuild;
    EXEC dbms_stats.gather_table_stats(USER, 'BIG_TABLE', CASCADE => TRUE);
    SELECT p.partition_name, p.num_rows
    FROM user_tab_partitions p
    WHERE table_name = 'BIG_TABLE';
    SELECT DISTINCT created_date FROM big_table partition(p20130319);
    SELECT DISTINCT created_date FROM big_table partition(p20120319);
    SELECT DISTINCT created_date FROM big_table partition(p20110319);

Maybe you are looking for