eygle.com   eygle.com
eygle.com eygle
eygle.com  
 

April 16, 2018

2018 Oracle APAC用户组大会在上海胜利闭

2018 Oracle APAC 用户组大会于2018年4月12日在上海举行,我和杨廷琨作为ACOUG的代表,参加了此次用户组大会。

除了中国本土的用户组,还有来自韩国、澳洲、印度等地的用户组。

APACOracleUG-2018.jpg

在会议开始,Tony Chen展示了Oracle 全球用户组,在 FY18 财年的活动统计,其中包括 675 个 Events,5216 个Sessions,其中和Cloud相关的Session达到1707个。

云技术推广是Oracle战略的主线和导引方向。

UGEvent.png

Oracle 全球社区的负责人 Jeremy Whyte 为我们介绍了Oracle云业务的增长,从数据上看,FY18财年,Oracle的新的软件收入中,

云上的SaaS和IaaS、PaaS部分已经超过 50%,Oracle的云战略已经成效初显:

IMG_20180412_093011R.jpg

ACOUG 联席主席杨廷琨发表演讲,介绍 ACOUG 在过去一年的成绩,ACOUG FY18 举行了超过20场活动,线下影响了5000+,线上的传播则影响了超过100w读者。

在2018年,ACOUG将继续展开基于Cloud技术的全国行,将18c以及Oracle Cloud新技术带给广大的Oracle用户。

IMG_20180412_134734R.jpg

不忘初心,继续前行,ACOUG 2018 将加速前行,感谢大家一贯的支持和帮助!

Posted by eygle at 10:46 AM | Permalink | Activity (152)

March 26, 2018

Oracle 12.2 新特性:BigSCN 支持 8 字节存储解决SCN越界问题

前情回顾:

更新通报:Oracle修正了关于DB Link补丁的公告

解决方案:Oracle的DB Link问题及升级路线详述

预警揭秘:11.2.0.4前版必须在2019年4月升级

Oracle Database 12.2 中,为了更彻底的解决SCN问题,Oracle 通过引入 BigSCN 的新特性,最终改变了 SCN 的算法。

ScnChangedCover.jpg

BigSCN 新特性最根本的改变是:将原来 SCN 的存储位数从 6 字节扩展为 8 字节。对比起来,我们将原来的SCN算法称为 SmallSCN,现在的就是 BigSCN。

在 Oracle 12.2 的执行文件中,可以看到其中的一点提示:

[oracle12c@enmotech bin]$ strings oracle | grep big_scn

_big_scn_test_mode

Raising initial SCN from 0x%016llx to 0x0002000000000000 due to _big_scn_test_mode = 4

Raising initial SCN from 0x%016llx to 0x0000ffffffff1fff due to _big_scn_test_mode = %d

通过隐含参数列表,可以获得 big scn 的一个隐含参数,从这个注释中可以看出新特性被命名为 BigSCN, 缺省值是 2 ,在产品环境中这个参数不可以修改,是以测试目的设置的 :

NAME: _big_scn_test_mode

VALUE: 2

DESCRIB: testing mode for BigSCN

通过以上两类输出,可以看到,当 _big_scn_test_mode 被设置为 4 的时候,SCN 会增进为 0x0002000000000000 ,由这些我们可以看出 SCN 终于突破了 6 Bytes 的设置,进入到了 8 Bytes 时代。


插播活动信息

2018 ACOUG中国行之·上海站 4月13日上海相见,从Oracle 18c到MySQL 8.0 ,5 大技术主题,欢迎来约,报名详情参考:

ACOUG China Tour 2018 - 4月13日启航上海站

当SCN mode 设置为 4 的时候,SCN 会直接跃迁到 7 Bytes,超越了 6 Bytes 的界限。

那么这个SCN 是多少?

SQL> select to_number('2000000000000','xxxxxxxxxxxxx') scn

from dual;

SCN

------------------------

562,949,953,421,312

而 6 Bytes 的 SCN极限值是281 trillion :

SQL> select power(2,48) scn from dual;

SCN

------------------------

281,474,976,710,656

将这两组数据放到一个表格会显得一目了然:

SCN 位数和设置 SCN值
6 Bytes最大可用

281,474,976,710,656

_big_scn_test_mode=4

562,949,953,421,312

BigSCN 最大可用
9,223,372,036,854,775,808

_big_scn_test_mode=4 的起点是 49 位,比较 原来的 48 位增进一位,这个起点就直接超越了过去的最大限制:

SQL> select power(2,49) scn from dual;

SCN

------------------------

562,949,953,421,312

BigSCN 最大可用值上升到一个天量数字,可以看到关于SCN问题,我们越来越不需要去担心了:

SQL> select power(2,63) scn from dual;

SCN

--------------------------------

9,223,372,036,854,775,808

虽然理论值做出了改变,SCN的地址空间也获得了增加,但是在实践中,这些新特性的获得是渐进式,在 12.2 之后,这些特性才会逐渐的释放出来。

在以下我的测试环境中,尝试将SCN推进到了极高的位置:

SQL> select current_scn scn from v$database;

SCN

--------------------------------

4,519,057,215,000,399

SQL> oradebug setmypid

Statement processed.

SQL> oradebug dumpvar sga kcsgscn_

kcslf kcsgscn_ [0600113B8, 0600113E8) = 00050F5D 00100E0F

将这个数字放到前面的表格中,大家可以看到SCN在实践中可以获得的海量值空间:

SCN 位数和设置 SCN值
6 位SmallSCN 最大

281,474,976,710,656

_big_scn_test_mode=4

562,949,953,421,312

测试环境 SCN 推进量 4,519,057,215,000,399

8 位BigSCN 最大

9,223,372,036,854,775,808

为了防止SCN的过度增加,Oracle 增加了内部函数去分析headroom,并通过 600 号错误的 kcm_low_scn_headroom_alert_1 抛出异常:

2018-03-23T18:12:01.849206+08:00

Errors in file /enmo12c/enmo12c/trace/enmo12c_ora_5259.trc (incident=174424) (PDBNAME=CDB$ROOT):

ORA-00600: internal error code, arguments: [2252], [4520092301887888], [4519517455400960], [], [], [], [], [], [], [], [], []

Incident details in: /enmo12c/enmo12c/incident/incdir_174424/enmo12c_ora_5259_i174424.trc

2018-03-23T18:12:01.858629+08:00

Errors in file /enmo12c/enmo12c/trace/enmo12c_ckpt_5220.trc (incident=174304) (PDBNAME=CDB$ROOT):

ORA-00600: internal error code, arguments: [kcm_low_scn_headroom_alert_1], [], [], [], [], [], [], [], [], [], [], []

Incident details in: /enmo12c/enmo12c/incident/incdir_174304/enmo12c_ckpt_5220_i174304.trc

这个启用了 BigSCN 的 12.2 数据库,当通过DB Link连接 11.2.0.4 的数据库时:

SQL> create database link enmo

connect to eygle identified by eygle using 'enmo';

Database link created.

SQL> select * from dual@enmo;

select * from dual@enmo

*

ERROR at line 1:

ORA-24442: SCN exceeds the capability of the target OCI database or client

这是一个新的错误号:

ORA-24442: SCN exceeds the capability of the target OCI database or client

Cause: An attempt was made to transfer a system change number (SCN) to an Oracle database or client that is older than Release 12.2 and the SCN exceeds the maximum value that such a system can handle.

Action: If needed, update the target database or client to Release 12.2 or higher.

有了BigSCN的新特性,在12.2版本之后,Oracle 关于SCN的种种问题,可能再也不容易被遇到了。

在官方文档上有一些描述与 8 Bytes的 BigSCN相关:

Data Pump Export and Data Pump Import support the new big SCN size of 8 bytes. See the Export FLASHBACK_SCN and the Import FLASHBACK_SCN parameters.

As of Oracle Database 12c release 2 (12.2), the SCN value can be a big SCN (8 bytes). You can also specify a big SCN when you create a dump file for an earlier version that does not support big SCNs because actual SCN values are not moved. See the following restrictions for more information about using big SCNs.

  • You cannot specify a big SCN for a network export or network import from a version that does not support big SCNs.

附录

在kcm内核文件中,可以看到和BigSCN相关的一些函数调用:

bigscn: %c

-?comment:PROF: NO_PROFILE krsu_fal_rcv_hndl_bigscn()

-?comment:PROF: NO_PROFILE krsu_fal_send_hndl_bigscn()

-?comment:PROF: NO_PROFILE krsu_rfs_rcv_hndl_bigscn()

-?comment:PROF: NO_PROFILE krsu_rfs_send_hndl_bigscn()

-?comment:PROF: NO_PROFILE krsu_rfx_rcv_hndl_bigscn()

-?comment:PROF: NO_PROFILE krsu_rfx_send_hndl_bigscn()

krsu_fal_rcv_hndl_bigscn

krsu_fal_send_hndl_bigscn

krsu_rfs_rcv_hndl_bigscn

krsu_rfs_send_hndl_bigscn

krsu_rfx_rcv_hndl_bigscn

krsu_rfx_send_hndl_bigscn

-?comment:PROF: USED kcm_low_scn_headroom_alert()

kcm_low_scn_headroom_alert

kcm_low_scn_headroom_alert_1

相关阅读:

更新通报:Oracle修正了关于DB Link补丁的公告

解决方案:Oracle的DB Link问题及升级路线详述

预警揭秘:11.2.0.4前版必须在2019年4月升级

SCN、ORA-19706错误和内部参数

深入剖析:Oracle SCN 机制详解

安全警报:2018一月号安全补丁修复安全漏洞

安全警告:WebLogic WSAT组件漏洞挖矿程序攻击

如果在此问题上需要进一步的协助,请联系云和恩墨的技术团队,更详细的解决方案将提供给我们的服务客户。也欢迎加入我们的微信群进一步的讨论该问题。

云和恩墨

数据驱动,成就未来。整合业界顶尖的技术与合作伙伴资源,围绕数据及相关领域,提供解决方案和专业服务。
IT基础架构
分布式存储 | zData一体机 | 容灾方案
数据架构
Oracle DB2 MySQL NoSQL
专项服务:架构/安全/优化/升级/迁移
运维服务:运维服务 代维服务
人才培养:个人认证 企业内训
软件产品:SQL审核、自动化运维、数据恢复
应用架构
应用和中间件:数据建模 | SQL审核和优化 | 中间件服务

Posted by eygle at 11:18 AM | Permalink | Oracle12c/11g (138)

March 24, 2018

Mac Terminal 终端防范 idle 避免自动中断的方法

在MAC电脑上,通过 Terminal 终端 ssh 连接远程主机时,如果一段时间没有操作,经常会发生中断。

可以通过修改mac上的ssh配置解决此问题:

vi ~/.ssh/config
// 加入:
ServerAliveInterval 30

这个参数是每隔30秒,mac客户端会主动向服务器发出一次请求。
这样就使得服务器端认为客户端是一直在线状态,也就不会主动断开连接了。

SecCRT 有个 30 秒自动发送字符的做法,Mac 的这个参数设置方便了很多。记录备忘。

Posted by eygle at 4:27 PM | Permalink | Windows (62)

March 19, 2018

SCN 新算法:DBMS_SCN的用法及范例

我们在之前的文章中介绍,Oracle修改了SCN算法,使得SCN的增长率最高可以达到96K/s。
并且设置了3个兼容性级别,对应不同的增长率,1,2,3 是三个可设置级别,3 是终极目标的 96K/s 增长率。

为了推进数据库自动演进到3级的SCN算法,引入了 Auto-Rollover 特性,
根据缺省设置,在 2019年6月23日,数据库将自动启用这个级别。

为了更好的监控和管理SCN,引入了DBMS_SCN包。我们来看一下这个包的使用。

以下是创建脚本:
CREATE OR REPLACE LIBRARY DBMS_SCN_LIB TRUSTED AS STATIC;
/

CREATE OR REPLACE PACKAGE DBMS_SCN AUTHID CURRENT_USER IS

DBMS_SCN_API_MAJOR_VERSION  CONSTANT NUMBER := 1; 
DBMS_SCN_API_MINOR_VERSION  CONSTANT NUMBER := 0;

以下存储过程用于获得当前的SCN参数,包括当前的SCN兼容性,Headroom:
PROCEDURE GetCurrentSCNParams(
                rsl      OUT number,
                headroom_in_scn OUT number,
                headroom_in_sec OUT number,
                cur_scn_compat OUT number,
                max_scn_compat OUT number);

--      Currently no exceptions are thrown.
--      rsl             - Reasonable SCN Limit as of 'now'
--      headroom_in_scn - Difference between current SCN and RSL
--      headroom_in_sec - number of seconds it would take to reach RSL
--                        assuming a constant SCN consumption rate associated
--                        with current SCN compatibility level
--      cur_scn_compat  - current value of SCN compatibility
--      max_scn_compat  - max value of SCN compatibility this database
--                        understands

采用这个过程可以获得如下信息:
DECLARE
 crsl  NUMBER;
 hscn NUMBER;
 hsec NUMBER;
 csc  NUMBER;
 msc  NUMBER;
BEGIN
  dbms_scn.getCurrentSCNParams(crsl, hscn, hsec, csc, msc);
  dbms_output.put_line('Current  RSL:'||TO_CHAR(crsl));
  dbms_output.put_line('Headroom SCN:'||TO_CHAR(hscn));
  dbms_output.put_line('Headroom Sec:'||TO_CHAR(hsec));
  dbms_output.put_line('Currnt SCOMP:'||TO_CHAR(csc));
  dbms_output.put_line('Max_SCN_COMP:'||TO_CHAR(msc));
END;
/
Current  RSL:20764257779712
Headroom SCN:20764254578401
Headroom Sec:633674761
Currnt SCOMP:2
Max_SCN_COMP:3

以下函数用于获得兼容性的信息:
FUNCTION GetSCNParamsByCompat(
                compat IN number,
                rsl           OUT number,
                headroom_in_scn OUT number,
                headroom_in_sec OUT number
         ) RETURN boolean;

--     compat           -- SCN compatibility value
--     rsl              -- Reasonable SCN Limit
--     headroom_in_scn  -- Difference between current SCN and RSL
--     headroom_in_sec  -- number of seconds it would take to reach RSL
--                         assuming a constant SCN consumption rate associated
--                         with specified database SCN compatibility
--
--     Returns False if 'compat' parameter value is invalid, and OUT parameters
--     are not updated.
DECLARE
 boo  BOOLEAN;
 rsl  NUMBER;
 hscn NUMBER;
 hsec NUMBER;
BEGIN
  boo := dbms_scn.getSCNParamsByCompat(1, rsl, hscn, hsec);
  IF boo THEN
    dbms_output.put_line('T');
  ELSE
    dbms_output.put_line('F');
  END IF;
  dbms_output.put_line(TO_CHAR(rsl));
  dbms_output.put_line(TO_CHAR(hscn));
  dbms_output.put_line(TO_CHAR(hsec));
END;
/
T
15910860898304
15910857696641
971121685

以下存储过程获得自动Rollover的时间和目标兼容性,启用与否的信息:
PROCEDURE GetSCNAutoRolloverParams(
                effective_auto_rollover_ts OUT DATE,
                target_compat OUT number,
                is_enabled OUT boolean);

--      effective_auto_rollover_ts  - timestamp at which rollover becomes
--                                    effective
--      target_compat               - SCN compatibility value this database
--                                    will move to, as a result of
--                                    auto-rollover
--      is_enabled                  - TRUE if auto-rollover feature is
--                                    currently enabled

执行如下代码的输出:
DECLARE
 boo     BOOLEAN;
 efrt    DATE;
 tcompat NUMBER;
BEGIN
  dbms_scn.GetSCNAutoRolloverParams(efrt, tcompat, boo);
  dbms_output.put_line('Eff time:'||TO_CHAR(efrt));
  dbms_output.put_line('Tar compt:'||TO_CHAR(tcompat));
  IF boo THEN
    dbms_output.put_line('Enabled');
  ELSE
    dbms_output.put_line('Not Enabled');
  END IF;
END;
/

Eff time:23-JUN-19 -- 可以看到启用时间是2019年6月23日。
Tar compt:3
Enabled



PROCEDURE EnableAutoRollover;

PROCEDURE DisableAutoRollover;

END DBMS_SCN;
/

Posted by eygle at 8:42 PM | Permalink | Oracle12c/11g (138)

Oracle全面修正了关于DB Link和SCN补丁的公告

前情回顾,请参考之前的文章:

预警揭秘:倒计时炸弹11.2.0.4前版本DB Link必须在2019年4月升级真相

解决方案:Oracle的 DB Link 问题及2019年4月前升级路线详述

Oracle 的 DBMS_SCN 修正以及 SCN 的 auto-rollover 新特性

在 Oracle 官方支持站点 MOS 上,此前关于 DB Link 和 SCN 问题的两篇文章已经更新,发布了更详细的信息,现在这两篇文章的标题已经修改为:

Recommended patches and actions for Oracle databases versions 12.1.0.1, 11.2.0.3 and earlier - before June 2019 (Doc ID 2361478.1)

Recommended patching and actions for Oracle database versions 12.1.0.1, 11.2.0.3 and earlier - before June 2019 (Doc ID 2335265.1)

主要更新反应了2点:

  1. 更新时间建议从原来的 2019 年4月,修改为 2019年6月;

  2. 必须更新,修改为 推荐补丁应用;

  3. 在文章中明确提出了 2019年6月23日这个时间点。

原来这两篇文章的标题是这样子的:

Oracle Databases Need to be Patched to a Minimum Patchset/PSU/RU level before April 2019 (Doc ID 2361478.1)

Mandatory Patching Requirement for Database Versions 11.2.0.3 or Earlier, Using DB Links (Doc ID 2335265.1)

现在大家终于可以松下一口气了,Oracle 开始较为详细的说明这件事,并且将时间延迟到6月份,我以为原来的文章是内部留了一个余量,现在看来是修正了。我们此前也在文章中详述了可选的解决方案,如果不启用新的SCN兼容性3,补丁应用就不是必须的。

在文章中,首次澄清了补丁修正的内容,补充了以下详细的描述,由于我们之前文章已经详细解释了这些内容,在此我只简要的翻译一下好了:

3. What is the change introduced by the patches listed above?

These patches increase the database's current maximum SCN (system change number) limit.

At any point in time, the Oracle Database calculates a "not to exceed" limit for the number of SCNs a database can have used, based on the number of seconds elapsed since 1988. This is known as the database's current maximum SCN limit. Doing this ensures that Oracle Databases will ration SCNs over time, allowing over 500 years of data processing for any Oracle Database.

These recommended patches enable the databases to allow for a higher current maximum SCN limit. The rate at which this limit is calculated can be referred to as the "SCN rate" and these patches help allow higher SCN rates to enable databases to support many times higher transaction rates than earlier releases.

Please note that the patches only increase the max limit but the current SCN is not impacted. So, if all your databases don't have any major change in transaction rate, the current SCN would still remain below the current maximum SCN limit and database links between newer (or patched) and unpatched databases would continue to work. The patches provide the safety measure to ensure that you don't have any issue with dblinks independent of any possible future change in your transaction rate.

请注意,这个补丁仅仅是增加了最大的SCN限制,所以如果你的数据库在事务率方面没有改变,或者事务率不高,当前的SCN将维持在最大SCN限制以下,在旧版本和新版本之间的DB link也可能毫无问题。

With the patches applied, this change in current maximum SCN limit will happen automatically starting 23rd June 2019.

如果应用了补丁,SCN 新算法的自动生效期是:2019年6月23日。

4. What happens if the recommended PSU / patchset is not applied?

If this patch is not applied, the unpatched database will have a lower SCN rate or lower current max SCN limit.

The newer or patched databases will have higher SCN rate or higher current max SCN limit.

如果不应用补丁,低版本的数据库使用低SCN增长率,高版本数据库使用高SCN增长率。这两类数据库互联,就可能出现SCN的问题。

Therefore, there can be situations when the patched database is at a higher SCN level (due to the higher SCN rate allowance) and the unpatched database is at a much lower SCN level (due to lower SCN rate allowance).

When you open a dblink between these two databases, it has to sync the SCN levels of both the databases and if the SCN increase needed in the unpatched database for this sync is beyond it's allowed SCN rate or current max SCN limit, then the dblink connection cannot be established.

This situation will not rise immediately after the change, but can potentially arise any time after 23rd June 2019.

相关阅读:

SCN、ORA-19706错误和内部参数

深入剖析:Oracle SCN 机制详解

预警揭秘:11.2.0.4前版必须在2019年4月升级

安全警报:2018一月号安全补丁修复安全漏洞

安全警告:WebLogic WSAT组件漏洞挖矿程序攻击

如果在此问题上需要进一步的协助,请联系云和恩墨的技术团队,更详细的解决方案将提供给我们的服务客户。也欢迎加入我们的微信群进一步的讨论该问题。

Posted by eygle at 6:02 PM | Permalink | Oracle12c/11g (138)

近期发表

  • Oracle 11g在补丁修正中引入DBMS_SCN包及新特性 - March 18, 2018
  • 解决方案:Oracle的DB Link问题及2019年4月升级路线详述 - March 17, 2018
  • Oracle 数据库需要在2019年April之前Mandatory升级的说明 - March 16, 2018
  • 揭秘Oracle 11.2.0.4前版本DB Link必须在2019年4月前升级 - March 15, 2018
  • Oracle 的 DBMS_SCN 修正以及SCN的auto-rollover新特性 - March 14, 2018
  • Oracle 18c 安装ORA-12754 Runtime Environment的两种解决方案 - March 5, 2018
  • 极速体验:Oracle 18c 下载和Scalable Sequence新特性 - February 23, 2018
  • Oracle Database 18c已经发布及新特性介绍 - February 23, 2018
  • 遇见未来 | 基于软件定义存储的数据加速解决方案:让你的系统加速跑 - February 7, 2018
  • 对话张冬洪 | 全面解读NoSQL数据库Redis的核心技术与应用实践 - February 5, 2018


  • CopyRight © 2004 ~ 2012 eygle.com, All rights reserved.