对于很多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.410gR2为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年开始做这种云化的工作确实节约了不少成本而且也方便了管理。社群相关文章可以复习下
-
Oracle 12c PDB迁移一
第三点是12cR2才推出的Sharding。Oracle的Sharding可以认为是patition思想的升级版一脉相承。上面卖了一个关子的GDS组件就是为了sharding而生的。有了shardingOracle一直被诟病缺失的分布式数据库终于出台了。从个人练习使用的情况来看非常简单易用而真正的生产实践还敬请期待。
当然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你还有哪些疑问或者希望社群推出什么文章欢迎留言。
原文发布时间为2017-03-03
本文来自云栖社区合作伙伴DBAplus
