Creating Custom Partitions on Cube

Question

Hi all
We are running BW7 (2004s) over Oracle.
We are contemplating creating our own partitions on the EFact table of a cube.  The reason for this is that currently the partitioning of cubes is only possible using time characteristics (0FICPER and 0CALMONTH).
We have a need to partition by a characteristic that is an 8 digit number.
Hence, we are proposing to create our own range partitions on this Characteristic.
My questions are as follows:
1. If we do this, we would be creating them directly at the Oracle level.  To do so, we would have to first create a copy of the Fact table definin then partitions.  We would then drop the orginal fact table, and rename the copied table back to the original efact table name. 
2. Are there any issues with us doing this?  i.e. if for some reason the table is dropped in the future (for some unknown internal BW database process), would we lose the partitions?
3. We are keen to do this so that queries which are keyed by this 8 digit number are much more efficient.  Also, when deleting data, we would delete by a partition (i.e. much faster to delete).
Has anyone else done this sort of thing?  Any issues encountered?  Any advice?
Thanks
Adam

Answer 1

I face the opposite problem, nobody wants to get rid of anything, so we jump thru hoops trying to figure out how to keep the data in BW and still maintain query performance. I'd love a few clients that want to get rid of stuff, perhaps we can trade a few folks for a couple of months.
You didn't say if this 8 digit char is a line item dimension, or if there are other chars in the dimension.  That has query and deletion performance implications.
You can partition your ODSs on the 8 digit char.
On the cube side side, I have never explored it further, but wondered if I wasn't using 0FISCPER, (or it could be 0CALMONTH) could I populate it in an update rule with some date values that could serve as the proxy for the characteristic ( or ranges of values in your case ) I really wanted to partition on, e.g.
8 digit char
00000001 - 00999999 = 0FISCPER 1000/000
01000000 - 01999999 = 0FISCPER 1000/001
etc.
I think you can probably get the idea. I think this would support the goal of the faster Selective Deletion, but obviously doesn't help you on the query side - although you might be able to have your user exit translate the 8 digit char to the corresponding 0FISCPER proxy.  Seems kind of goofy, but I think it could work, but ultimately might cause more confusion than it's worth. 
Query performance would only benefit from partitioning, of course, if the queries would restrict based on the partitioning characteristic to make Oracle prune the unneeded partitions from the query.
<u>Selective Deletion</u>
As I mentioned in my first post, Selective Deletion does have some performance tweaks built into the process besides dropping the partition.  If the deletion was going to delete more than 10% (the deletion process figures this out) of the rows (I don't remember if you can control that % by an RSADMIN parameter or not - although you could probably modify the program or create a Z version to use some lower %) it will create new E and F Fact tables, copying the data to the new tables, omitting the rows that meet your deletion criteria, and allows you to specify how many parallel processes to launch. Once it's done, it deletes the original Fact tables and renames the new ones.  You do need to have enough disk space to hold the original cube and the new, smaller cube, since they both exist for a period of time. This is much faster than the heavy lifting of Delete query, and could be run off hours and wouldn't require any special DDL or customization of the fact tables, or prevent use of aggregates, etc.
Or you could go the other route of running a daily deletion process to keep the deletion shorter.  If the number of rows to be deleted on any one day is small and there is an index on the 8 digit Char, it might be fast enough to suit your purposes.
I'll ponder on this a while and see if anything else comes to mind.  Some time back, I thought I had read a post that mentioned a custom partioning that had been developed for a DB2 customer.  I followed it up with a Custosmer Msg to SAP recently to see if there were any other partitioning options besides the two dates for Oracle.  I got a "not at this time" answer.  If you haven't contacted SAP about this issue already, perhaps if you post a msg, they'll get a better sense of the level of interest.
If you're attending Tech Ed (SDN Day?) in Vegas in Sept, we could explore this further. 
Pizzaman
PS.
Put yourself on the SDN world map (http://sdn.idizaai.be/sdn_world/sdn_world.html) and earn 25 points.
Spread the wor(l)d!