Partitions/subpartitions

Hey,
- the standard configuration of Oracle: RAC 10gR2 on Unix, ASM, SAN;
- an OLTP on-line telecom/phone purchasing/ordering DB system;
- a big table of telecom/phone ordering/purchasing details (the hundreds of millions of rows ), composite partitioned:
by range date-column (to have a monthly partitioning) +
hashed by ids (to ease the contention during the concurrent inserts);
- a table has the several local equi-partitioned indexes (to improve the queries performance);
- the global indexes can not been created, because the aging data need to be removed on
a regular basis, so no global indexes to avoid the multi-hours rebuilds;
a question: the queries (by the dates' ranges) run relatively slow, because the subpartitioning(by hash);
how to avoid the subpartitioning (it slows down the dates' ranges queries)? and at the same time how not lose a very good performance
of inserts (a hashed subpartitioning definitely gives it to the DB system)?

Similar Messages

Large (highest ?) Number of Partitions / SubPartitions in *Production*

In theory, the maximum number of Partitions/SubPartitions that Oracle supports for a table is 1024K-1 in 10gR2.
Per MetaLink Note#76765.1, the limit was 64K-1 in 8i -- and, I understand from the 9i docs, was also the same limit in 9i. The Note candidly admits that only 1,000 Partitions have been tested.
Have you implemented / seen implemented, say 64thousand Partitions for a table (and this being done for possibly half-a-dozen tables), with at leaste one corresponding LOCALly Partitioned Index ?
What are the implications on :
1. MetaData in the Shared Pool and Latching.
2. Gather_Stats (done GLOBAL or PARTITION wise).
3. Queries that, very unfortunately, end up scanning all the partitions, many of which are small 64K partitions only.

.

Query Optimization with partitioned/subpartitioned tables

I have a 1 billion row table with 72 partitions by range and thousands of subpartitions by list. There is a bitmap index on the subpartition by list field.
If I execute the following query which requests data from a single partition and a single subpartition:
SQL> select * from cen00_demog_sf1_hp where
ckey like '33011%' and demogname = 'P002006';
the optimizer selects a single partition ('33...') and a single subpartition ('P002006'). The query takes only 6 seconds including displaying the 7,386 row result.
However, if I then execute the following query which selects data from two partitions and a single subpartition within each partition:
SQL> select * from cen00_demog_sf1_hp where
(ckey like '33011%' or ckey like '35001%')
and demogname = 'P002006';
the optimizer scans all partitions rather than just scanning partitions 33 and 35. The query takes over 10 minutes to display the 17,972 row result. If this query is split into two separate queries, the same result set can be realized in a total 26 seconds including display the results to the screen.
Any suggestions on how the multiple partition query can be modified to avoid an all rows scan?
Thank you.

I had previously tried reversing the WHERE clause statements in the query but it had no affect. The execution plan for the two partition query follows. Note the "ALL" on the partition range. I purposely did not index the ckey field believing that partitioning would be sufficent (ckey contains 8,262,363 unique keys out of 1,041,057,738 rows). As a test a query requesting a demogval based on a single ckey for a particular demogname returns a result in less than a second. Another test requesting data for a particular ckey without a demogname qualifier resulted in a full scan of a single partition (but not all the partitions) taking 4 minutes of elapsed time. Note that the only reason that there is a bitmap index on the demogname in table cen00_demog_sf1_hp is that normally the query is a join with another table containing an indexed demogname field. In sum, it appears that the optimizer defaults to an all partition scan when more than one partition is included in the query.
Elapsed: 00:11:38.41
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=53824 Card=4 Bytes=148)
1 0 PARTITION RANGE (ALL) (Cost=53824 Card=4 Bytes=148)
2 1 PARTITION LIST (SINGLE) (Cost=53824 Card=4 Bytes=148)
3 2 TABLE ACCESS (BY LOCAL INDEX ROWID) OF 'CEN00_DEMOG_SF1_HP' (TABLE) (Cost=53824 Card=4 Bytes=148)
4 3 BITMAP CONVERSION (TO ROWIDS)
5 4 BITMAP INDEX (SINGLE VALUE) OF 'CEN00_DEMOG_SF1_HP_IDX' (INDEX (BITMAP))
The single partition query trace shows selectivity on the partition range.
Elapsed: 00:00:09.69
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=42 Card=133 Bytes=4655)
1 0 PARTITION RANGE (SINGLE) (Cost=42 Card=133 Bytes=4655)
2 1 PARTITION LIST (SINGLE) (Cost=42 Card=133 Bytes=4655)
3 2 TABLE ACCESS (BY LOCAL INDEX ROWID) OF 'CEN00_DEMOG_SF1_HP' (TABLE) (Cost=42 Card=133 Bytes=4655)
4 3 BITMAP CONVERSION (TO ROWIDS)
5 4 BITMAP INDEX (SINGLE VALUE) OF 'CEN00_DEMOG_SF1_HP_IDX' (INDEX (BITMAP))

Partition/Subpartition by hash

create table demo_table (
ID number(9) primary key,
Col1 varchar2(10) not null,
Col2 varchar2(10) not null,
Col3 varchar2(10)
partition by hash(col1)
subpartition by hash (col2)
partitions 4 subpartitions 4;
Now I would expect there to be a total of 16 sub-partitions. However I only get seven. How do I tell it to do all four partitions with 4 subpartitions instead of just the first one?
select * from user_segments where segment_name = 'DEMO_TABLE';
SEGMENT_NAME | PARTITION_NAME | SEGMENT_TYPE
DEMO_TABLE | SYS_SUBP50061 | TABLE SUBPARTITION
DEMO_TABLE | SYS_SUBP50062 | TABLE SUBPARTITION
DEMO_TABLE | SYS_SUBP50063 | TABLE SUBPARTITION
DEMO_TABLE | SYS_SUBP50064 | TABLE SUBPARTITION
DEMO_TABLE | SYS_SUBP50065 | TABLE SUBPARTITION
DEMO_TABLE | SYS_SUBP50066 | TABLE SUBPARTITION
DEMO_TABLE | SYS_SUBP50067 | TABLE SUBPARTITION

11.2.0.3.0
Using the following insert statements...
insert into demo_table values (1,'abc','def',null);
insert into demo_table values (2,'abc','ghi',null);
insert into demo_table values (3,'abc','jkl',null);
insert into demo_table values (4,'abc','mno',null);
insert into demo_table values (5,'pqr','abc',null);
insert into demo_table values (6,'pqr','def',null);
insert into demo_table values (7,'pqr','ghi',null);
insert into demo_table values (8,'pqr','mno',null);
insert into demo_table values (9,'stu','abc',null);
insert into demo_table values (10,'stu','def',null);
insert into demo_table values (11,'stu','ghi',null);
insert into demo_table values (12,'stu','mno',null);
insert into demo_table values (13,'vwz','abc',null);
insert into demo_table values (14,'vwz','def',null);
insert into demo_table values (15,'vwz','ghi',null);
insert into demo_table values (16,'vwz','mno',null);
I get one partition with 8 rows, one with 0 rows, and two with 4 rows. The first partition's four subparitions have 5,0,0,3 rows. The other tables only have one subpartition even after all these rows were inserted. That one subpartition has all the rows for that partition.
The query of the user_segments table still shows the same seven partitions, even though I would expect the other subparitions to materialize.
(I have the same problem - hash-hash partitions only have 1 subparititon - on a much larger table with a million-plus rows but I'm using this demo table as an example since I want to post something others can replicate)
Edit: I thought hash-hash partition support was added in 11R2?

AVOID Subpartition(list) to be created when Splitting Main Partition(range)

I have created a table structure as below:
CREATE TABLE TEST_SUBPARTITIONS_1
RECORD_ID INTEGER NOT NULL,
SUB_ID VARCHAR2(100),
COBDATE DATE,
DESC VARCHAR2(2000)
PARTITION BY RANGE (COBDATE)
SUBPARTITION BY list(SUB_ID)
PARTITION INITIAL_PARTITION VALUES LESS THAN (TO_DATE(' 2200-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
TABLESPACE TBS_DATA
PCTFREE 10
INITRANS 1
MAXTRANS 255
STORAGE
INITIAL 64K
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
(SUBPARTITION INITIAL_SUBPARTITION VALUES ('INITIAL_DUMMY_SUB_ID') TABLESPACE TBS_DATA
CREATE UNIQUE INDEX TEST_SUBPARTITIONS_1_PK ON TEST_SUBPARTITIONS_1 (COBDATE, RECORD_ID, SUB_ID) LOCAL;
ALTER TABLE TEST_SUBPARTITIONS_1 ADD CONSTRAINT TEST_SUBPARTITIONS_1_PK PRIMARY KEY (COBDATE, RECORD_ID, SUB_ID);
I am partitioning the table based on range (COBDATE) and subpartitioning based on list (SUB_ID).
The table now is created with initial partitions and initial subpartition.
We are splitting the partitions in our procedure as below
ALTER TABLE TEST_SUBPARTITIONS_1 SPLIT PARTITION
TST_SUB_R21001231 AT (TO_DATE(20130220,'YYYYMMDD') ) INTO
     (PARTITION TST_SUB_R20130219 TABLESPACE TBS_DATA, PARTITION TST_SUB_R21001231)
The partition is getting split correctly with new partition as
TST_SUB_R20130219, but the subpartition is also created automatically with some 'SYS' name.
(i.e Name: SYS_SUBP693 , Values: INITIAL_DUMMY_SUB_ID)
This happens after every split of range by COBDATE.
Here it has created as below:
Partition          SubPartition
TST_SUB_R21001231     INITIAL_SUBPARTITION
TST_SUB_R20130219     SYS_SUBP693
TST_SUB_R20130220     SYS_SUBP694
TST_SUB_R20130221     SYS_SUBP695
I want to AVOID splitting subpartition when I split the main partition
i.e a SYS subpartition should not be created when I split the partition for COBDATE.
Let me know how do I avoid this in main "alter statement" above?
Any other solution?     I do not want to drop the SYS subpartition later, instead want it to avoid creating only when I split the partition.

>
I want to AVOID splitting subpartition when I split the main partition
i.e a SYS subpartition should not be created when I split the partition for COBDATE.
Let me know how do I avoid this in main "alter statement" above?
Any other solution? I do not want to drop the SYS subpartition later, instead want it to avoid creating only when I split the partition.
>
The subpartitions aren't being split. Oracle is creating new subpartitions for the new partition. The subpartitions need to exist since that is where the data is stored.
You can avoid the SYS prefix on the name though by using a different naming convention.
See the 'Splitting a *-List Partition' section of the VLDB and Partitioning Guide
http://docs.oracle.com/cd/E11882_01/server.112/e25523/part_admin002.htm#i1008028
>
The ALTER TABLE ... SPLIT PARTITION statement provides no means of specifically naming subpartitions resulting from the split of a partition in a composite partitioned table. However, for those subpartitions in the parent partition with names of the form partition name_subpartition name, the database generates corresponding names in the newly created subpartitions using the new partition names. All other subpartitions are assigned system generated names of the form SYS_SUBPn. System generated names are also assigned for the subpartitions of any partition resulting from the split for which a name is not specified. Unnamed partitions are assigned a system generated partition name of the form SYS_Pn.

Parent partition of subpartitions that move to a new TS

PLATFORM_NAME: Solaris[tm] OE (64-bit)
VERSION: 11.2.0.2.0
In our system we have several tables that are partitioned by range. Some of these tables are then sub-partitioned by list. Well initially we were creating a new tablespace every month and creating the new monthly partition on the new tablespace. Well I got annoyed by this, so I decided to move all of the partitions/subpartitions to a single tablespace. And this went smooth, at first, in my dev region. I moved all of the segments to the new tablespace, but then I noticed something odd...
Example:
CREATE TABLE me.sub_partitioned_table
my_range_partitioned_column date,
my_list_partitioned_column varchar2(30)
PARTITION BY RANGE (my_range_partitioned_column)
SUBPARTITION BY LIST (my_list_partitioned_column)
SUBPARTITION TEMPLATE
(SUBPARTITION value4 VALUES (4),
SUBPARTITION value23 VALUES (23),
SUBPARTITION value60 VALUES (60),
SUBPARTITION "DEFAULT" VALUES (DEFAULT)
PARTITION P_HIST VALUES LESS THAN (TO_DATE(' 2007-09-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
TABLESPACE P_HIST
( SUBPARTITION P_HIST_value4 VALUES (4) TABLESPACE MONTHLY_PARTITION,
SUBPARTITION P_HIST_value23 VALUES (23) TABLESPACE MONTHLY_PARTITION,
SUBPARTITION P_HIST_value60 VALUES (60) TABLESPACE MONTHLY_PARTITION,
SUBPARTITION P_HIST_DEFAULT VALUES (DEFAULT) TABLESPACE MONTHLY_PARTITION ),
...... and there are a lot more partitions/subpartitions
So I create all of my alter table move subpartition statements, and the execute as they should. If I do:
select tablespace_name from dba_tab_subpartitions where table_name = 'SUB_PARTITIONED_TABLE' and table_owner = 'ME', I see that all of my subpartitions are on the new, single tablespace. BUUUUUUT, if I do:
select tablespace_name from dba_tab_partitions where table_name = 'SUB_PARTITIONED_TABLE' and table_owner = 'ME', I see all of the old tablespace names are still listed for my partitions.
My question is, can this be changed? Did I screw something up? Is this a bug? If I try to alter the table and move the partition I get an error because I'm trying to move something that isn't a segment. Any help would be appreciated. Hopefully this makes sense. If you need clarification on anything, please let me know.
Thanks!

I found my answer...
ALTER TABLE ME.sub_partitioned_table MODIFY DEFAULT ATTRIBUTES FOR PARTITION MONTHLY_PARTITION TABLESPACE NEW_BIG_TS;

Regarding Renaming INDEX Partitions

Hi All,
I have the following syntax for renaming table partitions/subpartitions :
ALTER TABLE SMTP_MSG_TRAFFIC_FCT RENAME PARTITION FOR (20100310) TO BASE_FACT_20100310;
ALTER TABLE SMTP_MSG_TRAFFIC_FCT RENAME SUBPARTITION FOR (20100310,19) TO BASE_FACT_20100310_MAILBOX;
I want to do the same thing for renaming the index partitions/subpartitions :
ALTER INDEX SMTP_MSG_TF_FX02_ARR_TM_DIM_ID RENAME PARTITION FOR (20100310) TO BASE_FACT_20100310;
ALTER TABLE SMTP_MSG_TF_FX02_ARR_TM_DIM_ID RENAME SUBPARTITION FOR (20100310,19) TO BASE_FACT_20100310_MAILBOX;
But I get the following error:
SQL> ALTER INDEX SMTP_MSG_TF_FX02_ARR_TM_DIM_ID RENAME PARTITION FOR (20100310) TO BASE_FACT_20100310;
ALTER INDEX SMTP_MSG_TF_FX02_ARR_TM_DIM_ID RENAME PARTITION FOR (20100310) TO BASE_FACT_20100310
ERROR at line 1:
ORA-14006: invalid partition name
Is it possible to rename the partition in this way? Or can I set any parameter that will ensure that when the base table partition name changes, it will also change the index partition name?
Thanks & Regards,
Aniket

yes its possible:
SQL>ALTER INDEX index_name RENAME PARTITION index_partiton_name TO new_index_partition;
You are getting error because :
a partition name is expected but not present as you typed,
enter an appropriate partition name, will solve the problem.
Edited by: adnanKaysar on Mar 18, 2010 12:32 PM

How to truncate data in a subpartition

Hi All,
I am using oracle 11gr2 database.
I have a table as given below
CREATE TABLE SCMSA_ESP.PP_DROP
ESP_MESSAGE_ID VARCHAR2(50 BYTE) NOT NULL ,
CREATE_DT DATE DEFAULT SYSDATE,
JOB_LOG_ID NUMBER NOT NULL ,
MON NUMBER GENERATED ALWAYS AS (TO_CHAR("CREATE_DT",'MM'))
TABLESPACE SCMSA_ESP_DATA
PARTITION BY RANGE (JOB_LOG_ID)
SUBPARTITION BY LIST (MON)
PARTITION PMINVALUE VALUES LESS THAN (1)
( SUBPARTITION PMINVALUE_M1 VALUES ('01') TABLESPACE SCMSA_ESP_DATA,
SUBPARTITION PMINVALUE_M2 VALUES ('02') TABLESPACE SCMSA_ESP_DATA,
SUBPARTITION PMINVALUE_M3 VALUES ('03') TABLESPACE SCMSA_ESP_DATA,
SUBPARTITION PMINVALUE_M4 VALUES ('04') TABLESPACE SCMSA_ESP_DATA,
SUBPARTITION PMINVALUE_M5 VALUES ('05') TABLESPACE SCMSA_ESP_DATA,
SUBPARTITION PMINVALUE_M6 VALUES ('06') TABLESPACE SCMSA_ESP_DATA,
SUBPARTITION PMINVALUE_M7 VALUES ('07') TABLESPACE SCMSA_ESP_DATA,
SUBPARTITION PMINVALUE_M8 VALUES ('08') TABLESPACE SCMSA_ESP_DATA,
SUBPARTITION PMINVALUE_M9 VALUES ('09') TABLESPACE SCMSA_ESP_DATA,
SUBPARTITION PMINVALUE_M10 VALUES ('10') TABLESPACE SCMSA_ESP_DATA,
SUBPARTITION PMINVALUE_M11 VALUES ('11') TABLESPACE SCMSA_ESP_DATA,
SUBPARTITION PMINVALUE_M12 VALUES ('12') TABLESPACE SCMSA_ESP_DATA
PARTITION PMAXVALUE VALUES LESS THAN (MAXVALUE)
( SUBPARTITION PMAXVALUE_M1 VALUES ('01') TABLESPACE SCMSA_ESP_DATA,
SUBPARTITION PMAXVALUE_M2 VALUES ('02') TABLESPACE SCMSA_ESP_DATA,
SUBPARTITION PMAXVALUE_M3 VALUES ('03') TABLESPACE SCMSA_ESP_DATA,
SUBPARTITION PMAXVALUE_M4 VALUES ('04') TABLESPACE SCMSA_ESP_DATA,
SUBPARTITION PMAXVALUE_M5 VALUES ('05') TABLESPACE SCMSA_ESP_DATA,
SUBPARTITION PMAXVALUE_M6 VALUES ('06') TABLESPACE SCMSA_ESP_DATA,
SUBPARTITION PMAXVALUE_M7 VALUES ('07') TABLESPACE SCMSA_ESP_DATA,
SUBPARTITION PMAXVALUE_M8 VALUES ('08') TABLESPACE SCMSA_ESP_DATA,
SUBPARTITION PMAXVALUE_M9 VALUES ('09') TABLESPACE SCMSA_ESP_DATA,
SUBPARTITION PMAXVALUE_M10 VALUES ('10') TABLESPACE SCMSA_ESP_DATA,
SUBPARTITION PMAXVALUE_M11 VALUES ('11') TABLESPACE SCMSA_ESP_DATA,
SUBPARTITION PMAXVALUE_M12 VALUES ('12') TABLESPACE SCMSA_ESP_DATA
ENABLE ROW MOVEMENT;
I have populate two sets of data.
One with Positive job_log_id and another with Negative job logid as given below.
Step 1:
Data going to PMAXVALUE Partition
INSERT INTO PP_DROP ( ESP_MESSAGE_ID, CREATE_DT,JOB_LOG_ID)
SELECT LEVEL, SYSDATE+TRUNC(DBMS_RANDOM.VALUE(1,300)), 1 FROM DUAL CONNECT BY LEVEL <=300;
Step 2:
Data going to PMINVALUE partition
INSERT INTO PP_DROP ( ESP_MESSAGE_ID, CREATE_DT,JOB_LOG_ID)
SELECT LEVEL, SYSDATE+TRUNC(DBMS_RANDOM.VALUE(1,300)), -1 FROM DUAL CONNECT BY LEVEL <=300;
Now the question is how to truncate the data that is present only in the Positive partitions subpartition
Like in the PMAXVALUE partition I have 10 subpartitions and I need to truncate the data in the JAN MONTH Partition only of the PMAXVALUE partition.
Appreciate your valuable response.
Thanks,
MK.

For future reference:
http://www.morganslibrary.org/reference/truncate.html
The library index is located at
http://www.morganslibrary.org/library.html

Export/Import subpartition stats

I hope someone can give me a workaround for this, because it's causing our reports to take longer than they should!
Background:
We have some sub-partitioned tables on a 10.2.0.3 database, partitioned daily on the date column, with the subpartitions based on a list of values.
Overnight, various reports are run. Each report loads its data into the table, and then produces a file based on the data that's been loaded for that report. It is not practical (IMO) to analyze the tables after each report has loaded its data, due to other reports loading their data at the same time.
As the amount of data loaded into the tables each night does not vary significantly, we export the stats from a previous partition and import them into the new partition as part of the partition housekeeping job (stats imported from old partition, old partition gets dropped, new partition created with same name as the old one, and stats imported). This is done using dbms_sql.export_table_stats and dbms_sql.import_table_stats.
However, one report which currently loads 43million rows is taking 4.5 hours to run. The size of the load file increases daily, but looking at the history of the report, each relatively small increase causes the report to run a disproportional amount longer (ie. an increase of a similar amount of rows on one night can add twice as much time onto the length of the report than the increase the previous night did).
We've just implemented some changes to improve the buffer sizes, etc, on the database, in a bid to reduce some of the waits, but this has not improved matters much - the report now runs in 4 hours.
We know this report can run faster, because in testing, we saw the report run in 60 minutes! Subsequent investigation shows that this was after the partitions had been analyzed, whereas the slow report ran prior to the partitions being analyzed, despite the stats being there for the partition.
I have now tested the export/import stats process and found that they do not import the stats for the subpartitions. This looks like it is a large part of why the report takes longer before the relevant partitions/subpartitions have been analyzed than it does afterwards.
Does anyone know of anyway that I can export/import the stats at a subpartition level? (I tried putting a subpartition name in the partition parameter, but I just got an error about it being an unknown partition name.)
Any help, ideas or workarounds on this will be gratefully received!

*** Duplicate Post - Please Ignore ***

Subpartitioning on index organized table in Oracle 10g

We have an indexorganized table with primary key on 3 columns one of which is a DATE column. We need to partition the table on the DATE column month wise and subpartition it further week wise.
Please let me know if it is possible and if yes, how?

Composite Partitioning
Composite partitioning partitions data using the range method, and within each
partition, subpartitions it using the hash method. Composite partitions are ideal
for both historical data and striping. Composite Partitioning also provides
improved manageability of range partitioning and data placement, as well as the
parallelism advantages of hash partitioning.
When creating composite partitions, you specify the following:
Partitioning method: range
Partitioning column(s)
Partition descriptions identifying partition bounds
Subpartitioning method: hash
Subpartitioning column(s)
Number of subpartitions per partition or descriptions of subpartition
Example:
CREATE TABLE scubagear (equipno NUMBER, equipname VARCHAR(32), price NUMBER)
PARTITION BY RANGE (equipno) SUBPARTITION BY HASH(equipname)
SUBPARTITIONS 8 STORE IN (ts1, ts3, ts5, ts7)
(PARTITION p1 VALUES LESS THAN (1000),
PARTITION p2 VALUES LESS THAN (2000),
PARTITION p3 VALUES LESS THAN (MAXVALUE));
Each subpartition of a composite-partitioned table is stored in its own segment.
The partitions of a composite-partitioned table are logical structures only as
their data is stored in the segments of their subpartitions. As with partitions,
these subpartitions share the same logical attributes. Unlike range partitions
in a range partitioned table, the subpartitions cannot have different physical
attributes from the owning partition except for the Tablespace attribute.
Composite Partitions Indexes
Composite partitioning method supports both Local and global indexes.
The following statement creates a local index on the EMP table where the index
segments will be spread across tablespaces TS7, TS8, and TS9.
CREATE INDEX emp_ix ON emp(deptno)
LOCAL STORE IN (ts7, ts8, ts9);
This local index will be equipartitioned with the base table as follows:
It will consist of as many partitions as the base partitioned table.
Each index partition will consist of as many subpartitions as the corresponding
base table partition.
Index entries for rows in a given subpartition of the base table will be stored
in the corresponding subpartition of the index.
Refer METALINK doc Note:125314.1

Best way to change partition key on existing table

Hi,
Using Oracle 11.20.3 on AIX.
We have a table about 800 million rows and 120gb in size.
Want to try copies oif this table to evalaute different partitiong strategies.
What is the quickest way to do this?
Would have liked say datapump table 1 tro disk and datapumo import the data to new table but do the tables need to be of the same format.
Thanks

>
Using Oracle 11.20.3 on AIX.
We have a table about 800 million rows and 120gb in size.
Want to try copies oif this table to evalaute different partitiong strategies.
What is the quickest way to do this?
Would have liked say datapump table 1 tro disk and datapumo import the data to new table but do the tables need to be of the same format.
>
First your subject asks a different question that the text you posted: Best way to change partition key on existing table. The answer to that question is YOU CAN'T. All data has to be moved to change the partition key since each partition/subpartition is in its own segment. You either create a new table or use DBMS_REDEFINITION to redefine the table online.
Why do you want to export all data to a file first? That just adds to the time and cost of doing the op.
What problem are you trying to use partitioning to solve? Performance? Data maintenance? For performance the appropriate partitioning key and whether to use subpartitions depends on the types of queries and the query predicates you typically use as well as the columns that may be suitable for partition keys.
For maintenance a common method is to partition on a date by year/month/day so you can more easily load new daily/weekly/monthly data into its own partition or drop old data that no longer needs to be kept online.
You should use a small subset of the data when testing your partitionings strategies.
Can you do the partitioning offline in an outage window? If not then using the DBMS_REDEFINITION is your only option.
Without knowing what you are trying to accomplish only general advice can be given. You even mentioned that you might want to use a different set of columns than the curren table has.
A standard heap table uses ONE segment for its data (ignoring possible LOB segments). A partitioned/subpartitioned table uses ONE segment for each partition/subpartition. This means that ALL data must be moved to partition the table (unless you are only creating one partition).
This means that every partitioning scheme that uses a different partition key requires ALL data to be moved again for that test.
Provide some information about what problem you are trying to solve.
>
Is this quicker than datapump?
>
Yes - exporting the data simplying moves it all an additional time. Ok to export if you need a backup before you start.
>
Found artcle which talks about using merge option on datapump import to convert partitioned table to non-partitioned table.
>
How would that apply to you? That isn't what you said you wanted to do.

A partition tab is needed in the schema-table browser and it's missing

After a first sight with the product, I couldn't find a partition tab in the schema-table browser.
For those having partitions it is absolutely essential.

It's easy to add,
create a file that has the following content
<?xml version="1.0" encoding="UTF-8"?>
<items>
<item type="sharedQuery" id="PartSubPartkeys">
<query minversion="9">
     <sql>
     <![CDATA[ select 'PARTITION KEYS' PARTITION_LEVEL,substr(sys_connect_by_path(column_name,','),2) "PARTITION KEYS"
               from (select column_name, column_position
               from all_part_key_columns
               where owner = :OBJECT_OWNER
               and name = :OBJECT_NAME
               and object_type='TABLE' )
               start with column_position=1
               connect by column_position=prior column_position+1
               union all
               select 'SUBPARTITION KEYS' ,substr(sys_connect_by_path(column_name,','),2)
               from (select column_name, column_position
               from all_subpart_key_columns
               where owner = :OBJECT_OWNER
               and name = :OBJECT_NAME
               and object_type='TABLE' )
               start with column_position=1
               connect by column_position=prior column_position+1]]></sql>
     </query>
     </item>
<item type="sharedQuery" id="PartSubPartkeysFI">
<query minversion="9">
     <sql>
     <![CDATA[ select 'PARTITION KEYS' PARTITION_LEVEL,substr(sys_connect_by_path(column_name,','),2) "PARTITION KEYS"
               from (select column_name, column_position
               from all_part_key_columns
               where owner = :OBJECT_OWNER
               and name = (select table_name
                         from all_indexes
                         where index_name=:OBJECT_NAME
                         and owner=:OBJECT_OWNER)
               and object_type='TABLE' )
               start with column_position=1
               connect by column_position=prior column_position+1
               union all
               select 'SUBPARTITION KEYS' ,substr(sys_connect_by_path(column_name,','),2)
               from (select column_name, column_position
               from all_subpart_key_columns
               where owner = :OBJECT_OWNER
               and name =(select table_name
                         from all_indexes
                         where index_name=:OBJECT_NAME
                         and owner=:OBJECT_OWNER)
               and object_type='TABLE' )
               start with column_position=1
               connect by column_position=prior column_position+1]]></sql>
     </query>
     </item>
<item type="sharedQuery" id="Partitions">
<query minversion="9">
     <sql>
     <![CDATA[ select partition_name, num_rows,AVG_ROW_LEN, blocks ,LAST_ANALYZED from all_tab_partitions where table_owner = :OBJECT_OWNER and table_name = :OBJECT_NAME order by partition_position]]></sql>
     </query>
     </item>
<item type="sharedQuery" id="SubPartitions">
<query minversion="9">
     <sql>
     <![CDATA[ select subpartition_name, partition_name, num_rows,AVG_ROW_LEN, blocks ,LAST_ANALYZED from all_tab_subpartitions where table_owner = :OBJECT_OWNER and table_name = :OBJECT_NAME order by partition_name,subpartition_position]]></sql>
     </query>
     </item>
<item type="editor" node="TableNode" >
<title><![CDATA[Partitions/SubPartitions]]></title>
<query id="PartSubPartkeys" />
<subquery>
<title>Partitions/SubPartition</title>
<query>
<sql><![CDATA[select partition_position, partition_name "Partition/Subpartition", tablespace_name,high_value,compression,num_rows,AVG_ROW_LEN, blocks ,LAST_ANALYZED from all_tab_partitions where table_owner = :OBJECT_OWNER and table_name = :OBJECT_NAME and 'PARTITION KEYS'=:PARTITION_LEVEL
         union all
         select subpartition_position, partition_name||'/'||subpartition_name, tablespace_name,high_value,compression,num_rows,AVG_ROW_LEN, blocks ,LAST_ANALYZED from all_tab_subpartitions where table_owner = :OBJECT_OWNER and table_name = :OBJECT_NAME and 'SUBPARTITION KEYS' =:PARTITION_LEVEL
         order by 2]]></sql>
</query>
</subquery>
</item>
<item type="editor" node="MViewNode" >
<title><![CDATA[Partitions/SubPartitions]]></title>
<query id="PartSubPartkeys" />
<subquery>
<title>Partitions/SubPArtition</title>
<query>
<sql><![CDATA[select partition_position, partition_name "Partition/Subpartition", tablespace_name,
         high_value,compression,num_rows,AVG_ROW_LEN, blocks ,LAST_ANALYZED
         from all_tab_partitions where table_owner = :OBJECT_OWNER and table_name = :OBJECT_NAME and 'PARTITION KEYS'=:PARTITION_LEVEL
         union all
         select subpartition_position, partition_name||'/'||subpartition_name, tablespace_name,high_value,
         compression,num_rows,AVG_ROW_LEN, blocks ,LAST_ANALYZED
         from all_tab_subpartitions where table_owner = :OBJECT_OWNER and table_name = :OBJECT_NAME and 'SUBPARTITION KEYS' =:PARTITION_LEVEL
         order by 2]]></sql>
</query>
</subquery>
</item>
<item type="editor" node="IndexNode" >
<title><![CDATA[Partitions/SubPartitions]]></title>
<query id="PartSubPartkeysFI" />
<subquery>
<title>Partitions/SubPArtition</title>
<query>
<sql><![CDATA[select partition_position, partition_name "Partition/Subpartition", tablespace_name,high_value,compression,
         Leaf_Blocks, Distinct_Keys, clustering_factor ,LAST_ANALYZED
         from all_ind_partitions where index_owner = :OBJECT_OWNER and index_name = :OBJECT_NAME
         and 'PARTITION KEYS'=:PARTITION_LEVEL
         union all
         select subpartition_position, partition_name||'/'||subpartition_name, tablespace_name,high_value,compression,
         Leaf_Blocks, Distinct_Keys, clustering_factor ,LAST_ANALYZED
         from all_ind_subpartitions
         where index_owner = :OBJECT_OWNER
         and index_name = :OBJECT_NAME
         and 'SUBPARTITION KEYS'=:PARTITION_LEVEL
         order by 2]]></sql>
</query>
</subquery>
</item>
<item type="editor" node="TableNode">
<title><![CDATA[Unabridged SQL]]></title>
<query>
<sql><![CDATA[select :OBJECT_OWNER OOWNER, :OBJECT_NAME ONAME, 'TABLE' OTYPE from dual union all select owner,index_name,'INDEX' from all_indexes where table_owner= :OBJECT_OWNER and table_name=:OBJECT_NAME ]]></sql>
</query>
<subquery type="code">
<query>
<sql><![CDATA[select dbms_metadata.get_ddl(:OTYPE,:ONAME, :OOWNER) "SQL Statements" from dual]]></sql>
</query>
</subquery>
</item>
<item type="editor" node="TableNode">
<title><![CDATA[Partition Columns Statistics]]></title>
<query id="Partitions" />
<subquery>
<query>
     <sql>
     <![CDATA[ select COLUMN_NAME, NUM_DISTINCT, LOW_VALUE, HIGH_VALUE, DENSITY, NUM_NULLS
         from all_part_col_statistics where owner = :OBJECT_OWNER
         and table_name = :OBJECT_NAME
         and partition_name= :PARTITION_NAME
         order by column_name]]></sql>
</query>
</subquery>
</item>
<item type="editor" node="TableNode">
<title><![CDATA[SUBPartition Columns Statistics]]></title>
<query id="SubPartitions" />
<subquery>
<query>
     <sql>
     <![CDATA[ select COLUMN_NAME, NUM_DISTINCT, LOW_VALUE, HIGH_VALUE, DENSITY, NUM_NULLS from all_subpart_col_statistics where owner = :OBJECT_OWNER and table_name = :OBJECT_NAME and subpartition_name=:SUBPARTITION_NAME order by column_name]]></sql>
     </query>
</subquery>
</item>
<item type="editor" node="MViewNode">
<title><![CDATA[Partition Columns Statistics]]></title>
<query id="Partitions" />
<subquery>
<query>
     <sql>
     <![CDATA[ select COLUMN_NAME, NUM_DISTINCT, LOW_VALUE, HIGH_VALUE, DENSITY, NUM_NULLS
         from all_part_col_statistics where owner = :OBJECT_OWNER
         and table_name = :OBJECT_NAME
         and partition_name= :PARTITION_NAME
         order by column_name]]></sql>
</query>
</subquery>
</item>
<item type="editor" node="MViewNode">
<title><![CDATA[SUBPartition Columns Statistics]]></title>
<query id="SubPartitions" />
<subquery>
<query>
     <sql>
     <![CDATA[ select COLUMN_NAME, NUM_DISTINCT, LOW_VALUE, HIGH_VALUE, DENSITY, NUM_NULLS from all_subpart_col_statistics where owner = :OBJECT_OWNER and table_name = :OBJECT_NAME and subpartition_name=:SUBPARTITION_NAME order by column_name]]></sql>
     </query>
</subquery>
</item>
<item type="editor" node="SchemaFolder" minversion="10.1">
<title><![CDATA[Sessions]]></title>
<query>
<sql><![CDATA[select sid,serial#,program,last_call_et,machine, status, sql_hash_value shv,sql_child_number scn
         from v$session
         order by 1]]></sql>
</query>
<subquery>
<query>
<sql><![CDATA[select * from table(dbms_xplan.display_cursor(:SHV,:SCN))]]></sql>
</query>
</subquery>
</item>
</items>
and add the following line to your ide.conf file (in jdev/bin directory in the sqldev install dir)
AddVMOption -Draptor.user.editors=fullpathofthefile(dir and name)
and restart, you'll get several additional tabs to the ones displayed for tables.
enjoy

Problems with partition tables

Hi all,
I've got some problems with partition tables. The script at the bottom run but when I wanna insert some values it returns me an error
(ORA-06550: line 1, column 30: PL/SQL: ORA-06552: PL/SQL: Compilation unit analysis terminated
ORA-06553: PLS-320: the declaration of the type of this expression is incomplete or malformed
ORA-06550: line 1, column 7: PL/SQL: SQL Statement ignored)
and I can't understand why!
There's something incorrect in the script or not?
Please help me
Thanks in advance
Steve
CREATE TABLE TW_E_CUSTOMER_UNIFIED
ID_CUSTOMER_UNIFIED VARCHAR2 (27) NOT NULL ,
START_VALIDITY_DATE DATE NOT NULL ,
END_VALIDITY_DATE DATE ,
CUSTOMER_STATUS VARCHAR2 (255)
PARTITION BY RANGE (START_VALIDITY_DATE)
SUBPARTITION BY LIST (END_VALIDITY_DATE)
PARTITION M200909 VALUES LESS THAN (TO_DATE('20091001','YYYYMMDD'))
(SUBPARTITION M200909_N VALUES (NULL), SUBPARTITION M200909_NN VALUES (DEFAULT)),
PARTITION M200910 VALUES LESS THAN (TO_DATE('20091101','YYYYMMDD'))
(SUBPARTITION M200910_N VALUES (NULL), SUBPARTITION M200910_NN VALUES (DEFAULT)),
PARTITION M200911 VALUES LESS THAN (TO_DATE('20091201','YYYYMMDD'))
(SUBPARTITION M200911_N VALUES (NULL), SUBPARTITION M200911_NN VALUES (DEFAULT)),
PARTITION M200912 VALUES LESS THAN (TO_DATE('20100101','YYYYMMDD'))
(SUBPARTITION M200912_N VALUES (NULL), SUBPARTITION M200912_NN VALUES (DEFAULT)),
PARTITION M201001 VALUES LESS THAN (TO_DATE('20100201','YYYYMMDD'))
(SUBPARTITION M201001_N VALUES (NULL), SUBPARTITION M201001_NN VALUES (DEFAULT)),
PARTITION M201002 VALUES LESS THAN (TO_DATE('20100301','YYYYMMDD'))
(SUBPARTITION M201002_N VALUES (NULL), SUBPARTITION M201002_NN VALUES (DEFAULT)),
PARTITION M210001 VALUES LESS THAN (MAXVALUE))
(SUBPARTITION M210001_N VALUES (NULL), SUBPARTITION M210001_NN VALUES (DEFAULT))
;

Hi Hoek,
the DB version is 10.2 (italian version, then SET is correct).
...there's something strange: now I can INSERT rows but I can't update them!
I'm using this command string:
UPDATE TW_E_CUSTOMER_UNIFIED SET END_VALIDITY_DATE = TO_DATE('09-SET-09', 'DD-MON-RR') WHERE
id_customer_unified = '123' and start_validity_date = TO_DATE('09-SET-09', 'DD-MON-RR');
And this is the error:
Error SQL: ORA-14402: updating partition key column would cause a partition change
14402. 00000 - "updating partition key column would cause a partition change"
*Cause: An UPDATE statement attempted to change the value of a partition
key column causing migration of the row to another partition
*Action: Do not attempt to update a partition key column or make sure that
the new partition key is within the range containing the old
partition key.
I think that is impossible to use a PARTITION/SUBPARTITION like that: in fact the update of "END_VALIDITY_DATE" cause a partition change.
Do u agree or it's possible an update on a field that implies a partition change?
Regards Steve

Problems with Partition pruning using LIST option in 9i

I am declaring the following partitions on a fact table and when
I do an explain plan on the following SELECT statements it is
doing a full table scan on the fact table. However if I use
the "PARTITION" statement in the FROM clause it picks up the
correct partition and runs great. I have used the analyze
command and dbms_utility.analyze_schema command on all tables
and indexes. I had simaliar problems when partitioning with the
RANGE options too. I have looked through all of the INIT file
parameters and don't see anything obvious. Is there something I
am missing?
Any help would be appreciated!
Thanks,
Bryan
Facttable create statement....
CREATE TABLE FactTable (
ProductGID INTEGER NULL,
CustomerGID INTEGER NULL,
OrganizationGID INTEGER NULL,
TimeGID INTEGER NULL,
FactValue NUMBER NOT NULL,
ModDate DATE NULL,
CombinedGID INTEGER NOT NULL)
PARTITION BY LIST (CombinedGID)
(PARTITION sales1 VALUES(9999101),
PARTITION sales2 VALUES(9999102),
PARTITION sales3 VALUES(9999103),
PARTITION model1 VALUES(9999204),
PARTITION model2 VALUES(9999205),
PARTITION model3 VALUES(9999206));
Select statement....that is causing a full table scan.....the
*tc tables are the equivelent to dimension tables in a star
schema.
SELECT tco.parentgid, tcc.parentgid, tcp.parentgid, sum
(factvalue)
FROM facttable f, custtc tcc, timetc tct, prodtc tcp, orgtc tco
WHERE
tco.childgid = f.organizationgid
AND tco.parentgid = 18262
AND tcc.childgid = f.customergid
AND tcc.parentmembertypegid = 16
AND tcp.childgid = f.productgid
AND tcp.parentmembertypegid = 7
AND tct.childgid = f.timegid
AND tct.parentgid = 1009
GROUP BY tco.parentgid, tcc.parentgid, tcp.parentgid;
Select statement that works great....
SELECT tco.parentgid, tcc.parentgid, tcp.parentgid, sum
(factvalue)
FROM facttable partition(sales1) f, custtc tcc, timetc tct,
prodtc tcp, orgtc tco
WHERE
tco.childgid = f.organizationgid
AND tco.parentgid = 18262
AND tcc.childgid = f.customergid
AND tcc.parentmembertypegid = 16
AND tcp.childgid = f.productgid
AND tcp.parentmembertypegid = 7
AND tct.childgid = f.timegid
AND tct.parentgid = 1009
GROUP BY tco.parentgid, tcc.parentgid, tcp.parentgid;

Hi Hoek,
the DB version is 10.2 (italian version, then SET is correct).
...there's something strange: now I can INSERT rows but I can't update them!
I'm using this command string:
UPDATE TW_E_CUSTOMER_UNIFIED SET END_VALIDITY_DATE = TO_DATE('09-SET-09', 'DD-MON-RR') WHERE
id_customer_unified = '123' and start_validity_date = TO_DATE('09-SET-09', 'DD-MON-RR');
And this is the error:
Error SQL: ORA-14402: updating partition key column would cause a partition change
14402. 00000 - "updating partition key column would cause a partition change"
*Cause: An UPDATE statement attempted to change the value of a partition
key column causing migration of the row to another partition
*Action: Do not attempt to update a partition key column or make sure that
the new partition key is within the range containing the old
partition key.
I think that is impossible to use a PARTITION/SUBPARTITION like that: in fact the update of "END_VALIDITY_DATE" cause a partition change.
Do u agree or it's possible an update on a field that implies a partition change?
Regards Steve

Drop partition with missing associate Tablespace

Hi All,
Scenario is user accidentally removed datafile using rm command then we dropped that Tablespace using offline drop. we want to drop partition for which TS and datafile both are already offline dropped .
Thanks.

>
I tried to exchange partition with another table having same properties of original table. While doing so it prompted below error,
ORA-14292: Partitioning type of table must match subpartitioning type of composite partition
>
Then most likely the table and partition do NOT have the same properties.
If you want to exchange a partition of a table that is subpartitioned then the other table has to be partitioned in the same way that the main table is subpartitioned.
Post the DDL for the main table that shows how it is partitioned/subpartitioned and the DDL for the work table you are trying to use for the exchange.
See my reply Posted: Jan 7, 2013 7:02 PM in this thread for a solution that uses exchange partition is a similar manner
Merge tables

Partitions/subpartitions

Similar Messages

Maybe you are looking for