亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標(biāo)題: sybase 的應(yīng)用到底在哪里？？ [打印本頁(yè)]

作者: byebeijing 時(shí)間: 2008-12-03 15:36
標(biāo)題: sybase 的應(yīng)用到底在哪里？？
看來應(yīng)用的不多啊

作者: chuxu 時(shí)間: 2008-12-03 16:35
什么意思？當(dāng)數(shù)據(jù)庫(kù)服務(wù)器呀

作者: RNW 時(shí)間: 2008-12-03 19:44
恩，不知道什么意思

作者: WFCJZ 時(shí)間: 2008-12-04 10:04
樓主可能說的是主要應(yīng)用在那些行業(yè)是吧.郵政,電信,商業(yè)流通,銀行,很多方面呀!不過大多市場(chǎng)都在采用ORACLE!

作者: RNW 時(shí)間: 2008-12-04 16:11
ORACLE賣的的確好啊

作者: tyrone.dev 時(shí)間: 2008-12-05 05:07
相比oracle,sybase的功能少了很多，而且許多功能都另外收費(fèi)。如果習(xí)慣了oracle，很難改到sybase上去。

作者: sesese 時(shí)間: 2008-12-07 15:05
sybase 對(duì)超大型數(shù)據(jù)庫(kù)應(yīng)用是否不太好?檢索比較慢。

作者: taker2001 時(shí)間: 2008-12-08 10:35
金融行業(yè)用得很多啊，我在外企銀行都是用sybase，紐約證券交易所都用sybase

作者: WFCJZ 時(shí)間: 2008-12-08 15:22

原帖由 sesese 于 2008-12-7 15:05 發(fā)表
sybase 對(duì)超大型數(shù)據(jù)庫(kù)應(yīng)用是否不太好?檢索比較慢。

不是SYBASE慢,而是編的應(yīng)用程序有問題?大多數(shù)在SYBASE上的應(yīng)用都有跳不出這個(gè)怪圈!不明白為什么?

作者: sybfresher 時(shí)間: 2008-12-10 23:17
就我最近使用Sybase來看，與Oracle相比，ASE有兩個(gè)比較致命的缺點(diǎn)：
1。很容易造成死鎖，導(dǎo)致性能下降
2。數(shù)據(jù)量大的情況下，性能下降嚴(yán)重
雖然一個(gè)系統(tǒng)性能的好壞，與上層應(yīng)用以及表結(jié)構(gòu)的設(shè)計(jì)有很大關(guān)系，但是不可否認(rèn)，上述兩點(diǎn)Sybase自身的問題也是為什么Sybase的市場(chǎng)逐漸流失的原因之一吧。
另外，軟件的易用性要好，畢竟，贏得了開發(fā)人員與維護(hù)人員，也是提高口碑最終占領(lǐng)市場(chǎng)的重要手段。

作者: chuxu 時(shí)間: 2008-12-11 08:09

原帖由 sybfresher 于 2008-12-10 23:17 發(fā)表
就我最近使用Sybase來看，與Oracle相比，ASE有兩個(gè)比較致命的缺點(diǎn)：
1。很容易造成死鎖，導(dǎo)致性能下降
2。數(shù)據(jù)量大的情況下，性能下降嚴(yán)重
雖然一個(gè)系統(tǒng)性能的好壞，與上層應(yīng)用以及表結(jié)構(gòu)的設(shè)計(jì)有很大關(guān)系， ...

1、你的意思是同樣的sql，在Sybase下容易產(chǎn)生死鎖，在oracle下不會(huì)？能否給出一個(gè)例子看一下？
2、數(shù)據(jù)量大的情況，是指單表的數(shù)據(jù)量大嗎？幾千萬行的表應(yīng)該處理檢索還好吧，如果超過億條，似乎應(yīng)該考慮一下是否該分表了。Oracle表記錄數(shù)的影響沒有實(shí)際測(cè)試過，最好也給一個(gè)實(shí)際的例子說明一下。

作者: sybfresher 時(shí)間: 2008-12-12 11:09
關(guān)于第一個(gè)問題，舉個(gè)最簡(jiǎn)單的例子。先看在Oracle中：
session1:
SQL> create table t200 (c1 int);

Table created.

SQL> insert into t200 values(100);

1 row created.

SQL> select * from t200;

      C1
----------
   100

此時(shí)沒有commit，在另外一個(gè)session2中查詢：
SQL> select * from t200;

no rows selected

可以看到，雖然session1中做的修改并沒有commit，但是session2并沒有被阻塞，可以正常查詢，只不過查詢到是session1修改前的數(shù)據(jù)。當(dāng)sessiion1中的事務(wù)commit之后，session2中再次運(yùn)行select * from t200，就會(huì)得出:
SQL> select * from t200;

      C1
----------
   100

我們?cè)倏纯碨ybase，同樣先在一個(gè)事務(wù)插入數(shù)據(jù)：
session1:
1> use test2
2> go
1> create table t200(c1 int)
2> go
1> begin tran
2> go
1> insert into t200 values(100)
2> go
(1 row affected)

此時(shí)在session2中查詢：

1> use test2
2> go
1> select * from t200
2> go
在這里被掛住了。。。。。。。。。。。。只有等待session1中的事務(wù)commit之后才能繼續(xù)。
這里雖然不是一個(gè)死鎖的例子，但是我相信Sybase與Oracle的這點(diǎn)差別導(dǎo)致sybase引起死鎖的概率比較大，性能也會(huì)有所下降。也許各有各的好處，是我理解不夠深刻，大家一起探討。

至于第二個(gè)問題，我并沒有什么具體數(shù)據(jù)。每個(gè)人心里都會(huì)有自己的一桿秤的。

作者: zhangyh123 時(shí)間: 2008-12-12 12:50
sybase 早不是 top5 的數(shù)據(jù)庫(kù)了

作者: sybfresher 時(shí)間: 2010-08-12 10:15
...

作者: hobbylu 時(shí)間: 2010-08-12 10:47
是top 1嘿嘿

作者: zq5143 時(shí)間: 2010-08-12 13:12
本帖最后由 zq5143 于 2010-08-12 13:15 編輯

Sybase的產(chǎn)品價(jià)格，售后服務(wù)比Oracle都有優(yōu)勢(shì)~！功能不像Oracle那樣All In One，你用多少功能就買多少功能，比如復(fù)制有專門的復(fù)制服務(wù)器，數(shù)據(jù)分析有專門的IQ。
關(guān)于鎖的問題，ASE12.5以后也都支持行鎖。只要應(yīng)用程序設(shè)計(jì)的沒問題，應(yīng)該沒問題的。中國(guó)鐵路售票系統(tǒng)用的就是Sybase的，想象一下你們春運(yùn)時(shí)買火車票時(shí)的情景，Sybase的性能也可想而知。

作者: Eisen 時(shí)間: 2010-08-12 22:42

關(guān)于第一個(gè)問題，舉個(gè)最簡(jiǎn)單的例子。先看在Oracle中：
session1:
SQL> create table t200 (c1 int);

...
sybfresher 發(fā)表于 2008-12-12 11:09

呵呵。這個(gè)例子我覺得舉得不恰當(dāng)，因?yàn)槟阌昧薕racle的那個(gè)樂觀鎖來比對(duì)Sybase的悲觀鎖。
你其實(shí)應(yīng)該在Oracle中使用select ... for update來比對(duì)，這才有可比性。

作者: sybfresher 時(shí)間: 2010-08-13 10:15
呵呵，樓上，不管用什么鎖，你能在sybase中實(shí)現(xiàn)我舉的oracle的功能嗎？

作者: wfcjz 時(shí)間: 2010-08-13 11:10

是top 1嘿嘿
hobbylu 發(fā)表于 2010-08-12 10:47

你就意淫吧！

作者: shakeone 時(shí)間: 2010-08-13 12:32

關(guān)于第一個(gè)問題，舉個(gè)最簡(jiǎn)單的例子。先看在Oracle中：
session1:
SQL> create table t200 (c1 int);

...
sybfresher 發(fā)表于 2008-12-12 11:09

你用的一定是APL的lock scheme吧？用dol不會(huì)出現(xiàn)這個(gè)問題的，話說dol都出來14年了，為什么不用dol呢？

作者: shakeone 時(shí)間: 2010-08-13 12:37
sybase的用戶都是jpmorgan, morgan stanley, goldman sachs, ubs, creidt suisse等各種金融巨頭。不過公司投入是有點(diǎn)保守，和oracle側(cè)重于大而全不同，ase側(cè)重于快，不過現(xiàn)在sap來了要求就更多了。

作者: shakeone 時(shí)間: 2010-08-13 12:38
如果lz有機(jī)會(huì)在ibank或者金融行業(yè)干過，就不會(huì)問這個(gè)問題了

作者: andkylee 時(shí)間: 2010-08-13 13:23
回復(fù) 20# shakeone

既然都dol都開發(fā)出來14個(gè)年頭了，為什么默認(rèn)的lock-scheme仍然是allpages？
這是一定的原因。

作者: andkylee 時(shí)間: 2010-08-13 13:24

sybase的用戶都是jpmorgan, morgan stanley, goldman sachs, ubs, creidt suisse等各種金融巨頭。不過公司投 ...
shakeone 發(fā)表于 2010-08-13 12:37

這個(gè)哥們是sybase的。因?yàn)榈枚嘞蚰銓W(xué)習(xí)。

作者: shakeone 時(shí)間: 2010-08-13 16:47

回復(fù) shakeone

既然都dol都開發(fā)出來14個(gè)年頭了，為什么默認(rèn)的lock-scheme仍然是allpages？
這 ...
andkylee 發(fā)表于 2010-08-13 13:23

你說的默認(rèn)的lock-scheme如果是指create table不指定lock-scheme的話，這個(gè)值可以在default.cfg里改的。
如果你說的是default.cfg里'lock scheme'的默認(rèn)值，主要大家覺得這個(gè)值沒必要改，因?yàn)榫退愀囊埠芎?jiǎn)單。
從1254升級(jí)到15x系列，連系統(tǒng)表都從apl變成了dol，所以我覺得如果你的表有大量dml的話，堅(jiān)決用dol，如果dml很少，query為主，apl比較合適

作者: sybfresher 時(shí)間: 2010-08-14 16:19
本帖最后由 sybfresher 于 2010-08-14 16:20 編輯

你用的一定是APL的lock scheme吧？用dol不會(huì)出現(xiàn)這個(gè)問題的，話說dol都出來14年了，為什么不用do ...
shakeone 發(fā)表于 2010-08-13 12:32

Datarows類型的表可以不會(huì)出現(xiàn)我舉的那個(gè)insert掛住的例子，但是，如果session1是對(duì)某些行數(shù)據(jù)進(jìn)行update，而session2去查詢，一樣的會(huì)被session1阻塞住，而Oracle不會(huì)。關(guān)鍵還是兩者的隔離級(jí)別不一樣導(dǎo)致的，ASE沒有Oracle的默認(rèn)隔離級(jí)別，本質(zhì)上與是否行級(jí)鎖無關(guān)。

作者: D_D_D_D 時(shí)間: 2010-08-16 11:29

關(guān)于第一個(gè)問題，舉個(gè)最簡(jiǎn)單的例子。先看在Oracle中：
session1:
SQL> create table t200 (c1 int);

...
sybfresher 發(fā)表于 2008-12-12 11:09

大哥，這個(gè)是因?yàn)镾和O對(duì)事物處理時(shí)默認(rèn)使用的是不同的隔離級(jí)別，你要是在S中set isolate 0的話和O完全一致，都是臟讀了。

這個(gè)只能說理念不同，默認(rèn)情況下，S保證數(shù)據(jù)的一致性和正確性，O求快，并沒有什么絕對(duì)錯(cuò)誤之分。但仔細(xì)想想，如果想銀行，券商等，默認(rèn)能允許臟讀么？我想不會(huì)吧。

作者: D_D_D_D 時(shí)間: 2010-08-16 11:32

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

隔離級(jí)別O和S都有，而且都有0,1,2,3，根據(jù)業(yè)務(wù)需要的不同在session中可以指定。

作者: sybfresher 時(shí)間: 2010-08-16 11:59

大哥，這個(gè)是因?yàn)镾和O對(duì)事物處理時(shí)默認(rèn)使用的是不同的隔離級(jí)別，你要是在S中set isolate 0的話和 ...
D_D_D_D 發(fā)表于 2010-08-16 11:29

我并沒有說ASE沒有實(shí)現(xiàn)ANSI定義的4種隔離級(jí)別。恰恰相反，ASE很好地實(shí)現(xiàn)了ANSI的四種隔離級(jí)別。但是，我舉的那個(gè)例子，Oracle并不是贓讀啊，session2讀到的是session1之前別人已經(jīng)提交的完整的數(shù)據(jù)，并不包括session1正在修改的、事務(wù)沒有結(jié)束的臟數(shù)據(jù)。Oracle的這各種類似IQ的snapshot的隔離級(jí)別ASE是沒有的。如果你使用ASE的隔離級(jí)別0去達(dá)到不被session1阻塞的目的，你讀到的東西也是不一樣的，和Oracle根本不在一個(gè)層次上。。。。退10000步講，就算我使用隔離級(jí)別0，ASE還必須要求這張表上要有唯一索引——這有可能會(huì)涉及到改變表結(jié)構(gòu)，又牽涉到另外一個(gè)層面的問題了。。。

作者: D_D_D_D 時(shí)間: 2010-08-16 12:34

我并沒有說ASE沒有實(shí)現(xiàn)ANSI定義的4種隔離級(jí)別。恰恰相反，ASE很好地實(shí)現(xiàn)了ANSI的四種隔離級(jí)別。但 ...
sybfresher 發(fā)表于 2010-08-16 11:59

又看了一遍你之前的例子，我認(rèn)為就是Read Uncommitted，O和S兩個(gè)廠商在對(duì)隔離級(jí)別為0時(shí)對(duì)事物采取的處理方式是一樣的，達(dá)到的效果也是一樣的。

話說回來，O和S東西再好意義也不大了，除非咱們搞技術(shù)的出國(guó)，ZF正在逐漸將核心和國(guó)計(jì)民生的應(yīng)用，連同服務(wù)器，操作系統(tǒng)，數(shù)據(jù)庫(kù)，中間件等逐步的往國(guó)有化上推，雖說很爛...

作者: D_D_D_D 時(shí)間: 2010-08-16 12:41

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

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

作者: sybfresher 時(shí)間: 2010-08-16 12:44

又看了一遍你之前的例子，我認(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仍然沒有。

作者: andkylee 時(shí)間: 2010-08-16 13:07
回復(fù) 32# sybfresher

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

作者: shakeone 時(shí)間: 2010-08-16 13:18

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

你說應(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ù)，可能是通過cache或者log來實(shí)現(xiàn)的，所以不會(huì)block

作者: xjtuhuth 時(shí)間: 2010-08-17 16:49
本帖最后由 xjtuhuth 于 2010-08-17 16:53 編輯

回復(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 時(shí)間: 2010-08-17 17:15
回復(fù) 32# sybfresher

IQ里有 MVCC

作者: shakeone 時(shí)間: 2010-08-17 18:01

回復(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 時(shí)間: 2010-08-17 18:34
本帖最后由 xjtuhuth 于 2010-08-17 18:47 編輯

回復(fù) 37# shakeone

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

作者: shakeone 時(shí)間: 2010-08-17 20:31
本帖最后由 shakeone 于 2010-08-17 20:43 編輯

回復(fù) 38# xjtuhuth

insert的問題：apl屬于all page locking,所以這個(gè)page被加上了事務(wù)級(jí)別的互斥鎖，就是說等這個(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沒有任何影響，所以不會(huì)有apl有的問題。
另外說一句，如果session 2是isolation level 3, insert也會(huì)block這個(gè)scan，因?yàn)閘evel 3防止幻影行的出現(xiàn)。

update的“問題”可以說是個(gè)問題，也可以說不是，因?yàn)閟ybase ase是嚴(yán)格按照sql標(biāo)準(zhǔn)的isolation level來實(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)為不是問題，也就沒有加入mvcc的必要了。

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

作者: xjtuhuth 時(shí)間: 2010-08-18 12:10
回復(fù) 39# shakeone

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

歡迎光臨 Chinaunix (http://www.72891.cn/)