This content has been marked as final. Show 10 replies
Rac is for scalability, load balancing and high availabilitiy. You can initially start with a one node RAC and based on more workload and more number of users decide for adding more nodes. But in a single node RAC features of load balancing and high availability is not achieved hence you can start with minimum 2 node rac. Most of the production instances are 2 or 3 node racs.
Yes, you can split the applications on different servers like concurrent managers on database tier, apache/forms/reports on another server.
RAC means one single physical database can be installed on more than one physical computer or server for balancing workload and backup data?RAC stands for Real Application Clusters. It allows multiple nodes in a clustered system to mount and open a single database that resides on shared disk storage. When a single system fail (node), the database service will still be available on the remaining nodes.
A non-RAC database is only available on a single system. If that system fails, the database service will be down (single point of failure).
if yes, what kind company needs this? employees more than 10000?It is not a matter of number of users as it is a matter of the availability of the database. If you cannot afford a single point of failure, then RAC should be taken into consideration.
Oracle Real Application Clusters
Note: 403347.1 - MAA Roadmap for the E-Business Suite
can we also setup one single application on more than one computer? divide the application tier into components, and setup them on different computers?eg http on server A, form on server B, etcYes, and this is called "Multi-node Installation".
In addition to what has been said already:
If your company cannot afford downtime longer than 15 minutes you should consider RAC. If they can, but still want some sort of high availability, you should consider clustering on the OS level (failover clustering, aka active/passive clustering). This means that when your server fails, the entire database will be transported to and started on another server in the cluster. Usually this can be achieved within 15 minutes nowadays. If you use solutions like HACMP (IBM), ServiceGuard (HP) or Sun Cluster, you can assign a hostname to the complete package of database and/or application, so there will be no need to run autoconfig and other tools to make things work again after a failover.
Keep in mind that RAC makes your environment more complex, and therefore more sensitive to failure(s). It is a very nice solution nevertheless if you can handle/manage it.
Sami Malik,hsawwan,Arnoud Roth
thanks for your explanation. now i know something about RAC.
by the way, eg. if we set a RAC with two servers(A and B) to support database. for daily work, as default server A is in working mode and server B in standby mode, only when server A is down, server B will take over the place of A? can we setup both servers in working mode at same time for daily work?
The whole idea of RAC is that it is active/active. This means that both (or all, if you have more than 2) servers will be active members of the cluster. All servers will be initially set up to working mode. There are ways of configuring your instances (e.g. through the use of services, or client-side connect definitions in tnsnames.ora) in such a way that one of the two, or not all servers will be accessed. You will let your client failover to the other instance in case of a failure. In this way, you would manually establish an active/passive environment.
Remember though, that failover is performed on the client-side rather than the server side. In principle, both/all servers are up and running and ready to take connections, whether the clients use them or not.
It would be interesting to have EBS RAC customers indicate how many unplanned outages they had in the past year due to RAC/CRS crashes...
That is an interesting question! If you would ask me (I have been involved in several (very) large projects with E-Business Suite on RAC), I'd say quite a few. However, this is mainly due to the fact that many customers do not really understand their technology demands when it comes to RAC and cluster-related issues. This is often the root cause of many unexpected failures. That is why I am always advising customers to take on a technical architect with knowledge of cluster technology/RAC (like myself! haha!).
Oracle E-Business Suite Technical Architect
AMIS Services - The Netherlands
That's a good question !!
My experience says that this tends to be more than what we have on a non-RAC environment - however, as Arnoud pointed out, if we dissect this to classify the root causes, this is predominantly on account of clusterware (Oracle/others) or hardware/network configuration issues and less on account of underlying reasons to do with Oracle Applications stack. Yes, for EBS to have a symbiotic relationship on the RAC infrastructure, it does take time to have all issues resolved on account of the underlying complexity - the degree of which may vary from implementation to implementation, though.
So true, Rakesh! But still, too many times I see people blaming technology for their own incompetencies. Not that they are to blame, but if one doesn't know how to design, implement and manage a cluster, that is asking for trouble somewhere along the line. I see too many system admins, architects and consultants who think they know it all, and still implement faulty architectures... And then the technology is blamed for the instability it delivers.