RPAS Hierarchy Cardinality

One of the major changes we had RPAS 13.3 or later, was the introduction of the concept Cardinality and Re-Indexing Threshold. This concept was developed to solve big issues about space management and capacity of dimensions within the RPAS.

How it was before version 13.3?

In previous versions, each position of a dimension was identified by STRING defined by the hierarchy and each dimension had a definition of “Buffer % Low” and “Buffer % High” to manage its capacity.

Theses informations were used to define how each dimension had space available for entering new positions; with this, the system made a reservation to load new positions – loaded or created by dynamic positions

The problem was that the base value for each dimension was based on the number of positions during the creation of the domain.

That is, if we created a domain with few positions in one dimension, RPAS has created small buffer to increase the positions. So if we want to load a large number of positions, would have to do many steps for open theses positions to be loaded.

Put another way, assuming a project you would like to start with only a department to validation or prototype. If you then wanted to increase the number of departments, you would have some difficulties because space will not be enough.

Other problem was when removing positions, the RPAS had trouble managing this available space, often was necessary to run the binary to solve this and always took a long time to complete.

How is it in version 13.3 or later?

In version 13.3, Oracle introduced a new methodology to manage this question: Integer Indexing. This solution allows the management of hierarchy through an Index for each position, as an Index for SQLs solutions.

In this scenario, RPAS could work with same performance of Oracle Database and made possible eliminate many issue with operations like add, remove or reclassifying positions within a solution.

Integer Indexing

Besides that, the dynamic positions management (DPM – Placeholders) has been simplified and less time-consuming. Now RPAS basically fetches an available position in the B-tree to create placeholder, without the need to increase the hierarchy.

Therefore with this strategy, the RPAS never increases or decreases the hierarchy until it’s requested; so throughout the hierarchy load, RPAS manage the positions to populate or clean the positions of the hierarchy, making the rapid charging process.

Thus, when RPAS needs to purge any position in one dimension, it will not remove more position, only frees up to the new loads.

Re-indexing Threshold

Another change we have in the new versions is a better capacity to manage of Threshold of hierarchies.

With load or purge activites, RPAS can activate or deactivate many positions, so it’s necessary to reindex the domain to keep the best index to performance all operations. To do it, it’s necessary to use reindexDomain.

This binary allows you to check the all dimensions we have in domain, checking dimension bitsize, capacity, maximum physical, logical maximum, threshold and action required.

In this analysis we have the following options for each dimension:

  • Nothing to do
  • Fragmented Positions
  • Bit Size Increase

Fragmented Positions option aims to index and rank the positions within the domain so that the positions are available for a next data load. It helps to reduce empty space in the hierarchy and keep the order of index.

Bit Size Increase option is a sign that the positions is near the limit of capacity of dimension, so it’s necessary to increase the positions before a load or create placeholder is not possible.

Leave a Reply

Your email address will not be published. Required fields are marked *