Main

February 23, 2007

Implementing Parallel Concurrent Processing

Implementing Parallel Concurrent Processing

Parallel Concurrent Processing is the ability to simultaneously run your concurrent managers of various nodes. This results in efficient processing power and also allows the ability of failover. That is in the even of one of your concurrent manager node becomes un available the standard managers will fail over to the other node.

You can implement PCP either in a normal implementation of Oracle Applications or by implementing RAC, however to exploit the feature of PCP completely it is best that you implement RAC to ensure that you have a oncurrent managers available even if your DB node comes down.

In my current post i will write about implementing PCP on a non- RAC environment.

Rapidinstall does not allow you to configure two concurrent processing nodes at the time of install for which I will I have to use rapid clone to create another concurrent processing node for me.

In the current example i have a single node installation of Oracle Applications (11.5.10.2) running on Node A.

The brief overview of steps involved in this implementation of PCP are

  • Use Rapidclone to clone and create another node.
  • Use adaddnode and register the new node in the database.
  • Use Oracle Application Manager to turn PCP on.
  • Define and Verfiy the Concurrent Manager seetings and Workshifts.
  • Test Failover.


Use Rapidclone to clone and create another node

Running Preclone on current node
#su - applsam
$cd samappl
$. ./APPSORA.env
$cd $COMMON_TOP/admin/scripts/SAM_SAMLXA
$perl adpreclone.pl appsTier

Disable security option
In Oracle Applications 11.5.10 the SQL*NET restricted security option is enabled by default. As a result your new node Node_B  will not be able to connect to the database. You must either disable this security option or the better way is to add Node_B is the list of trusted nodes through OAM.
Oracle Applications Manager -> Security ->Disable Restricted Sectrity Option.

After this you must run Autoconfig on the database Tier and restart your listener.
# su - orasam
$ cd $ORACLE_HOME/appsutil/scripts/SAM_NOde_A
$ ./adautocfg.sh

Restart your listener
$ ./addlnctl.sh stop sam
$ ./addlnctl.sh start sam

Preparing the new node (Node B) to copy the application tier file system.
On Node B make the following dir structure
# cd /u02
# mkdir sam
# chmod -R 777 sam

Copy the files across to Node B
Shutdown on Application and Database services on Node A
tar -cf - applsam | ssh Node_B tar -xf - -C /u02/sam/

Post Clone on Node B
Now you must run your post clone (adcfgclone.pl) on Node B and specify that it is your admin and concurrent processing node
# su - applsam
$ cd samcomn/clone/bin
$ perl adcfgclone.pl appsTier

Use adaddnode and register the new node in the database
After sourcing your environment file you must run the adaddnode.pl script on node A
#su - applsam
$ cd $COMMON_TOP/clone/bin
$ perl adaddnode.pl

The script will prompt you for your APPS user and password and do the required new node entries to the database FND tables.

Use Oracle Application Manager to turn PCP on
Once all the configured services have been started on both the nodes log on to your Oracle Applications Manager and turn the value for the APPLDCP variable to ON. Please make sure to do this change on the application tier context files on both the nodes.

Autoconfig
Shutdown the application tier services of both the nodes and run autoconfig on both the nodes.
After autoconfig completes successfully restart the application tier services on both the nodes.

Verfiy TNSNAMES.ora
Verify that the tnsnames.ora of your application tier has the FNDFS entries of both the nodes
FNDFS_SAMLXA=

        (DESCRIPTION=
                (ADDRESS=(PROTOCOL=tcp)(HOST=SAMLXA.appsdbablog.com)(PORT=1676))
            (CONNECT_DATA=
                (SID=FNDFS)
            )
        )
FNDFS_SAMLXA.appsdbablog.com=
        (DESCRIPTION=
                (ADDRESS=(PROTOCOL=tcp)(HOST=SAMLXA.appsdbablog.com)(PORT=1676))
            (CONNECT_DATA=
                (SID=FNDFS)
            )
        )
FNDFS_SAMLXB=
        (DESCRIPTION=
                (ADDRESS=(PROTOCOL=tcp)(HOST=SAMLXB.appsdbablog.com)(PORT=1676))
            (CONNECT_DATA=
                (SID=FNDFS)
            )
        )
FNDFS_SAMLXB.appsdbablog.com=
        (DESCRIPTION=
                (ADDRESS=(PROTOCOL=tcp)(HOST=SAMLXB.appsdbablog.com)(PORT=1676))
            (CONNECT_DATA=
                (SID=FNDFS)
            )
        )

Also verify that the failover entry exits in the tnsnames.ora of the application tier on both the nodes
SAM_BALANCE=
        (DESCRIPTION=
            (LOAD_BALANCE=YES)
            (FAILOVER=YES)
            (ADDRESS_LIST=
                (ADDRESS=(PROTOCOL=tcp)(HOST=SAMLXA.appsdbablog.com)(PORT=1571))
            )
            (CONNECT_DATA=
                (SID=SAMP)
            )
        )

Define and Verify your concurrent Manager definitions
Define the Primary and Secondary nodes for your Standard Manager and Internal Concurrent Manager
Log in to Oracle Applications as the SYSADMIN user and navigate to Concurrent Manager Administer screen.



Also define your Primary and Secondary nodes for your Internal Monitor : Node A and Internal Monitor : Node B. The primary Node for your Internal Monitor Node A will be Node A and the secondary will be Node B and vice versa for the Internal monitor Node B.


Testing Fail Over
You can test the failover process by shutting down node B in which case the the standard manager will failover to the secondary node which is Node B. Once the node comes back alive the concurrent managers will again failback.

Since PCP here is configured in a non RAC environment you cannot have an instance failover here, that is if your DB Node is down the concurrent managers will not failover.

January 16, 2007

Working with CONCSUB

Working with CONCSUB

Last week I had taken off for a vacation so did not find time to blog, now once back it great to be back posting.

In today's post I will talk about the one of the lesser used, but important to understand Oracle Applications utilities  the CONCSUB utility.

The CONCSUB is a utility which allows you to submit a concurrent program to the concurrent manager from the operating system level without having to log on to Oracle Applications.
The CONCSUB executable is located at $FND_TOP/bin/CONCSUB.

The functionality of the CONCSUB can be categorized into the following

  • Submitting Concurrent Requests
  • Controlling Concurrent Managers

Submitting Concurrent Requests
You can use the CONCSUB to execute both seeded and custom programs in Oracle Applications. In case of custom programs they must first be registered in Oracle Applications before you can execute them with CONCSUB.

The following can be used in Oracle Applications to run the active users report from the command line without logging in the  applications

CONCSUB APPS/APPS SYSADMIN "System Administrator" SYSADMIN WAIT=N CONCURRENT FND FNDSCURS PROGRAM_NAME='"Active Users"'
Submitted request 2866136 for CONCURRENT FND FNDSCURS PROGRAM_NAME="Active Users"

The log and out file for this program is also created at the location defined by your $APPLCSF/$APPLLOG and $APPLCSF/$APPLOUT respectively.

The WAIT=Y/N is used to specify weather to wait for the first concurrent request to be completed before the second is submitted or not.

You can also use various printing parameters with the COCNCSUB to directly print the output of your concurrent request.

PRINTER=<printer name>
NUMBER_OF_COPIES=<number of reports to be printed>
PRINT_STYLE=<printer style to be used>    
LANGUAGE=<language to be used>

Also you could specify the start date and completion options along with CONCSUB by using the following parameters

START=<Requested Start Date>
REPEAT_DAYS=<Repeat Interval>
REPEAT_END=<Request Resubmission End Date>

Controlling Concurrent Managers
Apart from submitting concurrent request the CONCSUB can also be used to shutdown your concurrent managers

CONCSUB apps/apps_password SYSADMIN 'System Administrator' SYSADMIN WAIT=N CONCURRENT FND SHUTDOWN

Sometimes the shutdown of the concurrent managers via the CONCSUB utility using the SHUTDOWN clause hangs and you may want to terminate your concurrent managers, in such a case you can use the ABORT clause with CONCSUB to do a force shutdown of your concurrent managers.

CONCSUB apps/apps SYSADMIN 'System Administrator' SYSADMIN WAIT=N CONCURRENT FND ABORT

In this case a concurrent request to terminate the concurrent managers is fired with a -75 priority. In case of the shutdown  the priority is 0 and default priority is of a concurrent request 50, by assigning a -75 priority the CONCSUB ensures abort is executed before shutdown.

Needless to say that the shutdown would fail in case the SYSADMN user or the System Administrator responsibility is inactive.

However to start the concurrent managers the CONCSUB is not used instead the startmgr executable is used.(Though possible)
This is located at $FND_TOP/bin/startmgr.

$startmgr sysmgr=apps/apps@sam
Starting icm@sam Internal Concurrent Manager
Default printer is

By default if no manager name is specified the ICM or the Internal Concurrent Manager is started. You can also start a specific manager by using the mgrname clause

To use CONCSUB to start the concurrent managers the STARTUP clause is used

$ CONCSUB apps/apps SYSADMIN 'System Administrator' SYSADMIN WAIT=N CONCURRENT FND STARTUP
Submitted request 2849496 for CONCURRENT FND STARTUP