1.发现问题
这里看到文件号为201，但是查询了v$datafile和v$tempfile视图都没有文件号为201

SQL> select username,segtype,segfile#,segblk#,extents,segrfno# from v$sort_usage;

USERN SEGTYPE     SEGFILE#    SEGBLK#    EXTENTS   SEGRFNO#
----- --------- ---------- ---------- ---------- ----------
SYS   SORT             201     260745        650          1

SEGFILE#  NUMBER  File number of initial extent 

SEGRFNO#   NUMBER  Relative file number of initial extent 

SQL> SELECT FILE#,RFILE# FROM V$DATAFILE;

     FILE#     RFILE#
---------- ----------
         1          1
         2          2
         3          3
         4          4
         5          5
         6          6
         7          7
         8          8
         9          9
        10         10
        11         11

     FILE#     RFILE#
---------- ----------
        13         13
        14         14

13 rows selected.

SQL> SELECT FILE#,RFILE# FROM V$TEMPFILE;

     FILE#     RFILE#
---------- ----------
         1          1

2.查看v$sort_usage的原始表

SELECT USERNAME,
       USERNAME,
       KTSSOSES,
       KTSSOSNO,
       PREV_SQL_ADDR,
       PREV_HASH_VALUE,
       PREV_SQL_ID,
       KTSSOTSN,
       DECODE(KTSSOCNT, 0, 'PERMANENT', 1, 'TEMPORARY'),
       DECODE(KTSSOSEGT,
              1,
              'SORT',
              2,
              'HASH',
              3,
              'DATA',
              4,
              'INDEX',
              5,
              'LOB_DATA',
              6,
              'LOB_INDEX',
              'UNDEFINED'),
       KTSSOFNO,
       KTSSOBNO,
       KTSSOEXTS,
       KTSSOBLKS,
       KTSSORFNO
  FROM X$KTSSO, V$SESSION
 WHERE KTSSOSES = V$SESSION.SADDR
   AND KTSSOSNO = V$SESSION.SERIAL#
   and inst_id = USERENV('Instance')

这里没有发现有用信息，只是知道X$KTSSO.KTSSOFNO是v$sort_usage.SEGFILE#，通过v$sort_usage视图是查询临时表空用来排序的数据文件使用情况。所以把问题定位在v$tempfile视图中，检查它为什么没有显示文件号为201的文件

3.查看v$tempfile视图

SELECT TF.TFNUM,
       TO_NUMBER(TF.TFCRC_SCN),
       TO_DATE(TF.TFCRC_TIM,
               'MM/DD/RR HH24:MI:SS',
               'NLS_CALENDAR=Gregorian'),
       TF.TFTSN,
       TF.TFRFN,
       DECODE(BITAND(TF.TFSTA, 2), 0, 'OFFLINE', 2, 'ONLINE', 'UNKNOWN'),
       DECODE(BITAND(TF.TFSTA, 12),
              0,
              'DISABLED',
              4,
              'READ ONLY',
              12,
              'READ WRITE',
              'UNKNOWN'),
       FH.FHTMPFSZ * TF.TFBSZ,
       FH.FHTMPFSZ,
       TF.TFCSZ * TF.TFBSZ,
       TF.TFBSZ,
       FN.FNNAM
  FROM X$KCCTF TF, X$KCCFN FN, X$KCVFHTMP FH
 WHERE FN.FNFNO = TF.TFNUM
   AND FN.FNFNO = FH.HTMPXFIL
   AND TF.TFFNH = FN.FNNUM
   AND TF.TFDUP != 0
   AND BITAND(TF.TFSTA, 32) <> 32
   AND FN.FNTYP = 7
   AND FN.FNNAM IS NOT NULL
   and inst_id = USERENV('Instance')

从这里可以看出v$tempfile.file#出自X$KCCTF.TFNUM

4.继续查看X$KCCTF表

SQL> desc X$KCCTF
 Name                                      Null?    Type
 ----------------------------------------- -------- -------------
 ADDR                                               RAW(8)
 INDX                                               NUMBER
 INST_ID                                            NUMBER
 TFNUM                                              NUMBER
 TFAFN                                              NUMBER
 TFCSZ                                              NUMBER
 TFBSZ                                              NUMBER
 TFSTA                                              NUMBER
 TFCRC_SCN                                          VARCHAR2(16)
 TFCRC_TIM                                          VARCHAR2(20)
 TFFNH                                              NUMBER
 TFFNT                                              NUMBER
 TFDUP                                              NUMBER
 TFTSN                                              NUMBER
 TFTSI                                              NUMBER
 TFRFN                                              NUMBER
 TFPFT                                              NUMBER
 TFMSZ                                              NUMBER
 TFNSZ                                              NUMBER

这里发现一列TFAFN，初步怀疑这个才是真正的绝对文件号。

5.证明X$KCCTF.TFAFN是绝对文件号

SQL> select TFAFN,TFNUM from X$KCCTF;

     TFAFN      TFNUM
---------- ----------
       201          1

如果证明X$KCCTF.TFAFN才是真正的文件号，而TFNUM是临时文件的文件号

6.temp file绝对文件号结论
再进一步可以知道，实际上，为了分离临时文件号和数据文件号，Oracle对临时文件的编号以db_files为起点，所以临时文件的绝对文件号应该等于db_files+file#。

SQL> show parameter db_files;

NAME                                 TYPE        VALUE
------------------------------------ ----------- --------
db_files                             integer     200

在很多时候，检查系统时候发现，由于某个Oracle的trace文件导致磁盘空间告警，因为业务需要不能让数据库down下来。这个时候你想到的方法可能是直接删除掉这个trace文件，如果是win系统，那恭喜你这样做可以解决问题；如果是linux/unix系统，那就等着事故的发生吧。在linux/unix中，如果直接rm掉oracle进程的某个文件(该进程还存在)，文件句柄不会释放，即磁盘使用空间不会释放。可以通过df命名看到磁盘的空间释放释放。下面通过对lgwr进程的一系列操作，使用oradebug来释放oracle进程句柄，从而达到释放oracle某个被删除的trace文件的磁盘空间
一、查找lgwr进程的trace文件

[oracle@localhost /]$ cd $ORACLE_BASE/admin/$ORACLE_SID/bdump
[oracle@localhost bdump]$ pwd
/opt/oracle/admin/mcrm/bdump
[oracle@localhost bdump]$ ls -l|grep lgwr
-rw-r----- 1 oracle oinstall 32133 Dec 22 21:00 mcrm_lgwr_3485.trc
-rw-r----- 1 oracle oinstall  3713 Oct  8 07:13 mcrm_lgwr_3489.trc
-rw-r----- 1 oracle oinstall 22507 Mar  3 06:00 mcrm_lgwr_3598.trc
-rw-r----- 1 oracle oinstall  8441 Sep 15 10:29 mcrm_lgwr_4963.trc
[oracle@localhost bdump]$ ps -ef|grep lgwr
oracle    1056 30718  0 21:10 pts/3    00:00:00 grep lgwr
oracle    3598     1  0  2011 ?        00:04:10 ora_lgwr_mcrm
[oracle@localhost bdump]$ df |grep /opt
/dev/sda6             37798668  33312588   2534988  93% /opt
[oracle@localhost bdump]$ du -s .
948     .

从这里得出几点结论：
1.当前lgwr进程的spid为：3598
2.当前lgwr进程产生的trace文件大小为：22507B
3.包含该trace文件的分区大小使用大小为：33312588KB
4.bdump目录大小为：948KB

二、删除lgwr进程对应trace文件

[oracle@localhost bdump]$ rm mcrm_lgwr_3598.trc
[oracle@localhost bdump]$ du -s .
924     .
[oracle@localhost bdump]$ df |grep /opt
/dev/sda6             37798668  33312588   2534988  93% /opt

[oracle@localhost bdump]$ ls -l /proc/3598/fd|grep lgwr   
l-wx------ 1 oracle oinstall 64 Mar  3 20:54 2 -> /opt/oracle/admin/mcrm/bdump/mcrm_lgwr_3598.trc (deleted)

从这里得出结论：
1.bdump目录当前大小变为：924KB(大约等于948KB-22507B)
2.包含该trace文件的分区大小使用大小依然为：33312588KB(没有因为删除trace文件而释放空间)

三、释放被删除trace文件空间

[oracle@localhost bdump]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 - Production on Sat Mar 3 21:12:41 2012

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> !ls -l /proc/3598/fd|grep lgwr  
l-wx------ 1 oracle oinstall 64 Mar  3 20:54 2 -> /opt/oracle/admin/mcrm/bdump/mcrm_lgwr_3598.trc (deleted)

SQL>  oradebug setospid 3598
Oracle pid: 6, Unix process pid: 3598, image: oracle@localhost.localdomain (LGWR)
SQL> oradebug flush;    
Statement processed.
SQL> oradebug close_trace;
Statement processed.
SQL> !ls -l /proc/3598/fd|grep lgwr  

SQL> !df |grep /opt
/dev/sda6             37798668  33312564   2535012  93% /opt

SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

从这里可以得出结论：
1.包含该trace文件的分区大小使用大小为：33312564KB(大约等于948KB-22507B)
2./proc/spid/fd下面的句柄已经释放
3.总这里可以看出使用oradebug可以真正释放oracle进程磁盘使用空间