Oracle与SQL Server在企业应用中的比较
在我供职的公司不仅仅拥有Oracle数据库，同时还拥有SQL Server数据库，所以我经常遇见人们向我提两种问题。
第一种通常都是以"你能教我使用Oracle吗？"开始的，对此我比较礼貌的回答一般是"当然可以，实际上我正准备办个Oracle学习班；准备好之后我就叫你"。这是做好人的办法，我没有告诉询问者这可能花费我数周的精力。有时候我进一步告诉他们可以在哪儿去下载Oracle的完整版本，以供他们安装和熟悉。但是有时候这样做给我带来了麻烦，因为它可能招来过多的追随者。
第二种一般是这样开头的"我们遇到了SQL Server的一些问题，我想看看Oracle是如何处理这个问题的"。好的，我们终于有了一些进展了。我可以为他们提供帮助，但是这不会占用我数小时时间。它应该是对某个特定问题进行了慎重地考虑之后的叙述，Oracle对这个问题的答案将为询问者指出一条道路，可能引导它们解决SQL Server的问题。询问者接者问"我们的SQL Server数据库变得太大了--Oracle如何处理这个问题呢"？唉...看来我说错了。
我想提供帮助，但是...
我的方法也许一直都是错的。也许我应该写一个总结材料，归纳可能涉及到的一些问题。当其他人向我寻求帮助的时候，我就可以把这个问题列表给他了。如果那个人正在接受普通的Oracle启蒙教育，这个列表也许稍微广泛了一些。另一方面，如果询问者在搜索特定的和可以量化的问题的解决方案，这个手册也可以帮助他们沿着正确的方面前进，这样他们就可以在自己的桌面上找到答案。
但我没有这样做，因为这样做花的时间太多了。尽管我尽可能地帮助这些"寄居者"，但是我真的担心为他们花费了太多的时间，偏离了自己的航向。这样做将是个不好的先例。它会鼓励他们在某个时刻遇到某些苦恼的时候再次回来向我求助。作为代替，我仅仅花几分钟时间谈一下SQL Server中的设计瑕疵。体系结构所涉及到的内容是不能改变的。如果你钻研数据库平台对比判断的技术细节，一般都无法得到那些不言自明的原理。相反地，如果你决定使用微软的数据库平台，这些问题就一定存在。它的特性或缺陷可能被我们处理得较好，但是产品基本的机制不容易改变--当然也不容易被封闭源代码软件的最终用户所改变。当然，有些办法可以减轻痛苦，但是却无法克服这些问题。两个平台之间有很大的差异，更不用说很多问题的起源之间的差异了。
请记住，我不是维护街上花店的系统。微软正在尽自己最大的力量进入企业中，进入Oracle的领地。因此我要讨论的是：企业级系统管理员所关心的问题。 我所关心的是...
由于公司需要使用管理企业级系统（我们公司是SAP），我更喜欢使用多用户（multiuser）数据库。现在你可能认为我使用这个术语太轻率了。实际上有大量的用户在多用户环境中使用SQL Server，不是吗？但是他们处理大量的并发用户是受到平台的影响，还是不管并发用户的？例如，我们来看看锁（locking）的问题。开始，微软告诉你"读取者－阻塞－写入者"的机制很好，很安全。它会告诉你这个机制防止了用户执行"错读（dirty read）"。不要相信这种鬼话；它只是性能低下的一个借口。这使我想起了Sun长期坚持认为64位系统不必要的立场。不必要是指他们销售这种产品之前没有必要存在。接下来，某一天Scott McNealy在你面前高谈不断增长的物理内存寻址的优点。
那么什么是"错读"？微软会告诉你，如果某个人正在更新一个数据行，而你准备读取这个处于更新之中的数据行，就会出现错读。错读=坏数据--这是微软希望你相信的内容。但是如果某个更新操作很长时间没有提交会出现什么情况？数据实际上没有真的被改变。如果那个更新操作在事务的末尾回滚了又会出现什么情况呢？这些读取者的等待得到了什么东西？什么也没有。
这就好像我在一家超市里，站在果汁面前，试图决定买哪一种。我知道自己会选择一种，我知道我的小孩明天早餐需要喝果汁。我已经伸出了手，但是还没有决定拿哪一种。上周我买的是苹果汁，上上周买的是什么呢？白葡萄汁。我想现在是不是该买酸葡萄汁了。另一方面，我在思考的时候你正好站在我后面，你可能在想"这个白痴什么时候才能拿一瓶，并且不要挡住我呢？我可知道自己想要什么"！
你会发现，我们都站在微软的杂货店前面，在你能够看见有哪些东西可以使用之前，你不得不等待，直到我做出决定为止。你看到了诱人的酸葡萄汁正摆放在货架上，而我也许会买下它，这对于你来说根本是没有意义的。因为我可能只是看看，但是微软知道你希望购买水果汁，因此你必须等待我停止闲逛或者选中某样东西，而这个过程都发生在你得到任何东西之前。
Oracle会使你更渺小、更容易的查看数据吗？
在街上的Oracle店里，你可以整天查看哪些东西可以使用，即使我已经查看了，或者我正处在挑选东西的过程中。可能果汁的种类更多，可能我更渺小了，谁知道呢？无论是哪种情况，我都没有真正做出决定，因此为什么不让你看看有些什么东西呢？也许我会拿走最后一瓶酸葡萄汁，也许不会。但是你看到有些什么东西会有什么坏处吗？你可以打电话给妻子，告诉她"我忘了你要什么东西了，但是这儿有些什么..."
你会发现，在Oracle中，读取者所关心的是，里面不存在长时间的、持续很久的数据行更新。我可能在内存中修改某个数据行，尽管与其它的人有关，但是该数据行不会被更新，直到我真正地发出提交命令。实际上，我可能不是一个很好的程序员，可能在提交之前，把数据行保持很长时间。或者我可能决定根本不修改记录，只是进行回滚操作。因此，根本就没有数据发生改变，但是同时，你也可以继续自己的业务，不管我是否登录进系统中，更不用管我是否正在进行更新操作。但是，一旦我修改了数据行，并发出了提交命令，数据行才会改变，并且直到那个时候你才读取到新的值。因为直到那个时候新的值才正式存在。
你可能认为这是很小的差异。但是我可以告诉你，它是至关紧要的一个。当你必须支持对相同范围的相同数据表进行几个并发的更新的某个系统的时候，如果同时始终有几个用户在查询你正在操作的数据，你会发现"读取者－阻塞－写入者"机制将使产品停止运作。这种情况在企业系统中根本就是不可接受的。
也许我们以后还可能讨论其它的一些架构方面的问题。例如：
? 由于内存不足造成锁逐步增加
? 由于SQL Server无法支持读操作的一致性，从而返回错误的数据
? 类似DBCC的时间密集型维护事务来检测/防止性能恶化
? 微软的"自我调节"数据库，在很多情况下会妨碍数据库管理（DBA）
? 无论TPC结果如何，SQL Server都缺少伸缩性
