Configtool connection to the database doesn't work

[Former Member]

Hello guys,

I have a BW system SAP EHP 1 for SAP NetWeaver 7.0, which has an ABAP and Java stack, but the java stack is switched off after a system copy from a production system (it was a wish of the customer that we do only an ABAP syscopy (without java export and import and the whole process with sapinst) and switch the java stack off [parameters rdisp/j2ee_start = 0, rdisp/j2ee_start_control = 0 in instance profile).

That means that the data in the data base is as it was in the production system, but the rests of the java stack still have the original information from the instance Q20 before the copy. The data in the secure store files /usr/sap/Q20/SYS/global/security/data/SecStore.properties & SecStore.key are same as they were before the copy.

I such situation I still decided  to exchange Sun Java (JDK) to SAP Java (sap jvm), took solaris switch tool  SAPJVMSWITCH00P_7-20008219.SAR  plus SAPJVM4_20-10009720.SAR (SAP JVM 4.1 software, solaris). I used te same software at another instance from the same landscape where a double stack is still running in a normal "full" condition and the sxchange went well.

But in this case i got the following error:

(sapinst)

Reading Java parameters from database ends with return code 101

SOLUTION: Make sure the database is up and running. For more information, see the output of log file /usr/sap/poli_tmp/Q20/sapinst_instdir/sapinst_instdir/NW70/SWITCH_JDK/jread.log

In jread.log (partly):

CONFIG: 2012-10-08 18:11:16

Application options:

arch=sap_64bit

instanceID=ID2436157

javaPath=/usr/j2sdk1.4.2_17

outputFile=/usr/sap/poli_tmp/Q20/sapinst_instdir/sapinst_instdir/NW70/SWITCH_JDK/ID2436157_javaParameters.properties

ssKeyFile=/usr/sap/Q20/SYS/global/security/data/SecStore.key

ssPropFile=/usr/sap/Q20/SYS/global/security/data/SecStore.properties

systemName=Q20

...

INFO: 2012-10-08 18:11:17

Trying to open database connection.

ERROR: 2012-10-08 18:11:22 com.sap.inst.jswitch.read.ReadTask run

Fatal exception during execution of JRead.

1. com.sap.engine.frame.core.configuration.ConfigurationException: Error while connecting to DB.

...

at java.lang.reflect.Method.invoke(Method.java:324)

        at com.sap.engine.offline.OfflineToolStart.main(OfflineToolStart.java:81)

Caused by: java.sql.SQLException: ORA-01017: invalid username/password; logon denied

I checked the users in the database, SAPSR3DB (java) and SAPSR3 exist and are not locked.

q20adm> sqlplus "SAPSR3DB"  

SQL*Plus: Release 11.2.0.3.0 Production on Wed Oct 10 11:21:01 2012

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Enter password:

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

Then i checked configtool, i could start it but it also couldn't make a connection to the database:

#1.5^H# #1349791994914#/System/Database/sql/jdbc##com.sap.sql.jdbc.NativeConnectionFactory#######Thread[main,5,main]##0#0#Error#1#co

m.sap.sql.jdbc.NativeConnectionFactory#Java#com.sap.sql_0002#com.sap.sql.log.OpenSQLResourceBundle#SQL error occurred on connection

{3}: code={0,number,integer}, state="{1}", message="{2}".#5#1017#72000#ORA-01017: invalid username/password; logon denied

#jdbc:oracle:thin:@sapq20p:1542:Q20#<null>#

So far i understand the data which was in securestore in configtool was actually correct, the passwords of the users J2EE_ADMIN and SAPSR3DB are same in production and Q systems. Url was also correct. Listener port, host name are still the same, nothing changed.

It is really interesting for me, what disturbed the connection actually? Is it the fact that Java stack is not running? or is  it a certain information in the java stack which still exists somewhere from the original Q20 system and which is not the same as in the Prod system?

Any ideas what can be the reason for such an error?

Thanks a lot in advance.

Polina

[Former Member]

Hello Polina,

I think in your case you have only restored the database of java stack, but as you know for java stack data is there on file system as well as in DB and both needs to be in sync,

For your scenario, I would have done one of the following things:-

1) Export the db schema of java stack using db utility --> restore the DB of PRD to QAS --> import the java schema back to QAS.

2) export the java stack using sapinst --> restore the PRD database to QAS --> import the java from sapinst. In this case java migration monitor will make the required changes in the file system.

Regards,

Vishal

[Former Member]

Hi Polina

When you first invoke configtool, it will see a message " Do you want to continue with Default DB settings" ( Yes / No) . Click on "No' and check all secureStore path and database library path, check these entries are correct or not ? If not correct them and try to connect to DB.

Regards,

Dipam

[rajan_thomas]

Did your Run Migration toolkit ran successfully?

if not you have to do your system copy again.

regards,

Rajan

[Former Member]

Hi Rajan,

which migration toolkit did you mean: a switch tool SAPJVMSWITCH00P or something else?

regards,

Polina

[Former Member]

Looks like you need to recreate OPS$ users.

Try Note 400241 - Problems with ops$ or sapr3 connect to Oracle

[Former Member]

Hi Pavel,

why do you think that it is an ops$ user problem? In this case i think even my ABAP stack wouldn't work properly, but it does. The user OPS$Q20ADM exists, it was created in the system copy process ( standard way)

if i make a query, it looks like that evything is fine with it.

SQL> select * from OPS$Q20ADM.SAPUSER;

USERID

--------------------------------------------------------------------------------

PASSWD

--------------------------------------------------------------------------------

SAPSR3-CRYPT

V01/0040ZctvSB67Wv3SgcQ1PaeGTTy3IEcod/JQ

regards,

Polina

[Former Member]

Well, your OPS user is ok.

Did you copy file \usr\sap\SID\SYS\global\security\data\SecStore.properties from source system to target or generated new?

Is your password for securestore same on source and target system?

[Former Member]

no, i neither copied it (then it would have a wrong url and a listener port in it) nor generated it new. It is still an old one from Q20 (before the copy). That means that the even if the users and url are correct (if the passwords are the same), the problem might be in the key phrase. i don't know if it is same or not, i think if it would be same, it could work properly.