Using Buffering When Working with Number Ranges

Let’s stimulate the grey matter with another deep dive into the technical intricacies of our beloved system. Today’s topic: using buffering when working with number ranges.

When working with number ranges in the SAP system, I’m sure very few pay attention to the option of configuring/activating buffering.

See: Buffering

And it's quite an interesting feature. The vendor offers three buffering modes:

• No buffering
• Main Memory Buffering
• Parallel Buffering

Here’s a bit of detail on each.

Using transaction SNUM, I will create a number range:

The range will look as follows:

This buffering type is activated (or more accurately, deactivated) on the Customizing tab of the number range:

When this setting is active, a record is created in the NRIV table that defines the last "issued" number in the range. This type of buffering locks the NRIV table until the next free number is assigned.

See: Buffering

To understand the consequences of an unbuffered number assignment, you have to examine the process in detail:

The structure of the intervals of a number range object is defined in database table NRIV. If a number is taken from an interval, the table line for it must be locked. This lock remains until the application that requested the number is closed, either with a COMMIT WORK or a ROLLBACK. Only then is it specified that the requested number actually has been used or that the process was cancelled. In the latter case the number remains available as before. By locking the table line in NRIV, a chronological number assignment with no gaps can be guaranteed. During the lock period no other numbers can be taken from the interval, which means that a lot of number requests may be collecting that have to be processed one after the other. This can lead to performance problems (see also 678501 Information published on SAP site).Demonstration:

1. For a newly defined number range, I run an ABAP program that calls FM NUMBER_GET_NEXT to request the next free number.
2. The first program run retrieves number 100.
3. I then launch the same program in parallel.
4. At the NUMBER_GET_NEXT call, the second program “hangs” until the first finishes.
5. After the first session ends, the second resumes and receives the next number, 101, and so on.
6. The last issued number is recorded in NRIV.

This buffering type is also activated via the Customizing tab:

When this type is used, a pool of numbers is issued upon request. The size of this pool is defined in the range settings (see No. of Numbers in Buffer). NRIV is not locked, and multiple simultaneous accesses are possible.

Depending on timing and system configuration (e.g., multiple app server instances, each with its own buffer), some numbers may be lost, resulting in gaps. Issued ranges are stored in main memory.

See:Main Memory Buffering

How Main Memory Buffering Works
When a number is requested for the first time from a specific interval after the application server instance is started, instead of these single numbers, a whole package of numbers is immediately loaded from this interval into the main memory. The number of numbers in this package corresponds to the number that was specified as the number of numbers in the buffer on the Customizing tab of transaction SNUM at the time when the number range object was defined. The numbers used, which is defined in table NRIV for this interval, increases by the corresponding number. With this process the line of table NRIV is not locked. Applications that later request numbers from this interval are assigned numbers directly from the associated main memory buffer until the supply of numbers is used up. They do not access table NRIV. If the application server instance is to be started before all numbers in the main memory buffer are used, these numbers are lost from the whole number supply. This results in gaps in the number assignment.

In many cases multiple instances of the application server are running in parallel. If so, each instance is provided with its own number buffer for this interval. Depending on which instance the application is running in, the numbers are pulled from one or the other buffer and can no longer be sorted chronologically.

Demonstration:

1. A new number range is defined, and an ABAP program calls NUMBER_GET_NEXT.
2. The first run retrieves number 100.
3. A pool of 3 numbers (100–102) is generated; 102 is written to NRIV.
4. Parallel runs reserve/use the next numbers from the buffer (101, etc.).
5. After exhausting the first pool, a new pool (103–105) is generated, and 105 is written to NRIV.

Note: You can view the current buffer status in transaction SM56.

See: Administration of the Number Range Buffer

This type is also activated on the Customizing tab:

Parallel buffering is nearly identical to main memory buffering, except that the issued range is stored in the NRIVSHADOW table, not memory.

A key advantage is that reserved numbers can be returned to the buffer if the application fails (e.g., ROLLBACK), allowing reuse and preventing gaps. This also applies to system restarts. More details can be found in vendor documentation (see link above).

See: Parallel Buffering

How Parallel Buffering Works
In principle, parallel buffering works in the same way as main memory buffering, with the difference that the number packages are not stored in the main memory, but are written to the table NRIVSHADOW. In the case of a termination by the application (a ROLLBACK), the number is written back to the buffer and can be used again later, so no numbers are lost from the set in this way. This is also the case if there is a system restart.
For more information, see SAP Note 599157 Information published on SAP site.

Demonstration:

1. I run an ABAP program for a new number range using NUMBER_GET_NEXT.
2. The first number (100) is reserved.
3. A record is created in NRIVSHADOW.
4. On subsequent runs, once the first pool (100–102) is exhausted, a new pool (103–105) is generated, and so on.