Altering Hash Partition table

Hi ,
version: 10gR2
I have a table that built with 5 hash partitions.
Since oracle recommand that hash partition table should built with power of two
(e.g: 2,4,8,16...) partition , i would like to rebuilt the table with 8 hash partition.
Its a table that contain more then 100 milion records and its size is more then 2 giga.
I understand that there isnt any: alter table .. for this kind of issue.
Please advice me what is the best way to do this task.
Thanks.

use
ALTER TABLE <table> SPLIT PARTITION <partition> AT
(<value>) INTO ( PARTITION <partition1> TABLESPACE <tbs> , PARTITION <partition2> TABLESPACE <tbs>);to divide your partitions
bye
aldo

Similar Messages

Need to uncompress a hash partitioned table

I am working on oracle 11.1.0.7 database on solaris.
We had issues loading data into compressed tables, so we are trying to uncompress the tables and their partitions.
When I tried uncompressing a hash partitioned table, I am getting this error
SQL> alter table sample move partition SYS_1 nocompress;
alter table sample move partition SYS_1 nocompress
ERROR at line 1:
ORA-14260: incorrect physical attribute specified for this partition
I am able to move the table, it is just the nocompress option which doesn;t work.
SQL> alter table sample move partition SYS_1;
Table altered.
Can't we uncompress a hash partitioned table which is compressed?

You have to do it in two steps
alter table sample modify partition SYS_1 nocompress;
alter table sample move partition SYS_1;Best regards
Maxim

Can we compress hash partitioned table in 9.2

Hi
Can we compress the hash partitioned table? How to check the compression? Is there any way to check for the partition size after compression?
Thanks

hi
go through below link
hope it will help you.
http://www.dbazine.com/oracle/or-articles/foot6
http://www.google.ae/search?hl=en&q=compressed+hash+partition+++oracle+9i&meta=
also check in google seconed point... Table compression do and don't.
hope this helps
Taj.

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

Design capture of hash partitioned tables

Hi,
Designer version 9.0.2.94.11
I am trying to capture from a server model where the tables are hash partitioned. But this errors because Designer only knows about range partitions. Does anyone know how I can get Designer to capture these tables and their constraints?
Thanks
Pete

Pete,
I have tried all three "current" Designer clients 6i, 9i, and 10g, at the "current" revision of the repository (I can post details if interested). I have trawled the net for instances of this too, there are many.
As stated by Sue, the Designer product model does not support this functionality (details can be found on ORACLE Metalink under [Bug No. 1484454] if you have access), if not, see excerpt below. It appears that at the moment ORACLE have no urgent plans to change this (the excerpt is dated as raised in 2001 and last updated in May 2004).
Composite partitioning and List partitioning are equally affected.
>>>>> ORACLE excerpt details STARTS >>>>>
CDS-18014 Error: Table Partition 'P1' has a null String parameter
'valueLessThan' in file ..\cddo\cddotp.cpp function
cddotp_table_partition::cddotp_table_partition and line 122
*** 03/02/01 01:16 am ***
*** 06/19/01 03:49 am *** (CHG: Pri->2)
*** 06/19/01 03:49 am ***
Publishing bug, and upping priority - user is stuck hitting this issue.
*** 09/27/01 04:23 pm *** (CHG: FixBy->9.0.2?)
*** 10/03/01 08:30 am *** (CHG: FixBy->9.1)
*** 10/03/01 08:30 am ***
This should be considered seriously when looking at ERs we should be able to
do this
*** 05/01/02 04:37 pm ***
*** 05/02/02 11:44 am ***
I have reproduced this problem in 6.5.82.2.
*** 05/02/02 11:45 am *** ESCALATION -> WAITING
*** 05/20/02 07:38 am ***
*** 05/20/02 07:38 am *** ESCALATED
*** 05/28/02 11:24 pm *** (CHG: FixBy->9.0.3)
*** 05/30/02 06:23 am ***
Hash partitioning is not modelled in repository and to do so would require a
major model change. This is not feasible at the moment but I am leaving this
open as an enhancement request because it is a much requested facility.
Although we can't implement this I think we should try to detect 'partition by
hash', output a warning message that it is not supported and then ignore it.
At least then capture can continue. If this is possible, it should be tested
and the status re-set to '15'
*** 05/30/02 06:23 am *** (CHG: FixBy->9.1)
*** 06/06/02 02:16 am *** (CHG: Sta->15)
*** 06/06/02 02:16 am RESPONSE ***
It was not possible to ignore the HASH and continue processing without a
considerable amount of work so we have not made any changes. The existing
ERROR message highlights that the problem is with the partition. To enable
the capture to continue the HASH clause must be removed from the file.
*** 06/10/02 08:32 am *** ESCALATION -> CLOSED
*** 06/10/02 09:34 am RESPONSE ***
*** 06/12/02 06:17 pm RESPONSE ***
*** 08/14/02 06:07 am *** (CHG: FixBy->10)
*** 01/16/03 10:05 am *** (CHG: Asg->NEW OWNER)
*** 02/13/03 06:02 am RESPONSE ***
*** 05/04/04 05:58 am RESPONSE ***
*** 05/04/04 07:15 am *** (CHG: Sta->97)
*** 05/04/04 07:15 am RESPONSE ***
<<<<< ORACLE excerpt details ENDS <<<<<
I (like I'm sure many of us) have an urgent immediate need for this sort of functionality, and have therefore resolved to looking at some form of post process to produce the required output.
I imagine that it will be necessary to flag the Designer meta-data content and then manipulate the generator output once it's done its "raw" generation as a RANGE partition stuff (probably by using the VALUE_LESS_THAN field as its mandatory, and meaningless for HASH partitions!).
An alternative would be to write an API level generator for this using the same flag, probably using PL/SQL.
If you have (or anyone else has) any ideas on this, then I'd be happy to share them to see what we can cobble together in the absence of an ORACLE interface to their own product.
Peter

Alter range partition table to Interval partitioning table.

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

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

Drop partitions in HASH partitioned table

SELECT * FROM product_component_version
NLSRTL      10.2.0.4.0     Production
Oracle Database 10g Enterprise Edition      10.2.0.4.0     64bi
PL/SQL      10.2.0.4.0     Production
TNS for Solaris:      10.2.0.4.0     ProductionI have a table which is partitioned by HASH into several partitions. I would like to remove them all the same way I can DROP partitions in a LIST or RANGE partitioned tables.
I COALESCE-d my table until it remained with only one partition. Now I've got a table with one HASH partition and I would like to remove it and to end up with unpartitioned table.
How could it be accomplished?
Thank you!

Verdi wrote:
I have a table which is partitioned by HASH into several partitions. I would like to remove them all the same way I can DROP partitions in a LIST or RANGE partitioned tables.
I COALESCE-d my table until it remained with only one partition. Now I've got a table with one HASH partition and I would like to remove it and to end up with unpartitioned table.
How could it be accomplished?
You cannot turn a partitioned table into a non-partitioned table, but you could create a replacement table (including indexes etc.) and then use the 'exchange partition' option on the partitioned table. This will modify the data dictionary so the data segments for the partition exchange names with the data segments for the new table - which gives you a simple table, holding the data, in minimum time and with (virtually) no undo and redo.
The drawback to this method is that you have to sort out all the dependencies and privileges.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Author: <b><em>Oracle Core</em></b>

Ask hash algortihm in partitioning table by hash

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

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

IOT or Hash partition

Hi all,
I want to insert large data into a table to be retreived later using a key column (like emp no).
To the performance point of view, which is more efficient: IOT (Index Organized Table) or Hash Partition ?

I highly appreciate your time Justin. Your explanation clarified many things to me.
However, I have small notes on your comments:
Firt:
<<IOT's tend to be useful when you have thin, tall tables (many rows, few columns) where you always want to retrieve all the rows.>>
Regarding this claim, I referred to the following sources:
1. Sybex-Oracle9i Performance Tuning book
"If you access the table using its primary key, an IOT will return the rows more quickly than a traditional table."
2. http://www.tlingua.com/articles/iot.html
For single row fetch,"IOTs could provide a substantial performance gain as well as reducing the demand for disk drives"
For Index Range Scans,"IOTs significantly outperform the standard B-tree/table model during index range scans."
3. Oracle9i Database Administratorâs Guide Release 2 (9.2)
"Index-organized tables are particularly useful when you are using applications that must retrieve data based on a primary key."
As you can see Justin, none of them mentioned the thin-tall-table fact. Did you obtain it from practical experience or from some source?
Also they all showed that IOT is most useful when retreiving based on PK.
Second:
"In general, partitioning works best when you are doing set-based processing where you can use partition elimination to concentrate on a particular subset of the data."
In Sybex-Oracle9i Performance Tuning book it is stated that "Hash partitions work best when applications retrieve the data from the partitioned table via the unique key. Range lookups on hash partitioned tables derive no benefit from the partitioning.".
I can see there is some confilict, isn't it?
Thanks in advance.

Need help on List-Hash partition - oracle 11 feature !

Can a list-hash partitioned tabled be exchanged for a partition?
Say, the table is partitioned by list on CODE (varchar2) column and subpartitioned by a NUMBER column
i.e. create table TAB1 (ID, Code, Number)
partition by LIST (Code)
subpartition by HASH (Number)
subpartition template
( subpartition1 , subpartition2 , subpartition3)
partition part1 values ('A'),
partition part1 values ('B'),
partition part1 values ('C')
Lets say the subpartitions1,2 and 3 have values 1,2,3,4,5,6....10, how can I move only say value 1 and 2 into another table using exchange partition method? Is this possible?

>
Thanks for the reply. The db version details is as below. And I am more interested in knowing if and how can data be extracted from hash sub-partitions for a given sub-partition key value, using partition exchange. Can anyone demonstrate this or point to any article that demonstrates this? I am not even sure if something like is possible.
>
What part of my reply didn't you undertand?
Except now you are saying 'extract' where before you wanted to exchange the hash subpartition. If you exchange then the subpartition will now have NO data since it will have been exchanged with an empty table.
In a partition exchange ALL of the partition (or subpartition) is exchanged, not just part of it. So for a hash subpartition you either exchange ALL data or none of it. If you only want some of the data in the subpartition you have to query it out.
No one can provide any samples until you provide a valid sample yourself. You said your partitions have character data
partition part1 values ('A'),
partition part1 values ('B'),
partition part1 values ('C')
);But then you ask about manipulating numeric data
>
Lets say the subpartitions1,2 and 3 have values 1,2,3,4,5,6....10, how
>
Which is it?
Post the DDL for the table and show which subpartition you want to query or exchange.

Doubt in Hash Partition

Hi friends,
I have a hash partition table with 3 parts.
My doubt is Can i use a query to see how many records are present in each parts?

SQL> CREATE TABLE my_table
a INTEGER
PARTITION BY HASH (a)
PARTITION part_1,
PARTITION part_2,
PARTITION part_3
Table created.
SQL> INSERT INTO my_table
   SELECT object_id
     FROM all_objects
43055 rows created.
SQL> SELECT COUNT (*)
FROM my_table PARTITION (part_1)
COUNT(*)
     10734
1 row selected.
SQL> SELECT COUNT (*)
FROM my_table PARTITION (part_2)
COUNT(*)
     21495
1 row selected.
SQL> SELECT COUNT (*)
FROM my_table PARTITION (part_3)
COUNT(*)
     10826

Convert Normal Table to Partition Table

Hi All,
I have a Normal Table with Millions of records and I want to convert that Normal table to Hash Partition Table.
Please let me know how to do that.
Thanks in Advance
Elan

Didn't see the exchange partition example, yes its the best practice I also agree.
If your table's data is huge better to do it with CTAS(create table as select) since this ddl can be parallel and nologging.
After creating the new partitioned table you may rename old one with its all dependencies; indexes, triggers, constraints, grants etc. So it would better to get the ddl of the heap table first with dbms_metadata.
Best regards.
Message was edited by:
TongucY

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 .

Create Partition table using CTAS

Hi there,
Is it possible to create a duplicate partition table from a existing partition table using CTAS method? If yes, could you explain how ?If No , how to make a duplicate partition table?
Thanks in advance?
Rajesh Marath

Easily:
conn / as sysdba
CREATE TABLESPACE part1
DATAFILE 'c:\temp\part01.dbf' SIZE 50M
BLOCKSIZE 8192
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K
SEGMENT SPACE MANAGEMENT AUTO
ONLINE;
CREATE TABLESPACE part2
DATAFILE 'c:\temp\part02.dbf' SIZE 50M
BLOCKSIZE 8192
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K
SEGMENT SPACE MANAGEMENT AUTO
ONLINE;
CREATE TABLESPACE part3
DATAFILE 'c:\temp\part03.dbf' SIZE 50M
BLOCKSIZE 8192
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K
SEGMENT SPACE MANAGEMENT AUTO
ONLINE;
ALTER USER uwclass QUOTA UNLIMITED ON part1;
ALTER USER uwclass QUOTA UNLIMITED ON part2;
ALTER USER uwclass QUOTA UNLIMITED ON part3;
conn uwclass/uwclass
CREATE TABLE hash_part (
prof_history_id NUMBER(10),
person_id NUMBER(10) NOT NULL,
organization_id NUMBER(10) NOT NULL,
record_date DATE NOT NULL,
prof_hist_comments VARCHAR2(2000))
PARTITION BY HASH (prof_history_id)
PARTITIONS 3
STORE IN (part1, part2, part3);
CREATE TABLE duplicate_hash_part
PARTITION BY HASH (prof_history_id)
PARTITIONS 3
STORE IN (part1, part2, part3) AS
SELECT * FROM hash_part;Follow the same logic for list and range partitions

Unique key on range-partitioned table

Hi,
We are using a composite range-hash interval partitioned table
Uses index - trying to make this have same tablespace as the partitions i.e. local but not liking it
alter table RETAILER_TRANSACTION_COMP_POR
add constraint RETAILER_TRANSACTION_COMP_PK primary key (DWH_NUM)
using index
LOCAL
ora-14039: partitioning columns must form a subset of key columns of a unique index
Without local then fine but doesn't have same tablespace as the partitions and don't want to make this part of partition key.
Tbale range partitioned - this is just a UK to prevent duplicates

[oracle@localhost ~]$ oerr ora 14039
14039, 00000, "partitioning columns must form a subset of key columns of a UNIQUE index"
// *Cause: User attempted to create a UNIQUE partitioned index whose
//          partitioning columns do not form a subset of its key columns
//          which is illegal
// *Action: If the user, indeed, desired to create an index whose
//          partitioning columns do not form a subset of its key columns,
//          it must be created as non-UNIQUE; otherwise, correct the
//          list of key and/or partitioning columns to ensure that the index'
//          partitioning columns form a subset of its key columns

Altering Hash Partition table

Similar Messages

Maybe you are looking for