Nic*_*mas 17
甲骨文 9i:
SELECT dbms_flashback.get_system_change_number as current_scn
FROM DUAL;
Run Code Online (Sandbox Code Playgroud)
Oracle 10g 及以上:
SELECT current_scn
FROM V$DATABASE;
Run Code Online (Sandbox Code Playgroud)
SCN 具有由其格式强加的硬限制和由 Oracle 人为强加的软限制,如此处所述。我引用了下面的相关部分(强调)。
Oracle 旗舰数据库应用程序的架构师一定很清楚 SCN 需要是一个大整数。它是:一个 48 位数字 ( 281,474,976,710,656 )。Oracle 数据库需要花费大量时间才能超过该数量的事务并导致问题—— 或者您可能会这么认为。
软限制源自一个非常简单的计算,该计算锚定到 24 年前的某个时间点:取自00:00:00 01/01/1988 以来的秒数,然后将该数字乘以 16,384。如果当前 SCN 值低于该值,则一切正常,处理继续正常进行。简而言之,该计算假设数据库自 1988 年 1 月 1 日起持续运行,每秒处理 16,384 个事务,在现实中不存在。
此脚本(Oracle 10g 及更高版本)将检查您已用尽了多少硬限制和软限制。感谢 Rob 提出软限制。
WITH limits AS (
SELECT
current_scn
--, dbms_flashback.get_system_change_number as current_scn -- Oracle 9i
, (SYSDATE - TO_DATE('1988-01-01 00:00:00', 'YYYY-MM-DD HH24:MI:SS')) * 24*60*60 * 16384
AS SCN_soft_limit
, 281474976710656 AS SCN_hard_limit
FROM V$DATABASE
)
SELECT
current_scn
, current_scn/scn_soft_limit*100 AS pct_soft_limit_exhausted
, scn_soft_limit
, current_scn/scn_hard_limit*100 AS pct_hard_limit_exhausted
, scn_hard_limit
FROM limits;
Run Code Online (Sandbox Code Playgroud)
小智 6
这是我想出的一个查询,用于检查我的数据库关于 SCN 错误问题的完整性:
# Show the amount of SCN keyspace we have used so far on this database
# By default the SCN max on a 10g/11g
# instance is a 48-bit integer (281,474,976,710,656)
SELECT NAME,
(current_scn/281474976710656)*100 as PCT_OF_SCN_KEYSPACE_USED,
ROUND(SYSDATE-CREATED) as DAYS_SINCE_DB_CREATION,
ROUND(1/(current_scn/281474976710656)*(SYSDATE-CREATED)) AS EST_DAYS_BEFORE_SCN_EXHAUSTED,
ROUND(1/(current_scn/281474976710656)*(SYSDATE-CREATED)/365) AS EST_YEARS_BEFORE_SCN_EXHAUSTED
FROM v$database;
Run Code Online (Sandbox Code Playgroud)
我的大多数使用数据库链接的数据库都处于 3.5% 耗尽标记,并且可以以当前速度继续使用 50 多年而不会出现问题。这并不意味着我可以免受 SCN 错误的困扰,但至少我们没有找到比其他数据库高得多或接近极限的数据库。