🧩 ORA-27037: Unable to Obtain File Status

🧩 Introduction

The error ORA-27037: unable to obtain file status occurs when Oracle cannot access or determine the status of a file at the operating-system level. It commonly appears during backup/restore, datafile operations, or when Oracle tries to read a file that has become missing, inaccessible, or corrupted. Resolving it quickly is important because the database may be unable to read or write critical files.

Root causes

1. The file path referenced by Oracle does not exist (file deleted or moved).

2. Incorrect file permissions or ownership prevent Oracle from stat’ing the file.

3. Filesystem or mount point is unavailable (unmounted, read-only, or NFS/ASM issues).

4. Symbolic link pointing to a missing target.

5. ASM diskgroup or device is offline (for ASM-managed files).

6. OS-level resource limits or quota preventing access.

7. Hardware or I/O subsystem problems causing OS errors when accessing the file.

How to diagnose

1. Inspect the full error text and alert log — Oracle usually prints the path and an OS error number.

2. On the database server, check the file reported in the error:

ls -l /path/to/file

3. Verify filesystem and free space:

df -h /path/to

mount | grep /path/to

4. If the file is on ASM, use ASMCMD to list the file:

asmcmd lsdskgroup

asmcmd ls +DATA/yourfile.dbf

5. Check file permissions and ownership:

stat /path/to/file

ls -ld /path/to/directory

6. Review OS messages for I/O errors:

dmesg | tail -50

journalctl -k | tail -50

7. If RMAN involved, run:

RMAN> CROSSCHECK DATAFILE ALL;

RMAN> LIST BACKUP SUMMARY;

Solutions (step-by-step)

1. Confirm file existence and path. If the file was moved, either move it back or update the controlfile:

ALTER DATABASE RENAME FILE '/old/path/file.dbf' TO '/new/path/file.dbf';

2. If file is missing and you have a backup, restore it with RMAN:

RMAN> RESTORE DATAFILE <file#>;

RMAN> RECOVER DATAFILE <file#>;

3. Fix permissions/ownership so the Oracle OS user can access the file:

chown oracle:dba /path/to/file

chmod 660 /path/to/file

4. Remount or make the filesystem available if it’s unmounted or read-only:

mount /dev/vol /u01

mount -o remount,rw /u01

5. For ASM-managed files, ensure the diskgroup is online:

SELECT name, state FROM v$asm_diskgroup;

Bring disks/diskgroup online via ASM storage admin if needed.

6. If the file is a symlink, confirm the target exists:

readlink -f /path/to/symlink

7. If the cause is OS-level I/O errors, escalate to storage/system admins to repair hardware or replace failing disks. After hardware fixes, restore corrupted/missing files from backup.

8. After any fix, validate and crosscheck RMAN and controlfile metadata:

RMAN> CROSSCHECK DATAFILE ALL;

RMAN> VALIDATE DATAFILE <file#>;

Example scenario

During an RMAN restore you see:

ORA-27037: unable to obtain file status

Linux Error: 2: No such file or directory

Investigation shows /u01/oradata/prod/users01.dbf was accidentally removed by a script. Resolution: restore the file from the latest backup (RMAN RESTORE DATAFILE), recover it, then open the tablespace.

Best practices to avoid ORA-27037

• Never delete or move datafiles directly on the OS; use RMAN or ALTER DATABASE RENAME FILE.

• Use ASM or redundant storage (RAID) to reduce filesystem/mount issues.

• Monitor disk space, mounts and I/O health (alerts for low space or disk errors).

• Automate RMAN CROSSCHECK and validation so metadata stays accurate.

• Keep regular backups and test restores frequently.

Conclusion

ORA-27037 signals that Oracle cannot determine file status at the OS level—most often due to missing files, permissions, unmounted filesystems, or ASM issues. The fix is to restore or correct the file path/permissions and ensure the underlying storage is healthy. Following safe file-management practices and regular RMAN verification prevents many of these incidents.