The Latest Oracle E-Business Suite Technology News direct from
Oracle E-Business Suite Development & Product Management

  • May 9, 2007

Reducing Patching Downtimes via Shared Apps File Systems

Steven Chan
Senior Director
I had a chance conversation with an Apps sysadmin late in the evening at the Collaborate conference.  He wearily noted that he had to somehow cover increasing maintenance costs with reduced levels of staffing.  The conversation suggested that our support for shared E-Business Suite application tier file systems may be one of our better-kept secrets.  If you haven't come across this yet, here's a way of reducing the amount of time that you spend patching.

Scaling Up with Load-Balancers

When your E-Business Suite user base grows beyond a certain size, it's likely that you'll look into deploying multiple application servers in a load-balanced pool of nodes.  Your deployment topology might look like this:

Generic Apps Load-balancing:

Regardless of whether you're running Release 11i or 12, each of these
nodes would need its own disk space and would to be maintained and
patched separately.  What a pain.

Different File System Structures in Release 11i and 12

In Release 11i, the Applications tier file system includes the APPL_TOP, the COMMON_TOP, and the Applications technology stack (8.0.6 and iAS ORACLE_HOMEs).  In a traditional deployment, each one of these application servers would have its own Applications file system, like this:

Distributed Application Tier Filesystem:

In Release 12, the Applications tier file system includes the APPL_TOP, the COMMON_TOP, and the Applications technology stack (10.1.2 and 10.1.3 ORACLE_HOMEs), plus a new INST_TOP.  Each node would have the following:

Release 12 application tier structure 2:

Enter the Shared Application Tier File System

For Release 11i, starting with 11.5.10, it's possible to put the Applications tier file system on a shared disk resource mounted to each Application tier server node in the system, like this:

Shared Application tier file system:

Similarly, in Release 12, you could put the Applications tier file system on a shared disk resource mounted to each Application tier server node, like this:

Release 12 shared filesystem:

Migrating to Shared File Systems

There are a few prerequisites:
  • Different nodes must be running the same operating system and the same O/S patches
  • You must be on a UNIX platform (Windows doesn't support shared file systems)
Certification of Shared File System Solutions

If you've gotten to this point, you're probably wondering, "Is my _____ SAN/NAS shared file system software certified with the E-Business Suite?"  File system solutions that customers have recently asked about include:
Supported but not Certified

The short answer is that your shared file system solution is supported but not certified with the E-Business Suite, for either Release 11i or 12.  Remember that there's a key distinction between support and certification, which I've covered in detail in this article:
The complexities of whatever shared disk resource management solution that you're using must be transparent to the E-Business Suite.  Aside from that, there aren't any special requirements for shared disk resources.  They can be local to the server or on a standalone disk array.

Almost Irresistible

Regardless of which E-Business Suite release you're running, the main advantage of using an Application shared file system is simplicity and ease of patching:  when
you apply patches or changes to the shared disk resource,
they're immediately visible on all application tier server nodes.  You
patch in a single place and deploy those changes across multiple
servers.  You save disk space for each additional application node you
deploy, and it's easier to deploy additional nodes, too.

If you've been wondering how to squeeze more productivity out a packed roster of administration activities, I'd recommend setting up a testbed to try this out.  Feel free to post a comment with your experiences with this; I'll make sure your feedback gets back our team.

Related Articles

Join the discussion

Comments ( 26 )
  • Gareth Roberts Wednesday, May 9, 2007

    Hi, I've used this shared everything under and highly recommend it. My only points of note are:

    1. After applying a patch on the master server, if autoconfig was run as part of the patch, ensure autoconfig is run on the other servers.

    2. Ensure your disk configuration includes mirroring because you are effectively reducing some of your "redundancy" with this configuration.

    3. Be aware that anything that is server specific (including modifications) at the filesystem level need to be sympathetic to your configuration.Gareth

  • Atul Kumar Thursday, May 10, 2007

    Nice post .. I was wondering during autoconfig patch (or any patch which updates context file), How context file (on other servers) is updated ?

  • Steven Chan Thursday, May 10, 2007

    Hi, Atul,If you're applying a patch that requires AutoConfig to be run:To a multi-node environment that doesn't use a shared file system, you need to run AutoConfig on each of the application tier nodes. To a multi-node environment that uses a shared file system, you need to AutoConfig on each of the application tier nodes if you apply a TXK/ADX or any other product patch that brings in configuration changes.  This particular point is documented in Note 233428.1 in Section 6.Regards,Steven

  • Steven Chan Thursday, May 10, 2007

    All excellent points, Gareth.  Thanks for posting those tips.  I think that our official documentation should be updated with some of these points.  I'll work with the team to get these updates into a future version of our Notes.Regards,Steven

  • Carlos Duarte Friday, May 11, 2007

    Does anybody have more details about INST_TOP and any documentation about it and any other new?

    Thanks & Regards,


  • Steven Chan Friday, May 11, 2007


    If I find the time, I'll try to write an article as an introduction to this new R12 concept, too.  Until then, more information about the Release 12 file system layout can be found in a couple of places.  The first link covers this in a lot of detail:

    Oracle Applications 12 Concepts Guide  (OTN, PDF, 1.3 MB)Metalink Note 384248.1  (with particular details on shared file system implications)Regards,Steven Regards,Steven

  • Atul Kumar Sunday, May 13, 2007

    Thanks Steven for your prompt reply, What I meant by my questions is that, if I apply an autoconfig patch from node1 which updates context file so this patch will update SID_node1.xml in $APPL_TOP on shared file system.

    How these changes will be introduced in SID_node2.xml so that I can run autoconfig from node2.

    Is patch update context parameters in database and with each execution of autoconfig context file is synched with database ?

    or patch physically update context file which the update context file copy stored in database ?

  • Fadi Hasweh Monday, May 14, 2007

    nice post, but i have qustion,

    if i have multi-node installation for 2 nodes, the first node has DB, CM, Admin and the second node has froms and web. dose this can be consider for shared appl_top or shard application file system, i mean is it feasible? from my reading i guess it should be at least more than one froms/web nodes is that correct?



  • Steven Chan Tuesday, May 15, 2007


    The shared file system approach is intended to support sharing between multiple application tier server nodes.  There's no advantage in setting this up if you only have one node running Forms.


  • Steven Chan Thursday, May 17, 2007

    Atul,Your first point neatly outlines the reason why we require AutoConfig to be run on all application tier server nodes.  This is due to a known functional limitation in the way ADpatch and AutoConfig work together.  We're tracking this as a possible enhancement in future versions of AutoConfig.In answer to your second question:  each AutoConfig run updates the context file on the file system, then uploads the same into the database.Regards,Steven 

  • Atul Kumar Tuesday, May 29, 2007

    Thanks steven for clarifying this.

  • Atul Kumar Tuesday, May 29, 2007


    Sorry for bugging you again with same question but when one apply autoconfig patch it will update context file of that node only & not other node context file (This is my understanding of autopatch, If patch updates all xml files then it makes sense to execute autoconfig i.e. after changes are introduced)

    But if autopatch is going to update xml file only for node on which patch is applied so that changes will not be in xml file of other node .

    If changes are not in xml file on other nodes how running of autoconfig (without new chnages in xml) will serve purpose ..

    I hope I have not confused you :-(

  • Subbu Saturday, August 25, 2007


    any update to the question asked by atul



  • Subbu Saturday, August 25, 2007

    i am eager to know the answer for what atul asked above...



  • Revital Altshuler Monday, June 1, 2009

    Hi Steven,

    We are implementing eBusiness Suite on Linux x86.

    We already have shared APPL_TOP using NFS shared filesystem (our storage is NetApp).

    We are about to replace our storage to EMC and we need to look for other alternative for shared filesystem.

    We would like to use Veritas 5.0 for that but we were told by the local Symantec personal that Veritas 5.0 is not supported on Linux 32bit.

    Is it correct ?

    I know there is such a limitation for Oracle RAC, does it also exist for shared APPL_TOP ?


  • Steven Chan Monday, June 1, 2009

    Hi, Revital,

    I'm afraid that I don't have a lot of visibility into platform-specific questions about third-party filesystems like Veritas 5.0. We do not specifically certify or test Veritas with EBS, so I don't have any hands-on experience with this technology.

    You might wish to investigate this further with Veritas Support to understand the limitations around this technology.



  • Robin Chatterjee Monday, August 10, 2009

    Hi atul, I notice that this may be a dead thread but I belive the answer to your question is that when you run autoconfig and chek the log you will notice that there is a preliminary stage where it says updating contect values int he databse. at that point if the database has a higher serrial number than the filesystem file then the filesystem contect file will be updated by the values in the database ( i assume not all of the values. this will then result in createion of an updated xml file. in fact the xml file is rewritten every time you run autoconfig

  • Steven Chan Monday, August 10, 2009

    Hi, Robin,

    Thanks for your comment; I appreciate your dusting off this old thread.



  • Saji Jose Friday, March 26, 2010

    I have a question regarding Shared APPL_TOP in a four node

    Node 1 : Database - In App-DB DMZ

    Node 2: Application Server 1 (Web/forms/Other Services etc) - IN App-DB DMZ

    Node 3: Application Server 2 (Concurrent Manager) - IN App-DB DMZ

    Node 3: Application Server 3 ( iModule) - IN Web DMZ

    I would like to use Shared Application Tier File system (NFS) between all the application servers. Since our Application Server 3 will be deployed on Web DMZ(No NFS Between App-DB DMZ and Web DMZ), how can we implement Shared Application Tier File system. Chances of opening NFS Port between App-DB DMZ and Web DMZ is very slim

    Is it possible to keep a copy of the "Shared File System" in Node 3 instead of NFS (And Manually sync it from the Primary Server using file system copy after each Patch).

    Also, If I do this, would it be supported by oracle (Not Certified)?

  • Steven Chan Tuesday, March 30, 2010

    Hi, Saji,

    You can share the APPL_TOP between Nodes 2 and 3, since they're inside your intranet.

    You must not share that APPL_TOP with Node 3. Node 3 should have its own APPL_TOP on a local filesystem. I would recommend maintaining this APPL_TOP in the same manner that you'd maintain a standalone application server. I would generally advise against copying the shared filesystem used by Nodes 2 and 3.



  • Clive Wednesday, November 17, 2010


    I would like ask a question on this old thread to clarify a position. I noticed that after a shared file system deployment, patches applied through the master node would fail to apply completely, unless changes are made to ad component

    of the adconfig.txt file. i.e the xml file of the master node.





    Effectively, making the context file to reflect a single node configuration. Is this the best way to work this out or I needed to do something else to ensure the patches are apllied correctly on all the three node?

  • Steven Chan Wednesday, November 17, 2010


    That doesn't sound like the behaviour that I'd expect in that situation. I'd like to have someone in our team look into this to see whether it's specific to your configuration or whether there's something deeper going on. Can you log a formal Service Request via My Oracle Support (formerly Metalink) to get one of our adpatch specialists engaged?

    Please feel free to forward your Service Request number to me if it gets stuck in the support process for some reason.



  • Clive Thursday, November 18, 2010


    I found the answer to my question on this note:

    Apply Patches in a Shared Application Tier File System Environment [ID 745580.1]



  • guest Sunday, September 2, 2012

    Hi Steve,

    I know this is an old thread but I think a very important question around patching in Shared Application Tier (asked by someone in the thread) is still not completely answered.

    The question --

    When one apply autoconfig patch it will update context file of that node only & not other node context file (This is my understanding of autopatch, If patch updates all xml files then it makes sense to execute autoconfig i.e. after changes are introduced)

    But if autopatch is going to update xml file only for node on which patch is applied so that changes will not be in xml file of other node .

    If changes are not in xml file on other nodes how running of autoconfig (without new chnages in xml) will serve purpose.

    One proposed answer was --

    Autoconfig checked the serial number of the database context and the file-system context and then updates the context file on the file-system if its on a lower version.

    Is it really the case? I always thought that autoconfig actually updates/builds the context file from the autoconfig template files? and hence would like to clarify if it would ever compare the context values in the database and update them in the context file on the file server (in case they were on a lower version)?



  • guest Tuesday, September 4, 2012


    adpatch generally does not update the "values" of a context file directly. Patches usually update templates. After the file is updated by adpatch, the autoconfig portion automatically launched from the patch session will replicate the templates into configuration files. The same applies for the context file. Having said that, if for some reason, a patch changes the setting of a context variable (which I really don't recall any particular case) then the autoconfig portion will update it in the database first and second it will also update the context file on the node where autoconfig was executed. If that is the case for a patch, autoconfig should be executed separately on all the nodes to make sure the configuration is transported. If such a patch exists, the README should include this clarification.

    Regardless of this particular use case, it is always recommended to run autoconfig on all the nodes to assure consistency.

  • Max Arderius Wednesday, September 5, 2012

    Additionally, the template of the context file is treated as any other file in EBS. If it has a lower version than the patch, then adpatch will replace the file and run AC. If the version in the file system is higher, then all the actions are skipped including the AC phase.

    Adpatch has a smart criteria to run AC. In the same way, the AC phase will not be launched from adpatch if the files included in the patch don't belong to the "autoconfig template" category. In other words if a patch includes another file type not related with AC (ie .o file for binaries) then it will not run AC because is not necessary.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.