Oracle与SQL Server在企业应用的比较

核心提示： 你会发现，我们都站在微软的杂货店前面，Oracle与SQL Server在企业应用的比较(3)，在你能够看见有哪些东西可以使用之前，你不得不等待，例如： · 由于内存不足造成锁逐步增加 · 由于SQL Server无法支持读操作的一致性，从而返回错误的数据 &m

你会发现，我们都站在微软的杂货店前面，在你能够看见有哪些东西可以使用之前，你不得不等待，直到我做出决定为止。你看到了诱人的酸葡萄汁正摆放在货架上，而我也许会买下它，这对于你来说根本是没有意义的。因为我可能只是看看，但是微软知道你希望购买水果汁，因此你必须等待我停止闲逛或者选中某样东西，而这个过程都发生在你得到任何东西之前。

Oracle会使你更渺小、更容易的查看数据吗？

在街上的Oracle店里，你可以整天查看哪些东西可以使用，即使我已经查看了，或者我正处在挑选东西的过程中。可能果汁的种类更多，可能我更渺小了，谁知道呢？无论是哪种情况，我都没有真正做出决定，因此为什么不让你看看有些什么东西呢？也许我会拿走最后一瓶酸葡萄汁，也许不会。但是你看到有些什么东西会有什么坏处吗？你可以打电话给妻子，告诉她"我忘了你要什么东西了，但是这儿有些什么..."

你会发现，在Oracle中，读取者所关心的是，里面不存在长时间的、持续很久的数据行更新。我可能在内存中修改某个数据行，尽管与其它的人有关，但是该数据行不会被更新，直到我真正地发出提交命令。实际上，我可能不是一个很好的程序员，可能在提交之前，把数据行保持很长时间。或者我可能决定根本不修改记录，只是进行回滚操作。因此，根本就没有数据发生改变，但是同时，你也可以继续自己的业务，不管我是否登录进系统中，更不用管我是否正在进行更新操作。但是，一旦我修改了数据行，并发出了提交命令，数据行才会改变，并且直到那个时候你才读取到新的值。因为直到那个时候新的值才正式存在。

你可能认为这是很小的差异。但是我可以告诉你，它是至关紧要的一个。当你必须支持对相同范围的相同数据表进行几个并发的更新的某个系统的时候，如果同时始终有几个用户在查询你正在操作的数据，你会发现"读取者－阻塞－写入者"机制将使产品停止运作。这种情况在企业系统中根本就是不可接受的。

也许我们以后还可能讨论其它的一些架构方面的问题。例如：

· 由于内存不足造成锁逐步增加

· 由于SQL Server无法支持读操作的一致性，从而返回错误的数据

· 类似DBCC的时间密集型维护事务来检测/防止性能恶化

· 微软的"自我调节"数据库，在很多情况下会妨碍数据库管理（DBA）

· 无论TPC结果如何，SQL Server都缺少伸缩性