About DATABASE

문제 설명
Oracle은OPEN_CURSORS매개변수를 사용하여 세션이 동시에 취할 수 있는 최대 열린 커서 개수를 지정합니다. 최대 개수를 초과하면 Oracle은ORA-01000오류를 보고합니다. 이 오류가 WebLogic Server로 전송되면SQLException이 발생합니다.

java.sql.SQLException: ORA-01000: maximum open cursors exceeded

이 패턴은 WebLogic Server를 사용할 때 오류를 발생시키는 원인과 해결 방법에 대해 설명합니다. 문제 해결 다음 항목을 모두 수행해야 하는 것은 아닙니다. 어떤 경우에는 다음 중 일부만 수행하여도 해결할 수 있습니다. 항목 바로가기 진 단 조회 일 반적인 원인과 해결 방법 코 드 연습 명 령문 캐시 데 이터베이스 드라이버

진단 조회 다음 SQL 조회는ORA-01000문제를 진단하는 데 유용합니다. 이런 조회를 실행하려면 데이터베이스에 관리자로 로그인하거나 데이터베이스 관리자가 사용자에게v$뷰에서 SELECT 명령문을 실행할 수 있는 권한을 승인해야 합니다. 1. 데이터베이스의 OPEN_CURSORS 매개변수 값을 확인합니다. Oracle 은OPEN_CURSORS초기 화 매개변수를init.ora에 사용하여 세션이 동시에 취할 수 있는 최대 커서 개수를 지정합니다. 디폴트값은 50이지만, WebLogic Server와 같은 시스템에는 너무 작습니다. 다음 조회를 사용하여 데이터베이스에서OPEN_CURSORS매개변수 값을 찾을 수 있습니다.

 

SQL> show parameter open_cursors; NAME                                 TYPE        VALUE ------------------------------------ ----------- ------------------------------ open_cursors                         integer     1000

OPEN_CURSORS값을 충분히 큰 값으로 설정하여 응용 프로그램에서 열린 커서가 부족하지 않도록 해야 합니다. 이 수는 응용 프로그램에 따라 다릅니다. 세션이OPEN_CURSORS에 지정된 커서 개수만큼 열지 않는 경우 이 값을 실제 필요한 값보다 크게 설정해도 오버헤드가 추가되지 않습니다. 2. 열린 커서의 수를 확인합니다. 아래 조회는 사용자 'SCOTT'가 각 세션에 대해 연 커서 개수를 내림차순으로 표시합니다.

 

SQL> select o.sid, osuser, machine, count(*) num_curs   2  from v$open_cursor o, v$session s   3  where user_name = 'SCOTT' and o.sid=s.sid   4  group by o.sid, osuser, machine   5 order by  num_curs desc;       SID OSUSER               MACHINE                                              NUM_CURS ---------- ---------------- ------------------------------------------------- ----------        217                                m1                                                           1000         96                                 m2                                                            10        411                                m3                                                             10         50                                test                                                              9

WebLogic Server에서 커넥션 풀을 사용할 때 커넥션을 커넥션 풀에서 가져온 경우 이 조회의user_name은 커넥션을 생성하는데 사용한user_name이 어야 합니다. 조회 결과는 시스템 이름도 출력합니다. 조회 결과를 통해 열린 커서의 개수가 큰SID와 WebLogic Server를 실행하는 시스템 이름을 식별할 수 있습니다. v$open_cursor는dbms_sql.open_cursor()를 사용하여 연 동적 커서인PARSED및NOT CLOSED를 세션에 대해 추적할 수 있습니다. 구문 분석 하지 않은 열린 동적 커서는 추적하지 않습니다. 응용 프로그램에서 동적 커서의 사용은 흔하지 않습니다. 이 패턴은 동적 커서가 사용되지 않는 것으로 간주합니다. 3. 커서에 대해 실행 중인 SQL을 확인합니다. 위의 조회 결과에서 식별한 SID를 취하고 다음 조회를 실행합니다.

SQL> select q.sql_text   2  from v$open_cursor o, v$sql q   3  where q.hash_value=o.hash_value and o.sid = 217; SQL_TEXT --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- select * from empdemo where empid='212' select * from empdemo where empid='321' select * from empdemo where empid='947' select * from empdemo where empid='527' ...

결과는 커넥션 상에서 실행 중인 조회를 표시합니다. 이를 기준으로 열린 커서의 출처를 역추적할 수 있습니다. 페 이지 맨 위 일 반적인 원인과 문제 해결 다음 단계는 문제의 원인을 파악하고 가능한 해결 방법을 모색하는 절차입니다. 코드 연습 이 문제의 가장 일반적인 원인은 JDBC Object가 정상적으로 닫히지 않은 경우입니다. 모든 JDBC Object가 정상적으로 닫혔는지 확인하기 위해 응용 프로그램 코드에서 역추적하려면진 단 조회에 타사의 조회 결과를 사용합니다. 모든 JDBC Object가 정상적인 상태나 예외 조건에서 닫히도록 하려면finally블록에서 Connections, Statements 및 ResultSets 같은 JDBC Object를 명시적으로 닫는 것이 좋습니다. 다음은 일반적인 예제입니다.

Connection conn = null; Statement stmt = null; ResultSet rs = null; try {     conn = getConnection(); //Method getConnection will return a JDBC Connection     stmt = conn.createStatement();     rs = stmt.executeQuery("select * from empdemo");     // do work } catch (Exception e) {     // handle any exceptions } finally {     try {         if(rs != null)             rs.close();     } catch (SQLException rse) {}     try {         if(stmt != null)             stmt.close();     } catch (SQLException sse) {}     try {         if(conn != null)             conn.close();     } catch (SQLException cse) {} }

JDBC Object를 버리는 코딩 습관을 피하십시오. 다음 연습은 각 루프 반복에서 새 Connection, Statement 및 ResultSet를 얻지만 각 반복에 대해 JDBC Object를 닫지는 않습니다. 그러므로 JDBC Object leak이 발생합니다.

Connection conn = null; Statement stmt = null; ResultSet rs = null; String[] queries = new String[10]; //Define queries try {     for(int i = 0; i < 10; i++) {         conn = getConnection();         stmt = conn.createStatement();         rs = stmt.executeQuery(queries[i]);         // do work     } } catch (Exception e) {     // handle any exceptions } finally {     try {         if(rs != null)              rs.close();     } catch (SQLException rse) {}     try {         if(stmt != null)              stmt.close();     } catch (SQLException sse) {}     try {         if(conn != null)              conn.close();     } catch (SQLException cse) {} }

Connection을 닫을 때 Statement와 ResultSet를 닫아야 하지만 JDBC 사양에 따라 하나의 Connection Object에 여러 Statement를 작성한 경우에는 사용한 직후 Statement와 ResultSet를 명시적으로 닫는 것이 좋습니다. Statement와 ResultSet를 명시적으로 즉시 닫지 않으면 커서가 누적되어 Connection이 닫히기 전에 데이터베이스에 허용된 최대 개수를 초과할 수 있습니다. 예를 들어, 아래 코드 부분에서는finally블록에 서 Connection을 닫을 때 ResultSet와 Statement도 닫아야 합니다. 그러나 이 코드 부분은 하나의 Connection에 여러 Statement와 ResultSet를 생성합니다. 루프가 끝나기 전에 "maximum open cursors exceeded(열린 최대 커서 개수 초과)" 문제가 발생했을 수 있습니다.

Connection conn = null; try{     conn = getConnection();     for(int i = 0; i < NUM_STMT; i++) {         Statement stmt = null;         ResultSet rs = null;            stmt = conn.createStatement();          rs = stmt.executeQuery(/*some query*/);         //do work     } } catch(SQLException e) {      // handle any exceptions } finally {     try{         if(conn != null)             conn.close();     } catch(SQLException ignor) {} }

페 이지 맨 위

명령문 캐시 성능 향상을 위해 WebLogic Server는 커넥션 풀을 사용할 때 prepared statements와 callable statements를 캐시하는 기능을 제공합니다. WebLogic Server가 prepared statements나 callable statements를 캐시할 때 많은 경우에 DBMS는 열린 각 명령문에 대해 커서를 유지합니다. 그러므로 명령문 캐시 기능은 "maximum open cursors exceeded(열린 최대 커서 개수 초과)" 문제의 원인이 될 수 있습니다. 명령문 캐시 크기 속성은 커넥션 풀의 각 인스턴스에서 각 커넥션에 대해 캐시할 prepared statements와 callable statements의 전체 개수를 결정합니다. 명령문을 너무 많이 캐시하면 데이터베이스 서버의 열린 커서 개수가 최대 개수를 초과할 수 있습니다. WebLogic Server에서 디폴트 명령문 캐시 크기는 버전마다 다를 수 있습니다. 예를 들면 다음과 같습니다.  WebLogic Server 6.1에서 prepared statements의 디폴트 캐시 크기는 0입니다.http://e-docs.bea.com/wls/docs61/adminguide/jdbc.html#1133404를 참조하십시오. WebLogic Server 7.0에서 비XA 및 XA prepared statements의 디폴트 캐시 크기는 각각 5입니다.http://e-docs.bea.com/wls/docs70/adminguide/jdbc.html#1144702를 참조하십시오. WebLogic Server 8.1에서 prepared statements와 callable statements의 디폴트 캐시 크기 합계는 10입니다.http://e-docs.bea.com/wls/docs81/ConsoleHelp/jdbc_connection_pools.html#1107805를 참조하십시오. 명령문 캐시에 대한 커넥션 풀 속성 이름과 캐시 알고리즘의 구성 가능성은 WebLogic Server 버전마다 다릅니다. 자세한 내용은 설명서를 참조하십시오. 그러므로 WebLogic Server를 이전 버전에서 최근에 업그레이드한 경우 명령문 캐시의 동작 변경은 열린 커서의 개수에 영향을 줄 수 있다는 점을 고려하십시오. ""maximum open cursors exceeded(열린 최대 커서 개수 초과)" 문제가 명령문 캐시와 관련이 있는지 확인하려면 명령문 캐시 크기를 0으로 설정하여 이 기능을 해제하거나 캐시 크기를 줄여 오류가 계속 발생하는지 확인할 수 있습니다. 캐시 크기를 줄여도 문제가 발생하지 않으면 커넥션 풀의 원래 명령문 캐시 크기가 너무 크거나 DBMS의 최대 열린 커서 개수 제한이 너무 적은 것이므로, 이 중 하나의 값을 조정해야 할 수 있습니다. 커넥션에 열린 커서의 개수가 계속 증가하다가 명령문 캐시 크기를 0으로 설정했을 때 이런 동작이 나타나지 않으면 커서 leak 문제일 수 있습니다. 사용 중인 JDBC 드라이버가 원인이거나 WebLogic Server 버그일 수도 있습니다. 다른 JDBC 드라이버를 사용해 보십시오. 다른 JDBC 드라이버를 사용할 때도 동일한 문제가 발생하면 기술 지원 엔지니어가 이 문제를 세부적으로 조사하여 WebLogic Server 버그인지 확인할 수 있도록 BEA에 보고하십시오. 페 이지 맨 위 데이터베이스 드라이버 ""maximum open cursors exceeded(열린 최대 커서 개수 초과)" 문제는 JDBC 드라이버가 원인일 수 있습니다. 드라이버가 문제인지 WebLogic 커넥션 풀이 문제인지 파악하기 위해 재현 가능한 테스트 케이스가 있으면 다음을 시도해 볼 수 있습니다. 1. 드라이버에서 커넥션을 직접 가져옵니다. 테스트 케이스에서 JDBC 커넥션은 드라이버에서 직접 가져오고 WebLogic 커넥션 풀은 우회합니다. 커넥션을 닫지 말고 배열이나 일부 다른 구조에 열어 두고 커서 leak 문제가 계속 발생하는지 확인합니다. 커넥션을 닫지 않는 이유는 커넥션 풀을 사용할 때의 동작을 시뮬레이션하기 위해서 입니다. 커넥션 풀을 사용할 때connection.close()는 커넥션을 실제로 닫지는 않으나 대신에 커넥션을 풀로 반환합니다. 2. 다른 JDBC 드라이버로 시도합니다. 타사의 JDBC 드라이버나 드라이버의 업데이트 버전으로 시도하여 문제가 계속 발생하는지 확인합니다. 메타 데이터를 사용하여 올바른 드라이버가 사용되었는지 확인할 수 있습니다. 샘플 코드는 다음과 같습니다.

Connection conn = getConnection(); DatabaseMetaData dmd = conn.getMetaData(); System.out.println("JDBC Driver Name is " + dmd.getDriverName());  System.out.println("JDBC Driver Version is " + dmd.getDriverVersion());

3. XA 드라이버 버그. Oracle XA 드라이버를 사용 중이고 데이터베이스에 "SELECT count (*) FROM SYS.DBA_PENDING_TRANSACTIONS" 같은 쿼리가 많은 경우 Oracle XA 드라이버에 커서 leak 문제가 발생할 수 있습니다. 이 문제는 MetaLink Case 3151681에 설명되어 있으며 버전 10.1.0.2에서 수정되었습니다. 또한 XA 드라이버를 사용할 때http://e-docs.bea.com/wls/docs81/jta/thirdpartytx.html#1075181에 설명된 대로 데이터베이스 서버에 XA 사용을 설정해야 합니다. 즉,grant select on dba_pending_transactions to public명 령을 실행해야 합니다. JDBC 드라이버가 문제이고 이 드라이버를 사용해야 할 경우 커서 leak 문제의 해결 방법은 WebLogic 커넥션을 가끔씩 재설정하거나 커넥션 풀을 축소하는 것입니다. 재설정하는 방법이나 커넥션 풀을 축소하는 방법은 WebLogic 설명서를 참조하십시오. 버전 8.1의 경우http://e-docs.bea.com/wls/docs81/ConsoleHelp/domain_jdbcconnectionpool_control.html에 설명되어 있습니다.

페 이지 맨 위

알려진 문제 사용하고 있는 WLS 버전의 릴리스 정보를 주기적으로 검토하여 서비스 팩에서 알려진 문제나 해결된 문제를 확인하고 ORA-01000 / 커서 Leak 관련 문제를 검색할 수 있습니다.다음을 참조하십시오. WLS 8.1 릴리스 정보 WLS 7.0 릴리스 정보 WLS 6.1 릴리스 정보 특별 정보의 경우, 각 버전의 서비스 팩 릴리스 정보에서 해결된 것으로 표시된 다음 CR를 참고하십시오.  CR129379- EJB 트랜잭션이 새로운 엔터티를 많이 만들거나 모두 JDBC를 사용하는 빈을 많이 끌어들인 경우 WebLogic Server가 Oracle 커서 부족의 위험을 감수합니다. 이는 의심되는 Oracle 드라이버 버그를 회피하기 위해 WebLogic Server가 트랜잭션이 끝날 때까지 JDBC 명령문 닫기를 지연시키고 명령문에 대한 커서를 유지하기 때문입니다. 이 동작은WLS 6.1 SP7,WLS 7.0 SP5및WLS 8.1 SP3에서 변경되었으므로 세션은 트랜잭션이 끝날 때까지 커서를 유지할 필요가 없습니다. CR179600 - WLS 8.1 SP3 - 특정 명령문 실패 조건에서 풀의 명령문 캐시는 DBMS 세션에서 커서 leak을 야기하는 명령문을 닫지 않을 수도 있습니다. 이 문제를 해결하기 위해WLS 8.1 SP4가 변경되었습니다. CR174126 - 하나의 트랜잭션에 다른 여러 prepared statements를 사용하면 XA 명령문 캐시에 버그를 발생시키므로 닫히지 않은 JDBC 명령문에 대한 핸들이 손실됩니다. 이로 인해 Oracle에서 사용 가능한 모든 커서가 신속하게 소모되어 leak이 발생합니다.WLS 8.1 SP3에서 XA 명령문 캐시를 구현하는 데 사용하는 기본 콜렉션 Object가 수정되었습니다. CR188814 - WLS 8.1 SP2 - EJB 2.0 CMP를 사용할 때 BLOB 또는 CLOB 열을 업데이트한 후에 PreparedStatement와 ResultSet가 닫히지 않았습니다. 이제 WebLogic Server는WLS 8.1 SP4에서 BLOB/CLOB를 업데이트할 때 PreparedStatement와 ResultSet를 닫습니다. 검색하면 릴리스 정보뿐 아니라추 가 도움말에서 언급된 기타 지원 솔루션 및 CR 관련 정보도 알 수 있습니다. 계약 고객은http://support.bea.com/에 로그인한 다음 Browse 포틀릿에서 Solutions 및 Bug Central을 검색하여 제품 버전별로 사용 가능한 최신 CR을 찾을 수 있습니다.

페 이지 맨 위

추 가 도움말이 필요하십니까?
패턴대로 작업했지만 추가 도움말이 필요한 경우 다음과 같이 할 수 있습니다.

1. http://support.bea.com/의 AskBEA에서"ORA-01000: maximum open cursors exceeded" 등으로 문제를조회하여 게시된 다른 해결 방법을 찾아봅니다. 계약 지원 고객: 제공되는 CR 관련 정보에 액세스할 수 있는 권한으로 로그온합니다
2. http://forums.bea.com에 서 BEA 뉴스그룹에 보다 자세한 내용을 질문합니다.
   

이렇게 해도 문제를 해결할 수 없는 경우 유효한 유지 보수 계약이 되어 있다면http://support.bea.com/에 로그인하여 지원요청할 수 있습니다.

리스너 로그 파일에  아래와 같은 메시지의 흔적이 보여 메타링크를 찾아봤습니다.

WARNING: Subscription for node down event still pending


역시나 올해 1월 8일에 메타링크에 이미 공지된 내용이네요. 10g 에서만 문제되는 듯합니다 ^^

오라클 리스너 파일에 아래 파라미터를 추가하면 되네요..

SUBSCRIBE_FOR_NODE_DOWN_EVENT_LISTENER=OFF





출처: 오라클 메타링크

Applies to:

Oracle Server - Enterprise Edition - Version: 10.1.0.5 to 10.2.0.4
This problem can occur on any platform.

Symptoms

Database can crash many times if Automatic Shared Memory Management (ASMM) is used.

Database crashes many times with the following messages from alert_log:-

Tue Oct 28 13:20:35 2008
Errors in file /ora/product/10.2.0prd/admin/oradwprd/bdump/oradwprd_cjq0_1990.trc:
Tue Oct 28 13:22:03 2008
System State dumped to trace file
Tue Oct 28 13:41:45 2008
MMNL absent for 1310 secs; Foregrounds taking over
Tue Oct 28 13:41:52 2008
MMNL absent for 1256 secs; Foregrounds taking over
MMNL absent for 1256 secs; Foregrounds taking over
MMNL absent for 1256 secs; Foregrounds taking over
Tue Oct 28 14:25:28 2008
...
Tue Oct 28 20:16:50 2008
ksvcreate: Process(m000) creation failed
Tue Oct 28 20:21:32 2008
MMNL absent for 1311 secs; Foregrounds taking over
Tue Oct 28 20:45:05 2008

The AWR report during the time the crash happens shows the following:-

Cache Sizes
~~~~~~~~~~~ Begin End
---------- ----------
Buffer Cache: 1,280M 1,568M Std Block Size: 8K
Shared Pool Size: 720M 432M Log Buffer: 15,148K

Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 1,031.15 6,487.12
Logical reads: 15,843.66 99,674.56
Block changes: 3.61 22.70
Physical reads: 1,975.69 12,429.32
Physical writes: 454.90 2,861.83
User calls: 53.04 333.65
Parses: 2.14 13.45
Hard parses: 0.44 2.79
Sorts: 1.91 12.00
Logons: 0.03 0.18
Executes: 3.74 23.55
Transactions: 0.16

% Blocks changed per Read: 0.02 Recursive Call %: 43.94
Rollback per transaction %: 7.99 Rows per Sort: ########

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 97.12 Redo NoWait %: 100.00
Buffer Hit %: 94.80 In-memory Sort %: 99.10
Library Hit %: 84.79 Soft Parse %: 79.23
Execute to Parse %: 42.89 Latch Hit %: 95.30
Parse CPU to Parse Elapsd %: 10.35 % Non-Parse CPU: 62.73

Shared Pool Statistics Begin End
------ ------
Memory Usage %: 14.69 25.80
% SQL with executions>1: 83.47 43.38
% Memory for SQL w/exec>1: 69.04 43.09

Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
latch: library cache 125 14,869 ###### 33.3 Concurrenc
latch: shared pool 553 13,177 23828 29.5 Concurrenc
read by other session 1,653,348 8,455 5 18.9 User I/O
CPU time 4,353 9.7
db file sequential read 841,956 3,000 4 6.7 User I/O

Cause

Huge contention for shared pool and library cache latches are seen from AWR report during the problem period.

Also the shared pool size is getting shrinked during the problem as evident from AWR.

This is because of dynamic memory allocation with in SGA.

As Automatic SGA is used, the repeated shrink / growth in the shared pool and buffer cache would happen and that could cause lot of waits in sessions.

Because of Auto SGA, the shared pool is shrinked during the problem and thats why the contention is seen across the shared pool which caused the database crash.

From the systemstate dumps it is shown Location from where latch is held:  ksucrp:
The function is used to Create and initialise a process.
The process cannot be initialized due to lack of memory.

All the messages seen in alert log are the indication of lack of memory available in shared pool.

Bug 6528336 seems to have caused the problem.

Solution

To disable Auto SGA.

sga_target=0

Configure memory components separately for shared pool and buffer cache.

shared_pool_size=<value>M

db_cache_size=<value>M

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 결과

SQL> @TBOARD
SP2-0734: unknown command beginning "작업이 진..." - rest of line ignored.
SP2-0734: unknown command beginning "각각의 업..." - rest of line ignored.
SP2-0734: unknown command beginning "업무 진행..." - rest of line ignored.
SP2-0734: unknown command beginning "==========..." - rest of line ignored.
SP2-0044: For a list of known commands enter HELP
and to leave enter EXIT.
SP2-0734: unknown command beginning "시스템 Upd..." - rest of line ignored.
SP2-0734: unknown command beginning "==========..." - rest of line ignored.
SP2-0734: unknown command beginning "TO_DATE('0..." - rest of line ignored.


해결방범
set sqlblanklines on 
을 하고 스크립트 실행하면 된다.