Capacity Planning and Architecture - Expert Oracle RAC Performance Diagnostics and Tuning - page 38

Re-mastering also happens when an instance joins or leaves the cluster. However, instead of re-mastering all
locks/resources across all nodes, Oracle uses an algorithm called “lazy re-mastering.” Basically, under this method,
instead of load balancing the objects by removing all objects and re-mastering them evenly across instances, Oracle
only re-masters the objects owned by the instance that crashed. Subsequently, during a future time GCS would
consider placing the object master on an instance where the requests are the highest for the object.
Figure 2-6 illustrates the re-mastering of resources from instance SSKY4 to instances SSKY2 and SSKY3 ,
respectively.

Public Interface

Cluster Interconnect

ORADB1 ORADB2 ORADB3 ORADB4

SSKY1 SSKY2 SSKY3 SSKY4

R4

R1 R5

R6

R2 R3

R7

AV1 AVL9 AV10 AV11 AV12 AV13 AV14 AV15 AV16 AV17 AV18

GRID_DATA PRD_DATA PRD_FRA

Figure 2-6. Object re-mastering

If instance SSKY4 crashes, instance SSKY1 and instance SSKY2 will continue to master their resources, namely,
R1, R2, R3, and R4. As part of the recovery process, the resources mastered on the failed instance will now have to be
mastered by one of the surviving instances. Oracle uses the lazy re-mastering concept and dynamically places the
resource master on one of the surviving instances. Consequently, per our illustration in Figure 2-6 , R6 is inherited by
instance SSKY2 and R7 is inherited by instance SSKY3 ; instance SSKY1 is not affected.