01-04-2007 9:38 PM
Hi,
We recently experienced a production issue where the number range buffer overflowed on mulitple appservers. No dumps, just "internal errors" in the job logs. Tracked back to number range buffer via dev_trace logs.
M *** ERROR => ThNoGet2: buffer overflow [thxxnum.c 1131]
M return number range rc 11
M *** WARNING => ThNoGet: get from object (cli/obj/subobj/range = 510/MATBELEG / /03) returned rc 11
where the 'obj' varies based on the buffered range looking for room.
We are running 46B SP56 with a 46D kernel at patchlevel 2234.
Number buffer had previously been extended to 1000 entries.
However, RF_BELEG occupies 88% of the entries eventhough it "appears" that the number range for RF_BELEG is not buffered (for legal reasons - sequentiality). The RF_BELEG number in the buffer (observed via ST02>detailed analysis) indicates a "curr from" number from BUKRS and a "curr to" number of 0 (indicating a single value?).
We've extended the buffer to 1500 entries as a stop-fix
SNRO settings for RF_BELEG are:
Object RF_BELEG No. range object has intervals
Short text Accounting document
Long text Number Ranges For Accounting Documents
Subobject data element BUKRS
To-year flag
Number length domain CHAR10
No interval rolling
Number range transaction FBN1
Warning % 10.0
Number ranges not buffered
Questions: Why does RF_BELEG even show up in the no. range buffer if it's not buffered? Is this normal behavior or a bug/config error?
Why so many entries? Are entries not cleared/aged out? Do these entries represent active transactions?
Any insight or lead to investigate would be much appreciated.
Regards,
Ken Johnson
.
01-05-2007 8:36 AM
Hi Ken!
I'm not sure, if you are looking already at the correct place. I also had a look at ST02 -> detailed analysis -> Number ranges and found a lot of RF_BELEG entries, also a lot of external ranges. External ranges can't be buffered at all, so this list must show something else.
When you press 'statistics' in this view, there will be a display of several current and max values. I guess it's not an issue of max entities or indices, but buffer sizes [kb]. If you have some (other than RF_BELEG, e.g. like MATBELEG from your example) indices with buffering in RAM with to big numbers, it might come to a problem. Highest amount of numbers we used were about 5000 (per application server), that should last for some hours even with heavy workload. But most are defined with 10 - 100 entries, that's enough to avoid the DB for every step / every minute.
I don't see a max value for buffer-size, but it sounds more promising to search in this direction (for you!).
Regards,
Christian
01-04-2007 9:53 PM
Have you checked for SAP notes? There seem to be a number of them. You can start with 47653.
rob
01-04-2007 10:16 PM
Tons of notes - but all seem to apply to how to get numbers into the buffer rather than how the buffer works.
None I found would explain why an unbuffered number range shows up there at all.
47653 was one of the first up on my screen.
Thanks,
Ken
01-04-2007 10:20 PM
Then try just looking for consulting notes. Maybe 307437.
Rob
01-05-2007 8:36 AM
Hi Ken!
I'm not sure, if you are looking already at the correct place. I also had a look at ST02 -> detailed analysis -> Number ranges and found a lot of RF_BELEG entries, also a lot of external ranges. External ranges can't be buffered at all, so this list must show something else.
When you press 'statistics' in this view, there will be a display of several current and max values. I guess it's not an issue of max entities or indices, but buffer sizes [kb]. If you have some (other than RF_BELEG, e.g. like MATBELEG from your example) indices with buffering in RAM with to big numbers, it might come to a problem. Highest amount of numbers we used were about 5000 (per application server), that should last for some hours even with heavy workload. But most are defined with 10 - 100 entries, that's enough to avoid the DB for every step / every minute.
I don't see a max value for buffer-size, but it sounds more promising to search in this direction (for you!).
Regards,
Christian
01-05-2007 4:36 PM
I agree with Christian that the issue is not with the size of interval in buffer - I think the issue is with total number of ranges in your system which are buffered...
I believe standard setting in SAP is to allocate memory for 1000 number range intervals.
Check SM56 - it will show you your settings, I would check the following 2... I think in your case current number is close to max. number
Max. no. of entries 1,000
Current no. of entries 40
......
nobuf/max_no_buffer_entries
Determines the maximum number of entries in the buffer (standard value: 1000).
The number range buffer cannot be extended dynamically at runtime. When a server is started up, this profile parameter determines how many number range intervals the buffer has space for.
......
01-05-2007 4:54 PM
Right, the number of buffer entries is the problem rather than quantity of numbers being buffered for any one range. We've increased the size of the buffer to 1500 entries since we maxed out the 1000 entry buffer.
The question still though is why RF_BELEG entries even show up in the buffer - if ST02 can be believed. If it's not buffered then why is it in there taking up so much space?
Since others are seeing the same thing I'm assuming that this is by design but it seems a poor one.
I'll check consulting notes as recommended and research the white papers.
Regards,
Ken
01-08-2007 12:36 PM
Ken,
is your object RV_BELEG buffered, if so - it may cause buffering of RF_BELEG (if it's set to external in FI, so the number actually is determined by RV_BELEG for invoice).
It's just a guess though.
BTW, if you reset buffers, does RF_BELEG appear after that again ?
01-09-2007 6:12 PM
Siarhei
Interesting consideration. RV_BELEG is not buffered either but <u>it</u> does not show in the buffer( as displayed via ST02).
RK_BELEG and RE_BELEG are buffered though....
Resetting buffers and/or restarting SAP has no lasting effect on the buffer. It clears out all the RF_BELEG entries but they start accumulating immediately after that though.
Ken
01-11-2007 1:45 PM
Ken,
It looks weird.
I would check which ranges (intervals) are involved to determine which FI docs trigger this buffering and then if these FI docs are not directly posted in FI but flow from any SD document/activity which in fact determine the number -> check if corresponding number range is buffered.
In other words, right after buffer refresh - if you post any FI doc (directly create via FB01) I doubt it's going to fill buffer, if your RV_BELEG is not buffered -> I think even invoice posting (SD invoice) will not cause buffer usage... but if you determine which activity causes buffering - probably you'll know which doc.type(=> number range object) causes buffering of RF_BELEG.
I really can't think of any other reason for appearing RF_BELEG in ST02 if your RF_BELEG object is not bufferd other than it's driven by buffering of "source" document range which actually determines the number of your FI doc.
01-11-2007 4:49 PM
Siarhei,
You're heading in the right direction. Per SAP from the note I opened: RF_BELEG accounting <u>numbers</u> are buffered even if the number-range is not. The accounting numbers are associated with company codes and are year dependent. For performance reasons they are kept close to hand.
By extension then, each appserver will have identical values for RF_BELEG entries in the number range buffer and until the buffers are reset and the the books closed on the previous year, there will be mutiple entries (for multiple years) of each company code. We have nearly 300 company codes.
Pays to keep track of % utilized for the buffer via SM56/ST02 especially towards year end. Clearing the buffer will temporarily make space at the expense of lost ranges and some performance hit as the buffer is refilled.
Thanks, everyone, for your time and advice.
Ken
11-06-2008 4:46 PM
Hi Ken,
Your message has been a GREAT HELP for me. I have experienced the same problem and I was going crazy about RF_BELEG been buffered when not supposed to do so.
I can't understand why SAP doesn't explain the behaviour of RF_BELEG in the tons of notes I found.
Thanks a lot.
Francisco