heavenmouse的专栏

接用户电话，某行核心系统 业务反应缓慢，超时。到达现场后检查数据库状态，SQLPLUS登陆慢，命令敲下去基本上需要15秒以后登陆检查等待事件，一切正常，检查LOG日志正常，系统无任何压力，VMSTAT 输出正常，用户反映ROOT登陆时也很慢。申请停机，重启了两台550，重启后未启动HA，最简单环境下故障依旧，ROOT及SQLPLUS登陆很缓慢。HA重新同步时一次超时，一次通过，但是日志中取

才下火车，接到电话说某用户的一套核心RAC一个节点重启，心急火燎的赶回家收LOG。

今天某用户电话问了一个有意思的问题。

关于RAC的io fence,一直想写点什么作为总结，毕竟干了这么多年，遇见的大大小小的节点重启也很多次了，今天，月黑风高，LOL被人骂成翔，还是静下心来写写技术文档吧RAC的io fence,中文名IO隔离，当RAC节点间无法正常联系彼此的时候，为了保证数据完整性，ORACLE会对故障节点发起驱逐命令，驱逐命令在原理上就是通过voting disk发出killblock，使节点重启或蓝屏，避

某用户割接现场保障，全部数据进库后，8点全网上线前最后一轮压测，截取AWR中发现如下等待   Event                                 Waits    Time (s)   (ms)   Time Wait Class------------------------------ ------------ ----------- ------ ----

我们在数据迁移的过程中，经常会发现数据库升级或迁移后，执行计划改变的情况，我们可以通过profile的方法固定执行计划。以下为一个10G-11G的模拟实验：1.创建实验环境[oracle@new10g ~]$ sqlplus mouse/mouseSQL*Plus: Release 10.2.0.5.0 - Production on Thu Dec 25 14:57:40 201

某行今天报告一个3T的库，恢复后无法OPEN，要求我方介入。到现场之前想当然的觉得无非不就是resetlog走起，结果到了以后用户说已经resetlog过了，从磁带恢复要两天，心凉半截。接手系统，recover database需要归档日志。询问用户得知备份已不存在。好吧，不管了。增加隐藏参数_allow_resetlogs_corruption=true起手alter datab