Chinese

猜测背景：
某个测试数据库中，有人在建立表空间的时候将数据文件制定到了$ORACLE_HOME/dbs，而最终导致了oracle的安装目录100%。
随后在释放空间的时候，管理员将该目录下面的几个数据文件删除掉了。当然如果发现的及时，则应该可以挽救。但是这是测试库，平时鲜有人关心。
之后由于硬件故障导致了主机重启，最终导致故障发生。


之后电话通知了我们，发现alert中大量出现：
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x100380A50] [PC:0x4000000003F1E0E0, kcbgtcr()+13184] [exception issued by pid: 3672656, uid: 0]
Errors in file /oracle/app/diag/rdbms/tsdb/tsdb/trace/tsdb_ora_14117.trc (incident=460572):
ORA-07445: exception encountered: core dump [kcbgtcr()+13184] [SIGSEGV] [ADDR:0x100380A50] [PC:0x4000000003F1E0E0] [Address not mapped to object] []
Incident details in: /oracle/app/diag/rdbms/tsdb/tsdb/incident/incdir_460572/tsdb_ora_14117_i460572.trc
而且alert中记录的日志最早是"Mon Aug 13 09:09:03 2012"的，就是说这之前由于空间一直是100%，alert中都没有记录。

推测宕机原因和7445有关。
该数据库是非归档模式。
检查该数据库的状态，为非归档模式。
SQL> archive log list
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination /oracle/app/product/11.1.0/db_1/dbs/arch
Oldest online log sequence 19201
Current log sequence 19203

检查表空间状态:
SELECT r.FILE# AS df#, d.NAME AS df_name, t.NAME AS tbsp_name,
d.STATUS, r.ERROR, r.CHANGE#, r.TIME
FROM V$RECOVER_FILE r, V$DATAFILE d, V$TABLESPACE t
WHERE t.TS# = d.TS#
AND d.FILE# = r.FILE#;

DF# DF_NAME TBSP_NAME STATUS ERROR CHANGE# TIME
---- ------------------------------------------------------------ --------------- ------- ------------------------------ --------------------- ------------
31 /oracle/app/product/11.1.0/db_1/dbs/TBS_ABC1 TBS_ABC RECOVER FILE NOT FOUND 0
32 /oracle/app/product/11.1.0/db_1/dbs/TBS_ABC2 TBS_ABC RECOVER FILE NOT FOUND 0
33 /oracle/app/product/11.1.0/db_1/dbs/TBS_ABC3 TBS_ABC RECOVER FILE NOT FOUND 0
34 /oracle/app/product/11.1.0/db_1/dbs/TBS_ABC4 TBS_ABC RECOVER FILE NOT FOUND 0

这几个数据文件都不存在了。
尝试执行:
drop tablespace tbs_abc include contents and datafiles;
提示表空间不存在。
之后删除数据文件，提示成功，但是执行上面的SQL，还是存在。
alter database datafile '/oracle/app/product/11.1.0/db_1/dbs/TBS_ABC1' offline drop;
alter database datafile '/oracle/app/product/11.1.0/db_1/dbs/TBS_ABC2' offline drop;
alter database datafile '/oracle/app/product/11.1.0/db_1/dbs/TBS_ABC3' offline drop;
alter database datafile '/oracle/app/product/11.1.0/db_1/dbs/TBS_ABC4' offline drop;

为了删除该表空间在数据库中的信息，我手工update了file$和TS$中的和TBS_ABC表空间相关的状态信息，并重启了DB，还是没有效果。
随后就脑残了，由于人为file$的文件编号是可以重用的，于是就手工将这四个数据文件的信息delete了。重启后故障依旧。

dump出了controlfile之后看到了这几个数据文件的信息仍旧存在，本来人为重建控制文件，在重建时候讲这几个datafile信息删除掉应该就能解决问题的。
但是已经将问题提交到了上级，重建控制文件必然导致一些信息的丢失。因此就没有操作。

之后我使用10046对create tablespace和drop tablespace进行了分析，这两个操作只对file$和ts$进行了数据的操作，并未对其他表进行维护。

背景讲完了，我有如下疑问：
1.数据库中的X$类视图的信息是不是都是从??$类的基表中读取的信息而构成的。
2.如果??$的基表信息改变了，那么x$表中的信息在什么情况下会更新？
3.如果像我做的手工将file$中的信息删除了，更新ts$中对应表空间的状态为删除，同时在重建控制文件时候讲对应信息删除后，启动数据库的时候是否会将所有相关的信息自动删除？
4.如果使用hccheck检查一下，出来的不一致情况，要如何进行维护？







。