앞서 Cache Fusion의 개념에 대해 알아보았는데, 이번에는 Cache Fusion의 엑세스에 대해 알아보겠다.

Cache Fusion Access

Cache Fusion은 서로 다른 Node의 Instance에서 Block을 동기화하여 액세스하는 기술이다. 따라서 필요한 Block이 접속한 Instance에 존재하는 경우와 아닌 경우로 구분할 수 있다.

Local Access

요청한 Block의 최신 Block이 Local Instance에 존재할 경우 Instance 간 동기화없이 액세스한다. 

즉, Block을 액세스하는 세션의 위치 = 필요한 Block의 위치 = Master Node의 위치 인 경우를 Local 액세스라고 한다.  

Remote Access

요청한 Block이 다른 Instance에 의해 수정되어 Remote Instance에 존재할 경우 Interconnect를 통해 Block을 복제하여 가져온 후 Data에 액세스한다.

2-way Access

1. Instance 2에 접속한 세션에서 1번 Block을 액세스하는데, Instance 2에는 1번 Block이 없다.

2. Instance 2는 1번 Block을 Master Node인 Instance 3에게 요청한다.

3. Master Node는 GRD를 확인하여 1번 Block의 소유자(Holder Node)가 Instance 3인 것을 확인하고 Instance 3에게 Block 요청을 전달한다.

4. Instance 3은 Master Node의 요청을 받고 1번 Block의 이미지를 Instance 2에 전송한다.

5. Block을 전송받은 Instance 2는 세션의 요청에 대한 응답을 수행한다. 

즉, Block을 요청하는 세션의 위치 ≠ Block의 위치 = Master Node의 위치 인 경우 2개의 Instance에 액세스하기 때문에 2-way Access라고 한다.

3-way Access

1. Instance 2에 접속한 세션에서 1번 Block을 액세스하는데, Instance 2에는 1번 Block이 없다.

2. Instance 2는 1번 Block을 Master Node인 Instance 3에게 요청한다.

3. Master Node는 GRD를 확인하여 1번 Block의 소유자(Holder Node)가 Instance 1인 것을 확인하고 Instance 1에게 Block 요청을 전달한다.

4. Instance 1은 Master Node의 요청을 받고 1번 Block의 이미지를 Instance 2에 전송한다.

5. Block을 전송받은 Instance 2는 세션의 요청에 대한 응답을 수행한다. 

즉, Block을 요청하는 세션의 위치 ≠ Block의 위치 ≠ Master Node의 위치 인 경우 3개의 Instance에 액세스하기 때문에 3-way Access라고 한다.

Disk Access

1. Instance 2에 접속한 세션에서 1번 Block을 액세스하는데, Instance 2에는 1번 Block이 없다.

2. Instance 2는 1번 Block을 Master Node인 Instance 2에게 요청한다.

3. Master Node는 GRD를 확인하여 1번 Block이 어느 Instance에도 존재하지 않음을 확인한다.

4. Master Node에게 그 사실을 전달받은 Instance 2는 Disk에 존재하는 해당 Block을 Instance 2의 DB Buffer Cache에 캐싱한다.

5. Instance 2에 해당 Block이 캐싱되었으므로 해당 Block을 엑세스한다. 

즉, 요청한 Block이 어느 Instance에도 존재하지 않을 경우 Disk Access를 한다.

Oracle RAC의 DB Buffer Cache

오늘은 오라클 RAC 특징에 있어서 가장 중요한 cache fusion에 대해서 알아보겠다. 그러면 그 전에 DB Buffer cache에 대해서 알아야 한다.

Node

하나의 DB에 연결된 서버를 의미한다. 2 Node RAC는 2대의 물리적인 서버가 하나의 DB에 연결된 경우이다.

Instance

각각의 Node는 각각의 Instance를 가진다. 하나의 Instance는 여러 Node에 중복 존재할 수 없지만 하나의 Node는 여러개의 Instance로 구성할 수 있다.

SGA

하나의 Instance는 반드시 하나의 SGA를 가지며 SGA는 Shared Pool, DB Buffer Cache, Redo Log Buffer 등으로 구성된다.

Cache Fusion과 DB Buffer Cache

DB Buffer Cache는 유저가 요청한 SQL문을 수행하기 위해서 필요한 Data Block을 Disk로부터 메모리로 올리는(Caching) 하는 영역이다. Cache Fusion에서 DB Buffer Cache가 중요한 이유는 Cache Fusion이 서로 다른 Instance의 DB Buffer Cache에서 Block을 이동시키는 부분에서 발생하기 때문이다.

Cache Fusion

Cache Fusion은 OPS(Oracle Parallel Server)의 Block Transformation의 문제를 극복하기 위해 나타난 아키텍쳐이며 이를 통해 Oracle RAC는 성능적으로 안정성을 갖추게 되었다.

*Block Transformation

특정 Instance에 존재하는 Block을 다른 Instance에서 액세스하기 위해서 해당 블럭을 공유 Storage에 write한 후, 그 Block을 호출한 Instance의 DB Buffer Cache로 캐싱하여 Data Block을 다른 Node로 이동시키는 방식이다.

하지만 각각의 Instance에서 많은 작업이 수행되고, 각각의 Instance 사이에서 이동하는 Block이 많으면 성능 저하가 발생한다. 이 이유로 OPS는 사라지게 되었다.

Cache Fusion은 아래와 같은 방식으로 수행된다.

① Instance 2에 접속한 A 프로세스는 Instance 1에 존재하는 1번 Block을 액세스하기 위해 호출한다.

② Instance 1에 존재하는 1번 Block은 Instance 2의 호출에 응답하기 위해 Instance 2의 SGA의 DB Buffer Cache로 이동해야 한다. 이동을 위해 공유 Storage에 존재하는 DB를 이용하지 않고 Instance 사이의 Interconnect를 이용한다.

③ Interconnect를 이용하여 Instance 2로 캐싱된 1번 Block을 A 프로세스가 액세스할 수 있게 된다.

Cache Fusion의 목적

Block이 특정 Node의 DB Buffer Cache에 로드되어 있다면 Disk I/O가 발생하지 않기 때문에 Block 이동을 빠르게 처리할 수 있어서 Oracle RAC의 성능 향상에 가장 중요한 아키텍쳐이다.

Cache Fusion의 구성 요소

• GRD(Global Resource Directory)

   RAC에서 Global Resource를 관리한다. Cluster의 동기화를 위해서 Cluster 내의 Resource 정보들(Resource Master,       Resource Holder)을 저장한다.

*Resource Master : 특정 Resource의 Master를 지칭한다. 특정 Global Resource는 반드시 하나의 GRD에서 최신 정보를 관리한다.

*Resource Holder : 특정 Resource의 최종 버전을 가지고 있는 Node를 의미한다.

• GCS(Global Cache Service)

   Data의 일관성 및 무결성을 유지하는 서비스로, DB Buffer Cache 동기화에 대한 Global 정보를 저장한다. 즉, Block에     대한 Lock 정보를 관리한다.

• GES(Global Enqueue Service)

   DB Lock에 대한 정보를 관리하는 서비스로 Block 이외의 Lock 정보를 저장한다. 즉, Enqueue Lock, Library Cache         Lock, Row Cache Lock 등의 정보를 관리한다.

[성능튜닝] ASH(Active Session History)란?

12bme 2018.01.30 13:41

ASH(Active Session History)

SQL> select * from v$sgastat where name = 'ASH buffers';

POOL      NAME    BYTES

---------  ---------  ---------

shared pool ASH buffers 16252928

- 오라클은 현재 접속해서 활동 중인 Active 세션 정보를 1초에 한번씩 샘플링해서 ASH 버퍼에 저장합니다.

- SGA Shared Pool에 CPU당 2MB의 버퍼를 할당받아 세션 정보를 기록하며, 1시간 혹은 버퍼의 2/3가 찰때마다 디스크로 기록합니다. 즉, AWR에 저장하는 것입니다.

- v$active_session_history 뷰를 이용해 ASH 버퍼에 저장된 세션 히스토리 정보를 조회할 수 있습니다.

select /* 1. 샘플링이 일어난 시간과 샘플 ID */ sample_id, sample_time /* 2. 세션정보, User명, 트랜잭션ID */ , session_id, session_serial#, user_id, xid /* 3. 수행중 SQL 정보 */ , sql_id, sql_child_number, sql_plan_hash_value /* 4. 현재 세션의 상태 정보 'ON CPU' 또는 'WAITING' */ , session_state /* 5. 병렬 Slave 세션일때, 쿼리 코디네이터(QC) 정보를 찾을 수 있게함 */ , qc_instance_id, gc_session_id /* 6. 현재 세션의 진행을 막고 있는(=블로킹) 세션 정보 */ , blocking_session, block_session_serial#, blocking_session_status /* 7. 현재 발생 중인 대기 이벤트 정보 */ , event, event#, seq#, wait_class, wait_time, time_waited /* 8. 현재 발생 중인 대기 이벤트의 파라미터 정보 */ , p1text, p1, p2text, p2, p3text, p3 /* 9. 해당 세션이 현재 참조하고 있는 오브젝트 정보. V$session 뷰에 있는 row_wait_obj#, row_wait_file#, row_wait_block# 컬럼을 가져온 것임 */ , current_obj#, current_file#, current_block# /* 10. 애플리케이션 정보 */ , program, module, action, client_id from V$ACTIVE_SESSION_HISTORY

7과 8번 '대기 이벤트' 정보는 두말할 것도 없고, 6번 '블로킹 세션' 정보와 9번 '현재 액세스 중인 오브젝트' 정보도 매우 유용합니다. 블로킹 세션 정보를 통해 현재 Lock을 발생시킨 세션을 빠릴 찾아 해소할 수 있게 도와줍니다.

오브젝트 정보도 더할 나위 없이 유용하지만 현재 발생 중인 대기 이벤트의 Wait Class가 Application, Concurrency, Cluster, User I/O일 때만 의미있는 값임을 알아야 합니다.

예를 들어, ITL 슬롯 부족?? 때문에 발생하는 enq: TX - allocate ITL entry 대기 이벤트는 Configuration에 속하므로, v$active_session_history 뷰를 조회할 때 함께 출력되는 오브젝트에 Lock이 걸렸다고 판단해서는 안됩니다. 대개 그럴때는 오브젝트 번호가 -1로 출력되지만 직전에 발생한 이벤트의 오브젝트 정보가 계속 남아서 보이는 경우가 있으므로 잘못 해석하지 않도록 주의해야 합니다.

column current_obj# format 99999 heading 'CUR_OBJ#'

column current_file# format 999 heading 'CUR_FIL#'

column current_block# format 999 heading 'CUR_BLK#'

select to_char(sample_time, 'hh24:mi:ss') sample_tm, session_state, event, wait_class, current_obj#, current_file#, current_block#

from v$active_session_history

where session_id = 143

and session_serial# = 9

order by sample_time;

초단위로 쓰기가 발생하는 ASH 버퍼를 읽을 때 래치를 사용한다면 경합이 생길 수 있습니다. 따라서 오라클은 ASH 버퍼를 읽는 세션에 대해서는 래치를 요구하지 않으며 그 때문에 간혹 일관성 없는 잘못된 정보가 나타날 수도 있습니다.

ASH 기능을 이용하면 현재뿐 아니라 과거시점에 발생한 장애 및 성능 저하 원인까지 세션 레벨로 분석할 수 있게 도와줍니다. 오라클 10g부터는 v$active_session_history 정보를 AWR 내에 보관하므로 과거치에 대한 세션 레벨 분석이 가능해졌습니다 (SGA를 DMA방식으로 액세스)

1/10만 샘플링해서 저장(문제가 되는 대기 이벤트는 일정간격을 두고 지속적으로 발생하기 때문에 샘플링된 자료만으로도 원인을 찾는데 큰 지장이 없습니다)

v$active_session_history를 조회했을때 정보가 찾아지지 않는다면 이미 AWR에 쓰여진것으로 dba_hist_active_sess_history 뷰를 조회하면 됩니다.

1. AWR 뷰를 이용해 하루 동안의 이벤트 발생현황을 조회해본다. 그래프는 dba_hist_system_event를 이용해 그린 것인데, 08:15~09:15 구간에서 enq: TM - contention 이벤트가 다량 발생한 것이 환인 되었다.

2. dba_hist_active_sess_history를 조회해서 해당 이벤트를 많이 대기한 세션을 확인한다.

3. 블로킹 세션 정보를 통해 dba_hist_active_sess_history를 다시 조회한다. 블로킹 세션이 찾아지면 해당 세션이 그 시점에 어떤 작업을 수행 중이었는지 확인한다. sql_id를 이용해 그 당시 SQL과 실행계획까지 확인할 수 있다. v$sql과 v$sql_plan까지 AWR에 저장되기 때문이다. 위 사례에서는 블로킹 세션인 Append Mode Insert를 수행하면서 Exclusive 모드 TM Lock에 의한 경합이 발생하고 있었다.

4. program, module, action, client_id 등 애플리케이션 정보를 이용해 관련 프로그램을 찾아 Append 힌트를 제거한다. 그러고 나서, 다른 트랜잭션과 동시에 DML이 발생할 수 있는 상황에서는 insert문에 Append 힌트를 사용해서는 안된다는 사실을 개발팀 전체에 공지한다.

ASH Viewer

ASH Viewer는 오라클 인스턴스 액티브 세션 히스토리 데이터 모니터링을 제공합니다. 링크를 통해 무료로 오픈소스기반 모니터링 툴을 다운받을 수 있습니다.

최근 ASH Viewer를 통해 실시간으로 Oracle 시스템을 모니터링하며 업무 진행하고 있습니다. V$ACTIVE_SESSION_HISTORY 데이터 기반으로 실시간으로 Oracle 시스템 현황을 모니터링 하는 툴인데요. 아직까지는 익숙치 않지만, 기존에 블로그를 통해 학습해왔던 오라클 시스템 튜닝 용어들을 실제 사용과 함께 눈에 익히고 있는 중입니다.

아래는 데모동영상에서 캡쳐한 화면입니다. 실제 Top Activity 화면도 아래와 같았습니다.

Other, Cluster, Queueing, Network, Administrative, Configuration, Commit, Application, Concurrency, System I/O, User I/O, Scheduler, CPU Used등의 항목을 Activice 세션당 사용률에 따라 아래 그래프처럼 표시됩니다. 보고싶은 시간만큼 그래프를 드래그하면 SQL, Session, Program 상세를 확인할 수 있습니다.

Detail 탭을 누르면 Top Activity 항목에 대한 상세 현황 그래프를 확인할 수 있습니다.

- CPU used (Active Session Waiting)

- Scheduler (Active Session Waiting)

- User I/O (Active Session Waiting)

   direct path write temp

   direct path read

   db file parallel read

   direct path read temp

   local write wait

   db file scattered read

   db file sequential read

- System I/O (Active Session Waiting)

   log file single write

   log archive I/O

   db file parallel write

   log file parallel write

   log file sequential read

   control file parallel write

   control file sequential read

- Concurrency (Active Session Waiting)

   row cache lock

   library cache lock

   os thread startup

- Application (Active Session Waiting)

   enq: R0 - fast object reuse

   enq: R0 - fast object reuse

- Commit (Active Session Waiting)

   log file sync

- Configuration (Active Session Waiting)

   log file switch (check point incomplete)

   enq: HW - contention

   log buffer space

   log file switch completion

- Administrative (Active Session Waiting)

- Network (Active Session Waiting)

   SQL*Net more data from client

   SQL*Net more data to client

- Queueing (Active Session Waiting)

- Cluster (Active Session Waiting)

   gc current grant busy

   gc cr block busy

   gc cr disk read

   gc current request

   gc cr request

   gc current block 3-way

   gc current multi block request

   gc current block busy

   gc cr multi block request

   gc cr block 3-way

   gc cr block 2-way

   gc current block 2-way

   gc cr grant 2-way

- Other (Active Session Waiting)

   enq: TT - contention

   px deq:L Signal ACK

   LGWR wait for redo copy

   reliable message

   latch: KCL gc element parent latch

   gcs log flush sync

   enq: FB - contention

   enq: WF - contention

   null event

   CGS wait for IPC msg

   DFS lock handle

   enq: PS - contention

실행방법: "/bin/java.exe" -Xmx528m -Dswing.defaultlaf=javax.swing.plaf.nimbusLookAndFeel -jar ASH.jar

* swing.defaultlaf 디폴트 Look&Feel 클래스 지정

* 실행방법 옵션 관련 추가 팁

JAVA 기반 어플리케이션을 구동하다보면 OOM(Out Of Memory)관련 에러가 발생하는 경우가 종종있습니다. 이럴 경우, JVM 옵션을 통해 관련 부분을 튜닝할 수 있습니다. 위 실행 방법의 Xmx가 그 옵션 중 하나입니다.

JAVA 메모리 구조

 - Heap = Eden + Survivor + Old

 - Non-Heap = Perm

GC와 Heap 영역의 기본 동작 원리

 - gc는 Eden과 ss1을 클리어하고 여전히 유효한 메모리에 대해서는 ss2로 이동시킵니다.

 - 그 다음 gc는 Eden과 ss2을 클리어하고 다시 유효한 메모리에 대해서는 ss1로 이동시킵니다.

메모리는 우선, Heap과 Non-Heap으로 나뉩니다.

 - Heap영역: new 연산자로 생성된 객체와 배열을 저장하는 영역으로 GC대상이 되는 영역입니다.

Eden: new키워드를 통해서 객체가 처음 생성되는 공간

Survivor: GC가 수행될때 살아있는 객체는 survivor 영역으로 이동

Old: survivor에서 일정시간 참조되는 객체들이 이동되는 공간

 - Non-Heap영역: 스택, 클래스 area, method area 등의 head을 제외한 나머지 영역

      Permanent: Class 메타정보, Method 메타정보, Static Object, 상수화된 String Object, Class관련 배열 메타정보, JVM 내부 객체와 최적화컴파일러(JIT) 최적화 정보 등 포함

XX: MaxPerm Size 옵션 값

XX:MaxPerm Size는 hot-deploy가 있을때 메모리 사용량이 점차 증가하는 부분입니다. 가령 서버에서 PermGen OOM 에러 발생시 이부분의 사이즈를 조절해야 합니다.

JVM Option

위에 기본 값을 기준으로 흔하게 일어나는 상황에 대한 조치 방법은 아래와 같습니다.

Hot Deploy 사용으로 재배포가 자주 일어나는 시스템 환경인 경우

1. PermGen 영역의 사이즈를 충분히 늘린다(but 한계 존재)

2. UseConcMarkSweepGC, CMSPermGenSweepingEnabled, CMSClassUnloadingEnabled 등의 옵션으로 PermGen 영역도 GC 수행

OOME, PermGen OOME(Out of Memory Exception) 발생

1. OOME: Xms, Xmx 조정

2. PermGen OOME: XX:PermSize, XX:MaxPermSize 조정

Xmx, Xmx를 동일하게 세팅하는 이유

1. Xms로 init메모리를 잡고, committed 도달할때까지 Used용량이 점차 증가하는데, committed에 도달시 메모리를 추가할 당시 시스템 부하 발생(WAS가 몇 ms가량 멈출 가능성 있음)

2. 메모리 용량은 init < used < committed < max

보통 운영시스템에서 Xms와 Xmx를 동일하게 지정하는 이유는 init와 max사이에서 used 메모리가 committed까지 사용하게 되면, 신규 메모리 공간을 요구하는데 이때 약 1초가량 jvm이 메모리 할당을 멈추는 경우가 생깁니다. 그래서 Xms와 Xmx를 동일하게 주고 메모리를 확보한 상태에서 jvm을 기동시키고는 합니다.

ASH Viewer 다운로드

https://sourceforge.net/projects/ashv/

Undo segment를 과도하게 사용하여

예를 들어, 개발한 배치, 개발자의 임의 작업 등이 잘못 진행되고 있다가 뒤늦게 발견하여 cancel했을 경우라던가 할 때

이를 rollback을 하는 중이지만 UNDO tablespace의 unexpire 영역이 반환되지 않아,

정규 배치 등의 서비스가 실패할 가능성이 있는 시나리오에 대응하려면

다음 쿼리들을 통해 문제를 해결하도록 한다.

Rollback 진행 중인 undo segment를 조회하는 쿼리

parallel rollback 일 경우

select * from v$fast_start_transactions where state='RECOVERING';

serial rollback 일 경우 (x$KTUXE(Kernel Transaction Undo Transaction Entry))

select ktuxesiz from sys.xm$ktuxe where ktuxesta = 'ACTIVE' and KTUXECFL = 'DEAD' ;

Undo tablespace의 사용량은 다음과 같이 확인한다.

col msg format a80
WITH TB AS (
SELECT TABLESPACE_NAME
,(SELECT ROUND(SUM(BLOCKS)*8/1024) FROM DBA_DATA_FILES WHERE TABLESPACE_NAME=A.TABLESPACE_NAME) TOT_MB
,SUM(DECODE(A.STATUS,'ACTIVE' ,SIZE_MB,0)) ACTIVE_MB
,SUM(DECODE(A.STATUS,'UNEXPIRED',SIZE_MB,0)) UNEXPI_MB
,SUM(DECODE(A.STATUS,'EXPIRED' ,SIZE_MB,0)) EXPIRE_MB
FROM (
SELECT TABLESPACE_NAME, STATUS, ROUND(SUM(BYTES)/1024/1024) SIZE_MB
FROM DBA_UNDO_EXTENTS
--WHERE tablespace_name in ( select value from v$parameter where name='undo_tablespace')
GROUP BY TABLESPACE_NAME, STATUS
) A
GROUP BY TABLESPACE_NAME
)
SELECT to_char(sysdate,'HH24:MI:SS')||' '||TABLESPACE_NAME||' : '||round((active_mb+unexpi_mb+expire_mb)/tot_mb*100)||
' % -> Act('||active_mb||') Unexp('||unexpi_mb||') Exp('||expire_mb||') TOT('||TOT_MB||')' MSG,
round(100*(ACTIVE_MB)/TOT_MB,2),
round(100*(ACTIVE_MB+UNEXPI_MB)/TOT_MB,2)
FROM TB;

현재 진행되고 있는 rollback의 잔여시간은 다음 쿼리로 대충 추산할 수 있다.

set serveroutput on
declare
l_start number ;
l_end number ;
r_min number ;
begin
select ktuxesiz into l_start from sys.xm$ktuxe where ktuxesta = 'ACTIVE' and KTUXECFL = 'DEAD' ;
dbms_lock.sleep(60);
select ktuxesiz into l_end from sys.xm$ktuxe where ktuxesta = 'ACTIVE' and KTUXECFL = 'DEAD' ;
r_min := round(l_end / (l_start - l_end) ) ;
dbms_output.put_line('['||to_char(sysdate,'HH24:MI:SS')||'] Remain Time : '|| r_min ||'분 '|| round(r_min/60,2)||'시간 / '||(l_start-l_end)||' blocks done / '|| l_end ||' Total blocks remains' );
end ;
/

운영DB에 임시 UNDO Tablespace를 생성한 후, 향후의 트랜잭션들은 이 UNDO tbs를 사용하도록 조치한다.

create undo tablespace undotbs2 datafile '/dev/rdsk/vsp1_000_ra000/dat_000_20G_001';

alter tablespace undotbs2 add datafile '/dev/rdsk/vsp1_000_ra000/dat_000_20G_002';

...

alter tablespace undotbs2 add datafile '/dev/rdsk/vsp1_000_ra000/dat_000_20G_NNN';

alter system set undo_tablespace=undotbs2 ;

이때 UNDO tablespace를 변경하는 것 자체는 금방 수행되므로 긴장하지 않아도 된다.

다만, alert log에 'active transactions found in undo tablespace NN - moved to pending switch-out state 라는 로그가 트랜잭션 당 1 라인씩 계속 발생할 수 있는데, 어떤 사이트의 경우에는 이 메시지가 다량 발생하기도 하였다고 하므로, alert log가 존재하는 path의 가용량을 모니터링하면서 작업 수행하자.

이러한 세션들은 세션에서 commit을 찍고 알아서 종료되길 기다리거나, 아니면 kill하여 처리하면 된다.

UNDO tablespace를 switch 한 후, 이전의 UNDO tbs를 사용하는 채로 commit 되지 않고 남아있는 세션을 찾아본다

select a.usn, a.name, b.status, c.tablespace_name, d.addr, e.sid, e.serial#, e.username, e.program, e.machine, e.osuser
from v$rollname a, v$rollstat b, dba_rollback_segs c, v$transaction d, v$session e
where a.usn=b.usn
and a.name = c.segment_name
and a.usn = d.xidusn
and d.addr = e.taddr
and b.status = 'PENDING OFFLINE';

rollback이 종료되고 상황이 정상화 되면,

기존 UNDO tablespace를 사용하도록 파라미터를 재설정해주고,

추가했었던 UNDO tablespace를 drop하면 된다.

Clusters 개념

클러스터란, 대칭형 다중 처리 방식(symmetric multiprocessing 또는 SMP)의 대안으로,

상호 연결된 하나 이상의 컴퓨터가 그룹을 이루어 작업을 함께 처리하는 방식입니다.

시스템을 이용하는 사용자 입장에서는 하나의 시스템을 사용하는 것과 같은 효과를 나타냅니다.

즉 최종 사용자 입장에서는 사용중인 시스템이 물리적으로 한대의 노드로 구성되어 있는지,

또는 여러 대의 노드가 클러스터를 구성하여 서비스를 제공하는지 고려하지 않아도 되는 것입니다

Cluster 의 Components

클러스터는 두개의 주요 요소로 구성됩니다.

클러스터 노드는 작업을 처리하는데 필요한 자원을 제공해 주는 시스템입니다.

즉, application이 작업할 수 있는 하드웨어를 말합니다.

이 하나 이상의 노드를 논리적으로 하나의 시스템으로 묶어주는 software가 필요하게 됩니다.

클러스터 매니저가 이 역할을 해 주는 시스템 소프트웨어입니다.

일반적으로, 클러스터를 구성하는 노드 관리, 클러스터 내 노드 추가, 삭제 , 자원 모니터링, Failover 처리 기능을 갖습니다.

Cluster내에서 작동하는 software는 cluster system에서 작동할 수 있도록 설계되어야 합니다.

즉, stand alone node에서 작동하도록 설계된 application은 cluster system에서 작동하지는 않습니다.

The Oracle Cluster

OCR과 Voting disk도 또한 oracle cluster의 콤포넌트입니다.

스토리지에서 제일 하단의ocr, voting disk부터 controlfile, database files 의 순서로

oracle은 file을 check하면서 read하기 시작합니다.

이 때 storage는 cluster 내의 모든 node에서 동시에 access가 가능해야 합니다.

여기서 CRS가 전체 node에 걸쳐 작동하고 있는 것을 알 수 있습니다.

ASM으로 구성된 경우라면 ASM instance가 필요하게 되고,

이 모든 Layer들이 정상적으로start 된 이후 oracle database instance가 작동하게 됩니다.

Public network 망에서 interface 는 일반 public IP 를 사용하지 않고, VIP를 사용하게 됩니다.

이것은 IP failover를 위해 ORACLE CRS가 제공하는 것 입니다.

랜카드 여러개를

랜카드 2개를 묶어서 쓰는 걸 Bonding 이라고 한다.

Architecture

오라클 클러스터 아키텍처를 이해하는데 필요한 중요한 개념들이 있습니다.

서비스, Node Application, Cluster Ready Services, Cluster Resources 등 입니다.

먼저 Service는 클러스터 내 작업을 배분해 주는 수단을 제공해줍니다.

서비스는 하나 또는 그 이상의 인스턴스에서 제공되는데, 데이터베이스 명이 기본적으로 하나의 서비스입니다.

Oracle 10g 이전 버전에서도 이 Service라는 개념이 있었지만,

10g 에서는 더 확대된 개념으로 하나의 instance에서 여러 Service를 제공할 수 있고,

하나의 서비스가 여러 instance에 걸쳐 제공될 수도 있습니다.

Node Application은 Oracle Listener, Global Services Daemon (GSD),

Oracle Enterprise Manager Agent (OEM Agent), Virtual IP Address (VIP) 등이 포함됩니다.

Cluster Ready Service는 logical하게 node를 묶어주는 Cluster Manager이고,

Cluster Resource는 Oracle Cluster Service에 의해 관리되는 Resource들이며 데이터베이스 인스턴스,

서비스, Listener 및 VIP 등이 포함됩니다.

Resource의 속성은 failover 특성 및, 재구동방식, 의존관계 등을 지정하기 위해 정의할 수 있습니다.

IP 용어들 잘 알아 두어야 합니다.

실제 서비스는 vip

public 은 매니지먼트

RAC 를 직접 건드릴 일은 거의 없습니다. 정말 중요한 곳 아니면 RAC 를 쓰지 않아요.

신규는 11g, 기본은 raw device 인데 asm 을 요구하기도 한다.

asm 설치는 asm bug로 인한 책임을 묻지 않겠다는 도장을 받고 설치하여야 합니다.

Cluster Applications Architecture

이 그림은 앞에서 설명한 몇가지 용어를 그림으로 표시한 것입니다.

3개의 node를 사용하고 있고, 각 node들은 기본적으로 Cluster Ready Services에 의해 하나의 system 으로 clustering 되어 있습니다.

각 Node application 들이 각각의 node 에서 작동하고 있고, Database 를 위한 Instance가 각 node에 올라와 있습니다.

Service 를보면, 이 Database 는 AP, HR, CRM 3개의 Service 가 있습니다.

회색으로 표시된 것은 failover 시 작동할 Service 입니다.

CRM 을 예를 들면 평시에는 Node1 에서 Service 를 제공하고,

만약 Node1 에 이상이 있을 경우 Node2 에서 CRM service 를 제공하게 됩니다.

이 후 Fail 된 Node 가 복구되면 다시 Service 는 ‘preferred’ Node로 돌아올 수 있습니다.

단, 이 경우는 user가 manual 하게 옮겨주어야 합니다.

앞의 그림은Service의 관점에서 그린 그림이고,

이 그림은 CRS와 Oracle Instance, Application의 관계를 보여줍니다.

Oracle Database Instance가 각 node에 하나씩 작동하고 있고, 이 두 개의 Instance가

Service A, B, C 3개의 Service를 제공합니다.

이 그림에서는 두개의 Instance가 모두 작동하고 있지만,

어떤 경우는 다른 하나의 Instance 는 Stand by 용 혹은 Failover 용으로 대기 중일 수도 있습니다.

그렇다고 하더라도 Node Application, 즉, Listener, EM, GSD 등은 여전히 각 node별로 작동하고 있습니다.

Client Application은 기본적으로 VIP를 통하여 접속이 되고, Oracle Listener 도 이 VIP를 listen하게 됩니다.

EM, DBCA, SRVCTL, NETCA 등은 HA적 관점에서 CRS와 통신하게 되며,

새로운 Resource 들을 생성할 때 CRS와 통신하여 OCR에 정보를 기록하게 합니다.

이 OCR과 voting Disk는 OS storage에 위치하게 됩니다.

CRS (Cluster Ready Services)

CRS는 크게 3개의 콤포넌트로 구성이 됩니다.

CSS, EVM, CRS. 이렇게 3개가 존재하며, 마지막의 CRS는 Oracle Cluster를 부를때 사용하는

CRS 와는 구분이 되는 Process 명으로 CRS의 resource를 관리합니다.

CRS Structure

이 그림은 앞의 그림들 좀더 확장한 그림입니다.

CRS는 Unix의 init에 의해 기동되고, windows에서는 service controller에 의해 기동됩니다.

여기서 하얀box내의 사각형들은 모두CRS의 component 들입니다.

Oprocd 는 oracle10g에서 사용하는 io fencing기능을 제공합니다.

Evmd 는cluster 내의 event 발생 시 이 event 를 전파하는 기능을 합니다.

이 그림에 표시되어 있지는 않지만, ‘crs_stat –t’ 명령을 수행하면 gsd(group service daemon) 가 나타나는 것을 보실 수 있습니다.

Gsd 는 10g version 에서는 사용되지 않지만, 9i version 의 srvctl 의 interface 가 gsd 로 되어있기 때문에 10g 에서도 아직 남아 있습니다.

실제로 oracle 9i 때의 gsd 의 역할은 이제 모두 crsd 가 담당하게 되었고, 9i version 을 지원하기 위해 존재하는 것 이외의 의미는 없습니다.

Ocssd 는 heartbeat 을 다른 node 에 보내어 health check를 하는 기능을 담당하며,

상대 node 의 이상 감지 시 cluster reconfiguration 도 css 가 담당합니다.

Crsd 는 cluster resource manager로써 CRS가 사용하는 resource를 start/stop/disable/configure 하는 역할을 합니다.

Process로서 존재하지는 않지만, OCR과 Voting disk도 CRS의 구성 Component 입니다.

OCR 은 cluster 와 cluster 내의 resource 의 정보가 저장되어있으며, Voting Disk 는 각 node 의 status 를 확인하기 위해 사용됩니다.

OPROCD (Processor Monitor Daemon)

Oprocd는processor monitor로써init에 의해 기동됩니다.

앞에서 말한 것처럼 oprocd는 Oralce Cluster 가 제공하는 IO fencing solution 입니다.

Linux 에서는 hangcheck timer 가 이 oprocd 의 기능을 제공하기 때문에 oprocd 는 작동하지 않습니다.

이외의 platform중에서 vendor clusterware가 설치되어 있다면, 마찬가지로 oprocd는 기동 되지 않습니다.

Linux를 제외한 flatform에서 Vendor clusterware가 설치되지 않은 경우만 oprocd가 기동 되어 processor를 monitoring하게 됩니다.

Monitoring하는 방법은 특정시간동안 sleep후 깨어나서 예정된 시간보다 늦게 깨어나게 되면,

system hang으로 간주하여 processor를 reset하고 machine을 reboot하게 됩니다.

EVMD (Event Forwarding Daemon)

EVMD는 Event forwarding Daemon입니다. 이 process도 init에 의해 기동됩니다.

Evmd는 evmlogger를 fork하는데 이 process는 log file에 event를 기록하는 역할을 합니다.

Oralce 10g에서는 oracle instance를 monitoring하는 racgimon이라는 process가 있는데,

이 process로부터 forwarding되는 message를 처리하기위해 evmlogger는 필요에 따라 racgevt라는 process를 생성합니다.

Racgevt는 message를 받을 때 마다 callout directory를 확인하여 필요 시 callout를 실행합니다.

Callout이란 특정 event에 따라 행해져야 하는 특정 action을 정한 script입니다.

Callout directory는 $ORA_CRS_HOME/racg/usrco입니다.

이 directory에 user가 특정 action을 미리 define하여 callout script를 생성할 수도 있습니다.

Evmd는 oracle user로 기동되며 fail발생시 자동적으로 재기동 됩니다.

EVM Architecture

EVM Daemon은 다시 두 개의 component로 구분할 수 있습니다.

하나는 local EVM(LEVM)이고 하나는 cluster EVM(CEVM)입니다.

CEVM은 clusters내의 evm daemon에 대한 cluster membership정보를 유지관리 합니다.

즉, 상태 node의 CEVM의 TCP connection정보를 유지하고, 상대 node의 evm에게 event를 전달하는 역할을 합니다.

LEVM은 clusterwide하게 전달될 event가 생성되면, Cluster event Queue에 event를 넣어서 CEVM이 clusterwide하게 event를 전달하도록 합니다.

CEVM이 다른 node로부터 event를 받는 경우, 마찬가지로 clustger event Queue에 event를 넣어 LEVM으로 전달합니다.

Cluster내의 어느 node가 새로 cluster에 join하는 경우, CEVM은 상대 node의 CEVM으로부터 이 event를 전달받고,

inbound cluster event queue에 이 event를 넣습니다.

그리고 CRSD에게 이 event를 넘겨줘서 CRSD가 node join을 알게 합니다.

LEVM은 queue에 있는 event를 받고 이 내용을 기록합니다.

이와 같이 CSS, CRSD가 발행하는 event들은 EVM을 통하여 clusterwide하게 전파됩니다

CSSD (Cluster Synchronization Service)

CSSD는 cluster synchronization service daemon의 약자입니다.

이 process는 다음 세가지의 service를 제공합니다.

Group service, lock service, node information service입니다.

Node information service는 어떤 node가 cluster에 join했는지 혹은 cluster를 떠났는지 monitoring하는 기능입니다.

Cssd는 process fail시 OS reboot이 됩니다.

CSS의 역할인 그룹서비스는 9i version에서의 skgxn의 역할이 확장된 것입니다.

Oracle database instance가 join하는 것을 처리하고 Cluster내의 이미 존재하는 member들에게

새로운 member가 join되거나 leave되는 것을 알려줍니다.

Lock service는 crsd가 사용하는 lock을 css의 lock service가 제공합니다.

Node Information Services는 node의 정보를 유지 관리하는 service입니다.

여기에는 cluster configuration정보, node명, node number등이 있으며 node추가나 삭제 시 갱신됩니다

다른 crs process들처럼 cssd도 multi thread로 되어있으며, 크게 두 부분으로 나눌 수 있습니다.

Node monitor는 nm이라고 불리우며, Node자체가 살아있는지 여부를 check한는 역할을 합니다.

이 기능은 heartbeat을 이용하게 됩니다.

상대 node의 css endpoint는 ocr에 기록되어있으며, 이 end point로 매초마다 interconnect를 통해 network heartbeat을 보냅니다.

일정 시간동안, 즉 miscount동안 heartbeat을 받지 못하면 css는 해당 node를 죽은 것으로 간주합니다.

이와는 별도로 voing disk을 매초마다 read하게 됩니다.

Network heartbeat이 miscount동안 오지 못하여 일부 node가 죽은 것으로 판단되면,

이 voting disk를 확인하여 어느 node들을 cluster에서 제거해야 하는지 voting을 하게 되는데 이 단계가 reconfiguration입니다.

Nm이 어느 node가 죽었는지 판단하여 nm reconfiguration을 한 이후에, gm이 해당 node의 crs,

evm, css등이 사용했던 resource들을 제거하고 cluster group에서 삭제하는 gm reconfiguration이 진행됩니다.

Reconfiguration은 node join시에도 발생합니다.

CRSD

다음은 crsd에 대해 알아보겠습니다.

CRSD는 cluster내에서 사용하는 resource를 monitoring하고 관리하는 역할을 합니다.

CRSD는 shell script인 racgwrap을 call하게 되고, 이 racgwrap은 racgmain을 call하여 특정

resource를 start/stop/check할 수 있습니다.

이 resource들을 관리하기 위해 해당 resource의 정보를 담아야 하는 공간이 필요하며, 이것이 ocr입니다.

CRSD는 이 OCR내의 정보를 직접 read/write하여 data를 유지 관리하는 역할을 합니다.

Read/write시 disk io를 최소화하기위해 OCR data를 memory에 caching하는 기능도 제공합니다.

CRSD는 root user로 기동하고, process fail이 발생하면 자동적으로 재기동 됩니다.

CRS Resources

Oracle entity는 database, instance, service나 listener등이 있습니다.

이런 oracle entity의 생성은 dbca, netca, srvctl등의 oracle tool들에 의해 생성하도록 요청되고,

CRSD가 실질적으로 OCR을 update하여 생성하게 됩니다.

이런 crs resource들간에는 dependency를 가질 수 있습니다.

예를 들어 database instance나 listener는 vip가 있어야만 생성될 수 있고, start될 수 있습니다.

이 경우 dependency가 성립됩니다.

Oracle crs가 crs resource를 관리하기위해 내부적으로 관리하는 명령어들은 다음과 같습니다.

이 명령어들이 담당하는 역할은 하나의 resource의 lifecycle과 동일합니다.

Crs_profile은 resource의 각종 attribute를 정의합니다.

일단 attribute가 정의되면, crs_register에 의해 resource로서 추가되고, ocr에 쓰여지게 됩니다.

Crs_start는 resource를 start할때 사용됩니다.

Crs_stat는 해당 resource의 정보를 조회할때 사용합니다.

Crs_relocate는 해당 resource를 move할때 사용합니다.

Crs-stop은 resource를 stop하며, crs_unregister를 이용하여 resource를 삭제할 수 있습니다.

Resource를 관리한다는 것은 위의 7가지 상태를 말하며, 이 7개의 단계는 resource의 life cycle이 됩니다.

CRS application resources

일단 resource가 startup 되면 crsd 는 resource 마다 하나씩 thread 를 생성하여 이 resource를

check_interval을 주기로 정상작동 여부를 check하게 됩니다.

Resource가 비정상 종료되면(예를 들어 instance crash) resource의 state는 offline으로 변경되고,

restart_attemps에 해당되는 숫자만큼 restart를 자동적으로 시도하게 됩니다. 이 숫자를 넘어서게 되면

더 이상 restart를 시도하지 않습니다.

Crs resource의 현재 상태는 crs_stat을 통하여 알 수 있습니다.

이 명령 결과로 조회되는 state는 current상태를 표시하고, target은 crs가 유지해야 하는 resource의 상태입니다.

즉, target이 대부분 online으로 되어있으므로 crs는 해당 resource의 current state를 online으로 유지하려고 합니다.

CRS Action

Crsd가 resource를 관리하기위해 node간에 message를 주고받는 예를 한번 보겠습니다.

Node는 2개이고, instnace start상황이라고 가정을 하겠습니다.

1. Node1의 client에서 api를 통해‘crs_start oracle’요청이 들어옵니다.

2. local CRSD는 이 요청을 받고, 이를 처리하기위해 새로운 thread를 생성합니다.

요청이 타당한지 검증을 하고, 어느 node에서 이 명령이 수행되어야 하는지 판단합니다.

여기서는 node2에서 작동하는 경우를 예로 들겠습니다.

3. Request=start resource=oracle로 key/value형태로 message를 생성합니다.

4. Node2의 crsd와 통신할 수 있는 port를 확인합니다.

5. Node2의 port가 open되고, socket이 open됩니다. Node2의 crsd는 이 요청을 처리하기 위한 thread를 생성합니다.

6. 3번에서 생성한 message를 node2로 보냅니다.

7. Node2의 crsd는 message를 decode하고, 이 message가 타당한지 여부를 확인하기 위해 ocr을 확인합니다.

특히, timeout value인 script_timeout의 값을 확인합니다.

8. Node2는 script_timeout의 값을 node1에 보내서 응답을 이 시간동안 기다리도록 합니다.

9. Node1은 timer를 시작하여 이 script_timeout동안 응답이 오기를 기다립니다.

10. Node2는 resource를 start합니다.

11. Node2는 node1으로 action program이 수행되었음을 socker을 통해서 보냅니다.

12. Node2에서 socket을 close합니다.

13. Node1에서 resource의 status를 변경함으로써 모든 작업이 완료됩니다.

OCR (Oracle Cluster Registry)

OCR은 oracle cluster registry의 약자입니다. CRS에서 사용하는 data를 저장하는 repository 역할을 합니다.

Data의 구조는 window의 registry처럼 tree구조로 되어있고, keyvalue의 형태로 data가 저장되어있습니다.

이 OCR data는 DBCA, NetCA, SRVCTL등의 oracle tool과 CRS가 사용합니다.

Srvctl에서 resource를 생성하는 예를 보면, srvctl create database –d mydatabase –o myOracleHome 의 형태입니다.

이 명령으로 OCR에는 mydatabase라는 database가 추가됩니다.

그러나 실제로 database가 생성 되는 것은 아닙니다.

Database의 생성은‘create database’문장으로 생성을 해야 합니다.

Dbca를 이용하면 database를 실제로 생성한 후 OCR에 등록하는 역할까지 합니다.

OCR은 shared device에 생성되어야 하며, raw device나 cluster file system도 가능합니다.

OCR의 위치는 일반적으로 /var/opt/oracle/srvConfig.loc file에 지정되어있거나, 환경 변수인 SRV_CONFIG로 지정이 가능합니다.

OCR Cache Architecture

Srvctl등의 oracle tool이 OCR정보를 access해야되는 경우 local node의 crsd가 관리하는 local ocr cache를 읽습니다.

Ocr cache는 각 node의 crs에 의해 관리되지만 그중의 한 crs는 cluster master cache로서 역할을 합니다.

이 master cache만이 OCR disk에 disk io를 발생시키게 되고 read한 data를 다른 node의 ocr cache로 전파합니다.

Resouce start/add등 OCR disk에 write해야 되는 상황에도 master cache를 담당하는 crsd가 write를 하고,

이 사실을 다른 node의 crsd에 전파합니다.

OCR write가 발생하면, 기존에 cache되어있던 해당 data는 invalid상태로 변경되어 master ocr cache로부터 다시 전달 받아야 합니다.

OCR Record 구조

각 ocr record는 key, value, permission의 3개의 field를 갖습니다.

여기 예에서 보면, 제일 위의 Databases.reld.instance.reld1은 key입니다.

여기서는 database instance를 예를 들었습니다.

그 밑에 oratext항목에 나타나는 reld1은 key에 대한 value입니다.

여기서는 instance명인 reld1이 value입니다.

세번째 항목은 security입니다.

Unix에서 permission을 관리하는 방식처럼 user, group, other group의 세 부분으로 나뉘고,

username과 primary_group_name에 이 user의 user명과 그룹 명이 표시됩니다.

여기 예에서는 oraha user에 other group으로 표시되었지만, 일반적인 경우에 oracle user에 dba group이 표시됩니다.

Voting disk

Voting disk는 split brain상태에서 node의 상태를 판단하기위한 second heart beat의 역할을 합니다.

Nm은 이 상태에서 어느 sub cluster node를 evict할지 결정하기 위해 voting disk를 사용합니다.

Eviction이 결정되면 해당 node가 eviction되도록 eviction message를 voting disk에 적어줍니다.

Voting disk는 dd로 backup을 받아 disk failure시 복구할 수 있습니다.

10gR1에서는 multiple voting disk를 지원하지 않으므로 os level의 mirroring 기능을 이용해야 하지만,

10gR2에서 multiple voting disk기능을 지원합니다.

참고로 OCR backup은 $ORA_CRS_HOME/cdata// direcotry에 자동적으로 backup이 됩니다.

Backup은 매 4시간마다 1개, 매일 1개, 매주 1개의 갯수로 유지됩니다.

Oraconfig –showbackup 명령으로 가용한 backup을 알수 있으며,

oraconfig–restore filename 명령으로 restore할 수 있습니다. Restore시는 crs를 down후 restore해야 합니다.

자세한 절차는 metalink에서 note. 268937.1를 확인하시기바랍니다.

Installation

CRS는 $ORACLE_HOME과는 별도의 경로에 $ORA_CRS_HOME이라는 환경 변수를 설정 후, 이 directory에 install합니다.

Install과정의 마지막 부분에 root.sh shell을 실행하도록 message가 나타납니다.

이 root.sh는 inittab file에 crs process들이 booting시 startup되도록 inittab에 관련 정보를 기록합니다.

이 inittab들 보면 crs는 root권한으로 evm은 oracle권한으로 기동되며, process fail시 자동으로 재기동됩니다.

Css는 oracle권한으로 기동되며, fatal mode로 기동되므로 process fail시 os reboot이 됩니다.

Booting시 실행되는 script는 init.crsd, init.cssd, init.evmd 이 세개가 실행되어 crs가 기동되게 됩니다.

이 process들은 $ORA_CRS_HOME//log directory에 각각의 log를 관리합니다.

따라서 각 process에 이상 발생시 우선적으로 이 log directory를 참조 하시기 바랍니다.

Install시 root.sh가 모든 node에서 실행되어야 합니다. 만약 정상적으로 실행되지 않은 경우라면, 문제발생시 원인을 찾기 힘들게 됩니다.

Starting CRS

CRS 가 start 되는 과정을 다시 한번 review 해보겠습니다.

Init.crsd, init.evmd, init.cssd 는 init.crs 에 의해 call 이 되어, manual 하게 start 될 수 있습니다.

‘Init.crs start’ 명령이 발생하면, 먼저 cssd 를 start 하여 cluster 를 형성하게 되고, 이후 evm 이 start 됩니다.

마지막으로 crsd 가 start 되어 crs 가 모두 기동됩니다.

Css 의 주요 thread 는 voting disk polling thread 와 network heartbeat thread입니다.

Disk polling thread 는 매 초마다 voting disk 를 read 합니다.

Heartbeat thread 도 또한 매초마다 작업합니다.

Css 는 이외에 timer thread, 기타 관리를 위한 thread 등이 있습니다.

Css 는 startup 하면서 OCR 과 voting disk 를 읽어 cluster node 들을 확인합니다.

이 단계에서 OCR이나 Voting disk 를 read 할 수 없는 상황이 되면 start 되지 못합니다.

이후 evm 이 start 됩니다.

CRSD 가 start 되면서 OCR data 를 cache 하기 위해 OCR cache thread 를 기동합니다.

OCR cache 는 node 간에 master-slave 관계를 갖게 되는데, 가장 먼저 booting 된 node 가 master 가 되고,

OCR disk 에 대한 write 는 이 master 에 의해서만 이루어집니다.

이후 변경된 data 의 전파도 이 master crs 가 하게 됩니다.

Crsd 는 ocr 을 읽어서 모든 resource 들을 파악하고, 이들간의 dependency 도 확인합니다.

이후 racgwrap 을 call 하여 각각의 resource 들을 start합니다.

Racgwrap 은 racgmail 을 call 하면서 argument 로써 resource name 과 start 를 넘겨줍니다.

각각의 resource 의 health check 를 하기 위해 매 초마다 sga의 특정 영역을 polling 합니다.

이 단계를 마치게 되면 모든 crs daemon들과 nodeapps, database, instance등의 resource가 모든 node에서 기동된 상태가 됩니다.

Diagnostics

다음은 문제 초기단계에서 볼 수 있는 trace file들을 확인해보겠습니다.

Crs, css, evm은 Oracle 10g R1 의 경우는 $ORA_CRS_HOME directory 밑에 process 명 아래에 log directory에 해당 log가 있습니다.

우선적으로 봐야 할 log file 은 이 log file 들입니다.

Css 의 경우는 interconnect 의 networking 이 안 되는 경우도 있으므로, css 의 network trace file인

$ORA_CRS_HOME/css/log/ocsns*.log 가 필요할 수도 있습니다.

그리고 network configuration 을 파악하기 위해 hosts, netstat 결과도 확인이 필요합니다.

Emvd의 log는 각각 다음과 같습니다.

EVM daemon log 는 $ORA_CRS_HOME/evm/init/.log

EVM event logger log 는 $ORA_CRS_HOME/evm/log/_evmdaemon.log

Oprocd 가 있는 경우는 $ORA_CRS_HOME/log에oprocd log file 이 있습니다.

Ocr의 이상 시는 먼저 ocr 의 위치를 지정하고 있는 ocr.loc file을 확인하세요.

이 file은 linux 의 경우는 /etc/oracle, 기타 unix 는 /var/opt/oracle 에 위치합니다.

Ocr 내부의 data를 확인하기 위해 ocrdump 명령을 사용할 수 있습니다.

별도의 이름을 주지 않은 경우 OCRDUMP 라는 file명으로 생성됩니다.

공통적으로 OS system log를 확인하여, network error나 io error, 혹은 다른 message가 있는지 확인이 필요합니다.

CRS의 경우도 여러 형태의 문제가 발생할 수 있기 때문에 문제 유형별로 trace를 발생시킬 수 있습니다.

이 내용에 대해서는 iSeminar에서 언급하지는 않겠습니다.

위의 기본적인log file들과 함께 Oracle Suppport Engineer와 함께 진행하시기 바랍니다.

 OCR

1. oracle clusterware 가 control 하는 컴포넌트에 대한 저장/관리 (RAC DB , Service , listener, VIP )

2. 설정 정보를 key-value 쌍으로 tree 구조로 관리한다.

3. crs 데몬이 죽은거 살릴떄 ocr 정보를 이용

 Voting Disk

1. 어느 node 가 cluster의 멤버인지를 determine , cluster 의 무결성 보장

2. CSS 데몬이 노드간에 동기화 작업을 하는데 voting disk 정보를 이용하고 node 제거 시

    interconnect 차후로 voting disk 에 알린다.

3. 메인 목적은 interconnect fail 시를 대비하기 위함

4. 어느 노드가 죽었는지에 대한 정보를 결정

5. Voting Disk가 없으면 네트웍이 문젠지 노드가 죽었는지 알 수 가 없다.

ASM 기반의 OCR , VOTING DISK 관리

Each node must be able to access a majority of vote disks otherwise it will be evicted from the cluster.

Voting disk can be stored on an ASM disk.

    not regular ASM files.

     Clusterware knows location in case ASM is unavailable.

The number of voting disks is determined by ASM disk group redundancy.

       1 for external redundancy disk group

       3 for normal redundancy disk group

       5 for high redundancy disk group

A separate failure group is required for each voting disk.

Voting disks are managed using crsctl utility.

ASM managed voting disks are automatically backed up into the OCR.

        Any configuration change in the cluster triggers a new backup of the voting disks.

        A failed voting disks is restored by ASM automatically.

The OCR is backed up automatically every 4 hours.

      Manual backups can also be taken as required.

      OCR should be protected by disk group redundancy or mirroring in the disk storage system.

ONLY IF all voting disks are corrupted or filed, AND the OCR is also corrupted or unavaliable,

THEN manual intervention is required.

Voting disk 는 홀수로 구성 한다. 50% 이상이 유실되면 오라클은 데이터 보호를 위해 모두 shutdown 된다.

하지만 ASM 내에 voting disk를 꺠기란 쉽지 않다.

1. ASM 관리하기

WIEW 이름                        설 명

v$ASM_DISKGROUP             디스크 그룹에 관련된 정보

v$ASM_DISK                       디스크에 대한 정보

v$ASM_FILE                        ASM내부에 생성 된 파일에 대한 정보

v$ASM_TEMPLATE                ASM내 모든 디스크 그룹에 설정된 템플릿 정보

v$ASM_ALIAS                      ASM디스크 그룹의 alias정보

v$ASM_OPERATION              ASM Instance 상에서 실행되는 작업들 현황

v$ASM_CLIENT                     ASM을 사용하는 DB Instance 현황

1) ASM disk 내용 확인

SYS/+ASM> set line 200
SYS/+ASM> col disk_group for a10
SYS/+ASM> col label for a10
SYS/+ASM> col state for a10
SYS/+ASM> select a.name as disk_group, d.name "Label", a.state
2 from v$asm_disk d, v$asm_diskgroup a
3 where d.group_number=a.group_number
4 order by 2;

DISK_GROUP Label STATE
---------- ---------- ----------
DATA ASM1 MOUNTED
FRA FRA1 MOUNTED

2) ASM 내부 살펴보기

2.1 ASM인스턴스에 현재 연결되어 있는 Disk group확인

SYS/+ASM> set line 200
SYS/+ASM> col group_number for 99
SYS/+ASM> col name for a10
SYS/+ASM> col type for a10
SYS/+ASM> col state for a10
SYS/+ASM> select group_number, name, type, state from v$asm_diskgroup;

GROUP_NUMBER NAME TYPE STATE
------------ ---------- ---------- ----------
1 DATA EXTERN MOUNTED
2 FRA EXTERN MOUNTED

2.2 디스크 그룹별 세부 상세 정보 보기

SYS/+ASM> col group_number for 999
SYS/+ASM> col disk_number for 999
SYS/+ASM> col name for a10
SYS/+ASM> col mount_status for a10
SYS/+ASM> col path for a15
SYS/+ASM> select group_number, disk_number, name, mount_status, path, total_mb
2 from v$asm_disk;

GROUP_NUMBER DISK_NUMBER NAME MOUNT_STAT PATH TOTAL_MB
------------ ----------- ---------- ---------- --------------- ----------
1 0 ASM1 CACHED ORCL:ASM1 7680
2 0 FRA1 CACHED ORCL:FRA1 2460

2.3 디스크 그룹별 파일 내역

SYS/+ASM> set line 200
SYS/+ASM> set pagesize 50
SYS/+ASM> col group_number for 99
SYS/+ASM> col file_name for 999
SYS/+ASM> col type for a15
SYS/+ASM> select group_number, file_number, round((bytes/1024/1024),1) MB, redundancy, type
2 from v$asm_file;

GROUP_NUMBER FILE_NUMBER MB REDUNDANCY TYPE
------------ ----------- ---------- ------------ ---------------
1 256 6.7 UNPROT CONTROLFILE
1 257 50 UNPROT ONLINELOG
1 258 50 UNPROT ONLINELOG
1 259 50 UNPROT ONLINELOG
1 260 300 UNPROT DATAFILE
1 261 200 UNPROT DATAFILE
1 262 120 UNPROT DATAFILE
1 263 20 UNPROT TEMPFILE
1 264 5 UNPROT DATAFILE
2 256 6.7 UNPROT CONTROLFILE
2 257 50 UNPROT ONLINELOG
2 258 50 UNPROT ONLINELOG
2 259 50 UNPROT ONLINELOG
2 260 0 UNPROT PARAMETERFILE

14 rows selected.

※ redundancy의 의미 - 만약의 경우를 위해 미러링하는 정도를 의미.

ASM 인스턴스 생성시 디스크 그룹을 선택할 때 생성하는 것으로 3가지 타입 중 하나를 선택할 수 있음.

Disk Group Type              Supported Mirroring Levels            Default Mirroring Level

Normal redundancy          2-way 3-way Unprotected(none)      2-way

High redundancy              3-way                                        3-way

External redundancy          Unprotected(none)                       Unprotected

1. OCR file이란?

- Oracle Cluster Repository약자로 cluster의 정보를 담고 있고 윈도우로 말하면 레지스트리의 역할을 하며 RAC상의 모든 노드들에 대한 정보와 모든 자원들에 대한 정보가 저장 되어 있습니다. OCR이 장애가 발생하면 RAC전체가 중단되므로 관리 철저를 요망!!!!

2. 특징

- OCR 디스크의 소유자는 기본적으로 root이지만 경우에 따라서 oracle사용자가 될수 있음

- 자동 백업(4시간 마다, 매일마다, 매주마다)

3. 상태 확인 방법

$ORACLE_CRS_HOME/bin/ocecheck 명령어 사용

4. 자동 백업 경로와 내역확인

$ ocrconfig -showbackup

5. OCR file복원하기(자동백업, 수동백업파일)

1) 자동 백업

step 1. 현재 노드의 오라클 클러스터웨어를 stop

# crsctl stop crs

step 2. 백업 리스트 확인 후 파일 복원

# ocrconfig -showbackup

파일 복원

# ocrconfig -resotre <파일 이름>

복원 확인

# cluvfy comp ocr -n all

현재 노드의 오라클 클러스터 다시 시작

# crsctl start crs

2) 수동 백업

step 1. 전체 노드의 오라클 클러스터웨어 stop

# crsctl stop crs

step 2. 수동으로 OCR file 해당 경로에 백업

# ocrconfig -export

step 3. 전체 노드의 오라클 클러스터웨어 start

# crsctl start crs

3) OCR file 리커버리

step 1. 전체 노드의 오라클 클러스터웨어 stop

# crsctl stop crs

step 2. 해당 백업 경로에서 복구 수행

# ocrconfig -import

step 3. 복원 확인

# cluvfy comp ocr -n all

step 4. 전체 노드의 오라클 클러스터웨어 start

# crsctl start crs

OCR - Oracle Cluster Repository

RAC구성의 전체 정보를 저장하고 있는 디스크

RAC에서의 핵심역할을 한다.

OCR에 저장되어있는 정보를 보고 RAC를 구성한다.

10g까지는 RAC 시작후 ASM instance를 시작하기 때문에 OCR을ASM에 저장할 경우 RAC를 시작할 수 없게 된다. 따라서 OCR, Vote disk는 ASM storage 에 저장하지 않고 raw device 에 저장한다.

Oracle이 권장하는 OCR의 최소 크기는 100MB이다.

Vote disk

각 노드들의 장애 여부를 구분하기 위해서 사용하는 일종의 출석부 이다.
RAC는 여러개의 인스턴스 노드들로 구성되어 있으면 각 노드들이 문제가 있는지 없는지를 실시간으로 파악하고 있어야 한다.

RAC를 구성하는 프로세스 중에서 cssd 라는 프로세스가 각 노드 들이 정상적으로 작동하고 있는지 매 초 마다 interconnet를 통해 매 초마다 heartbit를 보내고 각 노드는 그에 대한 응답을 보낸다.
각 노드들은 cssd가 보내는 heartbit에 대하여 자신이 정상작동하고 있음을 vote disk에 기록해두고 있다.

1차 cssd 는 Heartbit를 보내고 노드의 응답을 기다린다. 응답이 없을 경우

2차 cssd는 votedisk에 가서 확인해본다.

노드의 표시가 없다면 노드에 장애가 생겼다고 판단하고 해당 노드를 cluster에서 제외하고 재부팅하게된다.

Oracle이 권장하는 vote disk의 최소크기는 20MB이고, vote disk를 3개로 다중화하기를 권장한다.

참고로 11g RAC 부터는 OCR 과 Vote disk 를 모두 ASM Storage 에 저장 할 수 있습니다.
그리고 11g 부터는 Clusterware 가 Grid Infrastructure 라는 프로그램에 통합이 되어서 Grid 프로그램을 설치하면 자동으로 설치가 됩니다.

1. OCR

1-1 OCR 이란?

• OCR은 RAC를 구성하는 정보를 저장하는 저장소라는 것이 있습니다. 이러한 OCR정보는 RAC 환경에서 매우 중요한 관리 항목으로 주기적인 백업을 받아 두어야 합니다. 기본적으로 OCR 백업은 4시간 마다 자동으로 백업이 이루어 지며, 비상 상황을 대비하여 3벌의 백업을 자동으로 유지 관리 합니다.
• OCR file은 root 소유로 되며 Oracle Cluster Repository의 약자로 말그대로 Cluster의 정보를 담고 있습니다.
  
  

1-2 OCR 수동 백업/복구 절차

• ocrconfig -backuploc // 백업 시작
• ocrconfig -showbackup // 백업 현황 조회
• ocrconfig -restore // 복구(모든 NODE 중지 후 한 NODE씩 작업 진행)
• ocrconfig -export // export
• ocrconfig -import // import

1-3 CLUSTER를 중단시키고 OCR 정보를 Import 하는 방법

• CLUSTER상의 모든 Node를 Shutdown 한 후 Node 한대만을 single-usermode로 올립니다.
• ocrconfig -import 명령을 사용하여 import를 수행 합니다.
• CLUSTER상의 모든 Node를 Multi-usermode로 구동시킵니다.

1-4 CLUSTER를 중단시키지 않고 OCR 정보를 Import 하는 방법

• 모든 Node의 initab 파일을 다른 이름으로 COPY 해놓은 후 모든 NODE 상의 initab entries를 Update 하고 CRS 관련 entry를 제거합니다.
• 모든 Node에서 /etc/init.d/init.crsstop 명령을 사용하여 CRS를 중지 시킵니다.
• CLUSTER상의 한 Node에서 ocrconfig -import 명령을 사용하여 OCR export를 수행합니다.
• 모든 Node에서 originalinitab file을 복원 합니다.
• 모든 Node에서 /etc/init.d/init.crsstart명령으로 CRS START
• /etc/initq 명령을 실행 합니다.

2. Voting

2-1 Votiong 이란?

• Oracle 소유로(오라클 설치시 UID) 되며 장애시 어떤 Node를 제거할지 검사하는 용도로 사용 합니다.
  
  

2-2 Votiong 현재 상태 확인

• crsctl query css votedisk

3. 질문사항

3-1 ocr, voting 어떻게 확인 하나요?

• ocrcheck
• crsctl query css votedisk
• ocrdump -stdout
• http://cafe.naver.com/prodba/14143

3-2 ocr, voting 초기화 어떻게 하나요?

• http://cafe.naver.com/prodba/18101

3-3 ocr, voting 다른 스토리지로 이관은 어떻게 하나요?

• http://cafe.naver.com/prodba/7492

OCR과 Voting Disk는 Oracle Cluster component들 입니다. 스토리지에서 OCR, Voting Disk부터 controlfile, datafile등의 순서로 Oracle은 파일들을 체크하면서 읽기 시작 합니다. OCR은 cluster와 cluster 내의 resource의 정보를 담고 있고 Voting Disk는 각 노드의 status를 확인하기 위해 사용 합니다

출처: https://estenpark.tistory.com/305 [DATA 전문가로 가는 길]