22. “ ABC” block of data written to the disk drives in the database Node A Node B ABC Data
23. “ ABC” block of data read into memory on Node A Node A Node B ABC Data ABC Data
24. “ ABC” updated to “XYZ” in cache Node A Node B ABC Data ABC Data XYZ Data
25. Node B requests data block Node A Node B ABC Data ABC Data XYZ Data I want data! Gimme! Gimme!
26. Node A must write data block to disk drive Node A Node B ABC Data XYZ Data I want data! Gimme! Gimme! ABC Data XYZ Data write Previous to 9i RAC
27. Node B must read data block from disk drive Node A Node B ABC Data XYZ Data XYZ Data ABC Data XYZ Data read Previous to 9i RAC
28.
29. Shared Cache Across Nodes Users Database Server Server Server Server Cache Cache Cache Cache
30.
31.
32.
Editor's Notes
Oracle RAC allows multiple nodes to run multiple instances of Oracle while accessing a single physical database. On Linux, the maximum number of nodes supported in a certified configuration is eight.
Oracle has had clustering functionality in their product for a long time. Previously, the clustering technology was more dependent on the Operating System. Oracle chose to incorporate more of the the clustering functionality into the Oracle database rather than rely on how the OS does clustering. Oracle 9i and 10g RAC have more of the key clustering capabilities within Oracle itself. This means that the clustering is done differently than it was with OPS. From the Oracle 9i RAC whitepaper off of the Oracle website (see http://otn.oracle.com/products/oracle9i/pdf/appclusters_cache.pdf): “A cluster database lays on top of a hardware cluster. The hardware cluster architecture and the database cluster architecture may be the same; or may differ.”
Improved cluster aware tools: Oracle Universal Installer (OUI) Enterprise Manager (EM) Database Configuration Assistant (DBCA) Net Assistant (NetCA) Recovery Manager (RMAN) Command line interface (SRVCTL) The database configuration assistant (DBCA) has been enhanced for clustered operation for the fundamental operations: Create cluster database Create the server initialization file (SPFILE) Centralized, persistent Real Applications Clusters configuration storage Eliminates consistency problems with per node text file-based configuration files Add and delete instances Oracle Enterprise Manager has been enhanced at both the database level and at the drill down level for individual instances. These are some of the enhancements for the database as a whole. Report Generation: Generate/View reports for targets of type cluster database and cluster database instance Redo log assignment: Assign redo log groups to specific threads Wizards/Tools: Full support cluster support SPFILE Handling: View and update server side initialization parameter file Details of in-doubt transactions At the drill down level for each instance, Oracle Enterprise Manger provides detail information. Session Handling: List status of connected users, view latest SQL for the session, kill a session Lock Details: SQL DML enqueues, transaction enqueues and row level locks Resource Monitoring: Performance statistics of active resource plans For the cluster database: create/modify resource consumer groups and define/modify/activate resource plans
Real Application Clusters are designed as a “Shared Everything” architecture. This means that both server resources and storage resources are shared, with a single database image. This is beneficial for scalability and flexibility. However, the shared nature of all of the resources (particularly storage) make it more important than ever to institute a High Availability architecture, to avoid single points of failure.
Oracle RAC is “Shared Everything” clustering. This allows all nodes in the cluster to have access to the data at the same time. There is only one set of data that all of the nodes can use at all times.
According to Oracle Corporation, the ultimate goal for Real Application Clusters is to provide manageability that is comparable to a single computer with a single instance of the Oracle database. In other words, for the common management tasks, the goal is to have the system look and behave like a single system.
Each node has it’s own dedicated system memory as well as its own operating system, database instance and application software
Because the number of nodes in the cluster can grow as needed, and because they all have access to all of the same data, RAC can be used for both load-balancing and for failover: Load-balancing If you have the same application loaded on all of the nodes in the cluster, users can be distributed across all of the nodes. (In either a round-robin fashion or through distribution.) In either case, any user connecting through any node with see the same data. Failover Oracle RAC can also be used for failover. Since any 2 nodes will be configured exactly the same and have access to the same set of data, if one serer in the cluster goes down, the users can be transferred to another node in the cluster and the replacement node(s) will take over the duties of the failed server.
Listener The listener is a process that resides on the cluster server nodes. This process listens for incoming client connection requests and manages the traffic to the server. The listener brokers the client request, handing off the request to the server. Every time a client (or server acting as a client) requests a network session with a server, a listener receives the actual request. If the client's information matches the listener's information, then the listener grants a connection to the server.
Databases register with the listeners when started. Nodes in the cluster report their CPU usage to the registered listeners (pmon).
Then when a request comes in from a client, the Listener can assign the client to the least busy server.
Each node in the cluster has a different physical internet protocol address. However, users (or clients) connect to the database via a virtual database service name. Oracle automatically balances the user load among the multiple nodes in the cluster. The RAC database instances on the different nodes subscribe to all or some subset of database services. This allows you to choose whether specific application clients that connect to a particular database service can connect to some or all of the database nodes. If more nodes are added to the cluster, the CPU and memory resources of the new node are immediately made available to the rest of the cluster. (Data does not have to be re-partitioned.) This allows you to add nodes as you need them.
RAC specific enhancements include improvements that dramatically reduce the time to recover. These improvements include increased parallelism and reduced work by smarter algorithms. The Global Cache Service now only does the minimal amount of work needed to recover from node exits and joins to the cluster. The Global Resource Directory due to tight integration with the server processes is maintained optimally.
If a node in the shared disk cluster fails, the system dynamically redistributes the workload among the surviving cluster nodes.
Transparent Application Failover Real Application Clusters provide near-continuous availability by hiding failures from end-user clients and application server clients. Transparent Application Failover in the database transparently re-routes application (query) clients to an available database node in the cluster when the connected node fails. Application clients do not see error messages describing loss of service. Failures are also hidden from update clients, in a similar fashion, by way of a simple application coding technique. The failover routine calls the appropriate client library function to re-route the connection. Furthermore, you can configure database clients to pre-connect, or to have redundant idle connections. These redundant connections with another database node avoid delays if thousands of users must migrate servers during a node failure.
Oracle 9i RAC brought several improvements in scalability over Oracle Parallel Server in the following areas: Full Cache Fusion Enhanced coordination of cache management and distributed lock manager (DLM) Lock simplification and automation Global Cache Service coordinates local buffer cache and remote block transfers Enhanced IPC Resource configuration simplification and automation
Oracle 10 g RAC features a number of new features and improvements to existing features. These new features for Oracle 10g RAC are additive to the improvements introduced in Oracle 9i
Normally, when a node (that does not already have the data in memory) requests a data block, the node that does have the data (and thus has a lock on the data block) must write that data to disk and then the other nodes can access the same data block. This uses disk I/O to keep the data synchronized across multiple nodes. That means that the data has to be physically written to a drive which involves mechanical moving components, and therefore, is inherently slower than passing data from memory. It also means that the various nodes must communicate regarding lock status.
Cache Fusion in Oracle RAC allows immediate transfer of information from one node’s cache to another node without having to write to disk first.
Cache Fusion uses the collective caches of all the nodes in the cluster to satisfy database requests. Requests for a data block can now be satisfied by the local cache or any of the other caches (instead of having to go to the disk drive). Expensive disk I/Os are only performed when none of the collective caches contain the necessary data and when an update transaction performs a COMMIT operation that requires disk write guarantees.
No init.ora In previous Oracle Parallel Server releases, there were a number of sometimes difficult parameters that needed to be set in the init.ora file. In particular the GC_FILES_TO_LOCKS parameter was difficult to understand and correctly set. This was carried forward from Oracle7 when the DLM was external to the database. In Oracle 9i and 10g the DLM no longer exits; it has been integrated with the buffer cache manager and is now the Global Cache Service. With this integration there is no longer a need for configuration parameters and the memory taken up by resources in the Global Resource Directory is greatly reduced as compared to earlier releases. Resource Affinity and Dynamic Resource remastering Resource affinity optimizes the system in situations where update transactions are being executed on one instance. When activity shifts to another instance the resource affinity will correspondingly move to the new instance. If activity is not localized, then the resource ownership is hashed to the instances. Oracle 10g offers performance improvements in dynamic file and cache affinity.
![Overview ,[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)