Weblogic managed servers

[latifa]

Hi Erman,

I have an strange behavior. While starting weblogic managed servers, they are in ADMIN state instead of RUNNING.

I explain what we have done:
- Our DBA refreshed DB without stopping application Tier including weblogic
- source RUN File system was 'fs1' while destination it was set 'fs2'.
- I have only clean nodes, truncate adop valid nodes, DB dbconfig, autoconfig for appstier (only one server).
- the source was RAC and multinodes.

How can I arrange this situation ?

Regards,
Latifa

[ErmanArslansOracleBlog]

This is an unsupported move Latifa.
weblogic managed server logs and out files should be analyzed ( ex: 12.2 E-Business Suite Applications Technology Stack Oacore and OAFM Servers Do Not Restart And Are Stuck at State-Admin After Aborting ADOP Session And Restarting The Database / Applications Tiers (Doc ID 2285759.1))

Try your chance, but at the end of the day, you may need to reclone this system properly.
At least you could run afcfgclone.pl for the apps tier Latifa...:)

[latifa]

even apps password is not valid ! I connect to the database with it however:

select fnd_web_sec.validate_login('apps','****') from dual ;

FND_WEB_SEC.VALIDATE_LOGIN('APPS','*****')
--------------------------------------------------------------------------------
N


If I do adcfclone for the Appstier, how about DB Tier which was refreshed ? Is dbconfig is enough ?

Regards

[ErmanArslansOracleBlog]

How can Apps password be wrong?
Try your source env's apps password.

Db tier postclone is better ofcourse..

[latifa]

destination apps password was : apps.

While cloning dbTier (with dbconfig context_file= ...), I used the one from the source : for example ppapps
also for the appTier while doing autoconf, I used ppapps.

It was successful.

In a moment it was locked, so I unlocked it:

--> from

PROFILE                                    RESOURCE_NAME                    LIMIT
-------------------------           --------------------------------            ----------
DEFAULT                                   FAILED_LOGIN_ATTEMPTS            10
AD_PATCH_MONITOR_PROFILE   FAILED_LOGIN_ATTEMPTS            UNLIMITED
EM_OAM_MONITOR_PROFILE      FAILED_LOGIN_ATTEMPTS            3
ORA_STIG_PROFILE                   FAILED_LOGIN_ATTEMPTS            3
DBA_PROFILE                            FAILED_LOGIN_ATTEMPTS            UNLIMITED

--> to

PROFILE                   RESOURCE_NAME                    LIMIT
------------------------- -------------------------------- ----------
DEFAULT                   FAILED_LOGIN_ATTEMPTS            UNLIMITED
AD_PATCH_MONITOR_PROFILE  FAILED_LOGIN_ATTEMPTS            UNLIMITED
EM_OAM_MONITOR_PROFILE    FAILED_LOGIN_ATTEMPTS            3
ORA_STIG_PROFILE          FAILED_LOGIN_ATTEMPTS            3
DBA_PROFILE               FAILED_LOGIN_ATTEMPTS            UNLIMITED

and:

alter user apps account unlock;

I don't know why it doesn't block in the begining ...

What do you mean by Db Tier postclone ?

Thank you for your help.

Regards

[latifa]

Oh I forgot, what is it unsupported when you say :

"This is an unsupported move".

- refreshing only DB ?
- refreshing without stopping application Tier ?

Regards

[ErmanArslansOracleBlog]

you need to  change it once again.
Apps password info is stored in db as well.
so if you clone the db , your apps password stored in db comes from the source.
you should set it to source now. Set it to source 's apps password and then continue and try your chance.

DB tier post clone is also an activity that you can do in cloning.
normally, we clean the nodes by executing exec fnd_conc_clone.setup_clean, and then run autoconfig on db tier. But there are cases where postclone in db tier may be a recommended move.

[latifa]

how about changing apps password to the new one before running autoconfig on appstier ? I will make it as the destination password before ?

[ErmanArslansOracleBlog]

1)If the OS is not windows, then, source apps shutdown is unnecesary.
However, as for the target apps , this is not true.
target apps services should be shutdown, during the cloning operation.

2)In db tier, you should run adcfgclone.pl, as well.

3)You need to follow -> Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone (Doc ID 1383621.1): 5.1 Refreshing a Target System

4)Apps password should be the same as the source. After cloning the whole system , you will change it. Not during cloning.

[latifa]

I cleaned fnd_nodes, run autoconfig on both DBTier and AppsTier

Started adaminserver and connect to Weblogic console and restarted oacore and forservers managed servers however  the issue is remaining ... the state of these managed servers is : ADMIN !

So I think I have no other to do other than:
- adcfgclone.pl dbconfig for DB Tier
-  adcfgclone AppsTier for apps Tier

Regards

[ErmanArslansOracleBlog]

Yes, but oacore logs still need to be reviewed, if the issue persists.

[latifa]

I could see something like following in the oacoreserver log file:

 The returned message is: ORA-01017: invalid username/password; logon denied

 It is likely that the login or password is not valid.
 It is also possible that something else is invalid in
 the configuration or that the database is not available.
        at weblogic.jdbc.common.internal.JDBCUtil.parseException(JDBCUtil.java:301)
        at weblogic.jdbc.common.internal.ConnectionEnvFactory.makeConnection(ConnectionEnvFactory.java:383)
        at weblogic.jdbc.common.internal.ConnectionEnvFactory.createResource(ConnectionEnvFactory.java:241)
        at weblogic.common.resourcepool.ResourcePoolImpl.makeResources(ResourcePoolImpl.java:1322)

Regards

[ErmanArslansOracleBlog]

Your apps password is already in a unstable state. So this issue is related with it.
I don't know how you changed the apps password (using fndcpass or not) and exactly when you changed it, but it seems you could not change it properly.
It seems in datasource definitions, the apps password is not valid. lets change it its original/source value directly from the weblogic console and restart apps services.  
After that by using FNDCPASS and running autoconfig change the Apps password once again properly.
After that, restart the apps tier again.
Update me with the outcome.

[latifa]

That's exactly what I have done (following this link: https://community.oracle.com/thread/3628127) , I changed the apps password in weblogic console (connection pool), running autoconf on the appsTier and in this way I could restart the manages servers ...

I restarted all services in order to connect to the application however (happiness is not complete :( ), error message:

Login failed. Please verify your login information or contact the system administrator.

I checked the password as following:

select fnd_web_sec.validate_login('SYSADMIN','SYSADMIN') from dual;

FND_WEB_SEC.VALIDATE_LOGIN('SYSADMIN','SYSADMIN')
--------------------------------------------------------------------------------
N

FNDCPASS apps/ebsapps  0 Y system/oracle SYSTEM SYSADMIN SYSADMIN

log file error message:

Working...
Error in password verification for APPS


Regards

[latifa]

I made mistake with trying to change sysadmin password. The problem is remaining apps password even I could start managed servers ... where ? I don't know

[ErmanArslansOracleBlog]

you changed the apps password in weblogic console to what?
the "ebsapps" is the password of the source, right?

you need to change the apps password in weblogic console to the source value.
you need to be able to connect to database using apps/source_value_password.
Then you need to run FNDCPASS with the source value password + recreate the dbc file (just in case) and then run autoconfig.
--you may also try to recreate the dbc file before running FNDCPASS..

Do the above and update me (with the details)

[ErmanArslansOracleBlog]

you say: The problem is remaining apps password"

Give me the details about it.
But now, i need to sleep :)
Tomorrow, I will see ..

[latifa]

Ok Erman, I'm sorry. Good night  :)

and I'll continue posting (you will review tomorrow).

Thank you for your help.

[latifa]

1. I Changed apps password in weblogic console to ebsapps which is source apps password.

  --> This worked fine and even I could restart managed services and their state is "RUNNING" instead of "ADMIN" before.

2. I can connect to database with source value of apps password:
    @ >conn apps/ebsapps
     Connected.
     @APPS@DBOFINF1 >conn applsys/ebsapps
     Connected.

3. I recreate dbc file : sh adgendbc.sh (from  $INST_TOP/admin/install).

4. I run FNDCPASS with ebsapps to change it:

FNDCPASS apps/ebsapps  0 Y system/oracle SYSTEM APPLSYS apps

again log file:
Working...
Error in password verification for APPS

--> I can't do autoconfig

5. I have a question: Source RUN File system was fs1 and target RUN file is fs2. Can it be the problem ?

regards,
Latifa

Regards,
Latifa

[ErmanArslansOracleBlog]

What happens when you use the following command:

FNDCPASS apps/apps  0 Y system/oracle SYSTEM APPLSYS apps

-- I mean when you use apps/apps for the FNDCPASS.
Take a look at this note: How to Troubleshoot Login Issues After Changing APPS Password Using FNDCPASS Utility (Doc ID 809155.1) -- it is for 12.1 but still valuable.

As for fs2-fs1 question, this is weird, this should not be like that. But, I don't think that it should cause APPS password invalidation..