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>

Similar Messages

Is list partition and hash partition one and the same

I am creating table with partition with the commands
CREATE TABLE ABD (ENO NUMBER(5),CID NUMBER(3),ENAME VARCHAR2(10))
PARTITION BY LIST (ENO)
(PARTITION P1 VALUES (123),
PARTITION P2 VALUES (143),
PARTITION CLIENT_ID VALUES (746))
ALTER TABLE ABD
ADD PARTITION CLIENT_756 VALUES (756)
but when i describe the table script it is showing like this
CREATE TABLE ABD (
ENO NUMBER (5),
ENAME VARCHAR2 (10),
CID NUMBER (3) )
PARTITION BY HASH (ENO)
PARTITIONS 4
STORE IN ( USERS,USERS,USERS,
USERS);
actually i am creating list partition but it is showing hash partition why is it so?

when i describe the table script it is showing like thisHow do you describe it, and which version are you on ?
TEST@db102 SQL> CREATE TABLE ABD (ENO NUMBER(5),CID NUMBER(3),ENAME VARCHAR2(10))
2 PARTITION BY LIST (ENO)
3 (PARTITION P1 VALUES (123),
4 PARTITION P2 VALUES (143),
5* PARTITION CLIENT_ID VALUES (746))
TEST@db102 SQL> /
Table created.
TEST@db102 SQL> ALTER TABLE ABD
2* ADD PARTITION CLIENT_756 VALUES (756)
TEST@db102 SQL> /
Table altered.
TEST@db102 SQL> select dbms_metadata.get_ddl('TABLE','ABD','TEST') from dual;
DBMS_METADATA.GET_DDL('TABLE','ABD','TEST')
CREATE TABLE "TEST"."ABD"
   (    "ENO" NUMBER(5,0),
        "CID" NUMBER(3,0),
        "ENAME" VARCHAR2(10)
   ) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
STORAGE(
BUFFER_POOL DEFAULT)
TABLESPACE "USERS"
PARTITION BY LIST ("ENO")
(PARTITION "P1" VALUES (123)
PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "USERS" NOCOMPRESS ,
PARTITION "P2" VALUES (143)
PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "USERS" NOCOMPRESS ,
PARTITION "CLIENT_ID" VALUES (746)
PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "USERS" NOCOMPRESS ,
PARTITION "CLIENT_756" VALUES (756)
PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "USERS" NOCOMPRESS )
TEST@db102 SQL>

A question on Hash Partition

Hi,
I'm facing a proble.My table has 16 partition and all the partitions are hash partitioned.
But i found only one partition is being populated heavily rather than the other ones it near to 3-4 times of other partitions.
My database version is 9i.
Can anyone suggest me in this.
Thanks in advance
say my table structure like this ..
CREATE TABLE TAB1(COL1 NUMBER,COL2 VARCHAR2(10),COL3 VARCHAR(10));
PARTITON BY HASH(COL3)
PARTITION P1 TABLESPACE TS1
PARTITION P16 TABLESPACE TS1
And i have only one index i.e
create index indx on tab1(col1,col2,col3);
Edited by: bp on Feb 17, 2009 4:40 AM

bp wrote:
My table has near 1000 million data as it is a history table.
Partition_key (col3) has distinct 926 values.
One thing is sure as the cardinality of col3 is very low in comparison with the amount of data in the table data is not evenly distributed.
Now another problem is one value (say col3 =1) of col3 from the 926 distinct values only goes to p16 partition but surprisingly this is not going to any other partitons.We have no other objects on this table to control the flow of data between partitions.
I really counld not find any reason of such behaviour.I'm not sure if I understand what you attempt to describe. You mean to say that in partition p16 there is only one value of COL3 found, and this partition holds more rows than the other partitions. Whereas the remaining partitions cover more COL3 values but hold less rows.
A single COL3 value always maps to the same hash value, so if you don't change the number of hash partitions and cause a "rebalancing" the same value should always map to the same partition (it still does after rebalancing but it might be a different partition now). You might be unlucky that there is currently no other value than "1" that maps to the same hash value. You could think about adding/removing hash partitions to change the distribution of the rows, but this could be a quite expensive operation given the amount of data in your table.
Are these 926 distinct values evenly distributed or is the data skewed in this column? Your description suggests that the data is skewed if a single value in a partition holds more rows than the other partitions that cover multiple values.
You could do a simple
SELECT COUNT(*), COL3
FROM TAB
GROUP BY COL3
ORDER BY COUNT(*) DESC
to find this out, or check the column statistics if there is an histogram on that column describing the column skew. If that query takes too long use a SAMPLE size (...FROM TAB SAMPLE (1)...) indicates a 1 percent sampling. You need to scale the counts then by the sampling factor.
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/

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

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 .

Update in table partition by hash

I have a table partitioned by hash. I want to make some updates (not on the partition key column and also not based on this column, i.e this column is not used in where clause).
Do I need to specify partition name in the query?
For a concrete example:
CREATE TABLE invoices
(invoice_id NUMBER NOT NULL,
customer_id NUMBER NOT NULL,
invoice_date DATE NOT NULL,
comments VARCHAR2(500))
PARTITION BY HASH (customer_id)
PARTITIONS 10
primary key is customer_id + invoice_date
I need to update invoice_id based on the rowid, like update invoices set invoice_id = MEMO_ID_1SQ.nextval where rowid = <variable>. I will be running this query from multiple processes and I want to make sure they are hitting different partitions, so they actually run in parallel.
Thanks in advance,
Radu

Radu,
You can use parallel hint on your update statement.
update /*+ PARALLEL(invoices, 4) */ invoices set invoice_id = MEMO_ID_1SQ.nextval where rowid = <variable>;See following execution plan for both with and without using parallel option
SQL> update interfacerecords set status=1 where interfaceid=5;
200000 rows updated.
Elapsed: 00:00:03.75
Execution Plan
Plan hash value: 3154550297
| Id | Operation          | Name             | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | UPDATE STATEMENT   |                  |   200K| 3125K|   128   (3)| 00:00:02 |
|   1 | UPDATE            | INTERFACERECORDS |       |       |            |          |
|* 2 |   TABLE ACCESS FULL| INTERFACERECORDS |   200K| 3125K|   128   (3)| 00:00:02 |
Predicate Information (identified by operation id):
   2 - filter("INTERFACEID"=5)
Statistics
        262 recursive calls
     458353 db block gets
       1539 consistent gets
        378 physical reads
   91750476 redo size
        655 bytes sent via SQL*Net to client
        585 bytes received via SQL*Net from client
          3 SQL*Net roundtrips to/from client
          1 sorts (memory)
          0 sorts (disk)
     200000 rows processed
SQL> commit;
Commit complete.
Elapsed: 00:00:00.00
SQL> set autotrace traceonly;
SQL> set timi on;
SQL> set lines 400;
SQL> update /*+ PARALLEL(interfacerecords, 4) */ interfacerecords set status=5 where status=1;
200000 rows updated.
Elapsed: 00:00:02.48
Execution Plan
Plan hash value: 2940696107
| Id | Operation             | Name             | Rows | Bytes | Cost (%CPU)| Time     |    TQ |IN-OUT| PQ Distrib |
|   0 | UPDATE STATEMENT      |                  |     1 |    13 |    35   (0)| 00:00:01 |        |   |       |
|   1 | UPDATE               | INTERFACERECORDS |       |       |            |          |        |   |       |
|   2 |   PX COORDINATOR      |                  |       |       |            |          |        |   |       |
|   3 |    PX SEND QC (RANDOM)| :TQ10000         |     1 |    13 |    35   (0)| 00:00:01 | Q1,00 | P->S | QC (RAND) |
|   4 |     PX BLOCK ITERATOR |                  |     1 |    13 |    35   (0)| 00:00:01 | Q1,00 | PCWC |            |
|* 5 |      TABLE ACCESS FULL| INTERFACERECORDS |     1 |    13 |    35   (0)| 00:00:01 | Q1,00 | PCWP |            |
Predicate Information (identified by operation id):
   5 - filter("STATUS"=1)
Statistics
        309 recursive calls
     214609 db block gets
      30287 consistent gets
          0 physical reads
   63356488 redo size
        654 bytes sent via SQL*Net to client
        617 bytes received via SQL*Net from client
          3 SQL*Net roundtrips to/from client
          3 sorts (memory)
          0 sorts (disk)
     200000 rows processedRegards

Dropping/Creating index for an individual partition on a partitioned table.

Hi,
I wanted to know how to create and drop index for a single individual partition on a partitioned table.
Thanks..

You are not allowed to create an index on a single partition. All the table, mean all the partitiones must be indexed. You can create local or global indexes on partitioned tables. Local indexes ,imho, are easier maintained. For more info refer to documentation http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_5010.htm#i2062403
Also, index partitions are maintained through corresponding table partitions. For example, if a table partition is truncated or is dropped, the corresponding index partition is also truncated or dropped (in case of locally partitioned indexes of course). In case of globally partitioned indexes, you will have to rebuild the index each time you truncate or drop a table partition.

Dropping tablespace for a partitionned table

Hi all,
I have a table partitionned and I want to drop the tablespace for a specific partition. So what happen in the table if I drop one tablespace with a commande drop tablespace tbs including contents and datafiles;
Does the index unusable in this table?
Regards

No, you can not drop a tablespace which contains tables whose partitions are not completely contained in this tablespace.
db9i :SQL> create tablespace users2 datafile '/u02/oradata/db9i/users201.dbf' size 10M;
Tablespace created.
db9i :SQL> CREATE TABLE sales_by_region (item# INTEGER, qty INTEGER,
2 store_name VARCHAR(30), state_code VARCHAR(2),
3 sale_date DATE)
4 STORAGE(INITIAL 10K NEXT 20K) TABLESPACE test
5 PARTITION BY LIST (state_code)
6 (
7 PARTITION region_east
8 VALUES ('MA','NY','CT','NH','ME','MD','VA','PA','NJ')
9 STORAGE (INITIAL 20K NEXT 40K PCTINCREASE 50)
TABLESPACE users,
10   11 PARTITION region_west
12 VALUES ('CA','AZ','NM','OR','WA','UT','NV','CO')
13 PCTFREE 25
14 TABLESPACE users2,
15 PARTITION region_unknown
16 VALUES (DEFAULT)
17 TABLESPACE test
18 );
Table created.
db9i :SQL> insert into sales_by_region values (1, 100, 'store 1','NY',sysdate);
1 row created.
db9i :SQL> insert into sales_by_region values (2, 200, 'store 2','UT',sysdate);
1 row created.
db9i :SQL> insert into sales_by_region values (3, 300, 'store 3','ZZ',sysdate);
1 row created.
db9i :SQL> commit;
Commit complete.
db9i :SQL> select count(*) from sales_by_region
2 /
COUNT(*)
         3
--insure all data went to the right partition
db9i :SQL> alter table sales_by_region truncate PARTITION region_east;
Table truncated.
db9i :SQL> select count(*) from sales_by_region
2 /
COUNT(*)
         2
db9i :SQL> alter table sales_by_region truncate PARTITION region_west;
Table truncated.
db9i :SQL> select count(*) from sales_by_region
2 /
COUNT(*)
         1
db9i :SQL> alter table sales_by_region truncate PARTITION region_unknown;
Table truncated.
db9i :SQL> select count(*) from sales_by_region
2 /
COUNT(*)
         0
db9i :SQL> insert into sales_by_region values (1, 100, 'store 1','NY',sysdate);
insert into sales_by_region values (2, 200, 'store 2','UT',sysdate);
insert into sales_by_region values (3, 300, 'store 3','ZZ',sysdate);
1 row created.
db9i :SQL>
1 row created.
db9i :SQL>
1 row created.
db9i :SQL>
db9i :SQL>
db9i :SQL> commit;
Commit complete.
db9i :SQL> select count(*) from sales_by_region
2 /
COUNT(*)
         3
--now drop one tablespace
db9i :SQL> drop tablespace users2 including contents and datafiles
2 /
drop tablespace users2 including contents and datafiles
ERROR at line 1:
ORA-14404: partitioned table contains partitions in a different tablespace
db9i :SQL> !oerr ora 14404
14404, 00000, "partitioned table contains partitions in a different tablespace"
// *Cause: An attempt was made to drop a tablespace which contains tables
//         whose partitions are not completely contained in this tablespace
// *Action: find tables with partitions which span the tablespace being
//          dropped and some other tablespace(s). Drop these tables or move
//          partitions to a different tablespace
--move table partition from users2 to users
db9i :SQL> alter table sales_by_region move partition region_west
tablespace users; 2
Table altered.
--drop tablespace again
db9i :SQL> drop tablespace users2 including contents and datafiles
2 /
Tablespace dropped.

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.

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 column from compressed partitioned table

Hi,
DB version is 11.2.02.
We have table which is range partitioned and sub-partitioned by list.
Table is also compressed.
When I try to drop a column, I get error.
CREATE TABLE DWH_REP.P_RATING (
id_source$                 NUMBER(38,0) NULL,
time_insert$               DATE          ,
time_update$               DATE          ,
FLG_CURRENT$               NUMBER(38,0) ,
FLG_CHANGED$               NUMBER(38,0) ,
id_audit$                  NUMBER(38,0) ,
ID_DATE_PSTING             NUMBER(38,0) ,
partner_rating_id          VARCHAR2(256) ,
partner_id                 VARCHAR2(256) ,
id_partner                 NUMBER(38,0) ,
rating_system_id           VARCHAR2(256) ,
rating_id                  VARCHAR2(256) ,
date_rating                DATE          ,
date_follow_up             DATE          ,
risk_team_id               VARCHAR2(256) ,
risk_team_descr            VARCHAR2(256) ,
risk_team_changed_id       VARCHAR2(256) ,
risk_team_changed_descr    VARCHAR2(256) ,
date_risk_team_changed     DATE          ,
assignment_id              VARCHAR2(256) ,
date_assignment            DATE          ,
date_assignment_confirmed DATE          ,
date_assignment_expiration DATE          ,
flg_exception              VARCHAR2(256) ,
exception_id               VARCHAR2(256) ,
date_exception             DATE
-- TABLESPACE DWH_REP_DATA
PARTITION BY RANGE (FLG_CURRENT$, ID_DATE_PSTING)
   SUBPARTITION BY LIST (ID_SOURCE$)
   (PARTITION P_RATING_2010
       VALUES LESS THAN (0, 20110101)
       SUBPARTITION P_RATING_2010_UCS VALUES (10) TABLESPACE DWH_O_2010_TBS,
       SUBPARTITION P_RATING_2010_UCM VALUES (11) TABLESPACE DWH_O_2010_TBS,
--     SUBPARTITION P_RATING_2010_ORBI30 VALUES (30) TABLESPACE DWH_O_2010_TBS,
--     SUBPARTITION P_RATING_2010_ORBI31 VALUES (31) TABLESPACE DWH_O_2010_TBS,
       SUBPARTITION P_RATING_2010_CETELEM VALUES (40) TABLESPACE DWH_O_2010_TBS,
--     SUBPARTITION P_RATING_2010_MILES VALUES (60) TABLESPACE DWH_O_2010_TBS,
--     SUBPARTITION P_RATING_2010_BHI VALUES (80) TABLESPACE DWH_O_2010_TBS,
       SUBPARTITION P_RATING_2010_DF VALUES (DEFAULT) TABLESPACE DWH_O_2010_TBS),
     PARTITION P_RATING_2011
       VALUES LESS THAN (0, 20120101)
       SUBPARTITION P_RATING_2011_UCS VALUES (10) TABLESPACE DWH_O_2011_TBS,
       SUBPARTITION P_RATING_2011_UCM VALUES (11) TABLESPACE DWH_O_2011_TBS,
--     SUBPARTITION P_RATING_2011_ORBI30 VALUES (30) TABLESPACE DWH_O_2011_TBS,
--     SUBPARTITION P_RATING_2011_ORBI31 VALUES (31) TABLESPACE DWH_O_2011_TBS,
       SUBPARTITION P_RATING_2011_CETELEM VALUES (40) TABLESPACE DWH_O_2011_TBS,
--     SUBPARTITION P_RATING_2011_MILES VALUES (60) TABLESPACE DWH_O_2011_TBS,
--     SUBPARTITION P_RATING_2011_BHI VALUES (80) TABLESPACE DWH_O_2011_TBS,
       SUBPARTITION P_RATING_2011_DF VALUES (DEFAULT) TABLESPACE DWH_O_2011_TBS),
    PARTITION P_RATING_current
       VALUES LESS THAN (maxvalue, maxvalue)
       SUBPARTITION P_RATING_CUR_UCS VALUES (10) TABLESPACE DWH_O_CRT_UCS_TBS,
       SUBPARTITION P_RATING_CUR_UCM VALUES (11) TABLESPACE DWH_O_CRT_UPM_TBS,
--     SUBPARTITION P_RATING_CUR_ORBI30 VALUES (30) TABLESPACE DWH_O_CRT_ORBI30_TBS,
--     SUBPARTITION P_RATING_CUR_ORBI31 VALUES (31) TABLESPACE DWH_O_CRT_ORBI31_TBS,
       SUBPARTITION P_RATING_CUR_CETELEM VALUES (40) TABLESPACE DWH_O_CRT_CETELEM_TBS,
--     SUBPARTITION P_RATING_CUR_MILES VALUES (60) TABLESPACE DWH_O_CRT_MILES_TBS,
--     SUBPARTITION P_RATING_CUR_BHI VALUES (80) TABLESPACE DWH_O_CRT_BHI_TBS,
       SUBPARTITION P_RATING_CUR_DF VALUES (DEFAULT) TABLESPACE DWH_O_CRT_DF_TBS))
ENABLE ROW MOVEMENT
NOLOGGING
COMPRESS
NOCACHE
NOPARALLEL
MONITORING;
ALTER TABLE DWH_REP.P_RATING DROP COLUMN ID_PARTNER;
ORA-39726: unsupported add/drop column operation on compressed tables

littleboy wrote:
Hi,
DB version is 11.2.02.
We have table which is range partitioned and sub-partitioned by list.
Table is also compressed.
When I try to drop a column, I get error.
CREATE TABLE DWH_REP.P_RATING (
id_source$                 NUMBER(38,0) NULL,
time_insert$               DATE          ,
time_update$               DATE          ,
FLG_CURRENT$               NUMBER(38,0) ,
FLG_CHANGED$               NUMBER(38,0) ,
id_audit$                  NUMBER(38,0) ,
ID_DATE_PSTING             NUMBER(38,0) ,
partner_rating_id          VARCHAR2(256) ,
partner_id                 VARCHAR2(256) ,
id_partner                 NUMBER(38,0) ,
rating_system_id           VARCHAR2(256) ,
rating_id                  VARCHAR2(256) ,
date_rating                DATE          ,
date_follow_up             DATE          ,
risk_team_id               VARCHAR2(256) ,
risk_team_descr            VARCHAR2(256) ,
risk_team_changed_id       VARCHAR2(256) ,
risk_team_changed_descr    VARCHAR2(256) ,
date_risk_team_changed     DATE          ,
assignment_id              VARCHAR2(256) ,
date_assignment            DATE          ,
date_assignment_confirmed DATE          ,
date_assignment_expiration DATE          ,
flg_exception              VARCHAR2(256) ,
exception_id               VARCHAR2(256) ,
date_exception             DATE
-- TABLESPACE DWH_REP_DATA
PARTITION BY RANGE (FLG_CURRENT$, ID_DATE_PSTING)
SUBPARTITION BY LIST (ID_SOURCE$)
(PARTITION P_RATING_2010
VALUES LESS THAN (0, 20110101)
SUBPARTITION P_RATING_2010_UCS VALUES (10) TABLESPACE DWH_O_2010_TBS,
SUBPARTITION P_RATING_2010_UCM VALUES (11) TABLESPACE DWH_O_2010_TBS,
--     SUBPARTITION P_RATING_2010_ORBI30 VALUES (30) TABLESPACE DWH_O_2010_TBS,
--     SUBPARTITION P_RATING_2010_ORBI31 VALUES (31) TABLESPACE DWH_O_2010_TBS,
SUBPARTITION P_RATING_2010_CETELEM VALUES (40) TABLESPACE DWH_O_2010_TBS,
--     SUBPARTITION P_RATING_2010_MILES VALUES (60) TABLESPACE DWH_O_2010_TBS,
--     SUBPARTITION P_RATING_2010_BHI VALUES (80) TABLESPACE DWH_O_2010_TBS,
SUBPARTITION P_RATING_2010_DF VALUES (DEFAULT) TABLESPACE DWH_O_2010_TBS),
PARTITION P_RATING_2011
VALUES LESS THAN (0, 20120101)
SUBPARTITION P_RATING_2011_UCS VALUES (10) TABLESPACE DWH_O_2011_TBS,
SUBPARTITION P_RATING_2011_UCM VALUES (11) TABLESPACE DWH_O_2011_TBS,
--     SUBPARTITION P_RATING_2011_ORBI30 VALUES (30) TABLESPACE DWH_O_2011_TBS,
--     SUBPARTITION P_RATING_2011_ORBI31 VALUES (31) TABLESPACE DWH_O_2011_TBS,
SUBPARTITION P_RATING_2011_CETELEM VALUES (40) TABLESPACE DWH_O_2011_TBS,
--     SUBPARTITION P_RATING_2011_MILES VALUES (60) TABLESPACE DWH_O_2011_TBS,
--     SUBPARTITION P_RATING_2011_BHI VALUES (80) TABLESPACE DWH_O_2011_TBS,
SUBPARTITION P_RATING_2011_DF VALUES (DEFAULT) TABLESPACE DWH_O_2011_TBS),
PARTITION P_RATING_current
VALUES LESS THAN (maxvalue, maxvalue)
SUBPARTITION P_RATING_CUR_UCS VALUES (10) TABLESPACE DWH_O_CRT_UCS_TBS,
SUBPARTITION P_RATING_CUR_UCM VALUES (11) TABLESPACE DWH_O_CRT_UPM_TBS,
--     SUBPARTITION P_RATING_CUR_ORBI30 VALUES (30) TABLESPACE DWH_O_CRT_ORBI30_TBS,
--     SUBPARTITION P_RATING_CUR_ORBI31 VALUES (31) TABLESPACE DWH_O_CRT_ORBI31_TBS,
SUBPARTITION P_RATING_CUR_CETELEM VALUES (40) TABLESPACE DWH_O_CRT_CETELEM_TBS,
--     SUBPARTITION P_RATING_CUR_MILES VALUES (60) TABLESPACE DWH_O_CRT_MILES_TBS,
--     SUBPARTITION P_RATING_CUR_BHI VALUES (80) TABLESPACE DWH_O_CRT_BHI_TBS,
SUBPARTITION P_RATING_CUR_DF VALUES (DEFAULT) TABLESPACE DWH_O_CRT_DF_TBS))
ENABLE ROW MOVEMENT
NOLOGGING
COMPRESS
NOCACHE
NOPARALLEL
MONITORING;
ALTER TABLE DWH_REP.P_RATING DROP COLUMN ID_PARTNER;
ORA-39726: unsupported add/drop column operation on compressed tables
can you checkwith following?
SQL>alter table t set unused column x;
SQL>alter table t drop unused columns;Tom explains it ->http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:69076630635645

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

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

HASH PARTITION TO LIST PARTITION

version : Oracle 10g
hi All,
      i have a table partitioned by hash(8 segments) with 200 millions records . now we want to move to list partition the same table by state.
      Is there a way to drop hash Partitions with out losing the data, and Add list partition.


No, you can't "convert" the Hash Partitions to List Partitions.
You have to create a new, empty, table that is List Partitioned and then move the data over to the new table.
You could use Direct Path Insert (i.e. INSERT with APPEND Hint) with PARALLEL degree and NOLOGGING on the target table to speed up the copy.
You could also use DBMS_REDEFINITION to migrate the data.
In either case, you also have to create the Indexes on the new table.
Hemant K Chitale

How data is distributed in HASH partitions

Guys,
I want to partitions my one big table into 5 different partitions based on HASH value of the LOCATION field of the table.
My question is, Will the data be distributed equally in partitions or will end up in one partition or I need to have 5 diferent HASH value for location key to end up in five partitions.

Hash partitioning enables easy partitioning of data that does not lend itself to range or list partitioning. It does this with a simple syntax and is easy to implement. It is a better choice than range partitioning when:
1) You do not know beforehand how much data maps into a given range
2) The sizes of range partitions would differ quite substantially or would be difficult to balance manually
3) Range partitioning would cause the data to be undesirably clustered
4) Performance features such as parallel DML, partition pruning, and partition-wise joins are important
The concepts of splitting, dropping or merging partitions do not apply to hash partitions. Instead, hash partitions can be added and coalesced.
What I think that is, in your case list partitioning can be of choice.
http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14220/partconc.htm#i462869

Drop partitions in HASH partitioned table

Similar Messages

Maybe you are looking for