达梦数据库不是中国自主产权？？？？？

anlinew

当a session 做:
update a set a.name='sfads'
where a.id=1

update b set a.name='asfafa'
where a.id=2

......

b session 做：
update a set a.name='sfads'
where a.id=3

update b set a.name='asfafa'
where a.id=4

就算id上有主键索引，a session和b session做的id范围完全不重复时发生死锁，你做何感想？

至于snapshot，我还不至于连这个都不知道吧，呵呵
我特意说是加锁机制而不是锁机制，就是有意要去区分一下，oracle下update id=1 的永远不会阻塞id=3的但是mssql和db2就未必，这实际上是和锁机制不同层面上的问题，不知道我表述清楚没有。。。。

myth8860

呵呵，anlinew的例子
有主键的话mssql、db2和dm都不会阻塞的。

myth8860

感谢大家的关注，其实mvcc对性能的影响没有想象中那么大，达梦不支持mvcc的时候也移植了很多的oracle应用，性能都可以满足用户的要求。
   并且如果应用开发人员不了解mvcc的特性，开发出来的应用还有可能出现逻辑错误。正如tom所说只有充分了解了技术特性，才能够很好的发挥出作用。

anlinew

原帖由 myth8860 于 2011-4-8 10:04 发表
呵呵，anlinew的例子
有主键的话mssql、db2和dm都不会阻塞的。

是否阻塞与执行计划有关，就算是有主键，只要没有走主键唯一扫描，依然会阻塞，所以我说这才是最要命的
你去仔细看看我给的链接
事实上很多时候问题并没有我们现在事后看起来那么简单，现在看来原因其实上很简单：就是因为做了隐性数据类型转换
。。。。。。

[ 本帖最后由 anlinew 于 2011-4-8 20:57 编辑 ]

anlinew

以我目前对达梦的了解，达梦加锁机制应该也是如此，所以还是那句话：
“
锁等待的程度与系统中表及索引对象的设计/sql及其执行计划的优化程度有很大的关系，因此也就与系统开发设计以及维护人员的能力有了很大的关系
达梦也是如此
”

myth8860

原帖由 anlinew 于 2011-4-8 11:40 发表

是否阻塞与执行计划有关，就算是有主键，只要没有走主键唯一扫描，依然会阻塞，所以我说这才是最要命的
你去仔细看看我给的链接
事实上很多时候问题并没有我们现在事后看起来那么简单，现在看来原因其实上很简单：就是因为做了隐性数据类型转换

嗯，有隐形的类型转换确实利用不上索引，这样也会阻塞，这样oracle不会阻塞么？

试验一下啊

[ 本帖最后由 anlinew 于 2011-4-8 20:58 编辑 ]

anlinew

举个现实的例子：
有教室1/2/3/4等等，其中有些房要装修，其中教室1已经在装修，工人oracle和mssql正去装修2和3教室
如果他们都知道自己要装修的房子在那儿（有唯一索引），没问题，直接去装修了

如果某种情况下不知道房子在哪儿了，
oracle就把整栋楼找了一遍，找到自己要装的房子开装
mssql也开始找，当他找到教室1时就发现，唉，有人在装修呢，我先等着。。。。

显然oracle的做法更切合实际

myth8860

呵呵，很形象的例子，刚才试了下oracle11g，发现隐式类型转换也能用索引了，确实很好很强大。

anlinew

原帖由 myth8860 于 2011-4-8 13:13 发表
呵呵，很形象的例子，刚才试了下oracle11g，发现隐式类型转换也能用索引了，确实很好很强大。

隐式转换只是简化了的一个例子罢了，实际生产中跑错索引等等的例子举不胜举
而问题的关键是加锁与执行计划是相关的，就算你搞什么snapshot也是徒然，而要做到执行计划的优化对使用者有很高的技术要求，在使用者搞不定这个层面的问题的时候，自然会对不需要搞这个问题也还过得去的oracle喜爱有加了
所以我说oracle非常迎合开发/以及DBA，好像换了oracle这也快了那也快了，实际大家也没搞清楚也懒得去搞清楚到底是为什么，最后总结为oracle就是牛

比如我们曾经给oracle研发部门提过一些场景的sql在CBO层面优化的建议，oracle的态度是非常欢迎并且有些当时就反馈已经在某个下一版本有考虑了，而有些厂商的态度却是：你们可以改应用啊，你这样写是不对的，这样这样就好了，呵呵，我当然知道可以这样这样，甚至我们的应用里早就已经改了，问题是不是所有人都能买账呢。。。

[ 本帖最后由 anlinew 于 2011-4-8 13:49 编辑 ]

myth8860

达梦也很注意采集不同的sql应用场景，不断完善我们的产品，不同在于我们的应用领域和规模还远远不够，这也是我们努力的方向，相信oracle一开始也不是一个完善的产品，只有通过大规模的应用检验才能够成熟起来。