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

Similar Messages

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.

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

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.

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

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>

[Need help] Would Hash partitioning preferable here?

I have idea about Hash partitioning.
Now in my case volume of data is very high while search criteria on that table is dynamically coming from GUI.
There is search criteria for date range but date filed is dynamically decided.
In database terminology, different queries with different date type columns in where clause are executed based on the search criteria selected from GUI.
While using Range partition, we are allowed to use only one date column so query that do not use this date column would not get benefit from partitioning.
so i feel i can't go for range partitioning.
So here i need suggestion that would Hash partitioning would help in this case ?

The only reason i have put my query in this forum is
that here i found instant answers.So seeing that it is obvious that the only right way for such question is to divert them to the right forum and not provide any answer. Otherwise people start to become ignorant to polite requests.
And this forum is all about "feedback and suggestion"
again i am also asked for suggestions so i feel i am
right here.Are you blind or unable to read? Already 2 users asked you to post in more appropriate forum and when you open this forum there is following text just after the forum title:
"Use this forum for feedback about OTN programs, Web site content, and systems - product-related questions cannot be answered here. "
Is this not enough?
Gints Plivna
http://www.gplivna.eu

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

Importing Some Partion of a Partitioned Table

Hi Guru's,
I import a partitioned table using original import option, during import i am successful to import 80% of data but after that import discontinued due to n/w error. I just want to know can i continue my import from where it is discontinued or i need to import the complete partitioned table again. The export dump file is complete partitioned table export not partition wise export.
Any help will be greatly appreciated.
Thank in advance.

>
I import a partitioned table using original import option, during import i am successful to import 80% of data but after that import discontinued due to n/w error. I just want to know can i continue my import from where it is discontinued or i need to import the complete partitioned table again. The export dump file is complete partitioned table export not partition wise export.
>
Use the TABLES clause in the import statement.
See the Utilities doc
http://docs.oracle.com/cd/B28359_01/server.111/b28319/dp_import.htm
>
TABLES
Default: There is no default
Purpose
Specifies that you want to perform a table-mode import.
Syntax and Description
TABLES=[schema_name.]table_name[:partition_name]
In a table-mode import, you can filter the data that is imported from the source by specifying a comma-delimited list of tables and partitions or subpartitions.
If you do not supply a schema_name, it defaults to that of the current user. To specify a schema other than your own, you must either have the IMP_FULL_DATABASE role or remap the schema to the current user.
The use of filtering can restrict what is imported using this import mode. See Filtering During Import Operations.
If a partition_name is specified, it must be the name of a partition or subpartition in the associated table.
>
The doc has an example
>
The following example shows the use of the TABLES parameter to import partitions:
impdp hr DIRECTORY=dpump_dir1 DUMPFILE=expdat.dmp TABLES=sh.sales:sales_Q1_2000,sh.sales:sales_Q2_2000

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.

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

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

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

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

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

Help needed in EXPLAIN PLAN for a partitioned table

Oracle Version 9i
(Paste execution plan in a spreadsheet to make sense out of it)
I am trying to tune this query -
select * from comm c ,dates d
where
d.active_period = 'Y'
and c.period = d.period;
Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
SELECT STATEMENT Optimizer Mode=CHOOSE          5 M          278887
HASH JOIN          5 M     5G     278887
TABLE ACCESS FULL     SCHEMA.DATES     24      1 K     8
PARTITION LIST ALL                                   1     8
TABLE ACCESS FULL     SCHEMA.COMM     6 M     5G     277624                1     8
However, I know that the dates table will return only one record. So, if I add another condition to the above query, I get this execution plan. The comm table is huge but it is partitioned on period.
select * from comm c ,dates d
where
d.active_period = 'Y'
and c.period = qd.period
and c.period = 'OCT-07'
Operation     Object Name     Rows     Bytes     Cost     Object Node     In/Out     PStart     PStop
SELECT STATEMENT Optimizer Mode=CHOOSE          1           8
MERGE JOIN CARTESIAN          1      9 K     8
TABLE ACCESS FULL     SCHEMA.DATES     1      69      8
BUFFER SORT          1      9 K
TABLE ACCESS BY LOCAL INDEX ROWID     SCHEMA.COMM     1      9 K                    7     7
INDEX RANGE SCAN     SCHEMA.COMM_NP9     1                          7     7
How can I make the query such that the comm table does not have to traverse all of its partitions? The partitioning is based on quarters so it will get its data in one partition only (in the above example - partition no. 7)
Thanks in advance for writing in your replies :)

You need to specify period = 'OCT-07', otherwise there is no way the optimizer can know it needs to access only one partition.
Alternatively, partition the DATES table in exactly the same way on "period", and partition-wise joins should kick in, and effectively accessing only the active partition.

Need to uncompress a hash partitioned table

Similar Messages

Maybe you are looking for