In my post about RAC on Loosely-Coupled Clusters I discussed how strange it is to me that RAC is a shared disk architecture yet RAC deployments are shared-nothing for everything except the database. I mentioned the concept of Shared Applications Tier as well. Arnoud Roth has a post about shared APPL_TOP on the AMIS Technology Blog that I recommend you investigate. It seems there are some gaps in the shared APPL_TOP methodology that I was unaware of. There are a lot of folks doing shared APPL_TOP so perhaps they were all simply willing to work through these issues. They are issues nonetheless and do warrant consideration.
DISCLAIMER
I work for Amazon Web Services. The opinions I share in this blog are my own. I'm *not* communicating as a spokesperson for Amazon.
In other words, I work at Amazon, but this is my own opinion.
Pages
- About
- Index of Posts
- Misc
- Papers, Webcasts, etc
- SLOB Resources
- Little Things Doth Crabby Make
Blogroll
- AWS Database Blog
- Bart Sjerps
- Beat Ramseier
- Bertrand Drouvot's blog
- Daniel Westermann
- flashdba
- Franck Pachot
- Frits Hoogland
- Gokhan Atil
- James Morle
- Jan Karremans Blog (Johnnyq72)
- Jason Arneil
- Jonathan Lewis
- Luca Canali's Blog
- Mahmoud Hatem Blog
- Mark Smith
- Martin Bach
- Mauro Pagano
- Nikolay Savvinov
- Noons
- Pardy DBA
- Real World Technologies
- StorageIOblog (Greg Shulz)
- THE ORACLE ALCHEMIST
- The SQL Herald
- Tim Hall
Join 744 other subscribers
Recent Posts
- VMware Are Serious About Oracle Database Performance Characterization
- Little Things Doth Crabby Make – Part XXIII. IEC 60027 Still Makes Me Crabby!
- Microsoft Shares Oracle Database Direct NFS Capabilities with SLOB Testing Results
- Announcing SLOB 2.5.4
- Announcing SLOB 2.5.3
- (no title)
- Following Various Legal Action Regarding “Oracle Cloud Revenue”
- Announcing SLOB 2.5.2.4
- Announcing SLOB 2.5.2.3
- Announcing SLOB 2.5.2.2
Recent Comments
11.2.0.4
Automatic Workload Repository
AWR
columnar database
column projection
DBaaS
Exadata
Exadata benchmarks
Exadata ERP
Exadata OLTP
Exadata Storage Grid
Exadata Xeon 5600 Datawarehousing
HP Oracle Database Machine
Netezza
Netezza Oracle
NUMA
numactl
OOW12
OpenWorld
OpenWorld 2011
Oracle
Oracle Database performance XtremIO flash
Oracle Exadata Storage Server
Oracle Exadata Storage Server Software
Oracle I/O Performance
Oracle Performance
Oracle Programmable Storage Server
predicate offload processing
Random I/O
Sandy Bridge
SLOB
SLOB Testing
SUMA
Teradata
whitepaper
X2-2 vs X2-8
Xeon E5
Xeon E5-2600
Xeon E7 Performance
XtremIO
Copyright
All content is © Kevin Closson and "Kevin Closson's Blog: Platforms, Databases, and Storage", 2006-2015. Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Kevin Closson and Kevin Closson's Blog: Platforms, Databases, and Storage with appropriate and specific direction to the original content.
Hi Kevin,
First of all: Thanks for your recommendation.
Can you please edit your post and spell my name correctly?
It is Arnoud Roth, not Peter Arnoud (where did you get this Peter from, by the way?;-)
Regards,
Arnoud Roth
Hi Kevin,
Thanks for this recommendation! However, can you change my name to Arnoud Roth, in stead of Peter Arnoud? I am wondering how you got this Peter to come around…(I’ve got a brother who is called Peter, allright, but I am sure you didn’t know that;-).
Regards,
Arnoud Roth
Arnoud,
Sorry about that, Arnoud, I have no idea what sort of cut and paste mistake I made! It’s fixed now though.
We had tested the EBS 11.5.9/9.2.0.6 suite in a three-node RAC configuration last year and used shared ORACLE_HOME for our configuration. We used the Veritas SF suite 4.1 for RAC(first 3.5 MP4 and then upgraded to SF 4.1). Earlier on, we did discover the inability of the srvctl to work with the EBS but we were not controlling the database instances with srvctl; we were using the veritas agent to manage our instances and that does not use the srvctl utility. I have not worked with the Oracle clusterware but I believe that it uses srvctl to manage instances. I did not have any issues with the shared ORACLE_HOME, at least we did not discover anything in our testing. I did not try to clone a RAC environment to create another one and that was one of the items I had on my plate but we did not implement RAC in production due to severe performance issues due to a bug that we could not catch in our testing (long story).
I want to clarify that ONLY the database and the RDBMS ORACLE_HOME were residing on the clustered filesystem. The APPL_TOP and the related technology stack were not shared.