Oracle 12cR2发布,金融行业准备大规模上了

杨建荣、杨志洪 2017-03-03 09:50:47
DBAplus Newsletter第二期资讯中我们已经预告,Oracle率先发布了Exadata、SuperCluster版本,12c Release 2的发布也拉开了帷幕,而在2017年3月1日,Oracle终于发布了它的Linux 64版本和Solaris版本(包括x86和SPARC架构)。

 

对于很多Oracle DBA来说,12c最期待人心的就是12c Release 2的发布了,而Linux 64位版本的发布则是一个重头戏。

 

 

Oracle12cR2版本跟以前的版本相比,多了一个Global Service Manager,你可以叫GSM或者GDS,为其分布式特性而引入。

 

 

接下来还有windows、HPUX、AIX版本的12c会在Q2再发布。

 

为什么是12c R2,版本号解读

 

对于数据库软件版本来说,目前实际应用还是11g为主,10g逐步退役,11gR2目前最新稳定版本为11.2.0.4,10gR2为10.2.0.5。

 

Oracle版本描述在11g、12c没有变化,但是和10g略有一些差异,如下图。

 

 

  • —第一个数字位代表的是一个新版本软件,也标志着一些新的功能。如10g、11g、12c。

  • —第二个数字位代表的是新特性版本,也叫作维护版本,我们期待多年的Release 2就是这个版本。

  • 第三个数字位代表中间件的版本号,10g和11g的版本差别就在于此,也是对BEA融合的支持。

  • —第四个数字位代表组件的特定版本号,比如,Oracle的Patch包。

  • 第五个数字位代表平台版本的标示,通常用来标示Patch号。

 

关于第5位Patch号,值得一提的是2016年1月份Oracle推出了对 PSU、SPU、Bundle Patch 新的命名规则。新的命名规则为(以11.2.0.4为例):11.2.0.4.YYMMDD。YYMMDD 会对应为patch (PSU、SPU、Bundle)发布的具体日期。具体可以参见MOS文档(Doc ID 1454618.1),一个基本的情况如下图所示。

 

 

我们为什么要开始考虑大规模升级到Oracle12cR2呢?

 

看看下面这个表格,生产上现在最大装机量的11.2.0.4将在2020年12月31日就不再发布任何补丁支持(其实对于大部分用户来说,截止日期可以认为是2018年12月31日,因为你后面不付昂贵的延长支持费即使有补丁你也下载不了)

 

 

也就是说,满打满算,你还有22个月的时间,用于升级你的生产到12cR2。

 

这中间包括你的功能选型、架构选型、应用开发支持、测试、UED……直至运行在生产上。否则,如果刚好你的应用踩到了某个前人没有遇到的bug,你就真栽秧了。这是产品支持的风险。坦白说,如果你的应用已经很稳定,又不做业务功能需求变更、使用什么很新奇的函数,基本也不太会踩坑,所以这就是为什么至今仍有Oracle 8i的生产系统在运行的道理。

 

从纯技术的角度来说,我们也是支持上Oracle12cR2的。银行业这次一反常态,已经开始测试,准备大规模上生产了。(详情:2017年数据架构师架构选型必读

 

12c中到底有哪些变化呢,一种洞察的方法就是从数据库参数来一窥其中的奥妙。

 

首先我们选取了几个样本,因为12cR1和12cR2中间间隔了几年,我们就区别对待。

 

数据库版本

所有参数个数

开放的参数个数

10.2.0.5.0

1618

259

11.2.0.4.0

2912

351

12.1.0.2.0

3975

380

12.2.0.1.0

4845

417

 

Oracle中其实含有大量的隐含参数,而开放给我们的参数占比只占到了大概10%。

 

下面看到这两个图:

 

 

上图是所有的数据库参数,下图是开放给我们的参数,可以明显地看到数据库参数的增长情况。以12c为例,12cR2中的所有参数(包括隐含参数)有4845个,而通过show parameter开放给我们的参数却只有417个,这个比例非常低,也可以进一步说明Oracle中确实有非常多的潜在,丰富的设置,很多都可以通过隐含参数来特殊调整,而另一方面由此也可以看出,隐含参数如此之多,复杂度极高,本身还是不建议轻易修改隐含参数的,因为很多隐含参数的值是默认的最优值,有些还有关联关系。 

 

 

而不同数据库版本中,参数的数量占比是如何呢,我们看一下10g、11g、12c的参数占比图。绿色部分是12c的参数,数据库参数(开放参数+隐含参数)占比甚至超过了10g+11g的总和。

 

 

而开放的参数在12cR2中保留了相当的空间,其中参数增长部分主要体现在IMO和PDB两个方面,我们下面会展开来说。

 

 

12c有哪些亮点值得我们去用?

 

首当其冲的,当然是Oracle In Memory Option。社群之前发表过几篇文章,不摘录了,使用了列式内存存储,性能提高极大,非常有诱惑力:

 

 

其次,多租户对于有几十上百个小数据库的部门或者公司来说,这是一大福音,赶紧整合、云化吧。我们从2014年开始做这种云化的工作,确实节约了不少成本,而且也方便了管理。社群相关文章,可以复习下:

 

 

第三点,是12cR2才推出的Sharding。Oracle的Sharding可以认为是patition思想的升级版,一脉相承。上面卖了一个关子的GDS组件,就是为了sharding而生的。有了sharding,Oracle一直被诟病缺失的分布式数据库终于出台了。从个人练习使用的情况来看,非常简单易用,而真正的生产实践,还敬请期待。

 

当然12cR2还有许多小的改进,但是,有此三点,已经是足够充分的理由去考虑升级了。

 

说到升级,可不是个小事情,而是一个大工程。

 

 

从前期的调研分析、方案制定、升级测试到正式升级,环环相扣,疏忽不得。

具体的升级方法,可参考DBAplus社群分享的部分文章:

 

 

还有一些参数一定得注意,不然你可能要掉坑,甚至是在11g里掉过一次的。

 

  • DEFERRED_SEGMENT_CREATION

    默认是true,建议设置为false

 

  • _DATAFILE_WRITE_ERRORS_CRASH_INSTANCE

    默认是true,所有datafile的IO写error,都会导致数据库crash。建议设置为false。

 

  • JOB_QUEUE_PROCESSES

    默认是1000,建议设置为你真正需要的数字。如果你不知道,建议设置为0。

 

  • _OPTIMIZER_AGGR_GROUPBY_ELIM

    默认是true,可能会导致groupby类的结果集错误。建议设置为false。

 

  • SESSION_CACHED_CURSORS

    默认值是50,太小,容易导致内存碎片,建议设置为1000.

 

当然,还有一些参数也建议改,很难给一个具体建议,需要根据实际情况进行设置。

 

相信到了这儿,你对12cR2已经有一个整体的认识了,抽时间下载试用吧,等了很久,这一刻终于到来了。

 

那么,对于12cR2,你还有哪些疑问,或者希望社群推出什么文章,欢迎留言。

活动预告