在不同Linux发行版中awk的版本兼容问题

RedHat、CentOS系列发行版中,系统自带的awk是GNU awk 3.1.5(不同版本可能有所不同)。今天发现在aliyun上的Ubuntu中awk的行为与之前(RedHat上)不一致,检查一下发现Ubuntu中awk里的substr函数,其行为与GNU awk不一致,Ubuntu中默认的awk是mawk 1.2……GNU awk中,substr(‘/dev/vda:’,0,length(‘/dev/vda:’)-1) 会返回 /dev/vdamawk 1.2中, 返回的是/dev/vd

一次Bug诊断记录

友商维护的Oracle数据库10.2.0.5 + RAC + ASM 部署在vmware里……两个节点只能启动一个,另一个启动时会宕掉…… 友商工程师,跟客户说,你这是bug,你升级到11gR2才能打相关的补丁——这是屁话,意思就是:不是我不能给你解决,相当于给你重装一遍系统,你看着办吧……重装系统能够解决99.9%的问题——这个道理我在windows 95时代就已经明白了。 还是我们来吧…… 帮助客户就是帮助我们自己! alert 日志:Tue May 16 21:08:17 CST 2017ALTER DATABASE OPENPicked broadcast on commit scheme to generate SCNsTue May 16 21:13:15 CST 2017Errors in file /oracle/app/oracle/admin/yjjsdbs/bdump/yjjsdbs2_dbw0_6917.trc:ORA-00240: control file enqueue held for more than 120 secondsTue May 16 21:47:14 CST 2017alter database openTue May 16 21:47:14 CST 2017ORA-1154

Oracle活动会话异常增高诊断-续

……之前我们利用DPA-Lite,已经定位到LGWR进程在特定时刻,堵塞了几十、上百个会话,导致Active Session数量在短时间内出现高峰……之后是各种分析、诊断…… 到底是IO性能出现问题,还是Commit量太大,导致LGWR出现延迟,却是一时间无法分辨。甚至,由于REDO LOG是放在高端存储的SSD上的,SSD有无问题…… 每次“故障”也不过就10秒,想精确定位问题何其困难!我们还是通过DPA-Lite来仔细检查,看看能不能找出一些端倪……5月10日,16时左右,问题再现: 此时间段内,Active Session高峰多次出现;16:06:56秒,LGWR堵塞了68个会话; 我们仔细看一看都堵塞了哪些会话,有何特点…… 特点是: HTZT用户,通过JDBC连接的应用,在等待Commit; 当前操作的对象ID都是 131629872和131629864 通过DPA-Lite查询另外一个时间点: 再次确认了这个现象!我们再看看更早之前发生Active Session高峰时的现象(5月8日16时): 仍然是HTZT用户操作OBJECT ID 131629872 131629864时等待Commit……我们查询数据库,确认这两个对象,发现是一张LOG(日志)表和该表上的一个索引,这个表以BLOB方式保存日志,目前数据量极大——超过300G。使用DPA-Lite 查看对应时间段的Top Object: 问题时间点,对于该表索引的操作,在数据库中占用资源排名第一! 存储已经用的最高端的了,解决问题就从这个日志表入手吧……日志么,都是用来事后查询、分析使用的,我觉得存在文件系统里,利用Hadoop之类分析是最好不过的,核心数据库高端存储上存个几百GB的日志,还弄出这种问题来,赶紧迁走……一想到拿着这些证据,一会儿让应用开发那帮哥们哑口无言我就觉得兴奋!

Oracle活动会话异常增高诊断

近日,核心系统Oracle数据库集群的一个节点,多次出现Active Session超过100甚至超过300的现象,每次持续时间都是10秒左右,甚至只持续5秒以内…… 时间太短暂,我都来不及看清你的脸…… 头疼! 16:43:57 正常状态 16:44:58 发现LGWR 堵塞大量会话 16:45:08 堵塞情况依旧 16:45:19 恢复正常 系统在20秒时间内,由正常状态,一下切换到异常状态,Oracle Active Session在节点2上迅速超过300, 并且很快恢复……整个"异常”过程20秒,短暂到我们的REMS2 监控报警组件都没有发现这个异常(监控为了避免对系统的干扰,每2分钟检查会话情况)……还好有DPA-Lite, "事后"仍然可以进行"秒"级别状态回放…… 让我们知道当时发生了什么,利用DPA-Lite 就是十几分钟的事情,就可以知道LGWR产生了大量堵塞——如果没有DPA-Lite这样合适的工具,难以想象我们需要多久才能知道“作乱”的原来是LGWR……DPA-Lite Operation Screen Record. Screen Video