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中間間隔了幾年，我們就區別對待。

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已經有一個整體的認識了，抽時間下載試用吧，等了很久，這一刻終于到來了。