a) Good questions by Stephan, and knowing your requirement could help fine
tune the answer
b) The rec update date or the rec insert date is the current partition key?
If the former, that implies row movement enabled, and I can’t quite figure out
what the rolling age date is that allows you to know rows can get shoved into
history. If the latter, that is sweet, because archiving can be done via
partition exchange. You would lose that with hash partitioning.
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Stefan Knecht
Sent: Tuesday, June 05, 2018 8:08 PM
To: Woody McKay
Subject: Re: Would you hash partition a hash'ed column?
What's the problem you're trying to solve by changing the partitioning method?
Improve data load performance? Improve query performance of reports, etc ?
On Wed, Jun 6, 2018 at 6:33 AM, Woody McKay <woody.mckay@xxxxxxxxx> wrote:
Oracle 18.104.22.168 on Exadata...
Got a VLDB. Various tables are updated/inserted daily from various data
sources. The table from one source has roughly 8 billion records. The table is
currently range/interval partitioned on the rec update date/timestamp.
However, the PK and column used for the incoming data source upsert is a hash
key that's about 30 chars long and made up of digits and alphas.
Have the thought of changing the partition to be a hash partition of the PK
column that contains a hash'ed value. Does anyone have any thoughts on if that
would make sense of if there are any pros or cons for hashing partitioning a
Update. I found out that records older than x years are never updated, so we've
moved them to a history table. That took the rec count down from 8 billion to
about 750 million. That has helped performance much, but still wondering about
hash partitioning the hash key...
Thanks for any thoughts...
zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework!
Visit us at <http://zztat.net/> zztat.net | @zztat_oracle | fb.me/zztat |