现在的大部分流行的应用系统(如:weblogic, Jboss),都是启动时就建立若干到数据库的长连接,在应用程序整个生命周期内重用这些连接。 而Client-Side Connet Time Failover的工作方式是它对应用程序的可用性没有太大帮助。
所以从Oracle 8.1.5 版本只有引入了新的Failover 机制—TAF。 所谓TAF,就是连接建立以后,应用系统运行过程中,如果某个实例发生故障,连接到这个实例上的用户会被自动迁移到其他的健康实例上。对于应用程序而言,这个迁移过程是透明的,不需要用户的介入,当然,这种透明要是有引导的,因为用户的未提交事务会回滚。 相对与Client-Side Connect Time Failover的用户程序中断,抛出连接错误,用户必须重启应用程序,TAF 这种方式在提高HA上有了很大的进步。
TAF 的配置也很简单,只需要在客户端的tnsnames.ora中添加FAILOVER_MODE配置项。这个条目有5个子项目需要定义。
1)METHOD: 用户定义何时创建到其实例的连接,有BASIC 和 PRECONNECT 两种可选值。
BASIC: 是指在感知到节点故障时才创建到其他实例的连接。
PRECONNECT: 是在最初建立连接时就同时建立到所有实例的连接,当发生故障时,立刻就可以切换到其他链路上。
两种方法比较: BASIC方式在Failover时会有时间延迟,PRECONNECT方式虽然没有时间延迟,但是建立多个冗余连接会消耗更多资源,两者就是是用时间换资源和用资源换时间的区别。
2)TYPE: 用于定义发生故障时对完成的SQL 语句如何处理,其中有2种类型:session 和select.
这2种方式对于未提交的事务都会自动回滚,区别在于对select 语句的处理,对于select,用户正在执行的select语句会被转移到新的实例上,在新的节点上继续返回后续结果集,而已经返回的记录集则抛弃。
假设用户正在节点1上执行查询,整个结果集共有100条记录,现在已从节点1上返回10条记录,这时节点1宕机,用户连接被转移到节点2上,如果是session模式,则需要重新执行查询语句;如果是select方式,会从节点2上继续返回剩下的90天记录,而已经从节点1返回的10条记录不会重复返回给用户,对于用户而言,感受不到这种切换。
显然为了实现select方式,Oracle 必须为每个session保存更多的内容,包括游标,用户上下文等,需要更多的资源也是用资源换时间的方案。
示例:
sales.us.example.com=
(DESCRIPTION=
(LOAD_BALANCE=on)
(FAILOVER=on)
(ADDRESS=
(PROTOCOL=tcp)(HOST=sales1-server)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=sales2-server)(PORT=1521))
(CONNECT_DATA=
(SERVICE_NAME=sales.us.example.com)
(FAILOVER_MODE=
(TYPE=select)
(METHOD=basic))))
3)DELAY 和 RETRIES: 这2个参数分别代表重试间隔时间和重试次数。
示例:
sales.us.example.com=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=sales1-server)(PORT=1521))
(CONNECT_DATA=
(SERVICE_NAME=sales.us.example.com)
(FAILOVER_MODE=
(TYPE=select)
(METHOD=basic)
(RETRIES=20)
(DELAY=15))))
4)BACKUP: 当METHOD参数为PRECONNECT时,BACKUP参数必须指定备份的网络服务名。
示例:
sales2.us.example.com=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=sales2-server)(PORT=1521))
(CONNECT_DATA=
(SERVICE_NAME=sales.us.example.com)
(INSTANCE_NAME=sales2)
(FAILOVER_MODE=
(BACKUP=sales1.us.example.com)
(TYPE=select)
(METHOD=preconnect))))
sales1.us.example.com=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=sales1-server)(PORT=1521))
(CONNECT_DATA=
(SERVICE_NAME=sales.us.example.com)
(INSTANCE_NAME=sales1)
(FAILOVER_MODE=
(BACKUP=sales2.us.example.com)
(TYPE=select)
(METHOD=preconnect))))
Service-SideTAF可以看作是TAF的一种变种,首先Service-SideTAF也是TAF,所有TAF的特点它都有,其次这种TAF是在服务器上配置的,而不像TAF是在客户端配置的。
Client-Side TAF是在客户端修改tnsnames.ora文件来配置的,如果有很多客户端使用这个数据库,那么每次微小调整都需要把所有的计算机更改一遍,既低效又容易出错。而Service-Side TAF通过结合Service,在数据库里保存FAIL_MODE的配置,把所有的TAF配置保存在数据字典中,从而省去了客户端的配置工作,现在客户端的TNS文件就不需要任何TAF的配置选项了。
Server-side TAF配置信息覆盖客户端的TAF配置信息。
从配置参数而言,Service-Side TAF和TAF相比多了一个Instance Role(实例角色)的概念。所谓的实例角色,就是当有多个Instance 参与一个Service时,可以配置优先使用哪一个Instance为用户提供服务。用户共有两种可选角色。
PREFERRED:首选实例,会优先选择拥有这个角色的实例提供服务。
AVAILABLE:后备实例,用户连接会优先连接PREFFERRED的Instance,当PREFERRED的Instance不可用时,才会被转到AVAILBALE的Instance上。
要使用Server-Side TAF必须配置Service。Service 可以在创建数据库时创建,也可以在创建数据库之后修改,既可以使用dbca配置向导,也可以用命令行的方式配置。
3.1 用DBCA 配置Service
1). 运行DBCA,选择ORACLE RAC Application Clusters database
2). 在第二个界面选择:Services Management
3). 第三个界面会出现RAC 数据库列表,用户可以在这个列表中选择要配置Service 的数据库
4). 在Serice配置界面中,单击Add 创建新的Service,输入service名字。在Instance列表框定义实例角色,选择那个service1 作为 Preferred(首选实例),Service2 作为availiable(后备实例)。 TAF Policy有三个选项: None, Basic,Pre-connect。 我们选Basic。 最后点击Finish,完成Service 配置。
5)在结束Service配置后,服务会自动启动。
注意:在oracle11gr2中,dbca已去掉配置service功能,改用OEM(Oracle Enterprise Manager)进行配置。
3.2 用srvctl 命令配置Service
用命令行方式配置Service 对远程维护很有用。 先来看一下相关命令
1) 创建service
#Srvctl add service -d -s -r "preferred-instance-list" -a "available-instance-list" -P
其中TAF-Policy可选:basic 和 preconnect。 例如:
srvctl add service -d RAC -s Service2 -r "RAC1,RAC2" -a "RAC3,RAC4" -P basic
注意:srvctl add service中,只有perferred才会创建服务。 即在OCR中注册一个ora.raw.dmm.Raw1.Srv的服务。
2) 查看配置信息
#srvctl config service -d database-name [-s service-name] [-a]
如果这里不指定"-s service-name",就会显示所有Service的配置,这些配置包括preferred 和available instance. 使用-a 选项,还会显示TAF 相关信息。
3) 是否自动运行service
数据库启动时,会自动启动所有的Service。有时为了为了维护需要,需要禁用这个特性,在维护完成后再启动这个特性。
#srvctl enable/disable service -d database-name -s service-name -i instance-name
4)启动service
#srvctl start service -d -s -i instance-name -o start-option -c connect-string -q
如果不指定service-name, 则所有的service 都会被启动,可以使用逗号分隔方式,同时启动多个service。 -i 指定在那个实例上启动service。
5) 停止service
#srvctl stop service -d -s -i instance-name -c connect-string -q -f
其中-f 选项可以强制关闭service,并中断了其所有用户的连接。
6) 查看service 状态
#srvctl status service -d -s service-name -i instance-name -f -v
其中-f 可以显示被disable的instance 信息,而-v 可以显示详细输出
7) 删除service
#srvctl remove service -d database-name -s service-name -i instance-name [-f]
注意:在使用srvctl 创建service时,需要注意TAF策略选项必须通过dbms_service包来配置。
示例:
Begin
Dbms_service.modify_service(
Service_name='>Service1',
Failover_method=>dbms_service.failover_method_basic,
Failover_type=>dbms_service.failover_type_select,
Failover_retries=>180,
Failover_delay=>5
);
End;
3.3 配置Service 的注意事项
1). 数据库的服务名是用service_name 参数来指定的,一个数据库可以有多个服务名,但是service_name最长是4kb,不要手工来修改这个参数
2)最多可以创建64个service,每个数据库有2个隐含的service,因此留给用户的就只有62个service。不能修改这两个隐含service的配置,并且也不能手工启动或停止这2个服务。 这两个隐含的service分别是:SYS$BACKGROUND 和 SYS$USERS.
3) 当使用dbca配置Service 时,dbca 会自动更新OCR,启动Service, 当删除service时,会停止service,并更新OCR.
4) 使用srvctl 这个工具时,命令只更新OCR中的配置,不会更新data dctionary 和 listener 中的信息,因此还需要使用dbma_servie 包来更新data dictionary,手工更改listener配置文件。 故推荐使用DBCA工具来配置更改service配置
5) 如果客户端想通过Service 方式连接数据库,需要在tns条目中使用service_name 方式引用数据库。 如:
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)
)
)
注意:无论是使用dbca 工具还是使用srvctl 命令来配置service,都无法配置TAF的TYPE,DELAY,RETRIES 三个属性,必须使用dbms_service包来修改这些属性。
#Srvctl add service -d -s -r "preferred-instance-list" -a "available-instance-list" -P -m <FAILOVER_METHOD> -e <FAILOVER_TYPE> -z <number of times to retry> -w <wait time between reconnection attempts>
增强了以下内容:
-m:FAILOVER_METHOD
-e:FAILOVER_TYPE
-z:define the number of times that a failed session attempts to reconnect to the service
-w:define how long it should wait between reconnection attempts
在11gr2中通过srvctl命令增加service时仍然只能修改ocr信息,但通过srvctl start service命令或者重启数据库都可以将service配置信息更新到字典中,可在dba_services视图查询到。删除service时,srvctl remove service命令仍然只能修改orc信息,将service信息从字典中去除还只能通过dbms_service包完成。
Enabling Fast Connection Failover (FCF) for the Oracle JDBC Universal Connection
Pool (UCP) enables the use of FAN high availability and load balancing advisory
events. To use FAN, your application can use the JDBC development environment for
either thick or thin JDBC clients. The Java Database Connectivity Oracle Call Interface
(JDBC/OCI) driver connection pooling functionality is part of the JDBC client. This functionality is provided by the OracleOCIConnectionPool class.
The UCP is integrated to take advantage of Load Balancing Advisory information. Oracle introduced the Universal Connection Pool for JDBC in Oracle Database 11g
release 11.1.0.7.0. Consequently, Oracle deprecated the existing JDBC connection pool, the Implicit Connection Cache, that was introduced in Oracle Database 10g release 1,
for use with Oracle RAC databases. You can use the UCP with Oracle Database 10g or
Oracle Database 11g.
To enable FCF for the JDBC client, set the fastConnectionFailoverEnabled
property of the OracleDataSource class in the oracle.jdbc.pool package before making the first getConnection() request. When you enable FCF for the JDBC
client, the failover property applies to every connection in the connection pool.
Enabling FCF with JDBC Thin Driver (Thin driver) or JDBC/OCI clients enables the
connection pool to receive and react to all FAN events.
JDBC application developers can now programatically integrate with FAN by using a
set of APIs introduced in Oracle Database 11g release 2 (11.2). The Oracle RAC FAN
APIs enable application code to receive and respond to FAN event notifications sent
by Oracle RAC in the following ways:
■ Listening for Oracle RAC service down, service up, and node down events
■ Listening for load balancing advisory events and responding to them
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/95233/viewspace-764631/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/95233/viewspace-764631/