临时文件file#和db_files的关系

我们在查看临时表空间的当前的使用情况时，可以通过查询v$tempseg_usage得到：

SQL>  select username,user,SQLHASH,SEGFILE# from v$tempseg_usage;
USERNAME             USER                    SQLHASH   SEGFILE#
-------------------- -------------------- ---------- ----------
SYS                  SYS                  1283605935        201
SYS                  SYS                           0        201

很多朋友可能会注意到，临时段的文件号是从201开始的。

这是因为临时文件的绝对文件号是按照db_files + file# 来分配的，缺省的数据库的db_files设置为200，所以第一个临时文件的文件号就是201。

我们看一下实例:

SQL> show parameter db_files
NAME         TYPE        VALUE
------------------------------------ ----------- --------------
db_files     integer     200
SQL> select file#,name from v$tempfile;
FILE#       NAME
---------- -----------------------------------------
1          +ORADG/danaly/tempfile/temp.267.600173887

有时候,我们可能会在警报日志文件中看到类似如下的错误:

***
Corrupt block relative dba: 0x00c0008a (file 202, block 138)
Bad header found during buffer read
Data in bad block -
type: 8 format: 2 rdba: 0x0140008a
last change scn: 0x0000.431f8beb seq: 0x1 flg: 0x08
consistency value in tail: 0x8beb0801
check value in block header: 0x0, block checksum disabled
spare1: 0x0, spare2: 0x0, spare3: 0x0
***

这里的file 202其实指的就是临时文件而非数据文件。

很多时候，v$tempseg_usage.SEGFILE# 会引起大家的困惑，这个字段在文档中的解释是“File number of initial extent”，也就是指临时段的初始区间的文件号，由于一个临时段可以跨越多个临时文件，所以这里的注释是初始区的文件号，如果临时表空间只有一个临时文件，那么这个SEGFILE#也就是临时文件的绝对文件号，这个文件号不同于v$tempfile视图中的文件号（file#）。

临时文件的绝对文件号不能从V$TEMPFILE中得到,但是可以从v$tempfile的底层表x$kcctf （X$KCCTF - Controlfile Temporary File record）中获得。x$kcctf.TFAFN （temp file absolute file number）可以和v$sort_usage.SEGFILE#进行关联。