Create_pkg_journal.Plb Utility Ignores Partition_historic

(Doc ID 1147885.1)

Last updated on MAY 10, 2013

Applies to:

Oracle Communications Billing and Revenue Management - Version to [Release 6.7.0]
Information in this document applies to any platform.


When the package detects that event partitioning is enabled, it looks at the wrong end of the partition chain (highest values) to include the PARTITION_HISTORIC partition, which in fact is one of the partitions with the lowest values (below timed partitions). This is not a problem with OOB BRM, as no event types having balance impacts are considered “Historic”, but the current environment has redefined the "/event/billing/product/fee/purchase" event type from a timed partition type to an historic partition type.

Steps to Reproduce:
Looking into create_pkg_journal.source for partitioned event table migration to journal objects, after clauses for all the timed event partitions that could apply for the date ranges currently processed, we see:

' OR e.poid_id0 >= '||to_char(V_MIN_POID_ID_IN_HISTORIC)||...
i.e. 0x7FFFFFFFFFFFFFFF or 9223372036854775807 at the high end of a 64-bit ranged partition value.

PARTITION_HISTORIC is defined as < 0x200000000000 (35184372088832), which means that it will never be queried for the journal upgrade. In addition, PARTITION_MIGRATE (which does exist in the environment here since partitioning was enabled about a year after first go-live) is defined as < 0x100000000000 (17592186044416) and thus also is ignored.

The last partition-filtering clause should be something like:
' OR e.poid_id0 < 35184372088832'||..., so that the historic and migrate partitions are scanned for events to be converted to journal entries.

We have proven that no journal objects are created from these 2 partitions (which are known to contain G/L ledger report data) by running the " -mode create_temp_journals" mode in a production copy.

Note that the Perl script and PLB referenced here were used successfully in an upgrade from 6.5 to 7.2.1, but that environment did not have a PARTITION_MIGRATE, and the PARTITION_HISTORIC did not have any revenue-related balance impacts that were needed.

Expected result:
Journal objects are created for all data related to the time-frame configured, regardless of the partition in which is resides.

Actual result:
Some data (and thus revenue tracking) is being ignored.


Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms