Skip navigation

Kyle McCollum, Senior Principal Technical Support Engineer and RPAS Support Global Product Lead, shares best practices to encourage solid RPAS design and implementation.

 

Oracle Retail Predictive Application Server (RPAS) Support frequently responds to performance problems/concerns which may arise when loading hierarchies that add new partition positions and/or reclass existing products from one local domain to another. Below is Part 2 of a 3-part blog series which presents concepts intended to aid customers in putting forth the best design possible to ensure that the highest levels of performance are achieved when performing such actions.

 

 

PART 2 OF 3

 

By effectively using the parameters provided by loadHier, it is very possible to reduce the total reclass time by 50% or more. When performing a large reclass (such as one involving 10K+ items), this time savings could certainly make the difference when it comes to meeting an ‘Application Up’ SLA (service level agreement) for the business.

 

Although very powerful when it comes to performance optimization, the following parameters tend to be overlooked by most RPAS designers:

 

-excludeMeasList

  Path to exclude list XML file. Optimize performance by excluding this list of measures while moving data during the hierarchy reclassification process.

 

-includeMeasList

  Path to include list XML file. Optimize performance by including only this list of measures while moving data during the hierarchy reclassification process.

 


Without these parameters specified, every single measure with a base intersection that contains the reclass dimension will be invoked for a data transfer from the source domain to the destination domain -- including transferring data for calculated measures, which is a wasteful activity.

 

Therefore, the -excludeMeasList and -includeMeasList parameters should be a key part of every RPAS design in the field.  Designers should exploit this feature by telling RPAS to move data only for non-calculated measures during the reclass.  Consider the fact that after the reclass, the next likely batch job is going to be the main batch calculation sequence.  Thus, let the calculation engine perform the work of populating the data of calculated measures for the positions that have just been reclassed, and allow the reclass itself to bypass this duplication of effort.

 

A designer can quickly get a list of all calculated measures by using a 'mace –print –group' command and then piping that output to some 'grep' statements to get the LHS measures of the expressions. All rule groups with the exception of _load, _refresh, _commit should be evaluated to find the LHS measures. The 'mace –print –allGroups' should NOT be used, as this would include the rule groups just mentioned.

 

Another approach would be to utilize the “measure description” field in the Configuration Tools to describe each measure appropriately (e.g., “A calculated measure that ……” or “A loaded measure…”).  Then a command such as “printArray -array data/measdata.measinfo -slice info:description -cellsperrow 1 | grep -i calculate” would provide a list of the calculated measures.

 

 

Part 3 of this blog series will discuss space requirements for a large reclass.

Click here to revisit Part 1 of this series, which discussed partitioning considerations.



Feel free to comment on this article in this forum, or you may take in-depth questions and discussions to the Retail Predictive Application Server (RPAS) Support Community on My Oracle Support.

 

O_Retail_clr_new.png


 

Kyle McCollum, Senior Principal Technical Support Engineer and RPAS Support Global Product Lead, shares best practices to encourage solid RPAS design and implementation.

 

Oracle Retail Predictive Application Server (RPAS) Support frequently responds to performance problems/concerns which may arise when loading hierarchies that add new partition positions and/or reclass existing products from one local domain to another. Below is Part 1 of a 3-part blog series which presents concepts intended to aid customers in putting forth the best design possible to ensure that the highest levels of performance are achieved when performing such actions.

 

Note: In general, while most information contained herein is applicable to all RPAS versions, some information is only relevant to RPAS Integer Indexing (i.e., version 13.3 and higher). 

 


PART 1 OF 3

 

When adding new partition positions to an existing environment, those positions can either be added to an existing local domain or to a new local domain. When the partition and associated base positions are added to a new local domain, RPAS does not actually create the new domain from 'scratch'.  Instead, RPAS copies the first domain that is registered within the environment. Then, RPAS removes all of the existing products from the new, copied domain and adds the new partition and its associated positions to it.

 

It is well known that RPAS environments can be very large. We regularly see local domains that range in size from 50GB to 250GB. Therefore, if the first domain in the index of your environment is very large, RPAS must copy a very large local domain to create the new domain for the new partition position. That can become very expensive not only from a performance perspective, but also from a disk perspective. The disk expense becomes even more evident in the case of Integer Indexing because that architecture only marks positions as 'logically deleted'.  Thus, the 100GB of data that was copied from the first local domain cannot be reclaimed until the optimizeDomain utility is run.  However, optimizeDomain is an expensive, time-consuming operation and should only be performed on a scheduled basis, e.g. once per quarter.

 

Given this, what can be done to mitigate the performance and disk implications?

 

To work around this situation, it is best to build your environment with a dummy partition with 1 base level position as the first indexed domain.  On the surface, this is a very simple effort.  However, keep in mind the purgeAge. Typically, a 30 day purgeAge is recommended.  After all, RPAS is not meant to be a data warehouse and the environment should only contain data relevant to current operations.  Thus, the domain will be deleted after 30 days unless you design a mechanism by which to inject the 1 dummy record into the prod.dat such that it is loaded prior to meeting the purgeAge.  Keeping the 1 dummy record in a static file and using 'cat' to append it to the incoming prod.dat should suffice.  This will keep the small, dummy domain from being deleted.

 


Part 2 of this series will discuss effectively using the LoadHier utility to improve reclass performance.



Feel free to comment on this article in this forum, or you may take in-depth questions and discussions to the Retail Predictive Application Server (RPAS) Support Community on My Oracle Support.


O_Retail_clr_new.png

The popular Case Study: Creating a High Availability Environment for Oracle Retail (Document 1666048.1) has been updated to include information relevant to Retail Release 14.1!

 

This case study describes how an Oracle Linux high-availability environment can be configured to support Oracle Retail applications. Using Oracle Fusion Middleware active-active clustering and Oracle Real Application Clusters (RAC) databases, Oracle Retail applications can be deployed in a fault tolerant computing environment to provide high availability and scalability. This case study includes the following documents for Releases 14.0 and 14.1:

  • Oracle Retail High-Availability Case Study Introduction
  • Oracle Retail High-Availability Case Study Oracle Linux
  • Oracle Retail High-Availability Case Study RAC (Real Application Clusters Environment)
  • Oracle Retail High-Availability Case Study Fusion Middleware Cluster (Parts 1 and 2)

 

O_Retail_clr_new.png

Welcome to the My Oracle Support Community! We highly encourage you to personalize your community display name to make your activity more memorable. Please see https://community.oracle.com/docs/DOC-1022508 for instructions.