Oracle Database Tutorial: New Features of RAC11.2

Before Oracle11.2, you must register the public IP address and virtual IP address of the node to the DNS server to connect the client to the database normally and support Server Load balancer. Dimensions of some clusters

Before Oracle 11.2, you must register the public IP and virtual IP of the node to the DNS server to connect the client to the database normally and support load balancing. Dimensions of some clusters

Grid plug-and-play (GPnP)

Grid plug-and-play is used to help administrators maintain clusters. Some manual operation steps required to add or delete nodes can now be automatically implemented by GPnP.

GPnP is not a separate concept. It relies on the following features: storing cluster information in an XML configuration file, cluster time synchronization (CTSS), and grid Naming Service (GNS ); single client access name (SCAN) and Server pool (Server Pools ).

GPnP defines metadata network interfaces for public and private network connections, ASM spfile, and CSS voting disks. profile and XML files are protected by wallet to avoid modification. If you need to manually modify the profile, you must first use $ GRID_HOME/bin/gpnptool to contact the signature, then modify it, and then use the same tool to sign it again. When you use a cluster management tool (such as oifcfg), the profile is automatically updated without administrator intervention.

When NTP is not enabled, the CTSS background process is responsible for synchronizing the time between cluster nodes, which can remove the dependency on the NTP server, however, we recommend that you use NTP whenever possible -- otherwise, the time of all nodes may be consistent but inaccurate.

Before Oracle 11.2, you must register the public IP and virtual IP of the node to the DNS server to connect the client to the database normally and support load balancing. Some cluster maintenance, such as adding or deleting nodes, must be modified on DNS. If such operations happen frequently, it will make a burden. The grid Naming Service removes the ing between IP addresses and names from the DNS server and submits them to the cluster software for management. Strictly speaking, cluster software runs a small Domain Name Service and listens on another virtual IP address using subdomain delegation. Simply put, you have created a new subdomain for your domain name (example.com) (for example, ebsprod) and specified a Root Domain Name Server to map all pairs of subdomains (ebsprod.example.com) to GNS. In subsequent installation, the system will require the public network and private network information, rather than the virtual IP address and name. The address used by GNS comes from the Dynamic Host Configuration Protocol (DHCP) in the public network ). The following table provides an overview of the addresses and their usage, default names, and detailed information used for software tracking and analysis:

We recommend that you define private IP addresses in the/etc/hosts file to prevent others or other applications from using them.

In addition, GNS is optional during installation and is not yet mature enough. Some GNS-related bugs have been found.

Another feature mentioned above is SCAN. SCAN helps us abstract the number of nodes from the client connection, and the increase and decrease of nodes are completely transparent, because SCAN is more relevant to the cluster than the database.

In addition, a server pool is introduced to simplify the increase and decrease of RAC database instances.

Server Pools)

The server Pool provides a new method to shape resources in a cluster. It allows you to divide a cluster into multiple logical units, which is useful in a shared environment. All nodes in the cluster of version 11.2, whether explicit or implicit, are part of the server pool. By default, two pools are generated after a new installation: free pool and generic pool. The general pool is used for backward compatibility, it stores databases earlier than version 11.2 or administrator-managed databases in version 11.2. All unspecified nodes are allocated to the free pool.

The server pool is exclusive to each other and contains some attributes, such as the maximum and minimum number of nodes, importance, and name. The importance attribute of the server pool is used to ensure that low-priority workloads do not beat high-priority workloads to obtain resources. It is possible to re-allocate servers from one pool to another, which will be interesting in capacity management. The cluster software can automatically learn the minimum size requirement of the server pool from the mobile servers in other server pools.

The server pool is accompanied by a new method for busy RAC databases. Before Oracle 11.2, the Administrator is responsible for adding or deleting instances from the RAC database, including creating and enabling public online redo log threads and undo tablespace. The server pool (and OMF used in ASM) automates these operations through policy-managed databases.Administrator-managed databases are all managed by the database administrator, as mentioned in the name. In other words, it is the RAC database before Oracle 11.1. Policy-managed databases use automation to add and delete instances and services.The number of nodes started by the database managed by the policy is configured by the base of the server pool. In other words, if you need a new instance, you only need to allocate a new node to the server pool of the database, and Oracle will perform the rest of the work.

In combination with the server pool, Grid Infrastructure introduces another feature called Role Separated Management ). In a shared environment, administrators are restricted when managing their respective server pools. The Access Control Lists is used to allocate Access to resources. A new role named cluster administrator is introduced here ). By default, Grid Infrastructure software owner "grid" and root users are fixed cluster administrators. You can add new system users as cluster administrators. each user has several resources, types, and permissions on the server pool. Separation of duties can now be implemented at the cluster level. Note that the permissions of grid and root users are high.