Saturday, October 15, 2011

Accidently issued alter user command to change apps password

Sol 1:
APPS User Locks After Manually Altering Password [ID 566127.1] for 12.0.4
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;
Sol 2:
APP-FND-01496 Error After Changing Apps And Applsys Users Using Alter User [ID 445153.1] for Release: 11.5.10 to 11.5.10 1.
Restore the FND_ORACLE_USERID and FND_USER tables from a backup.
2. Then run FNDCPASS to change the APPLSYS password.
FNDCPASS apps/apps 0 Y system/ SYSTEM APPLSYS WELCOME

Troubleshooting Guide For Login and Changing Applications Passwords [ID 1306938.1]

R12 Upgrade patch fails with ORA-04021: timeout occurred while waiting to lock object

R12 Upgrade patch fails with ORA-04021: timeout occurred while waiting to lock object for multiple objects.
adwork001.log:ORA-04021: timeout occurred while waiting to lock object CS.CS_INCIDENTS_ALL
adwork002.log:ORA-04021: timeout occurred while waiting to lock object CN.CN_REV_CLASS_API_ALL
adwork003.log:ORA-04021: timeout occurred while waiting to lock object PJM.PJM_TASK_ATTR_USAGES
adwork004.log:ORA-04021: timeout occurred while waiting to lock object INV.MTL_ITEM_CATALOG_GROUPS_S
adwork005.log:ORA-04021: timeout occurred while waiting to lock object JA.JA_IN_AP_TDS_SERVICES
adwork005.log:ORA-04021: timeout occurred while waiting to lock object JA.JA_IN_REQN_INTERFACE
adwork006.log:ORA-04021: timeout occurred while waiting to lock object JA.JA_IN_57F4_LINES_S
adwork007.log:ORA-04021: timeout occurred while waiting to lock object JA.JAI_ITM_TEMPL_ATTRIBS
adwork008.log:ORA-04021: timeout occurred while waiting to lock object HR.PER_JP_BANK_LOOKUPS
adwork009.log:ORA-04021: timeout occurred while waiting to lock object INV.MTL_ITEM_CATALOG_GROUPS_S
adwork009.log:ORA-04021: timeout occurred while waiting to lock object PJM.PJM_TASK_ATTRIBUTES
adwork010.log:ORA-04021: timeout occurred while waiting to lock object ZX.ZX_ID_TCC_MAPPING
adwork013.log:ORA-04021: timeout occurred while waiting to lock object JA.JA_IN_GEM_TAX_CODES_S1
adwork014.log:ORA-04021: timeout occurred while waiting to lock object CS.CS_INCIDENTS_ALL
adwork017.log:ORA-04021: timeout occurred while waiting to lock object PJM.PJM_TASK_ATTR_USAGES
adwork025.log:ORA-04021: timeout occurred while waiting to lock object JA.JA_IN_AP_FORM16_DTL
adwork027.log:ORA-04021: timeout occurred while waiting to lock object CN.CN_REV_CLASS_API_ALL
adwork028.log:ORA-04021: timeout occurred while waiting to lock object PJM.PJM_TASK_ATTRIBUTES

Solution:
ALTER DATABASE DROP SUPPLEMENTAL LOG DATA;

and restart the failed workers.

Missing log records in receiving log queue for subscriber SUB_BILLPLAN_QUEUE errorcode = 416

Solution ( Below scripts needs to be run against each subscriber id having error)

begin
DBMS_MGWADM.CLEANUP_GATEWAY (action => DBMS_MGWADM.RESET_SUB_MISSING_LOG_REC,sarg => '<SUBSCRIBER_ID>');
end;

begin
dbms_mgwadm.reset_subscriber('<SUBSCRIBER_ID>');
end;


***********************************************
Refer mgw_subscibers for subscriber_id
***********************************************

Discoverer: Unable to connect to Oracle Applications database: invalid username/password

unable to connect to: user@123@sid Failed to connect to database - Unable to connect to Oracle Applications database: invalid username/password.
Solution:
1. use the following command to make the authentication off. java oracle.apps.fnd.security.AdminAppServer apps/apps AUTHENTICATION OFF DBC=file.dbc or Change the xml file and make the value of AUTHENTICATION secure to off.
2. Create a folder with name secure in Oracle Home, and copy dbc file from server ($FND_SECURE) to desktop.

patch 5980072 can also be applied on client to resolve this issue.

Routine FND_DCP.REQUEST_SESSION_LOCK received a result code of 1 from the call to DBMS_LOCK.Request.

In a Parallel Concurent processing environment, concurrnet managers only come up on one node, either nodeA or nodeB but not both nodes.

Encounter the following error in the Internal Concurrent Manager logfile:

Routine &ROUTINE has attempted to start the internal concurrent manager.
The ICM is already running. Contact you system administrator for further assistance.

afpdlrq received an unsuccessful result from PL/SQL procedure or function FND_DCP.Request_Session_Lock.
Routine FND_DCP.REQUEST_SESSION_LOCK received a result code of 1 from the call
to DBMS_LOCK.Request.
Possible DBMS_LOCK.Request resultCall to establish_icm failed.
The Internal Concurrent Manager has encountered an error.
Changes
Implementing parallel concurrent processing.
Cause
The concurrent manager startup script is being executed on both nodes.
This causes two instances of the ICM (internal concurrent manager) to be running in one application instance, which relates to error message in manager logfile.
Moreover, FNDSM is not able to complete its job of starting respective processes on the defined nodes.
Fix
1. Ensure that APPLDCP is set to ON in your $APPL_TOP/.env file.
2. Echo environment variable on command line prior to starting concurrent managers.
3. Execute adcmctl.sh only on the primary node of the Internal Concurrent Manager.

FNDCPVCM.fmb

concurrent requests are stuck in pending status

Below are several different possible solutions to the problem where concurrent requests are stuck in pending status:

1.  When shutting down the concurrent managers are there any FNDLIBR processes still running at the OS level?   If so, do a kill -9 on them,
then restart the concurrent managers.

2.  Try Relinking $FND_TOP.

3.  Rebuild the concurrent manager views.  As applmgr run the following from the OS:

This is non-destructive.
Concurrent Manager views can be rebuilt by running the following command at the command line:
Ensure that concurrent managers are shutdown.

FNDLIBR FND FNDCPBWV apps/apps SYSADMIN 'System Administrator' SYSADMIN

Restart the concurrent managers.

4.  The Profile Option 'Concurrent: OPS Request Partitioning' may be set incorrectly. This profile option should always be set to
OFF, regardless of whether you are running OPS(RAC) or not, because the profile is obsolete.

5.  The System Profile Option: Concurrent Active Requests is possibly to 0.
        a.  Log into Oracle Applications as SYSADMIN.
        b.  Select System Administrator responsibility.
        c.  Navigate to PROFILE > SYSTEM.
        d.  Query for %CONC%ACTIVE%.
        e.  Change the profile option for 'Concurrent: Active Request Limit' to Null (blank).
        f.  Exit Oracle Applications and log in again for the change to take affect.
        g.  Run a new concurrent request.

6.  The Concurrent managers were brought down, while an outstanding request was still running in the background.  In which case, update the
FND_CONCURRENT_REQUESTS table as follows:

sql>
update fnd_concurrent_requests
set status_code='X', phase_code='C'
where status_code='T';
sql> commit;

7.   The control_code for concurrent_queue_name = 'FNDCRM' is 'N' in the FND_CONCURRENT_QUEUES table,  which means 'Target node/queue unavailable'.
This value should be NULL (CRM is running; target and actual process amount are the same), or 'A' ('Activate concurrent manager' control status).
Set the control_code to 'A' in fnd_concurrent_queues for the Conflict Resolution Manager:
       a.  Logon to Oracle Applications database server as 'applmgr'.
       b.  Verify the Applications environment is setup correctly ($ORACLE_HOME and $ORACLE_SID).
       c.  Logon to SQL*Plus as 'APPS' and run the following SQL statement:
            update fnd_concurrent_queues
            set control_code = 'A'
            where concurrent_queue_name = 'FNDCRM';
            commit;
       d.  Verify the status of the concurrent managers through the  Concurrent -> Manager -> Administer form.

If the CRM is still not active, bounce (deactivate, activate) the Internal Concurrent Manager.  This is done through the Concurrent > Manager >  Administer form
from the 'System Administrator' responsibility. It can also be done through the CONCSUB command at the command level.     

Setting the control_code to 'A' in the fnd_concurrent_queues table for the Conflict Resolution Manager indicates that this concurrent manager
is to be activated with the parameter values specified through this table for this manager (MAX_PROCESSES, CACHE_SIZE, etc).

8.  What is the cache size?   Try increasing the cache size then stop/restart the concurrent managers.
If concurrent requests are rarely prioritized and there are managers that service short-running requests, consider setting the cache size to
equal at least twice the number of target processes.  This increases the throughput of the concurrent managers by attempting to avoid any sleep time.
For example:
If more than one manager or worker processes the same type of requests with only a small cache size, it may be unable to process any jobs in a
single processing cycle, because other processes have already run the cached requests.
When this happens, it is important to note that the manager will sleep before refreshing its cache.  To increase manager throughput where there
are sufficient requests of the required type in the queue, increase the cache size to improve the chance of the manager finding work to process
and thus avoid having to enter a sleep phase.

TIP: Ensure that the system is not resource-constrained before attempting to increase the rate of concurrent processing in this way, otherwise,
these changes may actually reduce concurrent processing throughput because jobs take longer to run.

Changes in R12 (12.2)

1. Oracle E-Business Suite R12 (12.2) uses Oracle Fusion Middleware 11g R1 PS3 (11.1.1.4) including WebLogic 10.3.4 as its application server (Note: In previous version of R12 i.e. 12.0.X and 12.1.X this is 10g R3 i.e. 10.1.3.X). Oracle HTTP server in R12 (12.2) is 11.1.1.4 . 2. Oracle E-Business Suite R12 (12.2) uses Oracle Application Server 10g R3 (10.1.2.3) for Forms & Reports (Note: In previous version of R12 i.e. 12.0.X and 12.1.X, forms are reports are of same version i.e. 10.1.2.3) 3. Default Database for Oracle E-Business Suite R12 (12.2) is 11g R2 (11.2.X) . (Note: In previous version of R12 i.e. 12.0.X, default database is 11.1 and 12.1.X, default database is 11.2) 4. Oracle JSP Compiler (OJSP) 10.1.3.5 (12.0.X and 12.1.X) is replaced by WebLogic JSP Compiler 11.1.1.4 in R12 version 12.2 5.Online Patching (OLP) introduced in Oracle Apps 12.2 , uses Oracle Database edition-based redefinition to reduce patch down time (more on edition-based redefinition coming soon). A secondary file system for application tier (in Apps R12 - 12.2) is introduced to support OnLine Patching (OLP) . 6. Oracle Apps R12.2 cloning will also support Fusion Middleware (11.1.1.4 - discussed in point 1) cloning. For standalone cloning of Fusion Middleware 11gR1 click here 7. Oracle Web Applications Desktop Integrator (Web ADI) in R12.2 is now certified with Microsoft Office 32-bit and 64-bit.