雜談自己做過的與資料庫相關的蠢事和收穫

第一件蠢事：
在本機上原來有一個資料庫例項，做完測試後給刪除了，然後建了一個開發伺服器上一模一樣的例項名字inxite，然後拿來做新的測試，結果一不小心在sys/inxite後面加了個@inxite，就給shutdown了，這下子開發人員做不了開發了；等他們叫的時候，我就給重啟了一下，才知道關錯了，沒好意思說自己錯了，呵呵！
結論：資料庫操作無小事，萬事應該小心謹慎。如果是正式環境的話，就會造成事故了。

第二件蠢事：
起因：
其實問題出來很早，一直沒去認真思考過罷了，在建立表、維護記錄的時候速度還可以，但是在drop table的時候經常要等待5分鐘，原來以為是做審計的緣故，就把審計給停了，結果還是很慢，後來就不了了之了。
也是因為今天誤關了資料庫，所以登陸到資料庫伺服器上看看去，結果發現windows日誌表保留了一大堆應用日誌之類的，怕日誌把把系統盤撐爆，就到系統盤上看看，結果發現只剩下1.7g的空間了，找了半天發現是SYSTEM01.DBF資料檔案已經變成11個G了。
先執行了一下以下語句，首先找到看看是哪個大表吧。
select segment_name,sum(bytes) sumbytes
from dba_extents
where tablespace_name='SYSTEM'
group by segment_name
order by sumbytes desc
結果找到了aud$表，發現竟然佔了10G的空間
看了一下這個表的內容，然後google了一下，該系統表可以刪除，就把aud$表給truncate了
然後執行
alter database datafile 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\INXITE\SYSTEM01.DBF' resize 500m;
想直接把資料檔案壓縮一下。結果系統資料包錯誤
ORA-03297: 檔案包含在請求的 RESIZE 值以外使用的資料
查查原因唄，就Google了一下，查詢一下system資料檔案，目前高水平線的位置的大小、當前system資料檔案的大小，兩者相減之後就是可以節省的空間
select file_name,
  ceil( (nvl(hwm,1)*8192)/1024/1024 ) smallest,
  ceil( blocks*8192/1024/1024) currsize,
  ceil( blocks*8192/1024/1024) -
  ceil( (nvl(hwm,1)*8192)/1024/1024 ) savings
  from dba_data_files a,
  ( select file_id, max(block_id+blocks-1) hwm
  from dba_extents
  group by file_id ) b
where a.file_id = b.file_id(+) and file_name like '%SYSTEM%'

結果大失所望，只能減少200M的空間對10g來說簡直是杯水車薪。
諮詢和google了一下，查檢視看那個表處於比較高的水平線上
select *
 from (
 select owner, segment_name,
       segment_type, block_id
  from dba_extents
 where file_id =
  ( select file_id
      from dba_data_files
     where file_id = 1 )  --用你的DATAFILE代替
     order by block_id desc
  )
where rownum <= 5
結果如下：
OWNER SEGMENT_NAME SEGMENT_TYPE BLOCK_ID
SYS C_OBJ#_INTCOL# CLUSTER 1281033
SYS I_OBJ#_INTCOL# INDEX 649681
SYS OBJAUTH$ TABLE 649673
SYS I_CON1 INDEX 649665
SYS SYN$ TABLE 649657
主要是C_OBJ#_INTCOL#這個聚簇段佔用的塊的位置的太大了，得想辦法把這個聚簇表的資料幹掉
首先得先知道這個聚簇段在哪個表吧
select * from dba_clu_columns where cluster_name='C_OBJ#_INTCOL#'
結果就是這個HISTGRM$系統表，這個表是記錄各個業務表的資料分佈情況的，應該可以刪除
想當然
truncate table HISTGRM$;
結果卻是：
ora-14512:不能對聚集物件進行操作
ora-00701：無法改變熱啟動資料庫所需的物件
再換個方法用ALTER TABLE MOVE的方法來看看能不能減少表佔用的空間
ALTER TABLE HISTGRM$ MOVE;
錯誤跟上面一樣:(
真的沒轍了，再去google一下
找到了http://blog.違規廣告.cn/baishan3/?cat=General&date=20081002
上面還真的可以對這個系統表進行處理
大意是說修改一下event級別，然後重新啟動後即可
alter system set EVENT="38003 trace name context forever, level 10" 2 SCOPE=SPFILE;
沒敢測試，好不容易搞了還原了100多個G的測試資料，怕給搞崩了。

算是一次不成功的經歷吧！

總結一下：
1、學習了dba_extent的真正用法
2、知道了高水平線的真正意圖，表有高水平線，那麼表空間是所有表的高水平線的最大集
3、知道了如何找到可以收縮資料檔案的方法以及如何量化可收縮的容量
4、學習了dba_clu_columns，知道了如何找到某些非表段對應的物件
5、知道了審計不能隨便亂開的
6、知道了系統安裝時需要認真做磁碟規劃和容量估算
7、知道了做DBA工作還是很煩的，需要一條線跟到底還不一定能成功
7、最重要的一點還是找DBA做這些更專業一點的工作吧，畢竟各有所長:)