Shulou(Shulou.com)05/31 Report--

This article mainly explains "Oracle RAC LoadBalance is useful", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's make up a small series to take you to learn "Oracle RAC LoadBalance what to use"!

Load Balance is to distribute the load evenly to each node in the cluster, thus improving the overall throughput capacity. Oracle10gRAC provides two different ways to spread the load:

1. Through Connection Balancing, users are assigned to different nodes according to some algorithm. It can also be considered a purely technical distributed load.

2. Through Service, it is distributed on the application layer, which can also be considered as the distributed load of the face service.

1.Connection Balancing

Connection Balancing This kind of Load Balancer is carried out at the user connection level, that is, when the user requests to establish a connection, it is decided to allocate the connection to which instance according to the load of each node. Once the connection is established, all operations of the session are completed on this instance and will not be dispatched to other nodes.

ConnectionBalancing can be implemented in both client and server ways.

1.1 Client-Side LB

Client-SideLB is the method used by Oracle8 and configured by adding: LOAD_BALANCE=YES to the client's tnsname.ora file.

When a client initiates a connection, it randomly selects one from the list of addresses and uses a random algorithm to distribute the connection request to each instance.

The TNS profile for a Clint-SideLB is as follows:

RAC=

(DESCRIPTION=

(ADDRESS=(PROTOCOL=TCP)(HOST=rac1-vip)(PORT=1521))

(ADDRESS=(PROTOCOL=TCP)(HOST=rac2-vip)(PORT=1521))

(LOAD_BALANCE=YES)

(CONNECT_DATA=

(SERVER=DEDICATED)

(SERVICE_NAME=RAC)

)

)

)

Note: rac1-vip needs to be added to the hosts file

The disadvantages of this method are obvious, because the real load of each node is not considered when allocating connections, and the final allocation result is not necessarily balanced; and the random algorithm requires a long time slice, if multiple connections are initiated simultaneously in a short time, these connections may all be allocated to a node, or even worse, the connection may be allocated to the failed node. Oracle introduced the Sevice-Side LB approach.

1.2 Server-Side LB

Server-Side LB was introduced from Oracle9. Its implementation relies on Listeners to collect load information.

As the database runs, the PMON daemon collects system load information and registers it in the Listener. PMON will update information in at least 1 minute and at most 10 minutes, and if the load of the node is higher, the update frequency will be higher, so as to ensure that the Listener can grasp the accurate load situation of each node. If the Listener is closed, the PMON process checks every second to see if the Listener is restarted. In addition to this automatic, timed update task, users can also perform this process manually using the alter system register command.

This automatic update action can be seen in the Listener log, such as the following Listener log fragment clearly records these actions. Note that the first registration process performed by the PMON process at instance startup is called Server-register, and the subsequent update process is called service-update.

[root@rac1log]#pwd

/u01/app/oracle/product/10.2.0/db_1/network/log

[root@rac1log]#more*.log

.....

27-FEB-201002:15:10*service_register*rac1*0

27-FEB-201002:15:11*service_update*rac1*0

27-FEB-201002:15:11*service_update*rac1*0

27-FEB-201002:15:23*service_update*+ASM1*0

27-FEB-201002:15:32*service_update*+ASM1*0

.....

Although the Listener log records the registration and update actions of the PMON process, the registered contents are not reflected. To obtain these contents, you can obtain them by tracking the 10257 time. This event is to track PMON activities.

Event="10257 trace name context forever,levl16"

For more information on the use of events, see my blog:

http://blog.csdn.net/tianlesoftware/archive/2009/12/13/4977827.aspx

PMON processes register not only with local Listeners, but also with Listeners on other nodes. However, exactly where you want to register is determined by two parameters: Remote_Listeners and Local_Listener. Local_Listener does not need to be set, while Remote_Listener needs to be set. The parameter value is a tnsnames item.

With PMON's automatic registration mechanism, the Listener of each node in the cluster knows the load of all nodes. When receiving a client connection request, it will transfer the connection to the node with the least load. This node may be itself or other nodes, that is, the Listener will forward the user's request.

The node selection method of the Listener varies according to the connection method requested by the user:

1). If the user requests a Delicate private connection, the Listener selects the node with the least load first, and if multiple nodes are equally loaded, selects the instance with the least load from the node.

2). If the user requests a ShreServer shared function connection, in addition to node load comparison and instance load comparison, select the Dispatcher with the lowest load on the selected instance for forwarding.

Server-Side LB and Client-Side LB are not mutually exclusive. They can work together. In this case, the user's connection request will first randomly select an address from the address list, and then send a request to the Listener of this address. After receiving the request, the Listener selects the most suitable node according to the load of each node to forward the connection request.

1. Server-side Load Balancer needs to configure the remote_listener parameter, and the value of this parameter depends on the connection string of tnsnames.ora.

2. For server-based connection Load Balancer, the listener will forward to idle instances according to the connection load on the current node and instance.

Forwarding is based only on the number of connections the current node is listening to, not the excessive load of the current instance.

4. From the above test, it can be concluded that the connections of each node are not balanced, but relatively balanced, so they should work together with the client connection load.

5. In case of excessive load of the current instance, Load Balancer should be realized in combination with the configuration service method.

Note: Regardless of whether you configure Client-Side LB or Server-Side LB, you need to delete the SID_LIST_LISTENER_NodeName entry generated by default from the listener.ora file of each node instance to ensure that the information obtained by the Listener is dynamically registered, not static information read from the file.

1.3 Two LB configuration methods

For Client-SideLB, add LOAD_BALANCE=YES to the client's tnsnames entry;

For Server-sideLB, the REMOTE_LISTENER parameter needs to be configured.

Note: When configuring LB, you need to delete the SID_LIST_LISTENER_NodeName entry generated by default from the listener.ora file of each node instance, so as to ensure that the information obtained by the Listener is dynamically registered, not static information read from the file.

We want to delete:

SID_LIST_LISTENER_RAC1=

(SID_LIST=

(SID_DESC=

(SID_NAME=PLSExtProc)

(ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1)

(PROGRAM=extproc)

)

)

Keep only:

LISTENER_RAC1=

(DESCRIPTION_LIST=

(DESCRIPTION=

(ADDRESS=(PROTOCOL=TCP)(HOST=rac1-vip)(PORT=1521)(IP=FIRST))

(ADDRESS=(PROTOCOL=TCP)(HOST=10.85.10.119)(PORT=1521)(IP=FIRST))

)

)

II. Spread the load with Service

Let's first analyze the shortcomings of the Connection Balancing method. Oracle clusters are a "share everything" architecture, where all nodes share a single disk of data. Data synchronization between instances is performed through the Cache Fusion mechanism, so RAC performance is largely limited by Cache Fusion performance. Therefore, to improve RAC performance, you can start from two aspects:

1. Improve Cache Fusion capabilities, which can use better interconnected devices, such as G-class private networks, or DRA technologies such as Infiniband.

2. You can minimize CacheFusion traffic and reduce interdependencies between instances. Service is the basis of the latter idea deleted out of development.

Take a look at Partition technology, which is very similar to Service. If the number in a table is large, Oracle recommends PartitionTable, which spreads the data over multiple physical segments according to certain rules (such as time), so that access to the data is limited to certain local segments.

The idea of "decentralized data" is further promoted. In RAC environment, if data can be separated according to application. For example, an ERP application includes multiple modules for production, sales, and supply chain management. Assuming that the database uses a 2-node RAC, before "scattering data," both users use the sales module, so these two users may be assigned to two nodes. During the operation, the sales data will be continuously transferred between two bytes under the action of CacheFusion. If two more users of the production module arrive, the two users are assigned to two nodes, and the production part synchronizes between the two instances with the help of CacheFusion during operation.

It can be seen that if there is only one mechanism for Connection Balancing, it seems that users are scattered to different instances, and it seems that the load is distributed. However, this decentralization is not combined with the business needs of each user and is a purely technical means. Such fragmentation may in turn increase the burden between systems.

If you think about it another way, suppose you assign all users of the sales module to node 1 and all users of the production module to node 2, and assume that the data between these two modules does not intersect. At this time, the data of the sales module is concentrated on node 1, and the data of the production module is concentrated on node 2. The workload of Cache Fusion will be greatly reduced, and the performance problem can be fundamentally solved.

This idea is the basic idea of load distribution by means of Service. By dividing the application into Services according to functional modules, each Service is fixed on a RAC node, so as to fundamentally measure the performance of the system. This method of load dispersion cannot be configured by DBAs alone. It requires cooperation between DBAs and developers. It is possible to see the effect after understanding the characteristics of business data.

In RAC environment, Service is not necessary, but if you can use the corresponding division of Service, I believe that the improvement of the performance of the whole system is very beneficial. Another benefit of using Service is that you can create the Service TAF parameter inside the database, and if the client connects to the database through Service, you no longer need many of the FAIL-OVER settings in tnsnames.ora on the client side. Just add the following entry:

RAC=

(DESCRIPTION=

(ADDRESS=(PROTOCOL=TCP)(HOST=rac1-vip)(PORT=1521))

(ADDRESS=(PROTOCOL=TCP)(HOST=rac2-vip)(PORT=1521))

(LOAD_BALANCE=YES)

(CONNECT_DATA=

(SERVER=DEDICATED)

(SERVICE_NAME=RAC)

)

)

At this point, I believe that everyone has a deeper understanding of "Oracle RAC LoadBalance", may wish to actually operate it! Here is the website, more related content can enter the relevant channels for inquiry, pay attention to us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.