删除表空间时发现ORA-1561异常，
通常将type#设置为3即可删除表空间，但是查seg$中没有对象。
奇怪
由于之前对 type# 不太了解，想先深入一下都有哪些segment段类型
seg$可是很底层的数据字典，如何看其说明呢?
初级DBA可能上网搜搜，看是否有人总结过
中级DBA可能去MOS找找，看看官方是否讲
高级DBA直接去rdbms目录下找bsq文件
很快就定位到了
sql
1 = UNDO,
2 = SAVE UNDO,
3 = TEMPORARY,
4 = CACHE,
5 = DATA,
6 = INDEX
7 = SORT
8 = LOB
9 = Space Header
10 = System Managed Undo这里得感谢2009年4月14日罗玛尼克的贡献
然后扩展看了一眼官方文档
里面有SEGMENT_TYPE
问题来了，比seg$里的多出很多
继续看定义，在catspace.sql里找到DBA_SEGMENTS
来自表sys_dba_segs，当然看这些视图的定义还可以通过
DBMS_METADATA.GET_DDL或dba_views查看，但sql文件里可能有注释
第4个字段就是类型，来自几个union all的结果，这里的so是sys_objects
基本上DBA_SEGMENTS里的前12个类型来自sys_objects，即seg里对应的
所以回到问题最初，如果想清理seg中对象是删除记录还是修改类型呢？
我看大家都习惯将type#修改为3，直接手工删除seg中记录是极不好的。
ORA-1561异常说明还有其他对象没清理，可能有别的残存信息，那就要通过10046事件来判断卡在哪里。
sql
alter session set tracefile_identifier='my10046';
alter session set timed_statistics=true;
alter session set statistics_level=all;
alter session set max_dump_file_size=unlimited;
alter session set events '10046 trace name context forever,level 12';
drop tablespace ts1 including contents;
alter session set events '10046 trace name context off';到trc目录下格式化输出文件
发现最后检查失败的sql是
删除表空间时检查的对象涉及很多个底层表，所以最好不要单独手工清理。
内部数据字典不一致，最好用hcheck.sql检查。
家里有26ai的朋友就省事了，可以直接执行DBMS_DICTIONARY_CHECK.full