售前資料——sybase 15.7 與 oracle 10g 對比——核心結(jié)構(gòu)的對比

jiachunzhou

核心結(jié)構(gòu)的對比
Oracle
Oracle 公司數(shù)據(jù)庫產(chǎn)品最早在主機系統(tǒng)實現(xiàn)，由于主機硬件資源充裕，因此Oracle在軟件設(shè)計上較少考慮硬件的開銷，所以基于多進程體系構(gòu)造DBMS核心結(jié)構(gòu)。隨著80年代Client/Server結(jié)構(gòu)的產(chǎn)生，Oracle公司將其數(shù)據(jù)庫系統(tǒng)移植到Client/Server平臺，為其核心增加了多線索的機制，但這種多線索機制僅僅是為了容納更多的用戶連接數(shù)，于服務(wù)器性能和并行度沒有任何提高（摘自O(shè)racle performance tuning guide）, 通過在Instance中預(yù)置一定數(shù)量的專用進程，用戶連接和數(shù)據(jù)訪問以隊列方式使用進程，事實上任何對數(shù)據(jù)庫的操作都以進程方式實現(xiàn)，由于進程對系統(tǒng)的開銷遠遠大于線程的開銷，同時進程切換的速度也遠遠低于線程切換速度，因此造成了Oracle 數(shù)據(jù)庫對系統(tǒng)的硬件尤其是內(nèi)存資源要求很高，在同樣硬件平臺上的運行速度較其它數(shù)據(jù)庫（均為單進程多線索內(nèi)核）為慢， Oracle數(shù)據(jù)庫難于管理多CPU系統(tǒng)，如果任何一個系統(tǒng)進程停止運行，將導致系統(tǒng)停滯。由于數(shù)據(jù)庫核心處理能力及并行能力的不足， 因此Oracle 試圖通過OPS，RAC等技術(shù)彌補其并行處理能力的缺陷。

Sybase
Sybase數(shù)據(jù)庫高效的多線索體系結(jié)構(gòu)提供強有力的可伸縮性能力和性能, 多線索體系結(jié)構(gòu)要比傳統(tǒng)的多進程結(jié)構(gòu)切換速度快，占用內(nèi)存資源少。針對1M內(nèi)存，采用多線索技術(shù)可支持20個線索；而多進程技術(shù)只能支持1～4個進程。線索之間的調(diào)度切換僅需100～200條CPU指令，而進程之間的切換則需要1000～2000條指令。因此多線索技術(shù)從資源的占用和調(diào)度切換速度上都有相當優(yōu)勢，可充分滿足應(yīng)用所需的吞吐量和響應(yīng)時間。同時ASE能夠在SMP系統(tǒng)中配置產(chǎn)生多個引擎，甚至允許在所有引擎之間進行分布式的客戶連接。引擎也處理自己的磁盤訪問，對于增加的用戶數(shù)提供了近似線性的性能伸縮性。

2BeSybPro

核心結(jié)構(gòu)必須提到transaction processing etc，Oracle的transaction processing與Sybase不在一個數(shù)量級, Oracle的MVCC/non-blocking是以犧牲事務(wù)處理為高昂代價的。In Oracle, one transaction must be written to at least two places (redo/undo)。你去問問Tom (asktom.oracle.com)，在Oracle中rollback是需要多么慎重的一件事，但trading system中rollback經(jīng)常發(fā)生。

Eisen

是啊，這個售前資料拿最新的ase15.7去和oracle n多年前的老版本10g作比較真不是個好主意，還是得從transanction設(shè)計以及oracle為了multi version 而設(shè)計出的scn號導致scn會用光致使無法支持巨量transaction這些本質(zhì)性問題上做比較。

zhangyh123

市場占有率說明一切 sybase 差oracle 十年

zhangyh123

[ 本帖最后由 zhangyh123 于 2013-01-12 02:41 編輯 ]

[quote][size=2][color=#000]Eisen 發(fā)表于 2013-01-11 21:32[/color] [url=forum.php?mod=redirect&goto=findpost&pid=23756657&ptid=4062032][img]static/image/common/back.gif[/img][/url][/size]
是啊，這個售前資料拿最新的ase15.7去和oracle n多年前的老版本10g作比較真不是個好主意，還是得從transanc ...[/quote]

SCN 這個只是個BUG而已 , 哪個數(shù)據(jù)庫不是一堆BUG :D  

Oracle使用6 Bytes記錄SCN，也就是48位，其最大值是：

    SQL> col scn for 999,999,999,999,999,999
    SQL> select power(2,48) scn from dual;
              SCN
------------------------
     281,474,976,710,656  大約可以用數(shù)百年時間

2BeSybPro

Oracle數(shù)據(jù)庫結(jié)構(gòu)設(shè)計有很大硬傷，是沒辦法改的。略舉幾例。
1、MVCC/Non-blocking是以犧牲事務(wù)性能為代價的，一條事務(wù)必須寫幾個地方。
2、不能提供實時數(shù)據(jù)，有更改的情況下只能提供快照，用過Oracle的人都知道ORA-01555 snapshot too old。一只股票前后一秒價差1分，快照很容易導致一筆交易差成千上萬的。Wall Street交易系統(tǒng)不愿用Oracle，就是這個原因。
3、舊石器時代的鎖機制，極大地降低了事務(wù)性能。Oracle locks are not in-memory structures and are attributes of the data itself instead, so Oracle has to go to the rows to find out what rows are locked。
.... (please see http://talussoftware.com/DBPowerSuite/index.html for Oracle facts, most of them still apply)

以前一提到這些東西，Oracle fans就以market share說事。在SAP的大力推廣下，Sybase市場份額正節(jié)節(jié)上升，Oracle壓力山大了。

Eisen

怎么說呢? SCN耗盡這可以說是個Bug,但這個bug怕是沒法修復(fù)的,因位這是個基于系統(tǒng)基本設(shè)計引出的結(jié)果。不過也可以說是一種產(chǎn)品feather。
另外，誠如2BeSybPro大哥所言，Oracle到現(xiàn)在也沒有一個全創(chuàng)新的基本架構(gòu)出現(xiàn)這個才是oracle的根本問題。
至于market share ... 唉，10年前的Sybase不也就這樣是死在market share導致的自滿自得上啊。

zhaopingzi

未來方向都是分布式，云數(shù)據(jù)庫，云計算了

hefan

慚愧啊，Oracle還是半桶水，混了個OCP，貌似就rman用過。

手頭要學的東西太多了。小機、存儲、備份、數(shù)據(jù)倉庫，抽取工具。。。。沒法啊

fuchen.w

你懂多少oracle？

回復(fù) 2# 2BeSybPro