Tag Archives: cluster

ODA之测试体验

测试了将近一周的ODA,关于ODA的技术文章也写了几篇,简单总结一下使用ODA的一点心得。 以前接触的一体机并不多,EXADATA虽然有过几次接触,但是与这次可以全方位的测试ODA相比就完全不值得一提了。 总的来说ODA给我的最大感触就是简便:把ODA插上电源和网线之后,唯一需要的配置就是通过ILOM配置一下ODA的网络,只需要把安装程序上传到服务器,通过ODA提供的命令进行解压,然后就是一键式安装。整个安装过程在一个小时左右。加上配置网络和上传软件的时间,整个RAC环境的部署也不会超过半天。而一般情况下,安装一套RAC,即使是熟手也没有十足把握在一天之内搞定,毕竟网络配置、存储设置、系统包的缺失甚至是BUG都可能会导致RAC环境的总体安装时间延迟,而ODA则完全避免了上面的问题。 此外无论是一键式卸载还是一键式升级,都已经将DBA烦琐的工作简化到了极致,在加上ILOM实现的无人值守功能,更是将ODA的简单、方便的特点发挥的淋漓尽致。 ODA的性能虽然不可能像EXADATA那样把执行效率以数量级的方式提高,但是无论是ORION还是SWINGBENCH的测试来看,ODA对于大部分中小型应用应该是足够支撑的。 说了半天的优点,最后说一下ODA的不足之处。首先不灵活性不够,虽然安装配置的简化和配置的灵活性存在一定的冲突,但是这并不妨碍ODA给高级DBA多一些定制的空间。其他的方面到还可以接受,就是ODA的ASM的3重镜像配置这一点是最让人头痛的。对于ODA来说,几乎没有可能改变这一点。除非是不使用ODA的一键式安装,而安全自己安装CLUSTER和RAC,而如此一来,ODA提供的简便性又荡然无存了。此外ODA另外一个致命的缺点,扩展性不足。虽然ODA目前支持外接存储,但是默认的安装配置是不支持将RAC部署到外部存储上的。当然通过将存储添加到ASM磁盘组中应该也可以实现ODA使用外部存储的功能,但是这是ODA策略所不允许的。除了磁盘空间外,CPU、内存资源也都是无法扩展的,更重要的是,ODA没有办法扩展第三个节点,也就是说ODA所能承载的最大压力是固定的。随着业务量的增长和历史数据的增加,ODA没有能力通过添加硬件资源来进行扩展。 因此,个人认为无法扩展是ODA的致命伤,但不是Oracle,因为根据Oracle的定义,总数据量小于3T的使用ODA,而大于3T的则应该使用EXADATA。那么根据这个观点,利用ODA作为EXADATA的热身产品,熟悉一下Oracle的一体机也是一个靠谱的选择。

Posted in ORACLE | Tagged , , , , , , | Leave a comment

ORA-600(ksqsgn:join)和ORA-7445(BREAKPOINT)错误

一个Windows环境下的RAC 10.2.0.4在添加节点时,原节点的ASM实例出现这两个错误。 错误信息如下: Sat Jun 09 11:24:21 2012 Starting ORACLE instance (normal) LICENSE_MAX_SESSION = 0 LICENSE_SESSIONS_WARNING = 0 Interface TYPE 1 GB2 192.168.7.0 configured FROM OCR FOR USE AS a cluster interconnect Interface TYPE 1 GB1 172.16.7.0 configured FROM OCR … Continue reading

Posted in ORACLE | Tagged , , , , , , , , , , , | Leave a comment

9iRAC环境遭遇library cache lock和library cache load lock等待

客户数据库版本为9208 RAC FOR AIX,客户反应系统缓慢,检查告警日志,发现大量Library cache lock和Library cache load lock等待。 由于客户的原因,这个问题只是远程协助的方式帮忙检查了一下,因此没有留下任何的操作记录,这里只是简单描述一下问题。 客户反应数据库操作响应变慢,平时一个执行很快的基于主键的UPDATE操作也变得异常缓慢,且执行计划本身并未发生改变。 登录数据库后检查两个节点上的告警日志,并未发现任何异常报错。分别检查两个实例的等待信息,发现除了上面提到的大量Library cache lock和Library cache load lock以外,还有明显的gc等待。 但是随后发现,查询V$SESSION和GV$SESSION的结果居然没有区别,接着查询GV$INSTANCE视图,发现只有当前的实例存在,而此时恰好连接另一个节点的工具出现了断连,以至于我一度以为另外一个节点上的实例已经DOWN掉,但是随后重新登录到该节点上,发现数据库实例仍然存在,而且登录到数据库实例中也可以进行任何正常的操作。不过发现在当前节点所有的GV$视图都只会返回当前实例的信息,这与另外一个节点的情况完全一样。显然两个节点间的通信出现了问题,当前节点已经不清楚另外一个节点的状态的。 现在再去分析那些等待信息已经没有太多的意义了,因为整个数据库已经处于不正常的状态。不难推断,当前数据库的异常是由于节点间的通信异常导致。由于9i使用的操作系统的CLUSTER,还没有Oracle的clusterware,剩下只能由操作系统或硬件维护人员去进一步跟踪了。 最终数据库和系统在夜间闲时进行了重启操作,重启后数据库恢复正常,GV$视图的结果也恢复了正常。

Posted in ORACLE | Tagged , , , , , | Leave a comment