众所周知，当在两个数据库之间建立 dblink连 接时，SCN 将被同步，以维持分布式事务读取一致性。 这将导致在较低 SCN 的数据库的 SCN 跳变。
在分布式事务中很难找到 SCN 跳变的来源。从 12.2 开始，视图DBA_EXTERNAL_SCN_ACTIVITY 以及 DBA_DB_LINK_SOURCES 和 DBA_DB_LINKS 使我们能够跟踪这些跳转。视图DBA_DB_LINK_SOURCES 也为 12.2 版本的新增视图。
Oracle 官网文档原文：
Finding out External SCN jump using DBA_EXTERNAL_SCN_ACTIVITY in 12.2 (Doc ID 2171090.1)
让我们看看下面的例子，如何在 dblink 连接中涉及的两个数据库中捕获这些跳转。
我们将使用以下示例视图，基于 DBA_EXTERNAL_SCN_ACTIVITY，DBA_DB_LINK_SOURCES，DBA_DB_LINKS 三个视图收集信息。
创建示例视图 SQL 文本：
create or replace view check_ext_scn as
(SELECT RESULT, OPERATION_TIMESTAMP, EXTERNAL_SCN, SCN_ADJUSTMENT,
HOST_NAME, DB_NAME, SESSION_ID, SESSION_SERIAL#
FROM DBA_EXTERNAL_SCN_ACTIVITY a, DBA_DB_LINK_SOURCES s
WHERE a.INBOUND_DB_LINK_SOURCE_ID = s.SOURCE_ID)
UNION
(SELECT RESULT, OPERATION_TIMESTAMP, EXTERNAL_SCN, SCN_ADJUSTMENT,
dbms_tns.resolve_tnsname(HOST) HOST_NAME, NULL DB_NAME, SESSION_ID, SESSION_SERIAL#
FROM DBA_EXTERNAL_SCN_ACTIVITY a, DBA_DB_LINKS o, DBA_DB_LINK_SOURCES s
WHERE a.OUTBOUND_DB_LINK_NAME = s.SOURCE_ID
AND OUTBOUND_DB_LINK_OWNER = o.OWNER)
UNION
(SELECT RESULT, OPERATION_TIMESTAMP, EXTERNAL_SCN, SCN_ADJUSTMENT,
s.MACHINE HOST_NAME, NULL DB_NAME, SESSION_ID, SESSION_SERIAL#
FROM DBA_EXTERNAL_SCN_ACTIVITY a, V$SESSION s
WHERE a.SESSION_ID = s.SID AND a.SESSION_SERIAL#=s.SERIAL#
AND INBOUND_DB_LINK_SOURCE_ID IS NULL
AND OUTBOUND_DB_LINK_NAME IS NULL
AND OUTBOUND_DB_LINK_OWNER IS NULL);上面输出中每列的描述如下：
-
RESULT：SCN 推进是否接受或拒绝
-
OPERATION_TIMESTAMP：推进发生的时间
-
EXTERNAL_SCN：当前 SCN 跳变到的新 SCN 值
-
SCN_ADJUSTMENT：SCN 的增量有多大
-
HOST_NAME：dblink 源于哪个主机
-
DB_NAME：dblink 源自哪个数据库
-
SESSION_ID：此条目的本地实例的会话 ID
-
SESSION_SERIAL#：此条目的本地实例的序列号
创建一个脚本名为 check_ext_scn.sql 内容如下：
select * from check_ext_scn;
检查两个数据库中的 SCN：
Database 1:
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
12693736
SQL> set pages 100 lines 200
col result for a15
col OPERATION_TIMESTAMP for a35
col HOST_NAME for a15
col DB_NAME for a15
SQL> @check_ext_scn
no rows selected
Database 2:
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
1574865
##数据库2的 SCN 是否远远小于数据库1。
SQL>@check_ext_scn
no rows selected尝试两个数据库之间的 Dblink 连接以同步 SCN
Database 1:
从数据库1到2启动 Dblink 连接DUAL：
SQL> select * from dual@testlnk;
D
-
X
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
12693943
SQL>@check_ext_scn
no rows selected
## 注意数据库1中没有发现记录。
Database 2:
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
12693956
##注意数据库2中的 SCN 现在与数据库1同步。
SQL>@check_ext_scn
## 从上面的输出，我们可以看到数据库1已导致数据库2中的 SCN 推进，推进量为11118928 个SCN。当前隐含参数_EXTERNAL_SCN_LOGGING_THRESHOLD_SECONDS 的值设置为600，因此只会记录大于9830400（600 * 16k）的跳变。
现在，由于两个数据库的 SCN 几乎接近，让我们尝试一个 Dblink 连接，看看如果跳变小于9830400个SCN，是否记录 SCN 跳变。
Database 1:
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
12694325
SQL> select * from dual@testlnk;
D
-
X
SQL>@check_ext_scn
no rows selected
Database 2:
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
12694325
##Dblink连接后SCN号发生推进。
SQL>@check_ext_scn
##注意，即使在 SCN 跳变之后，也没有额外的记录，因为它的跳变量小于9830400。
※§6 小结
A. 本质上，DBA_EXTERNAL_SCN_ACTIVITY 捕获 SCN 跳变将非常有用，有助于我们查找有问题的数据库时缩小范围。视图 DBA_EXTERNAL_SCN_ACTIVITY 不会捕获所有 SCN 跳变。 它只在下面的情况下捕获 SCN 跳变。
1) SCN 跳变请求使得本地 headroom 小于 threshold 而被拒绝（由 _external_scn_rejection_threshold_hours 控制）
2) SCN 跳变请求因为 SCN 的 DELTA 增量过高而被拒绝（由 _external_scn_rejection_delta_threshold_minutes 控制）
3) SCN 跳变被接受但带有警告（由 _external_scn_logging_threshold_seconds 控制）
B. 如果 SCN 推进是由此数据库发起的，则此视图不会提供信息。 我们需要在遇到 SCN 跳变的数据库上使用此视图。
原文发布时间为：2018-04-11
本文作者：云和恩墨
