对于很多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中间间隔了几年，我们就区别对待。

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已经有一个整体的认识了，抽时间下载试用吧，等了很久，这一刻终于到来了。

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