翻译自mos文章 在错误的从os级别remove掉 trace file 之后,怎么找到该trace file的内容?
Posted mfmdaoyou
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了翻译自mos文章 在错误的从os级别remove掉 trace file 之后,怎么找到该trace file的内容?相关的知识,希望对你有一定的参考价值。
在错误的从os级别remove掉 trace file 之后,怎么找到该trace file的内容?
參考原文:
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 2 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
以上是关于翻译自mos文章 在错误的从os级别remove掉 trace file 之后,怎么找到该trace file的内容?的主要内容,如果未能解决你的问题,请参考以下文章
翻译自mos文章设置了RemoveIPC=yes 的RHEL7.2上 会crash掉Oracle asm 实例和Oracle database实例
翻译自mos文章使用aum( Automatic Undo Management) 时遇到 ORA-01555错误--- 原因和解决方式。
翻译自mos文章使用asm来部署 超大数据库(10TB到PB 范围)--针对oracle 10G
翻译自mos文章执行utlpwdmg.sql之后报ORA-28003, ORA-20001, ORA-20002, ORA-20003, ORA-20004 错误