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

Is It Safe to Use SANs for EBS R12 Instance Tops?

Steven Chan
Senior Director

Guest Author: Ivo Dujmovic

Our documentation about sharing filesystems between multiple Oracle E-Business Suite Release 12 application servers recommends that you install the Instance Top (INST_TOP) on a local filesystem. This has prompted an interesting discussion about whether this is really mandatory, or whether it's technically feasible to put the Instance Top on, say, a dedicated fibre-attached SAN. 

Release 12 shared filesystem:

Our guidance on the INST_TOP being installed on a local file system is based on three major considerations:

  1. Separation of duties and security implications
  2. Impact of SAN performance on Apache
  3. Additional troubleshooting complexity

1. Separation of Duties & Security Implications

Our recommended configuration allows for different file system privileges and ownership between the Instance Top (INST_TOP) and the Code Top (ORACLE_HOMEs & APPL_TOP). This allows for the segregation of duties between administrators for the respective servers. Patching can be done on the Code Top by central system administrators who own the central shared portion of the file system. Instance Tops can be owned by instance sysadmins, who usually already own the CPU box with local storage.

Some instance-specific, run-time-generated files (e.g. reports, temp files) can include unencrypted data. Contrast those with database files (DBFs), which can be self-encrypted or contain encrypted data. Even with encrypted file system solution in place, there is less depth in defenses around some of the INST_TOP files.

2. Impact of SAN Performance on Apache

Apache performance is highly sensitive to mutex file access latency, and at higher loads is also sensitive to I/Os per second.  We tried using a central SAN for INST_TOPs in our internal EBS development environments but found the performance to be unacceptable.  However, not all SANs are created equal, and depending on the SAN, it might be good for even production use.

A very good article on this point is available from the SQLTeam web site:

3. Additional Troubleshooting Complexity

A network storage access problem can have a spectrum of symptoms, including performance slow downs and even as intermittent end-user session failures. Some of the affected code paths were made more resilient over the years, but we still prefer to err on the side of prudence and not potentially cause these (hard to diagnose) problems.

Your Mileage May Vary

All that said, you might decide that your testing of SAN performance demonstrates that its latency and I/O transaction throughput are good enough for your requirements. 

Our Support and Development teams will attempt to reproduce any reported issues in a multinode environment where the INST_TOPs are stored on a local filesystem.  If the issues are isolated to the external placement of the Instance Tops, our recommendations would be to either revert back to local storage, or to work with your SAN vendor to optimize the SAN's performance.


Related Articles

Join the discussion

Comments ( 16 )
  • Jennifer Chen Thursday, October 1, 2009

    Hi Ivo,

    One of our recent experiences may give you another reason why the INST_TOP should be installed on a local file system.

    We are running 11i shared file system architect on 4 app servers. Recently one of our ADMINs transferred our admin scripts from app1 to app2,3,4 in an attempt to keep the scripts and scheduled cron in sync. So, if one app server dies, others still function without impacting operations. But one of the scripts invoking 11i startup/shutdown scripts is server specific and 11i $ADMIN_SCRIPTS_HOME is on the $COMMON_TOP/admin/scripts/${CONTEXT_NAME} directory:





    Because $COMMON_TOP resides on the shared storage, basically it allows the server specific script to run on different servers, e.g. we can stop all app2 services from app2 and start all app2 services from app3 at the same time. That was the accident that happened to us and caused a great deal of headache and required intensive troubleshooting (SR: 7774130.992 - I also escalated the issue to Steven Chan).

    Apparently, the R12 architects are doing a better job in permitting apps DBAs to define the environment variable $ADMIN_SCRIPTS_HOME which points to the "$INST_TOP/admin/scripts" directory and it is recommended that this resides on the local disk so that sever specific scripts are truly segregated.

    Hope this helps.


  • Amir Hameed Tuesday, September 14, 2010

    Hi Steven,

    We are in the process of setting up an Advanced Supply Chain Planning environment with R12 and looking into implementing it with the Shared Application FS architecture. After I saw the recommendation on the INST_TOP in the manual and on Metalink, I decided to open an SR (3-2111204121) for clarification because it did not make much sense to me. We currently have an existing environment, which we implemented with the shared architecture about two years ago and used NFS for that purpose. In that environment, we directed the Apache Lock file to the local FS but the rest remained on NFS and it has been working fine for us. INST_TOP contains configuration files and log files (Apache, OPMN, etc). With the exception of Apache log file, the rest are not written to with frequent interval. So, the question for you is:

    - If the only issue is (in terms of performance) with the Apache Lock file which that could be pointed to a local file system and the rest of the INST_TOP could be left on NFS. What issue do you see with this configuration?

    - If you look at the Enterprise Deployment Guide for Oracle SOA Suite 11g, the recommended architecture from Oracle is to implement the entire suite on NFS. SOA 11g also uses Apache from OHS 10.1.3.x to front end the WebLogic Server. Your recommendation seems to be in conflict with what the Oracle SOA 11g team is suggesting?



  • Steven Chan Wednesday, September 15, 2010

    Hi, Amir,

    Ivo may choose to answer, but I suspect that OpenWorld-related activities may delay his response.

    As Ivo notes in his article above, our recommendations are based upon our internal tests, but that all SANs differ in their performance characteristics. We have deliberately recommended the most conservative architecture that will work for everyone.

    Depending upon your SAN, you may be able to adopt a more-aggressive stance. Your mileage may vary, so you should conduct careful performance and scalability tests to validate that your target architecture works as intended.

    If your tests conclude that your planned configuration works to your satisfaction, then you have likely answered your own question. We cannot answer it, however, since we can't replicate your transactional mix, load, nor hardware architecture. Only you can judge whether this more-aggressive strategy will work for you.

    Questions about SOA 11g might be better-answered by that team; I have no insight into their recommendations, which are (obviously) made generically without reference to EBS environments.



  • Amir Hameed Wednesday, September 29, 2010

    Hi Steven,

    My mistake for not realizing that this was not written by you. I would like to make the following points:

    - When a statement is made in a manual, it would help if a background is also provided for that statement. In this case, the reason for suggesting a local file system for INST_TOP related files should have been stated or a reference should have been provided for the suggestion.

    - This architecture can make the environment configuration quite complex. For example, In my case, I am using EMC DMX SAN storage for the database, EMC NAS (Celera/Clariion) storage for the Shared Application stack and if I were to use a local file system for INST_TOP then I will need DAS for that. Considering the way we backup our environments today where different technologies are used to backup storage on different frames (EMC's BCV technology to backup storage on DMX SAN, EMC's snap technology to backup storage on the clariion storage), the use of DAS in the mix would further complicate the backup process because we wil need to use a different technology to back it up.

    - Finally, can Ivo share his tests with us so that we know how he tested it and whether he ever tried putting just the Apache lock files on DAS as opposed to putting the entire INST_TOP.



  • martin brambley Tuesday, August 30, 2011


    (thanks in adv. helping on previous Q's i may not have thanked you for)

    I am busy singing the virtues of OracleVM to my current client and trying to migrate their over complicated infrastructure to OracleVM.

    I see all oracle products are now supported on it including R12.

    However I want to take advantage of the HA features of OVM.

    surely putting the INST_TOP on local storage means you cannot HA enable your midtier VM's. Can you let me know if the oracle advice is that you cannot use OVM HA clusters with R12? (seems odd given the praises Wim et al were just singing about it at the OVM3.0 release). Or can you tell me how this can be achieved.

    Thanks again

    Martin Brambley

  • Ivo Dujmovic Tuesday, August 30, 2011


    Please excuse if point 2. from the article is not clear enough, but it is meant to answer exactly your question. E-Business Suite does not require Instance Tops be placed on local storage; we instead require Instance Tops be placed on low latency storage.

    If your OVM HA cluster provides low-latencies, you can place your Instance Tops there without any known issues. However, if your storage latency (used for Instance Tops) deteriorates, you will likely experience Apache performance problems.

    Hope this clarifies the point.



  • Riley Carrier Tuesday, January 24, 2012


    We upgraded to 12.1.3 in July 2011 from with $INST_TOP residing on Sun 7210 SAN as an iSCSI target. We rarely experienced issues in the 11.5.10 environment related to Apache. We encountered period failures (weekly) with Apache and core services that were directly related to have the $INST_TOP on the SAN.

    To complicate the picture, our entire environment is VM based i.e., all Linux servers are running as guests under Oracle VM with guests using iSCSI targets. We had no physical servers running Oracle EBS and no local disks that were "physical."

    To solve the issue, we created a small partion on the underlying VM server and made it available to the production guest as a physical disk. Once we moved the instance top to that local disk, the number of failures was reduced immediately and the instability we were seeing was eliminated. I'm a believer--at least with low-end SAN solutions.

    Riley Carrier

  • Steven Chan Wednesday, January 25, 2012

    Hi, Riley,

    Thanks for letting us know about your experiences with that configuration. This is very helpful.



  • guest Thursday, February 2, 2012

    Hello Steve,

    Please correct if my understanding is right or wrong article "Is It Safe to Use SANs for EBS R12 Instance Tops?" is this something to do with Shared Application tech stack / Shared applicaiton tier / Shared appl_top?

    If I use SAN for having separate application tiers without configuring Shared Application tech stack / Shared applicaiton tier / Shared appl_top then will there be any issues? Please advice.

    Thanks in advance

  • Steven Chan Thursday, February 9, 2012

    Hello, Guest,

    You can use SANs for shared application tier file systems. This article goes into more detail about selecting file systems for the E-Business Suite:

    Choosing a Shared File System for Oracle E-Business Suite


    You can use SANs for individual application tier file systems without setting up a shared file system. The drawback of taking that approach would be that you would need to patch each of the individual file systems separately.



  • guest Wednesday, February 15, 2012

    Thanks Steven.

    So the conclusion is "we can use SAN for individual application tier file systems without setting up a shared file system and there are no issues with it ?" and there are no issues except for the suggested drawback -patching each of the indvidual f/s separately.

  • Steven Chan Thursday, February 16, 2012

    Hi, Guest,

    Yes, that would be a generic statement.

    All SANs have different performance and I/O characteristics, so I'd recommend that you conduct load-testing to ensure that there aren't any latency-driven side-effects when your individual servers are all accessing the same SAN storage under load. As always, your mileage may vary, so actual performance testing is crucial to validating any storage architecture in real conditions.



  • guest Tuesday, March 4, 2014

    does this still hold true for ebiz 12.2?

  • Steven Chan Tuesday, March 4, 2014

    Hello, Guest,

    Yes, this article still applies to EBS 12.2. We do not certify individual storage systems or third-party hardware with the E-Business Suite. These systems are assumed to be compatible without requiring application-level changes to E-Business Suite code.

    As always, you should test your hardware with the E-Business Suite before deploying it into production.



  • guest Tuesday, February 24, 2015

    Per the note 1375769.1, it recommends putting the INST_TOP on shared storage when using a shared application tier file system. It appears it must be shared for the add node procedure to work as documented. Is it best practice to keep the INST_TOP on shared storage when using a shared application tier file system?


    "•It is recommended to keep the Instance Top ( INST_TOP) on the shared file system for 1) Ease of maintenance 2) The number of application tier processes writing to this location is limited when compared with the previous releases."

  • Steven Chan Tuesday, February 24, 2015

    Hello, Guest,

    Yes. As documented in Note 1375769.1, we recommend that you keep the INST_TOP on the shared file system.



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