I was attempting to do some work on one of the databases on a sandbox environment that had been shutdown for a few weeks; so I log on to the server, set my environment, connect as sys, issue the startup command and… I get the ORA-03113: end of file on communication channel!
SQL> startup;
ORACLE instance started.
Total System Global Area 1660943096 bytes
Fixed Size 8940280 bytes
Variable Size 1358954496 bytes
Database Buffers 285212672 bytes
Redo Buffers 7835648 bytes
Database mounted.
ORA-03113: end-of-file on communication channel
Process ID: 8806
Session ID: 237 Serial number: 17248
SQL>
This was somewhat surprising as the last time I had it up and running, everything was running just fine, then again it’s one of those databases you can describe as a scratch database, not that I don’t care about it but no one other than me does. If I read about a new feature I’d go test it there, doesn’t matter if it broke everything or not I could drop it and create a new one nobody would care, hence the low maintenance. In any case the error got me curious so I got to looking and in this post I will describe one probable cause of this issue(the one that caused me to get it), how to resolve ORA-03113 and how to watch for and prevent it.
What the @!#$ is going on?
One of the first places I to get more information on errors like this and other instance events is the alert log . The alert log captures major changes and events that occur during the running of the oracle instance. it can be found in the location $ORACLE_BASE/diag/rdbms/<oracle_sid>/<ORACLE_SID>/trace. Here’s an extract of what my alert log file looks like:
[oracle@localhost ~]$ cd /u01/app/oracle/diag/rdbms/orcl/ORCL/trace
[oracle@localhost trace]$
[oracle@localhost trace]$
[oracle@localhost trace]$
[oracle@localhost trace]$
[oracle@localhost trace]$ ll alert_ORCL.log
-rw-r-----. 1 oracle oinstall 246661 Mar 6 04:20 alert_ORCL.log
[oracle@localhost trace]$
[oracle@localhost trace]$
[oracle@localhost trace]$ tail -100 alert_ORCL.log | more
Completed crash recovery at
Thread 1: RBA 94.141.16, nab 141, scn 0x0000000001681162
0 data blocks read, 0 data blocks written, 0 redo k-bytes read
Endian type of dictionary set to little
2026-03-06T04:20:35.603669-06:00
LGWR (PID:8750): STARTING ARCH PROCESSES
2026-03-06T04:20:35.649367-06:00
TT00 (PID:8808): Gap Manager starting
Starting background process ARC0
2026-03-06T04:20:35.701932-06:00
ARC0 started with pid=38, OS id=8810
...
ORACLE Instance ORCL, archival error, archiver continuing
2026-03-06T04:20:36.412928-06:00
ORA-16055: FAL request rejected
2026-03-06T04:20:36.413007-06:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/ORCL/trace/ORCL_arc1_8814.trc:
ORA-16055: FAL request rejected
2026-03-06T04:20:36.479140-06:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/ORCL/trace/ORCL_ora_8806.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 8657043456 bytes is 100.00% used, and has 0 remaining bytes available.
2026-03-06T04:20:36.479187-06:00
************************************************************************
You have following choices to free up space from recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
************************************************************************
Reclaimable space = 0
Available space = 0
Disk space limit = 8657043456
See trace file /u01/app/oracle/diag/rdbms/orcl/ORCL/trace/ORCL_ora_8806.trc for usage information from V$RECOVERY_AREA_USAGE
2026-03-06T04:20:36.531632-06:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/ORCL/trace/ORCL_ora_8806.trc:
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 44316160 bytes disk space from 8657043456 bytes limit
NET (PID:8806): Error 19809 Creating archive log file to '/u02/fast_recovery_area/ORCL/archivelog/2026_03_06/o1_mf_1_92_%u_.arc'
NET (PID:8806): Stuck archiver: inactive mandatory LAD:1
NET (PID:8806): Stuck archiver condition declared
2026-03-06T04:20:36.563485-06:00
Errors in file /u01/app/oracle/diag/rdbms/orcl/ORCL/trace/ORCL_ora_8806.trc:
The highlighted lines in the above output point to the error! the fast recovery area filled up. Now this can happen if your database is set to archivelog mode (which was the reason in my case) or if regular maintenance isn’t carried out on that directory.
This shouldn’t get past you in Production
Whatever your backup strategy is, you’ve got to watch out and put guardrails such that your alert log doesn’t get full. A lot of the dba management GUIs provide you with some notifications out of the box but if you’re like me and use little to no GUI to manage your databases, then you need some monitoring solution to ensure that this and other errors don’t get past you. The alert log notifies you as the fra is getting filled up. The script alert_log_ck.sh can check for this error and notify you in case of that and many other issues. You can schedule this script to run every 15 minutes or so via crontab on Linux.
RESOLVING ORA-03113
According to DOC ID: 1506805.1 The ORA-03113 itself could be caused by a lot of different things, and depending on the underlying issue, the resolution could be different.
For this case the underlying error was the ORA-19815, and you can do a couple of things to resolve it:
- Add disk space and increase the DB_RECOVERY_FILE_DEST_SIZE parameter.
- Back up the files to a tertiary device using Oracle Recovery Manager (Oracle RMAN).
- Consider changing the RMAN retention policy.
- Consider changing the RMAN archived log deletion policy.
- Delete the files from recovery area using RMAN.
I largely did not need to be able to recover this database for any reason whatsoever so I proceeded with the last option.
Old backup files and archivelog files can be deleted using rman (recovery manager)
[oracle@localhost trace]$ rman target /
Recovery Manager: Release 19.0.0.0.0 - Production on Fri Mar 6 06:22:30 2026
Version 19.23.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
connected to target database (not started)
RMAN> startup mount;
Oracle instance started
database mounted
Total System Global Area 1660943096 bytes
Fixed Size 8940280 bytes
Variable Size 1358954496 bytes
Database Buffers 285212672 bytes
Redo Buffers 7835648 bytes
RMAN>
RMAN>
RMAN> SELECT space_limit, space_used
2> FROM v$recovery_file_dest;
SPACE_LIMIT SPACE_USED
----------- ----------
8657043456 8655209984
RMAN>
My goal is to get rid of some backup files and free up some fra space which can be done using the delete command.
RMAN> delete noprompt backup of database;
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=17 device type=DISK
List of Backup Pieces
BP Key BS Key Pc# Cp# Status Device Type Piece Name
------- ------- --- --- ----------- ----------- ----------
17 17 1 1 AVAILABLE DISK /u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T210446_ntnk2h90_.bkp
19 19 1 1 AVAILABLE DISK /u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T210828_ntnk9doq_.bkp
20 20 1 1 AVAILABLE DISK /u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T210846_ntnk9y50_.bkp
21 21 1 1 AVAILABLE DISK /u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T211026_ntnkf2c8_.bkp
23 23 1 1 AVAILABLE DISK /u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T211300_ntnkkwrh_.bkp
24 24 1 1 AVAILABLE DISK /u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T212312_ntnl50c7_.bkp
25 25 1 1 AVAILABLE DISK /u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T212333_ntnl5olq_.bkp
26 26 1 1 AVAILABLE DISK /u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T212338_ntnl5tx2_.bkp
27 27 1 1 AVAILABLE DISK /u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T212344_ntnl612p_.bkp
28 28 1 1 AVAILABLE DISK /u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T212351_ntnl6794_.bkp
29 29 1 1 AVAILABLE DISK /u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T212356_ntnl6d9t_.bkp
30 30 1 1 AVAILABLE DISK /u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T212402_ntnl6l8k_.bkp
deleted backup piece
backup piece handle=/u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T210446_ntnk2h90_.bkp RECID=17 STAMP=1227128687
deleted backup piece
backup piece handle=/u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T210828_ntnk9doq_.bkp RECID=19 STAMP=1227128908
deleted backup piece
backup piece handle=/u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T210846_ntnk9y50_.bkp RECID=20 STAMP=1227128926
deleted backup piece
backup piece handle=/u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T211026_ntnkf2c8_.bkp RECID=21 STAMP=1227129026
deleted backup piece
backup piece handle=/u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T211300_ntnkkwrh_.bkp RECID=23 STAMP=1227129180
deleted backup piece
backup piece handle=/u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T212312_ntnl50c7_.bkp RECID=24 STAMP=1227129792
deleted backup piece
backup piece handle=/u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T212333_ntnl5olq_.bkp RECID=25 STAMP=1227129813
deleted backup piece
backup piece handle=/u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T212338_ntnl5tx2_.bkp RECID=26 STAMP=1227129818
deleted backup piece
backup piece handle=/u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T212344_ntnl612p_.bkp RECID=27 STAMP=1227129825
deleted backup piece
backup piece handle=/u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T212351_ntnl6794_.bkp RECID=28 STAMP=1227129831
deleted backup piece
backup piece handle=/u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T212356_ntnl6d9t_.bkp RECID=29 STAMP=1227129836
deleted backup piece
backup piece handle=/u02/fast_recovery_area/ORCL/backupset/2026_03_05/o1_mf_nnndf_TAG20260305T212402_ntnl6l8k_.bkp RECID=30 STAMP=1227129842
Deleted 12 objects
...
RMAN>
RMAN> SELECT space_limit/1024/1024, space_used/1024/1024
2> from v$recovery_file_dest;
SPACE_LIMIT/1024/1024 SPACE_USED/1024/1024
--------------------- --------------------
8256 611.34375
RMAN> After clearing up older backup files then we can open database up again
RMAN>
RMAN> alter database open;
Statement processed
RMAN> exit
Recovery Manager complete.
[oracle@localhost trace]$
[oracle@localhost trace]$
[oracle@localhost trace]$
[oracle@localhost trace]$ cd
[oracle@localhost ~]$
[oracle@localhost ~]$ sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Fri Mar 6 06:40:55 2026
Version 19.23.0.0.0
Copyright (c) 1982, 2023, Oracle. All rights reserved.
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.23.0.0.0
SQL> SELECT instance_name, status
2 FROM v$instance;
INSTANCE_NAME STATUS
---------------- ------------
ORCL OPEN
SQL>
CONCLUSION
When an ORA‑03113 shows up out of nowhere, it’s easy to assume something catastrophic has happened. In reality, as this little adventure shows, the root cause is often far more mundane—like a completely full Fast Recovery Area quietly choking the instance during startup. By checking the alert log, keeping an eye on FRA usage, and putting simple monitoring or retention policies in place, you can prevent this class of failure from ever surprising you. Whether it’s a scratch database or a mission‑critical system, a bit of housekeeping goes a long way toward keeping your Oracle environments healthy and predictable.
Cheers 🎊