理論上來說rac恢復(fù)到單實例， 在實例恢復(fù)比RAC有優(yōu)勢無需凍結(jié)。然后三節(jié)點以上情況下，對于多實例更新同一個數(shù)據(jù)塊寫操作比RAC需要的通信更少。在 12.1.0.2之前，比RAC即便使用的RDS仍然有更加減少上下文切換的優(yōu)勢。 12.1.0.2在上通過達到和采用uDAPL一樣的無需上下文切換和中斷的跨節(jié)點通信方式。
其OLTP劣勢在于如果讀別的節(jié)點 cache有的數(shù)據(jù)，必須通過CF，而RAC可以直接通信，不需要CF參與。此外CF成為一個性能瓶頸，SAP的公開測試在進行批處理的時候，CF的CPU耗盡而數(shù)據(jù)庫節(jié)點只能壓倒25%的情況而導(dǎo)致處理能力無法提升。此外如果CF宕機，的HA可能遇到很多麻煩的問題，例如切換時間會比RAC單實例宕還要長。
實際中的問題就更多了：例如案例太少，而IBM自己也嚴重擔(dān)心搶自己的 with Z的飯碗。這直接直接導(dǎo)致了其研發(fā)不給力。和單機版本的db2相比有太多限制，hadr備庫不可讀(是不是新版解決了？）,hadr備庫必須和主庫同結(jié)構(gòu)（節(jié)點數(shù)量一致），備份恢復(fù)需要拓撲結(jié)構(gòu)一樣（比如8節(jié)點備份沒法恢復(fù)到4節(jié)點環(huán)境rac恢復(fù)到單實例，這個不知道改進沒有）。reorg也相比單機有大量限制。然后只適合做OLTP，如果做DW/OLAP，沒法跨節(jié)點并行等等。做批處理會遇到CF性能瓶頸等等問題。
IBM最大的問題是這個公司整個戰(zhàn)略就瞎搞，數(shù)據(jù)庫產(chǎn)品一堆，自己先競爭的一塌糊涂，研發(fā)力量分散。
