Tuning the Cluster Interconnect - Expert Oracle RAC Performance Diagnostics and Tuning - page 456

Figure 14-4. IPTraf statistics for eth24
Check 5
Yet another method of verifying that the right interconnect is used is to dump the contents of the IPC stack from
inside the database is using the ORADEBUG utility. This method is illustrated later in the chapter as part of a
troubleshooting workshop.
Think Inside the Interconnect
In the previous chapter, we looked at scenarios of why the interconnect may not be the reason for the slow
performance. Here we look at the contrary: why interconnect can be one of the reasons for slow performance. Not
because the bandwidth of the GigE or 10GigE was not sufficient for the load, but due to several other factors that
caused the interconnect to be the reason for the poor performance.
With regard to Figure 14-1 , we discussed that the request for a block may not be satisfied by the local instance
or the master instance and may require a message to a third instance. We discussed in Chapter 13 how in a RAC
configuration there are two main message protocol types; one involves just two instances in the cluster, and the entire
communication process to request the block and find the block requires two hops. The other type is when the data is
not available in the local cache, with the master, but on a third instance. The communication in this type of operation
requires three hops to complete the request. In Chapter 13, we discussed these behaviors in Figures 13-3 and 13-5,
respectively.
We also discussed in Chapter 13 that the request for a block of data by one instance may require GCS to complete
two operational phases to get the block from the current holder to the requestor. Just to recap, we discuss these phases
briefly here and drill down into the transfer phase that involves the interconnect.