SAP Library - Find your answers

Archiving and Reorganization are totally different issues

Archiving is a process when you archive old master/transactional records which are not in use any more from long time. You archive those records keep on some backup device. These records can be displayed, and only Display, can never be reloaded in tables again physically.
This will free up the space in tables from those records which are not in use any more but exist in tables physically.

Reorganization basically removes deleted data from tables. During different transactions you delete some records, which are deleted virtually but not physically. Even Archive process delete those records virtually.
So you run Reorganization to free up the space consumed by deleted records.

This make the difference between the two clear.

Now about reorganization.

It depends on which OS and DB you are using.

If Oracle, SAPDBA is best tool to reorganise.

In addition to above, you can reorganise the whole database, but it takes time depending upon your database. Some times it can be more than a day or you can reorganise a table suggested in Early Watch system.

It all depends on you.

Archiving is a process when you archive old master/transactional records which are not in use any more from long time. You archive those records keep on some backup device. These records can be displayed, and only Display, can never be reloaded in tables again physically.
This will free up the space in tables from those records which are not in use any more but exist in tables physically.

Reorganization basically removes deleted data from tables. During different transactions you delete some records, which are deleted virtually but not physically. Even Archive process delete those records virtually.
So you run Reorganization to free up the space consumed by deleted records.

This make the difference between the two clear.

Now about reorganization.

It depends on which OS and DB you are using.

If Oracle, SAPDBA is best tool to reorganise.

In addition to above, you can reorganise the whole database, but it takes time depending upon your database. Some times it can be more than a day or you can reorganise a table suggested in Early Watch system.

Evaluate ITS Server Speed issues

You have 10 users accessing sap via an ITS server (6.20) and it is soooo slow !!! access via sapgui is fast - any ideas what to look for ??

We tested several options for deploying the SAPGUI :-

Tivoli packages
ITS
Citrix MF XP

Tivoli was already built and in house so all we had to do was create a SAPGUI package and deploy it to the field (3000+ users) - pain in the butt because we had to find out all the users workstation id's for the users in 900+ locations. So far we have deployed 35% and our Go-live is 10/01!

ITS - We had an ITS consultant come in and review our setup. We were able to enhance the performance to some extent (20%). But, that was still unacceptable in comparison to the WINGUI that the users are now accustomed to. In short, we scraped the ITS project because of the problems with latency/performance. Our connection between our test locations and the Data Center was 100MB. The other locations were 10MB.

ITS Tuning in relating to performance of the ITS Server

1. HKEY_LOCAL_MACHINE\Software\SAP\ITS.0\\Programs\SAPjulep\StaticTemplats
To simulate the test, the parameter for Static Templates was changed from 0 to 1

Recommendation : Development system = 0 ; Production System = 1

2. ITS Parameters / Recommended / Ours

a) Worktreads and Sessions
MaxSessions 400 400
MaxWorkThreads 64 40 (can be reduced)
MinWorkThreads 64 40 (can be reduced)

b) Caching
Caching 1 1
CacheSize 16384 16384
FileSize 1048576 1048576
TimeToLive 31 31
StaticTemplates 1 0
CacheInvalidateHour
CacheInvalidateMinute
Staticflows 1
ProductionMode 1 0
StaticBor 1 0

c) Timeout Parameters
TimeoutPercentage 75 75

d) Debugging Parameters
~rfcDebuggingOn 0 0
~rfcTraceOn 0 0
AdminEnabled 0 0
localTraceLevel 0 0
SAPDebuggerDelay

e) Miscellaneous
MinRespSize 32768 32768
MaxRespSize 2097152 2097152
MaxServiceContextSize 20480 20480
~http_compress_level 7 7
~http_use_compression 1 1

2. Load Balancing and Multiple Agates
IncAGates 1 (Do not modify this value.)
MinAGates (Do not modify this value.)
MaxAgates (Do not modify this value.)
IncWorkThreads 1

3. Windows Environment Settings

4. SAP R/3 Parameters
rdisp/gui_auto_logout >= ~userTimeout

3. Check the following internet option settings.
Under "Advanced", make sure both HTTP 1.1 settings are on
Under "Security", "Custom Level" under the point "micellaneous" make sure these are ENABLE:

a) access the data sources across domains
b) Launch programs and files in IFRAME
c) Migrate sub-frames across different domains

4 Verify Compression. These values were changed in the global.srvc file
~http_use_compression 1
To increase the transmission speed and reduce the overall network load we reduce the size of the data sent from the server to the web browser by using compression. The values are 0 to disable compression and 1 to enable compression.

~http_compress_level 7
The compress level can be set between 1- 9 where 1 is the lowest compression level and 9 is the highest. The higher the value set for ~http_compress_level, the better the compression achieved.

The Level 1 achieves the lowest compression level/ fastest procession speed and Level 9 achieves the highest compression level/slowest procession speed

5 ~navigationenabled : Enables / Disables Drag & Relate functionality in the SAP GUI for HTML.
Using Drag & Relate in the SAP GUI for HTML requires a callback from the R/3 System for nearly every request / response cycle. This is an unnecessary overhead for many applications. Hence we disable Drag&Relate by setting this parameter to 0 in the webgui.srvc file on the Agate.

Citrix proved to be just too expensive an option for right now. The SAP 4.6d protocol proved to be quite thin, with the bandwidth requirements tracking only slightly greater than ICA. However, on a number of occasions over the test period, it was observed that SAP could demand a considerable amount of bandwidth for short bursts. This traffic was primarily outbound, targeted at port 4803. However, even with the thin nature of SAP, ICA still provided a bandwidth advantage.

To better understand this and develop conservative figures, a trend analysis of the data was performed. This analysis allowed for a weighted smoothing of the statistics, lessening the impact of the burst type activities. Based on the trend figures, the following observations where made:
SAP showed an overall Kbps trend average of 2.5 Kbps
ICA showed an overall Kbps trend average of 1.7 Kbps

Overall, ICA showed a 30% improvement in bandwidth utilization when compared to SAP, based on the trend analysis of the data. This margin jumps to almost 70% when averages are analyzed.
The maximum SAP burst activity exceeded the maximum ICA burst activity by 70%.
Both SAP and ICA displayed extremely limited network utilization. Over extended periods, ICA displayed consistently low inbound traffic, trending towards .8

If all you have is 10 users, what's wrong with deploying the SAPGUI?

The ITS environment was initially created with very minimal customized configurations (2 servers Dell 2650's). Most ITS performance parameters were accepted as default. We tested over dual T1's (1.5MB) as well as Ethernet 10/100MB max.

For each request by the webserver, a separate request is made to the backend - so what you get is a constant request/send, even though each one is milliseconds adding hundreds of requests through the WGate to AGate to R/3 you can see there just isn't much you can do to improve the speed.

To help diagnose the network or measure network metrics, we used a program from SAP called “NIPING”. Niping is a test program for the network interfaces (NI) layer. It provides connection and performance test with the same mechanisms that the SAPGUI uses. To test the network, the niping tool runs a continuous test. It generate and evaluate a network trace simultaneously from the ITS server and the front end. We ran several niping tests and the following results were produced.

Since the communication between the client and the Web servers is over the HTTP protocol, SAP-ITS also makes the SAP transactions accessible to distant locations via the Internet, enterprise networks, and virtual private networks. These networks are typically very complex and have many users. As the distance between the nodes and the complexity of the network increase, application performance becomes an important issue. The performance of a network depends mainly on two
different factors - the bandwidth (throughput) and the latency (delay).

Bandwidth is the most commonly known factor affecting performance of a network. Network bandwidth defines the amount of data that can be transferred at a given time. Networks with higher bandwidth provide better performance.

The second factor relating to performance of a network is latency. Latency can be defined as the delay in processing data within the network. A network with lower latency performs better than a network with high latency.

In addition to the individual effects on bandwidth and latency within the network, their combination can also affect the quality of communication, hence determining the overall network performance (network speed).

Troubleshooting SAP Performance Issues

Is there a document that will help me troubleshoot system performance? What are the steps on how to troubleshoot?

Troubleshooting is a BIG task of itself, there is no single reference document because there are too many reasons why a system can appear "slow" to the user:

- Different Databases

Every database has its own mechanism for optimizing access, even more, each database has BOOKS on performance optimization. This can start from parameters to database layout to operating system configuration, used filesystems, mount parameters...

- Different Operating System

The same goes for operating systems, a standard Windows 2000 (or 2003) isn´t configured for optimal throughput, there is a LOT to tune, e. g. enable "background process priorities", stop non-needed services, network configurations (TCP window sizes) etc. Also the connection between application and database servers can be an issue

- SAP Itself

Almost for each and every long running program there are optimizations, be it on ABAP layer or on selection layer. Out of my experience, most self developed programs (Z*-programs) are the main issue, because developers program "quick-and-dirty"
doing "select *" and other things.

For e.g.:
If CPU is 100% Busy, what action should be taken to keep CPU idle?

This can't be answered generally. One need to check what process is using so much CPU - then one can start digging deeper. To add info regarding this issue, you may use:

st06->details analysis menu->snapshot analysis->top CPU from there, start to narrow down.

SAP System Performance Issues

My server becomes slow when more users login.
What could be the reason? Is it because of less hardware resource?

Server configuration is 104GB HDD, 2GB Ram.
OS:Win 2003 server.
Database:Oracle.

I manage SAP R/3 4.6C systems on Risc 6000 machines, under Oracle 9.2.

The overall performance problem for me is to know if SAP response time is acceptable ; if not, do this :
- at AIX level : utilities are topas, to catch what's wrong : Disk I/O ? CPU bottleneck ? Too much swap ?
- at Oracle level : tkprof but don't know much about this.
- at SAP level : you can manage SAP memory, Oracle and OS too.

If SAP response time is acceptable, then try this :

Try to have a look at OS response time : ST06 : look at CPU, Memory, Swap, Disk and Lan response time.

Try to have a look at buffer quality : ST02, if many fields are red, investigate each fields dependant parameters.

Try to have a look at DB response time : ST04N, databuffer quality (SGA zone), how much physical reads / logical reads Ratio, wait times, number of user calls, Shared Pool cache hit ratio should be >96%, Sort usage, Redo logging.

I use this kind of procedure to manage my systems.

SAP Tips by: Christophe Rabeau

It depends how much you allocated for SGA (database buffers, shared pool buffer, redo log buffers), how much you allocated for SAP buffers esp. Program buffers and whether the server have any other external processes/programs running.

How many Dialog Work Processes you allocated…I think your problem most likely is you don’t have enough of these Dialog processes. Also maybe users running inefficient reports/programs which are holding the Dialog processes, goto SM50 & check all DIA (Dialog) with status “waiting”…if ALL are “running” then you have wait time (problems !) for other users wanting to process transactions .

To troubleshoot performance, you need these tcode tools:-

ST04 – Database ß in here, check especially for Expensive SQLs (Detail Analysis à SQL Request)

ST02 – SAP buffers

ST06 – OS stats

ST05 – SQL trace

SE30 – Abap runtime analysis

SAP Tips by: Derek Phung

A few step which you can exercise to sort/identify performance issues.

* ST03, ST02, ST04 are the tcode for workload, tuning and DB Performance Monitoring codes.

* ST06 FOR Operation System Monitoring.

** SM51 OR SM50 is process overview which tells you the workprocess sequence. ( Ideally 10-15 process with OLTP and batch process scheduled at peak and off peak times respectively) say 8-17 hrs and 17-8 hrs for Batch Process)

Operation Mode can be configured in RZ04 tcode.

** Check for top CPU in ST06 tcode. CPU should not exceed more than 60% for long time for any process.

** Based of No. of instances ( Application Servers ) should have adequately sized.

** Most resources intensive process have to be scheduled in Batch Process ( in Background in Non Peak Hours )

** Look for unnecessary Jobs Active During Prime Time
** Look for Parameters Set To Your Business Process.
( RZ10, RZ11 ) Check Snote:0124361

** Refer Early Watch Alert Periodically for Overall System Performance.. ( Tcode SDCC )

Is there a document that will help me troubleshoot system performance? What are the steps on how to troubleshoot?

Troubleshooting is a BIG task of itself, there is no single reference document because there are too many reasons why a system can appear "slow" to the user:

- Different Databases

Every database has its own mechanism for optimizing access, even more, each database has BOOKS on performance optimization. This can start from parameters to database layout to operating system configuration, used filesystems, mount parameters...

- Different Operating System

The same goes for operating systems, a standard Windows 2000 (or 2003) isn´t configured for optimal throughput, there is a LOT to tune, e. g. enable "background process priorities", stop non-needed services, network configurations (TCP window sizes) etc. Also the connection between application and database servers can be an issue

- SAP Itself

Almost for each and every long running program there are optimizations, be it on ABAP layer or on selection layer. Out of my experience, most self developed programs (Z*-programs) are the main issue, because developers program "quick-and-dirty"
doing "select *" and other things.

For e.g.:
If CPU is 100% Busy, what action should be taken to keep CPU idle?

This can't be answered generally. One need to check what process is using so much CPU - then one can start digging deeper. To add info regarding this issue, you may use:

st06->details analysis menu->snapshot analysis->top CPU from there, start to narrow down.

My server becomes slow when more users login.
What could be the reason? Is it because of less hardware resource?

Server configuration is 104GB HDD, 2GB Ram.
OS:Win 2003 server.
Database:Oracle.

I manage SAP R/3 4.6C systems on Risc 6000 machines, under Oracle 9.2.

The overall performance problem for me is to know if SAP response time is acceptable ; if not, do this :
- at AIX level : utilities are topas, to catch what's wrong : Disk I/O ? CPU bottleneck ? Too much swap ?
- at Oracle level : tkprof but don't know much about this.
- at SAP level : you can manage SAP memory, Oracle and OS too.

If SAP response time is acceptable, then try this :

Try to have a look at OS response time : ST06 : look at CPU, Memory, Swap, Disk and Lan response time.

Try to have a look at buffer quality : ST02, if many fields are red, investigate each fields dependant parameters.

Try to have a look at DB response time : ST04N, databuffer quality (SGA zone), how much physical reads / logical reads Ratio, wait times, number of user calls, Shared Pool cache hit ratio should be >96%, Sort usage, Redo logging.

I use this kind of procedure to manage my systems.

SAP Tips by: Christophe Rabeau

It depends how much you allocated for SGA (database buffers, shared pool buffer, redo log buffers), how much you allocated for SAP buffers esp. Program buffers and whether the server have any other external processes/programs running.

How many Dialog Work Processes you allocated…I think your problem most likely is you don’t have enough of these Dialog processes. Also maybe users running inefficient reports/programs which are holding the Dialog processes, goto SM50 & check all DIA (Dialog) with status “waiting”…if ALL are “running” then you have wait time (problems !) for other users wanting to process transactions .

To troubleshoot performance, you need these tcode tools:-

ST04 – Database ß in here, check especially for Expensive SQLs (Detail Analysis à SQL Request)

ST02 – SAP buffers

ST06 – OS stats

ST05 – SQL trace

SE30 – Abap runtime analysis

SAP Tips by: Derek Phung

A few step which you can exercise to sort/identify performance issues.

* ST03, ST02, ST04 are the tcode for workload, tuning and DB Performance Monitoring codes.

* ST06 FOR Operation System Monitoring.

** SM51 OR SM50 is process overview which tells you the workprocess sequence. ( Ideally 10-15 process with OLTP and batch process scheduled at peak and off peak times respectively) say 8-17 hrs and 17-8 hrs for Batch Process)

Operation Mode can be configured in RZ04 tcode.

** Check for top CPU in ST06 tcode. CPU should not exceed more than 60% for long time for any process.

** Based of No. of instances ( Application Servers ) should have adequately sized.

** Most resources intensive process have to be scheduled in Batch Process ( in Background in Non Peak Hours )

** Look for unnecessary Jobs Active During Prime Time
** Look for Parameters Set To Your Business Process.
( RZ10, RZ11 ) Check Snote:0124361

** Refer Early Watch Alert Periodically for Overall System Performance.. ( Tcode SDCC )