ORA-609 Error (11.1.0.6 to 11.2.0.3)

ORA-609 에러 진단 가이드 : Opiodr aborting process unknown ospid (문서 ID 1575969.1) 맨 아래로 수정 날짜:2013. 8. 13유형:TROUBLESHOOTING 언어: English한국어 이 문서에서 목적 진단 절차 참고   적용 대상: Oracle Net Services - 버전 11.1.0.6 to 11.2.0.3 [릴리즈 11.1 to 11.2] 이 문서의 내용은 모든 플랫폼에 적용됩니다. 목적 ORA-609 에러는 alert.log 에 보고된다. 이 에러는 간헐적으로 발생하고 몇일 동안 발생하지 않을 수도 있다.  Mon Oct 12 10:03:39 2009 Errors in file e:\app\oracle\diag\rdbms\center\center\trace\center_ora_7464.trc: ORA-00609: could not attach to incoming connection ORA-12537: TNS:connection closed ORA-609 : opiodr aborting process unknown ospid (2436_7464) 데이타베이스 서버에 지역적으로 발생하는 sqlnet.log 화일에 이 에러가 발생할 수 있다.: Fatal NI connect error 12537, connecting to: (LOCAL=NO) VERSION INFORMATION: TNS for 64-bit Windows: Version 11.1.0.7.0 - Production Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.1.0.7.0 - Production Windows NT TCP/IP NT Protocol Adapter for 64-bit Windows: Version 11.1.0.7.0 - Production Time: 12-OCT-2009 10:03:39 Tracing to file: E:\app\oracle\product\11.1.0\db_1\NETWORK\trace\svr1_7464.trc Tns error struct: ns main err code: 12537 TNS-12537: TNS:connection closed ns secondary err code: 12560 nt main err code: 0 nt secondary err code: 0 nt OS err code: 0 listener.log에는 명확한 에러 없이 접속이 맺어졌다는 것을 보여준다. 이것은 리스너가 접속을 서버 프로세스에게 전달해 준 이후에 접속이 실패했기 때문이다. 12-OCT-2009 10:03:39 * (CONNECT_DATA=(SID=ORCL)) * (ADDRESS=(PROTOCOL=tcp)(HOST=123.456.1.123)(PORT=3158)) * establish * ORCL * 0 12-OCT-2009 10:03:39 * (CONNECT_DATA=(SID=ORCL)) * (ADDRESS=(PROTOCOL=tcp)(HOST=123.456.1.123)(PORT=3159)) * establish * ORCL * 0 아래의 Oracle Net 서버 트레이스화일에서 주목할 부분은 화일이름 "svr_7464.trc"이다. 여기서 문제는 접속 패킷을 클라이언트로부터 받을 때 나타난다. ORA-609 에러는 Oracle Net 트레이스에는 나타나지 않는다. ORA-609 에러는 트레이스 snippet에서 ns=12537 을 동반하면서 발생한다. [000001 12-OCT-2009 10:03:39:116] nscon: doing connect handshake... [000001 12-OCT-2009 10:03:39:116] nscon: recving a packet [000001 12-OCT-2009 10:03:39:116] nsprecv: entry [000001 12-OCT-2009 10:03:39:116] nsprecv: reading from transport... [000001 12-OCT-2009 10:03:39:116] nttrd: entry [000001 12-OCT-2009 10:03:39:163] nttrd: exit [000001 12-OCT-2009 10:03:39:163] ntt2err: entry [000001 12-OCT-2009 10:03:39:163] ntt2err: Read unexpected EOF ERROR on 7104 [000001 12-OCT-2009 10:03:39:163] ntt2err: exit [000001 12-OCT-2009 10:03:39:163] nsprecv: error exit [000001 12-OCT-2009 10:03:39:163] nserror: entry [000001 12-OCT-2009 10:03:39:163] nserror: nsres: id=0, op=68, ns=12537, ns2=12560; nt[0]=507, nt[1]=0, nt[2]=0; ora[0]=0, ora[1]=0, ora[2]=0 [000001 12-OCT-2009 10:03:39:163] nscon: error exit [000001 12-OCT-2009 10:03:39:163] nsdo: nsctxrnk=0 [000001 12-OCT-2009 10:03:39:163] nsdo: error exit [000001 12-OCT-2009 10:03:39:163] nsinh_hoff: error recving request Alert log와 Oracle Net 트레이스를 통해서 ORA-609 에러를 트레이스하는 다른 방법을 보여주는데, 핸드쉐이크하는 동안에 이슈가 나타나는 것을 보여준다. 아래는 Alert log를 보여준다.: Mon Dec 21 15:52:15 2009 ORA-609 : opiodr aborting process unknown ospid (21631120_1)   [21-DEC-2009 15:52:15:025] nscon: sending NSPTAC packet [21-DEC-2009 15:52:15:025] nspsend: entry [21-DEC-2009 15:52:15:031] ntt2err: Read unexpected EOF ERROR on 14 [21-DEC-2009 15:52:15:031] ntt2err: exit [21-DEC-2009 15:52:15:031] nsprecv: error exit [21-DEC-2009 15:52:15:031] nserror: entry [21-DEC-2009 15:52:15:031] nserror: nsres: id=0, op=68, ns=12537, ns2=12560; nt[0]=507, nt[1]=0, nt[2]=0; ora[0]=0, ora[1]=0, ora[2]=0 [21-DEC-2009 15:52:15:031] nsrdr: error exit [21-DEC-2009 15:52:15:031] nsdo: nsctxrnk=0 [21-DEC-2009 15:52:15:031] nsdo: error exit [21-DEC-2009 15:52:15:031] nsnareceive: error exit [21-DEC-2009 15:52:15:031] nserror: entry [21-DEC-2009 15:52:15:031] nserror: nsres: id=0, op=68, ns=12537, ns2=12532; nt[0]=0, nt[1]=0, nt[2]=0; ora[0]=0, ora[1]=0, ora[2]=0 [21-DEC-2009 15:52:15:031] nacomrc: received 12637 bytes [21-DEC-2009 15:52:15:031] nacomrc: failed with error 12637 [21-DEC-2009 15:52:15:031] nacomrc: exit [21-DEC-2009 15:52:15:031] na_receive_packet: failed with error 12637 [21-DEC-2009 15:52:15:031] na_receive_packet: exit [21-DEC-2009 15:52:15:031] na_server: failed with error 12637 인스턴스에 지역적인 sqlnet.log를 통해서 일치하는 에러 메시지를 발견할 수 있다. 다음은 그 예를 보여준다. Fatal NI connect error 12537, connecting to:  (LOCAL=NO)  VERSION INFORMATION:  TNS for Solaris: Version 11.2.0.2.0 - Production  Oracle Bequeath NT Protocol Adapter for Solaris: Version 11.2.0.2.0 - Production  TCP/IP NT Protocol Adapter for Solaris: Version 11.2.0.2.0 - Production  Time: 21-DEC-2009 15:52:15  Tracing not turned on.  Tns error struct:  ns main err code: 12537  TNS-12537: TNS:connection closed  ns secondary err code: 12560  nt main err code: 0  nt secondary err code: 0  nt OS err code: 0   Oracle Net 서버 트레이스 안에 event에 매치되는 것을 보여준다. 진단 절차 1. listener.log로부터 접속을 맺는 클라이언트를 찾아낸다. Alert log는 다음과 유사한 ORA-609 에러를 나타낸다. : Mon Oct 05 12:41:49 2009 ORA-609 : opiodr aborting process unknown ospid (21131406_1) Listener.log로 가서 이 접속에 일치하는 엔트리를 찾아본다. Listener.log 내 엔트리는 아래의 예처럼 보일 것이다.:  05-OCT-2009 12:41:49 * (CONNECT_DATA=(SID=orcl)) * (ADDRESS=(PROTOCOL=tcp)(HOST=sample.com)(PORT=1234)) * establish * orcl * 0 위 예제에서 클라이언트 주소값이 "sample.com"임을 주목하여야 한다. 한가지 옵션은 그 사이트에서 몇 개의 클라이언트를 위치시키고, 클라이언트 트레이싱을 활성화하는 것이다. 클라이언트 사이드에서 $ORACLE_HOME/network/log 화일을 확인해야 하고 동일한 timestamp 시점에 발생한 timeout 에러에 대해 명시적으로 확인해야 한다.   2. Oracle Net 트레이싱을 클라이언트 레벨 16으로 걸어서 확인한다. 클라이언트 SQLNET.ORA 화일 안에 아래와 같이 추가한다. DIAG_ADR_ENABLED=off                  # Diable ADR if version 11g TRACE_LEVEL_CLIENT = 16               # Enable level 16 trace  TRACE_TIMESTAMP_CLIENT = ON           # Set timestamp in the trace files TRACE_DIRECTORY_CLIENT = <DIRECTORY>  # Control trace file location  TRACE_FILELEN_CLIENT =<n>     #Control size of trace set in kilobytes eg 20480  TRACE_FILENO_CLIENT =<n>      #Control number of trace files per process 만일 접속 모델이 JDBC Thin이라면 클라이언트 사이드의 Java 트레이싱이 필요하므로, Document 793415.1 How to Perform the Equivalent of SQL*Net Client Tracing with Oracle JDBC Thin Driver 를 참고하도록 한다. 만일 11.2 JDBC Thin 클라이언트가 사용된다면 다음 노트가 활용될 수 있다. Document 1050942.1 How to Trace the Network Packets Exchanged Between JDBC and the RDBMS in Release 11.2 3. Oracle Net 트레이싱을 서버 사이드 레벨 16으로 걸어서 확인한다. 클라이언트 SQLNET.ORA 화일 안에 아래와 같이 추가한다. DIAG_ADR_ENABLED=off                  # Diable ADR if version 11g TRACE_LEVEL_SERVER = 16               # Enable level 16 trace TRACE_TIMESTAMP_SERVER = ON           # Set timestamp in the trace files TRACE_DIRECTORY_SERVER = <DIRECTORY>  # Control trace file location TRACE_FILELEN_SERVER =<n>   #Control size of trace set in kilobytes eg 20480  TRACE_FILENO_SERVER =<n>       #Control number of trace files per process 트레이싱을 순환하게 되면 생성되는 트레이스 화일의 갯수와 크기를 조절할 수 있다. TRACE_FILELEN 파라미터는 트레이스 화일의 크기를 셋팅하기 위해 사용된다. TRACE_FILENO 파라미터는 프로세스 당 트레이스 화일의 갯수를 셋팅하기 위해 사용된다. 중요 노트:  SQLNET.ORA 화일은 프로세스 생성 시 단 한번 읽혀진다. RDBMS 백그라운드 프로세스와 SHARED 서버 디스패처는 sqlnet.ora 화일의 파라미터 변경이 반영될 수 있도록 재기동되어야 한다. 프로세스가 트레이싱되기 위해 기동이 되었다면 트레이스는 프로세스가 멈출 때까지 중단되지 않는다.   Oracle Net 서버 트레이싱을 활성화하면 짧은 시간 동안에 많은 양의 트레이스를 생성시킬 수 있다. 비록 순환적인 트레이싱을 하더라도 각 프로세스는 TRACE_FILENO_SERVER 에 지정한 갯수 만큼의 트레이스를 생성시킬 것이다. 최적의 트레이싱 워크플로우는 트레이싱을 활성화하고 문제를 재현하고 트레이싱을 비활성화시키는 것이다. 그러므로, 트레이싱하는 시간의 양을 제한하는 것이 활성화된다. TRACE_FILENO_SERVER 를 1로 셋팅하고, TRACE_FILELEN_SERVER 를 20480로 셋팅하게 되면 프로세스 당 생성되는 트레이스의 양을 낮춰주기 위한 솔루션이다. 이렇게 셋팅하면 트레이스 화일이 overwrite되고, failure가 발생한 시점의 중요한 데이타를 유실할 수 있음을 명심해야 한다. 4. Errorstack: 에러가 났을 때를 대비해 errorstack 트레이스를 설정한다. 이것은 Oracle Net 클라이언트 트레이스를 캡춰하는 것이 쉽지 않을 때 적용한다. SQL> alter session set events '609 errorstack(3)'; 에러가 재현되는 동안 몇 개의 트레이스를 수집한다. SQL> alter session set events '609 off'; 만일 에러를 만났을 때에는 다음을 수행한다.: 서버에서 SQLNET.LOG 화일을 리뷰한다. ALERT. LOG 내에 timestamp를 비교하면서 일치하는 엔트리를 찾아본다.  SQLNET.LOG 화일 내의 엔트리로부터 Oracle Net server trace 이름을 "Tracing to file"이라는 라인에서 찾을 수 있다.  server 트레이스를 열어서 Connection ID 값에 대해서 grep 또는 찾아본다. 그런 다음, 같은 Connection ID 값에 대해서 클라이언트 트레이스 client 디렉토리를 찾아본다. 매칭되는 클라이언트와 서버 트레이스를 찾게 될 것이다. 이 절차는 이 문서에 자세히 소개되어 있다. Document 374116.1 How to Match Oracle Net Client and Server Trace Files 리뷰를 위해 다음을 업로드한다.: 매칭되는 Oracle Net 클라이언트와 서버 트레이스 또는 매칭되는 Javanet 과 서버 트레이스 화일. ALERT.LOG 와 LISTENER.LOG 화일. (전체의 로그 화일이 아니라 이슈를 커버하는 시간 대의 로그만 있으면 됨) 서버 ORACLE_HOME/network/log 아래의 SQLNET.LOG 화일 errorstack 트레이스 화일. 알려진 이슈들: 종종 ORA-609 에러가 접속이 완전히 이루어지기 전에 클라이언트가 접속이 끊기면서 발생한다. LISTENER.ORA 안에 있는 Timeout 파라미터 INBOUND_CONNECT_TIMEOUT_<listener_name> 과  SQLNET.ORA 화일 안에 있는 SQLNET.INBOUND_CONNECT_TIMEOUT 파라미터를 리뷰할 필요가 있다. 기본 시간인 60초를 사용한다면(명시적인 셋팅 없이), 이 파라미터는 증가시킬 필요가 있다. 데이타베이스가 수행 중인 서버 머신에서 네트워크 파라미터 셋팅을 확인한다. 셋팅 값이 모두 맞게 되었는지, DNS 서버가 가용한 상태인지 확인한다. 서버 플랫폼이 Microsoft Windows인 경우, 각 서비스가 동일한 계정으로 정상 기동되었는지 데이타베이스와 TNS 리스너를 위한 Windows 서비스를 확인해야 한다. REFERENCES NOTE:793415.1 - How to Perform the Equivalent of SQL*Net Client Tracing with Oracle JDBC Thin Driver NOTE:1050942.1 - How to Trace the Network Packets Exchanged Between JDBC and the RDBMS in Release 11.2 NOTE:609.1 - ORA-609 TNS-12537 and TNS-12547 in 11g Alert.log