ORA-03113: 통신 채널에 EOF가 있습니다.

1. 가장 많은 원인은 서버의 Oracle 쉐도 프로세스가 예기치 않게 종료된 경우 입니다.

따라서 수행중에 갑자기 ORA-3113과 3114가 발생했다면, 우선 서버의 alert.log를 점검하여 다른 Oracle 오류가 발생했는지 알아보십시요.

<< alert.log >> 서버가 UNIX 인경우 $ORACLE_HOME/rdbms/log/alert_.log 화일에 ORA-3113 에러가 발생했던 시점에서 다른 에러가 발생했는지 점검 합니다.

특히 ORA-600[],[]이 발생했으면 에러 내용을 Oracle Technical Support Center로 연락 하십시오.

2. ORA-3113의 원인 중 그 다음으로 많은 것은 SQL*NET 드라이버가 Unix의 ORACLE 실행 파일과 연결되지 않아 발생한 경우입니다.

연결을 공식적으로 수신하고 그것을 ORACLE 쉐도 프로세스에 전달한다 해도, 쉐도 프로세스는 처리방법을 모르기 때문에 어떤 방법으로도 응답하지 못할 수 있습니다.

그러므로 클라이언트는 연결순간에 ORA-3113을 보게 됩니다.

3. 세번째로 많은 원인은 서버쪽의 기계 손상이나 네트워크 고장입니다.

4. 자주 있는 것은 아니지만 같은 네트워크에서 두 서버가 같은 노드 이름을 가질 때에도 이 오류가 발생합니다.

5. ORA-3113은 토큰링 카드의 공유 RAM 크기가 16KB가 아니라 8KB로 설정 되었음을 나타내기도 합니다.

토큰 링을 사용중이라면 공유 버크 크기를 점검하고 키워 보십시요.

6. ORA-3113은 INIT.ORA 매개변수 CONTEXT_AREA와 CONTEXT_INCR이 4096이라는 값으로 설정된 경우에도 발생합니다.

그럴때는 값을 8192로 키우면ORA-3113이 해소됩니다.

이상 말한 모든 원인은 결국 클라이언트가 서버로부터 어떤 정보를 읽으러 갔다가 거기서 더 이상 연결이 없음을 발견했다는 뜻입니다.

ORA-3113은 좀 더 진단해야 추적 가능한 더 큰 문제가 있음을 알리는 신호탄에 불과합니다.

다행히도 앞서 말한 여섯가지 정보를 참고하면 해결책을 찾는 방향은 잡힐 것입니다.


우선 ORA-3113을 디버깅하려면, 루프백을 수행중에 같은 CONNECTING을 여러번 시도해 보는 것이 좋습니다.

즉, 서버의 어떤 툴이든 데스크탑 클라이언트에서 지정하는 것과 같은 연결 스트링을 사용하여 연결할 수 있습니다.

루프백을 수행중에도 똑같은 문제가 발생하면 데스크탑 클라이언트 쪽이 아니라 서버쪽에 문제가 있다고 보아야 합니다.

루프백을 수행하려면 서버에서 SQLPLUS 또는 SQLDBA를 호출하고, 서버의 SQLPLUS 또는 SQLDBA 프롬프트에서 다음과 같이 입력하십시요.

 CONNECT USERNAME/PASSWORD@t:/:

예를 들어, SQL*NET TCP/IP를 통해 Unix 서버에 연결돼 있고 SQL*Plus를 호출하고, 같은 "t::" 연결 스트링을 사용하여, 같은 SELECT 문을 내서 루프백을 해 보십시요.

티스토리 툴바