sybase 的應(yīng)用到底在哪里？？

D_D_D_D

不是SYBASE慢,而是編的應(yīng)用程序有問(wèn)題?大多數(shù)在SYBASE上的應(yīng)用都有跳不出這個(gè)怪圈!不明白為什么?
WFCJZ 發(fā)表于 2008-12-08 15:22

    同意，可能因?yàn)檎�體成本低，使用的服務(wù)器，盤陣，開(kāi)發(fā)人員素質(zhì)都要差一個(gè)檔次，我們就有較深的體會(huì)，同樣跑sybase，在相同配置的IBM和SUN上，AIX 5.2的穩(wěn)定性和維護(hù)成本真的明顯優(yōu)sloaris 10，但我們用SUN的東西最多，哎......

sybfresher

又看了一遍你之前的例子，我認(rèn)為就是Read Uncommitted，O和S兩個(gè)廠商在對(duì)隔離級(jí)別為0時(shí)對(duì)事物采取 ...
D_D_D_D 發(fā)表于 2010-08-16 12:34

    你親自去試一下，你會(huì)發(fā)現(xiàn)的確是不一樣的 ， Oracle并不是贓讀。   我特意查了一下，現(xiàn)在MS SQL Server也有了類似“快照”的隔離級(jí)別， 而ASE仍然沒(méi)有。

andkylee

回復(fù) 32# sybfresher


    因?yàn)閛racle有redo和undo兩種日志，而sybase僅有一種單線的日志序列。

shakeone

Datarows類型的表可以不會(huì)出現(xiàn)我舉的那個(gè)insert掛住的例子，但是，如果session1是對(duì)某些行數(shù)據(jù)進(jìn) ...
sybfresher 發(fā)表于 2010-08-14 16:19

    你說(shuō)應(yīng)該是isolation level 1 (read committed)下sybase和oracle的不同表現(xiàn)吧，一個(gè)update在一個(gè)row，另外一個(gè)scan到這個(gè)row上，sybase會(huì)block這個(gè)scan，等待到update完成。oracle對(duì)這個(gè)scan會(huì)返回update前的內(nèi)容，因?yàn)樗麄兊膍vcc技術(shù)可以找到修改前的數(shù)據(jù)，可能是通過(guò)cache或者log來(lái)實(shí)現(xiàn)的，所以不會(huì)block

xjtuhuth

回復(fù) 34# shakeone


    ASE 提供了readpast locking (read uncommited)， 這樣的話session1的update不會(huì)阻塞session2的select, 只是session 2的select skip all rows that have exclusive locks on them(臟讀)：

session1:
1> begin tran
2> update test set col1=1
3> go
(1 row affected)
1>


session 2:
1> select * from test readpast
2> go
col1
-----------

(0 rows affected)

xjtuhuth

回復(fù) 32# sybfresher


    IQ里有 MVCC

shakeone

回復(fù)  shakeone


    ASE 提供了readpast locking (read uncommited)， 這樣的話session1的update不會(huì) ...
xjtuhuth 發(fā)表于 2010-08-17 16:49

    恩，我知道，但sybfresher意思應(yīng)該是read committed的情況下的表現(xiàn)

xjtuhuth

回復(fù) 37# shakeone


    我有些疑問(wèn)：為什么datarow的lock schema可以避免insert的情況？如果沒(méi)有MVCC的話update阻塞的情況就不可能解決么？既然IQ都有MVCC，ASE為什么不實(shí)現(xiàn)呢？

shakeone

回復(fù) 38# xjtuhuth


insert的問(wèn)題：apl屬于all page locking,所以這個(gè)page被加上了事務(wù)級(jí)別的互斥鎖，就是說(shuō)等這個(gè)事務(wù)結(jié)束這個(gè)page才能被別的事務(wù)加上鎖。如果是dol的話，insert會(huì)產(chǎn)生一個(gè)新的row，對(duì)應(yīng)有一個(gè)新的row id，所以datarows locking會(huì)鎖住這個(gè)row id，對(duì)其他row沒(méi)有任何影響，所以不會(huì)有apl有的問(wèn)題。
另外說(shuō)一句，如果session 2是isolation level 3, insert也會(huì)block這個(gè)scan，因?yàn)閘evel 3防止幻影行的出現(xiàn)。

update的“問(wèn)題”可以說(shuō)是個(gè)問(wèn)題，也可以說(shuō)不是，因?yàn)閟ybase ase是嚴(yán)格按照sql標(biāo)準(zhǔn)的isolation level來(lái)實(shí)現(xiàn)的，所以阻止別的事務(wù)讀一個(gè)正在更新的數(shù)據(jù)是符合標(biāo)準(zhǔn)的，如果要改成那種返回更新前的數(shù)據(jù)或者是臟數(shù)據(jù)的話，ase的投行大客戶們一定會(huì)給我們發(fā)priority 80以上的change request的。所以這個(gè)被認(rèn)為不是問(wèn)題，也就沒(méi)有加入mvcc的必要了。

話說(shuō)mvcc這個(gè)項(xiàng)目應(yīng)該早就做了，本來(lái)是打算用到cluster里面的，后來(lái)不知道印度的同事們移植進(jìn)去了沒(méi)有。

xjtuhuth

回復(fù) 39# shakeone


    個(gè)人覺(jué)得可以把MVCC加進(jìn)ASE, 默認(rèn)是disable的，如果要用的話可以打開(kāi)。