共计 4063 个字符，预计需要花费 11 分钟才能阅读完成。
Alert Log 是我们进行日常巡检、故障调整和问题发现的重要研究对象。通过对数据库 Alert Log 的研究分析，很多问题都可以得到比较全面的掌握，我们也可以从中获得很多知识。
1、问题说明
在笔者观察的一台数据库中，Alert Log 出现如下信息：
Thu Oct 06 22:00:00 2016
Setting Resource Manager plan SCHEDULER[0x3006]:DEFAULT_MAINTENANCE_PLAN via scheduler window
Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter
Thu Oct 06 22:00:00 2016
Starting background process VKRM
Thu Oct 06 22:00:00 2016
……
Thread 1 advanced to log sequence 22 (LGWR switch)
Current log# 1 seq# 22 mem# 0: D:\APP\ADMINISTRATOR\ORADATA\DATAGATHER\REDO01.LOG
Thu Oct 06 23:04:31 2016
performing DML/DDL operation over object in bin.
performing DML/DDL operation over object in bin.
performing DML/DDL operation over object in bin.
Thu Oct 06 23:04:54 2016
performing DML/DDL operation over object in bin.
Fri Oct 07 00:39:20 2016
Thread 1 advanced to log sequence 23 (LGWR switch)
Current log# 2 seq# 23 mem# 0: D:\APP\ADMINISTRATOR\ORADATA\DATAGATHER\REDO02.LOG
Fri Oct 07 02:00:00 2016
Clearing Resource Manager plan via parameter
在夜间的 23 点前后，出现了“performing DML/DDL operation over object in bin”。从前后的日志信息看，这个时间段试进行资源管理（Resource Manager）夜间任务的时间段。
虽然没有明显的问题故障点，但是还是值得研究的题目。
2、分析说明
Oracle 从 10g 开始，就不断推动以 Flashback 为主线的非备份数据还原技术。从 Flashback Query、Flashback Drop 到 Flashback Database，都是建立在不同底层技术上的数据恢复技术。日志中出现的 bin 结构，也就是 Flashback Drop 所涉及的回收站。
回收站 Recycle bin 的原理很简单，就是当我们发出 Drop 数据段对象的时候，Oracle 并不是直接将数据段删除。而是通过改名 Rename 的动作隐藏在存储空间中。用户可以根据自己的情况将数据表 Flashback 回来。回收站的空间在紧张的时候，会自动进行回收处理。
从日志的信息看，Oracle 的意思是说不允许对回收站中的对象进行 DDL 和 DML 操作。下面通过系列实验进行说明，我们使用数据库版本为 11.2.0.1。
SQL> select * from v$version;
BANNER
——————————————————————————–
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – 64bit Production
PL/SQL Release 11.2.0.1.0 – Production
CORE 11.2.0.1.0 Production
TNS for 64-bit Windows: Version 11.2.0.1.0 – Production
NLSRTL Version 11.2.0.1.0 – Production
创建数据表 t 以及对应索引段。
SQL> select count(*) from recyclebin;
COUNT(*)
———-
0
SQL> create table t as select * from all_objects;
Table created
SQL> select count(*) from t;
COUNT(*)
———-
55617
SQL> create index idx_t_id on t(object_id);
Index created
删除 drop 对象，可以看到回收站中信息。
SQL> drop table t;
Table dropped
SQL> select object_name, original_name, type, operation from recyclebin;
OBJECT_NAME ORIGINAL_NAME TYPE OPERATION
—————————— ——————————– ————————- ———
BIN$/jnbfhsfQdC3s6sz0KECvQ==$0 T TABLE DROP
BIN$PsNuoiu2THyEmeMaVfxKRg==$0 IDX_T_ID INDEX DROP
注意：此时使用删除对象的新名字，是可以检索数据的。
SQL> select count(*) from “BIN$/jnbfhsfQdC3s6sz0KECvQ==$0”;
COUNT(*)
———-
55617
SQL> explain plan for select * from “BIN$/jnbfhsfQdC3s6sz0KECvQ==$0” where object_id=1000;
Explained
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
——————————————————————————–
Plan hash value: 2098445206
——————————————————————————–
| Id | Operation | Name | Rows | B
——————————————————————————–
| 0 | SELECT STATEMENT | | 1 |
| 1 | TABLE ACCESS BY INDEX ROWID| BIN$/jnbfhsfQdC3s6sz0KECvQ==$0 | 1 |
|* 2 | INDEX RANGE SCAN | BIN$PsNuoiu2THyEmeMaVfxKRg==$0 | 1 |
——————————————————————————–
Predicate Information (identified by operation id):
—————————————————
2 – access(“OBJECT_ID”=1000)
Note
—–
– dynamic sampling used for this statement (level=2)
18 rows selected
说明：数据表和索引结构，在 Oracle 中都是被识别认可的。甚至在执行计划生成过程中，索引都是被接受的。
但是，如果尝试进行 DDL 或者 DML 操作，就会报错。
SQL> delete from “BIN$/jnbfhsfQdC3s6sz0KECvQ==$0”;
delete from “BIN$/jnbfhsfQdC3s6sz0KECvQ==$0”
ORA-38301: 无法对回收站中的对象执行 DDL/DML
SQL> drop table “BIN$/jnbfhsfQdC3s6sz0KECvQ==$0”;
drop table “BIN$/jnbfhsfQdC3s6sz0KECvQ==$0”
ORA-38301: 无法对回收站中的对象执行 DDL/DML
注意：每一次在进行 DDL 或者 DML 操作的时候，Oracle 都会将这个信息实时的写入到 alert log 中。
Sun Oct 09 18:29:30 2016
performing DML/DDL operation over object in bin.
Sun Oct 09 18:50:59 2016
performing DML/DDL operation over object in bin.
3、结论和解决
那么，为什么会在 Resource Manager 运行的任务中出现报错呢？一种猜想是在调度任务中，视图对数据表或者索引（回收站）中进行整理或者处理，引发了报错信息。处理方法也比较简单，如果频繁出现，可以考虑将回收站清空。
更多 Oracle 相关信息见 Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2016-10/136039.htm
