oracle监听日志满了

上周五凌晨，监听我被一通电话从被窝里拽了出来。日志客户那边ERP系统全线卡死，监听登录界面转圈转到天荒地老。日志远程上去一看，监听监听日志文件已经膨胀到12个GB，日志磁盘红线报警器响得跟消防车似的监听。

Oracle监听日志这东西，日志平时没人正眼看它。监听它就在那默默记录每一个连接请求，日志像前台保安在本子上记来访客人名字。监听可这保安有个毛病——从来不清空本子。日志日积月累，监听本子越来越厚，日志直到把办公桌压塌。监听

那天我花了二十分钟定位问题，删掉旧日志，重启监听，系统恢复流畅。客户千恩万谢，我却心里发虚——这治标不治本。下个月呢？下下个月呢？

其实监听日志满这事儿，跟下水道堵塞一个道理。你以为是一块抹布堵了，实际上是日积月累的头发丝、菜叶子、油污凝结成团。每一条连接记录都像一根头发丝，单看微不足道，攒够三个月就能让你半夜爬起来加班。

有个DBA朋友跟我分享过他的土办法——写个crontab脚本，每天凌晨自动把日志文件切割归档，只保留最近七天。听起来简单粗暴，但人家系统三年没出过这毛病。相比之下，那些上了企业级监控平台的大厂，反而偶尔会栽跟头，因为监控告警阈值设得太高，等通知到你手机上时，磁盘早就满了。

还有更隐蔽的坑。有些应用连接池配置不当，每秒钟发起几十次无效重连，监听日志以肉眼可见的速度暴涨。你以为是日志问题，根子上是代码问题。去年我处理过一个案例，某Java应用getConnection()之后忘了close(),连接泄漏导致监听日志两天涨了40GB——这哪是日志问题，这是程序员忘了关水龙头。

处理这问题有个小技巧：别直接删监听日志文件，得用truncate命令清空。直接rm的话，Oracle进程还握着那个文件句柄，磁盘空间不会释放，你删了个寂寞。这细节很多老手都会栽跟头。

日志满了最恶心的连锁反应是——新连接进不来，旧连接超时断掉，整个数据库像被掐住脖子。而应用端的报错五花八门，一会儿ORA-12537，一会儿ORA-3136，排查方向稍偏就能让你绕一整天远路。

我的建议直白点：监听日志这玩意儿，要么配logrotate自动轮转，要么写脚本定时清，总之别让它活着超过一周。别迷信什么"保留审计记录"的说法——真需要审计的话，从归档日志里捞就是了，监听日志那点信息量，撑不起合规审查的门面。

凌晨四点半，我坐在客户机房里，看着清空后的监听日志文件，里面干干净净，一个字节都不剩。窗外天蒙蒙亮，这感觉跟刚扫完大雪的街道似的——清爽，但你知道用不了多久，雪还会落下来。所以扫帚得备好，脚本得写好，该加监控加监控，该设阈值设阈值。

别等到磁盘满了才想起它。这世上大部分技术债，都是"等有空再处理"攒出来的。