【翻译自mos文章】 在错误的从os级别remove掉 trace file 之后,怎么找到该trace file的内容?
2017-05-22 21:45
866 查看
在错误的从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 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
參考原文:
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 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文章]在windows上怎么在os级别跟踪CSS以便诊断OracleCSService的问题?
- 【翻译自mos文章】当/var/tmp文件夹被remove掉之后,GI crash,并启动失败,原因是ohasd can not create named pipe
- 【翻译自mos文章】运行utlpwdmg.sql之后报ORA-28003, ORA-20001, ORA-20002, ORA-20003, ORA-20004 错误
- 【翻译自mos文章】检测并解决datafile os header(Block Zero)的 损坏- - ORA-27047 DBV-107 ORA-1157/ORA-27048
- 【翻译自mos文章】当Oracle Linux 6重启之后,/etc/hosts文件内容被改变了
- 【翻译自mos文章】执行utlpwdmg.sql之后报ORA-28003, ORA-20001, ORA-20002, ORA-20003, ORA-20004 错误
- 【翻译自mos文章】当/var/tmp目录被remove掉之后,GI crash,并启动失败,原因是ohasd can not create named pipe
- 【翻译自mos文章】怎么获得datafile备份的 增长信息
- 【翻译自mos文章】当 在os上的datafile已经不存在的情况下 将该tablespace删除
- 【翻译自mos文章】怎么检查Oracle GoldenGate(OGG)的checkpoint file 是否被locked?
- 【翻译自mos文章】怎么找到OGG Director Server使用的数据库和username?
- [翻译自mos文章]不完全恢复之后,open resetlogs之前,怎么快速的检查数据库是否处于一致性的状态?
- 【翻译自mos文章】怎么找到OGG Director Server使用的数据库和用户名?
- 【翻译自mos文章】SYSAUX表空间里边存放的内容
- 【翻译自mos文章】OUI 的log文件和trace文件的位置
- 【翻译自mos文章】在alter/drop表空间时遇到错误ORA-38301,ORA-00604,purge dba_recyclebin 也不行
- 【翻译自mos文章】在不同au size的asm diskgroup 之间move datafile
- 【翻译自mos文章】升级到11.2.0.4之后在alert日志中出现 NUMA 警告信息
- 【翻译自mos文章】V$BACKUP_DATAFILE 中显示file#=0 有损坏