Warehouse partitioning - performance of queries across multiple partitions?

Question

Hi,
We are using Oracle 11.2.0.3 and have a large central fact table with several surrogate ids which have bitmap indexes on them and have fks looking at dimension tables + several measures
(PRODUCT_ID,
CUSTOMER_ID,
DAY_ID,
TRANS_TYPE_ID,
REGION_ID,
QTY
VALUE)
We have 2 distinct sets of queries users look to run for most part, ones accessing all transactions for products regradless of the time those transactions happened (i.e. non-financial queries - about 70%,
queries determining what happened in a particular week - 20% of queries.
Table will have approx 4bn rows in eventually.
Considering adding extra column to this DATE and range partition this to allow us to drop old partitions every year - however this data wouldn't be joined to any other table.
Then considering sub-partitioning by hash of product_id which is surrogate key for product dimension.
Thoughts on performance?
Queries by their nature would hit several sub-partitions.
Thoughts on query performance of queries which access several sub-partitions/partitions versus queries running aganist a single table.
Any other thoughts on partitioning strategy in our situation much apprecaited.
Thanks

Answer 1

>
Thoughts on query performance of queries which access several sub-partitions/partitions versus queries running aganist a single table.
>
Queries that access multiple partitions can improve performance for two use cases: 1) only a subset of the entire table is needed and 2) if the access is done in parallel.
Even if 9 of 10 partitions are needed that can still be better than scanning a single table containing all of the data. And when there is a logical partitioning key (transaction date) that matches typical query predicate conditions then you can get guaranteed benefits by limiting a query to only 1 (or a small number) partition when an index on a single table might not get used at all.
Conversely, if all table data is needed (perhaps there is no good partition key) and parallel option is not available then I wouldn't expect any performance benefit for either single table or partitioning.
You don't mention if you have licensed the parallel option.
>
Any other thoughts on partitioning strategy in our situation much apprecaited.
>
You provide some confusing information. On the one hand you say that 70% of your queries are
>
ones accessing all transactions for products regradless of the time those transactions happened
>
But then you add that you are
>
Considering adding extra column to this DATE and range partition this to allow us to drop old partitions every year
>
How can you drop old partitions every year if 70% of the queries need product data 'regardless of the time those transactions happened'?
What is the actual 'datetime' requirement'? And what is your definition of 'a particular week'? Does a week cross Month and Year boundaries? Does the requirement include MONTHLY, QUARTERLY or ANNUAL reporting?
Those 'boundary' requirements (and the online/offline need) are critical inputs to the best partitioning strategy. A MONTHLY partitioning strategy means that for some weeks two partitions are needed. A weekly partitioning strategy means that for some months two partitions are needed. Which queries are run more frequently weekly or monthly?
Why did you mention sub-partitioning? What benefit do you expect or what problem are you trying to address? And why hash? Hash partitioning guarantees that ALL partitions will be needed for predicate-based queries since Oracle can't prune partitions when it evaluates execution plans.
The biggest performance benefit of partitioning is when the partition keys used have a high correspondence with the filter predicates used in the queries that you run.
Contrarily the biggest management benefit of partitioning is when you can use interval partitioning to automate the creation of new partitions (and subpartitions if used) based solely on the data.
The other big consideration for partitioning, for both performance and management, is the use of global versus local indexes. WIth global indexes (e.g. a global primary key) you can't just drop a partition in isolation; the global primary key needs to be maintained by deleting the corresponding index entries.
On the other hand if your partition key includes the primary key column(s) then you can use a local index for the primary key. Then partition maintenance (drop, exchange) is very efficient.