ERP 6.0 EHP5 installation - MAIN_SHDRUN/ACT_UPG working for 12 days

[Former Member]

Dear All,

I checked many posts on this forum regarding long MAIN_SHDRUN/ACT_UPG process (Activates ABAP Dictionary Customer Objects), but people talk about 2 days, maybe 4 days... In my case on Windows 2008 x64 with 16GB of RAM and 4 CPUs it has been running for 12 days... I checked log and tmp directory. In logs there is nothing newer than:

ALOG702 - 12 days old file with last lines:

### Phase ACT_UPG:
ALL                  ALL.ALL d 0000 20111012193616              er1adm       SAPSVR 2011101219361600787c
ALL                  ER1.ALL a 0000 20111012193649              er1adm       SAPSVR 20111012193634007e64
ALL                  ER1.ALL ( 0000 20111012193650              er1adm       SAPSVR 20111012193634007e64

SLOG702 - also 12 days old:

### Phase ACT_UPG:
START REMOVE STOPMARK      ALL        20111012193616              er1adm       SAPSVR 2011101219361600787c
STOP  REMOVE STOPMARK      ALL        20111012193616              er1adm       SAPSVR 2011101219361600787c
START put                  ER1        20111012193635              er1adm       SAPSVR 20111012193634007e64
START SET STOPMARK         ER1        20111012193649              er1adm       SAPSVR 20111012193634007e64
INFO: Buffer saved as C:\usr\sap\ER1\EHPI\abap\buffer\ER1SAV.
STOP  SET STOPMARK         ER1        20111012193650              er1adm       SAPSVR 20111012193634007e64
LIST  put                  ER1 (A{|
START tplock_eu            ER1 (      20111012193650              er1adm       SAPSVR 20111012193634007e64
STOP  tplock_eu            ER1 (      20111012193650              er1adm       SAPSVR 20111012193634007e64
START DD ACTIVATION        ER1 A      20111012193650              er1adm       SAPSVR 20111012193634007e64
START tp_getprots          ER1 J      20111012193651              er1adm       SAPSVR 20111012193634007e64

and in tmp directory I have always fresh file SAPA-702DDINSAPBASIS.ER1 which is now about 220MB and last update 30minutes ago. Last lines:

1 EDO759 Deletion of table type "VC2OD_T_DESCRIPTIONS_LTXT_BO" successful
1 EDO759 Deletion of table type "VC2OD_T_DESCRIPTION_LTXT" successful
1 EDO759 Deletion of table type "VC2OD_T_DESCRIPTION_LTXT_BO" successful
1 EDO759 Deletion of table type "VC2OD_T_DMT_DEPENDENCY_EXP" successful
1 EDO759 Deletion of table type "VC2OD_T_DMT_SOURCE_CODE" successful
1 EDO759 Deletion of table type "VC2OD_T_DMT_SOURCE_TABLE_SP" successful
1 EDO759 Deletion of table type "VC2OD_T_ECN_HDR_ID" successful
1 EDO759 Deletion of table type "VC2OD_T_LANGUAGE_KEY" successful
1 EDO759 Deletion of table type "VC2OD_T_MEDIT_EDITOR_ID" successful
1 EDO759 Deletion of table type "VC2OD_T_MEDIT_EDITOR_SP" successful
1 EDO759 Deletion of table type "VC2OD_T_MEDIT_EDITOR_UI" successful
1 EDO759 Deletion of table type "WART_TR_EKORG" successful
1 EDO759 Deletion of table type "WART_TR_ELIFN" successful
1 EDO759 Deletion of table type "WBELN_ITAB" successful
1 EDO759 Deletion of table type "WCAT_FIELDMAP_BW_TT" successful
1 EDO759 Deletion of table type "WEC_BP_ADD_MODIFY_TAB" successful

I tried to log in to shadow instance, but always have error: 'update still in progress, cannot log in'

any ideas how long could it take? Or how to make it faster?

thanks in advance

[sunny_pahuja2 · Accepted solution]

Hi,

This phase usually takes long time but I never came across situation where it is taking 12 days. Please check SM37 and ST22 in the shadow instance if there is any dump in the system. You can login with DDIC user or you can unlock the system and then login with normal user.

There is something going wrong into your system thats why it is taking so much time. Please login to shadow system and then check.

Thanks

Sunny

[Former Member · Accepted solution]

There is Job RDDMASGL with status cancelled many times. Since 12th Ostober till today each two hours. After that there is the same job with status finished on 12th October and about 20 other finished jobs.. In cancelled job I checked log:

Job started
Step 001 started (program RDDMASGL, variant IMPACTMRG, user ID DDIC)
Start of mass activation 06:44:43
Internal session terminated with a runtime error (see ST22)
Job cancelled

in ST22 I have few runtime errors every day:

SYSTEM_NO_ROLL

Short text:
Unable to fulfil request for 16777216 bytes of memory space

[Former Member · Accepted solution]

Hi,

Please check Note 1387739 and set profile parameters as mentioned.

Then restart the phase.

Regards,

Srikishan

[sunny_pahuja2 · Accepted solution]

Hi,

That is the reason that this phase js running from last 12 days. Now login to shadow system and then change the profile parameters as suggested in dump. Then restart the shadow instance and repeat the phase. But after changing the parameter monitor this job so that it will not throw same error again.

Thanks

Sunny

[Former Member · Accepted solution]

After changing the parameters that step took only 13 hours... I've lost 12 days, but now I'm a bit more educated Thanks guys.