最近用了一次DB2, 感觉同Oracle还是有一定差距。

luckyjackgao

最初由 turbo_c 发布
[B]你400都没搞懂你评什么db2/400?
我orcacle和db2/400,db2 udb都有很深的研究,我比你有发言权得多
as/400  总体采购成本未必贵, db2/400是不收钱的,oracle 按cpu颗数算钱,再加上存储,总体拥有成本比as/400成本高,维护的复杂度就更不用说了
你不会开飞机,会开车,于是得到结论汽车比飞机快,这就是你的理论 [/B]

你说你很有研究，可是那不是靠说的，请你拿出具体的例证来，或者认真回答我的问题。你应该不像那些国内的经济学家吧，一下就给胆敢提出不同意见，用数据和事实说话的人扣一个什么不支持XX的帽子吧。
      既然你是专家，就请回答问题，另外专家应该很有涵养才对阿。别发火阿。呵呵。

bluewhite

luckyjackgao 很多方面说的有道理， IBM在开发方面的支持确实不够，不过也不能一口确定oracle 比db2 强。 从各位辩论中学到不少。谢谢.

turbo_c

最初由 luckyjackgao 发布
[B]
你说你很有研究，可是那不是靠说的，请你拿出具体的例证来，或者认真回答我的问题。你应该不像那些国内的经济学家吧，一下就给胆敢提出不同意见，用数据和事实说话的人扣一个什么不支持XX的帽子吧。
      既然你是专家，就请回答问题，另外专家应该很有涵养才对阿。别发火阿。呵呵。 [/B]

oracle有什么db2做不到的?db2已经有了oracle做不到的!!!,我已经举过例子了.不恢复数据库做forward, oracle做不到
这个不需要任何数据说话,你要是会as/400就做个实验

turbo_c

数据库计算机（Databank machine）
Mel Beckman

一个被大家广泛接受但实际上并不正确的格言是—“每个人都有权利拥有自己的意见”。对于我们中间的任何一个人来说，我们总会在一些事情上没有资格发表自己的意见。例如，我就没有资格对外科颅内视神经微管手术说三道四—虽然我可以在互联网上找到这些术语。

不幸的是，人们在发表自己的意见时常常并不首先具备必要的专家知识，这在技术领域是一个非常常见的现象。基于Unix的数据库系统（特别是基于Linux的数据库系统）就是这样的一个特别容易产生如此怪论的话题。

我在此前的20年中一直在运行Unix和Linux的不同版本，而我总是发现数据库可靠性是这些系统的一个主要问题，它们经常会发生随机和无法解释的系统崩溃。由于发生致命死机和处理过程被挂起的次数太多，以至于大多数Unix数据库管理员（DBM）为方便起见都将数据库的复位程序放在自己的监视器上。关于应该如何解决这一问题，数据库开发人员有各种各样的意见，但我担心他们并没有资格在这一领域发表自己的意见。

我并不是说Unix数据库开发人员不够聪明。实际上，他们需要创建如此复杂、如同巴洛克建筑一般的软件“城堡”，并与“会飞的墙壁、魔毯和深坑”进行战斗。我的意见是Unix数据库的开发人员没有这方面的发言权—他们深深地沉迷于自己周围的环境，对那些定义良好、能够解决Unix数据库可靠性问题的解决方案视而不见。实现数据库可靠性的正确途径是使核心数据库功能成为底层计算机硬件的一个组成部分。拥有内建的硬件辅助数据库引擎的i系列架构就是使用这种方法的一个非常好的例子。

i系列的数据库计算机（database machine）架构是一种有很长历史而又十分著名的架构，它最早出现在上世纪70年代的System/38中。通过将单级虚拟内存与抽象的机器指令集美妙地结合在一起，i系列内建的数据库工具在概念上与最初创建时并没有什么变化。因为基础理念非常好，所以无论其“年纪”如何，i系列的数据库机一直都值得使用和模仿。

与经常闯祸的Unix数据库不同，i系列数据库几乎不要求（人工）干预，但很少（如果有的话）崩溃。我从未见过一个崩溃的i系列数据库—尽管我认为在理论上存在着崩溃的可能性。另一方面，我每个月都会因为莫名其妙的原因而需要对一些Unix服务器上的Oracle、Sybase、SQL Server、MySQL或Postgres数据库进行恢复。这些系统拥有广泛的数据库验证和恢复工具（如使人感到胆战心惊的Postgres Vacuum工具），而这一事实恰恰证明了它们内在的不可靠性。

IBM的i系列服务器之所以拥有这样高的可靠性，是因为它将尽可能多的数据库功能放在底层硬件上实现—这些功能以经过长时间检验、高度优化的微代码的形式实现。例如，i系列有一条名为Create Index（创建索引）的机器指令，该指令的功能是创建一个完整的B-树索引。其它指令可以在这些机器实现的索引中插入或删除一个入口。使用单一存储虚拟内存的系统使这些机器指令无需考虑磁盘和内存的分级—在它们看来，所有的数据和指令都在内存之中，而且只有一个唯一的地址。

需要指出的是，并非整个数据库都在硬件上实现，实现的只有关键的核心功能。在硬件上实现可以使这些功能更加高效、更加重要和非常可靠。将其封装到硬件之中可使其免受意外变化和数据库软件其它组件崩溃的影响。

在计算机架构中有一个很好的先例可以说明将数据库引擎嵌入到硬件中的必要性。很久以前，计算机曾经有很长一段时间不能执行数学计算，它们只能执行算术计算。System/3处理器甚至不能执行乘法或除法，您会不会大声惊呼—还有这样的事！那时，当您需要执行真正的数学计算如浮点操作和三角计算时，您需要购买一个数学功能库。当时有很多相互竞争的库产品，每一个功能库都使用自己专有的计算方法。由此导致的结果是，对于这些运行不同数学库的计算机，在进行故障诊断时很难得到明确一致的答案。

最终，人们终于认识到解决这一问题需要通过标准。电气和电子工程师学会（IEEE）制订了一个机器表示标准，用于表示数字和执行基本的数学运算。这些标准和算法被嵌入到数学协处理器之中，并最终直接嵌入到CPU之中。因此，现在的软件开发人员可以开发更加一致和可靠的代码，而且它们的引导速度更快。

现在，其它平台将核心数据库功能嵌入到硬件中的时机已经成熟，而i系列架构就是一个极好的值得效仿的典范。i系列架构的开发人员在选择应该将哪些数据库功能转移到硬件的问题上拥有数十年的经验。在未来应如何继续的问题上，我们完全应该请教他们的意见。

turbo_c

1。db2可以包char,date,time,timestamp之类的保留字作为表的字段名，ORACLE不行。     
  2。db2的container(dms的时候与datafile一样)，加入新的后，db2会自动把数据重新自动平均分配到各个containor中。db2中可以间接删除数据文件，ORACLE可能只用drop   and   recreate的办法。     
  3。   db2   can   rename   tablespace   except   catalog   tablespace

wangzhonnew

两者各有所长，大家比较公认的就是oracle在对外接口(API+SP+Function+GUI)确实做的出色,db2主要在管理部分与对海量数据支持和对sql优化上作的比较好，实际上ibm正在对他们的不足作出改进，在V9中提供了更多的SP+Function，同时GUI也更加user friendly。

turbo_c

我没有说过AS400的开发效率低，我说的是AS400的DB2开发效率低不可以吗？
你AS400上的RPG开发效率高吗？写个报表程序得1个礼拜。时间都花在反复调整页面位置上了
==================
只有蠢货用rlu做个报表要一周,
你定义cursor   open cursor  fetch cursor 写了半天,我一个F表定义几秒钟搞定,你还好意比开发效率

turbo_c

你说你懂AS400 了，那么请问你回答我个问题，
你能解释为何开发报表打印程序的时候， 要针对每种不同的打印机专门写不同的DDS 的 Form 呢？
你能告诉我， 为什么 AS400中有那么多CCSID 吗？ 为何一个表或者你们所说的物理文件里各个字段都可以CSSID不同吗？有必要吗
================================
不懂装懂,你ccsid不会设65535啊,谁告诉你物理文件每个字段可以不同ccsid是个缺点的?装什么装?orcle里字符集难道少啊?

turbo_c

给你再列举个例子， DB2的SQL中， 没有写Log 文件的功能，这个已经过IBM的工程师证明了， 不是AS400上的DB2 ，是所有的DB2.。你们的法拉利可真强啊。
=========================================================
你所说的sql没有log是指什么?db2/400  里 strsql  按f13,然后选1再选2, 可以把sql的结果放在splf里

ryan76

同意楼上的观点，回过头来看，通过争论我们都增长了不少见识。i系列发展到今天只有了解其历史的人，足够了解，才能体会其深度，Oracle也一样，两者有些地方是能比较，但是也各有特点，因为我们面临的数据计算越来越复杂，不会也不可能有一种产品能满足我们现实世界的所有需求。同时这也是通过竞争来保持进化的方式，IBM虽然是大象，但也在进步，不会像恐龙一样消亡，同时我们也看到现在的Oracle也正在变成i一只大象，其收购和后来的一些产品线并不像起义开始的数据库那样优秀。我还是那个观点，我们何时能够拥有自己的大象，这才是我们目标，或者也可以写出上面那样的文章，不是因为内容，而是因为那种经历