Partition Exchange questions

I’m on 10gR2.
1) Is it possible to exchange the partition between two LIST partitioned tables? I know it’s possible to exchange partition between a partitioned table and a non-partitioned table but not sure on two partitioned table. Any one has done this?
2) IF I perform following, what would happen to SELECT that already in progress on the Partitioned table P1? Will it continue or will it be interrupted? Will my result be based on old data or exchanged data? i.e. Read consistency be applied in this case?
ALTER TABLE T1 EXCHANGE PARTITION P1 with table T2
Thanks in advance for your help.

max71 wrote:
I’m on 10gR2.
1) Is it possible to exchange the partition between two LIST partitioned tables? I know it’s possible to exchange partition between a partitioned table and a non-partitioned table but not sure on two partitioned table. Any one has done this?No,
You can exchange a simple table with a partition of a partitioned table.
You can exchange an entire (simple) partitioned table with a single partition of a composite partitioned table. To move a partition from one list-partitioned table to another you will have to do a "double-exchange" (or worse).
e.g. To swap partition pX of table pt1 with partition pY of table pt2:
Create empty simple table T of the right shape
alter table PT1 exchange partition pX with table T
alter table pT2 exchange partition pY with table T
alter table pT1 exchange partition pX with table T
Drop table T
2) IF I perform following, what would happen to SELECT that already in progress on the Partitioned table P1? Will it continue or will it be interrupted? Will my result be based on old data or exchanged data? i.e. Read consistency be applied in this case?
ALTER TABLE T1 EXCHANGE PARTITION P1 with table T2
In simple cases, the result will be correct. Oracle introduced a form of "cross-DDL" read-consistency in Oracle 8.0 for exactly this reason. It is possible (though a little unlikely after so many years) that you might find some bugs in it in complicated cases. I know that in the very early days I had some cases where queries would silently lose partitions after an exchange and give the wrong results.
The thing to watch out for is that the data segments you renamed (and still need current queries to see) do not get over-written. For example, a query against T1 that started just before the exchange you've quote above will want to see the data in the thing that is now table T2 - and that's possible. Even if you drop table T2, the query can still complete safely. But if you drop T3, and then create a new object that overwrites the hole left by T2, the query will crash when it starts to read that space with an error like ORA-01410 invaliid rowid, or something similar.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge." Stephen Hawking.

Similar Messages

Partition Exchange during DMLs

Hello,
This question regarding Partition Exchange during DML operations on 10.2.0.3
I have a table that's RANGE-LIST partitioned as follow. Syntaxt may not be perfact..
CREATE TABLE P_TBL
O_DATE DATE,
DOW NUMBER, -- This actually is TO_NUMBER(TO_CHAR(O_DATE,'D'))
SALE_AMT NUMBER,
PARTITION BY RANGE ( DOW)
SUBPARTITION BY LIST ( STATE)
PARTITION P01 VALUE LESS THAN ( 2)
(SUBPARTITION P01_EAST VALUE ('EAST'),
SUBPARTITION P01_WEST VALUE ('WEST'),
SUBPARTITION P01_NORTH VALUE ('NORTH'),
SUBPARTITION P01_SOUTH VALUE ('SOUTH')
PARTITION P02 VALUE LESS THAN ( 3)
(SUBPARTITION P02_EAST VALUE ('EAST'),
SUBPARTITION P02_WEST VALUE ('WEST'),
SUBPARTITION P02_NORTH VALUE ('NORTH'),
SUBPARTITION P02_SOUTH VALUE ('SOUTH')
PARTITION P07 VALUE LESS THAN ( 8)
(SUBPARTITION P07_EAST VALUE ('EAST'),
SUBPARTITION P07_WEST VALUE ('WEST'),
SUBPARTITION P07_NORTH VALUE ('NORTH'),
SUBPARTITION P07_SOUTH VALUE ('SOUTH')
/Other table (NP_TBL_EAST ) is Non partioned table. with the same columns.
CREATE TABLE NP_TBL_[EAST|WEST|SOUTH|NORTH]
O_DATE DATE,
DOW NUMBER,
SALE_AMT NUMBER,
)Now I have 2 processes,
Process 1:
Continuously INSERT the daily-Data in the P_TBL. Assume it's currently inserting data only in Partition P02 (i.e. Monday Partition )
INSERT INTO P_TBL
(O_DATE, DOW,SALE_AMT..... )
VALUES
(:1,:2, :3.... )
Process 2:
Will swap the previous day's( i.e. Sunday's ) data for each region with Partition Exchange mechanism.
ALTER TABLE P_TBL exchange subpartition P01_EAST with table NP_TBL_EAST;
ALTER TABLE P_TBL exchange subpartition P01_NORTH with table NP_TBL_NORTH;
Now questions:
1) What kind of lock Process 1 & process 2 will aquire?
2) Can any of these two processes have risk of failure due to locking?
Thanks in advance for your help
-Max

Create a dummy partitioned table without constraints and, in a loop that will run for 5 minutes, continuously insert into the table.
While that is running, in a separate session, exchange partitions.
What happens?
And yes I am returning to my instructor role intentionally.
Please report back to the other students the results from your homework assignment. <g>

Problem in Direct Partition Exchange Loading(PEL)

Hi all,
I am facing a problem during execution of a OWB mapping. The map is using direct partition exchange loading. There are one source and one target table in the map. it is very simple.
While the source and target are in the same schema there is no problem. But when they are in different schemas during execution a warning is given. That is:
ResolveTableNameErrorRTV20006;BIA_RTL_INTERFACE"."SALE_SRC
Here BIA_RTL_INTERFACE is source schema and SALE_SRC is source table.
However the source record is going to the target table as required but the same record also exists in the same table after execution which is not desirable for direct PEL. So i think though the loading is done in target but it is not using the direct Partition Exchange Technique.
Is there some kind of special privileage for Partition Exchange Loading when the source and target are in different schemas in the same database? Plase clarify this. Hope i can explain the problem. Waiting for reply.
Thanks & Regards,
Sumanta Das
Kolkata

The error means you are trying to swap a partition that still contains data in a configuration where OWB expects an empty partition. How did you set the "Replace existing data in Target Partition" configuration parameter?
Also, for more details on PEL, review the 10.19 to 10.27 pages of the user manual.
Regards:
Igor

Primary Key Causing Problem in Interval Partition Exchange

DB : 11.2.0.2
OS : AIX 6.1
I am getting the problem while exchanging data with interval partitioned table. I have a interval partitioned table and a normal staging table having data to be uploaded.
Following are the steps i am doing.
SQL> CREATE TABLE DEMO_INTERVAL_DATA_LOAD (
                ROLL_NUM        NUMBER(10),
                CLASS_ID        NUMBER(2),
                ADMISSION_DATE DATE,
                TOTAL_FEE       NUMBER(4),
                COURSE_ID       NUMBER(4))
                PARTITION BY RANGE (ADMISSION_DATE)
                INTERVAL (NUMTOYMINTERVAL(3,'MONTH'))
                ( PARTITION QUAT_1_2012 VALUES LESS THAN (TO_DATE('01-APR-2012','DD-MON-YYYY')),
                 PARTITION QUAT_2_2012 VALUES LESS THAN (TO_DATE('01-JUL-2012','DD-MON-YYYY')),
                 PARTITION QUAT_3_2012 VALUES LESS THAN (TO_DATE('01-OCT-2012','DD-MON-YYYY')),
                 PARTITION QUAT_4_2012 VALUES LESS THAN (TO_DATE('01-JAN-2013','DD-MON-YYYY')));
Table created.
SQL> ALTER TABLE DEMO_INTERVAL_DATA_LOAD ADD CONSTRAINT IDX_DEMO_ROLL PRIMARY KEY (ROLL_NUM);
Table altered.
SQL> SELECT TABLE_OWNER,
           TABLE_NAME,
           COMPOSITE,
           PARTITION_NAME,
       PARTITION_POSITION,
          TABLESPACE_NAME,
       LAST_ANALYZED
FROM DBA_TAB_PARTITIONS
    WHERE TABLE_OWNER='SCOTT'
   AND TABLE_NAME='DEMO_INTERVAL_DATA_LOAD'
   ORDER BY PARTITION_POSITION;
TABLE_OWNER                    TABLE_NAME                     COM PARTITION_NAME                 PARTITION_POSITION TABLESPACE_NAME                LAST_ANAL
SCOTT                          DEMO_INTERVAL_DATA_LOAD        NO QUAT_1_2012                                     1 USERS
SCOTT                          DEMO_INTERVAL_DATA_LOAD        NO QUAT_2_2012                                     2 USERS
SCOTT                          DEMO_INTERVAL_DATA_LOAD        NO QUAT_3_2012                                     3 USERS
SCOTT                          DEMO_INTERVAL_DATA_LOAD        NO QUAT_4_2012                                     4 USERS
SQL> INSERT INTO DEMO_INTERVAL_DATA_LOAD VALUES (10,1,'12-MAR-2012',1000,90);
1 row created.
SQL> INSERT INTO DEMO_INTERVAL_DATA_LOAD VALUES (11,5,'01-JUN-2012',5000,80);
1 row created.
SQL> INSERT INTO DEMO_INTERVAL_DATA_LOAD VALUES (12,9,'12-SEP-2012',4000,20);
1 row created.
SQL> INSERT INTO DEMO_INTERVAL_DATA_LOAD VALUES (13,7,'29-DEC-2012',7000,10);
1 row created.
SQL> INSERT INTO DEMO_INTERVAL_DATA_LOAD VALUES (14,8,'21-JAN-2013',2000,50); ---- This row will create a new interval partition in table.
1 row created.
SQL> commit;
SQL> SELECT TABLE_OWNER,
        TABLE_NAME,
        COMPOSITE,
        PARTITION_NAME,
        PARTITION_POSITION,
        TABLESPACE_NAME,
        LAST_ANALYZED
FROM DBA_TAB_PARTITIONS
     WHERE TABLE_OWNER='SCOTT'
   AND TABLE_NAME='DEMO_INTERVAL_DATA_LOAD'
   ORDER BY PARTITION_POSITION;
TABLE_OWNER                    TABLE_NAME                     COM PARTITION_NAME                 PARTITION_POSITION TABLESPACE_NAME                LAST_ANAL
SCOTT                          DEMO_INTERVAL_DATA_LOAD        NO QUAT_1_2012                                     1 USERS
SCOTT                          DEMO_INTERVAL_DATA_LOAD        NO QUAT_2_2012                                     2 USERS
SCOTT                          DEMO_INTERVAL_DATA_LOAD        NO QUAT_3_2012                                     3 USERS
SCOTT                          DEMO_INTERVAL_DATA_LOAD        NO QUAT_4_2012                                     4 USERS
SCOTT                          DEMO_INTERVAL_DATA_LOAD        NO SYS_P98                                         5 USERS
SYS_P98 partition is added to table automatically.
SQL> CREATE TABLE DEMO_INTERVAL_DATA_LOAD_Y (
                ROLL_NUM        NUMBER(10),
                CLASS_ID        NUMBER(2),
                ADMISSION_DATE DATE,
                TOTAL_FEE       NUMBER(4),
                COURSE_ID       NUMBER(4));
Table created.
SQL> INSERT INTO DEMO_INTERVAL_DATA_LOAD_Y VALUES (30,3,'21-MAY-2013',2000,12);
1 row created.
SQL> commit;
Commit complete.
Since, i need a partition in DEMO_INTERVAL_DATA_LOAD table, which can be used in partition exchange, so i create a new partition as below:
SQL> LOCK TABLE DEMO_INTERVAL_DATA_LOAD PARTITION FOR (TO_DATE('01-APR-2013','DD-MON-YYYY')) IN SHARE MODE;
Table(s) Locked.
SQL> SELECT TABLE_OWNER,
           TABLE_NAME,
           COMPOSITE,
           PARTITION_NAME,
           PARTITION_POSITION,
           TABLESPACE_NAME,
           LAST_ANALYZED
FROM DBA_TAB_PARTITIONS
    WHERE TABLE_OWNER='SCOTT'
   AND TABLE_NAME='DEMO_INTERVAL_DATA_LOAD'
   ORDER BY PARTITION_POSITION;
TABLE_OWNER                    TABLE_NAME                     COM PARTITION_NAME                 PARTITION_POSITION TABLESPACE_NAME                LAST_ANAL
SCOTT                          DEMO_INTERVAL_DATA_LOAD        NO QUAT_1_2012                                     1 USERS
SCOTT                          DEMO_INTERVAL_DATA_LOAD        NO QUAT_2_2012                                     2 USERS
SCOTT                          DEMO_INTERVAL_DATA_LOAD        NO QUAT_3_2012                                     3 USERS
SCOTT                          DEMO_INTERVAL_DATA_LOAD        NO QUAT_4_2012                                     4 USERS
SCOTT                          DEMO_INTERVAL_DATA_LOAD        NO SYS_P98                                         5 USERS
SCOTT                          DEMO_INTERVAL_DATA_LOAD        NO SYS_P102                                        6 USERS
SQL> ALTER TABLE DEMO_INTERVAL_DATA_LOAD
EXCHANGE PARTITION SYS_P102
WITH TABLE DEMO_INTERVAL_DATA_LOAD_Y
INCLUDING INDEXES
WITH VALIDATION;
ALTER TABLE DEMO_INTERVAL_DATA_LOAD
ERROR at line 1:
ORA-14097: column type or size mismatch in ALTER TABLE EXCHANGE PARTITIONNow, if i disable/drop the primary key constraint, it works without any problem.
SQL> alter table DEMO_INTERVAL_DATA_LOAD disable constraint IDX_DEMO_ROLL;
Table altered.
SQL> alter table DEMO_INTERVAL_DATA_LOAD drop constraint IDX_DEMO_ROLL;
Table altered.
SQL> ALTER TABLE DEMO_INTERVAL_DATA_LOAD
EXCHANGE PARTITION SYS_P102
WITH TABLE DEMO_INTERVAL_DATA_LOAD_Y
INCLUDING INDEXES
WITH VALIDATION;
Table altered.
SQL> select * from DEMO_INTERVAL_DATA_LOAD partition (SYS_P102);
ROLL_NUM   CLASS_ID ADMISSION TOTAL_FEE COURSE_ID
        30          3 21-MAY-13       2000         12
SQL> select * from DEMO_INTERVAL_DATA_LOAD_Y;
no rows selectedPlease suggest.

First, thanks for posting the code that lets us reproduce your test. That is essential for issues like this.
Because the primary key is global you will not be able to use
INCLUDING INDEXES
WITH VALIDATION;And you will need to add the primary key to the temp table
ALTER TABLE DEMO_INTERVAL_DATA_LOAD_Y ADD CONSTRAINT IDX_DEMO_ROLL_Y PRIMARY KEY (ROLL_NUM);The the exchange will work. You will need to rebuild the primary key after the exchange.

Explain plan changing after partition exchange

I currently have a data warehouse where I use partition exchange to refresh the data. I'm finding that after a partition exchange of exactly the same data. explain plan changes.
database 11.2.0.2
To demonstrate what I'm doing I simplified the steps.
first I gather stats on the table that will be exchanged and run explain plan
exec dbms_stats.gather_table_stats( ownname=> 'IDW_TARGET', tabname=> 'PROGRAM_DIM' );
Select
FROM IDW_TARGET.ITD_MONTHLY_SUMMARY_FACT A,
IDW_TARGET.GL_PERIOD_DIM B,
IDW_TARGET.PROGRAM_DIM C,
IDW_TARGET.RPT_ENTITY_DIM D
WHERE ASST_SEC_CONCISE_NAME = 'abc'
AND A.GL_PERIOD_KEY = B.KEY
AND A.PROGRAM_KEY = C.KEY
AND A.RPT_ENTITY_KEY = D.KEY
AND B.PERIOD_YEAR >= 2006;
** uses FTS on fact table and runs in 20 seconds. **
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 25M| 71G| 47105 (1)| 00:09:26 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10003 | 25M| 71G| 47105 (1)| 00:09:26 | | | Q1,03 | P->S | QC (RAND) |
|* 3 | HASH JOIN | | 25M| 71G| 47105 (1)| 00:09:26 | | | Q1,03 | PCWP | |
| 4 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 5 | PX RECEIVE | | 4551 | 1773K| 103 (0)| 00:00:02 | | | Q1,03 | PCWP | |
| 6 | PX SEND BROADCAST | :TQ10000 | 4551 | 1773K| 103 (0)| 00:00:02 | | | | S->P | BROADCAST |
| 7 | PARTITION RANGE SINGLE | | 4551 | 1773K| 103 (0)| 00:00:02 | 1 | 1 | | | |
| 8 | TABLE ACCESS FULL | RPT_ENTITY_DIM | 4551 | 1773K| 103 (0)| 00:00:02 | 1 | 1 | | | |
|* 9 | HASH JOIN | | 25M| 61G| 46999 (1)| 00:09:24 | | | Q1,03 | PCWP | |
| 10 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 11 | PX RECEIVE | | 184 | 35696 | 5 (0)| 00:00:01 | | | Q1,03 | PCWP | |
| 12 | PX SEND BROADCAST | :TQ10001 | 184 | 35696 | 5 (0)| 00:00:01 | | | | S->P | BROADCAST |
| 13 | PARTITION RANGE SINGLE | | 184 | 35696 | 5 (0)| 00:00:01 | 1 | 1 | | | |
|* 14 | TABLE ACCESS FULL | GL_PERIOD_DIM | 184 | 35696 | 5 (0)| 00:00:01 | 1 | 1 | | | |
|* 15 | HASH JOIN | | 25M| 57G| 46992 (1)| 00:09:24 | | | Q1,03 | PCWP | |
| 16 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 17 | PX RECEIVE | | 4085 | 6829K| 1334 (1)| 00:00:17 | | | Q1,03 | PCWP | |
| 18 | PX SEND BROADCAST | :TQ10002 | 4085 | 6829K| 1334 (1)| 00:00:17 | | | | S->P | BROADCAST |
| 19 | PARTITION RANGE SINGLE| | 4085 | 6829K| 1334 (1)| 00:00:17 | 1 | 1 | | | |
|* 20 | TABLE ACCESS FULL | PROGRAM_DIM | 4085 | 6829K| 1334 (1)| 00:00:17 | 1 | 1 | | | |
| 21 | PX BLOCK ITERATOR | | 71M| 45G| 45650 (1)| 00:09:08 | 1 | LAST | Q1,03 | PCWC | |
| 22 | TABLE ACCESS FULL | ITD_MONTHLY_SUMMARY_FACT | 71M| 45G| 45650 (1)| 00:09:08 | 1 | 141 | Q1,03 | PCWP | |
Predicate Information (identified by operation id):
3 - access("A"."RPT_ENTITY_KEY"="D"."KEY")
9 - access("A"."GL_PERIOD_KEY"="B"."KEY")
14 - filter("B"."PERIOD_YEAR">=2006)
15 - access("A"."PROGRAM_KEY"="C"."KEY")
20 - filter("ASST_SEC_CONCISE_NAME"='abc'')
drop table PELPROGRAMDIMALLDATA; -- Start fresh here and drop the partition that will be exchanged
create table PELPROGRAMDIMALLDATA as select * from PROGRAM_DIM; -- going to use exact same data for partition exchange (only one parition)
alter table PELPROGRAMDIMALLDATA add constraint CON_342 unique ("VALUE" ) using index ;
alter table PELPROGRAMDIMALLDATA add constraint CON_343 primary key ("KEY" ) using index ;
exec dbms_stats.gather_table_stats(ownname=>'IDW_TARGET', tabname=>'PELPROGRAMDIMALLDATA');
alter table PROGRAM_DIM exchange partition ALL_DATA with table PELPROGRAMDIMALLDATA excluding indexes;
** rebuild indexes **
** explain plan for same statement uses nested loop**
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 2637K| 7514M| 33428 (1)| 00:06:42 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10003 | 2637K| 7514M| 33428 (1)| 00:06:42 | | | Q1,03 | P->S | QC (RAND) |
|* 3 | HASH JOIN | | 2637K| 7514M| 33428 (1)| 00:06:42 | | | Q1,03 | PCWP | |
| 4 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 5 | PX RECEIVE | | 4551 | 1773K| 103 (0)| 00:00:02 | | | Q1,03 | PCWP | |
| 6 | PX SEND BROADCAST | :TQ10000 | 4551 | 1773K| 103 (0)| 00:00:02 | | | | S->P | BROADCAST |
| 7 | PARTITION RANGE SINGLE | | 4551 | 1773K| 103 (0)| 00:00:02 | 1 | 1 | | | |
| 8 | TABLE ACCESS FULL | RPT_ENTITY_DIM | 4551 | 1773K| 103 (0)| 00:00:02 | 1 | 1 | | | |
|* 9 | HASH JOIN | | 2637K| 6511M| 33324 (1)| 00:06:40 | | | Q1,03 | PCWP | |
| 10 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 11 | PX RECEIVE | | 184 | 35696 | 5 (0)| 00:00:01 | | | Q1,03 | PCWP | |
| 12 | PX SEND BROADCAST | :TQ10001 | 184 | 35696 | 5 (0)| 00:00:01 | | | | S->P | BROADCAST |
| 13 | PARTITION RANGE SINGLE | | 184 | 35696 | 5 (0)| 00:00:01 | 1 | 1 | | | |
|* 14 | TABLE ACCESS FULL | GL_PERIOD_DIM | 184 | 35696 | 5 (0)| 00:00:01 | 1 | 1 | | | |
| 15 | NESTED LOOPS | | 2642K| 6035M| 33318 (1)| 00:06:40 | | | Q1,03 | PCWP | |
| 16 | BUFFER SORT | | | | | | | | Q1,03 | PCWC | |
| 17 | PX RECEIVE | | | | | | | | Q1,03 | PCWP | |
| 18 | PX SEND ROUND-ROBIN | :TQ10002 | | | | | | | | S->P | RND-ROBIN |
| 19 | PARTITION RANGE SINGLE | | 420 | 702K| 220 (0)| 00:00:03 | 1 | 1 | | | |
| 20 | TABLE ACCESS BY LOCAL INDEX ROWID| PROGRAM_DIM | 420 | 702K| 220 (0)| 00:00:03 | 1 | 1 | | | |
|* 21 | INDEX RANGE SCAN | PROGRAM_DIM_IX20 | 420 | | 3 (0)| 00:00:01 | 1 | 1 | | | |
| 22 | PARTITION RANGE ALL | | 6299 | 4201K| 33318 (1)| 00:06:40 | 1 | 9 | Q1,03 | PCWP | |
| 23 | PARTITION LIST ALL | | 6299 | 4201K| 33318 (1)| 00:06:40 | 1 | LAST | Q1,03 | PCWP | |
| 24 | TABLE ACCESS BY LOCAL INDEX ROWID | ITD_MONTHLY_SUMMARY_FACT | 6299 | 4201K| 33318 (1)| 00:06:40 | 1 | 141 | Q1,03 | PCWP | |
| 25 | BITMAP CONVERSION TO ROWIDS | | | | | | | | Q1,03 | PCWP | |
|* 26 | BITMAP INDEX SINGLE VALUE | ITD_MONTHLY_SUMMARY_SK09 | | | | | 1 | 141 | Q1,03 | PCWP | |
Predicate Information (identified by operation id):
3 - access("A"."RPT_ENTITY_KEY"="D"."KEY")
9 - access("A"."GL_PERIOD_KEY"="B"."KEY")
14 - filter("B"."PERIOD_YEAR">=2006)
21 - access("ASST_SEC_CONCISE_NAME"='abc')
26 - access("A"."PROGRAM_KEY"="C"."KEY")
exec dbms_stats.gather_table_stats( ownname=> 'IDW_TARGET', tabname=> 'PROGRAM_DIM' );
** explain plan for same statement uses full table scan**
see first explain plan
Since the stats were not gathered after the partition exchange I would imagine that they would still be used.
Edited by: user12198207 on Feb 7, 2012 8:13 AM
Edited by: user12198207 on Feb 7, 2012 9:47 AM

Locking stats did not make any difference. Also, I deleted the stats at the global level leaving just partition stats and it continued to use the nested loop which takes 15+ minutes instead of 20 seconds with the FTS.
In my original situation it listed the stats at the global level as stale after the partition exchange. But after I removed many of the steps and use just what's described in this posts.
select * from dba_tab_statistics
where table_name='PROGRAM_DIM';
shows stale stats=no for both global and partition. Kind of unexpected. Further digging in shows that is just determined by a case statement.
from dba_tab_statistics view ddl
case
when t.analyzetime is null then null
when ((m.inserts + m.deletes + m.updates) >
t.rowcnt *
to_number(DBMS_STATS.GET_PREFS('STALE_PERCENT',
u.name, o.name))/100 or
bitand(m.flags,1) = 1) then 'YES'
else 'NO'
end

Partition exchange loading for specific subpartitions

Hi All,
Looking at an archive strategy - where we have to archive a specific dataset.
Rather than a insert/delete routine - I was thinking of using partition exchange.
The to-be archived table is interval range partitioned on date, with a list subpartition on country.
It is for specific countries that I want to partition exchange.
    create table
    test_table
    (tbl_id number,
    country varchar2(2),
    sales_dt date,
    volume number)
    partition by range (sales_dt) interval (NUMTOYMINTERVAL(1,'Month'))
    subpartition by list (country)
    Subpartition template
    (subpartition p_ireland values ('IR'),
    subpartition p_france values ('FR'),
    subpartition p_other values (DEFAULT))
    (partition before_2008 values less than (to_date('01-JAN-2008','DD-MON-YYYY'))); The data loaded falls into the partitions and subpartitions correctly. All the partitions names are system generated.
When I come to partition exchange for all the 'FR' subpartitions- I can't determine the logic.
Using
    Alter table test_table
    exchange subpartition system_generated_name
    with table TEST_TABLE_ARCH;I can swap out a specific 'known' subpartition.
I know you can use the 'for' logic with Oracle 11g but can't get the syntax to work.
Any ideas?

The error means you are trying to swap a partition that still contains data in a configuration where OWB expects an empty partition. How did you set the "Replace existing data in Target Partition" configuration parameter?
Also, for more details on PEL, review the 10.19 to 10.27 pages of the user manual.
Regards:
Igor

Partition Exchange Loading

Have anyone had success with this feature in OWB? I've just attempted it but got an "ORA-12841: Cannot alter the session parallel DML state within a transaction". Is there a property somewhere to stop it from generating these alter sessions stmt?
TIA
Hong
Environment:
OWB version 9.0.2.62.3
Oracle9i EE 9.0.1.3.0
Solaris 2.7

There is a number of restrictions when using Partition Exchange, please check these conditions are true:
- The partition you are loading into is empty,
- The index is local (i.e. every partition has it's own index),
- All the data you are loading fits into the partition (this is a primary suspect in your case),
- Loading tipe is INSERT (DELETE/INSERT, TRUNCATE/INSERT, CHECK/INSERT should work bu you can get warnings during generation),
Regards:
Igor

Partition Exchange Loading (PEL)

Hi everyone,
I'm trying to set up a mapping in Oracle Warehouse Builder 9.0.4 to use Partition Exchange Loading.
When running, I get the warning: PELWarningRTV1003
Does anyone know what this message means, and where I can find information about such error messages?
Thanks for your help!
Best regards,
Ronald Ommundsen

The error means you are trying to swap a partition that still contains data in a configuration where OWB expects an empty partition. How did you set the "Replace existing data in Target Partition" configuration parameter?
Also, for more details on PEL, review the 10.19 to 10.27 pages of the user manual.
Regards:
Igor

Virtual column and partition exchange load

Hi All,
Can someone tell me that if i have a virtual column on a table in 11g then can we load the data as partition exchange loading into the table.
Thanks & Regards,
Ankit Rana

Hemant K Chitale wrote:
Why not run a simple test with a dummy table, a few columns (plus a virtual column) and a few partitions ?
Excellent suggestion.
Shouldn't take more than about 30 minutes to create a test case - and if it takes more than 30 minutes the OP needs the practice anyway to get a better feel for the technology.
Hint to OP: make sure you put some data in the "incoming" table, make sure you put some data in the "non-exchanged" partitions, remember to include a unique/pk constraint if you're expecting one on production, and run with sql_trace enabled to see what's happening in the background.
Regards
Jonathan Lewis

Partition Exchange Issue

Hello,
When I am trying to do a partition exchange between one unpartitioned and partitioned table I am getting the following error
ORA-08103: object no longer exists
The indexes of the two table matches. I donot know what caused this problem. Can you please help me in resolving this??
Thanks
Sathish

Hi,
Check Metalink for this.
There are a lot of bugs related to this error.
Also check this blog.
Best Regards,
Alex

Partition Exchange Load in same schema

Hi all,
If my source and target tables are in different schema but table's structures are same. Can I apply Direct partition exchange load (PEL) in my mapping using OWB. Plz help me......
Thank & Regards
Soumen

Hemant K Chitale wrote:
Why not run a simple test with a dummy table, a few columns (plus a virtual column) and a few partitions ?
Excellent suggestion.
Shouldn't take more than about 30 minutes to create a test case - and if it takes more than 30 minutes the OP needs the practice anyway to get a better feel for the technology.
Hint to OP: make sure you put some data in the "incoming" table, make sure you put some data in the "non-exchanged" partitions, remember to include a unique/pk constraint if you're expecting one on production, and run with sql_trace enabled to see what's happening in the background.
Regards
Jonathan Lewis

Automating partition exchange

I am looking to automate a partition exchange process because I am changing a column
from a date to a timestamp.
For each parition in a table I want to do the following steps:
1. PEX: SRC_TBL to TEMP_TBL
2. Make the date to timestamp change on the TEMP_TBL
3. PEX: TEMP_TBL to DEST_TBL
4. Prepare the TEMP_TBL for the next cycle - change the timestamp back to date
CREATE OR REPLACE PROCEDURE test1.history_pex_proc
(OWNER in VARCHAR2(25)
SRC_TBL in VARCHAR2(25),
TEMP_TBL in VARCHAR2(25),
DEST_TBL in VARCHAR2(25))
-- Table name and owner can be hard coded.
for x in ( SELECT * FROM dba_tab_partitions WHERE
table_name = SRC_TBL AND
table_owner = OWNER)
loop
sql_stmt='ALTER TABLE OWNER.SRC_TBL EXCHANGE PARTITION x.partition_name WITH TABLE OWNER.TEMP_TBL WITHOUT VALIDATION;'
execute immediate sql_stmt ;
sql_stmt='ALTER TABLE OWNER.TEMP_TBL MODIFY(QUEUE_DATE TIMESTAMP(3));'
execute immediate sql_stmt ;
sql_stmt='ALTER TABLE OWNER.DEST_TBL EXCHANGE PARTITION x.partition_name WITH TABLE OWNER.TEMP_TBL WITHOUT VALIDATION;'
execute immediate sql_stmt ;
sql_stmt='TRUNCATE TABLE OWNER.TEMP_TBL ;'
execute immediate sql_stmt ;
sql_stmt='ALTER TABLE OWNER.TEMP_TBL MODIFY(QUEUE_DATE DATE);'
execute immediate sql_stmt ;
sql_stmt='commit;'
execute immediate sql_stmt ;
end loop
Is there a more efficient way to execute the commands other than using execute immediate sql_stmt after every command? I have about 300 partitions to exchange and the size of my tables is approx 3Tb's so I want to get this done as quick and as efficeintly as possible

Create a dummy partitioned table without constraints and, in a loop that will run for 5 minutes, continuously insert into the table.
While that is running, in a separate session, exchange partitions.
What happens?
And yes I am returning to my instructor role intentionally.
Please report back to the other students the results from your homework assignment. <g>

Partition exchange failure

(Oracle 10g R1 on zLinux) I've got a large partitioned table with some partitions that are almost empty (but still claiming large amounts of blocks). To do some partition exchanging I created a second table that has exactly the same column layout (I used the create script from the large table without the partition directives and I tried a 'create table .. as select * from big-table) without any indexes. Fot the indexes(the plan was to re-create them when the exchanges were done.
Now when I start the partition exchange using:
ALTER TABLE ahd_request
EXCHANGE PARTITION tm2002
WITH TABLE ahd_request_small
I get the message 'ORA-14097: column type or size mismatch in ALTER TABLE EXCHANGE PARTITION'
Any ideas wether or not this is a bug or am I missing something obivous?
tia
Martin

Please check two tables are absolutely in sync with
each other. In terms of columns and data type.That was the easy part (the query is supplied in the meta link documents).
After that it gets more complicated because you have to check for (deleted) Function Based Indexes, Unused Columns etc. which do not show up but create/hide hidden columns etc.
Believe me, I'm way beyond simple structure checking and will follow the only advise I haven't tried yet (from Oracle that is): dump and reload.
regards,
Martin

Partitions Related Questionn...

Hi All,
I want to move a partition from one table to another temporary table, by retaining the actual copy of the data in the initial table as well... Is it possible.... Howw,, Any documentationnn??
What happens when we move a partition?? Does the partition goes into read-mode only automaticallyy... As when this movement is happening, is it possible to insert the data in the partition simoultaneouslyy...
Are there anyy online documentss available through whichh i can grill more into Partitioning Conceptss... I have gone through the basic concepts of the partitioningg...
Thanks in Advance...

rahul12289471 wrote:
What happens when we move a partition?? The partition contents do not move - merely the ownership. With a partition exchange, the owner of the table data is swapped with the owner of the partitioned data. So the table now owns the partition data (and indexes) and the partition owns the table's data (and indexes).
The actual data does not move. Which is why exchanging a 1TB partition is as efficient (fast) as exchanging a 0 byte partition. And why this makes a very effective means of managing data in partition sets.
As there is no copying/moving of data involved, you cannot "retain" a copy of the data. To make a copy means requiring I/O to read the entire partitioned data set (all 1TB if that is the case) and then duplicating that (writing 1TB of data if that is the case).
Also keep in mind that duplicating data sets in a RDBMS is usually a silly and wrong thing to do. Relational design and relational databases are all about eliminating the need to duplicate data and then programatically maintain these duplicate data sets.
I/O is also the slowest and thus most expensive operation on a database. Why would you want to contribute to that, slowing down the database and server, by doing totally redundant I/O by reading and writing the exact same data multiple times?

Partition Exchange

We are in the process of moving data from regular tables to partition tables. The scheme is to make the partition tables first and then insert the data from its parent original table to these new partition tables. My understanding is that, partition exchange only occurs between a table and a selected partition and vice versa. Since the original table has data which would move to separate partitions, how it could be accomplished by exchange.
Here is an example. The original TABLE is Called X and it has data on column(Y), 1, 2, 3, 4, ...... We built a partition table PARTX on column Y with Partition_1, partition_2, partition_3 etc. Now can we use the partition exchange for it ? If not what would be a good startegy to transfer the data.
Thanks.

user6116850 wrote:
Here is an example. The original TABLE is Called X and it has data on column(Y), 1, 2, 3, 4, ...... We built a partition table PARTX on column Y with Partition_1, partition_2, partition_3 etc.The basic requirements for a partition exchange is that the table and partitioned table must have the same structure and same indexes. (i.e. the table's indexes must match the local partitioned indexes).
Also, it is not a transfer of data. The table owns the data and indexes of X. The partitioned table owns the data and indexes of partition PARTX. The partition exchange simply changes ownership. The partition now owns the table's data and indexes and vice versa.
As this in an exchange of ownership, it is a very effective method of swapping GBs (or even TBs) of data in and out of a partitioned table within milliseconds. In other words, a very effective data management tool.
Now can we use the partition exchange for it ? If not what would be a good startegy to transfer the data.That depends on what problem you are trying to solve and what requirement you are trying to address... The requirement dictates which tool to use.
I suggest you read chapter 18 of the [Oracle® Database Concepts|http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/partconc.htm] guide that deals with partitioned tables and indexes.

Partition Exchange questions

Similar Messages

Maybe you are looking for