閱讀670 返回首頁    go 技術社區[雲棲]


Oracle 12cR2發布,金融行業準備大規模上了

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位版本的發布則是一個重頭戲。

 

20170303095427316.jpg

 

Oracle12cR2版本跟以前的版本相比多了一個Global Service Manager你可以叫GSM或者GDS為其分布式特性而引入。

 

20170303095437143.jpg

 

接下來還有windows、HPUX、AIX版本的12c會在Q2再發布。

 

為什麼是12c R2版本號解讀

 

對於數據庫軟件版本來說目前實際應用還是11g為主10g逐步退役11gR2目前最新穩定版本為11.2.0.410gR2為10.2.0.5。

 

Oracle版本描述在11g、12c沒有變化但是和10g略有一些差異如下圖。

 

20170303095446126.jpg

 

  • 第一個數字位代表的是一個新版本軟件也標誌著一些新的功能。如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一個基本的情況如下圖所示。

 

20170303095545390.jpg

 

我們為什麼要開始考慮大規模升級到Oracle12cR2呢

 

看看下麵這個表格生產上現在最大裝機量的11.2.0.4將在2020年12月31日就不再發布任何補丁支持其實對於大部分用戶來說截止日期可以認為是2018年12月31日因為你後麵不付昂貴的延長支持費即使有補丁你也下載不了

 

20170303095552336.jpg

 

也就是說滿打滿算你還有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%。

 

下麵看到這兩個圖

 

20170303095609276.jpg

 

上圖是所有的數據庫參數下圖是開放給我們的參數可以明顯地看到數據庫參數的增長情況。以12c為例12cR2中的所有參數包括隱含參數有4845個而通過show parameter開放給我們的參數卻隻有417個這個比例非常低也可以進一步說明Oracle中確實有非常多的潛在豐富的設置很多都可以通過隱含參數來特殊調整而另一方麵由此也可以看出隱含參數如此之多複雜度極高本身還是不建議輕易修改隱含參數的因為很多隱含參數的值是默認的最優值有些還有關聯關係。 

 

20170303095617207.jpg

 

而不同數據庫版本中參數的數量占比是如何呢我們看一下10g、11g、12c的參數占比圖。綠色部分是12c的參數數據庫參數開放參數+隱含參數占比甚至超過了10g+11g的總和。

 

20170303095625309.jpg

 

而開放的參數在12cR2中保留了相當的空間其中參數增長部分主要體現在IMO和PDB兩個方麵我們下麵會展開來說。

 

20170303095632639.jpg

 

12c有哪些亮點值得我們去用

 

首當其衝的當然是Oracle In Memory Option。社群之前發表過幾篇文章不摘錄了使用了列式內存存儲性能提高極大非常有誘惑力

 

 

其次多租戶對於有幾十上百個小數據庫的部門或者公司來說這是一大福音趕緊整合、雲化吧。我們從2014年開始做這種雲化的工作確實節約了不少成本而且也方便了管理。社群相關文章可以複習下

 

 

第三點是12cR2才推出的Sharding。Oracle的Sharding可以認為是patition思想的升級版一脈相承。上麵賣了一個關子的GDS組件就是為了sharding而生的。有了shardingOracle一直被詬病缺失的分布式數據庫終於出台了。從個人練習使用的情況來看非常簡單易用而真正的生產實踐還敬請期待。

 

當然12cR2還有許多小的改進但是有此三點已經是足夠充分的理由去考慮升級了。

 

說到升級可不是個小事情而是一個大工程。

 

20170303095639680.jpg

 

從前期的調研分析、方案製定、升級測試到正式升級環環相扣疏忽不得。

具體的升級方法可參考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


最後更新:2017-05-15 10:03:56

  上一篇:go  加密勒索事件防護
  下一篇:go  數千台MySQL數據庫遭黑客比特幣勒索,該怎麼破?