About DATABASE

RAC 환경에서 ORA-29740 문제 진단
=================================

PURPOSE

---

이 문서는, RAC 환경에서의 ORA-29740 문제를 진단하는 방법을 기술하는 데 목적이 있다.

SCOPE

---

Real Application Clusters(RAC) Option은 9i Standard Edition에서는
지원하지 않는다.

Problem Description

---

ORA-29740 에러는, 클러스터 환경에서 소속된 그룹의 다른 인스턴스가 여러가지 이유로 인해, 멤버 인스턴스를
축출할 때 발생하는 문제이다. 주요 이유로는, 클러스터 내부의 통신 장애나, control file에 대한 heartbeat 실패
등이 있다.
이와 같은 메카니즘은, 데이터베이스 전체에 미치는 악영향을 예방하기 위해 설계된 것이다. 예를 들어,
클러스터 전체에 Hang이 발생하는 것보다는, 오라클에서는 문제를 유발시키는 인스턴스를 클러스터에서
추출시키는 편을 택한다.
ORA-29740 에러가 발생할 경우, 클러스터에 계속 남게되는 인스턴스가, 문제를
유발시키는 인스턴스를 클러스터에서 제외시키게 된다.

문제가 발생할 경우, 여러개의 인스턴스는, control file에 대한 갱신 권한을 획득 하기위해 control file에 대한
lock에 대해 경합하게 된다.
Control file에 대한 lock을 RR lock 또는 Result Record Lock이라 한다.
마침내 lock을 획득한 인스턴스가, 클러스터 멤버 구성을 결정하기 위한, "투표"
를 주관하게 된다.
멤버 인스턴스는 다음과 같은 경우 추출된다.

a) 통신 회선 장애
b) 하나 이상의 subgroup에서, subgroup 간 split-brain 현상이 발생
하는데, 멤버 인스턴스가, 가장 큰 subgroup에 속하지 않는 경우
c) 멤버 인스턴스가 inactive 상태인 것이 감지되었을 때

* Split-brain 현상은 클러스터 내 노드 간의 통신 장애가 발생하여, 각 노드입장에서는 다른 노드가 죽은 것으로 간주
하는데, 실제로는, 각 노드들은 살아 있는 경우를 말한다. 이와 같은 현상이 발생했을 때 적절한 조치를 취하지
않는다면, 각 노드에서 오라클 데이터 파일에 대해 write를 수행하여, corruption이 발생할 수 있다.

추출된 인스턴스의 alert log에는 다음과 같은 메시지가 남아 있게 된다.

Fri Sep 28 17:11:51 2001
Errors in file /oracle/export/TICK_BIG/lmon_26410_tick2.trc:
ORA-29740: evicted by member %d, group incarnation %d
Fri Sep 28 17:11:53 2001
Trace dumping is performing id=cdmp_20010928171153
Fri Sep 28 17:11:57 2001
Instance terminated by LMON, pid = 26410

ORA-29740 에러에 대한 진단을 위해서는 각 인스턴스 별 LMON 트레이스 파일을 분석하는 것이 중요하다.
추출된 인스턴스에서는 다음과 같은 메시지가 남게 된다.

*** 2002-11-20 18:49:51.369
kjxgrdtrt: Evicted by 0, seq (3, 2)
^

위 내용은, 어느 인스턴스에서 추출을 시켰는지를 나타낸다.

추출을 시킨 인스턴스에서는 다음과 같은 메시지가 남는다.

kjxgrrcfgchk: Initiating reconfig, reason 3
*** 2002-11-20 18:49:29.559
kjxgmrcfg: Reconfiguration started, reason 3

...
*** 2002-11-20 18:49:29.727
Obtained RR update lock for sequence 2, RR seq 2
*** 2002-11-20 18:49:31.284
Voting results, upd 0, seq 3, bitmap: 0
Evicting mem 1, stat 0x0047 err 0x0002

위에서 보는 바와 같이 인스턴스에서는 reconfiguration을 reason 3에 의해
시작하였음을 알 수 있다. (reconfiguration 관련 내용은, Note 139435.1
참조.

클러스터에 대한 reconfiguration을 시작한 인스턴스는 RR lock (Results Record Lock)을 획득하여야
하는데 이것은 이 인스턴스가, 멤버 구성에 대한 투표를 주재할 권한을 가진 다는 것을 의미한다.
마지막 줄에서는, 투표 결과를 나타내고 있으며, 결과적으로 1번 인스턴스를 추출시키는 것을
나타내고 있다.

ORA-29740 에러에 대한 문제 해결을 위해서는 '이유'가 (위 예에서는 reason 3로 나와있음)
무엇인지가 중요하다.
위 예제에서 첫번째 섹션이 reconfiguration을 시작한 이유를 나타내고 있다.

Reason 0 = No reconfiguration
Reason 1 = The Node Monitor generated the reconfiguration.
Reason 2 = An instance death was detected.
Reason 3 = Communications Failure
Reason 4 = Reconfiguration after suspend

대부분의 ORA-29740 에러에서는 reason 코드 1,2,3번을 만나게 될 것이다.

다음은 각각의 코드에 대한 설명이다.

Reason 1: 노드 모니터에서 reconfiguration을 지시하는 경우 :

a) 인스턴스가 클러스터에 합류할 때
b) 인스턴스가 클러스터에서 이탈할 때
c) 노드가 halt 상태가 될 때

이 경우는, 에러의 원인을 모든 인스턴스의 alert log와 LMON 트레이스파일을 살펴봄으로써 쉽게
알 수 있다. 인스턴스가 클러스터에 합류 또는 이탈하거나 halt 상태가 될 때
ORA-29740 에러가 발생하는 것은 정상적인 경우이며 문제가 되지 않는다.
만약 문제가 되는 경우로 의심이 된다면 Metalink에서 다음 검색어로 검색하도록 한다.

ORA-29740 'reason 1'

살펴 보아야 할 주요 파일은 다음과 같다:

a) 각 인스턴스의 alert log
b) 각 인스턴스의 LMON 트레이스 파일
c) 각 노드의 syslog 또는 messages 파일 (유닉스 플랫폼의 경우)

Reason 2: 인스턴스 종료가 감지된 경우 :

a) 인스턴스가 비정상 종료가 heartbeat 또는 control file로 인해 발생한 경우

Hearbeat이 누락될 경우, LMON에서는 heartbeat을 보내지 않는 인스턴스에 대해 네트워크
ping을 테스트 해 본다. 인스턴스가 ping에 대해 응답할 경우 LMON에서는 인스턴스가
살아 있는 것으로 간주한다. 하지만, hearbeat이 일정 기간동안 발생하지 않을 경우 ( 기간은
control file의 enqueue timeout에 지정되어 있음 ) 해당 인스턴스에 문제가 발생한 것으로
간주하고, 그 인스턴스를 클러스터에서 추출한다. 문제가 발생하는 경우에 대해서는 추가적인
분석이 필요한데, 이것은, 일반적으로 클러스터에서 추출 되기 전 ORA-600 2103 에러가
수반되기 때문이다. 만약 문제가 되는 경우로 의심 된다면, Metalink에서 다음 검색어로
검색 하도록 한다.
ORA-29740 'reason 2'

살펴 보아야 할 주요 파일은 다음과 같다:

a) 각 인스턴스의 alert log
b) 각 인스턴스의 LMON 트레이스 파일
c) 추출된 인스턴스의 CKPT process trace file
d) bdump 또는 udump에 존재하는 다른 파일
e) 각 노드의 syslog 또는 messages 파일 (유닉스 플랫폼의 경우)

Reason 3: 통신 장애가 발생한 경우 :

a) LMON 프로세스가 서로 통신 할 수 없을 때
b) 인스턴스가 다른 인스턴스의 LMD 프로세스와 통신 할 수 없을 때
c) LMON 프로세스가 블러킹, 스핀 (무한루프) 또는 살아는 있으나 동작을
하지 않아 다른 인스턴스의 LMON 프로세스의 요청에 응답하지 않을 때
d) LMD 프로세스가 블럭킹 또는 스핀 상태가 될 경우

이 경우 ORA-29740 에러는, 인스턴스간의 통신이 실패할 경우 기록된다.
이것은 인스턴스가 IPC 전송에 대한 timeout이 발생하여, 클러스터에서 추출 된
경우를 의미한다. LMON이 아닌 foreground 또는 backgroupd 프로세스와 원격지 LMON에서 통신 장애가
발생 할 경우에도 ORA-29740 이 발생하며 코드로 reason 3 이 남게 된다.
이와 같은 ㅁ문제가 발생 할 경우, 트레이스 파일 또는, 프로세서에서 다음과 같은
메시지가 나타난다 :

Reporting Communication error with instance:

만약 통신 장애가 클러스터 레벨에서 발생할 경우 (예 : 네트워크 케이블이 뽑힌 경우) 클러스터 소프트웨어는
클러스터의 split-brain 현상에 대응하기 위해 노드 추출을 시도하게 된다.
이 문제는 LMON 이 캐쉬된 자원을 처분할 (cleanup) 때도 발생할 수 있다. 만약 한번에 100개의 자원을 처분하려 한다면
중간에 클러스터 매니저의 활동을 점검해 본다. 만약 각각의 삭제 작업이 그리 오랜 시간이 걸리지 않지만
처분해야 할 자원이 너무 많다면, LMON이 상당 시간동안 블러킹 상태가 되며, LMON에서 원격지의 메시지를 처리
할 수 없게 되어 timeout이 발생하게 된다. 이 문제는 9.0.1.4 이상과 9.2.0.1에서 해결된 문제이다.

사용중인 오라클 버전에서 bug 2276622가 해결되었는지 확인해 볼 필요가 있으며, 만약 위 bug이 해결된
버전에서 클러스터 추출이 문제가 되는 경우로 의심된다면, Metalink에서 다음 검색어로
검색 하도록 한다.

ORA-29740 'reason 3'

살펴 보아야 할 주요 파일은 다음과 같다:

a) 각 인스턴스의 alert log
b) 각 인스턴스의 LMON 트레이스 파일
c) 각 인스턴스의 LMD trace file
d) bdump 또는 udump에 존재하는 다른 파일.
e) 각 노드의 syslog 또는 messages 파일 (유닉스 플랫폼의 경우)
f) Netstat -ai 그리고 netstat -s 결과