Oracle杂记

      好久木有写博客了。罪过罪过，实在是太忙，好在闲余没有白白浪费，Oracle的水平有了一个质的飞跃，越来越喜欢在命令行模式里面直接管理数据库的感觉了。

      前段时间参加Velocity China 2012 _ web性能大会，期间接触到了MySql的集群方案，鉴于对Oracle比较熟，就研究了一番RAC。其实RAC就是Oracle的集群方案，基本上做到了两点： 一个是实现了数据库的HA,主要包括数据层面和实例层面，数据层面是通过ASM实现的，实例层面是通过RAC节点实现的(例如两个节点每个都有自己的虚拟IP,这个IP是可以“浮动” 的。当非主节点发现主节点挂掉时，就发起一次Vote,根据Vote结果选举一个新的主节点，新的主节点多了一个新的虚拟IP，也就是原来主节点的虚拟IP,于是客户端请求就转到这里来了). 另一个功能就是实现了实例的负载均衡，使得能够利用多台机器的硬件资源处理能力。当然异地灾备方面还有DataGuard.这个没做太多研究。

         同时也研究了一下Oracle的表连接和分区技术。知道了索引在Oracle中的巨大作用，知道了复合索引中的前缀性和选择性。知道了还有分区索引这等逆天的存在。对于SQL的解析有了一定认识。也知道了类似V$Session, V$Activie_session_history(ashrpt.sql), awr.sql等数据库诊断方式，并且基本能看懂执行计划了。

         研究分区，自然就想到了分库分表。分库好理解，只是对于分表不是很理解，分表是不是应该一种特殊的分区？因为分区虽然可以指定不同的表空间，但是分表

是可以分在不同的实例上的吧？试着找了一下分库分表框架，发现貌似只有Guzz和阿里的CobarClient可用。改天研究下这两个框架。

         但是分库分表带来一个新的问题，事务的处理。其实随着SOA架构的流行，终归会面临分布式事务的问题。在并发大的情况下，分布式事务由于独特的2阶段提交，会带来很大的问题，比如等待，死锁 ，而且也很慢。所以除非迫不得已，不然一般高并发系统都不会采用类似XA这种分布式事务。

         除了传统的ACID事务模式，还有另外一种事务模式 —— BASE： Basic Available, Soft State, Eventually Consistent . 就我分析下来，如果要采用

Base模式，基本上就只有一种方式比较可行： Best Efforts 1PC + 基于消息的最终一致性，消息是用来重做失败的事务的。当然也可以在设计之初就直接采用异步的方式，这样的话连BestEfforts 1PC 都不需要了，直接通过消息来做—— 不过这样做对消息系统的要求很高，要合理设计消息的处理顺序。

          可惜啊，一直没机会亲自参与到这种大系统的建设过程中去，具体实现也只能靠猜了.....