BookmarkSubscribeRSS Feed

Meet The Worst Oracle Error Ever - ORA-3113

Started ‎11-02-2020 by
Modified ‎11-02-2020 by
Views 6,021

If you are reading this article, you probably have an ORA-3113 error. You have my sympathy because this is one of the toughest Oracle errors to diagnose and solve. ORA-3113 is described as a catch-all error meaning the Oracle developers don't know the actual cause of the problem. You - Dear SAS User - will be told that it is a SAS problem; contact your SAS Admin. This is most unfortunate because you probably are the SAS Administrator.


The full message is Oracle ORA-3113: end-of-file on communication channel.


The problem isn't that SAS cannot connect to Oracle; the problem is that something (hint - it's not SAS) is causing the connection to drop. The connection is usually dropped after a period of inactivity. Newer versions of Oracle may report a ORA-3135 error; it's the same thing.


So, how do you - the SAS User - fix this? You don't. That would be too easy. What you have to do is convince your Oracle DBAs that SAS isn't the problem. It is most likely something with the network or the Oracle instance. This is a difficult thing to do.


A SAS communities user recently encountered this issue. Naturally, the DBAs pointed the finger at SAS. This is a difficult situation because the DBAs want absolve themselves of responsibility. Understandable, but not helpful. Fortunately for the Communities Member, a second application reported an ORA-3113 error. So lucky!


In this case, the problem was an overworked Oracle server. The CPUs were maxed-out. Oracle was starved for cycles.


I have seen this problem many times at SAS. It was almost always a change in a network configuration. It isn't a problem with the connection information because the connection actually works. <-- Point this out to the DBAs;)


My favorite ORA-3113 incident happened at a customer site. SAS was reporting an ORA-3113 during a bulk load process. We could move the data using INSERT statements with no problem other than performance. Bulk load died every time. Running the load via SQL*Loader worked. Naturally, fingers were pointed at SAS. It took an embarrassingly long time, but we figured it out. This company had written a utility that would cancel idle Oracle connections. When SAS bulk loads it passes control to SQL*Loader. The SAS connection is idle; the utility killed it. When control returned to SAS - ORA-3113. We added SAS to the utility's exclude list and never encountered the error again.


The key take-away is that this is not a SAS issue. Push back on the DBAs, Networking, or Sys Admin folks.


Helpful Links






Version history
Last update:
‎11-02-2020 03:47 PM
Updated by:



Registration is open! SAS is returning to Vegas for an AI and analytics experience like no other! Whether you're an executive, manager, end user or SAS partner, SAS Innovate is designed for everyone on your team. Register for just $495 by 12/31/2023.

If you are interested in speaking, there is still time to submit a session idea. More details are posted on the website. 

Register now!

Free course: Data Literacy Essentials

Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning  and boost your career prospects.

Get Started

Article Tags