每天就是一次艰苦的旅行

每天的工作都好像一次一场艰苦的旅行.

旅行的开始似乎还算轻松: 上个周日宕机之后暴露了很多问题,这几天的任务就是逐渐消除这些问题.上午调试用来备份的 Shell 脚本, 一个弱智的错误浪费好多时间. 测试成功之后,照葫芦画瓢修改其他Script. 这中间还要面对开发人员 N 次的打扰, 还要参加一个会议,接发若干封邮件.跟进厂商对上次宕机问题的调查.这样一个上午就过去了.

中午休息的时候可以看看”风景”: 发现 Google 发布了 IM 工具, 这远比看到传言公司回购员工股票令人心动:毕竟 Google Talk 比股票更容易接近. 还看到了MSN 发布了 7.5 的版本. 有更多的人参加到 评论 Don 文章的队伍中.CNOUG 还是没有恢复,不知道是被黑了还是临时关掉了站点.最近流传的“怪癖 BLOG 病毒”也蛮无聊的, BLOG 世界毕竟脱离不开现实.

从下午开始麻烦多多.正式备份的时候该死的 NFS Server 又 Hang 住了.紧接着 Standby 数据库的操作系统也完蛋了.只观察到等待比较高.一会儿的功夫,系统已经不接受任何命令了.不接受新的连接.只好登录到 HMC 上重新启动 .

系统重新启动之后,snap -ac 收集 Snap 信息.恶心就恶心在这个地方,耗费了大量的时间,偏偏应用人员这个时候还拿来需求要立刻做.想想 AIX 上收集 Snap 呢,问题应该不大.先把开发人员打发了再说.没想到,这个时候问题已经出现了.等我空下来,观察主库的 alert_{SID}.log,居然发现有个特定序号的归档没创建成功,比这个序号大的归档都已经创建在本地了.手工切换归档,不成功;查看日志, 报告 Standby 监听找不到,查看 Standby 的监听,明明是启动的.再看主库上,新的归档又生成了,按照经验,在过一会儿, DB 有 Hang 的危险, 看看 Biti 在线,赶紧要他上来……先花了不少时间,确定Standby 的监听可用,但是主库的问题还是没有解决.又过了大约半个小时,感觉弄不好要出大乱子,赶紧请 Rudolf 也上来……

最艰难的时段开始了:ARC0 进程把 REDO 文件加了个锁,而自己不知道在做什么,从操作系统的进程中看,似乎并没有僵死……这个时候是一天中交易量比较大的时候,万一系统不可用,麻烦就大了……

等到把问题解决,看看都 23 点了,不知不觉好几个小时都过去了.长出了一口气.忽然感觉很累.

收拾东西,回家.在楼下的时候看到有个电视剧组在排戏,没心情看啦,打个车回家.这就是一个 DBA 一天的生活, 你说,有趣么?