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

You cannot watch scan snooping through lsnrctl. View scan snooping through the following command

[grid@node1 admin] $srvctl config scan_listener

SCAN Listener LISTENER_SCAN1 exists. Port: TCP:1521

[grid@node1 admin] $srvctl config scan

SCAN name: node-scan, Network: 1/192.168.92.0/255.255.255.0/eth0

SCAN VIP name: scan1, IP: / node-scan/192.168.92.99

RAC's tnsname.ora connection is recommended to use the following RACSCAN mode, of course, RACVIP can also

RACSCAN =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP) (HOST = SCAN-NAME) (PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = orcl)

)

)

RACVIP =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP) (HOST = NODE1 VIP) (PORT = 1521))

(ADDRESS = (PROTOCOL = TCP) (HOST = NODE2 VIP) (PORT = 1521))

(LOAD_BALANCE = ON)

(FAILOVER = ON)

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = orcl)

)

)

The problem 1:SCAN IP is only on one node. If you connect through SCAN IP, isn't it always connected to the node where the SCAN IP is located?

Answer: SCAN IP can automatically assign sessions to the corresponding nodes according to the RAC load, because the PMON process can regularly register the load on each node with the scan listener listener.

Question 2: when the service with prefer and available is configured, if the prefer primary server goes down, will the tns connection be wrong every time and then go to the available backup server?

Answer: not required if SCAN IP or VIP is configured

If Public IP is configured and LOAD_BALANCE is no, and the first IP is the prefer primary server, you have to make a mistake every time and then go to the available backup server.

FAILOVER and LOAD_BALANCE are configured in the phenomenon 1:TNS, but HOST is a PUBLIC IP of two nodes. The client connects many times through this TNS, and exits and then reconnects each time. It is found that about half of the connections take a long time to connect, and the other half connect very quickly.

FAILOVER and LOAD_BALANCE are configured in the phenomenon 2:TNS, but HOST is a VIP of two nodes. The client connects many times through this TNS, and then exits and reconnects each time, and finds that each connection is very fast.

Differences between TNSNAME configuration SCAN IP, VIP, and PUBLIC IP

SCAN IP floats and falls on a node, similar to VIP, but SCAN IP is associated with the entire cluster, not only a single node, but all services of all nodes, including VIP and PUBLIC IP, are registered on the scan_listener of the entire cluster. Scan listener knows the load of each node. SCAN IP is the virtual IP,srvctl config scan_listener of scan_listener that only displays port information. IP information, that is, SCAN IP is mapped to VIP and PUBLIC IP of all nodes.

The VIP floats and falls on a node, but the VIP will only register on the listener of the corresponding node. When the node goes down, the VIP will automatically drift to the normal node, but will no longer register to the listener of the normal node (that is, the VIP cannot be seen by the lsnrctl status, the VIP will not appear in the listening information of the normal node, and the VIP can be connected but cannot be served externally.) When the client connects through this VIP, the cluster immediately notifies the client that the listening node corresponding to the VIP is down, and the client will immediately use the VIP of another node to connect.

The PUBLIC IP is fixed and will only be registered on the listener of the corresponding node. When the node goes down, if you use this PUBLIC IP connection, you will not be able to reach the cluster. At this time, the client will rely on "TCP/IP protocol stack timeout" to determine the server failure until the time out is reported, which is a very time-consuming process.

So: do not configure PUBLIC IP in TNSNAME, but configure VIP. After a node goes down, the node PUBLIC IP cannot connect, but VIP can connect and return the node downtime information, so that the client can quickly know that the node is dead and consumes less resources.

FAILOVER

Purpose:To enable or disable connect-time failover for multiple protocol addresses.

When you set the parameter to on, yes, or true, Oracle Net, at connect time, fails over to a different address if the first protocol address fails. When you set the parameter to off, no, or false, Oracle Net tries one protocol address.

Fail-over

Purpose: enable or disable failover when connecting multiple protocol addresses.

When you set the parameter to on,yes or true, if the first protocol address fails, Oracle Net will fail to another address when connecting. When you set the parameter to off,no or false, Oracle Net tries a protocol address.

This parameter should be on by default. After the tns is configured as follows, the node 1 is turned off and the public ip NODE1 PUBLIC_IP of node 1 no longer exists. When you use sqlplus to connect the name of the tns, you can still connect to node 2.

PUBLIC_NO_LOADBALANCE_FAILOVER =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP) (HOST = NODE1 PUBLIC_IP) (PORT = 1521))

(ADDRESS = (PROTOCOL = TCP) (HOST = NODE2 PUBLIC_IP) (PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = orcl)

)

)

LOAD_BALANCE

Purpose:To enable or disable client load balancing for multiple protocol addresses.

When you set the parameter to on, yes, or true, Oracle Net progresses the list of addresses in a random sequence, balancing the load on the various listener or Oracle Connection Manager protocol addresses. When you set the parameter to off, no, or false, Oracle Net tries the first address in the address list. If the connection fails and the failover parameter is enabled, then Oracle Net tries the addresses sequentially until one succeeds.

Load balancing

Purpose: to enable or disable client load balancing for multiple protocol addresses.

When you set the parameter to on,yes or true, Oracle Net lists addresses in random order, balancing the load on various listeners or Oracle Connection Manager protocol addresses. When the parameter is set to off,no or false, Oracle Net attempts the first address in the address list. If the connection fails and the failover parameter is enabled, Oracle Net attempts the address in turn until it succeeds.

Load balancing: on which node of the database session is generated when connecting.

A. Tnsnames.ora using LOAD_BALANCE is actually the load balancer of the client.

Which node generates session is essentially a server-side load balancing, because the client does not know which node on the server side is the most idle.

As follows, randomly select a node from the tnsnames.ora to connect.

ERP= (DESCRIPTION=

(LOAD_BALANCE=on)

(ADDRESS= (PROTOCOL=TCP) (HOST=node-1vip) (PORT=1521))

(ADDRESS= (PROTOCOL=TCP) (HOST=node-2vip) (PORT=1521))

(ADDRESS= (PROTOCOL=TCP) (HOST=node-3vip) (PORT=1521))

(CONNECT_DATA= (SERVICE_NAME=ERP)

B. If tnsnames.ora uses scan name to connect, there is no load balancer when connecting to the client. Because there is only one connection address in the connection string.

If you are using SCAN name, then scan listener knows the load of each node, which is the real load balancing

So the client connection can be redirected to the most idle node.

ERP= (DESCRIPTION= # # Using the SCAN # #

(LOAD_BALANCE=on)

(ADDRESS= (PROTOCOL=TCP) (HOST=cluster-scan) (PORT=1521))

(CONNECT_DATA= (SERVICE_NAME=ERP)

C. If you use vip addresses but want to achieve server-side load balancing, you first need to modify the remote_listener to point to all listeners.

Modify the tnsnames.ora of the two nodes and add information similar to the following:

All_listener =

(DESCRIPTION =

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

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

)

Alter system set remote_listener='all_listener'

In this way, the pmon process can regularly register the workload on each node with the listeners of all nodes.

About the SCAN

Oracle Database 11g release 2 clients connect to the database using SCANs. The SCAN and its associated IP addresses provide a stable name for clients to use for connections, independent of the nodes that make up the cluster. SCAN addresses, virtual IP addresses, and public IP addresses must all be on the same subnet.

The SCAN is a virtual IP name, similar to the names used for virtual IP addresses, such as node1-vip. However, unlike a virtual IP, the SCAN is associated with the entire cluster, rather than an individual node, and associated with multiple IP addresses, not just one address.

The SCAN works by being able to resolve to multiple IP addresses in the cluster handling public client connections. When a client submits a request, the SCAN listener listening on a SCAN IP address and the SCAN port is made available to a client. Because all services on the cluster are registered with the SCAN listener, the SCAN listener replies with the address of the local listener on the least-loaded node where the service is currently being offered. Finally, the client establishes connection to the service through the listener on the node where service is offered. All of these actions take place transparently to the client without any explicit configuration required in the client.

During installation listeners are created. They listen on the SCAN IP addresses provided on nodes for the SCAN IP addresses. Oracle Net Services routes application requests to the least loaded instance providing the service. Because the SCAN addresses resolve to the cluster, rather than to a node address in the cluster, nodes can be added to or removed from the cluster without affecting the SCAN address configuration.

The SCAN should be configured so that it is resolvable either by using Grid Naming Service (GNS) within the cluster, or by using Domain Name Service (DNS) resolution. For high availability and scalability, Oracle recommends that you configure the SCAN name so that it resolves to three IP addresses. At a minimum, the SCAN must resolve to at least one address.

If you specify a GNS domain, then the SCAN name defaults to clustername-scan.GNS_domain. Otherwise, it defaults to clustername-scan.current_domain. For example, if you start Oracle Grid Infrastructure installation from the server node1, the cluster name is mycluster, and the GNS domain is grid.example.com, then the SCAN Name is mycluster-scan.grid.example.com.

Clients configured to use IP addresses for Oracle Database releases prior to Oracle Database 11g release 2 can continue to use their existing connection addresses; using SCANs is not required. When you upgrade to Oracle Clusterware 11g Release 2, the SCAN becomes available, and you should use the SCAN for connections to Oracle Database 11g release 2 or later databases. When an earlier version of Oracle Database is upgraded, it registers with the SCAN listeners, and clients can start using the SCAN to connect to that database. The database registers with the SCAN listener through the remote listener parameter in the init.ora file. The REMOTE_LISTENER parameter must be set to SCAN:PORT. Do not set it to a TNSNAMES alias with a single address with the SCAN as HOST=SCAN.

The SCAN is optional for most deployments. However, clients using Oracle Database 11g release 2 and later policy-managed databases using server pools should access the database using the SCAN. This is because policy-managed databases can run on different servers at different times, so connecting to a particular node virtual IP address for a policy-managed database is not possible.

About SCAN

The Oracle database 11g version 2 client uses SCAN to connect to the database. SCAN and its associated IP address provide a stable name for clients to connect to, independent of the nodes that make up the cluster. SCAN addresses, virtual IP addresses, and public IP addresses must all be on the same subnet.

SCAN is a virtual IP name, similar to the name of a virtual IP address, such as node1-vip. However, unlike virtual IP, SCAN is associated with the entire cluster, not a single node, and with multiple IP addresses, not just one address.

SCAN works by addressing multiple IP addresses in the cluster that handle public client connections. SCAN listeners that listen for SCAN IP addresses and SCAN ports are available to the client when the client submits a request. Because all services on the cluster are registered with the SCAN listener, the SCAN listener will reply to the address of the local listener on the minimum load node that currently provides the service. Finally, the client establishes a connection to the service through a listener on the node providing the service. All of these operations are done transparently to the client, and no explicit configuration is required in the client.

Create a listener during installation. They listen on the SCAN IP provided on the node. Oracle Net Services routes application requests to the minimum load instance that provides the service. Because the SCAN address resolves to the cluster rather than the node address in the cluster, nodes can be added to or removed from the cluster without affecting the SCAN address configuration.

SCAN should be configured so that it can be resolved by using the Grid naming Service (GNS) in the cluster or by using Domain name Service (DNS) resolution. For high availability and scalability, Oracle recommends that you configure the SCAN name so that it resolves to three IP addresses. At a minimum, SCAN must resolve at least one address.

If a GNS domain is specified, the SCAN name defaults to clustername-scan.GNS_domain. Otherwise, it defaults to clustername-scan.current_domain. For example, if you start the Oracle Grid Infrastructure installation from the server node1, the cluster name is mycluster and the GNS domain is grid.example.com, then the SCAN name is mycluster-scan.grid.example.com.

Clients configured to use the IP address of the Oracle database version prior to Oracle Database 11g version 2 can continue to use their existing connection address; SCAN is not required. When you upgrade to Oracle Clusterware 11g version 2 (11.2), SCAN becomes available, and you should use SCAN to connect to the Oracle Database 11g version 2 or later database. When an earlier version of the Oracle database is upgraded, it registers with the SCAN listener and the client can start connecting to the database using SCAN. The database is registered with the SCAN listener through the remote listener parameters in the init.ora file.

The REMOTE_LISTENER parameter must be set to SCAN:PORT. Do not set it as a TNSNAMES alias with a single address of SCAN as HOST = SCAN.

For most deployments, SCAN is optional. However, clients that use server pools for databases that use Oracle Database 11g version 2 and later policy management should use SCAN to access the database. This is because the policy management database can run on different servers at different times, so it is not possible to connect to the specific node virtual IP address of the policy management database.

Understanding SCAN Addresses and Client Service Connections

Public network addresses are used to provide services to clients. If your clients are connecting to the Single Client Access Name (SCAN) addresses, then you may need to change public and virtual IP addresses as you add or remove nodes from the cluster, but you do not need to update clients with new cluster addresses.

SCANs function like a cluster alias. However, SCANs are resolved on any node in the cluster, so unlike a VIP address for a node, clients connecting to the SCAN no longer require updated VIP addresses as nodes are added to or removed from the cluster. Because the SCAN addresses resolve to the cluster, rather than to a node address in the cluster, nodes can be added to or removed from the cluster without affecting the SCAN address configuration.

The SCAN is a fully qualified name (host name+domain) that is configured to resolve to all the addresses allocated for the SCAN. The addresses resolve using Round Robin DNS either on the DNS server, or within the cluster in a GNS configuration. SCAN listeners can run on any node in the cluster. SCANs provide location independence for the databases, so that client configuration does not have to depend on which nodes run a particular database.

Oracle Database 11g release 2 (11.2) and later instances only register with SCAN listeners as remote listeners. Upgraded databases register with SCAN listeners as remote listeners, and also continue to register with all node listeners.

Because of the Oracle Clusterware installation requirement that you provide a SCAN name during installation, if you resolved at least one IP address using the server / etc/hosts file to bypass the installation requirement but you do not have the infrastructure required for SCAN, then, after the installation, you can ignore the SCAN and connect to the databases in the cluster using VIPs.

Oracle does not support removing the SCAN address.

Understand SCAN addresses and client service connections

Public network addresses are used to provide services to clients. If your client connects to a single client access name (SCAN) address, you may need to change the public and virtual IP addresses when adding or removing nodes from the cluster, but you do not need to update the client with the new cluster address.

SCANs functions like a cluster alias. However, the SCAN is resolved on any node in the cluster, so unlike the VIP address of the node, the client connecting to the SCAN no longer needs an updated VIP address because the node is added to or removed from the cluster. Because the SCAN address resolves to the cluster rather than the node address in the cluster, nodes can be added to or removed from the cluster without affecting the SCAN address configuration.

SCAN is a fully qualified name (hostname + domain) that is configured to resolve all addresses assigned to SCAN. These addresses are resolved using DNS or GNS. The SCAN listener can run on any node in the cluster. SCAN provides location independence for databases, so client configuration does not have to depend on the node running a particular database.

Instances of Oracle Database 11g version 2 and later register only SCAN listeners as remote listeners. The upgrade database registers SCAN listeners as remote listeners and continues to register with all node listeners.

Because of the Oracle Clusterware installation requirements, you provide the SCAN name during installation, and if you use the server / etc/hosts file to resolve at least one IP address to bypass the installation requirements, but do not have the infrastructure required by SCAN, after installation, you can ignore SCAN and use VIP to connect to the database in the cluster. Oracle does not support deleting SCAN addresses.

About the Virtual IP Address

The virtual IP (VIP) address is registered in the GNS, or the DNS. Select an address for your VIP that meets the following requirements:

The IP address and host name are currently unused (it can be registered in a DNS, but should not be accessible by a ping command)

The VIP is on the same subnet as your public interface

D.1.3.4 About the Grid Naming Service (GNS) Virtual IP Address

The GNS virtual IP address is a static IP address configured in the DNS. The DNS delegates queries to the GNS virtual IP address, and the GNS daemon responds to incoming name resolution requests at that address.

Within the subdomain, the GNS uses multicast Domain Name Service (mDNS), included with Oracle Clusterware, to enable the cluster to map host names and IP addresses dynamically as nodes are added and removed from the cluster, without requiring additional host configuration in the DNS.

About Virtual IP addr

The virtual IP (VIP) address is registered in GNS or DNS. Select an VIP address that meets the following requirements:

The IP address and hostname are not currently in use (can be registered in DNS, but cannot be accessed through the ping command)

VIP and your PUBLIC IP interface are on the same subnet

D.1.3.4 about Grid naming Service (GNS) virtual IP address

The GNS virtual IP address is a static IP address configured in DNS. DNS delegates the query for the GNS virtual IP address to GNS, and the GNS daemon responds to the incoming name resolution request at that address.

Within the subdomain, GNS uses the Multicast Domain name Service (mDNS) that ships with Oracle Clusterware, which enables the cluster to map hostnames and IP addresses dynamically without the need to add and remove nodes in the cluster or other host configurations in the DNS.

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.