为什么银行很多用sybase？

Stargate

呵呵，现在被SAP收了。。。现在主攻移动产品了

xinyisky

因为Sybase  比oracle 简单，同时用Sybase的pb做东西上手比较容易。
个人观点

iihero

金融是Sybase的传统优势领域啊。

yulihua49

原帖由 eleooz 于 2007-4-22 22:26 发表
中国的银行、电信、石化甚至包括一些大型企业，近80%都是用的SYBASE，剩下的由oracle和db2瓜分。原因主要是：
1.这些部门信息化要求很高，而且实现信息化的时间也很早[关键是后一点]，而那时候，进入中国数据库市场的，主要就SYBASE、oracle和db2[microsoft sql还没有从SYBASE中分裂诞生出来]。其中就属SYBASE市场开拓做的最好，先就把电信这个客户牢牢抓住，然后就是银行[约80年代]。等oracle和db2明白过来时，已经到90年代中后期，上述大客户已经“嫁”给了SYBASE，“改嫁”的代价太大也不可能了；不过现在搞信息化的大型企业大多用的oracle，而db2似乎不怎么火，sql2000则还只停留在中型或者偏大型企业。
2.SYBASE的确很不错，功能强大，性能稳定，经受了银行、电信的TB级数据考验这么多年，好象没听说过有什么问题，是真正的超大型数据库。而且如前所说：microsoft sql也还是微软借合作之名偷了SYBASE的技术后，另立山头开发出来的，顶多只能算是SYBASE的“儿子”，而现在连“儿子”都开始发威了，你说“老子”是不是不可小觑？
3.SYBASE的缺点也比较明显，与oracle、db2一样，其安装、部署和管理需要专门的精通它的数据库管理专家来做，而且比oracle还要复杂许多，据说完整搞下来，有几千道步骤，还别说日常维护非常复杂。[这也可以说是所有大型数据库的公共特点] 再看看sql2000，咱老百姓自己的数据库，只要视力没问题，认得字，图形化界面简单！
3.补充一点不太好的消息：SYBASE已经在去年被IBM收购了，前途不太明朗，而且，现在中国的大型项目似乎越来越喜欢用oracle和sql2000，很多人甚至都忘记了还有SYBASE、db2和informix等。其实sql2000顶多只能算个中大型数据库而已，而且只能部署在windows server上，也就比mysql和interbase稍微强一点，速度绝对赶不上mysql。
就说这些，一家之言，见笑！

早年INFORMIX市场挺大，银行（ICBC）早期也是INFORMIX。
SYBASE的稳定性不如ORA，更不如INFORMIX。
如果动态数据，SYBADE每天都要DBCC。ORACLE需要3个月停机一次。INFORMIX可以免维护。

银行基本没有动态数据，所以SYBASE挺好。
铁路都是动态数据。其售票系统用SYBASE，但是每天DBCC，还不时发生重码。
原因是早年SYBASE与铁科院的营销关系。现在铁科院体会到其缺陷，但是改嫁已经不可能了。

[ 本帖最后由 yulihua49 于 2011-8-11 15:49 编辑 ]

eisen-pb

原帖由 yulihua49 于 2011-8-11 15:45 发表

早年INFORMIX市场挺大，银行（ICBC）早期也是INFORMIX。
SYBASE的稳定性不如ORA，更不如INFORMIX。
如果动态数据，SYBADE每天都要DBCC。ORACLE需要3个月停机一次。INFORMIX可以免维护。

银行基本没有动态数据，所以SYBASE挺好。
铁路都是动态数据。其售票系统用SYBASE，但是每天DBCC，还不时发生重码。
原因是早年SYBASE与铁科院的营销关系。现在铁科院体会到其缺陷，但是改嫁已经不可能了。

请问所指稳定性问题何指?
另外请问动态数据是否指OLTP处理? 所言不时重码，应该说是锁机制和业务系统设计缺陷吧，和数据库无关吧……
当然，如果要说Sybase缺省走悲观锁，而Oracle走乐观锁的话，那就只能说情不要误导新人啦。

yulihua49

原帖由 eisen-pb 于 2011-8-12 10:21 发表



请问所指稳定性问题何指?
另外请问动态数据是否指OLTP处理? 所言不时重码，应该说是锁机制和业务系统设计缺陷吧，和数据库无关吧……
当然，如果要说Sybase缺省走悲观锁，而Oracle走乐观锁的话，那就只能说情不要误导新人啦。

每天产生700-800万新纪录（席位），同时要删除这么多过期的数据。每个席位的状态不断的改变。
竞争是高概率，无序的。例如，大量的终端同时申请同一种车票。不像银行，很少有多个终端处理同一帐户。
每个席位都只能卖给一个客户。
这时，系统长期运行，要求，数据空间的增长和空洞，索引的有效性，查询性能下降情况，构成了系统的稳定性，或者应该叫数据库平稳性。

锁的问题，是通过悲观锁，维护乐观锁。具体说来，每个席位初始是可用状态。被选中后是占用状态，交款记账后，是售出状态。那个占用状态就是乐观锁。
无论在TRS（SYBASE）里，或TBS（ORACLE）里，都是这样的乐观锁。但是这个乐观锁需要用悲观锁来管理。
在select阶段，就必须for update来独占纪录，防止一个席位被多个终端抢去。
目前，TRS使用SYBASE12.5，页锁。锁一页。许多纪录，严重影响系统并行性。实际上，连页锁也没用，因为无游标的操作不支持for update操作。
只是使用超高性能的服务器，缩短竞争缝隙，减少重票概率。

即使采用游标操作，SYBASE也是有问题的。页锁的低并发性。行锁行吗？可惜，SYBASE的行锁是DOL，只锁数据，索引是不锁的。用不了多久，索引都损坏了。没人敢用。
ORACLE要好得多。行锁和for update是没问题的。
唯一的问题是，索引不是完全B+树，删除时不归并索引节点。时间长了，索引效率下降，需定期修复索引。平稳性稍差些。
目前，采用完全B+树索引的数据库，只有INFORMIX。

[ 本帖最后由 yulihua49 于 2011-8-12 11:23 编辑 ]

eisen-pb

嗯。是的。12.5的索引自维护问题是不少，这个东西大概是6年前的玩意儿了吧，怎么现在还在用啊?12.5.4已经好很多了。如果到15.5的话，个人感觉可以通过IMDB+分区的方式来搞定。
而说到cursor，为啥要用cursor? Sybase虽然有cursor，但是从来都不推荐使用cursor，那何必非要用其他db上的风格往sybase上套呢?而且也没必要只要是不和Oracle一致就要认为是问题吧。

yulihua49

原帖由 eisen-pb 于 2011-8-12 13:43 发表
嗯。是的。12.5的索引自维护问题是不少，这个东西大概是6年前的玩意儿了吧，怎么现在还在用啊?12.5.4已经好很多了。如果到15.5的话，个人感觉可以通过IMDB+分区的方式来搞定。
而说到cursor，为啥要用cursor? Sybase虽然有cursor，但是从来都不推荐使用cursor，那何必非要用其他db上的风格往sybase上套呢?而且也没必要只要是不和Oracle一致就要认为是问题吧。

没有cursor就无法在select    。。。。  for update。
这个操作只有在游标下可用。作为行锁，fetch 一行锁一行，没游标怎么定位？

游标，是提高性能的一个手段。被SYBASE弄成降低性能的了。

一大批数据需要插入数据库，不用游标，每个语句都要解释。使用游标，语句只解释一次。以后只需绑定变量，执行。大大提高效率。
如果进行成组操作，成组绑定即可。没游标，怎么办？

ORACLE采用游标成组操作，你SYBASE怎么跟人家比性能？

SYBASE 不用游标，插入1000条/秒。ORACLE游标成组，27000条/秒。
相同的机器。

[ 本帖最后由 yulihua49 于 2011-8-12 16:22 编辑 ]

eisen-pb

哦。为了update定位啊。那用primary key来定位应该可以吧。配合临时表，作while循环或batch commit避免cursor是Sybase开发中的一个常用技巧啊。我到现在已经有4年多不用cursor了。
确实，Sybase的编程逻辑思路和常人思维不大一样，不过总是有技巧来搞定的。

yulihua49

原帖由 eisen-pb 于 2011-8-12 16:14 发表
哦。为了update定位啊。那用primary key来定位应该可以吧。配合临时表，作while循环或batch commit避免cursor是Sybase开发中的一个常用技巧啊。我到现在已经有4年多不用cursor了。
确实，Sybase的编程逻辑思路和常人思维不大一样，不过总是有技巧来搞定的。

有时不可以。比方，你要买某日，上海，T21，硬座，5张。这肯定不是primary key。相同的坐席有好几百，PK一直定位到车厢号，座位号。

[ 本帖最后由 yulihua49 于 2011-8-12 16:19 编辑 ]