Application Continuity特性可以在中断后恢复受影响的数据库会话的任务，从而让终端用户和应用程序感觉不到中断的发生。Application Continuity执行恢复的过程是在应用程序的下层，因此中断发生后，应用程序只会表现为轻微的延迟。

这样，在计划内中断、或异常中断时，Application Continuity可以提高用户的使用体验，增强系统、应用的容错性。

在12CR2中，Application Continuity支持java、oci、odp.net应用。

当发生可恢复错误的时候，数据库会发送恢复请求，收到请求后，Application Continuity会以温和的、非破坏性的方式replay会话请求。请求可以包含事务型、非事务型调用，也可以是在客户端、中间层本地的调用。在replay成功之后，应用从数据库会话中断的时候继续执行，终端用户不会被挂起，可以继续执行操作。管理员也不用介入。

当然，对于不可恢复的错误，比如遇到无效的输入数据、或者其他限制，Application Continuity就不能起作用了。

1.未使用Application Continuity

2.使用Application Continuity后

12C中，Application Continuity支持以下的client端和server端：

1.client端

» Oracle JDBC Replay Driver 12c or later. This is a JDBC driver feature provided with Oracle Database 12c for Application Continuity, referred to as the “replay driver” onwards.
» Oracle Universal Connection Pool (UCP)
» Oracle WebLogic Server 12c, and third-party
» Java connection pools or standalone Java applications using Oracle JDBC - Replay Driver 12c or later.
» Oracle Tuxedo (version?)
» OCI Session Pool 12c Release 2 or later
» SQL*Plus 12c release 2 or later
» ODP.NET Unmanaged Provider 12c Release 2 or later

2.server端

Oracle Database 12c Server
» 数据库决定哪些调用是可恢复的，已经如何恢复。
» 以下数据库调用是可恢复的：select、pl/sql、alter session、dml、ddl、commit、rollback、savepint、jdbc、oci调用
» 支持所有的数据库事务类型：本地、并行、远程、分布式、内嵌事务

Application Continuity执行的三个阶段：

1.normal runtime 正常运行阶段
在正常运行阶段，每个数据库请求被会被加上标记(开始标记、结束标记)。
12C客户端和数据库端协作，决定请求中哪些调用是可replay的，哪些是不可以的。
replayable的调用以及调用的有效信息会被12c驱动保留的长一点，直到请求结束或者replay属性被取消。严格的调用、提交、请求结束，或者应用显式调用都会取消replay属性。

2.reconnect 重连接阶段
重连接阶段，可恢复的错误会触发Application Continuity。
在这个阶段会检查请求是否有replay属性；以及请求的replay的有效期。检查结束后，会对数据库建立新的连接，
重连接可能需要时间，所以dba应该检查网络配置属性replay_count、replay_delay，服务配置属性failover_delay、failover_timeout。
重连接数据库后，驱动会验证目标库的有效性，以及上一个事务是否成功提交。如果连接到数据库在逻辑上不是同一个库，或者事务已经丢失（比如数据库已经被还原到in time状态），驱动不会重新提交事务。
Transaction Guard强制提交上次事务结果。

3.replay 重放阶段
新连接建立后，进入replay阶段。
数据库会指导replay的执行。
如果有用户已经看到数据的变化，replay属性会被取消。
在replay阶段不可以提交事务，但是可以提交上一次的提交操作，也就是遇到需要恢复的调用。
replay成功后，请求恢复到上次失败的时间点。
如果replay不成功会报错。

Application Continuity使用的限制

1.global 全局限制
全局限制会取消对任何请求的Application Continuity特性
使用数据库service名连接数据库的请求是不支持Application Continuity特性的。比如默认的db_name，db_unique_name。数据库服务名不是设计用来支持高可用应用的，因为数据库服务名不能开启、取消或者fail over。
使用jdbc连接的应用，对已经过时的oracle.sql concrete classes不支持Application Continuity特性的，如blob、clob、bfile、opaque、rray、truct、oradata
OCI驱动要排除ADTs、高级队列，动态绑定，以及一些LOB APIs。
如果语句在应用服务器层设置了缓存（比如第三方应用服务器语句缓存），如果要开启replay特性，需要禁用缓存。作为替代，可以在jdbc、oci中设置语句缓存。比如设置oracle.jdbc.implicitstatementcachesize=nnn

2.request 请求级别限制
有些数据库请求不支持Application Continuity特性，下一个请求会自动恢复Application Continuity特性。
从12.2开始，分布式两阶段提交，replay只是支持本地事务。
ADG环境，如果应用使用dblink连接到其他库，不支持replay。
含有alter system、alter database的请求不支持replay。因为replya不会增加表空间、关闭或重启数据库
对于有些会修改提交行为、或set events的alter session操作也不支持replay。

3.目标数据库级别
目前Application Continuity不支持failover到不同的逻辑数据库。包括逻辑dg、ogg和第三方复制方案。
replay需要严格应用到相同的数据库，从而确保事务没有丢失

Application Continuity的评估
是否开启AC功能前需做出一些评估：
1.检查请求边界
请求边界是指数据库请求被标记了开始和结束标签。在12cR2的客户端中，被嵌入边界的连接池包括UCP、weblogic server数据源、Tuxedo、OCI、ODP.NET以及标准的第三方应用服务，使用12c jdbc驱动的单独java池。sql*plus也可以。
根据以下过程验证是否加了正确的标记：
(1)看应用是否从连接池使用和归还连接。如果是，请求会被内嵌加上连接边界。
(2)如果应用从连接池请求了连接，但是没有释放。通常是建议应用设置释放连接机制。
(3)如果是第三方java连接池，且没有使用oracle jdbc的 pooledconnection接口，有三种选择：
--使用UCP替换数据源
--使用oracle jdbc的 pooledconnection接口来创建和管理连接池
--增加带有开始请求和结束请求的api
2.确保没有过期的jdbc concreate classes
使用ORAchk中的acchk进行检测
$ ./orachk -asmhome /tmp/asm-all-5.0.3.jar -javahome /tmp/jdk1.8.0_40 -appjar /tmp/appdir

3.确定哪些请求不需要replay
比如使用外部调用、匿名事务等。如果不需要replay，要做好设置。

4.确定应用在failover之前是否需要最初的状态
有些应用是无连接状态的。要根据实际设置参数failover_restore的值

5.为易变值授权保留原值
易变函数通常每次会产生新值。要想使用replay，就要保持他们不会产生新的值：
sql> grant [keep date time | keep sysguid].. [to user]
sql> grant keep sequence.. [to user] on [sequence object];
sql> alter sequence.. [sequence object] [keep|nokeep];
sql> create sequence my_seq keep;
sql> -- or, if the sequence already exists but without keep:
sql> alter sequence my_seq keep;

Fast Connection Failover (FCF)
Fast Application Notification (FAN)

6.确定AC提供的保护级别
使用ORAchk的acchk生成报告AC的保护级别。