Alert Log中回收站物件操作告警

 

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執行的任務中出現報錯呢？一種猜想是在排程任務中，檢視對資料表或者索引（回收站）中進行整理或者處理，引發了報錯資訊。處理方法也比較簡單，如果頻繁出現，可以考慮將回收站清空。