我的oracle笔记-07 之 完结篇

关于ORACLE MVCC，我觉得大致就是这样了。单单从设计层面，这样的了解程度已经足够了，希望能够对目前还在挑战DSI的兄弟们有所帮助。当然，如果你想象我们曾经做过的那样，试图去自己实现一个ORACLEMVCC，那你还需要掌握更多的细节，但这已远远超出了博客本身的意义。

  所以到目前为止，我们实际上是了解了在ORACLE中，普通数据（堆表）上的MVCC是如何运行的，我们可能希望了解其它数据又如何呢？

  首先是关于索引，如果要求不是那么严格的话，你可以把索引看成是一种叶节点是多版本、非叶节点是单版本的数据结构，或者说，数据是多版本、结构是单版本。你需要注意两个问题，首先，你的更新可能在你提交之前被其它事务移动到新的页面上，为了仍然能够构造CR，ORACLE采用了最保险的策略：复制所有的ITL。第二点，SMO一旦完成就不可撤销，比如你分裂了一个页面，然后其它事务在你分裂的页面上插入了新的数据，然后你来试图Rollback掉这个分裂动作...好吧，其实大家都是在做慈善事业，所以不要一有抱怨就想着退出，在ORACLE中，SMO是由独立的事务来完成的，为了提高并发度，SMO过程中对其它事务是可见的，为此，你需要为这个事务保留ITL。

   其次就是LOB，同样的，你可以把LOB看成是一组数据页面被一根索引来定位，索引的MVCC与标准实现并无区别，而对于数据页面来说，它实际上是采用了一种以前叫做影子页面（Shadow Page）的处理方式，对页面的更新不产生UNDO，而是直接产生一新的页面（不原地更新），原来的页面被用作CR，你需要定义的是：有多少空间可以用来存放这些CR页面，以及如何淘汰掉哪些较早的CR页面。所以，如果你试图对一个LOB做频繁更新，你会比普通数据更频繁地碰到“Snapshot too old”。

   还有什么要说的？我实在是想不起来了。

   好吧，关于“我的ORACLE笔记”系列，暂时就写到这了，以后我会把我们在研发PearlMV中的收获与经验，继续与大家交流。另外，目前我的团队已经启动了对ORACLERAC的调研，等到我们的小玩具能够Run起来的时候，我会重开这个系列，并把我关于对RAC的理解也分享出来。但在这之前，我们还有更多的事情要做。

   最后，真心期盼，国内所有还在做国产数据库的力量，有一天能够联合起来，做出一款真正有竞争力的Made in China的数据库。但这确实不是我们这些搞技术的能左右的。

我欲春江载我游，奈何春江不回眸；我欲化土随波流，奈何一喝就上了头。

转载自：http://blog.sina.com.cn/s/blog_d3bf72ff0101o1ht.html