Oracle 12cR2中有一个不错的特性，那就是Active Data Guard会话保留，原本的叫法是Preserving Active Data Guard Application Connections
怎么理解呢，比如在Active Data Guard上的连接会话，在switchover的过程中会话连接会始终保持不会中断。这一点听起来就很有特点，能够提高用户体验度，而且是一种相对透明的方式。
到底怎么样呢，我们来简单测试一下，先看看默认情况下的ADG会话情况,切换的过程就直接使用DG Broker来做了，快。
这是一个12cR2的环境，也使用了Far Sync。
DGMGRL>show configuration
Configuration - dg_test12cs
Protection Mode: MaxPerformance
Members:
test12cs - Primary database
test_sync - Far sync instance
test12css - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 10 seconds ago)我们连接到备库，备库现在是ADG模式。
SQL> select open_mode from v$database;
OPEN_MODE
----------------------------------------
READ ONLY WITH APPLY如果这个时候我们就使用一条语句在备库端查询，使用TNS连接，然后DG Broker来切换，切换的情况如下，也是一气呵成。
DGMGRL> switchover to test12css
Performing switchover NOW, please wait...
Operation requires a connection to database "test12css"
Connecting ...
Connected to "test12css"
Connected as SYSDBA.
New primary database "test12css" is opening...
Operation requires start up of instance "test12cs" on database "test12cs"
Starting instance "test12cs"...
for RDBMS instance
ORACLE instance started.
Database mounted.
Database opened.
Connected to "test12cs"
Switchover succeeded, new primary is "test12css"
DGMGRL>
在客户端反复测试连接的情况如下：
SQL> select count(*) from cat;
COUNT(*)
----------
153
SQL> /
COUNT(*)
----------
153
SQL> /
select count(*) from cat
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Process ID: 94489
Session ID: 419 Serial number: 62932
可以看到在切换的过程中，连接被中断了，而接下来就会彻底断开连接。
SQL> /
ERROR:
ORA-03114: not connected to ORACLE
这里就需要说一下这个特性的情况，其实还涉及到一个参数standby_db_preserve_states,默认是NONE
SQL> show parameter standby_db_preserve_states
NAME TYPE VALUE
------------------------------------ ---------------------- ------
standby_db_preserve_states string NONE
我们设置为ALL,这个修改需要重启备库，我们设置好之后，再来做switchover
步骤和上面的类似，我们直接来看看效果，始终在这一个会话内查看数据查询的情况,整个过程相对平滑，在切换过程中会有一个大约两秒的停顿，但是连接始终是保持的。
COUNT(*)
----------
153
SQL> /
COUNT(*)
----------
153
SQL> /
COUNT(*)
----------
153
SQL> /
COUNT(*)
----------
153
SQL> /
COUNT(*)
----------
153
整体来看这个特性确实达到了预期的效果，还是蛮不错的。
