Very Large Table support for OAM in CMOD 8.4.0

[LWagner]

     Our PDF load requirement as currently designed, with go live date imminent has finally brought us live test files.
     We will need to store 25 - 45 Gb daily to OAM, averaging about 36 Gb, which look like it will require Partitioned tablespaces.  But the only way we can see to do this is with triggers on every insert from an external table, the app group index. And triggers have performance hits, so DBAs don't even want to consider them. 

      This works out to 800 Gb a month, and we want to have 2 years data online eventually, pushing 2 TB.

     


      Is anyone using extremely large OAM tables for OnDemand ?  If OAM is not possible, then what ?

[Alessandro Perucchi]

Hello

Which version of DB2 are you currently using?
In DB2 V9 on z/OS I would suggest to use partitioning by growth which will allow DB2 to extend automatically. I have one customer using this now.
If not, then another possibility would be to add collections by adding new nodes to the Storage Set so that e.g. every year or so a new OAM DB could be used.

(this was the answer of one of my collegue specialist on z/OS and DB2/CMOD here in Switzerland :-D)

Cheers,
Alessandro

[LWagner]

We are still on DB2 8.1, limited to 64 GB in non-partitioned databases, including OAM.  Without DB2 9.1, we are limited to CMOD 8.4.0. Poor PDF handling.

We would be using an OAM database pretty much everyday, and it would hit the VTS performance as OAMs Ttape usage grew. Our solution of last resort, and looks like we don't need it.

The 30Mb PDFs expand by a factor of 10 -16 to 300 MB or more, we will have a total of 24 - 42 Gb a day in about 100 or more files.  Much beyond 2000 pages per PDF causes an arsload abend.  The PDF Indexer reports the page count and fails stating it exceeded 1 Gb memory, so the abend happens quickly.

We decided to partition on system date, since we don't need to connect to the CMOD, only run very simple triggers.  This worked.  Now we're trying to get it OAM to work with Large Objects (LOB), and that failed with  DB2 error requiring a configuration change in DB2 for the large object size, DB2 error 00C900D1

[Ed_Arnold]

Hmmm:

00C900D1

Explanation

The amount of space allowed for processing LOB values by a user has been exceeded. The amount of space allowed per user is indicated by panel DSNTIPD.
System action

The operation is not allowed. DB2? returns "resource not available" to its invoker.

System programmer response

If possible, increase the value of subsystem parameter LOBVALA.

Problem determination

The requested operation is not performed. An SQLCODE -904 is issued. Message DSNT500I or message DSNT501I might also be issued.
Collect the following diagnostic items:

    Console output from the system on which the job was run, and a listing of the SYSLOG data set for the period of time spanning the failure.
    SVC dump (or system dump), taken to SYS1.DUMPxx data set, as result of an operator-initiated dump command or SLIP trap exit.
    Listing of SYS1.LOGREC data set, obtained by executing IFCEREP1.