sql - oracle multiple hash partitions parallel? -
i have pretty huge table using hash partitons:
create table test ( custid varchar2 (16) not null ,channel number(10) ,agent_id char(8) ,timestamp date ) cache partition hash(agent_id) ( partition e1 tablespace td_rtdm, partition e12 tablespace td_rtdm, partition e13 tablespace td_rtdm, partition e14 tablespace td_rtdm, partition e15 tablespace td_rtdm, partition e16 tablespace td_rtdm, partition e17 tablespace td_rtdm, partition e18 tablespace td_rtdm ); this works pretty good, when filter on agent_id. have new level on need filter, not include agent_id. guess need n new parallel hash partitions this:
create table test ( custid varchar2 (16) not null ,channel number(10) ,agent_id char(8) ,timestamp date ) cache partition hash(agent_id) ( partition e1 tablespace td_rtdm, partition e12 tablespace td_rtdm, partition e13 tablespace td_rtdm, partition e14 tablespace td_rtdm, partition e15 tablespace td_rtdm, partition e16 tablespace td_rtdm, partition e17 tablespace td_rtdm, partition e18 tablespace td_rtdm ) partition hash(channel) ( partition e1 tablespace td_rtdm, partition e12 tablespace td_rtdm, partition e13 tablespace td_rtdm ); but not work, since not allowed have multiple partition statements. googled , found lots of example using subpartitions, think not need.
do have idea, how tune table both queries performant? e.
partitioning not performance activity.
partitioning offers data management advantages, allowing load subsets of data through partition exchange or remove them dropping partitions.
partitioning offers high availability options, provided spread our partitions across multiple tablespaces.
now, partitioning can improve performance of queries, through partition pruning or elimination, queries aligned partition key. other queries, ones run against grain of our partitioning strategy perform neutrally or worse against unpartitioned table.
this because partitioning physical organization of table's data. rows grouped in partition key order. data cannot sorted in 2 different orders simultaneously, , that's why cannot have parallel partition keys.
there no easy solution this. global index on channel may help, because ignore partition keys, come own burdens; places forbid use of global indexes. subpartitioning can answer if key within key makes sense. rebuilding table new partitioning scheme theoretically possible never done in real life. try think outside box: maybe separate table (perhaps index-organized) help? perhaps queries might benefit different key run not worth tuning.
in short, need understand data , use cases.
Comments
Post a Comment