【翻译自mos文章】 在错误的从os级别remove掉 trace file 之后，怎么找到该trace file的内容？

在错误的从os级别remove掉 trace file 之后，怎么找到该trace file的内容？

參考原文：

How to Find the Content of Trace File Generated for an Oracle Process after Removing the Trace File by Mistake at OS Level (Doc ID 805083.1)

适用于：

Oracle Database - Enterprise Edition - Version 8.1.7.4 to 11.2.0.1.0 [Release 8.1.7 to 11.2]

Generic UNIX

Generic Linux





目标：



当错误的从从os级别remove（这个remove是指rm）掉 trace file 之后，oracle进程的trace file 是不会被又一次创建的。



那怎么看到这些trace file的内容？

解决方式：

这样的行为的解释 和解决方式在

Bug 8367394: A NEW TRACE FILE IS NOT BEING CREATED IF THE INITIAL ONE WAS REMOVED



给出了。

--->注意：我看了一下该bug的workground，是restart instance。



在以下的样例中，请注意从11g開始，trace file的位置不在bdump 下。而是在{ADR_HOME}/trace/下。

当进程是alive的时候，进程不会在 trace file上运行close（）函数。

进程依旧持有 指向trace file 的  file descriptor。



trace file 的名字包含进程的pid，

因此，除非进程被重新启动，否则我们不能关闭 file descriptor，也不能创建一个用新文件名称或者老文件名称的新文件





这并不意味着，在紧急情况下，你不能訪问该trace file。

当该trace file 被delete掉后。仅仅要file descriptor依旧open，你就能够获得该文件的内容。该内容依旧被正常写。



通过例如以下方法经过file descriptor 来訪问 file



ps -ef|grep v10204|grep dbw0

oracle 11283 1 0 16:23 ? 00:00:00 ora_dbw0_v10204



lsof -p 11283|grep dbw0

COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME

oracle 11283 oracle REG 3,1 767 20728692 /bdump/v10204_dbw0_11283.trc



从上面的结果中，我们能够看到fd 为2。例如以下也能验证fd 为2



ls -lA /proc/11283/fd | grep dbw0

l-wx------ 1 oracle dba-64 Mar 25 16:24 2 -> /bdump/v10204_dbw0_11283.trc





从os级别 remove掉trace file 。fd 依旧存在，仅仅是file 被delete掉了。



ls -lA /proc/11283/fd | grep dbw0

l-wx------ 1 oracle dba-64 Mar 25 16:24 2 -> /bdump/v10204_dbw0_11283.trc (deleted)



这个fd （file descriptor）在它被关闭 或者 进程被重新启动之前 是存在的。

你能够訪问它的内容：

cat /proc/11283/fd/2 > /tmp/v10204_dbw0_11283.trc