对于很多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年开始做这种云化的工作，确实节约了不少成本，而且也方便了管理。社群相关文章，可以复习下：
Oracle 12c PDB迁移（一）
第三点，是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，你还有哪些疑问，或者希望社群推出什么文章，欢迎留言。
原文发布时间为：2017-03-03
本文来自云栖社区合作伙伴DBAplus
