DBC creation

Before you run the AdminAppServer utility, check the following: Your


CLASSPATH contains the full path of the jdbc classes111.zip file.
This is usually $ORACLE_HOME/jdbc/lib/classes111.zip. Your
LD_LIBRARY_PATH contains the directory, which contains the jdbc oci
library file. This is usually $ORACLE_HOME/lib.

jre oracle.apps.fnd.security.AdminAppServer apps/@ ADD
FNDNAM=apps GWYUID=applsyspub/pub TWO_TASK=
SECURE_PATH=$FND_TOP/secure GUEST_USER_PWD=GUEST/ORACLE
APPS_JDBC_DRIVER_TYPE=THIN DB_HOST=hostname.xxxxx.in DB_PORT=1531

DBCA Templates
Metalink Note:148676.1
https://metalink.oracle.com/metalink/plsql/f?p=130:14:10696451704012263570::::p14_database_id,p14_docid,p14_show_header,p14_show_help,p14_black_frame,p14_font:NOT,148676.1,1,1,1,helvetica

Data guard

Data guard

Introduction:
Dataguard is configured to ensure the availability of database in case of disaster.
This document explains how to configure the physical standby database for switchover and fail over operations.

Prerequest:

• Same Oracle software release must be used for both primary and standby databases. The operating system running on primary and standby locations must be same, but operating system release may not need to be same.
• The Primary Database must run in ARCHIVELOG mode.
• The hardware and Operating system architecture on primary and standby location must be same.
• Each primary and standby database must have its own control file.
• If primary and standby databases are placed on the same system, initialization parameters must be adjusted correctly.
• Primary database must be FORCE LOGGING mode.

Preparing Primary Database for standby creation
To ensure that database in archive log mode, execute the following command.

SQL>archive log list

Enable database in Force logging mode

SQL>Alter database force logging;

Identify the location of the datafiles
SQL>select name from v$datafile;

Make a copy of the primary database

First step: Shutdown the primary database

SQL>shutdown immediate;

Second step: copy the datafiles manually to standby location

SQL>startup;

Create the standby control file by using the following command

SQL>alter database create standby controlfile as ‘D:\oracle\oradata\controlstby.ctl’

Create pfile from spfile. And save the same pfile to standby location;

Set the initialization parameters for the primary database and standby database as given below
Parameter file for Primary Database
aq_tm_processes=1
background_dump_dest='D:\oracle\admin\Orclc\bdump'
compatible='9.2.0.0.0'
control_files='C:\oracle\oradata\Orclc\CONTROL01.CTL',
'C:\oracle\oradata\Orclc\CONTROL02.CTL','C:\oracle\oradata\Orclc\CONTROL03.CTL'
core_dump_dest='D:\oracle\admin\Orclc\cdump'
db_block_size=8192
db_cache_size=25165824
db_domain=''
db_file_multiblock_read_count=16
db_name='Orclc'
dispatchers='(PROTOCOL=TCP) (SERVICE=OrclcXDB)'
fast_start_mttr_target=300
hash_join_enabled=TRUE
instance_name='Orclc'
java_pool_size=33554432
job_queue_processes=10
large_pool_size=8388608
log_archive_dest_1='LOCATION=C:\oracle\ora92\database\archive MANDATORY'
log_archive_dest_2='SERVICE=stby'
log_archive_dest_state_2='ENABLE'
log_archive_start=true
open_cursors=300
pga_aggregate_target=25165824
processes=150
query_rewrite_enabled='FALSE'
remote_login_passwordfile='EXCLUSIVE'
shared_pool_size=50331648
sort_area_size=524288
star_transformation_enabled='FALSE'
timed_statistics=TRUE
undo_management='AUTO'
undo_retention=10800
undo_tablespace='UNDOTBS1'
user_dump_dest='D:\oracle\admin\Orclc\udump'



Parameter file for Standby Database
aq_tm_processes=1
background_dump_dest='D:\oracle\admin\stby\bdump'
compatible='9.2.0.0.0'
control_files='D:\oracle\oradata\stby\CONTROL_SB01.CTL'
core_dump_dest='D:\oracle\admin\stby\cdump'
db_block_size=8192
db_cache_size=25165824
db_domain=''
db_file_multiblock_read_count=16
db_name='Orclc'
dispatchers='(PROTOCOL=TCP) (SERVICE=OrclcXDB)'
fast_start_mttr_target=300
hash_join_enabled=TRUE
instance_name='stby'
java_pool_size=33554432
job_queue_processes=10
large_pool_size=8388608
log_archive_dest_1='LOCATION=D:\oracle\admin\stby\archive'
log_archive_dest_state_1=enable
log_archive_start=true
open_cursors=300
pga_aggregate_target=25165824
processes=150
query_rewrite_enabled='FALSE'
remote_login_passwordfile='NONE'
shared_pool_size=50331648
sort_area_size=524288
star_transformation_enabled='FALSE'
timed_statistics=TRUE
undo_management='AUTO'
undo_retention=10800
undo_tablespace='UNDOTBS1'
user_dump_dest='D:\oracle\admin\stby\udump'
standby_archive_dest='C:\oracle\ora92\database\archive\ORCLC'
db_file_name_convert='C:\oracle\oradata\Orclc','D:\oracle\oradata\stby'
log_file_name_convert='C:\oracle\oradata\Orclc','D:\oracle\oradata\stby'
standby_file_management=AUTO
remote_archive_enable=TRUE
lock_name_space=stby

Configure listeners & tnsnames for standby and primary databases
Configure listeners in listeners.ora as follows
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = oraserver)(PORT = 1521))
)
)
)

SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = D:\oracle\ora92)
(PROGRAM = extproc)
)
(SID_DESC =
(GLOBAL_DBNAME = Orcl)
(ORACLE_HOME = D:\oracle\ora92)
(SID_NAME = Orcl)
)
(SID_DESC =
(GLOBAL_DBNAME = stby)
(ORACLE_HOME = D:\oracle\ora92)
(SID_NAME = stby)
)
)
Restart the listeners using LSNRCTL utility.
% lsnrctl stop
% lsnrctl start
Also make an entry into tnsnames.ora for standby database.
stby =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = oraserver)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = stby)
)
)


Start Physical standby database
Start up the stand by database using following commands
C:\>set oracle_sid=stby

C:\>sqlplus /nolog

SQL*Plus: Release 9.2.0.1.0 - Production on Mon Apr 25 17:13:26 2005

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup pfile='C:\oracle\ora92\database\initstby.ora' nomount;
ORACLE instance started.
Total System Global Area 135338868 bytes
Fixed Size 453492 bytes
Variable Size 109051904 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes

SQL> alter database mount standby database;
Database altered.
12 - Enabling archiving to Physical Standby Database
To configure archive logging from the primary database to the standby site the LOG_ARCHIVE_DEST_n and LOG_ARCHIVE_DEST_STATE_n parameters must be defined.

Issue following commands from primary database session:
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=stby' SCOPE=BOTH;

System altered.

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;

System altered.
13 - Initiate Log apply services
The example includes the DISCONNECT FROM SESSION option so that log apply services run in a background session.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Database altered.

SQL> alter database open read only;
alter database open read only
*
ERROR at line 1:
ORA-01154: database busy. Open, close, mount, and dismount not allowed now

SQL> recover managed standby database cancel;
Media recovery complete.

Now go to primary database prompt

SQL> alter system switch logfile;

Go to stand by database prompt

SQL> alter database open read only;

Database altered.
14 - Verifying the Standby Database
On standby database query the V$ARCHIVED_LOG view to verify that redo log received.
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME
2> FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

SEQUENCE# FIRST_TIME NEXT_TIME
-------------- ------------------- ----------------------
14 25-APR-05 16:50:34 25-APR-02 16:50:42
15 25-APR-05 16:50:42 25-APR-02 16:50:47
16 25-APR-05 16:50:47 25-APR-02 16:51:52

Archive the current log on the primary database using following statement.
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
On standby database query the V$ARCHIVED_LOG view
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME
2> FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

SEQUENCE# FIRST_TIME NEXT_TIME
-------------- ------------------- ----------------------
14 25-APR-05 16:50:34 25-APR-02 16:50:42
15 25-APR-05 16:50:42 25-APR-02 16:50:47
16 25-APR-05 16:50:47 25-APR-02 16:51:52
17 25-APR-05 16:51:52 25-APR-02 17:34:00
Now connect scott/tiger@orclc on primary database and create table or insert row in any table.

Now connect as sys on primary database and execute following SQL statement
SQL> alter system switch logfile;
On standby database execute following SQL statements
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Database altered.

SQL> recover managed standby database cancel;
Media recovery complete.

SQL> alter database open read only;

Database altered.
And check whether the changes applied on the standby database or not.




Oracle9i Release 2: Using the DBNEWID Utility

Only the DBID of a database
Only the DBNAME of a database

1. Make a whole database backup.
2. Invoke SQL*Plus and connect as a user with SYSDBA privileges.
3. Issue the following query to determine the current DBID:
SELECT dbid, name FROM v$database;
4. Shut down the instance using the NORMAL, IMMEDIATE, or TRANSACTIONAL options:
SHUTDOWN IMMEDIATE OR NORMAL
5. Start the instance and mount the database, specifying the parameter file if you are not using a server parameter file or the text initialization parameter file is not in the default location:
STARTUP MOUNT
6. Invoke the DBNEWID utility on the command line, specifying a valid user with the SYSDBA privilege. The DBNEWID utility performs validations of the headers of the data files and control files before attempting I/O to the files. If validation is successful, then DBNEWID prompts you to confirm the operation unless you specify a log file, changes the DBID for each data file (including offline normal and read-only data files), and then exits. The database is left mounted but is not yet usable.
nid TARGET=SYS/secure@
i.e: nid TARGET=SYS/PASSWORD@TEST
7. After DBNEWID successfully changes the DBID, shut down the instance:
SHUTDOWN IMMEDIATE OR NORMAL

8. Create a new password file using the ORAPWD utility:
orapwd file=orapw password= entries=

9. Start the instance and mount the database:
STARTUP MOUNT;
10. Open the database with the RESETLOGS option:
ALTER DATABASE OPEN RESETLOGS;

11. Verify the change to the DBID by issuing the following query:
SELECT dbid, name FROM v$database;

Changing Your Database Name (DBNAME)

1. Make a whole database backup.
2. Invoke SQL*Plus and connect as a user with SYSDBA privileges.
3. Issue the following query to determine the current DBID:
SELECT dbid, name FROM v$database;
4. Shut down the instance using the NORMAL, IMMEDIATE, or TRANSACTIONAL options:
SHUTDOWN IMMEDIATE OR NORMAL
5. Start the instance and mount the database, specifying the parameter file if you are not using a server parameter file or the text initialization parameter file is not in the default location:
STARTUP MOUNT
6. Invoke the DBNEWID utility on the command line, specifying a valid user with the SYSDBA privilege. You must specify the DBNAME parameter and supply your new database name. You must also specify the YES value for the SETNAME parameter to indicate that only the DBNAME is to be changed. DBNEWID performs validations of the headers of the control files, but not the data files, before attempting I/O to the files. If validation is successful, then DBNEWID prompts for confirmation, changes the database name in the control files, and exits. After DBNEWID completes successfully, the database is left mounted but is not yet usable.
nid TARGET=/@ DBNAME= SETNAME=YES
i.e: nid TARGET=SYS/PASSWORD@TEST DBNAME=DEVEL SETNAME=YES
7. After DBNEWID successfully changes the DBID, shut down the instance:
SHUTDOWN IMMEDIATE OR NORMAL

8. Create a new password file using the ORAPWD utility:
orapwd file=orapw password= entries=
9. Change the DB_NAME initialization parameter to your new database name
10. Start the instance and mount the database:
STARTUP

11. Verify the change to the DBID by issuing the following query:
SELECT dbid, name FROM v$database;

Database & Apps 11i Cloning and Multi Node to Single Node Cloning



Database & Apps 11i Cloning and Multi Node to Single Node Cloning

Copy AutoConfig to the RDBMS ORACLE_HOME
Update the RDBMS ORACLE_HOME file system with the AutoConfig files by performing the following steps:

On the Application Tier (as the APPLMGR user):

Log in to the APPL_TOP environment (source the environment file)
Create appsutil.zip file
perl /bin/admkappsutil.pl
This will create appsutil.zip in $APPL_TOP/admin/out.

On the Database Tier (as the ORACLE user):

Copy or FTP the appsutil.zip file to the
cd
unzip -o appsutil.zip

Generate your Database Context File
If your Applications system was created with the Release 11.5.9 Rapid Install or later, go to Task 3 in this section.
If your Applications system was created with the Release 11.5.8 Rapid Install or earlier, execute the following commands to create your Database Context File:

On UNIX
cd
. .env
cd /appsutil/bin
perl adbldxml.pl tier=db appsuser= appspasswd=


On Windows
Source the cmd Window using \.cmd
cd /d \appsutil\bin
perl adbldxml.pl tier=db appsuser= appspasswd=

Generate and Apply AutoConfig Configuration files

Attention: This step performs the conversion to AutoConfig. Once completed, the previous configuration will not be available.

Attention: The database server and the database listener must remain available during the AutoConfig run. All the other database tier services should be shut down.
Execute the following commands:
On UNIX
cd /appsutil/bin
adconfig.sh contextfile= appspass=

On Windows
cd /d \appsutil\bin
adconfig.cmd contextfile= appspass=

Warning: Running AutoConfig on the database node will update the RDBMS network listener file. Be sure to review the configuration changes from step 3. The new AutoConfig network listener file supports the use of IFILE to allow for values to be customized or added as needed.

Note: Running AutoConfig on the database tier will NOT overwrite any existing init.ora file. If no init.ora file exists in your instance, AutoConfig will generate an init.ora file for you.

Prepare the source system database tier for cloning
Log on to the source system as the ORACLE user and run the following commands:
cd /appsutil/scripts/
perl adpreclone.pl dbTier

APPLICATION TIER CLONING

Find or generate your Oracle Applications Context File
Look for the following file in the APPL_TOP:

/admin/.xml

On UNIX
cd /bin
perl adbldxml.pl tier=apps appsuser= appspasswd=

On Windows
cd /d \bin
perl adbldxml.pl tier=apps appsuser= appspasswd=

Generate and Apply AutoConfig Configuration files

Execute the following command:
On UNIX
/bin/adconfig.sh contextfile= appspass=

On Windows
\bin\adconfig.cmd contextfile= appspass=

Prepare the source system application tier for cloning

Log on to the source system as the APPLMGR user and run the following commands on each node that contains an APPL_TOP:
cd /admin/scripts/
perl adpreclone.pl appsTier

Copy the application tier file system
Log on to the source system application tier nodes as the APPLMGR user.
Shut down the application tier server processes
Copy the following application tier directories from the source node to the target application tier node:





/util
/clone
/_pages (when this directory exists)
<806>


Copy the database tier file system
Log on to the source system database node as the ORACLE user.
Perform a normal shutdown of the source system database
Copy the database (DBF) files from the source to the target system
Copy the source database ORACLE_HOME to the target system
Start up the source Applications system database and application tier processes

POST CLONING

Configure the target system database server
Log on to the target system as the ORACLE user and type the following commands to configure and start the database:

cd /appsutil/clone/bin
perl adcfgclone.pl dbTier

Configure the target system application tier server nodes
Log on to the target system as the APPLMGR user and type the following commands:

cd /clone/bin
perl adcfgclone.pl appsTier



Multi Node to Single Node Cloning

With Oracle Applications 11.5.10 the ability to clone from a multi node to a single node system using rapid clone has now been certified.

This is accomplished by the Shared APPL_TOP and Merging APPL_TOP features.

In this post i am listing out the steps to perform a multi note to a single node cloning from scratch. The information mentioned here is the steps which i have used and found them to be successful for a more elaborate explanation you might want to refer to the metalink note Sharing the Application Tier File System in Oracle E-Business Suite 11i (233428.1).

Source System here refers to the multi node system to be cloned
Target System refers to the newly to be created single node system
Applications Version 11.5.10
Operating System Linux ES 4

The following Steps are required to be performed on the source system
1. Apply application tier patches using adpatch

Apply patch 4038964Apply patch 4175764
Both the above patches are include in the consolidated update 2 or CU2 so in case you are on 11.5.10.2 or later you can ignore this step.

2. Maintain snapshot information

Log in as the applications user on each application tier node and run 'Maintain Snapshot Information' by using adadmin.

3. Merge existing APPL_TOPs

Log in to the primary node of your application tier as the application user user and run:
$ cd [COMMON_TOP]/admin/scripts/[CONTEXT_NAME]$ perl adpreclone.pl appsTier merge
This will prompt you with option to merge secondary nodes
Now log in as the applications user to each of the secondary application tier nodes being merged and run:
$ cd [COMMON_TOP]/admin/scripts/[CONTEXT_NAME]$ perl adpreclone.pl appltop merge

4. Prepare the source system database tier.
Log on to the database tier of the source system as the oracle user and run the following commands:
$ cd [RDBMS ORACLE_HOME]/appsutil/scripts/[CONTEXT_NAME]$ perl adpreclone.pl dbTier
With this all the pre clone tasks on the source system have been completed.
The next set of tasks are required to be carried out on the target system that is the system on which you wish to place the merged single node instance.

1. Create OS user accounts

Create a OS user account for your applications
$ useradd -g dba -d [home_directory] -p password username
Similarly create a OS user account for your database

2. Modify the orainventory to reflect the new location

$ vi /etc/oraInst.loc

3. Copy the following application tier directories

Copy the following application tier directories from the primary node of your source system to the target application tier node, retaining the original directory structure:
– [APPL_TOP]– [OA_HTML]– [OA_JAVA]– [COMMON_TOP/util]– [COMMON_TOP/clone>– [806 ORACLE_HOME]– [iAS ORACLE_HOME]

4. Copy the required files for merging

Log in as the applications user to each of the secondary source nodes and recursively copy:
directory [COMMON_TOP]/clone/appl- to -directory [COMMMON_TOP]/clone/appl on the target system node
Before proceeding with the next steps you must shutdown your oracle applications services and the database on the source system

5. Copy the database tier file system

Log on to the source system as the database user
Copy the database (DBF) files from the source to the target systemCopy the source database ORACLE_HOME to the target system
After this you can now startup the database and applications services on your source system and release it for use.

6. Configure the target system database server

Log on to the target system as the database user and type the following commands to configure and start the database:
$ cd [RDBMS ORACLE_HOME]/appsutil/clone/bin$ perl adcfgclone.pl dbTier
This will prompt for new ORACLE_SID,ORACLE_HOME,Port Pool,JAVA_TOP and DATA_TOP give the appropriate values matching your target system
Once successful this should start your database and listener

7. Configure the application tier server nodes

The database and its listener should remain up before executing the next set of commands.Log in to the merged APPL_TOP node as the applications user and execute the following commands:
$ cd [COMMON_TOP]/clone/bin$ perl adcfgclone.pl appsTier
This will prompt you new port pool for applictaion tier services as well as new APPLTOP,COMMON_TOP,ORACLE_HOME and IAS_TOP
Successful completion of this task will bring up your application tier services on the target or the cloned node.

8. Post Clone Tasks

Log in to the target system application tier node as the APPLMGR user.Run the following tasks in adadmin for all products:o generate JAR fileso generate message fileso relink executableso copy files to destination

9. Clean up of the target system

Remove the temporary directory [COMMON_TOP]/clone/appl to reduce disk space usage.
Note: The version of Oracle Applications used is 11.5.10 and the operating system is Linux ES 4

Create Recovery Catalog

Create Recovery Catalog

First create a user to hold the recovery catalog:
STEP 1
CONNECT sys/chnangeoninstall@RMAN AS SYSDBA

-- Create tablepsace to hold repository

CREATE TABLESPACE RMAN
DATAFILE '/d05/rmancat/rmandata/RMAN01.DBF' SIZE 500M REUSE
AUTOEXTEND ON NEXT 64K MAXSIZE 32767M
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO;

create temporary tablespace TEMP tempfile '/d05/rmancat/rmandata/temp01.dbf' size 500M reuse
autoextend on next 32m maxsize 2048m
extent management local;

-- Create rman schema owner
STEP 2
CREATE USER rman IDENTIFIED BY rman
TEMPORARY TABLESPACE temp
DEFAULT TABLESPACE rman
QUOTA UNLIMITED ON rman;

STEP 3

GRANT connect, resource, recovery_catalog_owner TO rman;

STEP 4

Then create the recovery catalog:

$ rman catalog=rman/rman@RMAN

Recovery Manager: Release 9.2.0.3.0 - Production

Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.

connected to recovery catalog database
recovery catalog is not installed

RMAN> create catalog tablespace "RMAN";

recovery catalog created

RMAN> exit

Recovery Manager complete.

Register Database
Each database to be backed up by RMAN must be registered:

$ rman catalog=rman/rman@RMANCAT target=sys/oracle@TEST
Recovery Manager: Release 9.2.0.3.0 - Production

Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.

connected to target database: TEST (DBID=1371963417)
connected to recovery catalog database

RMAN> register database;

database registered in recovery catalog
starting full resync of recovery catalog
full resync complete

FND Concurrent Manager FAQ's

When would one be required to bounce (stop and restart) the Concurrent Manager?

When you modify the Printer Driver you have to restart the Manager which
runs the request which is attached to that Printer Driver, however,if you do
not know which manager then you have to restart the Internal manager because
the printer driver can be used by multiple managers and multiple requests.
If only a concurrent program definition is modified, running a verify on the
Internal Manager will pick up the changes without the need for bouncing the
manager.



Does the Internal manager schedule requests to be run or does it put requests
into queues to be run by other managers?


This is a very common misconception. The ICM really does not have any
such scheduling responsibilities. It has NOTHING to do with scheduling
requests, or deciding which manager will run a particular request.
Its function is only to run 'queue control' requests, which are
requests to startup or shutdown other managers. It is responsible for
startup and shutdown of the whole concurrent processing facility, and
it also monitors the other managers periodically, and restarts them if
they should go down. It can also take over the Conflict Resolution
manager's job, and resolve incompatibilities.


If the ICM itself should go down, requests will continue to run
normally, except for 'queue control' requests. You can restart it with
'startmgr', you do not need to kill the other managers first.



How can I check to see if a concurrent manager is running?

One way to see if a manager is running is to use the 'Administer
Concurrent Managers' form. Navigate to Concurrent->Managers->Administer.
You will see two columns labeled 'Actual' and 'Target'. The Target column
lists the number of processes that should be running for each manager
for this particular workshift. The Actual column lists the number of
processes that are actually running. If the Actual column is zero, there
are no processes running for this manager. If the Target column is zero,
then either a workshift has not been assigned to this manager, or the current
workshift does not specify any target processes. If the target column
is not zero, then the manager processes have either failed to start up,
or gone down. You should check the manager's logfile and the ICM
logfile. You can also search for OS processes using the 'ps' command.
It is possible for the form to be inaccurate, i.e. it may show actual
processes even though they are not really running. When in doubt, check for
processes at the OS level. On NT, you can check to see if the Concurrent Manager
service is running using the Services control panel.



Where do concurrent request or manager logfiles and output files go?

The concurrent manager first looks for the environment variable
$APPLCSF. If this is set, it creates a path using two other
environment variables: $APPLLOG and $APPLOUT
It places log files in $APPLCSF/$APPLLOG, output files go in
$APPLCSF/$APPLOUT

So for example, if you have this environment set:
$APPLCSF = /u01/appl/common
$APPLLOG = log
$APPLOUT = out


The concurrent manager will place log files in /u01/appl/common/log,
and output files in /u01/appl/common/out
Note that $APPLCSF must be a full, absolute path, and the other two
are directory names.

If $APPLCSF is not set, it places the files under the product top of
the application associated with the request. For example, a PO report
would go under $PO_TOP/$APPLLOG and $PO_TOP/$APPLOUT
Logfiles go to: /u01/appl/po/9.0/log
Output files to: /u01/appl/po/9.0/out
All these directories must exist and have the correct permissions.

Note that all concurrent requests produce a log file, but not necessarily
an output file.
Concurrent manager logfiles follow the same convention, and will be
found in the $APPLLOG directory



What are the logfile and output file naming conventions?

Request logfiles: l.req


Output files: If $APPCPNAM is not set: .
If $APPCPNAM = REQID: o.out
If $APPCPNAM = USER: .out


Where: = The request id of the concurrent request
And: = The id of the user that submitted the request


Manager logfiles:


ICM logfile: Default is std.mgr, can be changed with the mgrname
startup parameter
Concurrent manager log: w.mgr
Transaction manager log: t.mgr
Conflict Resolution manager log: c.mgr


Where: is the concurrent process id of the manager



Can I delete a concurrent manager?

You can disable the manager by checking the 'Enabled' checkbox, or
you can simply Terminate the manager and it will not run again unless
you reactivate it.
If it is really necessary, you can query the manager in the
'Define Manager' form, and delete the row. (It is recommended that you
DO NOT do this)

What is the function of the 'Conflict Resolution Manager'?

Concurrent managers read requests to start concurrent programs running. The
Conflict Resolution Manager checks concurrent program definitions for
incompatibility rules.

If a program is identified as Run Alone, then the Conflict Resolution Manager
prevents the concurrent managers from starting other programs in the same
conflict domain.

When a program lists other programs as being incompatible with it, the
Conflict Resolution Manager prevents the program from starting until any
incompatible programs in the same domain have completed running.


What is the 'Internal Scheduler/Prereleaser' manager?

The short name for this manager is FNDSCH. It is also known as the
Advanced Scheduler/Prereleaser Manager. This manager is intended
to implement Advanced Schedules. Its job is to determine when a
scheduled request is ready to run. Advanced Schedules were not fully
implemented in Release 11.0, they are implemented in Release 11.5,
but are not widely used by the various Apps products. General Ledger
uses FNDSCH for financial schedules based on different calendars and
period types. It is then possible to schedule AutoAllocation sets,
Recurring Journals, MassAllocations, Budget Formulas, and MassBudgets
to run according to the General Ledger schedules that have been
defined.

If financial schedules in GL are not being used then it is not a
problem to deactivate this manager.



What is the 'Internal Monitor' manager/service?

This manager/service is used to implement Distributed Concurrent Processing.
It monitors whether the ICM is still running, and if the ICM crashes,
it will restart it on another node.
You do not need to run this manager/service unless you are using Distributed
Concurrent Processing.


See the Installation manual and Sysadmin Guide for more info on DCP.



How do I check/set the PMON method?

To check the PMON method:
1) cd $FND_TOP/sql
2) sqlplus apps/apps @afimchk.sql
This will tell whether the internal manager is running, what the PMON
method is, and where the log file is.


To set the PMON method:
1) first shut the concurrent managers down
2) cd $FND_TOP/sql
3) sqlplus apps/apps @afimpmon.sql LOCK (or RDBMS)




How do I enable/disable the Conflict Resolution Manager?

Use the system profile option 'Concurrent: Use ICM'.
Setting this to 'No' (which is the default) allows the CRM to be started.
Setting it to 'Yes' causes the CRM to be shutdown and the Internal
Manager (ICM) will take over the conflict resolution duties. If the CRM will
not start (it is started automatically by the ICM), check this profile option.


Note that using the ICM to resolve conflicts is not recommended.
The CRM's sole purpose is to resolve conflicts, while the ICM has
other functions to perform as well. Only set this option to 'YES'
if you have a good reason to do so.



How do I clean out the Concurrent Manager tables?

Cleaning out the tables is a useful method of making sure that there
are no invalid statuses that can prevent the managers from starting.
Previously, this has been done by truncating fnd_concurrent_processes
and/or fnd_concurrent_requests. Truncation of the tables is a little
drastic, and can cause problems later when trying to purge requests,
not to mention losing all of the request information.


Run the script, cmclean.sql, article Note 134007.1 CMCLEAN.SQL - Non
Destructive Script to Clean Concurrent Manager Tables
It will make sure the relevant status codes are valid without
deleting any information.



How do I tell concurrent manager processes apart at the OS level?

Use: pf -ef grep FNDLIBR


This will produce output like:


vd11 13703 13660 0 May 11 ? 0:01 FNDLIBR FND Concurrent_Processor
MANAGE OLOGIN="APPS/94A491A1000000000000000000
n1070161 24936 24927 0 Apr 29 ? 0:05 FNDLIBR FND Concurrent_Processor
MANAGE OLOGIN="APPS_APPDEMO/94C4B1C10000000000
n1070161 24938 24927 0 Apr 29 ? 0:06 FNDLIBR FND Concurrent_Processor
MANAGE OLOGIN="APPS_APPDEMO/94C4B1C10000000000
n1070161 24927 24922 0 Apr 29 ? 2:03 FNDLIBR FND CPMGR FNDCPMBR sysmgr
="" sleep=60 pmon=20 diag=N logfile=/u16/app


The last process, #24927, shows 'FNDLIBR FND CPMGR', this one is the
Internal Manager (ICM). Notice that it gives some of the parameters it
was started with, the other processes showing 'Concurrent_Processor'
are Standard manager processes. Notice that the ICM process is the
parent process of the Standard managers. (processes 24936 and 24938)

Other managers will have the name of the executable, like ARLIBR or
INVLIBR:

$ ps -ef grep ARLIBR
vd11 13683 13660 0 May 11 ? 0:20 ARLIBR APPS/82A2A4940000000000000
000000000000000000000000000000000000000 AR ART


The Conflict Resolution manager will look like:

$ ps -ef grep FNDCRM
n1070161 24941 24927 0 Apr 29 ? 1:17 FNDCRM APPS_APPDEMO/84BFBEB900000
0000000000000000000000000000000000000000000000



What is the syntax for controlling the concurrent manager using startmgr and
concsub in NT?

On NT, the concurrent manager is run as an NT service, you start and
stop the managers using the Services control panel.
See the Applications Installation manual for NT, Appendix A for
details. See pg. 5-9 of this manual for instructions on creating the
concurrent manager service.




Why am I seeing pinging entries like this in the ICM logfile?

PING (0.0.0.0): 56 data bytes
64 bytes from 192.75.91.2: icmp_seq=0 ttl=255 time=0.705 ms
64 bytes from 192.75.91.2: icmp_seq=1 ttl=255 time=1.120 ms
Process monitor session ended : 29-FEB-2000 10:38:43
64 bytes from 192.75.91.2: icmp_seq=2 ttl=255 time=0.985 ms
64 bytes from 192.75.91.2: icmp_seq=3 ttl=255 time=1.006 ms


Pinging other machines is used in Distributed Concurrent Processing.
This means you have DCP turned on, using the environment variable
APPLDCP. Set APPLDCP to OFF and restart the managers.



I hit the Restart button to start the Standard manager, but it still did not
start?


Telling a manager to restart just sets the status to Restart. The ICM
will start it the next process monitor session or the next time the
ICM starts. Use Activate to start a manager immediately.
When a manager is deactivated manually, the ICM will not restart
it, you will need to set it to Restart, or activate it manually.



How many rows are in FND_CONCURRENT_REQUESTS and FND_CONCURRENT_PROCESSES
tables?


When tables reach above 3000-4000 rows, the performance begins to
diminish. You may want to run Purge Concurrent Request on a regular basis,
dependant on the amount of requests being run.

The Purge Concurrent Requests job can be used to purge:
Requests, Mgr logs, and All requests depending on what is chosen.

Use the following options: Enter = All, Mode = AGE, Mode Value = 15

The std.mgr log continuously grows where it may good to
archive it regularly.



Any processes pending in Internal or Conflict Resolution Manager?

Best course of action before starting the Concurrent Managers is to cancel
any "Deactivate" or "Verify" jobs pending in the Internal Manager and place
any other pending jobs on hold.



How do I turn on transaction manager diagnostics?

Set the profile option 'Concurrent:Debug Flags' to 'TCTM1' at the site
level. This will cause transactions to make debug entries in the
FND_CONCURRENT_DEBUG_INFO table. Truncate this table before running a
tranasction, then select the entries from the table.
Starting the managers with diag=Y will also produce more information
in the transaction manager logfile.



How do transaction managers work?

Briefly:
(See the server documentation for details on the DBMS_PIPE package)
1) A tranasction manager is started on the concurrent processing
server, and periodically reads the pipe for incoming transactions.
2) A client program (usually a form) calls the
FND_TRANSACTION.SYNCHRONOUS function.
3) This function writes a message into the pipe containing the program
to be run and its parameters.
4) FND_TRANSACTION.SYNCHRONOUS begins reading a return pipe for the
return status.
5) The manager sees the message in the pipe, retrieves the program id
and parameters.
6) The manager runs the program with the specified parameters. The
program will be of type 'Immediate', so there will not be a
separate concurrent request run.
7) The program completes, and the manager packs its return status into
the return pipe.
8) FND_TRANSACTION.SYNCHRONOUS reads the return value and passes it
back to its caller.


Note that these events take place essentially simultaneously on the
client and server. This is a synchronous transaction because the
client waits for the server to return, or times out waiting for it.



Problem....

When you try to submit a request like Active users or
Active responsibilities, request gets submitted.

When we view the help requests, you find that it is
inactive / nomanager.

Within 12 to 15 seconds, you refresh-it gets completed.

Initially, you could find only inactive and we look at
the diagnostic- the concurrent manager assigned is not
picking up.

There is no specialization rules in any managers except
the include program this source.

Solution....

Most often when this occurs where a request goes
"inactive/no manager" and is then processed a short time
later, the solution is to either increase the cache size
for your Standard manger, or increase the actual number of
Standard manager processes.

Cache Size is set on the CONCURRENT/MANAGER/DEFINE form. Basically,
this regulates how many requests a manager will pick up for each
sleep cycle.


How do I process more concurrent requests concurrently?

The Concurrent Manager parameters, (Query the concurrent manager by
Login as Sysadmin, navigate -> Concurrent -> Manager -> Define and Query for
the relevant concurrent manager), should be modified to handle more
concurrent requests concurrently, this can be done in two steps:

(i) Increase the Number of Target processes for the manager

(ii) Change the cache size of the concurrent manager as this determines
how many requests will be evaluated by a manager at a time and should match the target (process) value as set above.



RELATED DOCUMENTS
-----------------
Note 1050938.6 What to Set $APPCPNAM for the Report Output File Naming Convention Format
Note 149600.1 FND_CONC_PP_ACTIONS and FND_RUN_REQ_PP_ACTIONS Growing Exponentially
Note 134007.1 CMCLEAN.SQL - Non Destructive Script to Clean Concurrent Manager Tables