cancel
Showing results for 
Search instead for 
Did you mean: 

EHP1 Upgrade - Error in START_J2EE_DEPL Phase

Former Member
0 Kudos

Hi,

I am upgrading BI 7.0 (ABAP+JAVA) to EHP1. Currently upgrade is in Downtime phase and we got error in START_J2EE_DEPL phase.

Error in log file STARTSAP_START_02_TJP_05.ERR is as mentioned below:

/usr/sap/<SID>/DVEBMGS02/exe/startsap[15]: 19.03.2010: not found.

Error in Trouble ticket is

The execution of UPGRADE/DEPLOYMENT_BASED_UPGRADE/START_J2EE_DEPL ended in error.

Could not start AS Java instance with name J2EE and number 02 of the standard system.

Could not start instance 02.

Currenlty, i am not able to access the ABAP instance also and in developer trace, there is error message related to UME

Core service com.sap.security.core.ume.service failed. J2EE Engine cannot be started.

OS : HP-UX 11.23

Database : 10.2.0.4.0

Please help.

Regards,

Ranjith

Accepted Solutions (0)

Answers (6)

Answers (6)

Former Member
0 Kudos

Ranjith,

Have you looked at note 716378?

https://websmp230.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/sapnotes/index2.htm?numm=716378

The note refers to a very similar situation during a unicode upgrade. Maybe some of those solutions are applicable in your case.

-Kevin

Former Member
0 Kudos

Hi Kevin,

Manually killed all the shadow instance services and continued the phase. Issue is resolved and released to the BI Team.

Thanks for all your support.

Regards,

Ranjith

Former Member
0 Kudos

Agreed, all your errors center around kernel files so that's likely the source of your issue. I'm not sure what to try next other than to let SAP work on it from their end, if you've got the time/patience to wait.

Please let us know what they come back with.

-Kevin

Former Member
0 Kudos

Hi,

Phase START_J2EE_DEPL is completed and currently i am facing issue in MAIN_NEWBAS/MOD_INSTNR_CLEAN and the error is

Cannot remove '/usr/sap/SBD/DVEBMGS12/exe/libicudata.sl.30': Text file busy

Regards,

Ranjith

Former Member
0 Kudos

Ranjith,

I glossed over this error when I first read your post... the error you're showing in your SAPInst logs:

-


Error in log file STARTSAP_START_02_TJP_05.ERR is as mentioned below:

/usr/sap/<SID>/DVEBMGS02/exe/startsap15: 19.03.2010: not found.

-


Maybe we're all overlooking the obvious, but this is suggesting that a file called "startsap15" is missing from the kernel directory? Can you verify that everything in the /usr/sap/<SID>/DVEBMGS02/exe directory is in tact and looks as it should? If your kernel deployment has already finished and some files were overwritten, maybe that's your problem.

Just thinking out loud, but check it out and let me know.

-Kevin

Former Member
0 Kudos

Hi Kevin,

Thanks for your reply.

startsap is available in the kernel directory. I would like to know, whether it is ok to stop and start the ABAP instance manually in Downtime Phase. Once the ABAP instance is started, i can stat the Java also.

Regards,

Ranjith

Former Member
0 Kudos

Hi,

This error is when start the ABAP + JAVA, ABAP will start very fast. so next it will wait for JAVA startup. some time through the error. Please start ABAP+JAVA manually and repeat the step.

Surely it will work. i faced this same error when i did EHP1 upgrade in BI system.

Thanks and Regards,

Jibin.

Former Member
0 Kudos

I'd agree with Jibin. Stop/Start the cluster manually to try to get the ABAP stack up and stable before the Java stack attempts to boot.

Give it a shot and let us know the results.

-Kevin

Former Member
0 Kudos

Hi Jibin/Kevin,

I started the instance manually using startsap command and now the shadow instance has been started, but the actual instance is still down. I think, there is issue in kernel, when i do disp+work in /usr/sap/SID/DVEBMGS02/exe, it is giving error as:

/usr/lib/hpux64/dld.so: Unsatisfied code symbol 'ab_xaGetTopXAType' in load module '/usr/sap/SID/SYS/exe/run/dw_xtc.so'.

Killed

But the disp+work is working in the shadow instance kernel directory. What should i do now?

As i have already raised a message to SAP and they are working from yesterday.

Regards,

Ranjith

Edited by: Ranjith Kumar D on Aug 26, 2010 5:24 PM

Former Member
0 Kudos

Ranjith,

What type of user store is your UME configured for? Your UME service is not starting and that's preventing the instance from starting. Some obvious reasons for the ume service not to start are:

- locked users (in that user store, could be remote id you use LDAP, etc.)

- no connection to user store (again, more common in LDAP scenario as user store lives external to instance host)

- bad conifugration of ume (did you attempt to make any changes during this upgrade?)

- using SNC? Did any SNC-related profile parameters get wiped out during the initial phases of the upgrade?

There's always the trusty "Secure Store Password Reset" which fixes a lot of these types of issues. The assumption is that your admin account password and the password stored in the secure store in the config tool have become out of sync. During upgrades and patches, SAPInst/JSPM/etc will retrieve this password from the secure store. If this is no longer accurate, you might get a failure like this, although typically you wouldn't get past the wizard without throwing errors. If you're confident you KNOW what the admin password should be, then launch the configtool, switch to the secure store, and overwrite the value stored there. Then down the cluster and bring it back up.

-Kevin

Former Member
0 Kudos

Hi,

Thanks for your reply.

Currently, ABAP instance is down, i think due to this, Java instance is not able to connect to the ABAP Data Source. As the upgrade is in Downtime phase, can we shutdown or start the instance manually and retry the EHP Upgrade?

Error in std_server0 is:

Aug 25, 2010 10:53:24... com.sap.security.core.persistence [SAPEngine_System_Thread[impl:5]_94] Fatal: User Management Engine (com.sap.security.core.persistence.datasource.imp.R3Persistence) failed to connect to the ABAP backend system. Check that connection data are correct and the backend system is available. Error message: "Upgrade still running: Logon not possible ". Connection data (obtained from properties of UME service in section "ume.r3.connection.master.": "{

passwd=********

receiverid=master

sysnr=$$

client=001

poolmaxsize=10

user=SAPJSF

receiverid_guest=master

ashost=localhost

poolmaxwait=10000

Regards,

Ranjith

Former Member
0 Kudos

Hi Ranjith,

Exactly as we discussed, the J2EE server won't start because its user store (your ABAP instance) is unavailable. My question now is, why do you need this instance up? Does this J2EE server host a different application then the ABAP stack on the same host? I have to assume so because if they're part of the same application, it stands to reason that you'd never expect to bring it up. ;o)

Unfortunately, the short answer is you can't bring up the J2EE stack until the ABAP stack is available because you have no available UME database otherwise. If this is an emergency, and you MUST get that instance up and running before the ABAP system comes up, you could try changing the user store to something other than THAT ABAP system. There are big down-sides to this as well though... since you're co-locating these apps on the same host, they're probably sharing the same database. So.... when you've got patching/downtime, etc. underway, that DB isn't the best source for UME so whichever UME source you choose will have to be external. Obviously, the biggest drawback is you'll losse all your user persistence when you switch and you'll need to set up your users again. Doesn't seem worth it, in my opinion.

Did I miss something though? Can you tell me more about why you're expecting/needing the J2EE instance of a dual stack system to start when then upgrade is still in down time? Sometimes I mis-read things so I could have confused mysellf. ;o)

-Kevin

Former Member
0 Kudos

Hi Ranjith,

Have you locked all the users during the downtime phase, If so, try to unlock the SAPJSF and J2EE_Guest users and then proceed with the update.

BTW: Whats the issue when u try to access ABAP instance.

Regards,

Varadharajan M

Former Member
0 Kudos

Hi,

Can you check the std_server0.out file this should give a "caused by" in relation to the UME error.

Can you post the stack trace that relates to the error?