Summary

There are two main reasons for looking at RAC—high availability and scalability. As far as high availability is concerned, setting up RAC is not a trivial operation and you should think carefully about your minimum acceptable down time before introducing such a complex stack into your business. As far as scalability is concerned, you need to be aware that badly designed applications may get worse in a RAC environment because of the traffic between instances; on the other hand, a well-designed application may allow you to match your user base with the number of commodity machines you group into a cluster in a nearly linear fashion.

A core feature of the implementation of RAC is that instances need to inform each other of the objects they are using, and the need to protect them properly. Oracle handles this in a distributed Global Resource Directory (GRD). Every object—down to the granularity of the block for data segments—has a master resource that lists the interest that every instance has in the resource. In general, the location of the master resource can be derived by simple arithmetic. Each instance that has attached an enqueue to the master resource will also keep a local “shadow” resource—as far as the data buffer is concerned this allows Oracle to ensure that only one instance can update a block at a time, and that the instance that is holding the master resource for a block coordinates its movement across the network when the block is needed by another instance. The implementation that Oracle uses for the GRD ensures that, no matter how many instances there are in the cluster, the largest number of steps required for an instance to acquire a block is three—this is how Oracle offers the potential for near perfect scalability as you add nodes. However, the probability of a three-way negotiation taking place increases as the number of instances increases, and three-way transfers are slower than two-way transfers.

When an instance crashes, one of the other instances will detect the crash very rapidly—and take control of recovery on behalf of that instance; this involves two steps. First it reverse engineers the master resources held by the crashed instance, which it can do by interrogating the other instances for the relevant shadow resources; then it simply reads the redo log files of the crashed instance in a way that virtually mirrors an absolutely standard recovery—pinning the blocks that need recovery in its buffer cache until the recovery is complete. It will also freeze the GRD temporarily while adjusting the algorithm that the cluster needs to follow to calculate where each master resource should now be located.

There are many small details to consider when converting from single instance to RAC, and lots of little ways you can engineer your design for optimum performance. In this chapter I have selected sequences as a showcase to highlight the patterns of thought that you need to follow to avoid the traps that RAC can lead you into. Sequences in RAC are a threat—you need to think carefully about what costs you are prepared to suffer if you really want to use them. At a minimum you should set the cache size for popular sequences to something much larger than the Oracle default. Don’t use nocache, and don’t use order unless the sequence sees very little activity.

Since sequences are often used to generate artificial keys, they also introduce hot spots at the “high-value” end of indexes; be cautious about using reverse key indexes to combat this problem as the strategy can lead to increased levels of disk activity—hash partitioned indexes may be a good idea, if you’ve already paid for the partitioning license.