Phase ACT_700 taking too long, no information about progress

[eduardo_gironas]

Hello:

I am upgrading from 46C to ECC 6.0 in a test SUN Solaris server with Oracle. In phase ACT_700 one hour after I adjusted some objects using SPDD and continued upgrading process, system crashed because of a physical disk problem. When it was solved one day after and the system was up again, I attempted to restart the ACT_700 process but it issued an error indicating that database objects could not be accesed. It was necessary to start the database instance manually. After that I proceeded again. The log file below indicates the last steps I followed:

CHECKS AFTER UPGRADE PHASE ACT_700 WERE NEGATIVE !!!

It is recommended that you repeat phase ACT_700

You can exit and restart the phase after the errors

have been corrected. Alternatively, if you know that

the error is not of concern, you may ignore it

and continue with phase RUN_RSPTBFIL_DEST

You are urged to repeat phase ACT_700 !

? repeat

? init

? exit

? ignore

Waiting for input since Jun 10, 2011 4:35:35 PM

> repeat

>> 16:35:54 UPGRADE/SHADOW: END OF PHASE ACT_700

>> 16:35:54 UPGRADE/SHADOW: START OF PHASE ACT_700

running /usr/sap/put/exe/tp pf=/usr/sap/put/bin/ACTUPG.TPP put DES

The last process is running for more than 16 hours!! The log files do not show a progress since then and I don't have access to any of the SAP instances (the normal and the shadow). Using ps -fea at the OS level does not indicate activity.

How can I know if the process is really executing?

Is this possible to cancel it?

If I can cancel, which steps should I take to avoid this situation?

Thanks for you attention and help.

Eduardo.

[markus_doehr2 · Accepted solution]

> The last process is running for more than 16 hours!! The log files do not show a progress since then and I don't have access to any of the SAP instances (the normal and the shadow). Using ps -fea at the OS level does not indicate activity.

This is not uncommon. Depending on the number of support packages and Addons and languages this process can take quite some time, especially if you didn't configure the resource use manually.

> How can I know if the process is really executing?

> Is this possible to cancel it?

> If I can cancel, which steps should I take to avoid this situation?

Check the latest logs in <PUTDIR>/log and <PUTDIR>/tmp.

use "prstat -a 1" to see if there is activity.

Markus

[eduardo_gironas · Accepted solution]

Marcus, Many thanks for your attention. Additional 24+ hours have elapsed since I have reported the problem, I executed the command you kindly indicated me, I show you a result; it dinamically changes between tp/1, java/35 and oracle, but I am noy sure if, it is in a waiting state or in an endless loop.

PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP

11984 desadm 3888K 3264K cpu193 40 0 0:00:02 1.4% prstat/1

5170 root 17M 12M sleep 59 0 0:06:13 0.1% fmd/21

11987 orades 632M 616M sleep 59 0 0:00:00 0.1% oracle/1

11799 desadm 7504K 4872K sleep 58 0 0:00:00 0.0% sshd/1

6313 orades 633M 617M sleep 59 0 0:03:23 0.0% oracle/1

66 root 20M 17M sleep 59 0 0:07:22 0.0% vxconfigd/3

6317 orades 632M 615M sleep 59 0 0:03:09 0.0% oracle/1

449 root 7184K 3768K sleep 59 0 0:00:14 0.0% nscd/26

6297 orades 633M 616M sleep 59 0 0:02:04 0.0% oracle/1

6307 orades 633M 617M sleep 59 0 0:01:45 0.0% oracle/11

4952 noaccess 215M 146M sleep 59 0 0:02:20 0.0% java/18

6465 desadm 52M 44M sleep 59 0 0:01:37 0.0% tp/1

499 root 2728K 1256K sleep 59 0 0:01:01 0.0% in.mpathd/1

11806 desadm 2072K 1552K sleep 55 0 0:00:00 0.0% csh/1

5544 desadm 265M 110M sleep 59 0 0:00:56 0.0% java/35

NPROC USERNAME SWAP RSS MEMORY TIME CPU

10 desadm 228M 233M 2.8% 0:02:36 1.5%

17 orades 642M 727M 8.9% 0:13:42 0.2%

60 root 102M 126M 1.5% 0:16:44 0.1%

1 noaccess 130M 197M 2.4% 0:02:20 0.0%

1 smmsp 1312K 5352K 0.1% 0:00:00 0.0%

Total: 96 processes, 573 lwps, load averages: 0.08, 0.05, 0.04

The last update date/time of the most recent files in /usr/sap/put/tmp and /usr/sap/log continue indicating June 10 at 16:35, i.e. the date and time I repeated the PHASE ACT_700. There is no activity in these directories since then.

I am thinking that SAPup is in a waiting state or locking state ¿is it possible it needs to have shadow instace started up? Currently Shadow instance is stopped.

I would like to restart all the upgrade process, ¿is this possible at this phase without restoring a previous backup that I have?

Thank you again for your attention and help.

Eduardo.

[markus_doehr2 · Accepted solution]

There seems to be no activity at all.

Stop SAPup on OS level and then restart it. Then "step back" instead of pressing "next".

Also check the upgrade guide for additional steps how to reset the upgrade. At this phase you don't need to restore the database.

Markus

[eduardo_gironas]

The problem was solved, the upgrade process continues sinces yesterday afternoon. I followed your indications and re-initiated the ACT_700 phase; and according to troubleshooting indications, previously it was necessary to execute the command "SAPup startshd" to start the shadow instance before continuation. It seems that when the Shadow instance is stopped due to unexpected system interruption, it doesn't restart automatically when the ACT_700 phase is resumed and a wait state occurs.

Thank you again for your kind help.