CONCURRENT MANAGER SETUP AND CONFIGURATION REQUIREMENTS IN AN 11I RAC ENVIR

Question

제품 : AOL
작성날짜 : 2004-05-13
PURPOSE
RAC-PCP 구성에 대한 Setup 사항을 기술한 문서입니다.
PCP 구현은 CM의 workload 분산, Failover등을 목적으로 합니다.
Explanation
Failure sceniro 는 다음 3가지로 구분해 볼수 있습니다.
1. The database instance that supports the CP, Applications, and Middle-Tier
processes such as Forms, or iAS can fail.
2. The Database node server that supports the CP, Applications, and Middle-
Tier processes such as Forms, or iAS can fail.
3. The Applications/Middle-Tier server that supports the CP (and Applications)
base can fail.
아래부분은 CM,AP 구성과
CM과 GSM(Global Service Management)과의 관계를 설명하고 있습니다.
The concurrent processing tier can reside on either the Applications, Middle-
Tier, or Database Tier nodes. In a single tier configuration, non PCP
environment, a node failure will impact Concurrent Processing operations do to
any of these failure conditions. In a multi-node configuration the impact of
any these types of failures will be dependent upon what type of failure is
experienced, and how concurrent processing is distributed among the nodes in
the configuration. Parallel Concurrent Processing provides seamless failover
for a Concurrent Processing environment in the event that any of these types of
failures takes place.
In an Applications environment where the database tier utilizes Listener (
server) load balancing is implemented, and in a non-load balanced environment,
there are changes that must be made to the default configuration generated by
Autoconfig so that CP initialization, processing, and PCP functionality are
initiated properly on their respective/assigned nodes. These changes are
described in the next section - Concurrent Manager Setup and Configuration
Requirements in an 11i RAC Environment.
The current Concurrent Processing architecture with Global Service Management
consists of the following processes and communication model, where each process
is responsible for performing a specific set of routines and communicating with
parent and dependent processes.
아래 내용은 PCP환경에서 ICM, FNDSM, IM, Standard Manager의 역활을 설명하고
있습니다.
Internal Concurrent Manager (FNDLIBR process) - Communicates with the Service
Manager.
The Internal Concurrent Manager (ICM) starts, sets the number of active
processes, monitors, and terminates all other concurrent processes through
requests made to the Service Manager, including restarting any failed processes.
The ICM also starts and stops, and restarts the Service Manager for each node.
The ICM will perform process migration during an instance or node failure.
The ICM will be
active on a single node. This is also true in a PCP environment, where the ICM
will be active on at least one node at all times.
Service Manager (FNDSM process) - Communicates with the Internal Concurrent
Manager, Concurrent Manager, and non-Manager Service processes.
The Service Manager (SM) spawns, and terminates manager and service processes (
these could be Forms, or Apache Listeners, Metrics or Reports Server, and any
other process controlled through Generic Service Management). When the ICM
terminates the SM that
resides on the same node with the ICM will also terminate. The SM is ？hained?
to the ICM. The SM will only reinitialize after termination when there is a
function it needs to perform (start, or stop a process), so there may be
periods of time when the SM is not active, and this would be normal. All
processes initialized by the SM
inherit the same environment as the SM. The SM environment is set by APPSORA.
env file, and the gsmstart.sh script. The TWO_TASK used by the SM to connect
to a RAC instance must match the instance_name from GV$INSTANCE. The apps_<sid>
listener must be active on each CP node to support the SM connection to the
local instance. There
should be a Service Manager active on each node where a Concurrent or non-
Manager service process will reside.
Internal Monitor (FNDIMON process) - Communicates with the Internal Concurrent
Manager.
The Internal Monitor (IM) monitors the Internal Concurrent Manager, and
restarts any failed ICM on the local node. During a node failure in a PCP
environment the IM will restart the ICM on a surviving node (multiple ICM's may
be started on multiple nodes, but only the first ICM started will eventually
remain active, all others will gracefully terminate). There should be an
Internal Monitor defined on each node
where the ICM may migrate.
Standard Manager (FNDLIBR process) - Communicates with the Service Manager and
any client application process.
The Standard Manager is a worker process, that initiates, and executes client
requests on behalf of Applications batch, and OLTP clients.
Transaction Manager - Communicates with the Service Manager, and any user
process initiated on behalf of a Forms, or Standard Manager request. See Note:
240818.1 regarding Transaction Manager communication and setup requirements for
RAC.
Concurrent Manager Setup and Configuration Requirements in an 11i RAC
Environment
PCP를 사용하기위한 기본적인 Setup 절차를 설명하고 있습니다.
In order to set up Setup Parallel Concurrent Processing Using AutoConfig with
GSM,
follow the instructions in the 11.5.8 Oracle Applications System Administrators
Guide
under Implementing Parallel Concurrent Processing using the following steps:
1. Applications 11.5.8 and higher is configured to use GSM. Verify the
configuration on each node (see WebIV Note:165041.1).
2. On each cluster node edit the Applications Context file (<SID>.xml), that
resides in APPL_TOP/admin, to set the variable <APPLDCP oa_var="s_appldcp">
ON </APPLDCP>. It is normally set to OFF. This change should be performed
using the Context Editor.
3. Prior to regenerating the configuration, copy the existing tnsnames.ora,
listener.ora and sqlnet.ora files, where they exist, under the 8.0.6 and iAS
ORACLE_HOME locations on the each node to preserve the files (i.e./<some_
directory>/<SID>ora/$ORACLE_HOME/network/admin/<SID>/tnsnames.ora). If any of
the Applications startup scripts that reside in COMMON_TOP/admin/scripts/<SID>
have been modified also copy these to preserve the files.
4. Regenerate the configuration by running adautocfg.sh on each cluster node as
outlined in Note:165195.1.
5. After regenerating the configuration merge any changes back into the
tnsnames.ora, listener.ora and sqlnet.ora files in the network directories,
and the startup scripts in the COMMON_TOP/admin/scripts/<SID> directory.
Each nodes tnsnames.ora file must contain the aliases that exist on all
other nodes in the cluster. When merging tnsnames.ora files ensure that each
node contains all other nodes tnsnames.ora entries. This includes tns
entries for any Applications tier nodes where a concurrent request could be
initiated, or request output to be viewed.
6. In the tnsnames.ora file of each Concurrent Processing node ensure that
there is an alias that matches the instance name from GV$INSTANCE of each
Oracle instance on each RAC node in the cluster. This is required in order
for the SM to establish connectivity to the local node during startup. The
entry for the local node will be the entry that is used for the TWO_TASK in
APPSORA.env (also in the APPS<SID>_<HOSTNAME>.env file referenced in the
Applications Listener [APPS_<SID>] listener.ora file entry "envs='MYAPPSORA=<
some directory>/APPS<SID>_<HOSTNAME>.env)
on each node in the cluster (this is modified in step 12).
7. Verify that the FNDSM_<SID> entry has been added to the listener.ora file
under the 8.0.6 ORACLE_HOME/network/admin/<SID> directory. See WebiV Note:
165041.1 for instructions regarding configuring this entry. NOTE: With the
implementation of GSM the 8.0.6 Applications, and 9.2.0 Database listeners
must be active on all PCP nodes in the cluster during normal operations.
8. AutoConfig will update the database profiles and reset them for the node
from which it was last run. If necessary reset the database profiles back to
their original settings.
9. Ensure that the Applications Listener is active on each node in the cluster
where Concurrent, or Service processes will execute. On each node start the
database and Forms Server processes as required by the configuration that
has been implemented.
10. Navigate to Install > Nodes and ensure that each node is registered. Use
the node name as it appears when executing a nodename?from the Unix prompt on
the server. GSM will add the appropriate services for each node at startup.
11. Navigate to Concurrent > Manager > Define, and set up the primary and
secondary node names for all the concurrent managers according to the
desired configuration for each node workload. The Internal Concurrent
Manager should be defined on the primary PCP node only. When defining the
Internal Monitor for the secondary (target) node(s), make the primary node (
local node) assignment, and assign a secondary node designation to the
Internal Monitor, also assign a standard work shift with one process.
12. Prior to starting the Manager processes it is necessary to edit the APPSORA.
env file on each node in order to specify a TWO_TASK entry that contains
the INSTANCE_NAME parameter for the local nodes Oracle instance, in order
to bind each Manager to the local instance. This should be done regardless
of whether Listener load balancing is configured, as it will ensure the
configuration conforms to the required standards of having the TWO_TASK set
to the instance name of each node as specified in GV$INSTANCE. Start the
Concurrent Processes on their primary node(s). This is the environment
that the Service Manager passes on to each process that it initializes on
behalf of the Internal Concurrent Manager. Also make the same update to
the file referenced by the Applications Listener APPS_<SID> in the
listener.ora entry "envs='MYAPPSORA= <some directory>/APPS<SID>_<HOSTNAME>.
env" on each node.
13. Navigate to Concurrent > Manager > Administer and verify that the Service
Manager and Internal Monitor are activated on the secondary node, and any
other addititional nodes in the cluster. The Internal Monitor should not be
active on the primary cluster node.
14. Stop and restart the Concurrent Manager processes on their primary node(s),
and verify that the managers are starting on their appropriate nodes. On
the target (secondary) node in addition to any defined managers you will
see an FNDSM process (the Service Manager), along with the FNDIMON process (
Internal Monitor).
Reference Documents
Note 241370.1

Answer 1

What is your database version? OS?
We are using VCP suite for Planning Purpose. We are using VCP environment (12.1.3) in Decentralized structure connecting to 3 differect source environment ( consisting 11i and R12). As per the Oracle Note {RAC Configuration Setup For Running MRP Planning, APS Planning, and Data Collection Processes [ID 279156]} we have implemented RAC in our test environment to get better performance.
But after doing all the setups and concurrent programs assignment to different nodes, we are seeing huge performance issue. The Complete Collection which takes generally on an avg 180 mins in Production, is taking more than 6 hours to complete in RAC.
So I would like to get suggestion from this forum, if anyone has implemented RAC in pure VCP (decentralized) environment ? Will there be any improvement if we make our VCP Instance in RAC ?Do you PCP enabled? Can you reproduce the issue when you stop the CM?
Have you reviewed these docs?
Value Chain Planning - VCP - Implementation Notes & White Papers [ID 280052.1]
Concurrent Processing - How To Ensure Load Balancing Of Concurrent Manager Processes In PCP-RAC Configuration [ID 762024.1]
How to Setup and Run Data Collections [ID 145419.1]
12.x - Latest Patches and Installation Requirements for Value Chain Planning (aka APS Advanced Planning & Scheduling) [ID 746824.1]
APSCHECK.sql Provides Information Needed for Diagnosing VCP and GOP Applications Issues [ID 246150.1]
Thanks,
Hussein