IFW Duplicate Check Implementation (Doc ID 2416583.1)

Last updated on NOVEMBER 18, 2024

Applies to:

Goal

On : 7.5.0.16.0 version, Pipeline Manager

IFW Duplicate Check implementation

Customer is going to implement the IFW duplicate check - in order to reject non-unique EDRs. To evaluate this method below are some of the questions needs to be answered prior to the implementation start.


1) Buffer Limit vs memory occupancy: - Let's assume customer is going to set buffer limit 3 days back, X - the daily number of CDRs generated, Y - the average size of the EDR in the flat file.
  Do we have any method/calculator to estimate extra memory sizing which will be consumed by IFW ?


2) The additional memory mentioned in the above  will be consumed immediately after restart and visible from OS perspective ?

3) In the below mentioned related documentation:

https://docs.oracle.com/cd/E16754_01/doc.75/e16710/ifw_rate_pipe_processing.htm#BRMPI254, there is a note:

  "Important:
  Do not use the DETAIL.CHARGING_START_TIMESTAMP field for duplicate checking"

Please share some background here as why we can not use this "start_timestamp" ?

4) Customer is using the multi-schema setup with BRM account routers in the front. While the integrated schema is a common one in the multischema setup - One can implement the IFW duplicate check as a part of the account router functionality (then the additional memory should be planned on 2 boxes (account routers) instead of the 6 BRM application nodes ? Or it should be implemented on BRM application boxes rather and linked to the different IFW_DUPLICATECHECK tables - each dedicated for particular schema ? Is there any best practice available ?
 

Solution

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.