1 、故障描述

某次，用户反馈，某核心应用系统突然瘫痪，系统报错信息提示如下：初步判断，同义词指向的对象不存在，可能是权限问题导致。

2 、根因分析

1)         进一步分析

同义词指向的表被删除：经检查发现，多张表（至少 20 多张）被删除；回收站检查：进一步检查回收站，发现所有被删除的表均不在回收站中。

2)         进一步处理

生产库未开启库级别闪回，且没有闪回点。有物理备份和逻辑备份，但恢复时间较长。因当前无法确定删除了哪些表，使用逻辑备份恢复的方式不可行；本地容灾环境同样未开启库级别闪回，没有闪回点（磁盘空间不足，无法保留闪回日志）；异地容灾环境有多个闪回点，找到当天早上 7:15 的闪回点。根据客户确认，当天早上 7:15 的数据是完整的，因此进行闪回操作。异地容灾库以只读模式打开，主库通过 dblink 连接异地容灾库，恢复丢失的表结构（空表）。此时没有做数据回插，是因为还不明确业务表被删除的具体时间点，后面还要做数据前滚，减少数据丢失。业务系统初步恢复。

3)         数据开始补入

通过归档日志挖掘，定位到表删除语句的时间节点： 2024/08/08 07:48:17 。

删除语句格式如下：

   ```sql

     drop table "OWNER_XXX"."TAB_XXX" cascade constraints purge force;

   ```

开始数据前滚，将异地容灾库的数据前滚至 2024/08/08 07:48:10 ，并通过回插方式恢复数据。

4)         故障根因溯源：

DROP 语句发起者定位：通过归档分析日志，定位到发起删除操作的客户端信息：

      `login_username=XXX`

      `client_info=`

      `OS_username=Administrator`

      `Machine_name=WORKGROUP\DESK_XXX`

      `OS_terminal=DESK_XXX`

      `OS_process_id=10728:11620`

      `OS_program_name=PLSQLDev.exe`

通过监听日志，进一步锁定发起者 IP ，经客户方查验，此为电脑为信息科操作机。操作者声明：操作者（信息科人员）表示未手动删除过表，仅在 7:39 删除了一个序列，属于正常维护行为，与故障发生的时间相差 9 分钟。

5)         溯源疑点分析：

删除语句特征：所有 `DROP TABLE` 语句均加了 `CASCADE CONSTRAINTS PURGE FORCE` 后缀，且 `schema` 和 `table_name` 均加了双引号，格式统一，看似不是人为编写，且操作者不具备编写此类复杂 SQL 的能力。如果通过 plsqlDEV.exe 图形界面删除表，表应进入回收站，且生成的 SQL 语句格式不同。

而通过 LOGMNR 日志挖掘，注意到 `DROP TABLE` 语句的 `INFO` 字段为 `INTERNAL DDL` ，而之前删除序列的 `INFO` 字段为 `USER DDL` ，表明这些 `DROP TABLE` 操作并非人工触发，可能是级联操作引发的结果。

6)         根因溯源推测

打开第三方防控软件，发现所在电脑的 plsqlDev.exe 工具执行了 `DROP USER XXX CASCADE` 操作，导致部分表被删除。

推测在 `DROP USER` 过程中操作者点击了取消操作，导致 `DROP USER` 未完全执行成功，只是部分表被删除。由于操作失败， `logmr` 未挖掘到 `DROP USER` 语句。

通过 `plsqlDev.exe` 工具，进行模拟验证操作，选中用户后鼠标右键点击删除，并经过两次“提示确认”后执行操作。

`logmnr` 的 `INFO` 信息显示确实为 `INTERNAL DDL` 。且发起的 drop table 语法一致。

3 、解决方案

本次事件导致业务停摆约 2 小时，业务数据核对过程中少了 5 条记录，后续已补救，未造成数据丢失。

在未查明 `DROP TABLE` 原因前，曾怀疑是 plsqlDEV.exe 中毒或 SQL 注入攻击，客户方已报警，网警已介入调查，多家 IT 合作公司也到现场做了笔录。

建议引入第三方安全平台，对高危操作设置阻断机制；出于数据安全层面，还应考虑数据泄漏等风险。或可使用触发器阻断关键对象的 drop 操作，防止类似事件再次发生。

针对本次事件中的操作失误，操作者予以检讨处罚。应用公司，操作不规范，通过电话方式指导操作者，容易引起误操作。重要信息系统的变更，没有预演，没有准备回退方案。高危操作的时间点选取不当。