Change Range Partition Condition

Hi all,
I have one partition table where the last two partitions are as below:
PARTITION "PT_CKPT_PART2009" VALUES LESS THAN (TO_DATE(' 2009-12-20 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
PARTITION "PT_CKPT_PARTMX" VALUES LESS THAN (MAXVALUE)
Now as per the year-end process I need to split the MAXVALUE partition to add the new partition for 2010 and that ok with me.
But, our users want us to modify the existing last partition and change the condition to as below:
VALUES LESS THAN (TO_DATE(' 2010-01-03 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
I am not sure how to achieve the same. I am new to this partition maintenance activity.
Please help me to achieve the same.
Regards,
Soumyajit

Hi,
AFAIK, you need to drop the highest partition and recreate the new partition as per your requirement and then further highest partition. Check the indexes on the table too.
- Pavan Kumar N
Oracle 9i/10g - OCP
http://oracleinternals.blogspot.com/

Similar Messages

Range Partitioning on Varchar2 column???

We hava table and it has a date column and its type is varchar2.
This column's format is '16021013' ('ddmmyyyy').
We want to make range partition on this column. What will be the best way?
do you think virtal column partitioning will be efficient?

>
I'm not a new DBA:-) You can be sure. I asked only about range partitioning trick with varchar2 column because we did our examination about this table. We will need to archive this table quarter by quarter to the other archive database. Then, off course, nearly all queries are coming firstly by using this date column and they can have different filtering inside "where" conditions. Already, this table has index on this column but with huge number of data, index performance is not enough for us. This is a 7x24 banking system and we are lately joined to this project. Because of this, we cant change everything like changing data type of that column after this moment.
>
You are taking things way too personally. No one said anything about whether you were, or were not, a DBA or made any other comments about your skill or abilities.
What we ask was for you to tell us WHAT the problem was that you were trying to solve and WHY you thought partitioning would solve it.
And now, after several generic posts, you have finally provided that information. We can only comment based on the information that you post. We can't guess as to what types of queries you use or what kinds of predicates you use in those queries. But we need to know that information in order to provide the best advice.
Next time you post put the important information in your original question:
1. A table column is VARCHAR2 but contains a date value. We are unable to change the datatype of this column.
2. We need to archive data quarterly based on this date value
3. Nearly all queries use this date value and then also may have additional filter conditions
4. This date column is indexed but we would like to improve the performance beyond what this index can give us.
The above is a summary that includes all important information that is needed to know how best to help you.
And I made a pretty good guess since two replies ago I provided you with example code that shows just how to partition the table.
>
Now, our only aim is how to make range partitioning this varchar2 date column.
>
As I showed you in my example code earlier you can add a virtual column to the table and partition on it. My example code creates a monthly partitioned table that allows you to archive by month or archive every three months to archive by quarter.
You can modify that example to use quarterly partitions if you want but I would recommend that you use standard monthly partitions since they will satisfy the widest range of predicates.

Cost to change hash partition key column in a history table

Hi All,
I have the following scenario.
We have a history table in production which has 16 hash partitions on the basis of key_column.
But the nature of data that we have in history table that has 878 distinct values of the key_column and about 1000 million data and all partitons are in same tablespace.
Now we have a Pro*C module which purges data from this history table in the following way..
> DELETE FROM hsitory_tab
> WHERE p_date < (TO_DATE(sysdate+1, 'YYYYMMDD') - 210)
> AND t_date < (TO_DATE(sysdate+1, 'YYYYMMDD') - 210)
> AND ROWNUM <= 210;
Now (p_date,t_data are one of the two columns in history table) data is deleted using thiese two date column conditions but key_column for partition is different.
So as per aboove statement this history table containd 6 months data.
DBA is asking to change this query and use partiton date wise.Now will it be proper to change the partition key_column (the existing hash partiton key_column >have 810 distinct values) and what things we need to cosider to calculate cost behind this hash partition key_column cahange(if it is appropriate to change >partition )key_column)Hope i explained my problem clearly and waiting for your suggestions .
Thanks in advance.

Hi Sir
Many thanks for the reply.
For first point -
we are in plan to move the database to 10g after a lot of hastle between client.For second point -
If we do partition by date or week we will have 30 or 7 partitions .As suggested by you as we have 16 partitions in the table best approach would be to have >partition by week then we will have 7 partitions and then each query will heat 7 partitions .For third point -
Our main aim to reduce the timings of a job(a Pro*C program) which contains the following delete query to delete data from a history table .So accroding to the >query it is deleting data every day for 7 months and while deleting it it queries this hug etable by date.So in this case hash partition or range partiton or >hash/range partition which will be more suitable.
DELETE FROM hsitory_tab
WHERE p_date < (TO_DATE(sysdate+1, 'YYYYMMDD') - 210)
AND t_date < (TO_DATE(sysdate+1, 'YYYYMMDD') - 210)
AND ROWNUM <= 210;I have read in hash partition is used so that data will be evenly distributed in all partitions (though it depends on nature of data).In my case i want some suggestion from you to take the best approach .

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

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

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.

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

Range partitioning of 3 columns

Hello!
I use Oracle 10g with SH schema.
Now I want to create a new table SALES_SH that have range partition of 3 columns:
create table SH.SALES_SH (PROD_ID NUMBER, CUST_ID NUMBER, TIME_ID DATE, CHANNEL_ID NUMBER, PROMO_ID NUMBER, QUANTITY_SOLD NUMBER(10,2), AMOUNT_SOLD NUMBER(10,2), COUNTRY_ID NUMBER, PROD_CATEGORY_ID NUMBER, FISCAL_YEAR NUMBER(4))
PARTITION BY RANGE (FISCAL_YEAR, COUNTRY_ID, PROD_CATEGORY_ID)
(PARTITION S_2000_GM_EL VALUES LESS THAN (2001,52789,203),
PARTITION S_2000_GM_PA VALUES LESS THAN (2001,52789,205),
PARTITION S_2000_GM_SO VALUES LESS THAN (2001,52789,206),
PARTITION S_2000_UK_EL VALUES LESS THAN (2001,52790,203),
PARTITION S_2000_UK_PA VALUES LESS THAN (2001,52790,205),
PARTITION S_2000_UK_SO VALUES LESS THAN (2001,52790,206),
PARTITION S_2000_US_EL VALUES LESS THAN (2001,52791,203),
PARTITION S_2000_US_PA VALUES LESS THAN (2001,52791,205),
PARTITION S_2000_US_SO VALUES LESS THAN (2001,52791,206),
PARTITION S_2001_GM_EL VALUES LESS THAN (2002,52789,203),
PARTITION S_2001_GM_PA VALUES LESS THAN (2002,52789,205),
PARTITION S_2001_GM_SO VALUES LESS THAN (2002,52789,206),
PARTITION S_2001_UK_EL VALUES LESS THAN (2002,52790,203),
PARTITION S_2001_UK_PA VALUES LESS THAN (2002,52790,205),
PARTITION S_2001_UK_SO VALUES LESS THAN (2002,52790,206),
PARTITION S_2001_US_EL VALUES LESS THAN (2002,52791,203),
PARTITION S_2001_US_PA VALUES LESS THAN (2002,52791,205),
PARTITION S_2001_US_SO VALUES LESS THAN (2002,52791,206),
PARTITION S_2002_GM_EL VALUES LESS THAN (2003,52789,203),
PARTITION S_2002_GM_PA VALUES LESS THAN (2003,52789,205),
PARTITION S_2002_GM_SO VALUES LESS THAN (2003,52789,206),
PARTITION S_2002_UK_EL VALUES LESS THAN (2003,52790,203),
PARTITION S_2002_UK_PA VALUES LESS THAN (2003,52790,205),
PARTITION S_2002_UK_SO VALUES LESS THAN (2003,52790,206),
PARTITION S_2002_US_EL VALUES LESS THAN (2003,52791,203),
PARTITION S_2002_US_PA VALUES LESS THAN (2003,52791,205),
PARTITION S_2002_US_SO VALUES LESS THAN (2003,52791,206));
Here is the Data:
INSERT INTO SH.SALES_SH
SELECT SALES.PROD_ID, SALES.CUST_ID, SALES.TIME_ID, CHANNEL_ID, PROMO_ID, QUANTITY_SOLD, AMOUNT_SOLD, COUNTRY_ID, PROD_CATEGORY_ID, FISCAL_YEAR
FROM SALES, CUSTOMERS, TIMES, PRODUCTS
WHERE SALES.PROD_ID=PRODUCTS.PROD_ID AND SALES.CUST_ID=CUSTOMERS.CUST_ID AND SALES.TIME_ID=TIMES.TIME_ID
AND (COUNTRY_ID=52790 OR COUNTRY_ID=52789 OR COUNTRY_ID=52776)
AND (PROD_CATEGORY_ID=201 OR PROD_CATEGORY_ID=203 OR PROD_CATEGORY_ID=205)
AND (FISCAL_YEAR=2000 OR FISCAL_YEAR=2001 OR FISCAL_YEAR=2002)
ORDER BY FISCAL_YEAR, COUNTRY_ID, PROD_CATEGORY_ID;
Note that, in Create table script, I use some "virtual value" (2003,52791,206) instead of MAXVALUE (because it get error)
It run. But the partitions with "virtual value" have no data, and the others data is wrong!
Please, help me! Thanks
TRAN MAI

OK. Here is the real data:
SELECT distinct fiscal_year, country_id, prod_category_id from sales_sh partition(s_2000_gm_el) order by fiscal_year, country_id, prod_category_id;
FISCAL_YEAR COUNTRY_ID PROD_CATEGORY_ID
2000 52776 201
2000 52776 203
2000 52776 205
2000 52789 201
2000 52789 203
2000 52789 205
2000 52790 201
2000 52790 203
2000 52790 205
2001 52776 201
2001 52776 203
FISCAL_YEAR COUNTRY_ID PROD_CATEGORY_ID
2001 52776 205
2001 52789 201
13 rows selected.
That mean, the PARTITION S_2000_GM_EL VALUES LESS THAN (2001,52789,203) get nearly all data.
That mean, VALUES LESS THAN (2001,52789,203) <=> Fiscal_year<2001 OR Country_id<52789 OR Prod_category_id<203 (the "OR" condition), while I want the "AND" condition.
Please, give me an advise! Thanks!
TRAN MAI

Convert range partition to range-hash composite partition

Hi,
I have several tables that are range partitioned on date and each table has several partitions as they are partitioned for each day. Is there anyway I con convet these table using alter statements to make them a composite? Thanks.

No, You can't with alter command change partitioning type.
http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b10739/partiti.htm
Create a new table with needed one partitioning type and insert there all data.

Problem exchanging partitions using range partitioning

I have a range-partitioned table. Here's a cut down version....
CREATE TABLE MY_TABLE
   (     VALUE           NUMBER,
     PARTITION_KEY      NUMBER
PARTITION BY RANGE ("PARTITION_KEY")
(PARTITION "P1" VALUES LESS THAN (2),
PARTITION "P2" VALUES LESS THAN (3),
PARTITION "P3" VALUES LESS THAN (4),
PARTITION "P4" VALUES LESS THAN (5),
PARTITION "P5" VALUES LESS THAN (6),
PARTITION "P6" VALUES LESS THAN (7),
PARTITION "P7" VALUES LESS THAN (8));For the process I'm working on, I want to be able to:
- create a table as a copy of one of the partitions
- do some processing on that table
- exchange the updated table back into the partitioned table
I can achieve this as follows....
CREATE TABLE MY_TABLE_COPY_P7 AS (SELECT * FROM MY_TABLE WHERE PARTITION_KEY = 7);
... do processing ...
ALTER TABLE MY_TABLE DROP PARTITION P7;
ALTER TABLE MY_TABLE ADD PARTITION P7 VALUES LESS THAN (8);
ALTER TABLE MY_TABLE EXCHANGE PARTITION P7 WITH TABLE MY_TABLE_COPY INCLUDING INDEXES;However, this only works if the partition I'm adding back in is the highest partition.
If I try do take out one of the middle partitions, then add it back I get an error:
SQL] ALTER TABLE MY_TABLE ADD PARTITION P5 VALUES LESS THAN (6);
ALTER TABLE MY_TABLE ADD PARTITION P5 VALUES LESS THAN (6)
ERROR at line 1:
ORA-14074: partition bound must collate higher than that of the last partitionAny ideas on how I can exchange one of the middle partitions with having to first drop the higher ones?
Btw, I have to use range partitioning as we're using spatial, which only supports range partitioning.
Cheers,

Actually, you can do the exchange partition thing with 8i and over. After creating my_table from your script, I did:
SQL> INSERT INTO my_table VALUES (1,7.5);
1 row created.
SQL> INSERT INTO my_table VALUES (2, 7.2);
1 row created.
SQL> INSERT INTO my_table VALUES (3,7.7);
1 row created.
SQL> CREATE TABLE my_tab_tmp AS
2 SELECT * FROM my_table
3 WHERE 1=2;
Table created.
SQL> ALTER TABLE my_table EXCHANGE PARTITION P7 WITH TABLE my_tab_tmp;
Table altered.
SQL> SELECT * FROM my_tab_tmp;
     VALUE PARTITION_KEY
         1           7.5
         2           7.2
         3           7.7
SQL> SELECT * FROM my_table;
no rows selected
SQL> UPDATE my_tab_tmp
2 set value = value * 20;
3 rows updated.
SQL> COMMIT;
Commit complete.
SQL> ALTER TABLE my_table EXCHANGE PARTITION P7 WITH TABLE my_tab_tmp;
Table altered.
SQL> SELECT * FROM my_tab_tmp;
no rows selected
SQL> SELECT * FROM my_table;
     VALUE PARTITION_KEY
        20           7.5
        40           7.2
        60           7.7You will, of course, need to re-build any global indexes on my_table.
When you first create my_tab_tmp, you should also create indexes to match any local indexes on the partitions, then do the exchange partition using the INCLUDING INDEXES clause. You could also skip creating the indexes and then re-create them after exchanging the updated table with the partition.
Note that none of this will work if you are changing values of partition_key so thatthey fall out of the range for the partition.
HTH
John

Creating Local partitioned index on Range-Partitioned table.

Hi All,
Database Version: Oracle 8i
OS Platform: Solaris
I need to create Local-Partitioned index on a column in Range-Partitioned table having 8 million records, is there any way to perform it in fastest way.
I think we can use Nologging, Parallel, Unrecoverable options.
But while considering Undo and Redo also mainly time required to perform this activity....Which is the best method ?
Please guide me to perform it in fastest way and also online !!!
-Yasser

YasserRACDBA wrote:
3. CREATE INDEX CSB_CLIENT_CODE ON CS_BILLING (CLIENT_CODE) LOCAL
NOLOGGING PARALLEL (DEGREE 14) online;
4. Analyze the table with cascade option.
Do you think this is the only method to perform operation in fastest way? As table contain 8 million records and its production database.Yasser,
if all partitions should go to the same tablespace then you don't need to specify it for each partition.
In addition you could use the "COMPUTE STATISTICS" clause then you don't need to analyze, if you want to do it only because of the added index.
If you want to do it separately, then analyze only the index. Of course, if you want to analyze the table, too, your approach is fine.
So this is how the statement could look like:
CREATE INDEX CSB_CLIENT_CODE ON CS_BILLING (CLIENT_CODE) TABLESPACE CS_BILLING LOCAL NOLOGGING PARALLEL (DEGREE 14) ONLINE COMPUTE STATISTICS;
If this operation exceeds particular time window....can i kill the process?...What worst will happen if i kill this process?Killing an ONLINE operation is a bit of a mess... You're already quite on the edge (parallel, online, possibly compute statistics) with this statement. The ONLINE operation creates an IOT table to record the changes to the underlying table during the build operation. All these things need to be cleaned up if the operation fails or the process dies/gets killed. This cleanup is supposed to be performed by the SMON process if I remember correctly. I remember that I once ran into trouble in 8i after such an operation failed, may be I got even an ORA-00600 when I tried to access the table afterwards.
It's not unlikely that your 8.1.7.2 makes your worries with this kind of statement, so be prepared.
How much time it may take? (Just to be on safer side)The time it takes to scan the whole table (if the information can't read from another index), the sorting operation, plus writing the segment, plus any wait time due to concurrent DML / locks, plus the time to process the table that holds the changes that were done to the table while building the index.
You can try to run an EXPLAIN PLAN on your create index statement which will give you a cost indication if you're using the cost based optimizer.
Please suggest me if any other way exists to perform in fastest way.Since you will need to sort 8 million rows, if you have sufficient memory you could bump up the SORT_AREA_SIZE for your session temporarily to sort as much as possible in RAM.
-- Use e.g. 100000000 to allow a 100M SORT_AREA_SIZE
ALTER SESSION SET SORT_AREA_SIZE = <something_large>;
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

Can I change some partitions of the partitioned table read-only?

I have a table partitioned by range( partitioned hourly).
I want to keep the history data online for query (the history data is rarely accessd). But in this way the table is too large. The performance may be a big problem. So some problems may be raised:
How can I change the aged partition read-only?
How to decrease the workload on this table and improve the performance?
Oracle 10g (10.2.0.3)+Solaris 10

How can I change the aged partition read-only?In 10.2.x.x I think only tablespaces can be made read only.
In 11g you can place tables in read only mode, but I don't know about specific partitions.

Merge Adjacent Range Partitions

I have found documentation about how the exchange partition command does not physically move any data, only updates the data dictionary which makes it almost instantaneous. Seems to me that merging adjacent range partitions might also have this behavior. Can anyone confirm this?
Thanks in advance for your reply

Hi! I've used the instructions before but can't remember the exact details. I think what it is talking about is the partition you are changing (ie the one being deleted) will be the one losing data and the space will be returned to the original volume from which it was created. I know this is the way it works using Diskstudio which I have used several times. But be sure you are confident with what you read and decide to do. Tom

Create range partition

hi ,
Oracle 10.2.0.1.0
I'm getting error while creating a range partition to already existing table (method employed : partition swap method ) .
PF screen shot of error
SQL> ed
Wrote file afiedt.buf
1 create table employee_details_temp partition by range (eid) (
2 partition eid_1r values less than (1000)
3 partition eid_2r values less than (20000)
4 partition eid_3r values less than (40000)
5 partition eid_3r values less than (maxvalue)
6* )
SQL> /
partition eid_2r values less than (20000)
ERROR at line 3:
ORA-14020: this physical attribute may not be specified for a table partitionalso ,
SQL> ed
Wrote file afiedt.buf
1 create table employee_details_temp partition by range (eid) (
2 partition eid_1r values less than (1000)
3 partition eid_2r values less than (20000)
4 partition eid_3r values less than (40000)
5 partition eid_3r values less than (maxvalue)
6 ) as select * from employee_details where 1=1;
7* /
SQL> /
partition eid_2r values less than (20000)
ERROR at line 3:
ORA-14020: this physical attribute may not be specified for a table partition please help .

answered .

Change header pricing condition in sales order

Hi,
I have an requirement in VA01 and VA02 to automatically edit one header pricing condition. The user can able to change the value of that condition type in header not in items . Does anyone know what user exit I can use for this requirement.
Thanks

Hi Sunil,
Plealse find below 2 methods to change header pricing conditions in sales order.
1.Goto SE38, give prog name as MV45AFZZ and in that write logic under USEREXIT_PRICING_PREPARE_TKOMK . (OR)
2) The same can be done by creating a Alt Calculation type routine through VOFM and writng the logic in the routine, which will then be assigned to the pricing procedure in the condition type which will automatically calculate the condition.
Try with the options mentioned above..
Regards,
KK

Change Range Partition Condition

Similar Messages

Maybe you are looking for