前言

众所周知，数据库是一个互联网企业的核心，每个公司都恨不得像守护刚出生的婴儿一样守护着它。但就算是7*24小时监控着，数据库也可能会出现天灾，更不要提一些人祸了。今天就跟大家总结一下我们公司数据库遇到的一些问题。

存储 info 级日志坑

某一天，监控数据显示交易量忽高忽低，没有规律，重灾区是设置交易超时时间的某产品，交易出现大量失败，客户投诉严重。大家聚焦问题，执行代码回滚方案仍无法解决，同时观察数据库现象为事务突然停滞数秒，然后又恢复正常，无时间规律以此反复。DBA 排查存储日志也未见异常 error，同时协调 IBM 分析这些日志，最终反馈有个 info 级日志无规律报某块 disk miss，建议更换硬盘试试，结果更换后交易恢复正常，此故障被 IBM 收集入案例库。

总结：日常巡检不要放过任何细节，info 级别日志也可能是 error 级别，也可能是致命的。

BUG 类高并发短小事务坑

某年考试集中报名，应用频繁出现繁忙，线程报警，导致交易时断时续。查看数据库端负载稍微偏高，事务量是平常的 4 倍多，分析事务量与交易量并不成正比，进一步排查发现执行频率最高的 SQL 达到每秒 2000 次以上。通过一个简单的银行字典查询，开发人员定位问题为此考试接口为定制代码，有多次重复查询 BUG。紧急修复后交易正常。

总结：优化核心交易事务，精简代码，严格控制代码质量。

悲催的各种用尽坑

DBA 发现由于最初的设计原因，交易流水表 ID 使用的是 INT 类型的 sequence，这使得交易流水表 ID很快就会用尽并导致交易停止。于是排查类似的可能用尽的坑，发现数据库日志 SN 居然也能用尽，只有升级版本后才能解决此问题，再一看当前 SN 号一身冷汗，此时推算核心交易库将在半年后用尽 SN 进入只读模式，后果不堪设想。继续探坑又有新发现，LINUX 平台 ETX3 文件系统单文件最大只支持 2T，而线上已经有存到 1.5T。

总结：坑也是无穷无尽的，想不掉下去，那就积极主动探坑吧。

半死不活的硬件故障坑

某日短信通知系统中断，电话应急处理过程中 NOC 反馈未发现任何数据库服务器有可用性报警，但开发反馈应用无法连接数据库，于是 DBA 尝试登录此服务器发现能 ping 通，但 ssh 无法连接。立刻登陆远控卡发现 RAID 卡报错导致系统 hang，执行数据库切换方案后，业务恢复正常。

总结：系统 hang 会导致 Agent 报警，数据无法推送到服务端。报警策略一定要配置采集数据超时时间，避免不能及时发现故障。

交易事务中乱七八糟的其他调用坑

核心交易数据库事务应该是最简洁并且效率最高的 SQL，如果调用其它资源响应时间慢或无响应，会直接影响主线交易。此类操作应做异步处理，此坑已经埋了很多人。

总结：核心交易事务代码必须严格审查，重视不够必进坑。

数据库不可用导致应用无法启动的坑

线上有一些非核心数据库，如归档库，只对外提供历史数据的查询，为节约硬件成本，此库可用性标准 999。偶然一次代码上线过程中，应用启动后 hang 住了，日志无任何输出，问题无从查起。而此时某台历史库正在维护，由此推断是否和数据库有关，查代码后发现果然如此，代码对于数据库异常未做任何处理，无 try catch。此问题如果在上线阶段发生，其后果将是灾难性的。

总结：日志输出一定要遵循软件设计原则，系统日志的缺失对于紧急问题定位是灾难性的。

缺乏沟通的坑

某天晚上接到系统人员通知，数据库不可用，交易中断。接到通知后， DBA 检查数据库状态，发现数据库表空间处于不可用状态。通过检查数据文件和询问系统人员做过什么，得知系统人员维护系统，修改了数据文件的权限，导致数据库不可用。后修改数据文件权限，并前滚数据库，故障恢复。

总结：数据库设备任何变更，都要和 DBA 进行沟通确认，不起眼的失误会导致灾难的发生。

总结

通过以上例子可以发现，一个小小的操作，都可能导致数据库崩溃，造成不可挽回的损失。希望大家一定要遵守各种规范，三思而后行，凡事多想一步。你的一小步，稳定一大步。让我们的运维人员有一个完美的夜生活！