Power Tools: Running AutoConfig in Parallel in EBS 12

[Editor's Note:  This is the second of a series of four articles on new AutoConfig features.  These articles are written by members of our AutoConfig Development team.  This is your opportunity to interact directly with that team with your feedback on this tool.]

Our last article discussed ways of tuning your AutoConfig runs via profiling reports that identify bottlenecks during template instantiation.  This article discusses another method of speeding up your AutoConfig runs.  In an R12 E-Business Suite instance, AutoConfig can now be run simultaneously across multiple nodes. This new feature significantly lowers maintenance downtime for multi-node installations. One beta customer of this feature improved the time it takes them to run AutoConfig across their dozen mid tiers by 45%.

How Does AutoConfig's Parallel Mode Work?

Executing AutoConfig in 'parallel mode' engages a locking mechanism so that processes running on individual nodes are synchronized. This mechanism prevents any conflicting updates to the database or the file system. The following figure illustrates AutoConfig running in parallel across multiple nodes:

Diagram showing how AutoConfig runs in parallel on EBS 12

Executing AutoConfig in Parallel Mode

The following command can be used to run AutoConfig in 'parallel mode'

Application Tier

perl $AD_TOP/bin/adconfig.pl contextfile=<CtxFile> [product=<product_top>] –parallel

Database Tier

perl $ORACLE_HOME/appssutil/bin/adconfig.pl contextfile=<CtxFile> –parallel

where

<CtxFile> is the absolute path to the context file
<product_top> is the Product short name

Note that while running AutoConfig simultaneously on multiple nodes, it is very important to ensure that the '-parallel' option is specified while starting AutoConfig on each node to prevent unstable and/or inconsistent filesystem and database states.

Downloading the Latest AutoConfig Engine

Customers on Oracle E-Business Suite Release 12 can obtain this new feature by installing:

This feature is currently not available for Oracle E-Business Suite 11i.  We currently do not have precise plans for delivery of this feature in 11i.

Your Thoughts?

Please let us know about your experience on using this new feature. We'd be very interested in hearing about how long it takes to run AutoConfig on your multi-node installations with and without the 'parallel' option. The new AutoConfig Performance Profiler feature can be used to collect this information. Also let us know of any issues you encounter while using this feature.

References

Related Articles

Comments:

Hello Srinivas,

The autoconfig parallel option is very cool staff from my point of view.
A. Just wonder can you comment if in previous autoconfig versions (before you implemented that feature) running autoconfig in parallel mode (just running autoconfig on multiple nodes at the same time without specifying any thing in addition) was unsupported and unrecompensed practice?
I remember some time ago we had related discussion in that blog related to that question and conclusion was it doesn’t suppose to damage anything.

>> it is very important to ensure that the '-parallel'
Would it be beneficial to make it other way around? If without that option (product top locking) there is a risk to damage/corrupt ether a product file system, ether data why you wouldn’t use that a default protection behaviour?
I don’t see any negative impact if each autoconfig run would lock appropriate product top (by default) to prevent any possible case of corruption and ensure that only one autoconfig session change a configuration at that very moment?

Once again! Thank you very much for making Apps DBA easer and improving ATG functionality.

With all my respect,
Hope to hear from you soon,
Yury

Posted by Jurijs Velikanovs on April 03, 2009 at 06:15 PM PDT #

Jurijs,

Since AutoConfig processes perform CRUD operations on shared resources (Eg: DB profiles), it is important to ensure that AutoConfig processes are synchronized.

The idea here was to provide a generic solution instead of dealing with one-off/ad hoc cases.

We do not engage the locking mechanism by default because:

1. We did not want to add the overhead of locking/unlocking product tops in a normal AutoConfig run.

2. AutoConfig is used internally by other products (Eg: cloning, Rapid Install, adpatch), some of which run AutoConfig while the DB is down. The locking mechanism would fail in these cases.

Thanks,
Srinivas

Posted by Srinivas Chaganti on April 05, 2009 at 07:05 PM PDT #

>> 1. We did not want to add the overhead
Just wonder what do you mean by locking overhead? I thought you just call DBMS_LOCK once per product, right?
If so we are talking about 30 DBMS_LOCK calls max. I don’t think it is an overhead at all.
>> 2. ... DB is down ...The locking mechanism would fail in these cases.
Aren’t we talking about one IF statement? :)

You might say that those things are not simple and I truly believe that they are not. But I encourage you to make this feature default it in the future releases as it sound very good and logical to me.

Have a good and short week,
Yury

Posted by Jurijs Velikanovs on April 05, 2009 at 09:46 PM PDT #

This Feature , we had thots in the past.

What about the Shared Appltop ?
how does parallel helps as all the nodes sharing the same production TOPs.??

--
Naresh

Posted by Naresh Giri on April 08, 2009 at 08:50 PM PDT #

Naresh,

AutoConfig parallel run is supported in shared Appltop setup also.

Thanks,
Srinivas

Posted by Srinivas Chaganti on April 12, 2009 at 05:53 PM PDT #

Are there any plans to certify it in 11i

Thanks/Vinay

Posted by vinay on April 15, 2009 at 04:12 PM PDT #

Hi
I was just wondering why the parallel option cannot be used running the sh version adautocfg.sh in the $ADMIN_SCRIPTS_HOME
When I try parallel as an option I receive the error
adautocfg.sh parallel
./adautocfg.sh: unrecognized action specified

# $Header: adautocfg_ux.sh 120.4 2008/02/19 04:28:02 sbandla ship $

Surely this is an oversite and there is patch to add this functionality?

Regards

Stuart

Posted by Stuart Moore on July 13, 2009 at 12:01 AM PDT #

As you must have already known $ADMIN_SCRIPTS_HOME./adautocfg.sh is just a AutoConfig wrapper script.

The script was implemented for ease of use (Example: It just prompts for apps password, all other parameters are taken as default - including context file).

It as such does not support any of the other AutoConfig parameters and '-parallel' option is no exception.

Are there any plans to certify it in 11i:

We do not have any scheduled plan to implement this in 11i as of now.

Posted by Srinivas Chaganti on September 01, 2009 at 12:08 AM PDT #

I am working on migrate existing r12 with 11g from RH to suSe. The db is from single node to 4 nodes RAC and the apps tier is from 2 nodes share appl_top to 10 nodes shared appl_top. During config shared appl_top, we need run autoconfig on the node after adding each node plus run autoconfig on all nodes after configed last node. This requires to run autoconfig more than 19 times.

In order to reduce down time, I am thinking to use autoconfig in parallel mode. I have following questions:
1. Do you think this is good approach?
2. Is “adconfig.pl –parallel” option automatically to start autoconfig on other nodes?
3. Or, I have to start “adconfig.pl –parallel” on each node but can start at the same time.
4. Can I run adautocfg.sh with/without parallel when the application is online and the users are using the node? I always run it by shut down apps on the node, but I heard we can run it when apps is up on the node.
Thanks in advance

Posted by Zosen Wang on October 07, 2009 at 12:29 PM PDT #

Hi,

You could use AutoConfig's '-parallel' option in the final run.

'adconfig.pl –parallel' needs to be explicitly started/run on each node.

We have plans to integrate AutoConfig and other configuration tools in Oracle Applications Plugin for Oracle Enterprise Manager. This would allow you to run AutoConfig across nodes from a single UI console. It would also take care of restarting the services as part of its execution.

To my knowledge running AutoConfig in 'hot mode' (with out shutting down the services) is not supported yet.

Posted by Srinivas Chaganti on October 19, 2009 at 03:09 PM PDT #

Can someone tell me that if autoconfig is run in parrallel mode in a set up having Multiple Middle Tiers and DMZ nodes also.

Say 3 Private MT and 1 dmz MT and shared appl_top.

Then from which node will the profile options get updated.

When not run in parallel mode it should be from private CM Nodes.
How is it handelled by parallel option.

Posted by Saurabh on December 13, 2009 at 04:33 PM PST #

Profile updates are done through template scripts that are instantiated and executed by the AutoConfig engine.

Even in AutoConfig parallel run, AutoConfig would instantiate/execute the all the template scripts (including scripts that update profiles) as per their declarations/entries in the product top driver file.

AutoConfig parallel run just ensures that the instantiation/execution of the template scripts across different nodes are synchronized.

Posted by Srinivas Chaganti on December 21, 2009 at 06:09 PM PST #

Hi, Saurabh,

Srinivas has changed responsibilities, but he asked me to pass on this reply to your question:

----

Profile updates are done through template scripts that are instantiated and executed by the AutoConfig engine.

Even in AutoConfig parallel run, AutoConfig would instantiate/execute the all the template scripts (including scripts that update profiles) as per their declarations/entries in the product top driver file.

AutoConfig parallel run just ensures that the instantiation/execution of the template scripts across different nodes are synchronized.

----

Regards,
Steven

Posted by Steven Chan on December 28, 2009 at 06:38 AM PST #

Wondering how this locking mechanism works on shared appl top. Consider below example:
If there are three nodes - all internal and running autoconfig with parellel mode on all three started exactly at the same time.

at this situation, wll 3 wud wait to configure the AD top at the first (this being the first top to get processed). as per the illustration, if 1st node is putting a lock on the product top, then execution at 2nd and 3rd nodes has oto wait for the lock to get released. pls correct me if i am wrong.

If the 2nd and 3rd nodes executions are waiting for their turns to process ad top, the same wud apply for all the tops. i.e - 1 node finishes, then comes the 2nd nodes execution and so on. So where are we saving the time? aren't we waiting for all three to finish one by one?

Posted by Syamantak on September 14, 2010 at 03:20 AM PDT #

Just ran a test of the parallel option:
Configuration is R12.1.2 shared appl_top running against a 2 node RAC.

App Node 1 w/o parallel 21 min
w/ parallel 21 min

App Node 2 w/o parallel 21 min
w/ parallel 31 min

Total time for execution w/o parallel is 42 min
Total time for execution w parallel is 31 min

I suspect this as previous poster indicated, the majority of the adcfg time is spent on ad_top, if node 1 locks the ad_top, node 2 waits. Even so, total run time with parallel was 25% faster than running serialized.

Posted by Rich on September 30, 2010 at 01:25 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
4
5
6
7
8
9
10
11
12
13
14
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today