Performance Issues and Known Errors during the Activation phase

f there are many objects to be activated, the activation can take several hours (for example, if many packages are included).

To analyze why the activation phase is taking so long, you must first examine whether the upgrade is still running or it has hung :

Performance Analysis :

1. Check if log files in (DIR_PUT)/tmp are getting updated.

If the logs are still updated, the activation phase is still running. Several minutes may elapse between individual updates to the file.

2. Check in shadow system, transaction SM50.

At the start of the activation, it analyzes the topological inter-dependencies of the objects to be activated. This operation is only executed with one process and can also take some hours. Many entries are read from tables DD03L and DD04L.

3. After the topological inter-dependency calculation, the individual objects are activated. This step is executed with several processes (if several processes were configured).

The number of processes used are defined by parameters:

1. Parameter "parallel uptime processes" for the strategy "downtime-minimized",
2. Parameter "number of batch processes“ for strategy "resource-minimized" 
3. Parameters can be modified using “SAPup set stdpar". You need to stop SAPup first to change the parameters, then restart SAPup and continue the upgrade.

Performance in this phase mostly due to poor DB performance

For example, the runtime of interdependency analysis is largely determined by accesses to DD03L, DD04L and DD40L. This step may take several hours. If access to these tables are not optimized, runtime will be longer.

Sometimes it’s necessary to involve a DB expert checking the performance problem.

Some Known Errors :

1. Out of Memory Errors like TSV_TNEW_PAGE_ALLOC_FAILED

The error TSV_NEW_PAGE_ALLOC_FAILED means that more memory was requested because the program needed to expand an internal table, but it was not

available.

When Extended Memory is used up, the process will go into PRIV mode as it starts using Heap Memory  (or vise-versa).  No other user will be able to use this wp while it is in PRIV mode.  If there is enough heap for it to finish, you will not see the error TSV_NEW_PAGE_ALLOC_FAILED and the wp will be freed.

To fix this issue you just need to increase the abap heap limits on the system.

The parameters to control these memory areas are:

a)  em/initial_size_MB

     This is the EM area shared by all work process

b)  ztta/roll_extension

     This is the EM area for a single work process

c)  abap/heap_area_total

     This is the heap area shared by all work process

d)  abap/heap_area_dia

     This is the heap area for a single DIA work process

e)  abap/heap_area_nondia

     This is the heap area for a single non DIA work process

Please check the following Notes which describe this issue :

     020527  Runtime error TSV_TNEW_PAGE_ALLOC_FAILED

     1260912 - Memory overflow note: Dump TSV_TNEW_PAGE_ALLOC_FAILED

     1387739 - Out of memory errors during shadow system operation

You can use it as a reference to adjust the parameters abap/heap_area_total, abap/heap_area_dia and abap/heap_area_nondia.

If you need more than 6 GB for heap you may need to reduce the dataset that the transaction is being run on.

A Few Notes that Describe Common Activation Issues :

1. 1387739 - Out of memory errors during shadow system operation
2. 1674812 - Performance improvement for ACT_UPG
3. Oracle: 556764 Upgrade hangs in phase ACT_<REL>
4. DB2: 545281 DB2/390: Performance of DD activation