close_trace命令释放误删trace文件

Applies to:
Oracle Server – Enterprise Edition – Version: 10.2.0.1
Information in this document applies to any platform.
Goal

This article outlines how to truncate a trace file generated by a background process without restarting the database and without breaking the logging mechanism.

In the first place you should investigate why this tracing is being written. If it is due to an event setting then this event needs to be disabled otherwise the tracing will just restart after the file has been truncated.
Solution

1. First identify the process id of the background process in question, in this example I will use LGWR background process:

SQL> select pid, program from v$process where program like ‘%LGWR%’;

PID PROGRAM
———- ————————————————
6 oracle@besun21 (LGWR)

2. Secondly, use oradebug to set the orapid and therby attach to the background process

SQL> oradebug setorapid 6
Unix process pid: 21955, image: oracle@besun21 (LGWR)

3. Rename the trace file at the Operating System level

4. Next close the trace file:

SQL> oradebug close_trace

When the background process needs to write to the trace file again it will create a new logfile.

Applies to:
Oracle Server – Enterprise Edition – Version: 9.2.0 to 10.2.0
Oracle Server – Standard Edition – Version: 9.2.0 to 10.2.0
Information in this document applies to any platform.
Oracle Real Application Cluster
Oracle Rdbms (Single Instance)
Goal

The goal of this document is to help recreate the trace files for background processes (like lmon,lms,pmon,ckpt) which have been deleted or renamed to some other file. There are many reasons why customers delete trace files. Some examples are

* Customers have jobs which go in and delete trace files which have not been written into for X days.
* Lack of space on the file system containing these traces
* Accidental as in file to be deleted was ora_lms1_10945.trc but the command given was rm -r ora_lms1*

In the end, it does not matter why these traces are deleted but the importance of these trace files come up when these trace files are requested by Oracle support for any issue that the customer has opened an Service request for.

It is a bad idea to delete trace files of background processes which are still active. If an automated job has been implemented to remove inactive trace files then it is recommended that the job skips the deleting / archiving or moving of files that are open.
Solution

Oracle RDBMS by itself does not delete any trace files. The process is unaware that the file it is writing to is deleted and continues to write to the file descriptor.

The steps below will help recreate the file however if the steps are performed after the issue then those information is gone. For example lets say

* The trace file for lms is deleted at 14:01
* There is some problem at 14:50 for which customer opens an Service request with Oracle Support
* Support requests the lms trace file
* Customer finds the lms trace file is missing
* Customer recreates the lms trace file at 15:05 following the steps in this Note
* However the information that would have helped to understand the issue at time 14:50 is lost since the trace file will only contain information subsequent to 15:05

Steps to recreate a trace file

1. Find out the process id of the process which was supposed to write trace (ps -ef |grep $ORACLE_SID |grep lms) There can be multiple lms so be sure to find the exact process
2. Login to SQL*plus using “/ as sysdba”
3. SQL>oradebug setospid 4. SQL>oradebug close_trace
5. SQL>oradebug flush
6. SQL>exit
7. Now check the file in the bdump location, a new file would have been created

Caution
Oradebug sends an interrupt to the background process so there is always a chance that something could go wrong. The server process may terminate or report an error when when these steps are executed. Therefore it is recommended to use these steps with caution.