我们知道，数据库是数据的载体，系统中所有的信息最终都要汇集到数据库进行存储和交换，那么数据库的重要性当然是不言而喻的。一旦由于网络中断，存储故障，或者服务器故障而导致数据库出现故障，必将会对客户造成业务中断、客户流失、生产力损失，以及其他不可估量的影响。
有时，我们需要进行安装数据库安全补丁、维护数据库服务器等操作。因为这些操作可能会造成业务中断，所以一般都放在周末或晚上才做。加班的人员会比较辛苦，尤其是数据库管理员，经常是通宵难眠。有时为了做维护，要协调全单位的人员加班，甚至还要涉及协调其他单位，提前半个月发布通告。辛苦做事，通宵加班，最后还有可能接到投诉。
或有时，我们通过应用程序或App填写数据，表格内容很多，比较复杂，用了九牛二虎之力填写完毕，点了提交，却一直转呀转呀转圈圈，最后来了个“温馨提示”：数据库连接超时。心里那个感觉，一下子跌到了谷底，所有的努力都白忙活了。这种感觉大家都深有体会，尤其在当今的数据时代，体验的时代。
为了提高应用的高可用，Oracle提供了一系列的解决方案，满足各种不同的需求。上面说的这些情况，现在就可以很好的避免。Oracle引入了事务卫士(Transaction Guard)和应用连续性(Application Continuity)，通过这些特性将对客户的影响降至最低。这些本是应用程序层面要考虑的问题，现在在数据库层面就可以很容易的实现。更重要的是这些功能对于应用来说是透明的。涉及到的功能和特性包含有ONS、FAN、TAF 、FCF、TG、AC、TAC等，这些特性在Oracle Database 19c中更易用。下面让我们回顾一下这些关键名词，并看一下他们的逻辑关系。
Transparent Application Failover(TAF)
TAF是Transparent Application Failover的缩写，就是我们说的透明应用程序故障转移，是一个可以追溯到Oracle 8i的功能。她只适合于OCI方式的客户端。在实例失败后，TAF会创建一个新会话，当使用SELECT模式时，根据需要将查询重放回失败之前的位置，继续从中断的地方执行下，不会中断。
在Oracle Database 12.2之前，只对SELECT有效，DML操作不会断点续传，不能重放。使用OCI客户端做TAF，应当启用FCF，它会使Failover更快。
从Oracle Database 12.2开始，TAF提供了FAILOVER_RESTORE选项，这个功能就是(Application Continuity)，对于SELECT语句，恢复到中断前的状态，对于事务，会重新建立链接，然后从失败的地方重放事务。
Fast Connection Failover (FCF)
FCF是Fast Connection Failover的缩写。通过支持FAN的Oracle客户端/应用接收FAN Events。当收到Down Event时，和这个Instance/Service相关的连接会被标记为无效并被清除；当收到Up Event时，可以创建新的连接。对于正在运行的Transaction，当应用捕捉到中止Transaction所产生的错误信息后，可以直接把相关错误返回给最终用户，或者从连接池中重新获取一个有效连接并重新执行被中止的Transaction。Oracle建议不要在同一应用程序中使用TAF和FCF，FCF和TAF也有区别 ，FCF不能像TAF那样做到断点续传。Tomcat和JBOSS等可以利用FCF的特性如果使用Oracle的连接池，可也以用UCP(Universal Connection Pool for JAVA)或ICC (JDBC Implicit Connection Cache)。建议使用UCP，因为ICC在将来的版本中会被废弃。从Oracle Database 12.1开始，ONS开始作为主要的消息传递方式。FAN AQ HA通知功能将被废弃，仅支持11g和之前版本的数据库。
Fast Application Notification(FAN)
FAN是Fast Application Notification的缩写，从Oracle 10.2开始才提供，是Oracle RAC的一个特性，是一种主动的消息通知机制。当数据库节点的信息变化(Node up/down, Instance up/down, Database up/down)和节点负载信息发生变化，Oracle通过FAN events把这些信息发布出去，订阅FAN events的客户端在收到这些事件后，能做出相应的动作来响应这些FAN events。在12.2中，FAN内置在JDBC和OCI驱动程序中，并且Java默认情况下处于启用状态。
Oracle Notification Service(ONS)
ONS是Oracle Notification Service的缩写，是Oracle Cluster实现FAN事件发布和订阅的组件，是由ONS配置文件$ORACLE_HOME/opmn/conf/ONS.config控制。这个文件告诉ONS守护进程它应该如何运行以及应与谁交互的详细信息。管理该组件的命令是onsctl，可以通过onsctl debug去做个测试。
Transaction Guard(TG)
TG是Transaction Guard的缩写，我们称之为事务卫士。对于事务来说，在异常情况下，比如最常见的宕机，由于应用程序无法感知事务的当前状态，很容易发生重复提交等情况，造成数据逻辑上的错误。在Oracle 12c中，引入了Transaction Guard功能，她是TAF的拓展，为应用程序提供了一个通用协议或者说是工具，在发生计划内和计划外停机时，或者有重复提交时，最多执行一次，进而保持事务一致性，是通过逻辑事务ID(LTXID)来确定停机后数据库会话中打开的最后一个事务的结果。TG是AC的基础，要使用AC，必须启用TG。启用TG很简单，设置服务中的参数COMMIT_OUTCOME = TRUE，授予用户执行DBMS_APP_CONT的权限。
Application Continuity(AC)
AC是 Application Continuity的缩写，我们称之为应用连续性 ，是在Oracle 12c中引入 的新功能，是 Oracle Real Application Clusters (RAC)、Oracle RAC One Node 和 Oracle Active Data Guard 选件的一个特性，事务中断后，通过恢复正在进行的数据库会话，对最终用户和应用程序屏蔽中断，使其不被最终用户和应用所觉察，同时也减少了对应用程序错误处理逻辑的调用。这样，在应用看来中断只是一次稍有延迟的执行。增强了使用Oracle数据库的系统和应用的容错性。从Oracle database 12.1开始，开始支持基于Java thin的应用程序。从Oracle database 12.2.0.1开始，开始支持基于OCI和ODP.NET的应用程序。
Transparent Application Continuity (TAC)
从Oracle Database 18c开始，引入了Transparent Application Continuity(TAC)，它会透明地跟踪和记录会话和事务状态，以便在出现可恢复的中断之后恢复数据库会话，我们称之为透明应用连续性。它是TAF的延伸，TAF支持SELECT，TAC支持INSERT、UPDATE、DELETE操作。在不需要修改应用程序代码的情况下，允许为您的应用程序启用透明的应用程序连续性。应用程序透明性和故障转移是通过使用状态跟踪信息来实现的，这些信息在应用程序发出用户调用时被捕获。
AC and TAC
AC和TAC的差别不大。TAC可以理解为是AC的升级。差别主要在于配置服务的参数。
另外一点就是副作用，如果要定制重放，请使用AC，如果要屏蔽副作用，可以使用TAC。举个副作用的例子，比如在应用程序的一个事务中，先给客户发一封邮件，然后继续操作，突然出现故障，造成业务中断，如果使用了应用连续性特性，那么就需要重放该事务，可能会再发一封邮件。这个情况，我们就可以称之为副作用。有时候这些是需要避免的。
借助这些特性很好的解决了两个问题，一个是在出问题的时候，能够快速的通知，并做出反应，另一个出现问题后能够快速恢复，并重新开始。
Notification：FAN是隐藏计划内或计划外故障的第一步。当发生中断时，它会通知客户端并中断他们当前的网络等待。这样可以避免应用程序因长时间的网络等待而暂停。
Recovery：在通知客户端后，AC或TAC会重新建立到新的可用实例的连接(在RAC情况下，可能是同一个或另一个实例，或者是Data Guard的备用站点)，并在可能的情况下重播正在进行中(未提交)的工作，应用程序通常可以在不知道发生任何故障的情况下继续执行。
Drain：在停止服务之前，可以有一个等待时间，等待该实例上的会话结束，我们称为放空/排空/耗尽。在该期间，只处理当前的连接请求，不接收新的请求。
下面我们看一下使用应用连续性后，针对计划内和计划外的操作是怎样的：
下面我们将通过SwingBench、sqlplus和Java应用这三种方式来测试应用连续性，看看效果如何。
测试环境信息
创建数据库服务
下面我们从连接数据库的三要素(IP地址、端口、服务名)之一的服务名来看，如何正确的配置服务，才能从客户端或服务器端实现负载均衡和故障转移。注意：不要使用默认的数据库服务名。
在主库上创建数据库服务ohs_ac和ohs_tac
在物理备库上创建数据库服务ohs_ac和ohs_tac
配置客户端TNS/URL
11gR2 RAC引入了SCAN，这个功能非常棒，除了减少了配置连接字符串的工作量，还能实现负载均衡。
如果使用了SCAN，请确保remote_listener设置成了SCAN地址
如果没有使用SCAN，请确保remote_listener设置了包含VIP的所有地址
在URL中设置RETRY_COUNT、CONNECT_TIMEOUT和TRANSPORT_CONNECT_TIMEOUT参数
不同版本的配置，稍有不同，请参考下面的内容
本次实验使用的TNS为
使用SwingBench测试应用连续性
SwingBench是一个免费负载生成器和基准测试工具，主要用于对Oracle数据库(12c，18c，19c)进行压力测试。
1.下载SwingBench并创建模拟数据
下载地址http://www.dominicgiles.com/swingbench.html，解压后运行oewizard 2.bat创建测试数据。注意：在创建初始化数据时，如果是RAC环境，数据文件请指定到ASM磁盘路径，比如+DATA。
2.输入连接的用户名、密码和连接的字符串
在该测试中，我们使用的是数据库服务ohs_ac，连接字符串如下：
(DESCRIPTION=(CONNECT_TIMEOUT=120)(RETRY_COUNT=20)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=xd08m-scan)(PORT=1521)))(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=xd09m-scan)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=ohs_ac)))
授予用户SOE执行DBMS_APP_CONT的权限
grant execute on DBMS_APP_CONT to soe;
3.使用Application Continuity的驱动
将AppContinuityDriver设置为true
将FastFailover设置为true
4.点击运行按钮，然后做下面的测试
下面我们就通过安装滚动补丁的方式来启停实例，这里只启停实例，模拟应用补丁。做了下面的操作：
停止第一个实例，观察应用情况
启动第一个实例，观察应用情况
停止第二个实例，观察应用情况
启动第二个实例，观察应用情况
5.观察应用运行状态
通过观察，我们发现，中间启停实例并未造成应用中断。
使用sqlplus测试应用连续性
sqlplus是oci连接方式的客户端，在这里我们通过sqlplus的一个开关ac来启用应用连续性，使用的数据库服务是ohs_ac。我们用两个会话来执行。下面我们将执行的内容做一步步的拆解，在后面有两张图显示会话1和会话2执行的内容。
准备工作
创建用户ohsdba，并授予相关权限
create user ohsdba identified by oracle12 default tablespace users;
grant resource,connect to ohdsba;
alter user ohsdba quota unlimited on users;
grant execute on DBMS_APP_CONT to ohsdba;
1.连接数据库，创建测试表，并插入数据，此会话标记为会话1
sqlplus -ac ohsdba/oracle12@ohs_ac
create table test(instname varchar2(20));
2.打开新窗口，并查询用户ohsdba连接的实例，此会话标记为会话2
通过下面的查询，我们知道ohsdba用户连接的实例是pgold2
sqlplus -ac system/oracle12@ohs_ac
SQL> select username,count(*),inst_id from gv$session where username='OHSDBA' group by inst_id,username;
USERNA COUNT(*) INST_ID
------ ---------- -------------
OHSDBA 1 2
3.在会话1中插入数据
SQL> insert into test values('pgold2');
1 row created.
4.在会话1中关闭实例pgold2
SQL>!srvctl stop instance -d pgold -i pgold2 -f
SQL>!ssh xd08mdb02 ps -ef|grep pmon
orgrid89081 0 Feb26 ? 00:00:08 asm_pmon_+ASM2
5.在会话1中提交数据并查询当前实例
我们发现虽然关闭了当前连接的实例，但提交成功了，并未出现中断的情况。查询实例名，我们发现当前连接的实例是pgold1(起初连接的是实例pgold2)
SQL> commit;
Commit complete.
SQL> select instance_name from v$instance;
INSTANCE_NAME
--------------------
pgold1
6.在会话2中查看ohsdba用户连接的实例
再次查询用户ohsdba连接的实例，我们发现实例变成了pgold1
SQL> select username,count(*),inst_id from gv$session where username='OHSDBA' group by inst_id,username;
USERNA COUNT(*) INST_ID
------ ---------- -------------
OHSDBA 1 1
使用Java应用测试应用连续性
在该实验中，我们使用数据库服务ohs_tac，然后运行Java程序，并做主备一键切换，在这种极端的情况下，体验透明应用连续性(TAC)。在连接数据库时，请使用Oracle的JDBC驱动，或者使用Oracle的通用连接池UCP(Universal Connection Pool)，jar包名称是ucp.jar。
准备工作，创建测试表
sqlplus ohsdba/oracle12@ohs_tac
create table ohs_test as select rownum rnum from dual connect by level <= 100000;
1.编译并运行java程序
通过下图我们能看到，当前连接的是主库的实例pgold2，按任意键继续。点击下载测试代码。
2.通过DG Broker做主备一键切换
3.观察应用程序变化
我们发现，虽然做了主备切换，经过20多分钟后，Java程序成功执行了，连接的新主库实例是pgoldadg1。
更多关于JDBC和UCP的实验，请参考下方的链接，包含详细的手册和代码
https://www.oracle.com/webfolder/technetwork/tutorials/obe/db/12c/r2/appdev/JDBC_UCP_HOL_2016/JDBC_UCP_HOL_2016.html
通过上面三种不同方式测试，我们可以发现应用连续性这个特性真的太棒了。即使在主备库切换的情况下，也可以保证事务的连续性，保障了系统的高可用，提升了用户体验。在Oracle Database 19c，这个特性支持所有的客户端连接方式。
在Oracle云端，Oracle的自治数据库，也开启了这些特性，并预配置了相应的数据库服务名。欢迎体验Oracle云端的自治数据库和自治数据仓库。
Reference
https://docs.oracle.com/en/database/oracle/oracle-database/19/racad/ensuring-application-continuity.html#GUID-C1EF6BDA-5F90-448F-A1E2-DC15AD5CFE75
扫描下方QR Code即刻预约ADW演示
编辑：殷海英
2275
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
