ABAP Internal Table Memory Size Calculator
A report that works in test and dumps in production with an out-of-memory error is usually a row count problem. This calculator estimates how much memory an internal table takes and gives a safe package size for chunked reads.
Your numbers
Sum of the component lengths. A character field of length 10 uses 20 bytes in a Unicode system.
A planning allowance for administration data and secondary keys, not an exact SAP figure.
For example the result table plus a sorted copy, or a table plus a loop work area snapshot.
Your effective extended plus heap allowance for a dialog or batch process, from your Basis team.
Your results
An approximation for planning. Strings, nested tables and references are stored differently. Verify actual consumption with the ABAP memory inspector or the debugger memory view.
Total memory in MB by row count
Sweeps Rows in the table from 100000 to 10000000, holding your other inputs fixed.
Hitting memory dumps in custom reports?
Optional: send us the dump header and report outline and we will suggest a chunking approach.
Optional. The tool and every export work without this. No spam.
How to use it
Work out the row width from the structure: add the lengths of all components, remembering that character fields take two bytes per character in Unicode systems. Enter the expected production row count, not the test count. Pick the table type, because hashed and sorted tables carry more administration data than a standard table. Set the number of copies you hold at once, since many programs keep both an input and a working copy. Compare the total with the memory limit given by your Basis team.
- Use production volumes, including year-end peaks
- Count every copy, including tables passed by value
- Ask Basis for the effective limit of the work process type
The formulas
Raw size is rows times row width, divided by 1,048,576 to get megabytes. Table size multiplies that by an overhead factor for the table type. Total size multiplies by the number of copies. The safe row count divides the memory limit by the width, overhead and copies. The package size output takes a quarter of the limit, which leaves headroom for the rest of the program, other tables and the stack. The factors are planning allowances; real overhead depends on the release and the key setup.
- Size = rows x width x overhead x copies
- Use SELECT ... PACKAGE SIZE or a cursor to stay under the limit
- Keep headroom for everything else in the session
Fixing a memory problem
When the estimate exceeds the limit, process data in packages: read a block, process it, write results and free the table before the next block. Select only the columns you need, since a narrower row cuts memory directly. Pass big tables by reference, not by value, and avoid building a second sorted copy if a sorted or hashed access path will do. The short dump TSV_TNEW_PAGE_ALLOC_FAILED in ST22 is the classic sign that an internal table outgrew the available memory.
- Use packages or cursors for large reads
- Select fewer columns
- Pass by reference and release tables with FREE or CLEAR
- Read the dump analysis in ST22 for the peak figure
Frequently Asked Questions
Why does a character field take twice the length in bytes?
Unicode systems store characters in two bytes. A field of type C with length 10 therefore uses 20 bytes in memory. Packed numbers, integers and dates use their own sizes, so add each component separately.
Is the overhead factor exact?
No. It is a planning allowance for administration data and secondary keys. Measure real consumption in the debugger or with the memory inspector when the result is close to the limit.
What is PACKAGE SIZE in a SELECT?
It makes the database return rows in blocks of a given size inside a SELECT loop, so you never hold the whole result at once. Process and clear each block before the next iteration.
Where do I find the memory limit?
It comes from profile parameters for extended memory and heap memory, and differs by work process type. Ask your Basis team for the effective values for dialog and for background jobs.
Memory dumps in custom reports are a symptom of design, not just limits. Netray can review your biggest reports and suggest packaging and push-down changes.
Related Tools
ABAP FOR ALL ENTRIES vs SELECT in LOOP Runtime Calculator
Model the database cost of a SELECT inside a LOOP against FOR ALL ENTRIES and see how the gap grows with the driver table size.
SAPABAP Background Job Runtime and Batch Window Calculator
Estimate batch job duration from record volume, per-record time, commit frequency and parallel processing, and test it against your batch window.
SAPSAP Dialog Work Process Sizing Calculator
Turn active users, dialog steps per hour and work process time into the number of dialog work processes needed at peak.
SAPSAP Number Range Exhaustion Calculator
Forecast how many years remain in a number range interval, including growth and numbers lost to buffering after restarts.
More SAP tools
See all- SAP Sales Document Types Reference
- SAP Pricing Procedure Design Worksheet
- SAP Item Category Determination Reference
- SAP Delivery Block Reasons Template
- SAP Credit Management Checklist
- SAP Output Determination Checklist
- SAP Billing Types Reference
- SAP Incompletion Log Checklist
- SAP SD Tables Reference (VBAK, VBAP, LIKP, VBRK and More)