Range Partitioning a table. Max value to be defined

Hi,
I am using a range partitioned table, range partitioned on date, and have defined max value as 6 months after the Creation Date.
I have a proc which creates the partitions I want in advance by splitting up the max partition.
- Now what do I do when max partition is reached after 6 months?
- If I define max partition one year or two year after the current date instead of the currently defined 6 months after creation date. What are the negatives attached with it?
I can't use Interval Partition and have to use Range only.
Kindly suggest.
Thanks..

>
I am using a range partitioned table, range partitioned on date, and have defined max value as 6 months after the Creation Date.
I have a proc which creates the partitions I want in advance by splitting up the max partition.
- Now what do I do when max partition is reached after 6 months?
- If I define max partition one year or two year after the current date instead of the currently defined 6 months after creation date. What are the negatives attached with it?
>
Any data with a partition key that does NOT match any partition will cause your INSERT query to fail.
Any partition that has no data to match it will simply remain empty.
A common partitioning scheme is to define one partition for all old data, one partition with a high max value and then split the max value partition to get the partitions you want in the middle.
Let's say you want monthly partitions but don't have that much data from before the current year, 2012.
1. Create one partition for dates < 1/1/2012
2. One partition each for the 12 months of 2012
3. One max value partition to be 1/1/4000
You would just split the max value partition to create each month of 2013. The split could be done ahead of time or a month at a time as you choose.
The only negative is that any data inserted by mistake that has a super-high date will go into the max value partition. But that is going to happen anyway. If you accidentally enter a date of 3/23/3882 it won't be rejected.
But it is easy to query periodically to see if you have any 'bad' data like that. And the alternative is that an INSERT would fail because of the one bad record and all of your good data would be rejected anyway so it's not really much of a negative.
Remember - for best management performance each partition should have its own tablespace and the indexes should all be local if possible.

Similar Messages

Range Partitioning Existing table

Hi,
I have a table with numeric field. I want to range partition the existing table. I used the following query
alter table dept add partition by range(deptno) (
partition p1 values less than (20),
partition p1 values less than (40))
It gives me ORA-00902: invalid datatype.
What am I doing wrong? Is it possible to partition an existing table?
Regards,
Subbu S.

Hi,
You cannot partition an existing table with an ALTER TABLE command. There are couple of techinques with which you can partition an existing table, like:
1) Rename existing table, create a new partitoned table and move data.
2) Using DBMS_REDEFINITION package.
Have a look at the following links for details:
http://www.oracle-base.com/articles/misc/PartitioningAnExistingTable.php
http://www.dba-oracle.com/oracle_news/2004_3_9_rittman.htm
Regards
Asif Momen
http://momendba.blogspot.com

Range Partitioning of Table

Hi all,
I need to do range partitioning on a table using current system timestamp. sth like
CREATE TABLE SAMPLE(ID NUMBER, SAMPLE_DATE TIMESTAMP)PARTITION BY RANGE(SAMPLE_DATE)(PARTITION P1 VALUES LESS THAN (LOCALTIMESTAMP));
Is there any way I can assign a dynamic date using variable other than string literal after VALUES LESS THAN clause? I tried achieving this with stored procedure but always throws error for this filed.
CREATE OR REPLACE PROCEDURE partition_test
IS
x TIMESTAMP;
comm long;
BEGIN
SELECT LOCALTIMESTAMP into x from dual;
comm := 'CREATE TABLE SAMPLE(ID NUMBER, SAMPLE_DATE TIMESTAMP)PARTITION BY RANGE(SAMPLE_DATE)(PARTITION P1 VALUES LESS THAN (x))';
execute immediate comm;
END partition_test;
error I'm getting is
ORA-14019: partition bound element must be one of: string, datetime or interval literal, number, or MAXVALUE
Any clue? Would really appreciate your help.
Noman

Can you please try with proper quotes like this...
comm := 'CREATE TABLE SAMPLE(ID NUMBER, SAMPLE_DATE TIMESTAMP)PARTITION BY RANGE(SAMPLE_DATE)(PARTITION P1 VALUES LESS THAN (' || x || '))';
If that didn't work out, try printing the value of comm before execute immediate and if required you can add proper number of quotes.

Range Partitioning a table based on day of the week

I have a logging table which i want to partition into 7 partition, each one for the day of the week, eg MON,TUE, WED. I am aware and I can do a list partition by creating a parition key which stores 'DY' of the week and this means that I need to add another column to the existing table.
I wanted to explore the option of creating a range parition based on the timestamp column that already exists. Can anyone let me know if this option is possible?
Example
create table test_partition
( log_id number,
log_date TIMESTAMP(6),
log_value varchar2(100)
PARTITION BY RANGE (log_date)
PARTITION p1_mon VALUES LESS THAN (), ---- Not sure what can be used here to create this parition.
PARTITION p2_tue VALUES LESS THAN (),
PARTITION p3_wed VALUES LESS THAN (),
PARTITION p4_thu VALUES LESS THAN (),
PARTITION p5_fri VALUES LESS THAN (),
PARTITION p6_sat VALUES LESS THAN (),
PARTITION p7_sun VALUES LESS THAN ()
Any oracle guru with some suggestion for this would be highly appreciated..
Cheers,
VJ

Something like:
PARTITION P1_MON VALUES LESS THAN (TIMESTAMP'2009-03-10 00:00:00')
....Bear in mind that you will have to write a procedure to drop and create your daily partitions, and run that on a daily basis. Also you would be well advised to create a catchall partition that holds anything that won't go into your latest specified partition, eg:
PARTITION P_MAX VALUES LESS THAN (MAXVALUE)

Range partition the table ( containing huge data ) by month

There ia a table with huge data ard 9GB.This needs to range patitioned by month
to improve performance.
Can any one suggest me the best option to implement partitioning in this.

I have a lot of tables like this. My main tip is to never assign 'MAXVALUE' for your last partition, because it will give you major headaches when you need to add a partition for a future month.
Here is an example of one of my tables. Lots of columns are omitted, but this is enough to illustrate the partitioning.
CREATE TABLE "TSER"."TERM_DEPOSITS"
( "IDENTITY_CODE" NUMBER(10), "ID_NUMBER" NUMBER(25),
"GL_ACCOUNT_ID" NUMBER(14) NOT NULL ,
"ORG_UNIT_ID" NUMBER(14) NOT NULL ,
"COMMON_COA_ID" NUMBER(14) NOT NULL ,
"AS_OF_DATE" DATE,
"ISO_CURRENCY_CD" VARCHAR2(15) DEFAULT 'USD' NOT NULL ,
"IDENTITY_CODE_CHG" NUMBER(10)
CONSTRAINT "TERM_DEPOSITS"
PRIMARY KEY ("IDENTITY_CODE", "ID_NUMBER", "AS_OF_DATE") VALIDATE )
TABLESPACE "DATA_TS" PCTFREE 10 INITRANS 1 MAXTRANS 255
STORAGE ( INITIAL 0K BUFFER_POOL DEFAULT)
LOGGING PARTITION BY RANGE ("AS_OF_DATE")
(PARTITION "P2008_06" VALUES LESS THAN (TO_DATE(' 2008-07-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
TABLESPACE "DATA_TS_PART1" PCTFREE 10 INITRANS 1
MAXTRANS 255 STORAGE ( INITIAL 1024K BUFFER_POOL DEFAULT)
LOGGING NOCOMPRESS , PARTITION "P2008_07" VALUES LESS THAN (TO_DATE(' 2008-08-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS',
'NLS_CALENDAR=GREGORIAN'))
TABLESPACE "DATA_TS_PART2" PCTFREE 10 INITRANS 1 MAXTRANS 255
STORAGE ( INITIAL 1024K BUFFER_POOL DEFAULT) LOGGING NOCOMPRESS )
PARALLEL 3

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

Doubt on Range Partitions

Hello everyone.
Oracle9i Enterprise Edition Release 9.2.0.5.0 - 64bit Production
18:44:45 161:tcs237427@EBPP> desc rs_ebpp.rs_mail_job
Name Null? Type
JOB_KEY NOT NULL VARCHAR2(50)
MOF_KEY NOT NULL VARCHAR2(50)
MOF_PATH VARCHAR2(255)
REPORT_ID NOT NULL NUMBER(38)
PROFILE_NAME VARCHAR2(25)
FILE_PATH VARCHAR2(1024)
JOB_DATE DATE
JOB_FINISH_DATE DATE
SCHEDULED NUMBER(38)
USER_ID VARCHAR2(25)
STATUS VARCHAR2(25)
COMMENTS VARCHAR2(255)
MAIL_FROM VARCHAR2(255)
MAIL_TO VARCHAR2(255)
MAIL_CC VARCHAR2(255)
MAIL_BCC VARCHAR2(255)
MAIL_SUBJECT VARCHAR2(255)
MAIL_MESSAGE VARCHAR2(512)
DATA7 VARCHAR2(50)
DATA8 VARCHAR2(50)
DATA9 VARCHAR2(50)
DATA20 DATE
DATA21 NUMBER
DATA22 NUMBER
DATA23 NUMBER
DATA24 NUMBER
DATA25 NUMBER
DATA26 FLOAT(126)
DATA27 FLOAT(126)
DATA28 FLOAT(126)
DATA29 FLOAT(126)
DATA30 FLOAT(126)
DATA10 VARCHAR2(50)
DATA11 VARCHAR2(50)
DATA12 VARCHAR2(50)
DATA13 VARCHAR2(50)
DATA14 VARCHAR2(50)
DATA1 VARCHAR2(50)
DATA15 VARCHAR2(50)
DATA16 DATE
DATA2 VARCHAR2(50)
DATA17 DATE
DATA3 VARCHAR2(50)
DATA4 VARCHAR2(50)
DATA18 DATE
DATA5 VARCHAR2(50)
DATA19 DATE
DATA6 VARCHAR2(50)
I tried to create range partition on table whose partitioning key (JOB_KEY) was a VARCHAR2. I was able to create the partitions till 30th Jan.
16:56:32 SQL> SELECT PARTITION_NAME,TABLE_NAME,HIGH_VALUE FROM DBA_TAB_PARTITIONS WHERE TABLE_NAME='RS_MAIL_JOB_NEW' ORDER BY 1;
Partition
Name TABLE_NAME HIGH_VALUE
P110101 RS_MAIL_JOB_NEW TO_DATE('2011-01-02 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110102 RS_MAIL_JOB_NEW TO_DATE('2011-01-03 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110103 RS_MAIL_JOB_NEW TO_DATE('2011-01-04 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110104 RS_MAIL_JOB_NEW TO_DATE('2011-01-05 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110105 RS_MAIL_JOB_NEW TO_DATE('2011-01-06 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110106 RS_MAIL_JOB_NEW TO_DATE('2011-01-07 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110107 RS_MAIL_JOB_NEW TO_DATE('2011-01-08 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110108 RS_MAIL_JOB_NEW TO_DATE('2011-01-09 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110109 RS_MAIL_JOB_NEW TO_DATE('2011-01-10 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110110 RS_MAIL_JOB_NEW TO_DATE('2011-01-11 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110111 RS_MAIL_JOB_NEW TO_DATE('2011-01-12 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110112 RS_MAIL_JOB_NEW TO_DATE('2011-01-13 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110113 RS_MAIL_JOB_NEW TO_DATE('2011-01-14 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110114 RS_MAIL_JOB_NEW TO_DATE('2011-01-15 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110115 RS_MAIL_JOB_NEW TO_DATE('2011-01-16 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110116 RS_MAIL_JOB_NEW TO_DATE('2011-01-17 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110117 RS_MAIL_JOB_NEW TO_DATE('2011-01-18 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110118 RS_MAIL_JOB_NEW TO_DATE('2011-01-19 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110119 RS_MAIL_JOB_NEW TO_DATE('2011-01-20 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110120 RS_MAIL_JOB_NEW TO_DATE('2011-01-21 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110121 RS_MAIL_JOB_NEW TO_DATE('2011-01-22 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110122 RS_MAIL_JOB_NEW TO_DATE('2011-01-23 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110123 RS_MAIL_JOB_NEW TO_DATE('2011-01-24 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110124 RS_MAIL_JOB_NEW TO_DATE('2011-01-25 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110125 RS_MAIL_JOB_NEW TO_DATE('2011-01-26 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110126 RS_MAIL_JOB_NEW TO_DATE('2011-01-27 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110127 RS_MAIL_JOB_NEW TO_DATE('2011-01-28 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110128 RS_MAIL_JOB_NEW TO_DATE('2011-01-29 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110129 RS_MAIL_JOB_NEW TO_DATE('2011-01-30 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
P110130 RS_MAIL_JOB_NEW TO_DATE('2011-01-31 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN
But after that I started getting below error:
16:56:40 SQL> alter table rs_ebpp.rs_mail_job_new add partition p110131 values less than (to_date('2011-02-01 00:00:00', 'SYYYY-mm-dd h
h24:mi:ss', 'nls_calendar=GREGORIAN'));
alter table rs_ebpp.rs_mail_job_new add partition p110131 values less than (to_date('2011-02-01 00:00:00', 'SYYYY-mm-dd hh24:mi:ss', 'n
ls_calendar=GREGORIAN'))
ERROR at line 1:
ORA-14074: partition bound must collate higher than that of the last partition
I checked the manual, but didn't find it written anywhere about restriction on column data type for Range partition or others.
I doubt if creating range partitions on columns with varchar2 is allowed and if yes, not sure why I get that error

Try to split first partition:
alter table rs_ebpp.rs_mail_job_new
split partition p110201 at (to_date('2011-31-01 00:00:00', 'SYYYY-mm-dd hh24:mi:ss', 'nls_calendar=GREGORIAN'))
into (partition p110131, partition p110201) ;

How to split max_value range partition

Hi,
How to split partition range partition .
I have already range partition on table but Yearly partition and i want to do monthly partition on Max_Value partition.
How to split partition on max_value?

Hi,
Some examples can be found here:
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:660224234238

How to find out the min & max partition_id in a range partition?

Hi we have a table set up by range partition
In the table creation script. It goes something like:
PARTITION PARTD_CUST_3_1_NEW VALUES LESS THAN ('39500')
so how we can find out this number '39500' from some of the data_dictionary view?
What we want to do is to set up parallel processing (do-it-yourself) based on partition.
So the number of parallel process will be based on this ID-range.
I can find out how many partitions are there by using something like this:
SELECT COUNT(*)
FROM all_tab_partitions WHERE table_owner='OWNER_NAME' AND table_name='TABLE_NAME'
We have 5 partitions now but the table structure can change in the near future even this table has moer than 130Million rows
I do not want to hardcode this "39500" just in case the table structure changes (partition structure changes)
Any idea ??

vxwo0owxv wrote:
Hi we have a table set up by range partition
In the table creation script. It goes something like:
PARTITION PARTD_CUST_3_1_NEW VALUES LESS THAN ('39500')
so how we can find out this number '39500' from some of the data_dictionary view?
What we want to do is to set up parallel processing (do-it-yourself) based on partition.
So the number of parallel process will be based on this ID-range.
I can find out how many partitions are there by using something like this:
SELECT COUNT(*)
FROM all_tab_partitions WHERE table_owner='OWNER_NAME' AND table_name='TABLE_NAME'
We have 5 partitions now but the table structure can change in the near future even this table has moer than 130Million rows
I do not want to hardcode this "39500" just in case the table structure changes (partition structure changes)
Any idea ??query DBA_TAB_PARTITIONS.HIGH_VALUE

Non-Partitioned Global Index on Range-Partitioned Table.

Hi All,
Is it possible to create Non-Partitioned Global Index on Range-Partitioned Table?
We have 4 indexes on CS_BILLING range-partitioned table, in which one is CBS_CLIENT_CODE(*local partitioned index*) and others are unknown types of index to me??
Means other 3 indexes are what type indexes ...either non-partitioned global index OR non-partitioned normal index??
Also if we create index as :(create index i_name on t_name(c_name)) By default it will create Global index. Please correct me......
Please help me in identifying other 3 indexes types by referring below ouputs!!!
select INDEX_NAME,TABLE_NAME,PARTITIONING_TYPE,LOCALITY from dba_part_indexes where TABLE_NAME='CS_BILLING';
INDEX_NAME TABLE_NAME PARTITI LOCALI
CSB_CLIENT_CODE CS_BILLING RANGE LOCAL
select index_name,index_type,table_name,table_type,PARTITIONED from dba_indexes where table_name='CS_BILLING';
INDEX_NAME INDEX_TYPE TABLE_NAME TABLE_TYPE PAR
CSB_CREATE_DATE NORMAL CS_BILLING TABLE NO
CSB_SUBMIT_ORDER NORMAL CS_BILLING TABLE NO
CSB_CLIENT_CODE NORMAL CS_BILLING TABLE YES
CSB_ORDER_NBR NORMAL CS_BILLING TABLE NO
select INDEX_OWNER,INDEX_NAME,TABLE_NAME,COLUMN_NAME from dba_ind_columns where TABLE_NAME='CS_BILLING';
INDEX_OWNER INDEX_NAME TABLE_NAME COLUMN_NAME
RPADMIN CSB_CREATE_DATE CS_BILLING CREATE_DATE
RPADMIN CSB_SUBMIT_ORDER CS_BILLING SUBMIT_TO_INVOICE
RPADMIN CSB_SUBMIT_ORDER CS_BILLING ORDER_NBR
RPADMIN CSB_CLIENT_CODE CS_BILLING CLIENT_CODE
RPADMIN CSB_ORDER_NBR CS_BILLING ORDER_NBR
select dip.index_name, dpi.locality, dip.partition_name, dip.status
from dba_part_indexes dpi, dba_ind_partitions dip
where dpi.table_name ='CS_BILLING'
and dpi.index_name = dip.index_name;
INDEX_NAME LOCALI PARTITION_NAME STATUS
CSB_CLIENT_CODE LOCAL CSB_2006_4Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2006_3Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2007_1Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2007_2Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2007_3Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2007_4Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2008_1Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2008_2Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2008_3Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2008_4Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2009_1Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2009_2Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2009_3Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2009_4Q USABLE
select * from dba_part_indexes
where table_name ='CS_BILLING'
and locality = 'GLOBAL';
no rows selected
-Yasser
Edited by: YasserRACDBA on Mar 5, 2009 11:45 PM

Yaseer,
Is it possible to create Non-Partitioned and Global Index on Range-Partitioned Table?
Yes
We have 4 indexes on CS_BILLING range-partitioned table, in which one is CBS_CLIENT_CODE(*local partitioned index*) and others are unknown types of index to me??
Means other 3 indexes are what type indexes ...either non-partitioned global index OR non-partitioned normal index??
You got local index and 3 non-partitioned "NORMAL" b-tree tyep indexes
Also if we create index as :(create index i_name on t_name(c_name)) By default it will create Global index. Please correct me......
Above staement will create non-partitioned index
Here is an example of creating global partitioned indexes
CREATE INDEX month_ix ON sales(sales_month)
   GLOBAL PARTITION BY RANGE(sales_month)
      (PARTITION pm1_ix VALUES LESS THAN (2)
       PARTITION pm2_ix VALUES LESS THAN (3)
       PARTITION pm3_ix VALUES LESS THAN (4)
        PARTITION pm12_ix VALUES LESS THAN (MAXVALUE));Regards

Problem with a 2 columns Range Partitioning for a indexed organized table

have an indexed organized table with a 2 column PK. the first field (datum) is a date field the second field (installatieid) is a number(2) field.
Every minute a 7 records are inserted (installatieid 0-6).
I like to partition this table with one partition per year per installatieid.
I tried to do it with:
partition by range(datum,installatieid)
(partition P_2004_0 values less than (to_date('2004-01,'yyyy-mm'),1)
,partition P_2004_6 values less than (to_date('2004-01','yyyy-mm'),7)
partition P_2005_0 values less than (to_date('2005-01','yyyy-mm'),1)
,partition P_2005_6 values less than (to_date('2005-01','yyyy-mm'),7)
but now only the P_2004_0 and P_2005_0 are filled.
I thought about to combine a range partition on datum with a list subpartition on installatieid, but I read this is not allowed with an index organized table.
How can I solve this problem.

partition by range(datum,installatieid)
(partition P_2004_0 values less than
(to_date('2004-01,'yyyy-mm'))
,partition P_2004_6 values less than
(to_date('2004-07','yyyy-mm'))
partition P_2005_0 values less than
(to_date('2005-01','yyyy-mm'))
,partition P_2005_6 values less than
(to_date('2005-07','yyyy-mm'))
? Sorry haven't got time to test it this morning ;0)

Partition Pruning on Interval Range Partitioned Table not happening when SYSDATE used in Where Clause

We have tables that are interval range partitioned on a DATE column, with a partition for each day - all very standard and straight out of Oracle doc.
A 3rd party application queries the tables to find number of rows based on date range that is on the column used for the partition key.
This application uses date range specified relative to current date - i.e. for last two days would be "..startdate > SYSDATE -2 " - but partition pruning does not take place and the explain plan shows that every partition is included.
By presenting the query using the date in a variable partition pruning does table place, and query obviously performs much better.
DB is 11.2.0.3 on RHEL6, and default parameters set - i.e. nothing changed that would influence optimizer behavior to something unusual.
I can't work out why this would be so. It very easy to reproduce with simple test case below.
I'd be very interested to hear any thoughts on why it is this way and whether anything can be done to permit the partition pruning to work with a query including SYSDATE as it would be difficult to get the application code changed.
Furthermore to make a case to change the code I would need an explanation of why querying using SYSDATE is not good practice, and I don't know of any such information.
1) Create simple partitioned table
CREATETABLE part_test
   (id                      NUMBER NOT NULL,
    starttime               DATE NOT NULL,
    CONSTRAINT pk_part_test PRIMARY KEY (id))
PARTITION BY RANGE (starttime) INTERVAL (NUMTODSINTERVAL(1,'day')) (PARTITION p0 VALUES LESS THAN (TO_DATE('01-01-2013','DD-MM-YYYY')));
2) Populate table 1million rows spread between 10 partitions
BEGIN
    FOR i IN 1..1000000
    LOOP
        INSERT INTO part_test (id, starttime) VALUES (i, SYSDATE - DBMS_RANDOM.value(low => 1, high => 10));
    END LOOP;
END;
EXEC dbms_stats.gather_table_stats('SUPER_CONF','PART_TEST');
3) Query the Table for data from last 2 days using SYSDATE in clause
EXPLAIN PLAN FOR
SELECT count(*)
FROM    part_test
WHERE   starttime >= SYSDATE - 2;
| Id | Operation                 | Name      | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT          |           |     1 |     8 | 7895 (1)| 00:00:01 |       |       |
|   1 | SORT AGGREGATE           |           |     1 |     8 |            |          |       |       |
|   2 |   PARTITION RANGE ITERATOR|           |   111K|   867K| 7895   (1)| 00:00:01 |   KEY |1048575|
|* 3 |    TABLE ACCESS FULL      | PART_TEST |   111K|   867K| 7895   (1)| 00:00:01 |   KEY |1048575|
Predicate Information (identified by operation id):
   3 - filter("STARTTIME">=SYSDATE@!-2)
4) Now do the same query but with SYSDATE - 2 presented as a literal value.
This query returns the same answer but very different cost.
EXPLAIN PLAN FOR
SELECT count(*)
FROM part_test
WHERE starttime >= (to_date('23122013:0950','DDMMYYYY:HH24MI'))-2;
| Id | Operation                 | Name      | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT          |           |     1 |     8 |   131 (0)| 00:00:01 |       |       |
|   1 | SORT AGGREGATE           |           |     1 |     8 |            |          |       |       |
|   2 |   PARTITION RANGE ITERATOR|           |   111K|   867K|   131   (0)| 00:00:01 |   356 |1048575|
|* 3 |    TABLE ACCESS FULL      | PART_TEST |   111K|   867K|   131   (0)| 00:00:01 |   356 |1048575|
Predicate Information (identified by operation id):
   3 - filter("STARTTIME">=TO_DATE(' 2013-12-21 09:50:00', 'syyyy-mm-dd hh24:mi:ss'))
thanks in anticipation
Jim

As Jonathan has already pointed out there are situations where the CBO knows that partition pruning will occur but is unable to identify those partitions at parse time. The CBO will then use a dynamic pruning which means determine the partitions to eliminate dynamically at run time. This is why you see the KEY information instead of a known partition number. This is to occur mainly when you compare a function to your partition key i.e. where partition_key = function. And SYSDATE is a function. For the other bizarre PSTOP number (1048575) see this blog
http://hourim.wordpress.com/2013/11/08/interval-partitioning-and-pstop-in-execution-plan/
Best regards
Mohamed Houri

Range partitioning and update to range value

There is a V. large table on our system, where a column is initally set to NULL, but updated with sysdate when processed. The majority of qureies against this table are for those with NULL values. I'm considering range partitioning by this column, where all NULLs will appear in the one partition, all non_NULLs in the other. The questions are.....
1)will a row automatically move from one partion to the next on update of the NULL value
2) If so, what are the overheads

Using ENABLE ROW MOVEMENT will work, but the overhead of moving the rows is fairly high. If the date column is only updated once over the life of the record, then this overhead may be acceptable. However, if the date field is updated to sysdate most times the record is touched, then this may be a large performance hit.
You may want to investigate the use of a function based index to get the NULL dates indexed. A function like:
DECODE(date_field,NULL,1,NULL)
would create an index containing only the null rows. Then a query like:
SELECT stuff
FROM table
WHERE DECODE(date_field,NULL,1,NULL) = 1would likely do and index range scan.
TTFN
John

Best approach to do Range partitioning on Huge tables.

Hi All,
I am working on 11gR2 oracle 3node RAC database. below are the db details.
SQL> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE 11.2.0.3.0 Production
TNS for Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
in my environment we have 10 big transaction (10 billion rows) tables and it is growing bigger and bigger. Now the management is planning to do a range partition based on created_dt partition key column.
We tested this partitioning startegy with few million record in other environment with below steps.
1. CREATE TABLE TRANSACTION_N
PARTITION BY RANGE ("CREATED_DT")
( PARTITION DATA1 VALUES LESS THAN (TO_DATE(' 2012-08-01 00:00:00', 'YYYY-MM-DD HH24:MI:SS') ) TABLESPACE &&TXN_TAB_PART1,
PARTITIONDATA2 VALUES LESS THAN (TO_DATE(' 2012-09-01 00:00:00', 'YYYY-MM-DD HH24:MI:SS') ) TABLESPACE &&TXN_TAB_PART2,
PARTITION DATA3 VALUES LESS THAN (TO_DATE(' 2012-10-01 00:00:00', 'YYYY-MM-DD HH24:MI:SS') ) TABLESPACE &&TXN_TAB_PART3
as (select * from TRANSACTION where 1=2);
2. exchange partion for data move to new partition table from old one.
ALTER TABLE TRANSACTION_N
EXCHANGE PARTITION DATA1
WITH TABLE TRANSACTION
WITHOUT VALIDATION;
3. create required indexes (took almost 3.5 hrs with parallel 16).
4. Rename the table names and drop the old tables.
this took around 8 hrs for one table which has 70 millions of records, then for billions of records it will take more than 8 hrs. But the problem is we get only 2 to 3 hrs of down time in production to implement these change for all tables.
Can you please suggest the best approach i can do, to copy that much big data from existing table to the newly created partitioned table and create required indexes.
Thanks,
Hari

>
in my environment we have 10 big transaction (10 billion rows) tables and it is growing bigger and bigger. Now the management is planning to do a range partition based on created_dt partition key column.
We tested this partitioning startegy with few million record in other environment with below steps.
1. CREATE TABLE TRANSACTION_N
PARTITION BY RANGE ("CREATED_DT")
( PARTITION DATA1 VALUES LESS THAN (TO_DATE(' 2012-08-01 00:00:00', 'YYYY-MM-DD HH24:MI:SS') ) TABLESPACE &&TXN_TAB_PART1,
PARTITIONDATA2 VALUES LESS THAN (TO_DATE(' 2012-09-01 00:00:00', 'YYYY-MM-DD HH24:MI:SS') ) TABLESPACE &&TXN_TAB_PART2,
PARTITION DATA3 VALUES LESS THAN (TO_DATE(' 2012-10-01 00:00:00', 'YYYY-MM-DD HH24:MI:SS') ) TABLESPACE &&TXN_TAB_PART3
as (select * from TRANSACTION where 1=2);
2. exchange partion for data move to new partition table from old one.
ALTER TABLE TRANSACTION_N
EXCHANGE PARTITION DATA1
WITH TABLE TRANSACTION
WITHOUT VALIDATION;
3. create required indexes (took almost 3.5 hrs with parallel 16).
4. Rename the table names and drop the old tables.
this took around 8 hrs for one table which has 70 millions of records, then for billions of records it will take more than 8 hrs. But the problem is we get only 2 to 3 hrs of down time in production to implement these change for all tables.
Can you please suggest the best approach i can do, to copy that much big data from existing table to the newly created partitioned table and create required indexes.
>
Sorry to tell you but that test and partitioning strategy is essentially useless and won't work for you entire table anyway. One reasone is that if you use the WITHOUT VALIDATION clause you must ensure that the data being exchanged actually belongs to the partition you are putting it in. If it doesn't you won't be able to reenable or rebuild any primary key or unique constraints that exist on the table.
See Exchanging Partitions in the VLDB and Partitioning doc
http://docs.oracle.com/cd/E18283_01/server.112/e16541/part_admin002.htm#i1107555
>
When you specify WITHOUT VALIDATION for the exchange partition operation, this is normally a fast operation because it involves only data dictionary updates. However, if the table or partitioned table involved in the exchange operation has a primary key or unique constraint enabled, then the exchange operation is performed as if WITH VALIDATION were specified to maintain the integrity of the constraints.
If you specify WITHOUT VALIDATION, then you must ensure that the data to be exchanged belongs in the partition you exchange.
>
Comments below are limited to working with ONE table only.
ISSUE #1 - ALL data will have to be moved regardless of the approach used. This should be obvious since your current data is all in one segment but each partition of a partitioned table requires its own segment. So the nut of partitioning is splitting the existing data into multiple segments almost as if you were splitting it up and inserting it into multiple tables, one table for each partition.
ISSUE#2 - You likely cannot move that much data in the 2 to 3 hours window that you have available for down time even if all you had to do was copy the existing datafiles.
ISSUE#3 - Even if you can avoid issue #2 you likely cannot rebuild ALL of the required indexes in whatever remains of the outage windows after moving the data itself.
ISSUE#4 - Unless you have conducted full volume performance testing in another environment prior to doing this in production you are taking on a tremendous amount of risk.
ISSUE#5 - Unless you have fully documented the current, actual execution plans for your most critical queries in your existing system you will have great difficulty overcoming issue #4 since you won't have the requisite plan baseline to know if the new partitioning and indexing strategies are giving you the equivalent, or better, performance.
ISSUE#6 - Things can, and will, go wrong and cause delays no matter which approach you take.
So assuming you plan to take care of issues #4 and #5 you will probably have three viable alternatives:
1. use DBMS_REDEFINITION to do the partitioning on-line. See the Oracle docs and this example from oracle-base for more info.
Redefining Tables Online - http://docs.oracle.com/cd/B28359_01/server.111/b28310/tables007.htm
Partitioning an Existing Table using DBMS_REDEFINITION
http://www.oracle-base.com/articles/misc/partitioning-an-existing-table.php
2. do the partitioning offline and hope that you don't exceed your outage window. Recover by continuing to use the existing table.
3. do the partitioning offline but remove the oldest data to minimize the amount of data that has to be worked with.
You should review all of the tables to see if you can remove older data from the current system. If you can you could use online redefinition that ignores older data. Then afterwards you can extract this old data from the old table for archiving.
If the amount of old data is substantial you can extract the new data to a new partitioned table in parallel and not deal with the old data at all.

1.5 Edit Table Partitions - Can not edit Values Less than Field

When editing (or more importantly to me) creating new partitions through the GUI. This slao was an issue w/1.2.1 that I recently discovered, I was hoping that it would have gotten fixed in 1.5

Just to confirm this is only a problem when editing a table? It seems fine when creating a table from scratch.
The field is disabled when editing an existing partition because there isn't (as far as I can tell) an ALTER TABLE clause for changing the less than value of a range partition.
It's a bug that when you create a new partition, while editing a table, the field is still disabled. I'll log it now.

Range Partitioning a table. Max value to be defined

Similar Messages

Maybe you are looking for