Interval Partitioning

Question

Hi everyone,
I've got a question about interval partitioning. I've got a fact table, W_GL_BALANCE_F that is fairly massive and I want to use interval partitioning on the BALANCE_DT_WID field. The values in the field are of the form YYYYMMDD || '000', i.e. 20100820000 would be today, 20100821000 would be tomorrow, etc.
I create the table with interval partitioning with an interval of 1000, and then when I go to insert the data, I get the error "Partition does not exist". I was a little confused because I thought interval partitions created partitions for any new value.
I ran some tests on a test table part_test(part_key number) partition range interval (1) ( partition "zero" less than 1). Then I inserted a few test records
INSERT INTO part_test (part_key) values (1);
INSERT INTO part_test (part_key) values (2);
INSERT INTO part_test (part_key) values (10);
INSERT INTO part_test (part_key) values (1000000); --- This causes error "Partition does not exist"
Obviously there are some additional rules to go along with using the intervals. I was under the impression that it would just create a range for any new value but it seems more complicated than that.
Can someone explain to me why the final record isn't able to have a new partition created for it?
I apologize if this is a dumb question, but I'm a little new to the different partitioning options.
Best regards and thanks for the help!
-Joe

Answer 1

Joe Bertram wrote:
Hi Tubby,
Just to give you a little more background, I am working with the Oracle BI Applications prepackaged data warehouse and ETLs. Because it's all prepackaged ETLs, I don't have too much flexibility to change the data being loaded, otherwise, I totally agree that using this date format is kind of strange. Thanks for the information, helps to know :)
Joe Bertram wrote:
I looked at other fields on the table for a potential partition key, and this field was the only one that was remotely uniformly distributed. That really isn't the first consideration you should have for partitioning. What are you trying to accomplish with partitioning? Are you looking to make data archival easier (dropping old partitions is the easiest way to go), or are you looking to enhance querying? Partitioning is a tool you implement for a given purpose ... so what's yours?
Joe Bertram wrote:>
You are correct, my test case was a little simplistic. I went back to the data the see why your case succeeded and mine failed. It turns out I missed one part in the date format. In addition to the date format as I laid it out, they also append the calendar ID which refers to the fiscal calender to which the date belongs. the actual format is <4-digit-cal_id>YYYYMMDD<000> i.e. 100120100820000 is today on calendar 1001, but there could also be a calendar 1007 which could have today's date i.e. 100720100820000.
drop table part_test;
create table part_test
part_key number
partition by range (part_key)
interval (1000)
partition zero_1 values less than (100120100820000)
INSERT INTO part_test (part_key) values (100120100820000);
INSERT INTO part_test (part_key) values (100720100820000); -- same day on calendar 1007, causes an errorIt pretty much seems to me that there would be too many potential partitions, so the DB gives up. Is that correct?That indeed seems to be the case, you could perhaps raise a service request with Oracle, but i'm not sure how eager they'd be to enhance the interval partitioning for this case. This data doesn't seem like it would be a good candidate for range partitioning. Again, we need to know what you're goal is from partitioning.
If housekeeping is paramount (keeping X days of data and purging old data) then i would suggest the following.
create table part_test
   part_key       number,
   magic_column   generated always as ( to_date(substr (part_key, 5, 8), 'yyyymmdd') ) virtual
   partition by range (magic_column)
   INTERVAL ( INTERVAL '1' DAY)
   partition zero_1 values less than ( to_date('20100820', 'yyyymmdd') )
);Partitioning by a virtual column, the date in this case.
It's possibly you have a more logical key to partition off of, but a RANGE partition scheme on your part_key doesn't sound good at all.