杂谈自己做过的与数据库相关的蠢事和收获

第一件蠢事：
在本机上原来有一个数据库实例，做完测试后给删除了，然后建了一个开发服务器上一模一样的实例名字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做这些更专业一点的工作吧，毕竟各有所长:)

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/6517/viewspace-536246/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/6517/viewspace-536246/