Hierarchy
DMIS (Software Component) DMIS 2011_1⤷
CA-GTF-BS (Application Component) Business Application Support⤷
CNV_10020 (Package) CNV package 10020
Basic Data
| Data Element | CNV_10020_LRU_METHOD |
| Short Description | Method for deleting relationship data (partial loading) |
Data Type
| Category of Dictionary Type | D | Domain |
| Type of Object Referenced | No Information | |
| Domain / Name of Reference Type | CNV_10020_LRU_METHOD | |
| Data Type | CHAR | Character String |
| Length | 2 | |
| Decimal Places | 0 | |
| Output Length | 2 | |
| Value Table |
Further Characteristics
| Search Help: Name | ||
| Search Help: Parameters | ||
| Parameter ID | ||
| Default Component name | ||
| Change document | ||
| No Input History | ||
| Basic direction is set to LTR | ||
| No BIDI Filtering |
Field Label
| Length | Field Label | |
| Short | 10 | LRU M. |
| Medium | 15 | LRU Method |
| Long | 20 | LRU Method |
| Heading | 6 | LRU M. |
Documentation
Definition
If a determination path has a huge amount of relationship data, memory problems can occur when this data is loaded into the internal object tables. To avoid this, only individual blocks of relationship data are loaded in a partial loading process and stored in the memory as long as they are required. If determination is meant to take place for a source determination value, but the corresponding data block is not present in the memory, it has to be loaded subsequently. If the maximum number of jobs for partial loading has already been reached, one of the loaded blocks has to make way for the new block. Each block has an internal counter (BL) that is incremented every time the block gets loaded. With regard to the fact that loading a block is quite expensive, BL should be kept as low as possible. Ideally, a deleted block should not be needed any more at all in subsequent processing.
You use this parameter to define the strategy for determining the block to be deleted. Some strategies try to avoid multiple deletions of blocks (which would result in high BL values).
The currently implemented alternatives are as follows:
LRU - Deletion of least recently used block
The system deletes the block that has been accessed least often. To be able to decide which block this should be, the system increments the access counter Z for the block every time it is accessed. The first block with the lowest value for Z gets deleted, and its Z counter is initialized.
LRU considering the number of block loads
With the LRU strategy, blocks that have a high value for Z are kept in the memory. gehalten. Because Z is reset to 0 every time a block gets deleted, it is hard for "new" blocks to get a high value for Z. Consequently, they get deleted over and over again, and their BL increases accordingly. To avoid this, this method deletes the first block with the lowest value for Z * BL.
LRU without resetting the access counter
Other than for the LRU method described above, this method involves keeping the existing value for Z when a block gets deleted. When the deleted block is loaded again, Z gets the value it had before the block got deleted. This avoids that blocks with a high value for Z remain in the memory for too long.
LRU without resetting the access counter and considering the number of block loads
By keeping Z intact when a block gets deleted, you avoid a strong increase in BL. To further increase this effect, the first block with the smallest value for Z * BL gets deleted if you choose this method.
LFU - Deletion of least frequently used block
The system deletes the block that has not been accessed for the longest period of time. To be able to decide which block this should be, the system initializes the non-access counter (NZ) of a block every time the block gets accessed, and increments the corresponding NZ values for all other blocks. The first block with the highest value for NZ gets deleted.
LFU considering the number of block loads
With the LFU strategy, blocks that have a high value for NZ get deleted. This may affect blocks that are accessed time and again, but only a few times in total. These blocks get deleted over and over again, and their BL increases. To avoid this, method deletes the first block with the highest value for NZ / BL.
FIFO - Delete the block that was loaded first
Out of the currently loaded blocks, the block that was loaded first gets deleted. In comparison with the LRU and LFU methods, the advantage of this method is that no counters have to be kept up-to-date.
FIFO considering the number of block loads
Out of the currently loaded blocks with the lowest value for BL, the block that was loaded first gets deleted (as with FIFO). The advantage of this method is that blocks with a high value for BL do not get deleted so easily.
RANDOM - Random selection of block to be deleted
The block to be deleted is determined at random.
RANDOM considering the number of block loads
Out of the currently loaded blocks with the lowest value for BL, the block to be deleted is determined at random. The advantage of this method is that blocks with a high value for BL do not get deleted so easily. In addition, it is not necessary to keep any counters up-to-date (unlike with LRU and LFU).
RANDOM with adapted likelihood
As with the RANDOM method, the block to be deleted is determined at random. However the system makes sure that blocks with a high value for BL are less likely to be deleted than blocks with a low value for BL.
NO DELETE - do not delete loaded blocks
Loaded blocks remain in the memory irrespective of the number of blocks to be loaded. No deletion takes place. In comparison with the LRU and LFU methods, the advantage of this method is that no counters have to be kept up-to-date. However it may mean that ultimately all blocks get loaded.
Notes
- You can change the deletion method even while the conversion program is running. The change becomes effective the next time a block gets loaded or deleted.
- Note that the system initializes the counters when you change the deletion method.
History
| Last changed by/on | SAP | 20141030 |
| SAP Release Created in |
