504
Oracle Database 12.2新特性詳解
在2015年舊金山的Oracle OpenWorld大會上，Oracle發布了Database 12.2的Beta版本，雖然Beta版本隻對部分用戶開放，但是大會上已經公布了12.2的很多重要的新特性，雲和恩墨是Oracle的Beta用戶，已經開始測試這一產品。在剛剛結束的“Oracle技術嘉年華”大會上，更詳細的主題分享披露了更多內容。在這篇文章中，我將和大家一一來細數Oracle Database 12.2的新特性。
Oracle Sharding的實現
簡單來說，Oracle的Sharding技術就是通過分區（Partioning）技術的擴展來實現的。以前一個表的分區可以存在於不同的表空間，現在可以存在於不同的數據庫。
不同分區存在於不同數據庫，這就將數據隔離了開來，Sharding就此實現。
Sharding如何實現數據路由？
既然數據被拆分，那麼在訪問時如何實現數據路由呢？在Sharding的架構裏，存在一個“Shard Directories”目錄庫來管理Sharding的分布，當應用通過Sharding Key來訪問數據時，連接池就會給出訪問路徑，快速指向需要訪問的Shard。如果應用不指定分區鍵訪問，則需要通過協調庫-Coordinator DB來協助判定。
那麼這裏提到的連接池是什麼呢？
可能很少有人注意到，在Oracle 12.1版本中增加的一個新的產品組件 GDS - Global Data Services，通過GDS可以構建一個訪問“連接池”，為後端的數據庫訪問提供代理和路由服務，前麵提到的Shard Directories，正是在GDS中配置的。
如何創建Sharding數據表？
在創建Sharding對象之前，需要先創建表空間集合 - Tablespace Set，表空間集合包含在不同數據庫中的表空間定義，也就是將以前針對不同分區創建的表空間轉移到不同的數據庫中。
如何配置連接池？
關於連接池的配置，實際上在GDS的文檔中，早有描述，以下圖中則詳細描述了Sharded Database的部署，其中最先創建的是shardcatalog，創建了一個Shard的目錄配置數據庫，而GSM - Global Service Managment，就是全局的服務管理配置。
關於GDS的配置，以下一圖 - 一目了然：
如果在12.1中還看不清楚 GDS的作用，現在12.2中，Sharding中的重要作用就日益凸現出來。
Oracle的多租戶與IMO組件更新
多租戶選件為雲而生，也就不斷向著雲的便利性、自動化邁進。在12.2中多租戶支持更多的PDB共存，從上個版本中的252增加到4096個；在便利性上，支持Hot Clone,支持Refresh，支持在線的Tenent轉移。PDB的Hot Clone可以讓數據庫在業務負載運行時進行Clone拷貝，並且實時同步變化數據，從而使得數據不斷追平，進而實現在線切換，這極大的改善了上雲的遷移過程。對用戶來說是簡化，並且在OEM的管理之下，所有工作可以近乎自動的完成。
In-Memory Option在12.2上也獲得了增強，這一特性在ADG上的增強使得讀寫進一步分離，由於ADG的隻讀屬性，備庫上的內存數據又可以和主庫不同，比如備庫在內存中可以存儲更廣泛的數據，實現實時計算。而在性能和易用性上改進也值得稱道，In-Memory在12.2中支持根據熱圖自動向內存進行數據轉移，也可以動態的清除冷數據以釋放內存空間，簡化用戶管理。
那些溫暖人心的細節改進
除了以上這些大的改進，Oracle在DataGuard的細節上也不斷增強，同樣溫暖人心。
-
DBCA備庫創建 - 在備庫主機安裝軟件啟動監聽，則可以通過DBCA來創建備庫，指向主庫來獲取文件；
以前DataGuard的創建已經非常簡化，RMAN的操作也很精簡，現在DBCA也被利用起來，更方便容易了，夠體貼吧？
-
口令文件維護 - 標題中用了“Headache”，可見以前多頭疼
以前大家可能都被口令文件的變更坑過，現在這一切自動維護了，夠溫暖吧？
-
AWR支持遠程快照 - AWR支持捕獲遠程數據庫的信息，包括ADG
要知道在之前的ADG中，備庫隻能通過Statspack來進行性能分析和診斷，現在可以支持AWR了，夠高級吧？
-
連接保持 - 在進行DataGuard切換過程中，保持會話連接
對於ADG，終於，Oracle自己人也說“終於”，實現了Failover、SwitchOver中的連接會話保持，這極大的改善了用戶體驗，夠給力吧？
-
自動塊修複增強 - ADG自動塊修複自11gR2引入，現在已經非常成熟，修複的類型大大增加；
-
12.2 DataGuard中並行日誌應用
要知道在12.2之前，DG的備庫隻能由一個實例通過MRP進程進行應用，現在可以在多實例並行進行。
在8節點的RAC環境中，可以實現3500MB+/sec的應用速度，這極大的改善了大數據量備庫環境中的同步效率。
多實例應用，可以在所有Mounted或者Open的實例上並行進行，在執行Recover時，類似如下一條命令即可指定並行的恢複實例：
recover managed standby database disconnect using instances 4;
我們可以對比一下單實例應用和多實例應用的架構對比，在常規模式下，多實例的備庫，可以有多個Remote File Server (RFS)進程進行Redo Thread的日誌接收，但是僅有一個實例進行Managed Recovery Process (MRP)應用恢複：
當然，在單個實例上，仍然可以啟動多個MRP進程，進行並行的恢複，以下引自官方文檔：
The managed recovery process (MRP) applies archived redo log files to the physical standby database, and automatically determines the optimal number of parallel recovery processes at the time it starts. The number of parallel recovery slaves spawned is based on the number of CPUs available on the standby server.
在PayPal的分享的“Internals About DataGuard”中，有一頁關於MRP在RAC上的描述可以供參考（關注公眾號回複“PayPal”可以獲得本文檔）：
在Oracle 12.2 的版本中，多實例並行MRP恢複被支持，以下架構圖詳細說明了這一改進。通過一個Coordinator進程進行協同，多個MRP進行可以並行進行Redo Apply。
這一改變將極大的提升DataGuard的效率和可用性：
這是否又一溫暖人心的特性增強？
在RDBMS數據庫中，Oracle無論在大處的張揚，還是小處的體貼，都讓人越來越喜愛這個產品。雲時代，一起加油吧。
文章轉自數據和雲公眾號，原文鏈接
最後更新：2017-07-18 11:04:00