条码打印软件的错误日志涨到 30GB——根因不是硬盘不够，是免费版数据库触了顶
Bartender（条码标签打印软件）配套的 SQL Server，错误日志文件（ERRORLOG）在没人特别留意的情况下涨到了 30GB。发现的时候第一反应是先止血：把现有日志文件挪到别的位置腾出磁盘空间，让系统生成一份新的错误日志，再联系软件供应商的支持团队排查根因，尤其想确认最近是不是有什么改动触发了这个症状。
根因不在磁盘，在一张早就”满员”的数据库
供应商支持团队翻查错误日志内容后给出的诊断很干脆：这套系统背后的数据库（Datastore）已经撞上了 SQL Server Express 版本强制施加的容量上限。日志里反复出现的是两类报错：
Error: 1827——“CREATE DATABASE 或 ALTER DATABASE 失败，因为结果累积数据库大小将超出每数据库 10240 MB 的授权上限”；Error: 1101——“无法为 ‘Datastore’ 数据库分配新页，因为文件组中磁盘空间不足”。
Express 版对单个数据库有一条硬性容量红线（10GB），业务系统（打印任务日志、消息记录）却在持续写入。写入被数据库引擎拒绝之后,应用层没有停下来,而是把每一次被拒绝的写入都当作一条新的错误,继续记进 SQL Server 的错误日志里。数据库本体被死死卡在容量上限动弹不得,但日志文件却完全没有这层限制,于是变成了一个安静却持续的循环:业务照常尝试写入 → 数据库拒绝 → 错误日志多记一行 → 反复上万次 → 日志文件涨到 30GB。30GB 的膨胀,源头是一张被卡死在 10GB 上限的数据库,不是磁盘性能或者容量本身的问题。
修复分三步,治标 + 治本
第一步,给数据库腾空间:用 SQL Server Management Studio 对 Datastore 数据库执行 Shrink(收缩),释放已分配但未使用的空间;同时把数据库的恢复模式改成 Simple,避免事务日志跟着继续膨胀。
第二步,清理业务侧的历史数据,这才是真正的治本:通过 Bartender 自带的 Administration Console,找到 System Database → Administrative Tasks 里的 Purge Records(清除记录)功能,先手动清一轮积压的历史打印任务记录和消息日志,再配置一个每日自动执行的维护计划,让老旧的日志数据按周期自动清理(可选归档)。这里有一个容易被误解的细节值得记住:清除的只是打印任务日志和消息记录,存放在 Librarian 里的实际文件不受影响——业务数据和运行日志是分开存放的,清理日志不会误删归档文件。
第三步,为后续的日常维护单独开了两个 SQL 账号,专门用于执行这类收缩/清理操作,不需要每次都用系统管理员账号登录处理。
被”卡住”的是数据库，真正”涨起来”的是错误日志——两者是同一个根因的两种症状
教训
- 一个文件的体积异常增长,不要只看这个文件本身,要看它记录的内容在说什么——30GB 的错误日志不是”日志系统坏了”,而是数据库在忠实记录一件持续发生的失败:一次写入被拒绝,就是一行日志;
- 用了 SQL Server Express 版的系统,要主动知道并盯住它的容量上限——Express 版单库 10GB 的红线是设计使然、不是 bug,业务数据量会随时间自然增长,提前排期做数据清理或考虑升级到付费版,好过等撞线了才处理;
- 应用层的业务清理和数据库层的空间释放是两件事,缺一不可——只做 Shrink 不清理历史数据,过一段时间数据库还会重新撞上容量线;只清理历史数据不 Shrink,已分配的磁盘空间也不会自动还给系统;
- 把清理动作从”手动做一次”升级成”排期自动做”——业务系统的日志、任务记录这类会持续累积的数据,配一条定期维护计划,比每次等它长到吓人再手动处理省心得多。