Basics of Oracle 12c’s Real Application Clusters
If you’ve visited Oracle’s websites in the last 12 years, you’ve seen the marketing byline: “Unbreakable.” That tag line refers to the feature Real Application Clusters (RAC). Of course, a lot of elements are involved, but RAC has the spotlight.
RAC is Oracle’s database clustering solution. In a sense, it works on the theory that there is strength in numbers. RAC lets you have parallel database instance operating environments.
These instances cooperate to share work and back each other up in case one of them fails. RAC can help with both planned and unplanned outages. It allows you to shift your processing from server to server with little to no interruption to your end users and applications.
Real Applications Clusters versus Oracle Parallel Service
RAC, which has been around for many years, was previously known as the parallel server option. Before anyone gets flamed about when RAC was RAC, it is easy to admit that before the RAC moniker, Oracle Parallel Server (OPS) was far from the capabilities that RAC has to offer.
Oracle significantly hardened the architecture, making it more accessible and easier to set up. Oracle also focused on the components of the environment that minimize downtime. So, you could say that RAC is a new breed of OPS that far surpasses prior capabilities in usability and performance.
Determining whether RAC is right for you is a big decision. Implementing RAC requires lots of resources and money. However, sometimes spending a little more up front can save you later.
Consider what RAC can offer:
Scalability: The technology is based on computers and resources that team up as one. With RAC, you can purchase and license hardware as you need it. Furthermore, you can plug in the new hardware as you go without taking down your database. If you’ve exceeded your computing capabilities for the server, seamlessly add one to your configuration.
Uptime: RAC can harden your computing environment against planned and unplanned downtime. You can transparently remove portions of the application for planned downtime (such as maintenance, patches, and upgrades) with little to no interruption to end users. Furthermore, if one of your environment’s computing resources fails, RAC automatically transfers application connections to other resources in the framework.
Performance: Some might argue with this point, but you have to carefully define RAC’s performance capabilities:
Because RAC is a complicated environment, your application has to be designed to best take advantage. If you ignore this fact, RAC can actually hurt performance. Keep that in mind.
RAC can offer performance benefits when it comes to the divide-and-conquer methodology. You can split large jobs across computers. If you know an underpowered machine is limiting your company, reconfiguring the job to run on multiple machines can offer great benefits.
It’s called parallel processing, and it’s part of RAC fundamentals. RAC is a scaling out (horizontal) solution. This means you add nodes to the cluster rather than having one server replaced with another more powerful server, or scaling up (vertical).
How to explore Oracle 12c’s RAC architecture
RAC works through a complex organization of hardware and software configurations. Oracle databases are typically referred to as a single set of files (the database) and a single set of memory and process components (the instance) that work together for you to access and maintain your data.
That is the most typical configuration for an Oracle installation. In this configuration, the database files can be mounted and accessed by only one machine and one Oracle instance at a time.
With RAC, those files are sharable so many machines and instances can access the same files. You can have (depending on certification and versions) 100 database instances accessing the same shared database. Just like you might have two DBAs in your office:
One can vacation while the other works (read: high availability).
Both can work together on a large project to split the workload and meet an aggressive timeline (read: performance).
Add a third person to meet workload requirements as the Oracle responsibilities grow (read: scalability).
Many components are required in a RAC setup. To get a general idea of what the architecture looks like.