List Files Opened by an Oracle Process with lsof -p

calendar Apr 28, 2026 / · 5 min read · Oracle Database Unix Commands Oracle DBA lsof Process Diagnostics File Handles Troubleshooting Background Processes  ·
Share on: linkedin copy

List Files Opened by an Oracle Process with lsof -p

Purpose

lsof (LiSt Open Files) is the UNIX tool for inspecting which processes have which files open. For an Oracle DBA it is the fastest answer to four common questions: which datafiles is this server process touching, which trace file is PMON writing into right now, why is df reporting more space used than du, and which library is the database currently mapped against. The one-liner below — taken straight from the shutdownabort.com DBA Quick Guides (Andrew Barry, 2007–2013, preserved via the Wayback Machine as the anchor source for this post) — is the smallest possible invocation: list every file held open by one process, identified by its PID.

Code

1lsof -p <pid>

Breakdown of Code

  • lsof — the binary. Reads /proc/<pid>/fd (Linux) or the kernel's open-file table (other UNIX) for the process(es) you select.
  • -p <pid> — restrict output to the named process ID. Comma-separate to list several, e.g. lsof -p 1234,5678.

The output has nine columns: COMMAND, PID, USER, FD (file descriptor number or kind), TYPE (REG, DIR, CHR, IPv4, ...), DEVICE, SIZE/OFF (size in bytes for regular files, offset for sockets), NODE (inode for files, port for sockets), NAME (path or address). For a typical Oracle dedicated server process you will see hundreds of rows: the executable, every shared library, every open datafile, the redo log group it is writing to, the process's own trace file, and TCP connections back to the client.

How It Works

When the database opens a file it issues an open() system call and the kernel returns a file descriptor. The kernel keeps the open-file record alive until every descriptor pointing at it is closed. lsof -p <pid> walks that table for one process and prints one row per descriptor.

That makes lsof strictly point-in-time: it shows what is open right now. A datafile that the server process opened, read from, and closed five seconds ago will not appear in the output. For long-running diagnostics, run lsof on a loop with watch -n 1 lsof -p <pid> or take repeated snapshots into a file.

Why a DBA cares — three concrete uses

1. Find which trace file a stuck background process is writing to.

Background processes (PMON, SMON, MMON, CKPT, LGWR, ARCH, DBWn) write to per-process trace files in DIAGNOSTIC_DEST/diag/rdbms/<dbname>/<sid>/trace. When one of these processes hangs, you want the trace file fast. Get the OS PID from V$PROCESS, then lsof -p:

1select spid, pname from v$process where pname in ('PMON', 'SMON', 'MMON');

1$ lsof -p 12345 | grep .trc
2oracle  12345 oracle   12u   REG  253,0  4612  ...  /u01/.../trace/scr10_pmon_12345.trc

2. Diagnose "deleted but held open" disk-space leaks.

A common Oracle production incident: someone runs rm on a logfile or audit file the database still has open. The directory entry is gone, but the inode lives until the database closes the descriptor — which often means until the next instance restart. Disk usage goes up (df) but du cannot find the bytes. lsof finds it instantly:

1$ lsof -p 12345 | grep deleted
2oracle  12345 oracle   8u   REG  253,0  104857600  ...  /u01/.../audit_old.log (deleted)

The fix is to close the descriptor (which usually means restarting the affected process) — or simply wait if a database bounce is already on the calendar.

3. Confirm which datafile and redo log a session is touching.

When a session hangs on I/O, find its OS PID via V$PROCESS joined to V$SESSION and run lsof -p. Filter to dbf, arc, log, or ctl to see only Oracle storage files:

1$ lsof -p 12345 | egrep '\.(dbf|arc|log|ctl)$'

This complements V$FILESTAT and the db file sequential read wait events with kernel-level ground truth — useful when the wait history is ambiguous about which file the wait is against.

Key Points

  • Run as oracle (or root) — lsof can only see processes the running user can ptrace or read /proc/<pid>/fd for. Root sees everything; the oracle UNIX user sees Oracle's own processes.
  • The output is a snapshot — repeat the command or use watch for trend data.
  • Performance cost is tiny but non-zero — lsof walks /proc and stats every entry. Avoid running it in tight loops on hosts with many thousands of processes.
  • Use -n for fast output — lsof -nP -p <pid> skips DNS reverse lookups (-n) and port-name lookups (-P). On hosts with broken DNS this is the difference between an instant response and a 30-second hang.

Common Variations

List Oracle's open files across all processes for a given SID — useful for a fleet-wide audit:

1# All processes whose command name starts with "oracle"
2lsof -c oracle
3
4# Only processes belonging to a specific Oracle SID (LD_LIBRARY_PATH-style match)
5ps -ef | grep ora_..._scr10 | awk '{print $2}' | xargs -I{} lsof -p {}

Find every process holding a specific file open (the inverse query):

1lsof /u01/oradata/scr10/system01.dbf

This is invaluable when you cannot drop or move a datafile because "something" still has it open.

Show only network connections for a process:

1lsof -i -a -p <pid>

The -a flag is an AND: it intersects the -i (network) and -p (process) filters.

Important Considerations

lsof prints the path as it was at open time. If a file was renamed after the process opened it, the path shown is the old name. Use the inode column plus find / -inum <inode> to resolve the current path.

On Linux, /proc/<pid>/fd exposes the same information without lsof:

1ls -l /proc/12345/fd | head

This is useful on minimal containers where lsof is not installed. Output format differs (one symlink per FD pointing at the open file or socket), but the data is the same.

For cross-process Oracle storage diagnostics also see DBA_OBJECTS and V$FILESTAT — the database-side view of file activity. lsof and V$FILESTAT together give a complete picture: kernel-level "what is open now" plus database-level "I/O attributed to which file."

References

Posts in this series