Skip navigation

Kyle McCollum, Senior Principal Technical Support Engineer and RPAS Support Global Product Lead, shares RPAS 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. In Parts 1 and 2 of this 3-part blog series, we focused on design elements of RPAS that will provide the highest levels of performance as it relates to domain partition additions and/or reclass.  In Part 3, we’ll review how to plan for a reclass in order to avoid the headaches that will be caused by inadequate disk space.


PART 3 of 3


Consider this recent example of a reclass gone awry. One Friday night about a month ago, a customer logged a Sev 1. They had kicked off a 15K item reclass, but it failed due to disk space exhaustion. The customer contacted their hardware group and had the disk mount extended from the storage pool. As evidenced in the logs, RPAS had already begun the process of copying the measure data from the source domain to the new destination, and several hundred measures had completed prior to the disk space exhaustion. Unfortunately, there were still several thousand measures still to be reclassed, and RPAS currently has no restart mechanism for a reclass that fails before completion. Since the customer’s environment now had been extended with adequate space, we simply loaded the prod.dat again. When the load finished in about 30 seconds, we knew the hierarchies indeed had already been committed to their new destination, and therefore, there was absolutely no way to continue the reclassification from the point that the disk exhausted.


The story above does have a happy ending because we were able to recover without going to a backup.  That is a topic for a future blog: how to recover from such a state.  And, certainly, it is possible that such a failure could lead to instances where a backup must be restored.  However, it is not a desirable state to be in and it can be avoided by proper advance planning.


In order to plan, it is necessary to understand what RPAS does when a reclass is performed. The RPAS hierarchy load mechanism first compares the current hierarchy loaded in the domain with the incoming prod.dat in order to determine if a reclass needs to take place. The item(s) being reclassed then are loaded into their new local domain destination and marked as active logical positions. At the same time, the item(s) will be marked as ‘inactive’ in the current local domain. A map is created from the source to the destination, and rpasDataMover commences for all registered measures that contain the reclassed dimension. However, instead of actually moving the data from the source to the destination,  RPAS copies the data. This is the reason for the additional disk space.


Knowing this about RPAS, how do you plan for the reclass?


Planning for the disk requirements of a reclass starts by finding the size of the RPAS environment without workbooks; i.e., the size of all /data directories in the global/local domains. Then, determine the % of items being reclassed as represented by “the number of items to be reclassed divided by the total items in an environment”.   Multiply the % being reclassed by the environment size.  This provides a rough estimate of how much additional disk space you will need to complete the reclass successfully. This rough estimate should be quite liberal, as certainly not every measure in the environment is reclassed; only the measures which contain dimensions for which a position has been reclassed will undertake an rpasDataMover.


Let’s review a quick example:

   1. RPAS Environment = 1.8TB

   2. # of items being reclassed = 12,000

   3. Total # of items in environment = 320,000


Additional disk space required = 1.8TB X (12,000/320,000) = 67.5 GB


As stated previously, RPAS copies (rather than moves) the data from the source to the destination. Thus the data associated with the ‘inactive logical positions’ in the source remains in the system. This is a departure from the earlier Position Name Indirection (PNI) design, which went to the expense of cleaning all of the measures – a very time-consuming task.  In the current design, RPAS has removed this task from loadHier in order to enhance the overall performance of reclass.  The optimizeDomain utility is responsible for deleting the stale data. The utility should be run during a window with idle system time (i.e., no users / no batch).  When executing the utility, be sure to use the '-processes' flag to ensure the highest throughput possible.


This concludes the 3-part blog series on design and planning considerations related to domain partition additions and/or reclass.

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

- Click here to revisit Part 2 of this series, which discussed effective use of loadHier parameters to maximize 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.


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 for instructions.