APPLSYSPUB

APPLSYSPUB  

·       Initially, oracle applications connects to this public schema, APPLSYSPUB This schema has sufficient privileges to perform the authentication of an Applications User (FND user), which includes running PL/SQL packages to verify the username/password combination and the privilege to record the success or failure of a login attempt. 

·       The public ORACLE username and password that grants access to the Oracle E-Business Suite initial sign-on form. The default is APPLSYSPUB/PUB.

·       Once we changed the APPLSYSPUB password, it must propagate the change to application tier configuration files. If the instance is Autoconfig enabled, it must edit the CONTEXT file on each tier prior to running Autoconfig. 

·       In the CONTEXT file, we need to locate the autoconfig variable “s_gwyuid_pass” and set it to the new password, then run AutoConfig in each applicatins nodes. 

Always change password of APPLSYSPUB with FNDCPASS. 

$ FNDCPASS APPS/[apps_pwd] 0 Y SYSTEM/[system_pwd] ORACLE APPLSYSPUB [new_pwd] 

0 & Y are flags for FNDCPASS

 0 is request id  (request ID 0 is assigned to request ID's which are not submitted via Submit Concurrent Request Form)

'Y' indicates that this method is directly invoked from the command-line and not from the Submit Request Form. 

If we are not using AutoConfig,then we must manually edit the following configuration files : 

1) FND_TOP/resource/appsweb.cfg

2) OA_HTML/bin/appsweb.cfg

3) FND_TOP/secure/HOSTNAME_DBNAME.dbc 

Note :-

All application tier processes must be restarted.  

Oracle Ebusiness Suite R12 Security Reference

Oracle Ebusiness Suite R12 Security Reference 

https://www.integrigy.com/files/Integrigy%20Oracle%20E-Business%20Suite%20Security%20Quick%20Reference.pdf


https://docs.oracle.com/cd/E26401_01/doc.122/e22952/T156458T659606.htm


https://docs.oracle.com/cd/E18727_01/doc.121/e12893/T174296T174305.htm

APPS User Locks After Manually Altering Password (Doc ID 566127.1)

SYMPTOMS

On 12.0.4 Changed APPS password and cannot login.

The issue can be reproduced at will with the following steps:
Changed the apps pwd using

alter user command instead of FNDCPASS

CAUSE

Apps password was manually changed. Changing the password manually is a security breach and will corrupt the passwords.

SOLUTION

To implement the solution, please execute the following steps:

1. Backup the FND_USER, FND_ORACLE_USERID tables.
2. Change the password in the following sequence.

SQL> alter user applsys identified by apps;
SQL> alter user apps identified by apps;
SQL> alter user apps account unlock;

MRP process is running on DR

Check if MRP process is running on DR instance.

Sometime we need to check if the MRP process is running in our DR database.

Solution:

This can be done using one simple SQL


SELECT PROCESS, DELAY_MINS
FROM V$MANAGED_STANDBY
WHERE PROCESS like 'MRP%';


If the above SQL returns nothing that means MRP is not running. How ever if it returns something that means MRP is running.

SQL> SELECT PROCESS, DELAY_MINS FROM V$MANAGED_STANDBY WHERE PROCESS like 'MRP%';
no rows selected
SQL>

-- MRP is not running
-- To start MPR issue the SQL below

SQL>  ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
Database altered.
SQL>
SQL> SELECT PROCESS, DELAY_MINS FROM V$MANAGED_STANDBY WHERE PROCESS like 'MRP%';
PROCESS   DELAY_MINS
--------- ----------
MRP0               0
SQL>

-- MRP process is running now.

Tip: if you want standby logs to be applied instantly then issue

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;