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 都不需要了,直接通过消息来做—— 不过这样做对消息系统的要求很高,要合理设计消息的处理顺序。

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

        

相关推荐