Is it possible a partition table create a partition itself?

Hi,
I migrated a table to range partition table by years on production system.
But I thought, after the new year 2011 must I add new partition again for year 2011?
For example,
When a new record comes for year 2011 and if there is no partition for 2011 the table should be create new partition for 2011 itself?
Every year must I add new partition myself? this is a time consuming job.
Yes. I know MAXVALUE but I don't want to use it. I want to be done automatically.
regards,

Hi,
I haven't tried EXECUTE_IMMEDIATE. It doesn't matter because I haven't found how the partition name concatenate a variable automatically.
DB version is 10.2.0.1.
table script is:
CREATE TABLE INVOICE_PART1
ID NUMBER(10) NOT NULL,
PREPARED DATE NOT NULL,
TOTAL NUMBER,
FINAL VARCHAR2(1 BYTE),
NOTE VARCHAR2(240 BYTE),
CREATED DATE NOT NULL,
CREATOR VARCHAR2(8 BYTE) NOT NULL,
TABLESPACE PROD
PCTUSED 40
PCTFREE 10
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 1M
NEXT 1M
MINEXTENTS 1
MAXEXTENTS 2147483645
PCTINCREASE 0
LOGGING
PARTITION BY RANGE (CREATED)
PARTITION INV08 VALUES LESS THAN (TO_DATE(' 2010-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
NOCOMPRESS
TABLESPACE PROD
PCTUSED 40
PCTFREE 10
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 1M
NEXT 1M
MINEXTENTS 1
MAXEXTENTS 2147483645
PCTINCREASE 0
FREELISTS 1
FREELIST GROUPS 1
BUFFER_POOL DEFAULT
PARTITION INV09 VALUES LESS THAN (TO_DATE(' 2010-10-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
NOCOMPRESS
TABLESPACE PROD
PCTUSED 40
PCTFREE 10
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 1M
NEXT 1M
MINEXTENTS 1
MAXEXTENTS 2147483645
PCTINCREASE 0
FREELISTS 1
FREELIST GROUPS 1
BUFFER_POOL DEFAULT
PARTITION INV10 VALUES LESS THAN (TO_DATE(' 2010-11-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
NOCOMPRESS
TABLESPACE PROD
PCTUSED 40
PCTFREE 10
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 1M
NEXT 1M
MINEXTENTS 1
MAXEXTENTS 2147483645
PCTINCREASE 0
FREELISTS 1
FREELIST GROUPS 1
BUFFER_POOL DEFAULT
PARTITION INV VALUES LESS THAN (MAXVALUE)
LOGGING
NOCOMPRESS
TABLESPACE PROD
PCTUSED 40
PCTFREE 10
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 1M
NEXT 1M
MINEXTENTS 1
MAXEXTENTS 2147483645
PCTINCREASE 0
FREELISTS 1
FREELIST GROUPS 1
BUFFER_POOL DEFAULT
NOCOMPRESS
NOCACHE
NOPARALLEL
MONITORING
ENABLE ROW MOVEMENT;

Similar Messages

Alter range partition table to Interval partitioning table.

Hi DBA's,
I have a very big range partitioned table.
Recently we have upgraded our database to 11gR2 which has a feautre called interval partitioning.
Now i want to modify that existing range partitioned table to Interval Partitioning.
can we alter the range partitioned table to interval partitioning table?
I googled for the syntax but i didn't find it, can any one help[ me out on this?
Thanks.

If you ignore the "alter session set NLS_CALENDAR=PERSIAN;" during create/alter, everything else seems to work.
When you set the "alter session..." during inserts, the rows gets inserted into the correct partitions.
Only thing is when you look at HIGH_VALUE, you need to convert from the default GREGORIAN to PERSIAN.

Modify HUGE HASH partition table to RANGE partition and HASH subpartition

I have a table with 130,000,000 rows hash partitioned as below
----RANGE PARTITION--
CREATE TABLE TEST_PART(
C_NBR CHAR(12),
YRMO_NBR NUMBER(6),
LINE_ID CHAR(2))
PARTITION BY RANGE (YRMO_NBR)(
PARTITION TEST_PART_200009 VALUES LESS THAN(200009),
PARTITION TEST_PART_200010 VALUES LESS THAN(200010),
PARTITION TEST_PART_200011 VALUES LESS THAN(200011),
PARTITION TEST_PART_MAX VALUES LESS THAN(MAXVALUE)
CREATE INDEX TEST_PART_IX_001 ON TEST_PART(C_NBR, LINE_ID);
Data: -
INSERT INTO TEST_PART
VALUES ('2000',200001,'CM');
INSERT INTO TEST_PART
VALUES ('2000',200009,'CM');
INSERT INTO TEST_PART
VALUES ('2000',200010,'CM');
VALUES ('2006',NULL,'CM');
COMMIT;
Now, I need to keep this table from growing by deleting records that fall b/w a specific range of YRMO_NBR. I think it will be easy if I create a range partition on YRMO_NBR field and then create the current hash partition as a sub-partition.
How do I change the current partition of the table from HASH partition to RANGE partition and a sub-partition (HASH) without losing the data and existing indexes?
The table after restructuring should look like the one below
COMPOSIT PARTITION-- RANGE PARTITION & HASH SUBPARTITION --
CREATE TABLE TEST_PART(
C_NBR CHAR(12),
YRMO_NBR NUMBER(6),
LINE_ID CHAR(2))
PARTITION BY RANGE (YRMO_NBR)
SUBPARTITION BY HASH (C_NBR) (
PARTITION TEST_PART_200009 VALUES LESS THAN(200009) SUBPARTITIONS 2,
PARTITION TEST_PART_200010 VALUES LESS THAN(200010) SUBPARTITIONS 2,
PARTITION TEST_PART_200011 VALUES LESS THAN(200011) SUBPARTITIONS 2,
PARTITION TEST_PART_MAX VALUES LESS THAN(MAXVALUE) SUBPARTITIONS 2
CREATE INDEX TEST_PART_IX_001 ON TEST_PART(C_NBR,LINE_ID);
Pls advice
Thanks in advance

Sorry for the confusion in the first part where I had given a RANGE PARTITION instead of HASH partition. Pls read as follows;
I have a table with 130,000,000 rows hash partitioned as below
----HASH PARTITION--
CREATE TABLE TEST_PART(
C_NBR CHAR(12),
YRMO_NBR NUMBER(6),
LINE_ID CHAR(2))
PARTITION BY HASH (C_NBR)
PARTITIONS 2
STORE IN (PCRD_MBR_MR_02, PCRD_MBR_MR_01);
CREATE INDEX TEST_PART_IX_001 ON TEST_PART(C_NBR,LINE_ID);
Data: -
INSERT INTO TEST_PART
VALUES ('2000',200001,'CM');
INSERT INTO TEST_PART
VALUES ('2000',200009,'CM');
INSERT INTO TEST_PART
VALUES ('2000',200010,'CM');
VALUES ('2006',NULL,'CM');
COMMIT;
Now, I need to keep this table from growing by deleting records that fall b/w a specific range of YRMO_NBR. I think it will be easy if I create a range partition on YRMO_NBR field and then create the current hash partition as a sub-partition.
How do I change the current partition of the table from hash partition to range partition and a sub-partition (hash) without losing the data and existing indexes?
The table after restructuring should look like the one below
COMPOSIT PARTITION-- RANGE PARTITION & HASH SUBPARTITION --
CREATE TABLE TEST_PART(
C_NBR CHAR(12),
YRMO_NBR NUMBER(6),
LINE_ID CHAR(2))
PARTITION BY RANGE (YRMO_NBR)
SUBPARTITION BY HASH (C_NBR) (
PARTITION TEST_PART_200009 VALUES LESS THAN(200009) SUBPARTITIONS 2,
PARTITION TEST_PART_200010 VALUES LESS THAN(200010) SUBPARTITIONS 2,
PARTITION TEST_PART_200011 VALUES LESS THAN(200011) SUBPARTITIONS 2,
PARTITION TEST_PART_MAX VALUES LESS THAN(MAXVALUE) SUBPARTITIONS 2
CREATE INDEX TEST_PART_IX_001 ON TEST_PART(C_NBR,LINE_ID);
Pls advice
Thanks in advance

How to dd Partition Table through First Partition

Hi; I have a flash drive which has a single NTFS partition that fills up less space than the whole drive (so there's a bunch of empty/unused space at the end of the drive). I'd like to use dd to make an image from the very beginning of the drive (to catch the partition table) through the end of the NTFS partition, ignoring the empty space after it. I tried the commands below but they didn't seem to work (a copy of the drive had partition table issues):
dd count=1 bs=512 if=/dev/sdb of=partition_table.img
dd bs=8M if=/dev/sdb1 of=sdb1.img
cat sdb1.img >> partition_table.img
rm sdb1.img
mv partition_table.img mydrive.img
Any ideas? Am I failing to capture something between the partition table and the first partition? Or is it possible my partition table is not 512 bytes?

My suggestion is to dd the MBR (dd if=/dev/XXX of=<image file> bs=512 count=1) and use ntfsclone or fsarchiver to make the image.
But if you want to use dd for the whole image:
$ fdisk -l /dev/sda
Disk /dev/sda: 251.1 GB, 251059544064 bytes, 490350672 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x4d9ddc04
Device Boot Start End Blocks Id System
/dev/sda1 2048 2099199 1048576 83 Linux
/dev/sda2 * 2099200 2303999 102400 83 Linux
/dev/sda3 2304000 490350671 244023336 8e Linux LVM
To image everything through the first partition, I would (dd if=/dev/sda of=image bs=512 count=2099200). I stop at 1+ the end of the partition, because the first sector is 0, rather than 1. You can also modify the bs for better performance, but you'll have to modify the count accordingly. For a 1M bs I think you divide the count by 2048 (FYI, this is completely unrelated to the fact that the partition starts on sector 2048). But I would suggest you do the math yourself.

Error while creating partition table

Hi frnds i am getting error while i am trying to create a partition table using range
getting error ORA-00906: missing left parenthesis.I used the following statement to create partition table
CREATE TABLE SAMPLE_ORDERS
(ORDER_NUMBER NUMBER,
ORDER_DATE DATE,
CUST_NUM NUMBER,
TOTAL_PRICE NUMBER,
TOTAL_TAX NUMBER,
TOTAL_SHIPPING NUMBER)
PARTITION BY RANGE(ORDER_DATE)
PARTITION SO99Q1 VALUES LESS THAN TO_DATE(‘01-APR-1999’, ‘DD-MON-YYYY’),
PARTITION SO99Q2 VALUES LESS THAN TO_DATE(‘01-JUL-1999’, ‘DD-MON-YYYY’),
PARTITION SO99Q3 VALUES LESS THAN TO_DATE(‘01-OCT-1999’, ‘DD-MON-YYYY’),
PARTITION SO99Q4 VALUES LESS THAN TO_DATE(‘01-JAN-2000’, ‘DD-MON-YYYY’),
PARTITION SO00Q1 VALUES LESS THAN TO_DATE(‘01-APR-2000’, ‘DD-MON-YYYY’),
PARTITION SO00Q2 VALUES LESS THAN TO_DATE(‘01-JUL-2000’, ‘DD-MON-YYYY’),
PARTITION SO00Q3 VALUES LESS THAN TO_DATE(‘01-OCT-2000’, ‘DD-MON-YYYY’),
PARTITION SO00Q4 VALUES LESS THAN TO_DATE(‘01-JAN-2001’, ‘DD-MON-YYYY’)
;

More than one of them. Try this instead:
CREATE TABLE SAMPLE_ORDERS
(ORDER_NUMBER NUMBER,
ORDER_DATE DATE,
CUST_NUM NUMBER,
TOTAL_PRICE NUMBER,
TOTAL_TAX NUMBER,
TOTAL_SHIPPING NUMBER)
PARTITION BY RANGE(ORDER_DATE) (
PARTITION SO99Q1 VALUES LESS THAN (TO_DATE('01-APR-1999', 'DD-MON-YYYY')),
PARTITION SO99Q2 VALUES LESS THAN (TO_DATE('01-JUL-1999', 'DD-MON-YYYY')),
PARTITION SO99Q3 VALUES LESS THAN (TO_DATE('01-OCT-1999', 'DD-MON-YYYY')),
PARTITION SO99Q4 VALUES LESS THAN (TO_DATE('01-JAN-2000', 'DD-MON-YYYY')),
PARTITION SO00Q1 VALUES LESS THAN (TO_DATE('01-APR-2000', 'DD-MON-YYYY')),
PARTITION SO00Q2 VALUES LESS THAN (TO_DATE('01-JUL-2000', 'DD-MON-YYYY')),
PARTITION SO00Q3 VALUES LESS THAN (TO_DATE('01-OCT-2000', 'DD-MON-YYYY')),
PARTITION SO00Q4 VALUES LESS THAN (TO_DATE('01-JAN-2001', 'DD-MON-YYYY')))In the future, if you are having problems, go to Morgan's Library at www.psoug.org.
Find a working demo, copy it, then modify it for your purposes.

Best practice for replicating Partitioned table

Hi SQL Gurus,
Requesting your help on the design consideration for replicating a partitioned table.
1. 4 Partitioned tables (1 master table with foreign key constraints to 3 tables) partitioned based on monthly YYYYMM
2. 1 table has a XML column in it
3. Monthly switch partition to remove old data, since it is having foreign key constraint; disable until the switch is complete
4. 1 month partitioned data is 60 GB
having said the above, wanted to create a copy of the same tables to a different servers.
I can think of
1. Transactional replication, but then worried about the XML column,snapshot size and the alter switch will make the same thing
on the subscriber or row by row delete.
2. Logshipping with standby with every 15 minutes, but then it will be for the entire database; because I have other partitioned monthly table which is of 250 GB worth.
3. Thinking about replicating the Partitioned table as Non Partitioned, in that case how the alter switch will work. Is it possible to ignore delete when setting up the replication.
3. SSIS or Stored procedure method of moving data on a daily basis.
4. Backup and restore on a daily basis, but this will not work when the source partition is removed.
Ganesh

Plz refer to
http://msdn.microsoft.com/en-us/library/cc280940.aspx

Ask hash algortihm in partitioning table by hash

hi all,
I wanted to ask about the hash algortihm in partitioning table by hash .How hash algorithm evenly distribute the data on each partisi??anybody know??

A simple calculation probably isn't going to be possible. The problem is that a simple hash function is unlikely to produce the nearly uniform data distribution and a function that produces the nearly uniform data distribution is unlikely to be particularly simple to compute. ORA_HASH has to balance the desire to be quick to compute against the desire to produce nearly uniform data. I don't know what algorithm Oracle picked or where relatively they made the trade off-- I expect that the algorithm may well change across releases.
Conceptually, though, if you had a perfect hash algorithm, it would provide a perfect "fingerprint" of the data and any valid input would have an equal a priori probability of being mapped anywhere in the valid output set-- just like a perfect encryption algorithm generates encrypted output that would appear totally random. If you can look at a piece of data and know that its hash was more likely to be in one part of the output set than another, that would mean that there would be an opportunity to attack the hash-- you could probabilistically reconstruct data if you knew the hash.
If you assume that ORA_HASH is a perfect hash (it probably isn't, but it's probably close enough for this analysis so long as the range is a power of 2), then for any given input, any output is equally likely. If you create a hash partitioned table with 8 partitions, that basically equates to asking ORA_HASH to generate a hash that is between 0 and 7 and puts the data in whichever partition comes out. Since each value is equally likely to be in any of the partitions, you'd expect that the data would be equally distributed. Unless of course there is a lot of repetition in the values in the column you are partitioning by-- the hash for two identical values is identical, so that sort of repetitive data would cause the data distribution to be unequal.
To take a simplistic example, let's assume you were hashing numbers and let's say you have 8 partitions. The simplest possible hash algorithm would be "mod 8". That is, if you insert a value x, insert it into the partiition (x mod 8). If x = 2, 2 mod 8 = 2, so put it in partition 2. If x = 10, 10 mod 8 = 2, so put it in partition 2. If x = 14, 14 mod 8 = 6 so put it in partition 6. If the numeric values that you insert are uniformly distributed (not unlikely if you're dealing with large amounts of data and very likely if you're dealing with sequence-generated primary keys), all 8 partitions will be roughly equally full.
Of course, this algorithm is far from perfect-- if all the data you are inserting is a power of 2, for example, then all the odd partitions would be empty and the even numbered partitions would be full. ORA_HASH needs to be quite a bit more complex than a simple mod N in order to provide more uniform mapping even if there are patterns in the input.
Justin

Partition an Non Partition Table in 11.2.0.1

Hi Friends,
I am using Oracle 11.2.0.1 Oracle Database.
I have a table with 10 Million records and it's a Non Partitioned Table.
1) I would like to partition the table (with partition by range ) without creating new table . I should do it in the existing table itself (not sure DBMS_REDEFINITION is the only option ) (or) can i use alter table ...?
2) Add one partition which will have data for the unspecified range.
Please let me know the inputs on the above
Regards,
DB

Hi,
what is the advantage of using DBMS_REDEFINITION over normal method (create partition table,grant access,insert records)You can't just add a partition in a non-partitioned table. You need to recreate existing table to have it partitioned (you can't just start adding new partitions to existing non-partitioned table). Advantage of dbms_redefinition is that it is online operation to re-create an existing table and and your data always remains available during table recreation
I would like to know how to copy the object privileges,constraints,indexes from Non Partitioned table (sales) to Partitioned table (sales_part) which i am creating. will >DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS help on this?First you need to tell us what method you are using to partition an existing table? If you are using dbms_redifiniiton, you really don't need to worry about triggers, indexex or constraints at all. Just follow any document which explains how to use dbms_redifinition. Dr. Tim has done a lot of work for dummys like us by writing documents for us. Follow this document.
http://www.oracle-base.com/articles/misc/partitioning-an-existing-table.php
If so can i use DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS alone for copying the table dependents alone after i create partition table (or) it should be used along with >DBMS_REDEFINITION.START_REDEF_TABLE only?See above document which i mentioned.
Salman

Issue with updating partitioned table

Hi,
Anyone seen this bug with updating partitioned tables.
Its very esoteric - its occurs when we update a partitioned table using a join to a temp table (not non-temp table) when the join has multiple joins and you're updating the partitoned column that isn't the first column in the primary key and the table contains a bit field. We've tried changing just one of these features and the bug disappears.
We've tested this on 15.5 and 15.7 SP122 and the error occurs in both of them.
Here's the test case - it does the same operation of a partitioned table and a non-partitioned table, but the partitioned table shows and error of "Attempt to insert duplicate key row in object 'partitioned' with unique index 'pk'".
I'd be interested if anyone has seen this and has a version of Sybase without the issue.
Unfortunately when it happens on a replicated table - it takes down rep server.
CREATE TABLE #table1
    (   PK          char(8) null,
        FileDate        date,
        changed         bit
CREATE TABLE partitioned (
PK         char(8) NOT NULL,
ValidFrom     date DEFAULT current_date() NOT NULL,
ValidTo       date DEFAULT '31-Dec-9999' NOT NULL
LOCK DATAROWS
PARTITION BY RANGE (ValidTo)
( p2014 VALUES <= ('20141231') ON [default],
p2015 VALUES <= ('20151231') ON [default],
pMAX VALUES <= (MAX) ON [default]
CREATE UNIQUE CLUSTERED INDEX pk
ON partitioned(PK, ValidFrom, ValidTo)
LOCAL INDEX
CREATE TABLE unpartitioned (
PK         char(8) NOT NULL,
ValidFrom     date DEFAULT current_date() NOT NULL,
ValidTo       date DEFAULT '31-Dec-9999' NOT NULL,
LOCK DATAROWS
CREATE UNIQUE CLUSTERED INDEX pk
ON unpartitioned(PK, ValidFrom, ValidTo)
insert partitioned
select "ET00jPzh", "Jan 7 2015", "Dec 31 9999"
insert unpartitioned
select "ET00jPzh", "Jan 7 2015", "Dec 31 9999"
insert #table1
select "ET00jPzh", "Jan 15 2015", 1
union all
select "ET00jPzh", "Jan 15 2015", 1
go
update partitioned
set    ValidTo = dateadd(dd,-1,FileDate)
from   #table1 t
inner join partitioned p on (p.PK = t.PK)
where p.ValidTo = '99991231'
and    t.changed = 1
go
update unpartitioned
set    ValidTo = dateadd(dd,-1,FileDate)
from   #table1 t
inner join unpartitioned u on (u.PK = t.PK)
where u.ValidTo = '99991231'
and    t.changed = 1
go
drop table #table1
go
drop table partitioned
drop table unpartitioned
go

wrt to replication - it is a bit unclear as not enough information has been stated to point out what happened. I also am not sure that your DBA's are accurately telling you what happened - and may have made the problem worse by not knowing themselves what to do - e.g. 'losing' the log points to fact that someone doesn't know what they should.   You can *always* disable the replication secondary truncation point and resync a standby system, so claims about 'losing' the log are a bit strange to be making.
wrt to ASE versions, I suspect if there are any differences, it may have to do with endian-ness and not the version of ASE itself.   There may be other factors.....but I would suggest the best thing would be to open a separate message/case on it.
Adaptive Server Enterprise/15.7/EBF 23010 SMP SP130 /P/X64/Windows Server/ase157sp13x/3819/64-bit/OPT/Fri Aug 22 22:28:21 2014:
-- testing with tinyint
1> use demo_db
1>
2> CREATE TABLE #table1
3>     (   PK          char(8) null,
4>         FileDate        date,
5> --        changed         bit
6> changed tinyint
7>     )
8>
9> CREATE TABLE partitioned (
10>   PK         char(8) NOT NULL,
11>   ValidFrom     date DEFAULT current_date() NOT NULL,
12>   ValidTo       date DEFAULT '31-Dec-9999' NOT NULL
13>   )
14>
15> LOCK DATAROWS
16>   PARTITION BY RANGE (ValidTo)
17>   ( p2014 VALUES <= ('20141231') ON [default],
18>   p2015 VALUES <= ('20151231') ON [default],
19>   pMAX VALUES <= (MAX) ON [default]
20>         )
21>
22> CREATE UNIQUE CLUSTERED INDEX pk
23>   ON partitioned(PK, ValidFrom, ValidTo)
24>   LOCAL INDEX
25>
26> CREATE TABLE unpartitioned (
27>   PK         char(8) NOT NULL,
28>   ValidFrom     date DEFAULT current_date() NOT NULL,
29>   ValidTo       date DEFAULT '31-Dec-9999' NOT NULL,
30>   )
31> LOCK DATAROWS
32>
33> CREATE UNIQUE CLUSTERED INDEX pk
34>   ON unpartitioned(PK, ValidFrom, ValidTo)
35>
36> insert partitioned
37> select "ET00jPzh", "Jan 7 2015", "Dec 31 9999"
38>
39> insert unpartitioned
40> select "ET00jPzh", "Jan 7 2015", "Dec 31 9999"
41>
42> insert #table1
43> select "ET00jPzh", "Jan 15 2015", 1
44> union all
45> select "ET00jPzh", "Jan 15 2015", 1
(1 row affected)
(1 row affected)
(2 rows affected)
1>
2> update partitioned
3> set    ValidTo = dateadd(dd,-1,FileDate)
4> from   #table1 t
5> inner join partitioned p on (p.PK = t.PK)
6> where p.ValidTo = '99991231'
7> and    t.changed = 1
Msg 2601, Level 14, State 6:
Server 'PHILLY_ASE', Line 2:
Attempt to insert duplicate key row in object 'partitioned' with unique index 'pk'
Command has been aborted.
(0 rows affected)
1>
2> update unpartitioned
3> set    ValidTo = dateadd(dd,-1,FileDate)
4> from   #table1 t
5> inner join unpartitioned u on (u.PK = t.PK)
6> where u.ValidTo = '99991231'
7> and    t.changed = 1
(1 row affected)
1>
2> drop table #table1
1>
2> drop table partitioned
3> drop table unpartitioned
-- duplicating with 'int'
1> use demo_db
1>
2> CREATE TABLE #table1
3>     (   PK          char(8) null,
4>         FileDate        date,
5> --        changed         bit
6> changed int
7>     )
8>
9> CREATE TABLE partitioned (
10>   PK         char(8) NOT NULL,
11>   ValidFrom     date DEFAULT current_date() NOT NULL,
12>   ValidTo       date DEFAULT '31-Dec-9999' NOT NULL
13>   )
14>
15> LOCK DATAROWS
16>   PARTITION BY RANGE (ValidTo)
17>   ( p2014 VALUES <= ('20141231') ON [default],
18>   p2015 VALUES <= ('20151231') ON [default],
19>   pMAX VALUES <= (MAX) ON [default]
20>         )
21>
22> CREATE UNIQUE CLUSTERED INDEX pk
23>   ON partitioned(PK, ValidFrom, ValidTo)
24>   LOCAL INDEX
25>
26> CREATE TABLE unpartitioned (
27>   PK         char(8) NOT NULL,
28>   ValidFrom     date DEFAULT current_date() NOT NULL,
29>   ValidTo       date DEFAULT '31-Dec-9999' NOT NULL,
30>   )
31> LOCK DATAROWS
32>
33> CREATE UNIQUE CLUSTERED INDEX pk
34>   ON unpartitioned(PK, ValidFrom, ValidTo)
35>
36> insert partitioned
37> select "ET00jPzh", "Jan 7 2015", "Dec 31 9999"
38>
39> insert unpartitioned
40> select "ET00jPzh", "Jan 7 2015", "Dec 31 9999"
41>
42> insert #table1
43> select "ET00jPzh", "Jan 15 2015", 1
44> union all
45> select "ET00jPzh", "Jan 15 2015", 1
(1 row affected)
(1 row affected)
(2 rows affected)
1>
2> update partitioned
3> set    ValidTo = dateadd(dd,-1,FileDate)
4> from   #table1 t
5> inner join partitioned p on (p.PK = t.PK)
6> where p.ValidTo = '99991231'
7> and    t.changed = 1
Msg 2601, Level 14, State 6:
Server 'PHILLY_ASE', Line 2:
Attempt to insert duplicate key row in object 'partitioned' with unique index 'pk'
Command has been aborted.
(0 rows affected)
1>
2> update unpartitioned
3> set    ValidTo = dateadd(dd,-1,FileDate)
4> from   #table1 t
5> inner join unpartitioned u on (u.PK = t.PK)
6> where u.ValidTo = '99991231'
7> and    t.changed = 1
(1 row affected)
1>
2> drop table #table1
1>
2> drop table partitioned
3> drop table unpartitioned

Datapump skipping partitioned tables in the database

I have run expdp on Oracle 10.2.0.4.0 on AIX 5.6 Platform, the export runs well exporting rows in the database but when it comes to partitioned tables in the database it export no rows for all the partitioned tables. When I run a normal exp/imp the partitioned tables are exported with all their rows.
I used the following commands:
expdp system/****** dumpfile=export_data.dmp directory=DATA_PUMP_DIR full=y logfile=export_dump.log
Output for expdp on partitioned table:
. . exported "SCOTT"."DEPT":"DEPT_2003_P1" 0 KB 0 rows
. . exported "SCOTT"."DEPT":"DEPT_2003_P10" 0 KB 0 rows
. . exported "SCOTT"."DEPT":"DEPT_2003_P11" 0 KB 0 rows
. . exported "SCOTT"."DEPT":"DEPT_2003_P12" 0 KB 0 rows
. . exported "SCOTT"."DEPT":"DEPT_2003_P2" 0 KB 0 rows
. . exported "SCOTT"."DEPT":"DEPT_2003_P3" 0 KB 0 rows
. . exported "SCOTT"."DEPT":"DEPT_2003_P4" 0 KB 0 rows
. . exported "SCOTT"."DEPT":"DEPT_2003_P5" 0 KB 0 rows
. . exported "SCOTT"."DEPT":"DEPT_2003_P6" 0 KB 0 rows
. . exported "SCOTT"."DEPT":"DEPT_2003_P7" 0 KB 0 rows
. . exported "SCOTT"."DEPT":"DEPT_2003_P8" 0 KB 0 rows
. . exported "SCOTT"."DEPT":"DEPT_2003_P9" 0 KB 0 rows
And for exp:
exp system/****** file=export_dump.dmp full=y log=export_log1.log
Result from the export log for partitioned tables:
. . exporting partition DEPT_2005_P1 881080 rows exported
. . exporting partition DEPT_2005_P2 1347780 rows exported
. . exporting partition DEPT_2005_P3 2002962 rows exported
. . exporting partition DEPT_2005_P4 2318227 rows exported
. . exporting partition DEPT_2005_P5 3122371 rows exported
. . exporting partition DEPT_2005_P6 3916020 rows exported
. . exporting partition DEPT_2005_P7 4217100 rows exported
. . exporting partition DEPT_2005_P8 4125915 rows exported
. . exporting partition DEPT_2005_P9 1913970 rows exported
. . exporting partition DEPT_2005_P10 1100156 rows exported
. . exporting partition DEPT_2005_P11 786516 rows exported
. . exporting partition DEPT_2005_P12 822976 rows exported
I am not sure about this behavour from datapump, my database is more than 800GB and we want to migrate the database from AIX to LINUX.
Thanks

Sorry I just copied and pasted some extracts from my exp and expdp logs:
For testing purposes I tried to run a datapump export of only 1 partitioned table in the database and its going through, but when I do the same on a full datapump export these partitioned tables are being exported with no rows.
Export: Release 10.2.0.4.0 - 64bit Production on Tuesday, 02 August, 2011 12:18:47
Copyright (c) 2003, 2007, Oracle. All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Starting "SYSTEM"."SYS_EXPORT_TABLE_01": system/******** dumpfile=DEPT.dmp tables=scott.dept logfile=dept1.log
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 48.50 GB
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT
Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX
Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type TABLE_EXPORT/TABLE/COMMENT
Processing object type TABLE_EXPORT/TABLE/RLS_POLICY
Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
Processing object type TABLE_EXPORT/TABLE/TRIGGER
Processing object type TABLE_EXPORT/TABLE/INDEX/FUNCTIONAL_AND_BITMAP/INDEX
Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/FUNCTIONAL_AND_BITMAP/INDEX_STATISTICS
Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
. . exported "SCOTT"."DEPT":"DEPT_2009_P6" 1.452 GB 7377736 rows
. . exported "SCOTT"."DEPT":"DEPT_2009_P7" 1.363 GB 6935687 rows
. . exported "SCOTT"."DEPT":"DEPT_2008_P6" 1.304 GB 6656096 rows
. . exported "SCOTT"."DEPT":"DEPT_2010_P7" 1.410 GB 7300618 rows
. . exported "SCOTT"."DEPT":"DEPT_2008_P7" 1.296 GB 6641073 rows
. . exported "SCOTT"."DEPT":"DEPT_2010_P6" 1.328 GB 6863885 rows
. . exported "SCOTT"."DEPT":"DEPT_2007_P6" 1.158 GB 6568075 rows
. . exported "SCOTT"."DEPT":"DEPT_2009_P5" 1.141 GB 5801822 rows
. . exported "SCOTT"."DEPT":"DEPT_2011_P5" 1.162 GB 6027466 rows
. . exported "SCOTT"."DEPT":"DEPT_2007_P7" 1.100 GB 6214680 rows
. . exported "SCOTT"."DEPT":"DEPT_2011_P6" 1.106 GB 5762303 rows
. . exported "SCOTT"."DEPT":"DEPT_2010_P5" 1.133 GB 5859492 rows
. . exported "SCOTT"."DEPT":"DEPT_2007_P5" 1.001 GB 5664315 rows
. . exported "SCOTT"."DEPT":"DEPT_2008_P5" 1.023 GB 5229356 rows
. . exported "SCOTT"."DEPT":"DEPT_2010_P8" 1.078 GB 5549666 rows
. . exported "SCOTT"."DEPT":"DEPT_2007_P8" 940.3 MB 5171379 rows
. . exported "SCOTT"."DEPT":"DEPT_2008_P8" 989.0 MB 4920276 rows
. . exported "SCOTT"."DEPT":"DEPT_2009_P8" 918.6 MB 4553523 rows
. . exported "SCOTT"."DEPT":"DEPT_2006_P6" 821.0 MB 5220879 rows
. . exported "SCOTT"."DEPT":"DEPT_2008_P4" 766.6 MB 3832262 rows
. . exported "SCOTT"."DEPT":"DEPT_2006_P8" 747.9 MB 4753538 rows
. . exported "SCOTT"."DEPT":"DEPT_2006_P7" 741.8 MB 4708242 rows
. . exported "SCOTT"."DEPT":"DEPT_2010_P4" 734.2 MB 3713567 rows
. . exported "SCOTT"."DEPT":"DEPT_2005_P7" 661.4 MB 4217100 rows
. . exported "SCOTT"."DEPT":"DEPT_2005_P8" 647.1 MB 4125915 rows
. . exported "SCOTT"."DEPT":"DEPT_2011_P4" 677.8 MB 3428887 rows
I also tried to run a normal schema by schema export with the normal exp system/password command the and got my dump file which is about 300GB, when I run the imp system/password command and specify fromuser=<system > and touser=<schemas_in_the_dumpfile> seperated by commas, it just comes up with this message:
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Export file created by EXPORT:V10.02.01 via conventional path
import done in WE8ISO8859P9 character set and AL16UTF16 NCHAR character set
Import terminated successfully without warnings.
No tables are exported.
If I specify the parameter imp system/password file=dept_export.dmp full=y log=dept_imp.log with the same dumpfile and it imports data from the dumpfile into my database.
I am not sure what could be wrong with my dumpfile or my imp command and its parameters.

Migrating a new partition table with transportable tablespace

I created a partitioned table with 2 partitions (2010 and 2011) and used transportable tablespace to migrate the data over to a new envionment. My question is, if I decide to add a partition (2012) in the future, can I simply move that new partition along with the associated datafile via transportable tablespace or would I have to move all the partitions (2010, 2011, 2012).

user564785 wrote:
I created a partitioned table with 2 partitions (2010 and 2011) and used transportable tablespace to migrate the data over to a new envionment. My question is, if I decide to add a partition (2012) in the future, can I simply move that new partition along with the associated datafile via transportable tablespace or would I have to move all the partitions (2010, 2011, 2012).Yes why not.
1) create a table as CTAS from 2012 in new Tablespace on source
2) transport the tablespace
3) Add partition to existing partition table Or exchange partition
Oracle has also documented this procedure:
http://docs.oracle.com/cd/B28359_01/server.111/b28310/tspaces013.htm#i1007549

Set table level degree for partitioned table

Hi all,
Usually, we set degree 2 or 4 to big tables. In this case, CBO will choose parallel select for these tables if possible.
Let assume one case that is table1 joins table2. non-partitioned Table1 has 20m rows and has degree 2. partitioned table2 has 50m rows and has no parallel degree.
When I checked the execution plan, CBO uses parallel execution and uses PX BLOCK ITERATOR on table1 as expected. But I don't know whether table2 is selected in parallel, too.
I mean I am not sure whether CBO launches slave processes against table2 or just select table2 as a whole.
And with your tuning or architecture experiences, do you think whehther we should set degree for a partitioned table as the partitioned table can be parallelized based on partitions?
best regards,
Leon

user12064076 wrote:
And with your tuning or architecture experiences, do you think whether we should set degree for a partitioned table as the partitioned table can be parallelized based on partitions?What version of Oracle?
A site I worked at recently preferred not to hard-code the degree but to let Oracle choose it at runtime; they felt it offered better allocation of system load than hard-coding the values. They were on 10g release 2.

Why elapsed time is high in Partitioned table ?

HI All,
I executed two cases, where I update a col of partition and non partitioned table, but the complete elapsed time is quite high in partition table. I am going to paste my findings on the board.
update test_partcodes set codetype = 'A'
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          5          0           0
Execute      1     36.65      82.90      16982        367    3554469     3476353
Fetch        0      0.00       0.00          0          0          0           0
total        2     36.65      82.91      16982        372    3554469     3476353
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
PX Deq: Join ACK                                4        0.00          0.00
PX Deq: Parse Reply                             4        0.09          0.16
PX Deq: Execute Reply                          61        0.07          0.18
db file sequential read                     16982        0.57         41.57
log file switch completion                     27        0.57          1.76
PX Deq: Signal ACK                              5        0.10          0.10
enqueue                                         2        0.00          0.00
SQL*Net message to client                       2        0.00          0.00
SQL*Net message from client                     2        8.12          8.13
SQL*Net break/reset to client                   2        0.00          0.00
update test_partcode_partition set codetype = 'A'
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1    105.34     182.91      13334    2637470    8409866     2899525
Fetch        0      0.00       0.00          0          0          0           0
total        2    105.34     182.91      13334    2637470    8409866     2899525
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
rdbms ipc reply                                 2        0.00          0.00
enqueue                                         2        1.28          1.28
PX Deq: Join ACK                                5        0.00          0.00
PX Deq: Parse Reply                             4        0.26          0.31
PX Deq: Execute Reply                        2464        0.17          1.50
log buffer space                              163        0.28          2.27
log file switch completion                     75        0.41          3.04
db file sequential read                     13333        0.67         59.54
PX Deq: Signal ACK                              8        0.10          0.32
SQL*Net message to client                       1        0.00          0.00
SQL*Net message from client                     1        0.00          0.00
Also, you can check explain plan
test_staging@CHRYSLER> explain plan for update test_partcodes set codetype = 'A' ;
Explained.
test_staging@CHRYSLER> @plan
PLAN_TABLE_OUTPUT
| Id | Operation            | Name           | Rows | Bytes | Cost | TQ    |IN-OUT| PQ Distrib |
|   0 | UPDATE STATEMENT     |                 | 3476K| 6789K|   410 |        |      |            |
|   1 | UPDATE              | TEST_PARTCODES |       |       |       |        |      |            |
|   2 |   TABLE ACCESS FULL | TEST_PARTCODES | 3476K| 6789K|   410 | 37,00 | P->S | QC (RAND) |
test_staging@CHRYSLER> explain plan for update test_partcode_partition set codetype = 'A' ;
Explained.
test_staging@CHRYSLER> @plan
PLAN_TABLE_OUTPUT
| Id | Operation            | Name                    | Rows | Bytes | Cost | Pstart| Pstop | TQ    |IN-OUT| PQ Distrib |
|   0 | UPDATE STATEMENT     |                          | 1159K| 3397K|   342 |       |       |     | |            |
|   1 | UPDATE              | TEST_PARTCODE_PARTITION |       |       |       |       |       |     | |            |
|   2 |   PARTITION RANGE ALL|                          |       |       |       |     1 |    12 | 38,00 | PCWP |            |
|   3 |    TABLE ACCESS FULL | TEST_PARTCODE_PARTITION | 1159K| 3397K|   342 |     1 |    12 | 38,00 | P->S | QC (RAND) |
Note: cpu costing is offhare krishna
Alok

Sorry for incomplete info, Now I am pasting the DDL, which I used to create a Partition Table.
create table test_partcode_partition
Partition by range (codetype)
( PARTITION part_2 VALUES LESS THAN ('C'),
PARTITION part_3 VALUES LESS THAN ('E'),
PARTITION part_4 VALUES LESS THAN ('F'),
PARTITION part_5 VALUES LESS THAN ('L'),
PARTITION part_6 VALUES LESS THAN ('M'),
PARTITION part_7 VALUES LESS THAN ('O'),
PARTITION part_8 VALUES LESS THAN ('R'),
PARTITION part_9 VALUES LESS THAN ('T'),
PARTITION part_10 VALUES LESS THAN ('X'),
PARTITION part_11 VALUES LESS THAN ('Y'),
PARTITION part_12 VALUES LESS THAN ('Z'),
PARTITION PM VALUES LESS THAN (MAXVALUE))
nologging parallel
as
select * from mxm_partcodes ;
DB VERSION - 9.2.0.5.0
OS - WIn 2003 Server.
hare krishna
Alok

PARTITION TABLE 이란?

제품 : ORACLE SERVER
작성날짜 : 2004-08-13
PARTITION TABLE 이란?
=====================
PURPOSE
partition table에 대한 기본 개념입니다.
SCOPE
8~10g Standard Edition 에서는 Partitioning Option 은 지원하지 않습니다.
Explanation
ORACLE 8에서 제공하는 partition table 에 대해 알아보자.
1. Partitioned Table이란?
partitioning 이란 큰 object 를 작고 manage 가 가능하게 분리하는 것을 의미하며,
table 이나 index 에서만 가능하고 cluster, snapshot 은 불가능하다.
각 partition 은 별개의 segment 에 저장되어진다.
Oracle8에서 table 은 기본이 되는 key value 에 의해 partition 으로 분리되어진다.
각 partition은 독립적으로 운영된다.
예를 들어 table partition 은 DML (insert, update, delete) 문에 의한
transaction 을 다른 partition 에 영향을 주지 않고 복구가 가능하다.
DBA_TAB_PARTITIONS 에 각 partition 의 storage 정보 등을 갖는다.
2. 어떻게 partitioned Table을 생성하는가 ?
partition key(s)와 개개의 partition 에 범위를 주어 생성한다.
이 partition 이름은 주어질 수 있으며 만일 생략되면 ORACLE 이 SYS_Pn 으로
generate 한다.
예제 :
emp partition 을 EMPNO column을 partition key 로 하여 생성해 보자.
CREATE TABLE emp
(EMPNO NUMBER(5),
PARTITION BY RANGE(EMPNO)(
partition emp_p1 VALUES LESS THAN (2000),
partition emp_p2 VALUES LESS THAN (4000),
partition emp_p3 VALUES LESS THAN (MAXVALUE));
select * from emp partition (emp_p3);
ACCT_NO PERSON SALES_AMOUNT WEEK_NO
1000 abc 10 30
insert into emp partition (emp_p3) values (7000, 'bcd', 10, 30);
3. partition table 관련한 dictionary 정보
. storage parameters
--> DBA_TAB_PARTITIONS
. partiton table 의 upper partition bound
--> select high_value, partition_position from sys.dba_tab_partitions
where table_name = 'SALES';
4. Partitioned tables의 제약점은?
a) Datatype 제약
Partitioned table은 LONG 이나 LONG RAW datatype을 가질 수 없다.
또한 LOB datatypes (BLOB, CLOB, NCLOB, or BFILE), object types을 가질 수
없다. 이 LOB type 은 V8.1부터는 가능할 것으로 기대된다.
b) Clusters 는 partition 될 수 없다.
c) Bitmap 제한
bitmap 은 local partitioned table 에서만 가능하고 global indexes 로는
불가능하다.
d) Physical 제한
Partitioned table은 여러 개의 database에 걸쳐 있을 수 없다.
오직 1 instance 에서만 가능하다.
5. Local Prefixed와 Local Non-Prefixed index란?
Local index란 partitioned table 의 index로 이는 오로지 한 partition 의
row들을 나타내는 ROWID 를 갖는 index 이다.
이는 주로 partition table 의 partition key 로 사용되어진다.
이를 equi-partitioning 이라 한다.
Prefixed index는 partition key 에 대응하는 leading index key(s) 이다.
Non-Prefixed index 는 leading column 이 되는 partition key 를 포함하지 않는
index key 이다.
6. Global index란?
global index 는 prefix 만 제공하며 non-prefix 는 제공하지 않는다.
global Index 는 전체 table 의 ROWID 처럼 사용되어진다.
7. partitions을 사용하는 방법?
Partition-Extended Table Name을 사용한다.
즉 "schema.table PARTITION part_name" 를 사용하는데 schema 는 schema owner
이고 table은 base table 이름이며, PARTITION 은 써도 되고 안 써도 되는 용어이고,
partition_name은 partition 의 name 이다.
이 partition-extented table 이름은 다음 문장에서 사용되어진다.
INSERT
UPDATE
DELETE
LOCK TABLE
SELECT
Q) partition 에 insert 시:
SQL> insert into sales partition (p8) values (7000, 'bcd', 10, 30);
Q) partition을 delete시:
SQL> delete from sales partition (p8);
Q) partition을 update 시:
SQL> update sales partition (p8) set sales_amount = 20;
Q) partition을 select 시:
SQL> select * from sales PARTITION (Q4);
8. partition-extended table 이름의 제약?
. remote schema object를 포함할 수 없다.
partition-extended table name 은 dblink 를 포함할 수 없으며, dblink 를 통해
table 로 변환 가능한 synonym 을 포함할 수 없다.
만일 remote partition의 사용을 원할 때에는 remote site 에서
partitioned-extended table 이름을 사용하여 view 를 생성할 수 있다.
. partition-extended table 이름은 PL/SQL에서 사용되지 않는다.
partition-extended table 이름을 사용한 SQL 문은 DBMS_SQL package 를 통해
만일 사용하고자 한다면 view 를 사용하여야 한다.
. 오로지 base table 만 허용된다.
partition extension 은 base table 에만 허용되고 synonyms, views, 그외 schema
에서는 허용되지 않는다.
9. Export/Import 시 Table-Level 과 Partition-Level 의 차이점?
테이블 단위의 export에서는 partitioned or non-partitioned table 전체가 index
와 그 table 에 dependent 한 다른 모든 object 가 함께 export 된다.
즉 partitioned table 의 모든 partition 이 export 된다. (이는 direct path
export and conventional path export에 모두 적용.)
또한 모든 export 모드 (full, user, table) 가 테이블 단위의 export 를 support
한다.
partition 단위의 export에서는 사용자가 테이블의 하나 또는 그 이상의 partition
을 export 할 수 있다.
Full database 단위나 user mode 는 partition-level의 export 를 support 하지
않는다. 오직 table levle 만 가능하다.
또한 incremental export (incremental,cumulative, and complete) 가 full
database mode 에서만 가능하기 때문에 partition-level export는 incremental
exports를 지원하지 못한다.
Partition-level import는 export 되어진 non-partitioned table을 import 하지
못한다. 그러나, table-level 의 import로 non-partitioned table 로부터
partitioned table 이 import되어진다.
즉 partition-level import 는 export 되어진 table 이 partitioned 되어 있고
export file 에 있을 때에만 가능하다.
export file 의 partition name 이 valid 하지 않는 경우 import 시 경고
message 를 발생한다.
모든 경우 partitioned data 는 import 시 선택적으로 가능하게 export 되어 진다.
export 나 import 시 table name 을 지정 시는
TABLES=schema_name : tables_name : partition_name 으로 사용한다.
Partition 단위의 export 는 table 내의 특정 partition 을 한개 또는 그 이상을
export 가능하게 한다.
이 때 partition name 이 주어지지 않으면 table 전체가 사용된다.
다음은 partiotion level 의 export 예제이다.
exp system/manager FILE = export.dmp TABLES = (scott.b:px, scott.b:py,
mary.c, d:qb)
이 예제에서 scott.b 는 반드시 partitioned table이고 px ,py 는 2개의
partition 이다.
mary.c 는 partitioned 또는 non-partitioned table 이다. 그러나 d table 은
반드시 partitioned table 이며 qb 는 그 partioion 중의 하나이다.
만일 table-name이나 같은 table 의 partition-name이 중복 사용되어지면
export 는 error 를 발생한다. 예를 들어 다음 partition-level의 export 명령어는
table sc 와 partition px 가 중복 사용되어 error 를 발생한다.
exp system/manager FILE = export.dmp TABLES = (sc, sc:px, sc)
10. partiton table 또는 view를 어떻게 non-partitioned table로 변환시키는가?
table 을 변환하기 위해 dummy table 을 생성하고,
alter table EXCHANGE PARTITION 명령어를 통해 수행한다.
이 명령어는 매우 빨리 data dictionary 를 update 시킨다.
SPLIT PARTITION 은 매우 큰 partition table 이나 view 를 handling 하는 데
유용하다.
SQL:
1. partition을 갖는 dummy_t table 을 생성
2. alter table EXCHANGE partition T with dummy_T
3. drop table T
exp/imp:
1. export the table
2. drop the table .
3. partiton 을 갖는 table 을 다시 생성
4. table data 를 import 한다.
11. table partition을 결합하는 법?
export/import:
partition-level 의 export, import 를 통해 가능하다.
1. partition data 를 갖는 temporary table을 생성한다.
2. drop the partition to be merged
3. insert into table (select * from temporary table)
4. drop temp.
그러나, table partition 을 분할하는 방법은 export, import 를 통해 불가능하다.
Example
Reference Document
------------------

Before we go too far with this, if you manually query with TO_DATE on the variable instead of TO_CHAR on the column, does the query actually use the index?
The TO_CHAR on the column will definitely stop Oracle from using any index on the column. If the query will use the index if you TO_DATE the variable, as I see it, you have three options. First, fix the application problem that won't let you use TO_DATE from the application. Second, change the application to call a function returning a ref cursor, get the date string as a parameter to the function, and do the TO_DATE in the function.
Third, you could consider creating a function-based index on TO_CHAR(transaction_date, 'dd-Mon-yy'). This would be the least desirable option, particularly if you would also be selecting records based on a range of transaction_dates, since it loses a lot of information that the optimizer could use in devising an efficient query plan. It could also change your results for a range scan.
John

Trying to convert Interval Partitioned Table to Range..Exchange Partition..

Requirement:
Replace Interval partitioned Table by Range Partitioned Table
DROP TABLE A;
CREATE TABLE A
   a              NUMBER,
   CreationDate   DATE
PARTITION BY RANGE (CreationDate)
   INTERVAL ( NUMTODSINTERVAL (30, 'DAY') )
   (PARTITION P_FIRST
       VALUES LESS THAN (TIMESTAMP ' 2001-01-01 00:00:00'));
INSERT INTO A
     VALUES (1, SYSDATE);
INSERT INTO A
     VALUES (1, SYSDATE - 30);
INSERT INTO A
     VALUES (1, SYSDATE - 60);I need to change this Interval Partitioned Table to a Range Partitioned Table. Can I do it using EXCHANGE PARTITION. As if I use the conventional way of creating another Range Partitioned table and then :
DROP TABLE A_Range
CREATE TABLE A_Range
a NUMBER,
CreationDate DATE
PARTITION BY RANGE (CreationDate)
   (partition MAX values less than (MAXVALUE));
Insert /*+ append */ into A_Range Select * from A; --This Step takes very very long..Trying to cut it short using Exchange Partition.Problems:
I can't do
ALTER TABLE A_Range
EXCHANGE PARTITION MAX
WITH TABLE A
WITHOUT VALIDATION;
ORA-14095: ALTER TABLE EXCHANGE requires a non-partitioned, non-clustered table
This is because both the tables are partitioned. So it does not allow me.
If I do instead :
create a non partitioned table for exchanging the data through partition.
Create Table A_Temp as Select * from A;
   ALTER TABLE A_Range
EXCHANGE PARTITION MAX
WITH TABLE A_TEMP
WITHOUT VALIDATION;
select count(*) from A_Range partition(MAX);
-Problem is that all the data goes into MAX Partition.
Even after creating a lot of partitions by Splitting Partitions, still the data is in MAX Partition only.
So:
-- Is it that we can't Replace an Interval Partitioned Table by Range Partitioned Table using EXCHANGE PARTITION. i.e. We will have to do Insert into..
-- We can do it but I am missing something over here.
-- If all the data is in MAX Partition because of "WITHOUT VALIDATION" , can we make it be redistributed in the right kind of range partitions.

You will need to pre-create the partitions in a_range, then exchange them one by one from a to a tmp then then to arange. Using your sample (thanks for proviing the code by the way).
SQL> CREATE TABLE A
2 (
3     a              NUMBER,
4     CreationDate   DATE
5 )
6 PARTITION BY RANGE (CreationDate)
7     INTERVAL ( NUMTODSINTERVAL (30, 'DAY') )
8     (PARTITION P_FIRST
9         VALUES LESS THAN (TIMESTAMP ' 2001-01-01 00:00:00'));
Table created.
SQL> INSERT INTO A VALUES (1, SYSDATE);
1 row created.
SQL> INSERT INTO A VALUES (1, SYSDATE - 30);
1 row created.
SQL> INSERT INTO A VALUES (1, SYSDATE - 60);
1 row created.
SQL> commit;
Commit complete.You can find the existing partitions form a using:
SQL> select table_name, partition_name, high_value
2 from user_tab_partitions
3 where table_name = 'A';
TABLE_NAME PARTITION_NAME HIGH_VALUE
A          P_FIRST        TO_DATE(' 2001-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA
A          SYS_P44        TO_DATE(' 2013-01-28 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA
A          SYS_P45        TO_DATE(' 2012-12-29 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIA
A          SYS_P46        TO_DATE(' 2012-11-29 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAYou can then create table a_range with the apporopriate partitions. Note that you may need to create additional partitions in a_range because interval partitioning does not create partitions that it has no data for, even if that leaves "holes" in the partitioning scheme. So, based on the above:
SQL> CREATE TABLE A_Range (
2     a NUMBER,
3     CreationDate DATE)
4 PARTITION BY RANGE (CreationDate)
5     (partition Nov_2012 values less than (to_date('30-nov-2012', 'dd-mon-yyyy')),
6      partition Dec_2012 values less than (to_date('31-dec-2012', 'dd-mon-yyyy')),
7      partition Jan_2013 values less than (to_date('31-jan-2013', 'dd-mon-yyyy')),
8      partition MAX values less than (MAXVALUE));
Table created.Now, create a plain table to use in the exchanges:
SQL> CREATE TABLE A_tmp (
2     a              NUMBER,
3     CreationDate   DATE);
Table created.and exchange all of the partitions:
SQL> ALTER TABLE A
2    EXCHANGE PARTITION sys_p44
3    WITH TABLE A_tmp;
Table altered.
SQL> ALTER TABLE A_Range
2    EXCHANGE PARTITION jan_2013
3    WITH TABLE A_tmp;
Table altered.
SQL> ALTER TABLE A
2    EXCHANGE PARTITION sys_p45
3    WITH TABLE A_tmp;
Table altered.
SQL> ALTER TABLE A_Range
2    EXCHANGE PARTITION dec_2012
3    WITH TABLE A_tmp;
Table altered.
SQL> ALTER TABLE A
2    EXCHANGE PARTITION sys_p46
3    WITH TABLE A_tmp;
Table altered.
SQL> ALTER TABLE A_Range
2    EXCHANGE PARTITION nov_2012
3    WITH TABLE A_tmp;
Table altered.
SQL> select * from a;
no rows selected
SQL> select * from a_range;
         A CREATIOND
         1 23-NOV-12
         1 23-DEC-12
         1 22-JAN-13John

Is it possible a partition table create a partition itself?

Similar Messages

Maybe you are looking for