承上 DBlink 与 SCN | 新增视图找出外部 SCN 跳变

时间：2018-11-02 23:31:40 阅读：199 评论：0 收藏：0 [点我收藏+]

标签：db_name dnw track justify round 数据库 under 基于 release

技术分享图片

?综述?

众所周知。当在两个数据库之间建立 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#：此条目的本地实例的序列号

创建监測SQL脚本

创建一个脚本名为 check_ext_scn.sql 内容例如以下：

select * from check_ext_scn;

?使用Dblink前查看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号与推进记录?

尝试两个数据库之间的 Dblink 连接以同步 SCN?

Database 1:

从数据库1到2启动 Dblink 连接DUAL：?

SQL> select * from dual@testlnk;

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;

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 跳变的数据库上使用此视图。