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 6.7.0.1.1 to 6.7.0.1.1 [Release 6.7.0]
Information in this document applies to any platform.

Symptoms

Problem:
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 "create_journal.pl -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.

Cause

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