Ii. lb
Loadbalance distributes load balancing to all nodes in the cluster to improve the overall throughput. Oracle 10gRAC provides two methods to achieve load. One is to allocate users to different nodes by using connection balancing, and the other is to distribute data on the application layer through services.
Connection balancing
Connection balancingThis type of Server Load balancer is implemented at the user connection level, that is, when a user requests a connection, the instance to which the connection is allocated is determined based on each load. Once a connection is established, all operations of the session are completed on this strength without being distributed to other instances.
Client-side lb)
Client-side lb is used by Oracle 8i. The configuration method is to add load_balance = yes to the client's tnsnames. ora file. When a client initiates a connection, it randomly selects one from the address list, and then uses the random algorithm to distribute the connection requests to various instances.
A client-side lb tns configuration instance is as follows:
Taf_server =
(Description =
(Address = (Protocol = TCP) (host = felix1-vip) (Port = 1521 ))
(Address = (Protocol = TCP) (host = felix2-vip) (Port = 1521 ))
(Load_balance = yes)
(CONNECT_DATA =
(Server = dedicated)
(SERVICE_NAME = taf_server)
(Failover_mode =
(Type = select)
(Method = Basic)
(Retries = 180)
(Delay = 5)
)
)
)
The disadvantage of this method is obvious because the actual load of each node is not considered during connection allocation, and the allocation result is not necessarily balanced. In addition, the random algorithm requires a long time slice, if multiple connections are initiated at the same time within a short period of time, these connections may be allocated to one node. Even worse, the connections may be allocated to the faulty node. Therefore, Oracle introduces the server-side LB mode.
Conclusion: The biggest disadvantage of client-side balancing is that users cannot be dispersed based on the actual load of each instance.
Server-side balancing)
The implementation of Server Load balancer depends on the load information of the listener (listener) mobile phone. During database operation, the pmon background process registers the load information of the mobile phone system to the listener. A message update is required at least one minute and at most ten minutes for pmon. If the load on the node is higher, the update frequency is higher to ensure that the listener can grasp the load of each node accurately. If the listener is disabled, the pmon process checks whether the listener is restarted every other time. In addition to this automatic and Scheduled Update task, you can also use the altersystem register command to perform this process manually. This automatic update action can be seen in the listener log. Note: The first registration process of the pmon process at instance startup is server-rgister, and the subsequent update process is service-update;
Tnslsnr for Linux: Version 10.2.0.5.0-productionon 03-jun-2014 11:51:54
Copyright (c) 1991,201 0, Oracle. All rights reserved.
System parameter file is/u01/Oracle/10.2.0/db_1/Network/admin/listener. ora
Log messages written to/u01/Oracle/10.2.0/db_1/Network/log/listener. Log
Trace information written to/u01/Oracle/10.2.0/db_1/Network/Trace/listener. TRC
Trace Level is currently 0
Started with PID = 25371
Listening On: (description = (address = (Protocol = TCP) (host = felix1) (Port = 1521 )))
Listener completed notification to CRS on Start
Timestamp * connect data [* protocol info] * event [* Sid] * return code
03-jun-2014 11:51:54 * (CONNECT_DATA = (cid = (program =) (host = felix1) (user = Oracle) (command = status) (arguments = 64) (Service = listener) (Version = 169870592) * status * 0
03-jun-2014 11:52:15 * service_register * felix2 * 0
03-jun-2014 11:52:15 * service_register * felix1 * 0
03-jun-2014 11:52:15 * service_update * felix1 * 0
03-jun-2014 11:52:15 * service_register * + ASM1 * 0
Although the listener log records the registration and update actions of the pmon process, the registration content is not reflected. To obtain this content, you can obtain it through various 1025 events, this time is related to the pmon activity.
SQL> alter session set events '10257 trace namecontext forever, level 16 ';
Session altered.
SQL>
Obtain the trace file:
Create or replace function get_trace return varchar is
Resultvarchar2 (4000 );
Begin
Dbms_output.enable (1000000 );
Begin
For X in (select D. Value
| '/'
| Lower (rtrim (I. instance, CHR (0 )))
| '_ Ora _'
| P. spid
| '. Trc'
Trace_file_name
From (select P. spid
From v $ mystat M, V $ session S, V $ PROCESS p
Where M. Statistic # = 1 and S. Sid = M. Sid and P. ADDR = S. paddr) P,
(Select T. Instance
From v $ thread t, V $ parameter V
Where v. Name = 'thread'
And (V. value = 0 or T. Thread # = to_number (V. Value) I,
(Select Value
From v $ Parameter
Where name = 'user _ dump_dest ') d) loop
Result: = Result | X. trace_file_name;
End loop;
End;
Return (substr (result, 1, 4000 ));
End get_trace;
Select get_trace from dual;
Get_trace
--------------------------------------------------------------------------------
/U01/Oracle/admin/Felix/udump/felix1_ora_27465.trc
The pmon process not only registers the local listener, but also registers it with the listener of other nodes. However, it is determined by the remote_listener and local_listener parameters. Local_listener does not need to be set, but remote needs to be set. The parameter value is a tnsnames item.
SQL> show parameter listener
Name type value
-----------------------------------------------------------------------------
Local_listener string listener_felix1
Remote_listener string listeners_felix
SQL>
The content of listeners_felix in tnsnames. ora is as follows:
Listeners_felix =
(Address_list =
(Address = (Protocol = TCP) (host = felix1-vip) (Port = 1521 ))
(Address = (Protocol = TCP) (host = felix2-vip) (Port = 1521 ))
)
With the automatic registration mechanism of pmon, the listener of each node in the cluster can master the Load Status of all nodes. When a client connection request is received, the connection will be transferred to the node with the smallest load, this node may be itself or another node, that is, the listener will forward the node selection method of the user's connection request listener according to the connection method requested by the user:
A. If the user requests a dedicate private connection, listener first selects the node with the smallest load. If multiple nodes have the same load, select the instance with the smallest load;
B. If the user requests a shared connection from the Shared Server, in addition to comparing the node load and instance load, select the smallest dispatcher on the selected instance for forwarding.
Two LB configuration methods:
For client-side LB, you must add load_balance = yes to the customer's tnsnames entry. For server-side LB, You need to configure the remote_listener parameter.
When configuring LB, note that the default sid_list_listener_name entry must be removed from the listener file of each instance to ensure that all information obtained by listener is dynamically registered, instead of the static information read from the file.
Before modification:
[[Email protected] admin] $ cat listener. ora
# Listener. ora. felix2 network configuration file:/u01/Oracle/10.2.0/db_1/Network/admin/listener. ora. felix2
# Generated by Oracle configuration tools.
Listener_felix2 =
(Description_list =
(Description =
(Address = (Protocol = TCP) (host = felix2-vip) (Port = 1521) (IP = first ))
(Address = (Protocol = TCP) (host = 192.168.10.102) (Port = 1521) (IP = first ))
)
)
----------------------------------------
Sid_list_listener_felix2 =
(Sid_list =
(Sid_desc =
(Sid_name = plsextproc)
(ORACLE_HOME =/u01/Oracle/10.2.0/db_1)
(Program = EXTPROC)
)
)
[[Email protected] admin] $
The modified configuration is as follows:
[[Email protected] admin] $ catlistener. ora
# Listener. ora. felix2 network configuration file:/u01/Oracle/10.2.0/db_1/Network/admin/listener. ora. felix2
# Generated by Oracle configuration tools.
Listener_felix2 =
(Description_list =
(Description =
(Address = (Protocol = TCP) (host = felix2-vip) (Port = 1521) (IP = first ))
(Address = (Protocol = TCP) (host = 192.168.10.102) (Port = 1521) (IP = first ))
)
)
[[Email protected] admin] $
Distribute loads using services
The limitations of the connection balancing method are that the Oracle cluster "share everything" architecture, and all nodes share a disk data. Data is synchronized between instances through the cachefusion mechanism, so the performance of RAC is largely limited by the performance of cache fusion. Therefore, to improve RAC performance, we can start from two aspects: on the one hand, we can improve the cache fusion capability through better interconnected devices, such as G-level private network, you can also use DRA technology such as InfiniBand. On the other hand, you can minimize the cache fusion traffic and reduce the mutual dependencies between instances. Service is developed based on the latter idea.
Let's take a look at the partition technology that is very similar to the service. If a table contains a large amount of data, oralce recommends partition table to distribute data to multiple physical segments according to certain rules, in this way, access to data is restricted to certain segments.
Increase the concept of "Scattered Data". In the RAC environment, if data can be separated by application, consider the following scenario: an ERP application consists of multiple modules: production, sales, and supply chain management. Assume that the database uses a 2-node RAC and both users use the sales module before "Data dispersion". Then, these two users may be allocated to two nodes, during the operation, sales data must be continuously transmitted between two nodes under the action of cache fusion. If there are users of the other two production modules, the two users are assigned to the two nodes. During the operation, the data produced must be synchronized between the two nodes with the assistance of cache fusion.
It can be seen that if there is only connectionbalance mechanism, it seems that the user is allocated to different instances, and the load seems to be dispersed. However, this dispersion does not meet the business needs of each user. It is a pure technical means (so it can be called pure technical means ).
For another solution, if users of the sales module are allocated to node 1 and users of the production module are allocated to node 2, assume that there is not much data cross between the two modules, because the data of the sales module is concentrated on node 1, and the data of the production database module is concentrated on node 2, the workload of cachefusion will be greatly reduced, which fundamentally solves the performance problem.
This idea is based on the basic idea that the Service distributes loads. By dividing applications into services by functional modules, each service is fixed on certain RAC nodes to fundamentally provide system performance.This method of distributed load is not completed only by DBA configuration. It requires dBA and developers to work together to see the effect after understanding the characteristics of business data.
In the RAC environment, the service is not necessary, but if we use the service to divide the application, we believe that the performance of the entire system is greatly improved. Another advantage is that you can create a TAF parameter for the service in the database. If you connect to the database through the service on the client, the client tnsnames. ora does not need many fail-over settings.
If the service method is used, the SERVICE_NAME entry must be used for client configuration, for example, the following red part:
Taf_server =
(Description =
(Address = (Protocol = TCP) (host = felix1-vip) (Port = 1521 ))
(Address = (Protocol = TCP) (host = felix2-vip) (Port = 1521 ))
(CONNECT_DATA =
(Server = dedicated)
(SERVICE_NAME = taf_server)
)
)
For more information, see [RAC] Zhang Xiaoming p238 ~ 242. I spoke very well !!!!