Slow Performance For PCM_OP_REFUND

In BRM 7.5 MPS1 (Doc ID 2165089.1)

Last updated on DECEMBER 14, 2017

Applies to:
Oracle Communications Billing and Revenue Management - Version 7.5.0.13.0 and later
Information in this document applies to any platform.

Goal
On : 7.5.0.13.0 version, Subscription Management

Scenario:
In production environment, the execution of PCM_OP_REFUND takes a lot of time.

Most of the time (about 300 sec for single transaction) is spent by performing the following
standard search in fm_pymt_pol_pre_collect.c policy:

In particular, the part in the "exists" condition is the issue. This is because the
event_billing_charge_t in production environment is a partitioned table with over 200 millions of
rows, which host over six years of data.
This part of the query searches only on the uncommitted (so, really recent) transactions.
Customer wants to change the search by substituting the 0 value in the condition "where obj_id0
> 0" with a dynamically computed one, so that the search period is reduced to the last 5 days
(and several millions rows less...).
For example: "where obj_id0 > 297712564429651968" (max poid value for 01/05/2016).

Question: Need to reduce the time taken in execution. Is the above solution feasible, or could it
produce any issues with BRM refund logic or other processes?
Solution

To view full details, 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 a
vibrant support community of peers and Oracle experts.
Oracle offers a comprehensive and fully integrated stack of cloud applications and platform
services. For more information about Oracle (NYSE:ORCL), visit oracle.com.

© Oracle | Contact and Chat | Support | Communities | Connect with us | Legal Notices |
Terms of Use