起原：天极网
在我管事的公司不光仅拥有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都短少伸缩性
当然，还有更多的标题结果必要办理，不过今日就到这里。
版权声明：
原创作品，容许转载，转载时请务必以超链接方式标明文章 原始来因 、作者信息和本声明。不然将清查法律责任。