本来想写篇“人生无常,谨小慎微”的博文,可是还没等写,接二连三又发生了几起别的事情,所以就合并在一起。
自此购车以后,就常常做不那么好的梦,右眼也老跳。去合肥上牌的头一天晚上,不知是兴奋还是紧张,没怎么睡好,似乎梦见了两具尸体上盖着白布,旁边还有棺材。等到回程的时候,才把这个梦告诉了来回帮我开车的lawrence,闹的这家伙很生气。
其实梦也许是准的,因为我们回程的时候,一是晚上(6点从合肥出发12点多到的上海),二是雾大,所以遇到了两起车祸。一起是快到南京三桥前面,堵了小半个小时,只看见宝马的前脸大半个没有了,没看见其他事故车;第二起是快到昆山了,大货车的东西撒到了4个车道上,小汽车的第二排座位和后翼没了。害我最后自己从高架开回家的时候,手和脚都是抖的。
没过多久,一个同学她老公,做出租车遇上车祸了。出租车和一辆黑色BYD F3在转弯的时候,以较高的速度相撞,我同学老公飞出去了。幸运的是,没有内伤,目前还在医院治疗。我坐出租车基本不坐前排,除非是后面有比我更重要的人。而前排没有安全带是极其危险的。
我也曾在购车第12天,下火车站地库转弯的时候,右后门撞到了墙,虽然可以钣金,但还是去换了门。原因主要还是速度。
每一个动作或行为也许都不那么危险,但结果我们往往难以预料,也许是身体的伤害,也许是生命的结束。
对自己如此,对别人也是如此。
上周六,刚下课就接到一个同事电话。客户觉得业务系统性能慢,说是以前一分钟能跑4万笔的业务,现在一分钟只能跑1万笔。原因只是前一天,原厂工程师将其中一个60多G的表从普通表,改为hash partition 表而已。由于这个应用非常复杂,无法定位到某个session,最后只能采用alter system 的方式跟踪(注意,也许是10.2.0.3版本特殊,这种方式开启的跟踪无法用alter system关闭,使用oradebug可以正常关闭,配合ultraedit可以加快关闭速度)。跟踪发现有大量无谓的反复的direct path read。幸好这只是其中一个测试库,比较了对应的开发库,结构变更后的cache选项没有加上。然而,这并没有结束,加上cache后,只是将速度提到一分钟2万笔。
周五接到一个电话,说是由于掉电,导致存储坏了,现在存储由IBM修复好了,数据库起不来了,需要帮助一下。销售人员一个月前去拜访过这个客户,据说在4年前投资了3000万,不仅购买了oracle RAC和IBM小型机,还买了DS4800,且8个EXP810柜子和1个EXP710,但是由于买产品却没买服务,所以系统一直运行的徐徐停停的。EXP810是用来存储地理图片的,数据库存储在EXP710上,一年前的dmp文件40G左右。通过QQ远程连上去看了alert log才发现,这个数据库系统自十天前开始,就没有启动过。进一步与客户沟通,了解到基本情况如下:12号由于机房停电,存储发生故障,19号请IBM工程师到现场修复RAID信息后,除了数据库文件所在的LUNs,其余LUN均可以正常访问。Crs check healthy,ASM instance也能正常启动.
能找到asm disks的路径,但是没有asm的diskgroup.
使用kfed逐一查看asm disks,发现信息全部如下:
kfbh.endian: 201 ; 0×000: 0xc9
kfbh.hard: 194 ; 0×001: 0xc2
kfbh.type: 212 ; 0×002: *** Unknown Enum ***
kfbh.datfmt: 193 ; 0×003: 0xc1
kfbh.block.blk: 0 ; 0×004: T=0 NUMB=0×0
kfbh.block.obj: 0 ; 0×008: NUMB=0×0
kfbh.check: 0 ; 0x00c: 0×00000000
kfbh.fcn.base: 0 ; 0×010: 0×00000000
kfbh.fcn.wrap: 0 ; 0×014: 0×00000000
kfbh.spare1: 0 ; 0×018: 0×00000000
kfbh.spare2: 0 ; 0x01c: 0×00000000
没有任何oracle的信息了。束手无策。如果IBM不能把原始的asd信息恢复,唯一的途径是从1年前的dmp还原,然后慢慢补录了。
这不,快下班了,又接到一个电话,一个测试库由于aud$表增长太快,工程师一不留神把truncate敲成了drop。不过幸运的是,这个表可以重建。
Anyway,就算2012快要到了,大家还是悠着点,该干嘛干嘛,不要慌不要忙。就算一切就有宿命,像稻盛和夫说的,运我们还是可以掌握的!
Recent Comments