只讀表空間物件被刪除後對應的物件資訊

前面寫了一篇文章，關於DROP USER過程中，查詢DBA_SEGMENTS出現的奇怪的物件資訊。而實際上那篇文章介紹的內容是個意外發現，第一次碰到這個現象是當前的問題所引發的，由於當時來不及記錄，環境就被刪除後。於是在不斷嘗試重現問題的過程中，引發了昨天問題。

DROP USER過程中出現的奇怪的物件資訊：http://yangtingkun.itpub.net/post/468/492422

 

 

記得第一次碰到這個現象時，發現表空間存在很多OWNER為SYS的段，這些段的名稱很奇怪，都是數字組成的。但是當時沒有來得及研究環境就被清除了。唯一可以確定的是，這個問題和當時的DROP USER操作有關。

當然，透過上一篇文章的研究，已經瞭解這種現象的產生原因了。但是這個由FILE_ID和BLOCK_ID構成的物件名稱只是在物件建立或刪除的短暫時間內產生，並不會一直儲存。而當時碰到的情況是這種數字構成的段名並不會消失，而是一直存在。

其實這時原因已經顯而易見了，如果刪除的物件處於一個只讀表空間中，就會出現這種現象：

SQL> alter tablespace ndmain read only;

表空間已更改。

SQL> drop user ndmain cascade;

使用者已刪除。

SQL> set pages 100 lines 120
SQL> col segment_name format a30
SQL> select count(*)
  2  from dba_segments
  3  where tablespace_name = 'NDMAIN';

  COUNT(*)
----------
       327

SQL> select owner, segment_name
  2  from dba_segments
  3  where tablespace_name = 'NDMAIN';

OWNER                          SEGMENT_NAME
------------------------------ ------------------------------
SYS                            16.143303
SYS                            16.138695
SYS                            16.138631
SYS                            16.138567
.
.
.
SYS                            14.391
SYS                            14.327
SYS                            14.135
SYS                            14.7

已選擇327行。

由於DROP USER CASCADE命令刪除了使用者下的所有物件，因此這些物件資訊從資料字典中被清除。但是由於表空間NDMAIN處於只讀狀態，因此資料庫不會真正清除表空間的資料檔案上的資訊，Oracle透過FILE_ID.BLOCK_ID的這種方式來表示這些被刪除的段資訊，而這些資訊的清除將變成延遲事務，記錄在SYS表空間內的系統回滾段中。

SQL> alter tablespace ndmain read write;

表空間已更改。

SQL> select owner, segment_name
  2  from dba_segments
  3  where tablespace_name = 'NDMAIN';

未選定行

當表空間恢復可寫狀態後，Oracle自動清除這個表空間上所有的被刪除的段資訊。