在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無論在大處的張揚，還是小處的體貼，都讓人越來越喜愛這個產品。雲時代，一起加油吧

Oracle Database 12.2新特性詳解 --該國強

相關文章