Applying support packages

[Former Member]

Dear gurus,

we have upgraded R/3 4.7 to ECC 6.0.

i have started the applying support packages for sap_aba component. (sapka70016). but the ddic_activation pahase is still goin from last 6 hours.

still queue is being processed. in sm37 i checked the status is active.

besically it does not take that much of time.

please suggest me why it's taking this much of time.

regards

deepak

[former_member229314]

Hello all,

we encounter this problem when running SPAM completely in the BACKGROUND on a system with multiple APPLICATION servers.

We start SPAM on the Central Instance (ECC50)/first Dialog Instance(ECC60), choosing to run all 4 steps in the BACKground. Then the DDIC_ACTIVATION phase gets scheduled to run on some OTHER application server, and that is where it looses it. My theory is that tp either won't run on the other app server, or tp can't connect properly back to the CI/1st DI or to SAPTRANSHOST. It can also be that tp completes successfully, but cannot return control to SPAM.

On the other app server, we notice a background process in status RFC, busy running report SAPLSTPA. It sits there forever.

To get out of this bind, we kill the app server, reset the SPAM queue, and start over properly:

Our crude 'solution' to prevent this in the first place is to shut down all application servers before running SPAM (not a bad idea in a production system anyway), and/or running SPAM in the FOREGROUND from the CI/1st DI.

What do you think?

Thanks,

Ruben

[Former Member]

Hi All,

Yes do not run all the steps in SPAM in the background out of the 4 steps your are free to run the 1st and the 2nd steps in the foreground as these would not create any problem.

This is what SAP suggests - please check this demo (.sim) file in the service marketplace.

https://websmp103.sap-ag.de/~form/sapnet?_SHORTKEY=01200252310000064279&_SCENARIO=011000358700000002...

Since your case it has already got into this loop, please cancel the job. Check if tp is running in the background. And if needed kill it.

Reset the queue and start overall again.

Hope this helps.

- Regards, Dibya

[Former Member]

Thanks for your suggestion.

[former_member186775]

Hi Deepak,

It does'nt take that much time .Either it encountered a loop

or else just check with the Queue.cancel it .clear the queue

in the STMS tcode then try to start it from the first.

regards

manjula

[Former Member]

Hi Deepak,

Please check on with the logs , then with the tablespaces(via db02) or brtools. Then check for the orarch directory( the drive has enough memory space).

Please check on and let us know the problems you face.Also clearing the table entries would help in this case.But let us know whether the above mentioned are done.

Regards,

Radeesh V

[Former Member]

Hi,

What is active in SM37? did u check if there are any canceled jobs?

Did u see some error messages in sm21 logs?

Regards

KVR

[Former Member]

Hi

Check the tablespaces of the system, and see that there is enough space in the oraarch directory.

Paste the log here and come back

or else

u can stop and upgrade the kernel with latest r3trans and try.

Regards

Bhaskar

Edited by: bhaskar1818 on Sep 8, 2008 4:55 PM

[Former Member]

Hi Deepak,

Please check if any tablespace or filesystem is full.

If space is OK, then select the job in SM37 & got to JOB -> Check Status.

-Pankaj