3.6 Changes between OPS and RAC

---

Administrators who are familiar with OPS technology will know that RAC is the successor to this technology. After the release of OPS with Version 6.2, Oracle evolved this product over the years, and has, during the evolution process, encountered certain performance issues. As with every version of Oracle RDBMS, enhancements to OPS have been under way. With the purchase of Oracle Rdb from Digital Equipment Corporation in 1993, Oracle RDBMS has seen several changes to its core functionality and performance improvements. Most of the enhancements have existed in Oracle Rdb, in some form or another, for quite some time.

Oracle Rdb, primarily functional on Open VMS platforms (pioneers in the clustering technology), has worked in a clustered configuration since its inception into the market. For quite some time Oracle only worked as a single instance configuration. However, with Version 6.2, Oracle has introduced the clustered concept into this product line with OPS.

One of the main performance and scalability concerns in OPS has been around data sharing between multiple instances, as this typically caused pinging activity. Pinging is forced writing of information in the memory of one instance onto disk, so that this information is available to the other instances requesting access to this information. An example of pinging is as follows. Instance 1 places a request to read a row from employee table with employee ID = 45987. While reading this row from the disk, Oracle, in its ultimate wisdom to share and expecting the request for the next (thinking ahead), reads the entire block. Reading the entire block also reads in certain additional rows. Depending on the block size and the data being retrieved, typically the previous rows and the subsequent rows are retrieved, for example, rows with employee IDs 45988, 45989, and 45986. Assume another user has connected to another instance, Instance 2, which is part of the clustered configuration, and has requested access to the row for employee ID 45987. While attempting to read the row from disk, Oracle realizes that the row is in a block that has already been acquired by Instance 1. In order to gain access to the row of data, Oracle requests the Instance 1 to write the block back to disk so that Instance 2 can get access to the row in the same block. This writing to disk to allow the Instance 2 to read the row is called pinging. This write activity to disk to allow Instance 2 to read the row incurs an I/O operation. This in turn causes performance problems. Pinging activity between instances is a tuning nightmare for database administrators.

While Oracle Rdb also functioned in a clustered configuration and had a similar functionality, it did not cause performance issues during a similar operation. This is because data did not get written to disk in order for the other node to gain access to it but instead was transferred across the cluster interconnect to the other node. In Version 8.1, Oracle had introduced this concept, called cache fusion. While cache fusion was only available for read/read operations, with Oracle 9.0 it has been enhanced to provide support for operations of all types (read/read, read/write, and write/write).

The concept of transferring data between cache of one instance to cache of another instance is called cache fusion. Cache fusion guarantees cache coherency among multiple cluster nodes without incurring disk I/O costs.

With the new concept of sharing information across the cluster interconnect and other various enhancements to other areas of the system, the product was renamed RAC, potentially to create a new paradigm shift and to remove all the performance concerns surrounding OPS.

Table 3.3 provides a comparison chart between OPS and RAC.

Table 3.3: OPS vs. RAC

Oracle Parallel Server	Real Application Clusters
Called Oracle Parallel Server (OPS) in Version 8i and prior versions	Called Real Application Clusters (RAC) in Version 9i
Synchronization of instances only by pinging	Synchronization between instances is using the cache fusion technology via the cluster interconnect
Uses the PCM locking technology	Does not use the PCM locking technology. This has been rewritten in RAC
OPSCTL	SRVCTL
OPS daemon	Global services daemon (GSD)
OPS management	Server management (SRVM)
Parallel cache management	GCS block requests
Lock mastering	Resource mastering
Lock database	Resource database
Block server process (BSPn)	Global cache server process (LMSn)

3.6.1 Terminology changes

This section provides a brief introduction to changes in terminology between OPS and RAC. A more detailed discussion about the functionalities will be found in the appropriate sections in the book.

Oracle Parallel Fail Safe (OPFS) is replaced with Oracle Real Application Cluster Guard.

This feature is now integrated with Microsoft's Cluster Server (MSCS) and makes use of Internet protocol (IP) failover and Microsoft's cluster management utilities.

The term distributed lock manager (DLM), is obsolete. The background processes that were formerly aggregated under the DLM in previous cluster software products still exist, but the DLM no longer manages resources under RAC. The two new processes, global cache service (GCS) and global enqueue service (GES), handle the management functions that had been handled by the DLM in OPS.

The OPSCTL utility has been replaced with SRVCTL utility. SRVCTL manages configuration information that is used by several Oracle tools. For example, Oracle Enterprise Manager (OEM) and the Oracle Intelligent Agent use the configuration information that SRVCTL generates to discover and monitor nodes participating in the cluster.

The global service daemon (GSD) has replaced the Oracle Parallel Server communications daemon (OPSD). OPSD under OPS is a process that received requests from the OPSCTL utility to execute administrative job tasks, such as startup and shutdown. Under a RAC the GSD also performs exactly the same function; however, and instead of the OPSCTL utility, it receives requests from the SRVCTL utility. The only difference is that the OPSD service that was not available under Windows for OPS, GSD, is available under windows.

Server Management (SRVM) has replaced Oracle Parallel Server Management (OPSM). OPSM under OPS was used for management of OPS instances, including startup, shutdown, etc. Under RAC, the SRVM process does the same functionality, however, and also provides support to OEM by providing functions such as scheduling jobs, event management, monitoring performance, and the obtaining of statistics of the clustered database. SRVM is part of OEM.

The term parallel cache management (PCM) is obsolete. These operations have been replaced by GCS block requests. PCM locks under OPS are distributed locks that cover one or more blocks in the buffer cache. With the GCS functionality being introduced the PCM locks are now obsolete with RAC implementation.

The term non-PCM is obsolete. The GES implements the resource management functions.

Lock mastering is obsolete. The equivalent function in RAC is resource mastering.

The lock database under OPS is obsolete. The global resource directory (GRD) handles the equivalent functions in a RAC configuration. Under the OPS implementation, Oracle maintained a lock database to manage cluster-interdependent locks on blocks being accessed by multiple nodes. With the RAC implementation, the lock database concept is obsolete; however, it is replaced with a new functionality called GRD. As in the lock database concept, GRD is maintained on one instance. Each instance portion of the GRD contains the information about the current statuses of all shared resources. Information contained in GRD is used by Oracle during instance failure recovery and during cluster reconfiguration.

3.6.2 Parameter changes

The OPS_INTERCONNECTS parameter is replaced by CLUSTER_INTERCONNECTS.

OPS_INTERCONNECTS, which is an optional undocumented parameter under OPS, provides information about additional cluster interconnects for use in OPS environments. Oracle uses the information from this param eter to distribute traffic among the various interfaces. However, CLUSTER_INTERCONNECTS, another optional, but documented, parameter under RAC, does exactly what OPS_INTERCONNECTS did under OPS.

The PARALLEL_SERVER parameter is replaced by CLUSTER_DATABASE.

PARALLEL_SERVER under OPS, which informs Oracle if the clustered database solution has been enabled, is replaced with the CLUSTER_DATABASE parameter under RAC.

The PARALLEL_SERVER_INSTANCES parameter is replaced by CLUSTER_DATABASE_INSTANCE.

PARALLEL_SERVER_INSTANCES under OPS, which informs Oracle regarding the number of instances that have been enabled, is replaced with CLUSTER_DATABASE_INSTANCE under RAC.

3.6.3 Data dictionary changes

In this section only the basic differences between OPS and RAC have been highlighted, a detailed discussion on the various data dictionary views is forthcoming in Chapter 9 (Parameters and Views).

• GV$DLM_MISC is replaced by GV$GES_STATISTICS

• GV$DLM_LATCH is replaced by GV$GES_LATCH

• GV$DLM_CONVERT is replaced by GV$GES_CONVERT_LOCAL

• GV$DLM_CONVERT_REMOTE is replaced by GV$GES_CONVERT_REMOTE

• GV$DML_ALL_LOCKS is replaced by GV$GES_ENQUEUE

• GV$DLM_LOCKS is replaced by GV$GES_BLOCKING_ENQUEUE

• GV$DLM_RESS is replaced by GV$GES_RESOURCE

• GV$DLM_TRAFFIC_CONTROLLER is replaced by GV$GES_TRAFFIC_CONTROLLER

• GV$DLM_LOCK_ELEMENT is replaced by GV$GC_ELEMENT

• GV$BSP is replaced by GV$CR_BLOCK_SERVER

• GV$LOCKS_WITH_COLLISIONS is replaced by GV$GC_ELEMENT_WITH_COLLISIONS

• GV$FILE_PING is replaced by GV$FILE_CACHE_TRANSFER

• GV$TEMP_PING is replaced by GV$TEMP_CACHE_TRANSFER

• GV$CLASS_PING is replaced by GV$CLASS_CACHE_TRANSFER

• GV$PING is replaced by GV$CACHE_TRANSFER

The following new data dictionary views have been added under the RAC implementation:

• V$HVMASTER_INFO: This view describes the current and previous master instances and the number of times remastering of the GES resources has occurred.

• V$GCSHVMASTER_INFO: This view describes the current and previous master instances and the number of times remastering of the GCS resources has occurred, excluding those belonging to files mapped to a particular master.

• V$GCSPFMASTER_INFO: This view describes the current and previous master instances and the number of times remastering of GCS resources that belong to files mapped to instances has occurred.

---