(轉)Oracle與DB2在數據庫高可用技術上的相同與差異探討
原文：http://www.talkwithtrend.com/Article/178339
數據庫建設過程中，高可用是每一個企業數據中心數據庫建設過程中至關重要的一個關註點，直接關系到業務連續性和穩定性。要想將這個工作做好，我們必須從其底層原理、機制、架構等方面進行深入了解，深入分析，深入對比才能知道我們應該如何去實踐。下面的幾個關鍵點，不僅僅是每一個DBA應該琢磨的事情，同時也是搞企業IT架構規劃和建設的人必須了解和知道的事情。
下面總結了一些Oracle與DB2在數據庫高可用技術上的相同與差異的一些典型問題和困惑，幫助大家更好地去理解這兩者之間的差異。
具體如下：
- 數據庫對象配置的差異。
- 數據庫高可用的配置。
- 數據庫存儲機制的差異。
- 數據庫容災技術的差異。
- 數據庫鎖機制的差異。
一、關於數據庫對象概念等方面的差異？
觀點一、
DB2類似管理容器的概念，是一個實例下可以有多個數據庫，各庫互相獨立。Oracle是一個實例只能運行一個數據庫，一個數據庫在群集環境下可運行於多個實例下，類似運行機的概念。
觀點二、
DB2的instance和database是一對多的關系，即一個實例下面可以有多個數據庫；ORACLE的instance和database是一對一的關系。
二、關於數據庫仲裁機制及原理差異？
ORACLE仲裁算法：
有兩個非常重要的規則：1. 保障隔離後的集群子集中節點數目最多的子集存活。2. 當隔離後的集群子集獲得的仲裁票數相等時，保障實例號小者存活。
mysql galera 的仲裁機制：
當集群出現故障的時候，galera cluster會啟動特別的仲裁算法來選舉一個節點作為主節點，集群裏成員的數量決定了quorum仲裁的投票數（最好是單數），當一個節點出現故障不再屬於集群的時候，galera就會啟動一次仲裁選舉。默認設置是5秒。galera有獨立的進程叫做garbd來做仲裁者Arbitrator
galera仲裁者是集群的一員，參與投票，但不真正參與復制。
galera仲裁者的設立出於以下兩個目的：
1、偶數節點時，仲裁者作為一個節點使集群成為奇數，從而避免腦裂
2、它可以請求一個連續的應用狀態快照，可用來做備份
盡管仲裁者不存數據，它必須能夠流經所有的復制流，所以把仲裁者放在一個和其他節點網絡連接差的網絡環境裏會導致整個cluster的性能變差。仲裁者倒了並不會影響cluster的操作，可以在任何時間掛一個新的節點上去
db2 purescale的仲裁機制：
采用的是NODE QUORUM + TieBreaker的方式進行仲裁，對於集群節點<=2的情況下，宕掉一個節點，只要仲裁盤狀態正常也是可以正常工作的。
三、如何看待各個關系數據庫對存儲利用的原理和機制？
觀點一（oracle）、
ASM有自動條帶化和鏡像的能力，減輕管理負擔，而且存儲的操作不必每次再和系統管理員約時間創建lv了！性能沒覺得比裸設備好太多，主要是可用性以及和集群的兼容性。
觀點二（db2）、
1.文件系統的話在aix上是基於jfs或jfs2來管理的,性能受到文件系統本身的塊化結構所限制。2.裸設備影射的話就交由存儲來管理,性能主要由存儲緩存和通訊接口比如說光纖接口,交換機,還有服務器接口限制.還有一個非常重要的地方就是oracle ASM的failure group機制做的非常好，保障了靈活的高可用機制。db2結合GPFS也是一個非常好的解決方案，但是GPFS畢竟是文件系統映射之後提供給db2的容器，性能上還是不如ASM直接。個人理解。
觀點三（oracle）、
Asm實現了的主機層面文件系統，裸設備等存儲資源的自動管理和優化工作，降低了dba對lvm的管理和性能調優的成本。直接的lvm管理就是需要dba定制化的對fs，lv，VG等對象的設計和對最底層存儲的磁盤陣列的設計。
四、數據庫容災中的數據復制原理？
oracle：
oracle的dataguard同步方式有兩種，一種是同步，一種異步。下面先來說下DG的原理：
當用戶在主庫提交數據的時候，會在sga的redo緩沖區中首先記錄redo信息，在提及操作的時候lgwr會將redo數據寫入redo數據文件中，那麽這個時候lns進程會實時的將redo數據從主庫的redo緩沖區傳送到備庫，在備庫使用rfs接受數據，傳入standby logfile中，進而應用redo數據（sql apply）。在應用完成後rfs將信息返回主庫進程，告知該redo條目已經在備庫應用完畢，lgwr收到lns的確認消息，從而提示提交成功。
在最高可用性中，如果主庫收不到備庫應用的確認消息，那麽會通過net_timeout值超時，繼續完成本次操作，那麽lns進程將不會在獲得sga中的重做數據，只有當下次日誌switch的時候才主動去嘗試獲得lns數據，如果期間還是沒有和備庫完成通信，當超過net_timeout參數的時候會繼續停止，主機事務也繼續完成，但當存在於最大保護模式下，那麽必須等到備庫應用redo的確認消息，那麽就會停止數據庫的運行操作。
db2：
非purescale環境的DB2 HADR有四種復制模式SYNC,NEARSYNC,ASYNC,SUPERSYNC; oracle支持三個模式最高性能，最高保護，最高可用性,可以歸納為兩種模式SYNC,ASYNC，我覺得DB2在這一塊劃分的更細些。兩種數據庫的復制原理來講都是基於capture log--->TCP傳輸---->REDO log這樣一個過程。
最佳參照文章：
https://www.ibm.com/developerworks/cn/data/library/techarticles/dm-1010baosf/
五、關於數據庫鎖機制？
觀點一、
Oracle是通過SCN實現多版本並發控制，並且是基於頁面粒度。
Db2，舊的版本似乎是有讀一致性鎖存在，而且是靠Locklist來實現鎖的管理。後期版本似乎是有MVCC的。
Oracle：
1 寫redo。
2 寫undo。
3 修改數據。
這個時候，讀請求實際是可以從undo中讀取歷史版本的。
觀點二、
ORACLE的並發機制使用的是不同類型的鎖來控制.
有數據方面的鎖比如TM,TX
也有內存方面的鎖 比如 LATCH,MUTEX,LOCK
另外TM,TX不是真實的鎖, 裏面還有個叫鎖模式的才是真的鎖,NULL,X,S
TM,TX及其他的是排隊機制的結構體.
不過通俗地,大家都把TM,TX都叫成鎖了.我就不在糾正了.
因此ORACLE鎖不是負擔,沒有相應的管理成本! 在這一點上MS SQLSERVER不如ORACLE
民生銀行牛總的文章引用：
https://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0512niuxzh/
(轉)Oracle與DB2在數據庫高可用技術上的相同與差異探討