Large partitioned tables with WM

Question

Hello
I've got a few large tables (6-10GB+) that will have around 500k new rows added on a daily basis as part of an overnight batch job. No rows are ever updated, only inserted or deleted and then re-inserted. I want to stop the process that adds the new rows from being an overnight batch to being a near real time process i.e. a queue will be populated with requests to rebuild the content of these tables for specific parent ids, and a process will consume those requests throughout the day rather than going through the whole list in one go.
I need to provide views of the data asof a point in time i.e. what was the content of the tables at close of business yesterday, and for this I am considering using workspaces.
I need to keep at least 10 days worth of data and I was planning to partition the table and drop one partition every day. If I use workspaces, I can see that oracle creates a view in place of the original table and creates a versioned table with the LT suffix - this is the table name returned by DBMSMW.GetPhysicalTableName. Would it be considered bad practice to drop partitions from this physical table as I would do with a non version enabled table? If so, what would be the best method for dropping off old data?
Thanks in advance
David

Answer 1

Hello Ben
Thank you for your reply.
The table structure we have is like so:
CREATE TABLE hdr
(   pk_id               NUMBER PRIMARY KEY,
    customer_id         NUMBER FOREIGN KEY REFERENCES customer,
    entry_type          NUMBER NOT NULL
CREATE TABLE dtl_daily
(   pk_id               NUMBER PRIMARY KEY,
    hdr_id              NUMBER FOREIGN KEY REFERENCES hdr
    active_date         DATE NOT NULL,
    col1                NUMBER
    col2                NUMBER
PARTITION BY RANGE(active_date)
(   PARTITION ptn_200709
        VALUES LESS THAN (TO_DATE('200710','YYYYMM'))
        TABLESPACE x COMPRESS,
    PARTITION ptn_200710
        VALUES LESS THAN (TO_DATE('200711','YYYYMM'))
        TABLESPACE x COMPRESS
CREATE TABLE dtl_hourly
(   pk_id               NUMBER PRIMARY KEY,
    hdr_id              NUMBER FOREIGN KEY REFERENCES hdr
    active_date         DATE NOT NULL,
    active_hour         NUMBER NOT NULL,
    col1                NUMBER
    col2                NUMBER
PARTITION BY RANGE(active_date)
(   PARTITION ptn_20070901
        VALUES LESS THAN (TO_DATE('20070902','YYYYMMDD'))
        TABLESPACE x COMPRESS,
    PARTITION ptn_20070902
        VALUES LESS THAN (TO_DATE('20070903','YYYYMMDD'))
        TABLESPACE x COMPRESS
    PARTITION ptn_20070903
        VALUES LESS THAN (TO_DATE('20070904','YYYYMMDD'))
        TABLESPACE x COMPRESS
    ...For every day for 20 years
/The hdr table holds one or more rows for each customer and has it's own synthetic key generated for every entry as there can be multiple rows having the same entry_type for a customer. There are two detail tables, daily and hourly, which hold detail data at those two granularities. Some customers require hourly detail, in which case the hourly table is populated and the daily table is populated by aggregating the hourly data. Other customers require only daily data in which case the hourly table is not populated.
At the moment, changes to customer data require that the content of these tables are rebuilt for that customer. This rebuild is done every night for the changed customers and I want to change this to be a near real time rebuild. The rebuild involves deleteing all existing entries from the three tables for the customer and then re-inserting the new set using new synthetic keys. If we do make this near real time, we need to be able to provide a snapshot of the data asof close of business every day, and we need to be able to report as of a point of time up to 10 days in the past.
For any one customer, they may have rows in the hourly table that goes out 20 years at a hourly granularity, but once the active date has passed(by 10 days), we no longer need to keep it. This is why we were considering partitioning as it gives us a simple way of dropping off old data, and as a nice side effect, helps to improve performance of queries that are looking for active data between a range of dates (which is most of them).
I did have a look at the idea of save points but I wasn't sure it would be efficient. So in this case, would the idea be that we don't partition the table but instead at close of business every day, we create a savepoint like "savepoint_20070921" and instead of using dbms_wm.gotodate. we would use dbms_wm.gotosavepoint. Then every day we would do
DBMS_WM.DeleteSavepoint(
   workspace                   => 'LIVE',
   savepoint_name              => 'savepoint_20070910', --10 days ago
   compress_view_wo_overwrite  => TRUE,
DBMS_WM.CompressWorkspace(
   workspace                   => 'LIVE,
   compress_view_wo_overwrite  => TRUE,
   firstSP                     => 'savepoint_20070911', --the new oldest save point
   );Is my understanding correct?
David
Message was edited by:
fixed some formatting
David Tyler