ORACLE ERROR : ORA-28000
The account is locked
From your command prompt, type sqlplus “/ as sysdba”
Once logged in as SYSDBA, you need to unlock the SCOTT account
SQL> alter user scott account unlock;
SQL> grant connect, resource to scott;
ICX:Session Timeout to change the session Timeout in Oracle Apps R122 version:
Increase oracle forms session timeout in r122
To change oracle forms session time out via “ICX:session Timeout” Profile in oracle application.
ICX:Session Timeout is a profile provided in Oracle apps which controls the time for which a session is valid. Post that time out limit, the user gets below error.
Log on session is no longer valid. Would you like to log back in so you can continue working? If you do not log in, any outstanding data changes in your forms will not be saved.

When the user clicks on the Yes button, App opens the login page. Enter the password and login again to continue. Click No to exit from the current session.
30 minutes is the value of this profile in any production instance. It is fine for production instance but for development instance, this may not be ideal, as you will repeatedly get this message and you need to log in again and again.
Just increase the value of this profile to avoid the timeout message.
Set ICX:Session Timeout profile
Now let me show how you can change this profile. You can set this profile at the site or user level. It is always better to set at the user level.
Log in to Oracle Apps Instance. Navigate to System Administrator->Profile->System. Query profile the ICX:Session Timeout for the user. The default value is 30 and is set at the site level. We are going to set it a user level.
Enter the new value greater than 30 and click on Save.
Log off and log in again.
This will make sure that your Oracle apps session will never time out in a smaller interval.
Summary :
ICX:Session Timeout provides an easy way to increase the session limit. It is good to increase only in development or test instance, but production let it be default 30.
This tip should work for both Oracle App 11i and R12 release. I hope you found this small tip useful.
To set the User Session Timeout, test the following steps in a development instance and then migrate accordingly !!
If suppose we executed autoconfig on application again default value 30 will be added to “ICX:session Timeout” Profile.
So we need to change the value in autoconfig file itself.
1. If R12.2 EBS instance view $CONTEXT_FILE change the value for vairable “s_sessiontimeout” in config file then execute the autoconfig.sh in oracle application.
1. Log on to Oracle Applications with
Responsibility = System Administrator
2. Submit Request Window
Navigate to: Concurrent > Requests
3. Query for the Gather Schema Statistics
4. Enter the appropriate parameters. This can be run for specific schemas by specifying the schema name or entering ‘ALL’ to gather statistics for every schema in the database
5. Submit the Gather Schema Statistics program
Parameters :
Schema Name:
Schema for which statistics are to be gathered. Specify ALL for all Oracle Applications schemas
Percent:
The sampling percentage. If left blank, the default value of 10 is used. The valid range is from 0 to 100
Degree:
The degree of parallelism to be used for gathering statistics. If a Degree is not provided, it defaults to the minimum of parallel_max_servers and cpu_count.
Backup Flag: NO BACKUP is used,
then the GATHER_SCHEMA_STATS procedure will not backup the current statistics. This way the GATHER_SCHEMA_STATS procedure will run faster.
Restart Request ID:
In the case where the Gather Schema Statistics run fails due to whatever reasons, the concurrent request can be re-submitted and it will pick up where the failed run left off, if you provide the concurrent request_id of the failed run.
History Mode: Last Run – History records for each object are maintained only for the last gather statistics run. Each subsequent run will overwrite the previous history record for the object. This is the default behavior
Gather Options:
GATHER: All tables and indexes of the schema schema name are selected for stats gathering. This is the default
Gather Options This parameter specifies how objects are selected for statistics gathering.
GATHER : All tables and indexes of the schema schemaname are selected for stats gathering. This is the default.
GATHER AUTO : Tables of the schema schemaname for which the percentage of modifications has exceeded modpercent are selected for statistics gathering.
Indexes of these tables are selected by default. Table monitoring needs to be enabled before using this option.
GATHER EMPTY : Statistics are gathered only for tables and indexes that are missing statistics.
LIST AUTO : This option does not gather statistics. It only provides a listing of all the tables that will be selected for statistic gathering,
if the GATHER AUTO option is used.
LIST EMPTY : This option does not gather statistics. It only provides a listing of all the tables that will be selected for statistics gathering,
if the GATHER EMPTY option is used.
Modifications Threshold: Applicable only to GATHER AUTO and LIST AUTO Options
Invalidate Dependent Cursors: This flag indicates whether cursors dependent on the table being analyzed should be invalidated or not. By default, dependent cursors are invalidated.
E-Business Suite R12 Concurrent Processing, Output Post Processing related issues
Requests fail during Post Processing with the following errors :
‘Unable to find an Output Post Processor service to post-process request xxxxx.
Check that the Output Post Processor service is running’
Cause :
Incorrect data is present in the OPP queue table AQ$FND_CP_GSM_OPP_AQTBL_S, which occurs when the concurrent managers are not shutdown correctly.
A quick sql query shows orphaned OPP subscribers in APPLSYS.AQ$FND_CP_GSM_OPP_AQTBL_S, causing the select_random_subscriber routine to pick a non-running process.
Solution :
To resolve the issue test the following steps in a development instance and then migrate accordingly:
1. Find the active processes for OPP :
SELECT fcp.concurrent_process_id
FROM fnd_concurrent_queues fcq, fnd_concurrent_processes fcp
WHERE concurrent_queue_name = ‘FNDCPOPP’
AND fcq.concurrent_queue_id = fcp.concurrent_queue_id
AND fcq.application_id = fcp.queue_application_id
AND fcp.process_status_code = ‘A’;
Output example:
CONCURRENT_PROCESS_ID
———————
93557
93558
2. Find the OPP subscribers :
select name from APPLSYS.AQ$FND_CP_GSM_OPP_AQTBL_S ;
The name in the table is the concurrent_process_id prefixed with ‘OPP’.
The output should normally correspond to the output of first query: have the same number of records and have as name the concurrent_process_id of the running OPP processes prefixed by OPP
Output example:
NAME
——————————
OPP35562
OPP35563
OPP35564
OPP35565
3. If there are any old process which are left from previous runs of OPP processes, unsubscribe them via the following command:
exec fnd_cp_opp_ipc.unsubscribe(”);
Example:
exec fnd_cp_opp_ipc.unsubscribe(‘88933’);
exec fnd_cp_opp_ipc.unsubscribe(‘92625’);
4. Bounce the concurrent managers.
5. Retest some concurrent requests and confirm the post processing actions now complete successfully.
Output Post Processor (OPP) – An Overview
Maximum Memory Usage Per Process :
The maximum amount of memory or maximum Java heap size a single OPP process can use is by default set to 512MB. This value is seeded by the Loader Data File:
$FND_TOP/patch/115/import/US/afoppsrv.ldt which specifies that the DEVELOPER_PARAMETERS is “J:oracle.apps.fnd.cp.gsf.GSMServiceController:-mx512m”.
Determine the current maximum Java heap size :
SELECT service_id, service_handle, developer_parameters
FROM fnd_cp_services
WHERE service_id = (SELECT manager_type
FROM fnd_concurrent_queues
WHERE concurrent_queue_name = 'FNDCPOPP');
SERVICE_ID SERVICE_HANDLE DEVELOPER_PARAMETERS
1091 FNDOPP J:oracle.apps.fnd.cp.gsf.GSMServiceController:-mx512m
Increase the maximum Java heap size for the OPP to 1024MB (1GB) :
UPDATE fnd_cp_services
SET developer_parameters =
'J:oracle.apps.fnd.cp.gsf.GSMServiceController:-mx1024m'
WHERE service_id = (SELECT manager_type
FROM fnd_concurrent_queues
WHERE concurrent_queue_name = 'FNDCPOPP');
The OPP queue can be Recreated the using $FND_TOP/patch/115/sql/afopp002.sql file as
‘APPLSYS’ user. On running the script you will be prompted for username and password.
There are two new profiles options that can be used to control the timeouts :
Profile Option : Concurrent:OPP Response Timeout
Internal Name : CONC_PP_RESPONSE_TIMEOUT
Description : Specifies the amount of time a manager waits for OPP to respond to its
request for post processing.
Profile Option : Concurrent:OPP Process Timeout
Internal Name : CONC_PP_PROCESS_TIMEOUT
Description : Specifies the amount of time the manager waits for the OPP to actually
process the request.