Shulou(Shulou.com)06/01 Report--

Http://blog.csdn.net/tianlesoftware/article/details/6087045

one。 LOCAL_LISTENER and REMOTE_LISTENER description

1.1 LOCAL_LISTENER

The information on the official website is as follows:

Property

Description

Parameter type

String

Syntax

LOCAL_LISTENER = network_name

Default value

(ADDRESS = (PROTOCOL=TCP) (HOST=hostname) (PORT=1521)) where hostname is the network name of the local host

Modifiable

ALTER SYSTEM

Basic

No

LOCAL_LISTENER specifies a network name that resolves to an address or address list of Oracle Net local listeners (that is, listeners that are running on the same machine as this instance). The address or address list is specified in the TNSNAMES.ORA file or other address repository as configured for your system.

1.2 REMOTE_LISTENER

The official website says:

Property

Description

Parameter type

String

Syntax

REMOTE_LISTENER = network_name

Default value

There is no default value.

Modifiable

ALTER SYSTEM

Basic

Yes

REMOTE_LISTENER specifies a network name that resolves to an address or address list of Oracle Net remote listeners (that is, listeners that are not running on the same machine as this instance). The address or address list is specified in the TNSNAMES.ORA file or other address repository as configured for your system.

two。 LOCAL_LISTENER and dynamic Registration

For dynamic registration, refer to my Blog:

Oracle Listener dynamic Registration and static Registration

Http://www.cndba.cn/Dave/article/1177

Dynamic registration is when the instance starts, the PMON process dynamically registers the instance and service with the listener according to the two parameters instance_name,service_names in the init.ora.

The instance value registered with the listener is obtained from the instance_name parameter in the init.ora file. If the parameter does not have a set value, it takes the value of db_name in the init.ora file. If configured in RAC, you must set the instance_name parameter for each instance in the cluster to a unique value.

The service value registered with the listener is obtained from the parameter service_names in the init.ora file. If the parameter does not have a set value, the database registers itself by splicing the values of db_name and db_domain in the init.ora file. If you choose to provide a service_ name value, you can use a fully qualified name (such as orcl.oracle.com) or an abbreviated name (such as orcl). If you choose an abbreviated name and set the db_domain parameter, the service registered with the listener will be a concatenation of the service_ name value and the db_ domain value.

It should be noted here that dynamic registration is only registered on the default listener by default (name is LISTENER, port is 1521, protocol is TCP), because pmon only dynamically registers listeners with port equal to 1521, otherwise pmon cannot dynamically register listener. If you need to register with non-default listeners, you need to configure the local_listener parameter.

So we see the role of LOCAL_LISTENER. The listening port is 1521 by default, but in many cases, port 1521 will not be used for installation reasons, because dynamic registration in this case requires the configuration of the LOCAL_LISTENER parameter.

Add the listening information to the tnsnames.ora file. Because pmon reads relevant information from tnsnames.ora when dynamically registering snooping.

LISTENER _ RACDB1 =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP) (HOST = rac1) (PORT = 1522))

)

Then modify the local_listener parameter with sys and modify:

SQL > alter system set local_listener= LISTENER _ RACDB1

You can also specify directly:

SQL > alter system set LOCAL_LISTENER=' (ADDRESS = (PROTOCOL = TCP) (HOST = rac1) (PORT = 1522)'

In this way, when DB starts, instence_name and service_name are automatically registered as listeners. If the monitor is restarted during this period, and the information in the monitor will be lost, you need to register the information with the monitor manually:

SQL > alter system register

three。 LOCAL_LISTENER, REMOTE_LISTENER and RAC CLIENT-SIDE TAF and LOAD BALCANING

3.1 Parameter description

In Blog:

Oracle RAC Failover detailed explanation

Http://www.cndba.cn/Dave/article/1192

The Failover of RAC is classified in: Client-Side TAF and Server-side TAF.

Service-SideTAF is configured on the server and Client-Side TAF is configured on the client.

Client-Side TAF is configured by modifying the tnsnames.ora file on the client side. If many clients use this database, then every smile adjustment needs to change all the computers, which is both inefficient and error-prone. On the other hand, Service-Side TAF saves the configuration of FAIL_MODE in the database and all the TAF configuration in the data dictionary by combining Service, thus saving the configuration work of the client, and the TNS file of the client does not need any configuration options of TAF.

For more information about Server-side TAF configuration, refer to Blog:

How To Configure Server Side Transparent Application Failover [ID 460982.1]

Http://blog.csdn.net/tianlesoftware/archive/2010/12/20/6086728.aspx

The two parameters LOCAL_LISTENER and REMOTE_LISTENER are used to configure Client-Side TAF.

Reference for the configuration of the official website:

10g & 11g Configuration of TAF (Transparent Application Failover) and Load Balancing [ID 453293.1]

Http://blog.csdn.net/tianlesoftware/archive/2010/12/19/6085529.aspx

3.2 Client-Side TAF configuration

3.2.1 the host information is as follows

Node1:

Hostname: node1.idc.oracle.com

VIP Hostname: node1-vip.idc.oracle.com

Database Service_names: service.idc.oracle.com

SID: sid1

Node2:

Hostname: node2.idc.oracle.com

VIP Hostname: node2-vip.idc.oracle.com

Database Service_names: service.idc.oracle.com

SID: sid2

3.2.2 Node1 configuration

(1) modify Listener.ora file

LISTENER_NODE1=

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP) (HOST = node1-vip.idc.oracle.com) (PORT = 1521) (IP=FIRST))-- Private IP

(ADDRESS = (PROTOCOL = TCP) (HOST = node1.idc.oracle.com) (PORT = 1521) (IP=FIRST))-public IP

)

)

(2) start Listener

$lsnrctl start LISTENER_NODE1

(3) modify Tnsnames.ora file

NODE1_LOCAL=

(ADDRESS = (PROTOCOL = TCP) (HOST=node1-vip.idc.oracle.com) (PORT = 1521))

Test:

$tnsping node1_local

(4) set the local_listener parameter of node1

Sql > alter system set LOCAL_LISTENER='node1_local' scope=both sid='sid1'

3.2.3 NODE2 configuration

(1) modify Listener.ora file

LISTENER_NODE2=

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS= (PROTOCOL=TCP) (HOST=node2.idc.oracle.com) (PORT=1521) (IP=FIRST))

(ADDRESS= (PROTOCOL=TCP) (HOST=node2-vip.idc.oracle.com) (PORT=1521) (IP=FIRST))

)

)

(2) start Listener

$lsnrctl start LISTENER_NODE2

(3) modify Tnsnames.ora file

NODE2_LOCAL=

(ADDRESS = (PROTOCOL = TCP) (HOST = node2-vip.idc.oracle.com) (PORT = 1521))

Verify:

$tnsping node2_local

(4) set local_listener parameters

Sql > alter system set LOCAL_LISTENER='node2_local' scope=both sid='sid2'

3.2.4 add the following to the tnsnames.ora files of node1 and node2

NODE_REMOTE =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP) (HOST=node1-vip.idc.oracle.com) (PORT = 1521))

(ADDRESS = (PROTOCOL = TCP) (HOST=node2-vip.idc.oracle.com) (PORT = 1521))

)

)

Test:

$tnsping node_remote

3.2.5 set remote listener on all nodes

Sql > alter system set REMOTE_LISTENER='node_remote' scope=both

3.2.6 set TAF in the tnsnames.ora set by the client

RACTAF=

(DESCRIPTION =

(ADDRESS_LIST =

(LOAD_BALANCE = yes)

(FAILOVER=ON)-- this parameter is the default value and can be left unwritten

(ADDRESS = (PROTOCOL = TCP) (HOST = node1-vip.idc.oracle.com) (PORT = 1521))

(ADDRESS = (PROTOCOL = TCP) (HOST = node2-vip.idc.oracle.com) (PORT = 1521))

)

(CONNECT_DATA =

(SERVICE_NAME = service.idc.oracle.com)

(failover_mode= (type=select) (method=basic))

)

)

When the client sends a connection request to the server listener, the local_listener registered service receives the connection request, and it is up to the master instance to decide which target instance should issue the server process response to the connection request. If load balancing is enabled, the master node will choose the instance with the least cpu load, at this time:

If the target instance assigned by master is local listener machine, then directly through local server listener, open the background server process, process the client that sends out conn, establish a connection, and process the session

If the target instance assigned by master is not local listener machine, then the connection request will be transferred to listener on remote machine through the parameter remote_listener, and then a server process will be sent back to the client by remote service listener to establish the connection and process the session.

When the conn establishes a connection, the listener is useless and will no longer be used. If the connected instance down is gone, the newly assigned master instance will be switched from the newly assigned master instance to the available instance through remote_listener, and the customer will not find the connection interrupted. Conn and select operations are uninterrupted.

When instance 1 registers listening, even if the instance of node 2 is not started, it will register the corresponding listener1 on node 2 server through remote_listener. It is added to the corresponding listener service when the database is started.

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.