Netweaver Archives » Page 11 of 12 » Musings of an IT Implementor

Analysing SAP Java Memory Usage in Windows

Running SAP systems on a Windows operating system provided me with some difficulties when it came to understanding memory usage. I was used to Unix based systems and using terms like “swap file”, “virtual memory” etc.
Hopefully this article will help you diagnose SAP Java system memory issues on Windows, especially “Out Of Memory” (OOM) error situations in the SAP Java stack.
It has been written based on Windows Server 2003 64bit with SAP Netweaver 7.0 (2004s) and Oracle 10g (10.2.x).

REFERENCES:

Understanding memory usage in Windows 2000.
SAP Note 723909 v33 – Java VM Settings For J2EE 6.40/7.0
SAP Note 879377 – Adjusting SDM Java Memory Usage
SAP Note 716604 v56 – Sun J2SE Recommended Options
SAP Note 313347 – Windows Editions Memory Support
Netweaver 7.0 SR2 Java Windows Oracle Installation Guide.

WINDOWS MEMORY TERMINOLOGY

Before we go into the memory details of an SAP system on Windows, it is useful to understand the memory terminology of the Windows operating system.
This is useful if you come from a UNIX background.

RAM – Random Access Memory, physical installed memory in the server.

Page File – An area of hard disk (or other storage medium) used for temporary storage of memory blocks. Generally this should be manually set according to the installation guide for the SAP system.

Virtual Memory – The logical memory accessed by user space program (calculator or any other app) this is roughly the summary of physical RAM plus page file size.

Kernel Memory – This is the area of virtual memory and RAM used by the operating system for device driver memory (non-user space programs).

Page Faults – When a process tries to access a portion of virtual memory that has been swapped to disk, a page fault occurs and the swapped portion is read back into RAM from disk potentially displacing an existing memory page).

Page – A block of memory usually around 4K in size.

DETERMINE OS MEMORY

We need to first determine how much memory is actively being used at the operating system level and how much memory is available to us.
On the Windows server, open Windows Task Manager and click on the “Performance” tab:

This will show the current memory usage of the entire server.
Ignore the line graphs and histograms as the bottom section of the pane is more important.
The following sections are described:

Physical Memory – Total Total amount of RAM installed in server.
Physical Memory – Available RAM available for CPU processes.
Physical Memory – System Cache RAM being used by the file cache.
Commit Charge – Total Size of virtual memory in use.
Commit Charge – Limit Max amount of virtual memory.
Commit Charge – Peak Virtual memory used high water mark.
Kernel Memory – Total Paged and non-paged mem used by the operating system’s kernel e.g. device drivers etc.
Kernel Memory – Paged Virtual memory set aside for the kernel.
Kernel Memory – Nonpaged Physical RAM set aside for the kernel.

The most important to watch when measuring memory usage of an SAP system are the following:

Commit Charge – Peak: This is the high water mark for memory usage on the server. If this is close to the maximum available virtual memory (Commit Charge – Total) then you could be suffering performance issues caused by excessive paging to/from hard disk.

Physical Memory – System Cache: This is the file system cache that stores data accessed from the hard disk in RAM for more efficient data retrieval.
This value is maintained by the operating system but can be influenced by setting the performance options in “My Computer -> Properties -> Advanced -> Settings (Performance) -> Advanced” shown below:

Which is also related to (or rather overridden by) the setting of “Maximize data throughput for network applications” in the “File and Printer Sharing for Microsoft Networks” of the local network connections in control panel:

MANAGE OS MEMORY

Before you try and tune the memory in the SAP system, you should first explore all avenues of optimising the amount of RAM available in the operating system.
We can see that there are three factors that affect the amount of RAM available for use with programs:

1, Other programs running.
2, The file system cache.
3, Device drivers loaded in the system (kernel).

Reducing the number of running programs and services is a good way of freeing up memory.
The amount of memory used by a specific program or service can be seen in Task Manager on the “Processes” tab:

Only the needed applications for the application and its management should be running.
The svhost.exe binary signifies services that are visible in the services applet in the Administrative Tools applet in Windows Control Panel.
Disabling redundant services will improve available RAM.

You should seek to reduce the file system cache as much as possible.
Since the SAP system is not a file server, any file system level buffering of data is only wasting resources. This is especially true for the Oracle database which buffers read data in memory anyway, which is then potentially buffered again in SAP.

You can reduce the system cache by setting the “Maximize throughput for network applications” as discussed in the previous section. This should be done on all servers within the SAP landscape (apart from specific cache servers, subject to SAP recommendations).
This is generally recommended by SAP in the installation guide for the Netweaver system.

Lastly, disable any redundant devices from the device manager.
These devices require kernel memory, some of which is taken directly from RAM.
You can see the memory ranges allocated to devices in the device manager accessed from the “Computer Management -> Device Manager” option from the Administrative Tools applet in Windows Control Panel.
Simply select “View -> Resources by Connection” in the Computer Management panel:

Expand the “Memory” item from the tree on the right and the devices will be listed with their memory address ranges:

The address ranges are in hexadecimal notation and in the form [RegionLetter][HEX Values] e.g. A0000000 – AFFFFFFF. The value in hex is bytes and is calculated as follows: FFFFFFF = 4294967295 bytes in decimal. Divide the decimal by 1024 accordingly to get a value in Kilobytes, Megabytes or Gigabytes.

Devices which are not required can be disabled (right click and choose “Disable”).

DETERMINE SAP JAVA SYSTEM MEMORY

The memory allocated to an SAP system comprises of three parts:

1, The Database instance memory.
If the database is on the same server as the SAP system, then some of the operating system memory will be taken up by the database itself.

2, The ABAP system memory.
If the SAP system is a dual stack system with an ABAP instance also on the same server then some memory will also be taken up by the ABAP instance.

3, The Java stack memory.
The Java stack comprises of mainly three (sometimes four) running Java Runtime Environments (Server, Dispatcher & SDM).

The main memory of the server must be divvied up between these 3 main components of the SAP system.

Since we are concentrating on the Java stack only, we will assume that SAP recommendations were followed correctly for the setup of the database and ABAP components.

Using Windows Task Manager it is possible to determine the amount of memory in use by the SAP Java system.
The jlaunch.exe processes represent the Java Runtime Environments of the Java stack and therefore the memory usage for each process equates to the current virtual memory usage for the SAP processes:

In the Windows Task Manager you must change the view to be able to see the process ID of a process:

Ensure that you select the following columns:

PID,
Memory Usage,
Peak Memory Usage,
Page Faults
Virtual Memory Size,
Paged Pool,
Non-paged Pool

With these columns selected, we can get a far better overview of the memory usage for the SAP components:

You can now see that the actual virtual memory usage (VM Size) of the PID 5144 (what we think is the SAP Java server process) is ~1.7GB in size (1,678,188 K).

The summary of the VM Size column should roughly add up to the size of the “Commit Charge – Total” value displayed on the “Performance Tab”.

Generally you can guess that the jlaunch processes with the highest memory usage will be the SAP Java server processes (since they have the largest memory settings out of the box), followed by the dispatcher and finally the SDM (with the smallest default settings).

For confirmation, it is possible to find the exact process id using the jcmon.exe program.
Use option 30 (Shared Memory Menu), then select option 2 (Display Process Data):

The running components will be displayed and we can confirm that PID 5144 is in fact the server0 process:

DETERMINE SET MEMORY VALUES

We have determined what virtual memory the SAP Java processes are actually using but we need to see the configuration settings of the Java processes so we know what to expect at startup and maximum use.

There are a number of different areas of memory for a Java Runtime Environment.
The following is a very brief overview:

Heap Size The total amount of memory stack available to a Java Runtime Environment process (excludes the resident memory for the binary). The minimum heap memory is set using parameter “–Xms”.

New Size Also known as the “young generation”, is the amount of heap memory allocated by default for new java classes created within the JRE. The new size is set using parameter “–NewSize”.

Perm Size Also know as the “old generation” or “tenured generation” is the amount of heap memory allocated by default for java classes that have survived a number of garbage collections and are deemed “permanent” in the JRE. The perm size is set using parameter “–PermSize”.

Any java classes that are no longer referenced are cleared from memory during the garbage collection cycles which are either time-triggered or based on a percentage of free heap size.

The sections of heap memory and the heap memory total size itself can be set within bounds using the “-MaxXXXXSize” arguments or “-Xmx” (for the heap itself) to the JRE.
The JRE will not break these bounds.
If the amount of Heap allocated is not enough for the running JRE it will constantly try to garbage collect more aggressively. This will be seen in the developer trace files e.g. dev_server0, dev_dispatcher and dev_sdm.

If the JRE is still unable to reference enough memory, then a Java.Lang.OutOfMemoryError will be thrown. If this is visible in the dev_server0 trace file, then this is the JRE that threw the error and was suffering the problem (more than likely).

If no maximum heap size is set using the –Xmx parameter, then the JRE will attempt to expand the heap dynamically when required (it may not shrink back).
If the Windows virtual memory is exhausted, then the JRE will eventually throw a Java.Lang.OutOfMemoryError and Windows may throw its own error.

Now we understand roughly how the JRE memory is utilised, we can see the settings for the respective SAP JREs for the server, dispatcher and SDM.

The JRE server0 memory allocation can be seen either through ConfigTool by selecting “Cluster-Data -> Instance ID XXXXXX” -> Server” and checking the parameters on the right hand side:

Or by looking in the jlaunch process trace file:

This concludes the analysis of memory usage for the Java stack.
Using this information you should now be able to determine if this meets the recommendations by SAP.

SAP JAVA STACK MEMORY RECOMMENDATIONS

During the creation of this article a number of SAP notes became of significance.
Generally SAP try to recommend certain settings during installation of the SAP software, and then at a later date, they will release a note that details changes to the installation settings.

The base install of SAP Netweaver 7.0 Java (SR3) seems to install with the following settings:

Server:
-Xms 1024m
-NewSize 171m
-MaxNewSize 171m
-PermSize 256m
-MaxPermSize 256m

Dispatcher:
-Xms 170m
-NewSize 57m
-MaxNewSize 57m

SDM:
-Xms 256m

The installation documentation specifically states that the sizing of the Windows page file is essential for correct operation of the SAP system.
The document states in the section “3.1.2 Requirements Checklist for a Central System”:

“Minimum RAM:
1.5 GB
To check RAM, in the Windows Explorer choose Help About Windows.
Paging File Size: 1 times RAM plus 8 GB”

This would infer that on a system with 10GB of RAM, the page file should be 18GB in size. This would give a total virtual memory size of 28GB.

According to note 723909, SAP’s latest recommendations for sizing the JRE memory is as follows:

“For 32 bit platforms we recommend to start the server nodes with 1GB
whereby the initial and the maximal heap size should be equal: -Xmx1024m
-Xms1024m
Higher values may cause troubles, for example see notes 736462 and 664607
about Windows DLLs preventing big java heap.
We recommend using additional server nodes instead of huge heaps.

For 64 bit platforms (that means not only your OS but also your JDK
supports 64 bit) we recommend using 2GB: -Xmx2048m -Xms2048m
Take into account while planning your productive landscape: for NW 7.0
(04s) there is a general recommendation to use 64bit systems, see note
996600.
2.2 For dispatcher nodes it’s sufficient to set the heap size to 171m on 32
bit and to 256m on 64 bit platforms. There is no need to apply the
parameters mentioned under 4-9 below.
Default size of the young generation (one third of the heap) is ok for
dispatchers.
If the instance contains more than three server nodes we recommend to add
50MB of dispatcher heap for each additional server node.
2.3 The max heap size (plus max perm size) of all Java server nodes
must fit completely into the physical memory in order to avoid heavy
paging on OS level. You must also consider the space needed for OS
and other processes.
For each JavaVM on the server, all Java memory must fit completely
into physical memory (no paging)!
Therefore the rule of thumb for number of server nodes for SUN and HP
JavaVM with 1 GB Heap each will be
#ServerNodes = (AvailableMemory / 1.5 GB)
and factor 2.5 should be used instead of 1.5 for 64 bit with 2GB heap size.”

The additional note 716604 recommends some specific settings for the SUN JVM:

“For 6.40/7.00:
For the heapsize and the size of the new generation please take care of the
recommendations of note 723909.
For Windows (ia64 and x86 (64Bit)) and Linux/ia64 (Itanium) platforms set
the stack size to at least 2MB for each serverID, the dispatcher and the
Java based tools:
-Xss2m
Additionally, increase the stack size of the JIT compiler threads at least
on the server nodes of the J2EE Engine to 4MB on these platforms with
following parameter (effective on Windows starting with 1.4.2_17 b12 resp.
1.4.2_18):
-XX:CompilerThreadStackSize=4096”

Any modifications to the Java stack should be proven in the DEV and QA environments before application to production.

Basic Performance Tuning Guide – SAP NetWeaver 7.0 – Part II – Reading Single Record Statistics

This is Part II. You may like to see Part I.

In Part I, we showed you how to trace an ABAP program using STAD to show the single record statistics of the response times for a transaction/program.
In this part, we will go through and decipher the statistics to help you decide where the problem may lie in your slow performing program.

Following Part I, we saw the STAD screen output. Below is a snapshot of the right hand side of the screen showing the “standard” view fields:

The “Response time (ms)” field shows the total response time for the dialog step (or summary of steps if you have chosen not to expand the left tree).

As a reminder, SAP says (https://help.sap.com/saphelp_nw70ehp1/helpdata/en/21/2c8f38c7215428e10000009b38f8cf/content.htm
):
“Response time = wait time + execution time
where: execution time =
Generation time during the run
+ Load time for programs, screens, and graphical user interfaces
+ Roll times for rolling in the work data
+ ABAP processing time
+ Database time
+ Enqueue time for logical SAP lock processes
+ CPIC/RFC time
+ Roll wait time (excluding task types RFC/CPIC/ALE).“

So if we take a look at our initial screen of values, the example below shows that the “DB req time (ms)” is one of the larger values (4929):

The total database request time (time taken for database work to be done for this step) is more than 92% of the total response time for the step.
If the database time IS NOT a significant percentage of total response time, then you should check the other parts that make up the total response time, for clues.

At this point, it’s better to change the screen columns so that you can see all the timings.
The best view is the “Time Analysis” view. Switch views by clicking the “Sel. fields” button:

Click “Time Analysis“:

You will now see more timing fields

The fields highlighted are responsible for the total response time calculation.

In our example, TOTAL RESPONSE TIME = Wait Time + DB Req Time + Processing Time + Load Time + Generating Time + Roll In Time + Roll Wait Time + Enqueue Time.
=> 5330 = 0 + 4929 + 122 + 17 + 0 + 262 + 0
(5330 / 1000 = 5.3 seconds total response time)

You should check each of the fields, looking for disproportionate response times.

The “Wait time (ms)” indicates the amount of time the dialog step was waiting to be processed by a dialog work process. High values indicate that the overall system performance is degraded. Maybe a lack of memory, CPU or I/O performance at the O/S layer could be causing issues. Check the dispatcher queue.

The “Time in WPs (ms)” indicates the time that the dialog step was being actively serviced by a work process and not by any other type of process (BTC, UPD, UPD2 etc). Check “SM51 -> Goto -> Server Name -> Information -> Queue Information” and SM66 to see how busy the system is.

The “Processing time (ms)” indicates the amount of time the individual components spent processing (working) and not idle or sleeping or waiting. Check SM50 and SM66 to see how busy the system is.
Use ST06 (O/S monitor) to check CPU usage and system load.

The “Load time (ms)” indicates the amount of time taken to load the program code into memory buffers.
A problem here could indicate the program buffer is not large enough (see ST02). You should check the CPU time if the load time value is large.

Values for “Generating time (ms)” show the time spent compiling the ABAP source code. You will see a value here if the code has not already been compiled through SGEN. Any large values here for programs already generated could mean a problem in the database with the code storage tables.

Large values for “Roll (i+w) time (ms)” indicates that the Roll-In and Roll-Wait times are being affected.

Roll-In is the process of moving the users session context into the work process so that it can be used to execute the dialog step. High values could indicate that the roll buffer is too small (see ST02) or that the user has a very large set of roles and profiles and is consuming too much memory.

Values for “Enqueue time (ms)” show the time waited for a logical database lock to be performed.
A high value here could indicate excessive contention (someone else doing the same work) in the SAP system or the underlying database. Maybe check SM13.

If we look at a CPU time example, a high value here would indicate a large amount of overall processing causing the WP to use more CPU.
Maybe a rogue loop, or a large internal table operation.
The example below shows a high CPU time for a background job performing a lot of RFC calls.
Notice how the processing time (just off the screen shot, sorry) has increased too (some component has to do the work):

Could be that a lot of data/work was transfered by RFC call.

Summary:
If you see high database time in your analysis, Part III will show you how to perform an SQL trace to see what the database is doing for so long.

If you have high CPU/processing time, then in Part IV you will be shown how to find where exactly in the ABAP program is causing the most response time.

SAP RFC Gateway Error 10060

Yesterday I spent the majority of the morning tracking a problem in the SAP ERP system.

It has been occurring for a while but I have had far more important issues. Finally I got round to looking at it.

In hosta SM21 system log, the gateway process (RD) had registered a network connect error (Q0I) “Operating system call connect failed (error no. 10060)”:

The architecture of the SAP systems involved in the landscape looks like the following diagram, which shows an SAP ERP single ABAP stack (hosta), which is connected to an SAP Enterprise Portal system which is clustered (hostb & hostc):

Looking in the gateway error log (TX: SMGW), I saw the network interface (Ni) timeout error when looking up the hostname for IP address 192.168.1.1:

The business process involved means that an RFC connection is established from the EP server processes (hostb) to the ERP gateway process (hosta).
As you can see in the architecture diagram, the IP 192.168.1.1 is the private IP address of the hostb server in the EP cluster.
The private IP address is only used as a heartbeat address as part of the Microsoft Cluster service.
So the question was, why was the SAP ERP gateway process receiving inbound connections from hostb via the private IP address?

The method of analysis involves understanding how the IP to hostname lookups are performed on the Windows servers:

First, if you open a command prompt and use NSLOOKUP to check the hostname (“C:> nslookup hostb”) it will return the hostname from the Name Service configured for the Windows Server. Usually this is in the order of hosts file first, then DNS. It performs the lookup using the appropriate network interface according to the network routings (“C:> route print”).
In our example, the nslookup correctly returned the public IP address.

Second, you can issue a PING of hostb from hostb (itself) using “C:> ping hostb”.
When using PING, it sends a network packet using the appropriate network interface according to the network routings (“C:> route print”). Since we are pinging ourselves, it will use the first network interface in bind order of the Windows network connections.
In our case, it was pinging the *private* IP address.
According to Microsoft, the PING command in Windows uses gethostbyname() to find the IP address for the destination to be ping’d(https://support.microsoft.com/kb/822713).

So we have established that the private IP address is seen when we ping our own servername on hostb, why does this mean that the private IP is seen as the client in a SAP RFC gateway connection?
Well, in the same way that PING uses gethostbyname(), the RFC connection that is established through jlaunch.exe (host of the JAVA stack server processes) also uses gethostbyname(). Of course, we know what IP address a gethostbyname() call returns, as this is used in the PING command .

(findstr /M gethostbyname jlaunch.exe)

So, the RFC connection performed by the JAVA stack is created from the jlanuch.exe binary, which uses gethostbyname() during the bind() call, which returns the private IP.
The RFC connection is established and part of the RFC connection process the jlanuch.exe process passes it’s calling IP address. Which is the private IP address.
The ERP system gateway at the other end of the connection receives the incoming connection and notes that it is coming from 192.168.1.1. Should the ERP system on hosta wish to make an RFC callback (https://help.sap.com/saphelp_nw04/helpdata/en/22/042a77488911d189490000e829fbbd/content.htm)
(https://help.sap.com/saphelp_nw04/helpdata/en/22/042a91488911d189490000e829fbbd/content.htm), it has no chance of returning the call to the private IP address on hostb. This is where we get the error “NiHsLGetHostByName failed”.

So how do we resolve the problem?
We could code the lookup into the hosts file (172.x.x.2 hostb) on hostb, but this might cause other issues.
A quick look into the SAP documentation for installing Netweaver 7.0 SR3 in a Microsoft Clustered system reveals that a simple step was missed during installation on hostb.
In the document it states “The card of the public network must be displayed before that of the private network. If necessary, change the order in which the cards are listed by using the Move Up and Move Down arrows”.

So I check the binding orders on hostb in Control Panel -> Network Connections -> Advanced Settings:

They are the wrong way around. The “Cluster Heartbeat” (Private IP) should be beneath the Public IP (“Local Area Connection” in our example).
The Microsoft article here (https://support.microsoft.com/kb/894564) lists the process to change it and provides alternative solutions (I would recommend to follow the SAP document).

Changing the binding order on Windows Server 2003 does not require a reboot, but the change will not be effective until a reboot is performed.

Detecting & Reducing Space Used For SAP Business Workplace Documents

Within the SAP Netweaver 7.0 system is a complete e-mail tool that allows users to send/receive electronic documents.
These documents are visible in the SAP Business Workplace (TX: SBWP) inbox/outbox and also in the SAP Connect transmission requests (TX: SOST).

As time goes by and users accumulate documents in their inbox and internal/external mails get sent through SAPConnect, space in the database will be used.

SAP Note: 966854 recommends running RSBCS_REORG to clear down these documents and free the space.
Unfortunately it doesn’t tell you how much space is taken up and how much you could get back.

Using the details in SAP Note: 706478 it is possible to check some of the tables at the database level.
Once again, the note doesn’t list all tables involved.
Instead, running the RSBCS_REORG report in “Test” mode reveals the full extent of the tables where records will be deleted:

So using this information, the following constructed SQL query will return the current size of the database segments (Oracle) for the selected tables (FOR ECC 6.0 based systems):

SELECT * FROM ( select sum(s.bytes)/1024/1024 size_mb , s.segment_name, s.segment_type, s.segment_name table_name, t.ddtext descr from dba_segments s, sapsr3.dd02t t where s.segment_name in ('BCST_BOR', 'BCST_CAM', 'BCST_RE', 'BCST_SR', 'SOC3', 'SOCS', 'SOCX', 'SOER', 'SOES', 'SOFM', 'SOOD', 'SOOS', 'SOST') and s.segment_name = t.tabname and ddlanguage='E' group by s.segment_name, s.segment_type, s.segment_name, t.ddtext union all select sum(s.bytes)/1024/1024 size_mb , s.segment_name, s.segment_type, i.table_name, t.ddtext descr from dba_segments s, sapsr3.dd02t t, dba_indexes i where i.table_name in ( 'BCST_BOR', 'BCST_CAM', 'BCST_RE', 'BCST_SR', 'SOC3', 'SOCS', 'SOCX', 'SOER', 'SOES', 'SOFM', 'SOOD', 'SOOS', 'SOST') and i.table_name = t.tabname and i.index_name = s.segment_name and ddlanguage='E' group by s.segment_name, s.segment_type, i.table_name, t.ddtext ) t1 ORDER BY t1.table_name ASC, t1.segment_type DESC;

For R/3 4.7 you can use the query below (removes the table and index descriptions):

SELECT * FROM ( select sum(s.bytes)/1024/1024 size_mb , s.segment_name, s.segment_type, s.segment_name table_name from dba_segments s where s.segment_name in ('BCST_BOR', 'BCST_CAM', 'BCST_RE', 'BCST_SR', 'SOC3', 'SOCS', 'SOCX', 'SOER', 'SOES', 'SOFM', 'SOOD', 'SOOS', 'SOST') group by s.segment_name, s.segment_type, s.segment_name union all select sum(s.bytes)/1024/1024 size_mb , s.segment_name, s.segment_type, i.table_name from dba_segments s, dba_indexes i where i.table_name in ( 'BCST_BOR', 'BCST_CAM', 'BCST_RE', 'BCST_SR', 'SOC3', 'SOCS', 'SOCX', 'SOER', 'SOES', 'SOFM', 'SOOD', 'SOOS', 'SOST') and i.index_name = s.segment_name group by s.segment_name, s.segment_type, i.table_name ) t1 ORDER BY t1.table_name ASC, t1.segment_type DESC;

You may just be able to see that the SOC3 table is using ~7GB of space with an index of 144MB and a lob object of 64KB.

Now if you run the RSBCS_REORG report using “Test” mode, with the settings to remove the documents that are >60 days old, then you can estimate what percentage of records will be removed from table SOC3 and therefore estimate the space saving.

As a rule of thumb, it may be wise to remove the documents from users who have left the company.
Generally the SAP account will be locked, so you can pull the account names using the following SQL query then add them into the RSBCS_REORG report “User” field:

SELECT DISTINCT bname FROM sapsr3.usr02 WHERE uflag =128;

NOTE: When running RSBCS_REORG, it will not remove assigned workflows from the “Workflow” folder (or sub-folders).

You may also consider running the report for the user who runs the SAPConnect background job step. As this user will have the majority of occupied space.

Once you’ve deleted the records that are not required, the space in the database tables will be freed.
However, this will not release the space to the rest of the database, only the tables from where the records were deleted.
Stay tuned for my up-coming post on how to free the table segment space after you’ve removed thousands of records from the Oracle database.

Useful SAP Reports

It’s always good to have the exact report handy, just incase the transaction is not in your SAP role:

BTCTRNS1 – Suspend All Jobs For an Upgrade
BTCTRNS2 – Un-Suspend All Jobs For an Upgrade
RDBMIDOC – Create IDocs from change pointers and send.
RBDMOIND – Status conversion of successfull IDoc communication.
RSALDBRG – Reorganise CCMS Alert Database
RSALERTTEST – Test alerts
RSAVGL00 – Table adjustment across clients
RSINCL00 – Extended program list
RSBDCSUB – Release batch-input sessions automaticly
RSCPINST – Check language installation config.

RSCSAUTH – Authorisations assigned to ABAP reports.

RSTXSCRP – Transport SAPscript files across systems
RGUGBR00 – Substitution/Validation utility
RSBCSRE03 – Clean old SOST records (send deliveries)
RSBDCOS0 – Execute Shell command (non-interactive).
RSBTCDEL – Clean the old background job records
RSDBCREO – Clean batch input session log
RSEIDOCA – Active IDoc Monitoring
RSORAPATCHINFO – Oracle patch level.
RSPARAM – Display all instance parameters
RSPO0041 – Removing old spooling objects
RSSNAPDL – Clean the old ABAP error dumps
RSSLG200 – Remove expired application logs (SLG1).
RSSLGK90 – Delete application logs created before the specified date.
RSSOREST – Clean old SOST records (send deliveries)
RSPO1041 – Cross-Client Spool Request Cleanup.
RSPOR_SETUP – BW / BI Configuration Consistency Check
RSTXICON – List all icons in the system
RSTRFCEG – Consistency check of outbound queues (RFC/trfc/qrfc).
RSUSR002 – Roles by complex selection (new)
RSUSR003 – Check the passwords of users SAP* and DDIC in all clients
RSUSR006 – List users last login
RSUSR020 – Profiles by complex selection
RSUSR050 – Compare users
RSUSR070 – Roles by complex selection
RSUSR200 – List users by login date.
RSWUWFML2 – Delivers work items via users e-mail address.
RSWWWIDE – Remove work items and related sub-items.
RSXMB_CANCEL_MESSAGES – Cancel messages in error.
RSXMB_CHECK_MSG_QUEUE – Check messages in queue.
RSXMB_SHOW_STATUS – Show statuses of XI messages in the persistence layer.
SSF_ALERT_CERTEXPIRE – Certificate expiry check.