출처: http://database.sarang.net
:: 제가 실수를 했습니다... --;;
:: 죄송합니다...
::
:: 최성준님의 말씀대로 ORA-03113이랑 ORA-03114입니다...
:: 문제는 에러가 통신때문인것 같은데, 네트워크 연결상 문제가 없다는데 있습니다.
:: 더불어 다른 에러도 뜨지 않구요...
:: 처음엔 03113 에러창이 뜨고 확인버튼을 누르면 03114가 뜹니다.
:: 오라클 본사에 연락해 봤으나 SQL Plus에서 연결상태를 확인해 보더니
:: 이상이 없다 하는데...
:: 어떻게 해야될지 잘 모르겠습니다...
:: 연결이 끊기는 이유만이라도 알수 있었으면 정말 좋겠습니다...
:: 감사합니다.
저의경우를 비추어보면 많은양에 데이타를 가져오는 퀴리를 실행했습니다.
리스너쪽에 timeout interval를 짧게한 후 위에 쿼리를 동시에 여러개를
실행시켰습니다. 그러자 dedicate 서버가 죽고
alertlog화일에 ora-3113,ora-3114에러가 나타납습니다.
즉 잘못된 쿼리문에의한 에러였습니다. 만약 쿼리문 수행이라면
쿼리문을 튜닝해보는것도 좋은 방법입니다.
그리고 두가지에 오라클사 자료를 올리죠.
/*첫번째자료*/
: ORA-3113, 3114의 발생원인및 진단 방법
--------------------------------------------------------------------------------
ORA-3113 'end-of-file on communication (통신 채널에서 파일끝)'에 대해서 설명하겠습니다.
ORA-3113은 가장 포괄적인 오류입니다.
원초적인 의미로는 예기치 않은 이유때문에 통신이 두절된 상태를 의미합니다.
이 오류뒤에는 대개 ORA-3114 'not connected to ORACLE'이 동반됩니다.
원인을 살펴보면
가장 많은 원인은 서버의 Oracle 쉐도 프로세스가 예기치 않게 종료된 경우 입니다.
따라서 수행중에 갑자기 ORA-3113과 3114가 발생했다면,
우선 서버의 alert.log를 점검 하여 다른 Oracle 오류가 발생했는지 알아보십시요.
ORA-3113의 원인 중 그 다음으로 많은 것은 SQL*NET 드라이버가
Unix의 ORACLE 실행 파일과 연결되지 않아 발생한 경우입니다.
연결을 공식적으로 수신하고 그것을 ORACLE 쉐도 프로세스에 전달한다 해도,
쉐도 프로세스는 처리 방법을 모르기 때문에 어떤 방법으로도 응답하지 못할 수 있습니다. 그러므로 클라이언트는 연결순간에 ORA-3113을 보게 됩니다.
세번째로 많은 원인은 서버쪽의 기계 손상이나 네트워크 고장입니다.
자주 있는 것은 아니지만 같은 네트워크에서 두 서버가 같은 노드 이름을
가질 때에도 이 오류가 발생합니다.
ORA-3113은 토큰링 카드의 공유 RAM 크기가 16KB가 아니라 8KB로 설정되었음을 나타내기도 합니다.
토큰 링을 사용중이라면 공유 버크 크기를 점검하고 키워 보십시요.
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:(servername)/(port#):(sid)
예를 들어, SQL*NET TCP/IP를 통해 Unix 서버에 연결돼 있고 SQL*Plus를 호출하고, 같은 "t:(servername):(sid)"
연결 스트링을 사용하여, 같은 SELECT 문을 내서 루프백을 해 보십시요.
/*두번째자료*/
ORA-3113의 의미는 클라이언트에서 서버에 대한 접속을 갑작스럽게 잃어 버릴
때에 발생하며 대부분의 경우 서버에서 클라이언트의 접속을 kill하는 경우이다.
이 에러는 주로 서버 장비의 데이타베이스 또는 SQL*NET LISTENER(서버측)의
문제이므로 초기에는 클라이언트측은 무시하고 대신 서버측을 조사해 보아야 한다
드문 경우이긴 하지만 이 것은 클라이언트의 memory나 resource의 부족으로 발생
할수도 있고, DLL 버젼이 서로 맞지 않아 발생하기도 한다. 그러나 이런 경우는
극히 드물다.
1. Server side
첫번째로는 사용자의 DBA에게 도움을 요청한다. 그런 다음 사용자의 응용
프로그램에서 ORA-3113 에러를 재현한다. DBA에게 요청하여 데이타베이스의
alert.log와 trace file을 보고, ORA-3113절에 에러와 동시에 나오는 다른
내용이 있는지를 확인한다.
예로 만일 클라이언트가 ORA-3113에러를 얻게 되면 매번 trace 화일 생성
하거나, 또는 alert.log화일내에 ORA-00600 에러가 남게 되는데 이는 데이타
베이스 또는 SQL*NET의 문제로 인해 생기는 것이다.
2. Client Side
이 에러는 Windows 3.1에서는 아주 큰 문제이며, Windows 95에서는 문제가
덜 발생하며, Windows NT에서는 드물게 발생한다.
2.1 Memory 문제
2.1.1 Windows 3.1
Test를 하기 위해 Control Panel * 386Enh * Virtual Memory를 통해
Permanent swap file (temporary가 아님)을 생성한다. 특히 클라이언트와
서버 사이에서 매우 큰 data를 전달하는 경우 ORA-3113에러가 발생한다면
보다 큰 sizes로 swap size를 늘린다. 그리고 AUTOEXEC.BAT와 CONFIG.SYS
화일에서 memory에 상주시키는 불필요한 프로그램들은 제거 하도록 한다.
2.1.2 Windows 95
가능하다면 ALT-CTRL-DEL을 누르고 windows 95에 올라와 있는 여러 Tasks을
죽인후 operation을 다시 시도해 본다.
Permanent swap file을 증가시켜 보고 test를 하기 위해 설정 -> 제어판 ->
시스템 -> 성능 -> 가상메모리를 통해 Permanent swap file의 size를 증가
시켜 본다.
특히 클라이언트와 서버 사이에서 매우 큰 data를 전달하는 경우 ORA-3113
에러가 발생 한다면 보다 큰 sizes로 swap size를 늘린다.
2.1.3 Windows NT
위의 Windows 95에서와 마찬가지로 Permanent swap file을 증가시킨다.
2.2 DLL Version mismatch
2.2.1 SQL*NET과 Database의 버젼
Oracle Installer를 수행하여 현재 사용 중인 SQL*NET version을 점검하며
아래에 기술된 내용은 최소한 충족시켜 주어야 합니다.
(아래의 Version이 서로 맞지 않는다고 해서 사용할 수 없는 것은 아님)
=============================================
SQL*NET | RDBMS
=============================================
Ver 1 or Ver 2.0 | 7.0 또는 이후 버젼
Version 2.1 | 7.1 또는 이후 버젼
Version 2.2 | 7.2 또는 이후 버젼
Version 2.3 | 7.3 또는 이후 버젼
=============================================
2.2.2 OCI 사용자
만일 사용자의 프로그램이 OCIW32.DLL을 링크한다면 PC에 설치되어 있는 가장
최근의 RSF(Required Support File)을 로드할 것 이다.
또한 만일 데이타베이스 버젼 보다 PC에 새로운 RSF가 설치 되어 있는 상태
에서 데이타 베이스에 접속하기를 원한다면 그 것을 remove하고 가급적이면
데이타 베이스의 버젼(처음부터 최소한 2digit : 예로 데이타베이스 버젼이
7.3.2.3이라면 RSF는 최소한 V7.3.x)과 맞추는 것이 좋다.
2.2.3 ODBC 사용자
Oracle Web site(www.oracle.com/products/free_software)에 ODBC driver를
Free software로 올려 놓은 곳이 있으니 SQL*NET 버젼에 해당하는 ODBC
Driver를 사용하시기 바란다.
2.2.4 기타
가능하다면 응용 프로그램에서 현재 사용하고 있는 SQL*NET의 버젼과 동일한
Required Support File의 버젼을 사용한다.
SQL*NET | RSF (Required Support File)
======================================================
V2.1 | V7.1
V2.2 | V7.2
V2.3 | V7.3
참고 : 3rd party 제품의 경우 Oracle에 접속하는 경우 자체 Native
Database driver에서 요구 하는 ORACLE RSF의 버젼을 요구하는
경우도 있다.
ORA-3113은 가장 포괄적인 오류입니다. 원초적인 의미로는 예기치 않은 이유 때문
에 통신이 두절된 상태를 의미합니다. 이 오류 뒤에는 대개 ORA-3114 'not
connected to ORACLE'이 동반됩니다.
원인을 살펴보면 다음과 같습니다.
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 문을
내서 루프백을 해 보십시요.
