http://dbaplus.cn/news-10-1098-1.html
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。社群之前发表过几篇文章,不摘录了,使用了列式内存存储,性能提高极大,非常有诱惑力:
Oracle Database 12c新特性对企业影响的思考
In Memory—Oracle 12C重要新特性IMO详解
专家经验论,答In-Memory是否支持Column之疑
平均提速20倍!Oracle 12c In-Memory最佳实践
其次,多租户对于有几十上百个小数据库的部门或者公司来说,这是一大福音,赶紧整合、云化吧。我们从2014年开始做这种云化的工作,确实节约了不少成本,而且也方便了管理。社群相关文章,可以复习下:
Oracle DBCA高级玩法:从模板选择、脚本调用到多租户
Oracle 12c PDB迁移(一)
(http://dbaplus.cn/blog-57-745-1.html)
第三点,是12cR2才推出的Sharding。Oracle的Sharding可以认为是patition思想的升级版,一脉相承。上面卖了一个关子的GDS组件,就是为了sharding而生的。有了sharding,Oracle一直被诟病缺失的分布式数据库终于出台了。从个人练习使用的情况来看,非常简单易用,而真正的生产实践,还敬请期待。
当然12cR2还有许多小的改进,但是,有此三点,已经是足够充分的理由去考虑升级了。
说到升级,可不是个小事情,而是一个大工程。
从前期的调研分析、方案制定、升级测试到正式升级,环环相扣,疏忽不得。
具体的升级方法,可参考DBAplus社群分享的部分文章:
升级到12c云数据库的最佳实践
XTTS,又一个值得你重视的Oracle数据库迁移升级利器
如何保障业务0暂停下,从11gR2 MAA升级到12c?
扒一扒Oracle数据库迁移中的各种坑
还有一些参数一定得注意,不然你可能要掉坑,甚至是在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已经有一个整体的认识了,抽时间下载试用吧,等了很久,这一刻终于到来了。
新闻热点
疑难解答