原文：http://www.talkwithtrend.com/Article/178339

數(shù)據(jù)庫建設(shè)過程中，高可用是每一個企業(yè)數(shù)據(jù)中心數(shù)據(jù)庫建設(shè)過程中至關(guān)重要的一個關(guān)注點，直接關(guān)系到業(yè)務連續(xù)性和穩(wěn)定性。要想將這個工作做好，我們必須從其底層原理、機制、架構(gòu)等方面進行深入了解，深入分析，深入對比才能知道我們應該如何去實踐。下面的幾個關(guān)鍵點，不僅僅是每一個DBA應該琢磨的事情，同時也是搞企業(yè)IT架構(gòu)規(guī)劃和建設(shè)的人必須了解和知道的事情。

下面總結(jié)了一些Oracle與DB2在數(shù)據(jù)庫高可用技術(shù)上的相同與差異的一些典型問題和困惑，幫助大家更好地去理解這兩者之間的差異。

具體如下：

數(shù)據(jù)庫對象配置的差異。

數(shù)據(jù)庫高可用的配置。

數(shù)據(jù)庫存儲機制的差異。

數(shù)據(jù)庫容災技術(shù)的差異。

數(shù)據(jù)庫鎖機制的差異。

一、關(guān)于數(shù)據(jù)庫對象概念等方面的差異？

觀點一、
DB2類似管理容器的概念，是一個實例下可以有多個數(shù)據(jù)庫，各庫互相獨立。Oracle是一個實例只能運行一個數(shù)據(jù)庫，一個數(shù)據(jù)庫在群集環(huán)境下可運行于多個實例下，類似運行機的概念。

觀點二、
DB2的instance和database是一對多的關(guān)系，即一個實例下面可以有多個數(shù)據(jù)庫；ORACLE的instance和database是一對一的關(guān)系。

二、關(guān)于數(shù)據(jù)庫仲裁機制及原理差異？

ORACLE仲裁算法：

有兩個非常重要的規(guī)則：1. 保障隔離后的集群子集中節(jié)點數(shù)目最多的子集存活。2. 當隔離后的集群子集獲得的仲裁票數(shù)相等時，保障實例號小者存活。

mysql galera 的仲裁機制：

當集群出現(xiàn)故障的時候，galera cluster會啟動特別的仲裁算法來選舉一個節(jié)點作為主節(jié)點，集群里成員的數(shù)量決定了quorum仲裁的投票數(shù)（最好是單數(shù)），當一個節(jié)點出現(xiàn)故障不再屬于集群的時候，galera就會啟動一次仲裁選舉。默認設(shè)置是5秒。galera有獨立的進程叫做garbd來做仲裁者Arbitrator
galera仲裁者是集群的一員，參與投票，但不真正參與復制。
galera仲裁者的設(shè)立出于以下兩個目的：
1、偶數(shù)節(jié)點時，仲裁者作為一個節(jié)點使集群成為奇數(shù)，從而避免腦裂
2、它可以請求一個連續(xù)的應用狀態(tài)快照，可用來做備份
盡管仲裁者不存數(shù)據(jù)，它必須能夠流經(jīng)所有的復制流，所以把仲裁者放在一個和其他節(jié)點網(wǎng)絡(luò)連接差的網(wǎng)絡(luò)環(huán)境里會導致整個cluster的性能變差。仲裁者倒了并不會影響cluster的操作，可以在任何時間掛一個新的節(jié)點上去

db2 purescale的仲裁機制：

采用的是NODE QUORUM + TieBreaker的方式進行仲裁，對于集群節(jié)點<=2的情況下，宕掉一個節(jié)點，只要仲裁盤狀態(tài)正常也是可以正常工作的。

三、如何看待各個關(guān)系數(shù)據(jù)庫對存儲利用的原理和機制？

觀點一（oracle）、
ASM有自動條帶化和鏡像的能力，減輕管理負擔，而且存儲的操作不必每次再和系統(tǒng)管理員約時間創(chuàng)建lv了！性能沒覺得比裸設(shè)備好太多，主要是可用性以及和集群的兼容性。

觀點二（db2）、
1.文件系統(tǒng)的話在aix上是基于jfs或jfs2來管理的,性能受到文件系統(tǒng)本身的塊化結(jié)構(gòu)所限制。2.裸設(shè)備影射的話就交由存儲來管理,性能主要由存儲緩存和通訊接口比如說光纖接口,交換機,還有服務器接口限制.還有一個非常重要的地方就是oracle ASM的failure group機制做的非常好，保障了靈活的高可用機制。db2結(jié)合GPFS也是一個非常好的解決方案，但是GPFS畢竟是文件系統(tǒng)映射之后提供給db2的容器，性能上還是不如ASM直接。個人理解。

觀點三（oracle）、
Asm實現(xiàn)了的主機層面文件系統(tǒng)，裸設(shè)備等存儲資源的自動管理和優(yōu)化工作，降低了dba對lvm的管理和性能調(diào)優(yōu)的成本。直接的lvm管理就是需要dba定制化的對fs，lv，VG等對象的設(shè)計和對最底層存儲的磁盤陣列的設(shè)計。

四、數(shù)據(jù)庫容災中的數(shù)據(jù)復制原理？

oracle：
oracle的dataguard同步方式有兩種，一種是同步，一種異步。下面先來說下DG的原理：
當用戶在主庫提交數(shù)據(jù)的時候，會在sga的redo緩沖區(qū)中首先記錄redo信息，在提及操作的時候lgwr會將redo數(shù)據(jù)寫入redo數(shù)據(jù)文件中，那么這個時候lns進程會實時的將redo數(shù)據(jù)從主庫的redo緩沖區(qū)傳送到備庫，在備庫使用rfs接受數(shù)據(jù)，傳入standby logfile中，進而應用redo數(shù)據(jù)（sql apply）。在應用完成后rfs將信息返回主庫進程，告知該redo條目已經(jīng)在備庫應用完畢，lgwr收到lns的確認消息，從而提示提交成功。
在最高可用性中，如果主庫收不到備庫應用的確認消息，那么會通過net_timeout值超時，繼續(xù)完成本次操作，那么lns進程將不會在獲得sga中的重做數(shù)據(jù)，只有當下次日志switch的時候才主動去嘗試獲得lns數(shù)據(jù)，如果期間還是沒有和備庫完成通信，當超過net_timeout參數(shù)的時候會繼續(xù)停止，主機事務也繼續(xù)完成，但當存在于最大保護模式下，那么必須等到備庫應用redo的確認消息，那么就會停止數(shù)據(jù)庫的運行操作。

db2：
非purescale環(huán)境的DB2 HADR有四種復制模式SYNC,NEARSYNC,ASYNC,SUPERSYNC; oracle支持三個模式最高性能，最高保護，最高可用性,可以歸納為兩種模式SYNC,ASYNC，我覺得DB2在這一塊劃分的更細些。兩種數(shù)據(jù)庫的復制原理來講都是基于capture log--->TCP傳輸---->REDO log這樣一個過程。
最佳參照文章：
https://www.ibm.com/developerworks/cn/data/library/techarticles/dm-1010baosf/

五、關(guān)于數(shù)據(jù)庫鎖機制？

觀點一、
Oracle是通過SCN實現(xiàn)多版本并發(fā)控制，并且是基于頁面粒度。
Db2，舊的版本似乎是有讀一致性鎖存在，而且是靠Locklist來實現(xiàn)鎖的管理。后期版本似乎是有MVCC的。
Oracle：
1 寫redo。
2 寫undo。
3 修改數(shù)據(jù)。

這個時候，讀請求實際是可以從undo中讀取歷史版本的。

觀點二、
ORACLE的并發(fā)機制使用的是不同類型的鎖來控制.
有數(shù)據(jù)方面的鎖比如TM,TX
也有內(nèi)存方面的鎖 比如 LATCH,MUTEX,LOCK
另外TM,TX不是真實的鎖, 里面還有個叫鎖模式的才是真的鎖,NULL,X,S
TM,TX及其他的是排隊機制的結(jié)構(gòu)體.
不過通俗地,大家都把TM,TX都叫成鎖了.我就不在糾正了.
因此ORACLE鎖不是負擔,沒有相應的管理成本! 在這一點上MS SQLSERVER不如ORACLE

民生銀行牛總的文章引用：
https://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0512niuxzh/

轉(zhuǎn)載于:https://www.cnblogs.com/liujiacai/p/9313018.html

總結(jié)

以上是生活随笔為你收集整理的(转)Oracle与DB2在数据库高可用技术上的相同与差异探讨的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。