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

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.

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

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

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 .

Batch Design Capture of tables that include Object Types

When I attempt to use the Batch Design Capture facility to capture a table that includes an Object Type the facility dies without completing.
I am using Designer 9i / Oracle Design Editor v9.0.2.80.4.
The Batch Design Capture facility reports the following and then exits:
Repository connected successfully
Server Generator 9.0.2.80.4, Wed Jun 09 17:24:33 2004
Copyright (c) Oracle Corporation 1995, 2002. All rights reserved.
CDS-15334 Warning: The Oracle Object Type MESSAGEHEADER_TYPE already exists in the Repository. NOMERGE_AND_SAC Rule selected
=> the captured property values will not replace the existing property values in the repository but the Rules for the Secondary Elements (SACs) will apply for their own update
CDS-11305 Warning: Column 'E2B.MESSAGEHEADER' property DEFAULT VALUE exceeds maximum length (60) - Truncated
The table that I am trying to capture looks like this:
E2B
E2B_ID NOT NULL NUMBER
MESSAGEHEADER MESSAGEHEADER_TYPE
DATE_TRANSMITTED DATE
DATE_RECEIVED DATE
DATE_ACKNOWLEDGED DATE
... other columns ...
MESSAGE CLOB
and MESSAGEHEADER_TYPE looks like this:
MESSAGEHEADER_TYPE
MESSAGETYPE VARCHAR2(16)
MESSAGEFORMATVERSION VARCHAR2(3)
MESSAGEFORMATRELEASE VARCHAR2(3)
MESSAGENUMB VARCHAR2(100)
MESSAGESENDERIDENTIFIER VARCHAR2(60)
MESSAGERECEIVERIDENTIFIER VARCHAR2(60)
MESSAGEDATEFORMAT NUMBER(3)
MESSAGEDATE NUMBER(14)
Is is possible to use Designer to capture tables that include object types?

hi,
while running the package, use the activity "Maintain Table Reduction" in phase System Analysis to include / exclude / reduce the table from transfer.
Srila.

How to delete the data from partition table

Hi all,
Am very new to partition concepts in oracle..
here my question is how to delete the data from partition table.
is the below query will work ?
delete from table1 partition (P_2008_1212)
we have define range partition ...
or help me how to delete the data from partition table.
Thanks
Sree

874823 wrote:
delete from table1 partition (P_2008_1212)This approach is wrong - as Andre pointed, this is not how partition tables should be used.
Oracle supports different structures for data and indexes. A table can be a hash table or index organised table. It can have B+tree index. It can have bitmap indexes. It can be partitioned. Etc.
How the table implements its structure is a physical design consideration.
Application code should only deal with the logical data structure. How that data structure is physically implemented has no bearing on application. Does your application need to know what the indexes are and the names of the indexes,in order to use a table? Obviously not. So why then does your application need to know that the table is partitioned?
When your application code starts referring directly to physical partitions, it needs to know HOW the table is partitioned. It needs to know WHAT partitions to use. It needs to know the names of the partitions. Etc.
And why? All this means is increased complexity in application code as this code now needs to know and understand the physical data structure. This app code is now more complex, has more moving parts, will have more bugs, and will be more complex to maintain.
Oracle can take an app SQL and it can determine (based on the predicates of the SQL), which partitions to use and not use for executing that SQL. All done totally transparently. The app does not need to know that the table is even partitioned.
This is a crucial concept to understand and get right.

Query with non partition key in partitioning table

i compare query select with non-partition key condition in table partition with 3, 4 and 6 partition.
time execution for 3 partition faster then 4 partition, time execution for 4 partition faster than 6 partition.
i know processing query select is selection all partition, but i don't know what make time execution different between 3, 4 and 6 partition??
whether the transfer from one partition to another partition takes time?
this example sql trace query select for 3,4 and 6 partition
3 partition
SELECT *
FROM
EQU_PARAM_MONITORINGHASH WHERE TO_CHAR(time_stamp,'mm/yy')=('02/09')
call          cpu    elapsed       disk        rows
Parse        0.00       0.00          0           0
Execute      0.00       0.00          0           0
Fetch        5.70       7.57      25291     1157583
total        5.70       7.57      25291     1157583
Parsing user id: 61 (SKENARIO1)
Rows     Execution Plan
      0 SELECT STATEMENT   MODE: ALL_ROWS
      0   PARTITION HASH (ALL) PARTITION: START=1 STOP=3
      0    TABLE ACCESS   MODE: ANALYZED (FULL) OF
               'EQU_PARAM_MONITORINGHASH' (TABLE) PARTITION: START=1 STOP=34 partition
SELECT *
FROM
EQU_PARAM_MONITORINGHASH WHERE TO_CHAR(time_stamp,'mm/yy')=('02/09')
call          cpu    elapsed       disk        rows
Parse        0.00       0.00          0           0
Execute      0.00       0.00          0           0
Fetch        5.46       8.03      25126     1157583
total        5.46       8.03      25126     1157583
Parsing user id: 62 (SKENARIO2)
Rows     Execution Plan
      0 SELECT STATEMENT   MODE: ALL_ROWS
      0   PARTITION HASH (ALL) PARTITION: START=1 STOP=4
      0    TABLE ACCESS   MODE: ANALYZED (FULL) OF
               'EQU_PARAM_MONITORINGHASH' (TABLE) PARTITION: START=1 STOP=46 partition
SELECT *
FROM
EQU_PARAM_MONITORINGHASH WHERE TO_CHAR(time_stamp,'mm/yy')=('02/09')
call          cpu    elapsed       disk        rows
Parse        0.00       0.00          0           0
Execute      0.00       0.00          0           0
Fetch        5.73       9.13      25190     1157583
total        5.73       9.13      25190     1157583
Parsing user id: 63 (SKENARIO3)
Rows     Execution Plan
      0 SELECT STATEMENT   MODE: ALL_ROWS
      0   PARTITION HASH (ALL) PARTITION: START=1 STOP=6
      0    TABLE ACCESS   MODE: ANALYZED (FULL) OF
               'EQU_PARAM_MONITORINGHASH' (TABLE) PARTITION: START=1 STOP=6thanks
best regards
eko

ekopur wrote:
i compare query select with non-partition key condition in table partition with 3, 4 and 6 partition.
time execution for 3 partition faster then 4 partition, time execution for 4 partition faster than 6 partition.
i know processing query select is selection all partition, but i don't know what make time execution different between 3, 4 and 6 partition??
whether the transfer from one partition to another partition takes time?
this example sql trace query select for 3,4 and 6 partition
3 partition
SELECT *
FROM
EQU_PARAM_MONITORINGHASH WHERE TO_CHAR(time_stamp,'mm/yy')=('02/09')
call          cpu    elapsed       disk        rows
Parse        0.00       0.00          0           0
Execute      0.00       0.00          0           0
Fetch        5.70       7.57      25291     1157583
total        5.70       7.57      25291     1157583
Parsing user id: 61 (SKENARIO1)
Rows     Execution Plan
0 SELECT STATEMENT   MODE: ALL_ROWS
0   PARTITION HASH (ALL) PARTITION: START=1 STOP=3
0    TABLE ACCESS   MODE: ANALYZED (FULL) OF
'EQU_PARAM_MONITORINGHASH' (TABLE) PARTITION: START=1 STOP=34 partition
SELECT *
FROM
EQU_PARAM_MONITORINGHASH WHERE TO_CHAR(time_stamp,'mm/yy')=('02/09')
call          cpu    elapsed       disk        rows
Parse        0.00       0.00          0           0
Execute      0.00       0.00          0           0
Fetch        5.46       8.03      25126     1157583
total        5.46       8.03      25126     1157583
Parsing user id: 62 (SKENARIO2)
Rows     Execution Plan
0 SELECT STATEMENT   MODE: ALL_ROWS
0   PARTITION HASH (ALL) PARTITION: START=1 STOP=4
0    TABLE ACCESS   MODE: ANALYZED (FULL) OF
'EQU_PARAM_MONITORINGHASH' (TABLE) PARTITION: START=1 STOP=46 partition
SELECT *
FROM
EQU_PARAM_MONITORINGHASH WHERE TO_CHAR(time_stamp,'mm/yy')=('02/09')
call          cpu    elapsed       disk        rows
Parse        0.00       0.00          0           0
Execute      0.00       0.00          0           0
Fetch        5.73       9.13      25190     1157583
total        5.73       9.13      25190     1157583
Parsing user id: 63 (SKENARIO3)
Rows     Execution Plan
0 SELECT STATEMENT   MODE: ALL_ROWS
0   PARTITION HASH (ALL) PARTITION: START=1 STOP=6
0    TABLE ACCESS   MODE: ANALYZED (FULL) OF
'EQU_PARAM_MONITORINGHASH' (TABLE) PARTITION: START=1 STOP=6
I'm assuming you recreated the table a couple of times with different numbers of hash partitions. (Tip: always use a power of two for the number of hash partitions - it keeps them all around the same size if you are using the feature on an appropriate data set.)
There isn't really enough difference in time within the database to make any sensible comment about the difference in times. I note that you have also edited out the fetch count for the 1.1 million rows fetched, and have not captured (or perhaps just not printed) the wait times, so we don't know where you spent the time inside and outside the database.
For all we can tell, the difference you are worried about might simply be network time on the fetch calls, and have nothing to do with the extract you've published.
Regards
Jonathan Lewis

Design capture of hash partitioned tables

Similar Messages

Maybe you are looking for