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.
Our guidance on the INST_TOP being installed on a local file system is based on three major considerations:
- Separation of duties and security implications
- Impact of SAN performance on Apache
- 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:
- Which is Faster: SAN or Directly-Attached Storage? (SQLTeam.com)
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.
References
Related Articles
- Choosing a Shared File System for Oracle E-Business Suite
- Sharing Apps R12 File Systems Across Multiple Database Instances
- Reducing Patching Downtimes via Shared Apps File Systems
- In-Depth: Load-Balancing E-Business Suite Environments
- Case Study Redux: Oracle's Own Oracle E-Business Suite Release 12 Upgrade
Comments (1)
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:
$COMMON_TOP/admin/scripts/xxxxxprd_xxxxx-app1
$COMMON_TOP/admin/scripts/xxxxxprd_xxxxx-app2
$COMMON_TOP/admin/scripts/xxxxxprd_xxxxx-app3
$COMMON_TOP/admin/scripts/xxxxxprd_xxxxx-app4
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.
Jennifer.
Posted by Jennifer Chen | October 1, 2009 11:12 AM
Posted on October 1, 2009 11:12