High Availability of oracleHA

I. HA

FAILOVER: the technical basis for High Availability of Oracle RAC is Failover, which means that faults of a node in the hot river in the cluster will not affect user usage, the user who connects to the faulty node will be automatically transferred to the healthy node. From the perspective of the user Master, this switching feature is called Failover (Failover) in Oracle ).

The Oracle RAC Failover can be subdivided into three parts:

(1) Client-Side Connect time Failover;

(2) TAF;

(3) Server-side TAF;

Note:

Do not set GLOBAL_DB_NAME in listener. ora, because this parameter will disable Connect-time Failover and TransparentApplication Failover.

Client-Side Connect time Failover

Client-Side Connect timeFailover indicates that if multiple addresses are configured in the Client tnsname, the user tries to Connect to the first address in the address table when initiating a request, if the connection fails, the second address will be used until the connection is successful or all the addresses are traversed.

ThisFeatures of FailoverFrom his name, "connect time" is clearly expressed,It only works at the moment when the connection is established. That is to say, this Failover method only detects node faults when initiating a connection. If no response is received from the node, it will automatically try the next address in the address list. Once the connection is established, the node will not be processed if it fails. The client is disconnected, and the user program must establish a new connection.

To enable this type of Failover, add the FAILOVER = ON entry to tnsnames. ora of the client. This parameter is ON by default. Therefore, the client can obtain the Failover capability even if this entry is not added.

TAF (Transparent Apllication Failover)

From the above analysis of the features of Client-Side Connecttime Failover, we can see that this failover has limited significance. Downloading most popular application systems (such as WebLogic and JBOSS) is to establish several persistent connections to the database at startup and reuse these connections throughout the application lifecycle. Client-Side Connect Time Failover works in a way that it does not greatly help application availability.

A new Failover mechanism TAF was introduced from Oracle 8.1.5. the so-called TAF means that after the connection is established, if an instance fails while the application is running, the user connected to the instance will be automatically migrated to other healthy instances. For applications, this billion process is transparent and does not require user intervention. Of course, this transparency is also enclosed in quotation marks because uncommitted transactions will be rolled back. Compared with Client-Side Connect Time Failover, the user program is interrupted, a connection error is thrown, and the user must use medium-term applications, TAF is a major step forward in improving the application HA capability.

TAF configuration is also very simple. You only need to add the FAILOVER_MODE configuration item to tnsnames. ora of the client. This entry has four sub-projects to be defined.

FRAC =

(DESCRIPTION =

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

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

(LOAD_BALANCE = YES)

(

CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = FRAC)

(

FAILOVER_MODE =

(TYPE = session)

(METHOD = basic)

(RETRIES = 180)

(DELAY = 5)

)

)

)

(1) The METHOD option defines when to create a connection to another instance. There are two options: BASIC and PERCONNECT.

A. BASIC refers to the connection that is created to other instances only when a node fault is detected.

B. PERCONNECT is a connection established to all instances at the same time when a connection is initially established. When a fault occurs, you can immediately switch to another link.

It is easy to compare the two methods. The BASIC method has time to speak in Faiover. Although the PERCONNECT method does not have time to speak, setting up multiple redundant nodes will consume more resources, the two are the differences between changing resources by time and changing resources by time.

(2) The Type option is used to determine how to handle the completed SQL statement in the event of a fault. There are two types: session and select.

Both methods automatically roll back uncommitted transactions. The difference lies in the processing of select statements. For the select type, the select statements that the user is executing will also be transferred to the new strength, and the subsequent result set will be returned on the new node, the returned record result set is discarded.

Assume that the user is performing a query on node 1, and there are a total of 100 records in the result set. Now, 10 records are returned from node 1, and node 1 is down, the user connection is transferred to node 2. If the session method is used, the query statement needs to be re-executed. If the select method is used, the remaining 90 records will be returned from node 2, the 10 records that have been returned from node 1 will not be returned to the user again, and the user cannot feel this switching.

Obviously, in order to implement the select method, oracle must save more content for each session, including the cursor, user, context, and so on. More resources are also required to change the time of resources.

(3) the DELAY and RETRIES parameters are simple and indicate the Retry Interval and the number of RETRIES.

Failover (TAF) testing relies on the previous monitoring and tnsnames configuration, but before 11G R2 was introduced, a fault occurred, using the cluster vip "drifting" for Failover, after 11G R2, a new ip address is introduced, that is, the SCAN (SingleClient Access Name) IP address. Scan is a domain Name and can resolve 1 to 3 scan ip addresses, the client can access the database through SCAN name resolution. The advantage is that no additional client maintenance is required when adding or deleting nodes, greatly reducing the tedious maintenance work.

In the cluster environment, the client we configure is configured in the scan ip Mode. When a user is connected outside, the cluster automatically connects the session to a specific instance based on the load. If the session is being selected for a table, when the instance goes down, oracle will automatically switch the faulty node to another instance for execution. This switchover is transparent to users. The user will not feel the exception, and the operation will return normal results, which is also the high availability of the RAC cluster.

The following is a network failover test in session mode;

First, the user uses the Client Service for connection:

[Oracle @ frac1admin] $ sqlplus scott/oracle @ frac

SQL * Plus: Release11.2.0.3.0 Production on Wed Apr 16 01:55:37 2014

Copyright (c) 1982,2011, Oracle. All rights reserved.

Connected:

Oracle Database 11 gEnterprise Edition Release 11.2.0.3.0-64bit Production

With thePartitioning, Real Application Clusters, Automatic Storage Management, OLAP,

Data Mining and RealApplication Testing options

SQL> showparameter instance_name

NAME TYPE VALUE

----------------------------------------------------------------------------------------

Instance_name string FRAC2

SQL> create tablebig_a as select * from dba_objects;

SQL> insert into big_a select * from big_a;

To ensure data adequacy, I have executed the insert statement several times. Due to disk space limitations, I have executed four times here, with a total of 1203888 records.

According to the above information, you can connect to the frac2 instance and perform some DML operations:

SQL> selectOBJECT_TYPE, count (*) from big_a group by object_type;

If the frac2 instance is down before the query is completed, the following error is returned:

SQL> shutdownabort;

ORACLE instance shutdown.

SQL> selectOBJECT_TYPE, count (*) from dba_objects group by object_type;

SelectOBJECT_TYPE, count (*) from dba_objects group by object_type

*

ERROR at line 1:

ORA-25408: can notsafely replay call

Again, we found that the session has been automatically switched to the frac1 instance:

SQL>/

OBJECT_TYPE COUNT (*)

------------------------------------------------

EDITION 1

Index partition 302

TABLESUBPARTITION 32

Consumer group 25

SEQUENCE 229

TABLE 2936

INDEX 5266

SYNONYM 28152

VIEW 5186

FUNCTION 305

Java class 23165

Java source 2

INDEXTYPE 9

CLUSTER 10

TYPE 2913

Resource plan 10

JOB 14

EVALUATIONCONTEXT 15

45 rows selected.

SQL> showparameter instance_name;

NAME TYPE VALUE

----------------------------------------------------------------------------------

Instance_name string FRAC1

SQL>! Hostname

Frac1

Server-Side TAF

The third method is Server-Side TAF, but you can guess from the name that this method has a certain relationship with the previous TAF. As a matter of fact, we can regard Server-Side TAF as a variant of TAF. First, Server-Side TAF is also TAF, which has all the characteristics of TAF. Second, such TAF is configured on the Server, unlike TAF configured on the client.

The Client-Side TAF described earlier requires you to modify the Client tnsnames during the configuration process. ora file. If many clients use this database, they need to change the library user's computer every tiny parameter adjustment, which is inefficient and error-prone. Server-Side TAF saves the FAIL_MODE configuration in the database by combining the Service, saving all TAF configurations in the data dictionary, thus saving the client configuration work, currently, the TNS file on the client does not require any TAF configuration options.

In terms of configuration parameters, Service-Side TAF has a larger concept than Instance Role. When multiple instances participate in a Service, you can configure which Instance is used for Service. A user has two optional roles.

A. PREFERRED: PREFERRED instance. instances with this role will be given priority to provide services.

B. AVILABLE: Backup Instance. The user will first connect to the PREFERRD Instance. When the PREFERRED Instance is unavailable, it will be transferred to the AVILABLE Instance.

To use Server-Side TAF, you must configure the Server. Server can be created when a database is created or modified after the database is created. You can configure the database either through the Configuration Wizard or through the command line. The following describes how to configure the Service by using DBCA or manually.