问题速览
/u01目录使用率超99%，并持续增长，应用无法正常连接数据库。
-
应急处理：安全备份并清理历史审计日志，快速恢复业务。 -
扩容加固：将/u01目录从100G扩容至300G，为排查和调整预留缓冲空间。
-
根治优化：配合DRS要求的归档保留策略调整，同步扩容归档目录，让归档目录使用率保持在备份脚本触发阈值已下，从根本上杜绝问题复发。
中亦工程师的深度诊断
客户的信任源于中亦工程师团队清晰、专业的排查思路。面对问题，我们是如何一步步锁定“真凶”的？
1. 排障第一步：确认空间占用元凶
通过df-g命令，我们迅速确认是/u01目录被占满。该目录是oracle的家目录，通常存放Oracle二进制文件和审计日志，继续排查定位到/u01/app/oracle/admin/<DB_NAME>/adump目录下的审计日志文件占用了大量的空间，并且大多数审计日志都是近期产生的，第一步就锁定了重点怀疑对象。
2. 关键洞察：发现规律性的审计记录
我们检查了审计日志内容，发现大量记录来自oracle用户以SYSDBA身份连接，并定期执行一系列查询v$instance、v$database等动态性能视图和调用dbms_backup_restore、dbms_rcvman包的操作。经分析确认，这些审计日志都是NBU调用Rman产生的。
更重要的是，这些操作每5分钟就规律性地产生一批。这强烈暗示了某个定时任务正在执行。
3. 溯源归因：揪出“幕后”的脚本
通过crontab-l命令，我们发现了每分钟执行一次的归档清理脚本/home/oracle/scripts/delarch.sh。
分析计划任务和NBU的归档备份脚本后发现：
脚本逻辑是判断归档目录/arch的使用率。若使用率超过60%，就调用NBU（NetBackup）脚本对归档日志进行备份并删除；若使用率低于60%，脚本就什么都不做直接退出。
原本的NBU归档备份脚本逻辑是：BACKUP XXX ARCHIVELOG ALL DELETE INPUT（备份归档后删除所有已备份的归档文件）
部署DRS后，客户将NBU归档备份逻辑改成：先BACKUP ARCHIVELOG ALL NOT BACKED UP;然后DELETE ARCHIVELOG COMPLETED BEFORE ‘SYSDATE -2’（即使归档已经备份，也要求在本地再保留2天的时间）
定时任务每5分钟运行一次，正常情况下会先备份归档，然后清理所有已备份过的归档。将/arch的使用率从60%直接清理到0%，这样后续定时任务检测/arch使用率未到清理阈值（60%），就会跳过备份过程，直接退出。
由于部署DRS的要求，客户修改了NBU的归档备份脚本，在本地保留了2天的归档。所以即使清理完成，/arch的使用率依旧在60%以上，造成定时任务每次运行都要调用NBU备份归档。
每次RMAN备份操作都会被数据库审计策略记录，从而产生了大量看似“正常”的审计日志。
至此，真相大白：DRS同步 → 修改归档删除策略 → 归档备份脚本无法清理归档目录到阈值以下 → 每次计划任务都要触发RMAN备份动作 → RMAN操作产生大量审计日志 → 占满 /u01 空间 → 数据库异常。
中亦的解决之道
既治标，亦治本
中亦的解决方案从不满足于“救火”，更追求系统性的稳健。
应急处理（治标）：
-
立即安全备份当前审计日志以供后续分析。 -
清理历史审计日志文件，快速释放空间，恢复业务。（操作前务必进行备份！） 容量加固（缓冲）：将/u01文件系统在线扩容至300G。这为后续的问题彻底排查和策略调整提供了宝贵的时间窗口，避免了在调整过程中再次爆满的风险。
策略优化（治本）：
-
我们协助客户重新评估了/arch目录所需的大小，完成扩容； -
综合考虑DRS同步所需的归档日志保留周期、NBU备份窗口及存储成本，重新设合理的RMAN保留策略和备份触发条件，避免了不必要的、高频的备份操作，从根源上消除了审计日志的暴增问题。
如果您也遇到棘手的数据库性能或运维难题，欢迎联系我们！
