Gc cr/current block 2-way

EXEM Knowledge Base

Jump to: navigation, 찾기

목차

[편집] Basic Info

gc cr/current block 2-way 이벤트는 gc cr/current request 이벤트에 대한 Fixed-up 이벤트로, 블록을 요청한 프로세스가 마스터 노드로부터 직접 블록 이미지를 전송 받았다는 것을 의미한다. gc cr/current request 이벤트가 gc cr/current block 2-way 이벤트로 바뀌는(fixed up되는) 흐름은 다음과 같다.

요청 노드의 유저 프로세스가 특정 데이터 블록을 CR 모드 또는 Current 모드로 읽고자 한다.
유저 프로세스는 해당 데이터 블록의 적절한 버전이 로컬 버퍼 캐시에 없는 것을 확인하고, 마스터 노드의 LMS 프로세스에 블록 전송을 요청한다. 유저 프로세스는 응답을 받을 때까지 gc cr request 이벤트나 gc current request 이벤트를 대기한다.
마스터 노드의 LMS 프로세스는 자신의 로컬 버퍼 캐시에 요청 받은 블록 이미지가 존재하는 것을 확인하고, 인터커넥트를 통해 해당 블록 이미지를 전송한다. CR 블록을 전송하는 경우에는 gc cr blocks served, gc cr block build time, gc cr block flush time, gc cr block send time 통계 값이 증가한다. Current 블록을 전송하는 경우에는 gc current blocks served, gc current block pin time, gc cr block flush time, gc cr block send time 통계 값이 증가한다.
유저 프로세스는 블록 이미지를 전송 받고, gc cr/current request 이벤트를 Fixed-up 이벤트인 gc cr block 2-way 이벤트나 gc current block 2-way 이벤트로 변경한다. CR 블록을 전송 받은 경우에는 gc cr blocks received, gc cr block receive time 통계 값이 증가한다. Current 블록을 전송 받은 경우에는 gc current blocks received, gc current block receive time 통계 값이 증가한다.

오라클은 이미 로컬 캐시에 읽을 수 있는 버전의 블록이 존재하면, 즉 현재 SQL 문장이 요구하는 SCN을 만족하는 블록이 로컬 캐시에 존재한다면 추가적인 글로벌 캐시 동기화 작업을 수행하지 않고, 로컬 캐시에 있는 블록 이미지를 사용한다. 따라서 SQL 문장 튜닝과 효율적인 버퍼 캐시 사용을 통해, 일단 로컬 캐시로 읽어 들인 블록들을 최대한 재활용하는 것이 RAC를 위한 최고의 튜닝 방법이 된다. 로컬 캐시에 읽을 수 있는 버전이 존재하는 경우, 글로벌 캐시 동기화를 수행하지 않는 정확한 조건을 이해할 필요가 있다. RAC 시스템에서 “CR 모드로 읽을 수 있는 버전의 블록”의 정확한 의미는 “공유 모드(Shared Mode)로 BL 락을 획득한 블록”을 말한다. 즉, 로컬 버퍼 캐시에 BL 락을 공유 모드로 획득한 블록이 존재하는 경우에는 글로벌 캐시 동기화 작업 없이 로컬 버퍼 캐시에서 바로 블록을 읽어 들인다. 요청 노드의 유저 프로세스가 CR 모드의 블록 전송을 요청한 후에 데이터 블록에 대해 공유 모드로 BL 락을 획득하는 경우는 다음과 같다.

전체 클러스터에서 최초로 블록을 읽어 들이는 경우. 이 경우 gc cr grant 2/3-way 이벤트가 Fixed-up 이벤트로 사용된다.
홀더 노드가 공유 모드(Shared Mode)로 읽어 들인 블록을 전송 받는 경우. 이 경우 gc cr block 2-way/3-way 이벤트가 Fixed-up 이벤트로 사용된다. 하나의 블록에 대해 여러 노드가 동시에 공유 모드로 BL 락을 획득하게 된다.
홀더 노드가 독점 모드(Exclusive Mode)로 읽어 들인 블록을 전송 받되, 이 블록이 _FAIRNESS_THRESHOLD 파라미터 값(기본값은 4)을 초과하여 전송된 경우. 이 경우에는 gc current block 2-way/3-way 이벤트가 Fixed-up 이벤트로 사용된다. 특정 블록을 독점 모드로 보유하고 있는 홀더 노드는, 해당 블록에 대해 CR 모드의 전송이 요청된 경우, 가능한 자신이 현재 보유한 독점 모드의 락을 유지한다. 락 다운그레이드가 지나치게 자주 발생하는 것을 방지하기 위해서이다. 이 경우 요청 노드는 공유 모드가 아닌 널 모드(Null Mode)로 BL 락을 획득한다. 하지만, 요청 노드가 계속해서 락 다운그레이드 요청을 하는 경우에는, 즉 CR 모드 요청을 하는 경우에는, 독점 모드의 락을 공유 모드(Shared Mode)로 다운그레이드하고, 다른 노드가 BL 락을 공유 모드로 획득하는 것을 허용한다. 이것을 제어하는 파라미터가 _FAIRNESS_THRESHOLD 파라미터로, 말 그대로 “노드간에 공평성을 제어하는” 역할을 한다.

_FAIRNESS_THRESHOLD 임계치를 초과하여 락 다운그레이드가 발생한 경우의 수는 V$CR_BLOCK_SERVER 뷰를 통해 확인할 수 있다.

SQL> SELECT cr_requests, fairness_down_converts FROM V$CR_BLOCK_SERVER;
CR_REQUESTS	FAIRNESS_DOWN_CONVERTS
-----------	----------------------
38726154	      1973959

전체 CR 블록 요청 회수 대비 락 다운그레이드 발생 회수가 약 5% 정도로 양호한 수치를 보인다.

CR 블록 요청에 의한 락 다운그레이드 발생 회수가 지나치게 높은 경우에는(25% 이상), _FAIRNESS_THRESHOLD 파라미터 값을 1이나 2 정도로 낮추는 것을 고려할 필요가 있다. 락 다운그레이드 회수가 높다는 것은, 거꾸로 CR 블록 요청에 대해 추가적인 블록 전송(최대 네 번까지)이 많이 발생한다는 것을 의미하기 때문이다. 이런 경우에는 락 다운그레이드가 빨리 이루어지도록 하면, 그만큼 추가적인 블록 전송이 없어지기 때문에 성능 개선에 도움이 될 수 있다.

간단한 테스트를 통해 _FAIRNESS_THRESHOLD 파라미터에 의해 글로벌 캐시 동기화가 어떻게 이루어지는지 확인해보자. gc cr block 2-way 이벤트가 5번째 요청에서 gc current block 2-way 이벤트로 바뀌고, 6번째 요청부터는 글로벌 캐시 동기화가 발생하지 않는다는 사실에 유의해서 테스트 결과를 분석해보자.

-- 두 개의 노드로 이루어진 RAC 환경이며, 오라클 버전은 10g R1이다.
-- SQL#1: 노드 1, SQL#2 : 노드 2
SQL#2> CREATE TABLE rac_test(id NUMBER);
SQL#2> INSERT INTO rac_test VALUES(1); COMMIT;
-- File#=14, Block#=10307 블록
SQL#2> 
SELECT DBMS_ROWID.ROWID_RELATIVE_FNO(ROWID) AS file#,
	DBMS_ROWID.ROWID_BLOCK_NUMBER(ROWID) AS block#
FROM rac_test;
FILE#            BLOCK#
----------     ----------
      14          10307

-- 노드 2에서 다음 명령을 수행한다. 노드 2가 14번 데이터 파일의 마스터 노드가 된다.
SQL#2> connect /as sysdba
SQL#2> oradebug lkdebug -m pfile 14
(오라클 10g R2에서는 oradebug lkdebug -m pkey [object_no] 명령을 사용한다)

-- 노드 2에서 rac_test 테이블에 대해 업데이트(Update)를 수행해서 10307번 블록에 대해 독점 모드로 BL 락을 획득한다. 단, 이때 언두 정보를 참조할 필요가 없도록 반드시 Commit을 수행한다.
SQL#2> UPDATE rac_test SET id = 2;
SQL#2> COMMIT;

-- 노드 1에서 총 6번의 SELECT, 즉 일관된 읽기 모드로 블록을 요청한다.
SQL#1> SELECT * FROM rac_test;
SQL#1> /
… ( 같은 쿼리를 6번 수행) …
-- 노드 1에서 수행한 6번의 쿼리를 SQL Trace를 통해 추적한 결과는 다음과 같다.
SQL#1> ho vi /admin/LAS10/udump/ora102_ora_19049.trc

-- 1번째 요청. gc cr block 2-way 이벤트를 대기하는 것을 확인할 수 있다.
SELECT * FROM rac_test
…
WAIT #6: nam='gc cr block 2-way' ela= 1584 p1=14 p2=10307 p3=1

-- 2번째 요청. 역시 gc cr block 2-way 이벤트를 대기.
WAIT #7: nam='gc cr block 2-way' ela= 1203 p1=14 p2=10307 p3=1

-- 3번째 요청
WAIT #2: nam='gc cr block 2-way' ela= 1630 p1=14 p2=10307 p3=1

-- 4번째 요청. _FAIRNESS_THRESHOLD 파라미터의 값(4)에 도달
WAIT #3: nam='gc cr block 2-way' ela= 1206 p1=14 p2=10307 p3=1

-- 5번째 요청. 노드 2에서 락 다운그레이드가 발생했으며, 그 결과로 Current 블록을 전송 받았음을 확인할 수 있다. 대기 이벤트가 gc current block 2-way로 바뀐 것에 주목하자. 노드 2는 독점 모드의 BL 락을 공유 모드로 다운그레이드하고, 노드 1은 공유 모드의 BL 락을 획득하게 된다.
WAIT #12: nam='gc current block 2-way' ela= 1174 p1=14 p2=10307 p3=1

-- 6번째 요청
노드 1이 해당 블록에 대해 공유 모드로 BL 락을 획득했기 때문에, 글로벌 캐시 동기화 작업으로 인한 대기 현상이 발생하지 않는다.

RAC 시스템에서 “Current 모드로 읽을 수 있는 버전의 블록”의 정확한 의미는 “독점 모드(Exclusive Mode)로 BL 락을 획득한 블록”을 말한다. 즉, 로컬 버퍼 캐시에 BL 락을 독점 모드로 획득한 블록이 존재하는 경우에는 글로벌 캐시 동기화 작업없이 로컬 버퍼 캐시에서 바로 블록을 읽어 들인다. 요청 노드의 유저 프로세스가 현재 모드의 블록 전송을 요청한 후에 데이터 블록에 대해 독점 모드로 BL 락을 획득하는 경우는 다음과 같다.

  • 전체 클러스터에서 최초로 블록을 읽어 들이는 경우. 이 경우 gc current grant 2/3-way 이벤트가 Fixed-up 이벤트로 사용된다.
  • 홀더 노드가 공유 모드(Shared Mode)로 읽어 들인 Current 블록을 전송 받는 경우. 이 경우 gc current block 2/3-way 이벤트가 Fixed-up 이벤트로 사용된다.
  • 홀더 노드가 독점 모드(Exclusive Mode)로 읽어 들인 Current 블록을 전송 받은 경우. 이 경우 gc current block 2/3-way 이벤트가 Fixed-up 이벤트로 사용된다. 이 과정에서, 요청 노드는 트랜잭션 정보를 위해 언두 세그먼트 헤더 블록과 언두 블록을 추가로 전송 받게 되며, 해당 블록에 대해서는 gc cr block 2/3-way 이벤트 대기가 관찰된다. 만일 홀더 노드가 블록 변경 후 커밋을 수행하지 않는다면, 요청 노드는 계속해서 언두 정보를 참조해야 하므로 gc cr block 2/3-way 이벤트 대기가 증가할 수 있다. 요청 노드는 Current 블록을 전송하고 난 후, 해당 블록을 과거 이미지(PI. Past Image) 블록으로 전환한다.

독점 모드의 Current 블록을 Current 모드로 전송하는 경우(이것을 흔히 Write-Write 경쟁이라고 부른다)에는 항상 PI 블록이 생성된다. 따라서 클러스터 내에 하나의 블록에 대한 PI 블록이 여러 개 존재할 수 있다. PI 블록은 로컬 인스턴스 레벨의 독점 모드의 Current 블록이라고 할 수 있다. 비록 클러스터 전체 레벨에서는 단 하나만의 독점 모드의 Current 블록이 존재하지만, 각 인스턴스 레벨에서 개별적인 Current 블록(PI 블록)을 가지고 있는 셈이다. 이 경우 클러스터 전체 레벨의 Current 블록만이 디스크에 기록되는 메커니즘이 보장되어야 한다. 특정 인스턴스에서 더티 버퍼를 기록할 필요가 생기면, 자신이 직접 기록하지 않고 마스터 노드에게 클러스터 전체 레벨에서의 Current 블록을 기록할 것을 요청한다. 마스터 노드는 GRD를 통해 홀더 노드에 디스크 기록을 요청하고, 디스크 기록이 성공하면 다른 모든 인스턴스에게 PI 블록을 버퍼 캐시에서 해제할 것을 알린다. 이러한 일련의 과정을 Fusion Write라고 부른다. 오라클은 Fusion Write를 통해 오직 하나의 최신 블록만이 디스크에 기록되는 것을 보장하고, 불필요한 PI 블록들을 메모리에서 해제하는 방법을 제공한다. V$SYSSTAT 뷰를 통해 DBWR 프로세스의 의한 디스크 기록 작업 중 Fusion Write가 얼마나 많은 비중을 차지하는지 확인할 수 있다.

SQL> SELECT name, value FROM v$sysstat WHERE name like '%DBWR%';
NAME		          	            VALUE
--------------------------------	           ----------
DBWR checkpoint buffers written            28039411
…
DBWR fusion writes		            8524130

1)일관된 읽기 모드 요청에 대해 현재 모드의 블록을 전송하는 경우 홀더 노드가 Current 블록을 로컬 캐시에 가지고 있는 상황에서, 다른 노드들이 _FAIRNESS_THRESHOLD 파라미터 값(4)을 초과하여 CR 모드로 블록을 요청한 경우에는, CR 모드가 아닌 Current 모드의 블록 이미지를 전송 받는다. 이 경우 요청 노드는 gc cr block 2-way/3-way 이벤트가 아닌 gc current block 2-way/3-way 이벤트를 Fixed-up 이벤트로 사용한다. 또한, 요청 노드에서는 gc current blocks received, gc current receive time 통계 값이 증가하고, 홀더 노드에서는 gc current blocks served, gc current block pin time, gc current block flush time, gc current block send time 통계 값이 증가한다.

2)현재 모드의 블록 요청에 대해 일관된 읽기 모드의 블록을 전송하는 경우 Update 문과 같은 DML 수행에서는 Current 블록을 요청한다. 홀더 노드에서 이미 변경된 블록을 전송 받는 경우에는 추가적으로 언두 세그먼트 헤더 블록과 언두 블록의 정보를 일관된 읽기 모드로 전송 받아야 한다. 이들 블록에 트랜잭션 정보가 관리되기 때문이다. DML 수행 후 지나치게 장시간 커밋을 수행하지 않으면 언두 세그먼트 헤더 블록이나 언두 블록의 CR 버전이 전송되어야 하므로, 불필요한 인터커넥트 경합을 유발할 수 있다는 사실을 기억해야 한다. 특정 노드의 장시간의 트랜잭션을 수행하는 도중에, 다른 노드에서 DML을 수행하게 되면 언두 정보 참조를 위해 추가적인 블록 전송이 이루어지고, gc cr block 2/3-way 이벤트 대기로 관찰된다.

간단한 테스트를 통해 DML 수행 시에 CR 블록 전송이 이루어지는 것을 확인할 수 있다.

마스터 노드가 노드 2인 rac_test 테이블. id=2, id=3 에 해당하는 로우가 같은 블록에 있는 로우임을 확인
SQL#2> select 
	        id, dbms_rowid.rowid_block_number(rowid) 
               from rac_test;
ID DBMS_     ROWID.ROWID_BLOCK_NUMBER(ROWID)
---------- -     -------------------------------------------------
         2                                10299
         3                                10299
노드 2에서 id = 2 에 대해 Update 수행 후, Commit을 수행하지 않음
SQL#2> UPDATE rac_test SET id = id WHERE id = 2;

노드 1에서 로우 레벨 락이 걸리지 않도록 id = 3 에 대해 Update 수행
SQL#1> UPDATE rac_test SET id = id WHERE id = 3;
SQL#1> / 

노드 1에서 Update 문을 여러 차례 수행한 후, 수행 결과를 SQL Trace를 통해 추적하면 아래와 같다.
update rac_test set id = id where id = 3
WAIT #1: nam='gc cr block 2-way' ela= 1375 p1=8 p2=104457 p3=93
WAIT #1: nam='SQL*Net message to client' ela= 23 p1=16508 p2=1 p3=0
WAIT #1: nam='SQL*Net message from client' ela= 356 p1=16508 p2=1 p3=0
…
P1(file#)=8, P2(block#)=104457, P3(2*r+15, r=39)=93 인 언두 세그먼트 헤더 블록 정보를 얻는 과정에서 gc cr block 2-way 이벤트를 대기하는 것을 알 수 있다. 또한 DBA_ROLLBACK_SEGS 뷰를 조회해 보면, 39번 언두 세그먼트의 헤더 블록임을 확인할 수 있다.'
SQL#2> EXEC print_table('SELECT * FROM DBA_ROLLBACK_SEGS WHERE file_id = 8 AND block_id = 104457');
---------------------------------------------
SEGMENT_NAME		: RAC02_06
OWNER			: PUBLIC
TABLESPACE_NAME	                : TEST_DATA
SEGMENT_ID		: 39
FILE_ID			: 8
BLOCK_ID                                  : 104457
INITIAL_EXTENT		: 2097152
NEXT_EXTENT		:
MIN_EXTENTS		: 1
MAX_EXTENTS		: 32765
PCT_INCREASE		:
STATUS			: ONLINE
INSTANCE_NUM		: 1
RELATIVE_FNO		: 8

[편집] Parameter & Wait Time

[편집] Wait Parameters

gc cr block 2-way 이벤트와 같은 Fixed-up 이벤트는 P1, P2, P3 값이 별도로 부여되지 않으며, Placeholder 이벤트(여기서는 gc cr request 이벤트)와 동일한 값을 가지는 것으로 해석하면 된다.

[편집] Wait Time

[편집] Check Point & Solution

gc cr/current request#Check Point & Solution을 참조한다.

[편집] Event Tip

[편집] 2-way와 3-way의 차이

두 개의 노드로 이루어진 RAC 환경에서는 최대 2 회(2-way)의 통신이 이루어진다. 하지만, 세 개 이상의 노드로 이루어진 RAC 환경에서는 최대 3 회(3-way)까지 통신이 이루어진다. 3 회의 통신을 통해 블록 이미지를 전송 받은 경우에는 gc cr/current block 3-way 이벤트를 Fixed-up 이벤트로 사용한다. 3-way 통신은 클러스터 환경에서는 필연적으로 발생하며, 이 현상 자체를 튜닝하려는 노력은 무의미하다. 하지만, 3-way 통신이 지나치게 많다는 것은 마스터 노드가 잘못 할당되어 있다는 것을 암시할 수도 있다. 오라클 10g R2부터는 세그먼트 레벨의 다이나믹 리마스터링이 지원되므로, 잘못된 마스터 노드 지정에 의한 불필요한 인터커넥트 통신이 자연스럽게 줄어든다. 2-way 통신과 3-way 통신의 차이점을 그림으로 표현하면 아래와 같다. 그림:2way_3way.jpg

[편집] gc cr blocks served

다른 인스턴스의 CR 블록 요청으로 인해 전송(Send/Serve)된 블록의 개수를 의미한다. 이름과 달리 이 통계 값이 전송된 “CR 블록의 수”만을 의미하는 것이 아니라는 사실에 주의할 필요가 있다. CR 블록 요청에 대해 Current 블록을 전송하는 경우도 있기 때문이다. gc cr blocks serverd 통계 값은 항상 gc cr block build time, gc cr block flush time, gc cr block send time 통계 값과 함께 분석해야 한다. CR 블록을 전송하는 과정은 CR 블록 구성(Build), CR 블록 리두 플러시(Flush)와 CR 블록 전송(Send)을 포함하기 때문이다.

[편집] gc cr block build time

다른 인스턴스의 CR 블록 요청으로 인해 CR 블록을 전송하기 위해 CR 블록을 구성(Build)하는데 소요된 시간을 의미한다. 단위는 1/100 초(cs)이다. CR 블록의 구성(Build)은 버퍼 캐시로부터 CR 블록을 탐색하는 시간과 버퍼 캐시에 CR 블록이 존재하지 않는 경우에 디스크로부터 CR 카피(Copy)를 생성하는 시간을 포함한다. 일반적으로 CR 카피를 생성하는 작업은 디스크로부터 언두 이미지를 읽어 들이고, 언두 이미지로부터 CR 블록을 생성하는 작업을 포함한다. 이 작업이 LMS 프로세스에 큰 부하를 유발할 수 있기 때문에, 오라클은 요청된 SCN과 가장 근접한 블록으로부터 CR 블록을 생성한다(이 과정을 CR 카피라고 함). 즉 디스크로부터 언두 이미지를 반영하지 않고 불완전한 이미지의 CR 블록을 생성한 후 전송한다. 불완전한 CR 블록을 전송받은 요청 노드의 프로세스가 직접 언두를 수행해서 완전한 이미지의 CR 블록을 생성한다. 이것을 흔히 Light Weight Rule이라고 부른다. CR 블록을 구성(Build)하는 작업은 메모리 탐색과 메모리 복사 작업을 포함하기 때문에 CPU 자원을 많이 필요로 하며, 이 일련의 작업들을 LMS 프로세스가 담당한다. 만일 CR 블록 구성에 많은 시간이 소모된다면 LMS 프로세스의 성능에 대한 점검이 필요하다.

[편집] gc cr block flush time

다른 인스턴스의 CR 블록 요청으로 인해 Current 블록을 전송하는 과정에서 리두 플러시(Redo Flush)에 소요된 시간을 의미한다. 단위는 1/100 초(cs)이다. 오라클은 요청된 CR 블록에 대해 Current 이미지로 만족 가능한 경우에는 CR 카피 작업을 수행하지 않고 Current 블록을 직접 전송한다. 만일 Current 블록이 현재 더티(Dirty) 상태라면 리두 로그에 변경 내역을 기록한 후 전송해야 한다. 만일 리두 플러시에 많은 시간이 소모된다면 LGWR 프로세스의 성능이나 리두 로그 파일의 I/O 성능에 대한 점검이 필요하다. gcs log flush sysnc 대기 이벤트와 gc cr block busy 대기 이벤트와 연관해서 분석하면 더욱 정확한 진단을 내릴 수 있다.

[편집] gc cr block send time

다른 인스턴스의 CR 블록 요청으로 인해 블록을 전송하는 과정에서 네트워크 전송(Send)에 소요된 시간을 의미한다. 단위는 1/100 초(cs)이다. 이 값의 의미를 정확하게 이해하려면 블록 전송 과정이 버퍼 캐시 레이어와 네트워크 레이어라는 두 개의 레이어에 의해 이루어진다는 사실을 이해해야 한다. 버퍼 캐시 레이어로부터 시작된 블록 전송 요청은 다음과 같은 과정을 통해 물리적인 전송이 이루어진다.

  • 버퍼 캐시 레이어에서 전송할 블록을 준비한 다음(gc cr block build time, gc cr block flush time), 네트워크 레이어로 블록을 전달한다.
  • 네트워크 레이어에서는 OS가 관리하는 네트워크 서브 시스템에 블록 전송 요청을 전달한다.
  • 네트워크 서브 시스템은 전송 큐(가령 UDP Send Buffer)에 전송 데이터를 추가한 후, 네트워크 레이어에 전송에 성공했음을 알린다. 전송 큐에 데이터를 추가하는 것이 곧 물리적으로 데이터가 전송된다는 것을 의미하지는 않는다는 사실에 주의해야 한다.
  • 네트워크 레이어는 버퍼 캐시 레이어에 블록 전송이 성공했음을 알린다.

gc cr block send time 통계 값은 실제 블록 전송에 걸린 시간이 아닌, 네트워크 레이어에 블록 전송 요청을 한 후 응답을 받을 때까지 걸린 시간을 의미한다. 일반적으로 OS 레벨에서의 네트워크 전송 요청은 매우 빠른 속도로 이루어지기 때문에 gc cr block send time 통계 값의 차지하는 비중은 높지 않다. 만일 gc cr block send time 통계 값이 다른 통계 값과 비교해 높은 비중을 차지한다면 네트워크 설정이나 네트워크 드라이브, 하드웨어 설정 등에 문제가 있는지 점검해 볼 필요가 있다.

[편집] gc current blocks served

다른 인스턴스의 Current 블록 요청으로 인해 전송(Send. Serve)된 블록의 개수를 의미한다. gc current blocks serverd 통계 값은 항상 gc current block pin time, gc current block flush time, gc current block send time 통계 값과 함께 분석해야 한다. Current 블록을 전송하는 과정은 Current 블록에 대한 락 획득(Pin), Current 블록 리두 플러시(Flush)와 Current 블록 전송(Send)을 포함하기 때문이다.

[편집] gc current block pin time

다른 인스턴스의 Current 블록 전송 요청을 처리하기 위해 Current 블록에 대한 락을 획득하는데 소요된 시간을 의미한다. 단위는 1/100 초(cs)이다. 락을 획득하는 작업을 보통 핀(Pin)이라고 부르는 데서 비롯된 이름이다. 락 획득 과정에서 시간이 소요되는 사유에는 크게 두 가지가 있다.

  • _GC_DEFER_TIME 파라미터에 의한 블록 전송 지연. 만일 전송 대상인 Current 블록에 대해 블록 클린 아웃 작업이 아직 이루어지지 않았다면 오라클은 _GC_DEFER_TIME 파라미터 값(기본값은 3ms)만큼 대기한 후 락을 획득한다.
  • 블록 경합이 발생하는 경우. 전송 대상인 Current 블록을 다른 로컬 프로세스가 사용 중이라면 락을 획득할 수 없다. 만일 블록 경합이 매우 심해서, 즉 수많은 로컬 프로세스가 같은 블록에 대해 경쟁을 하는 상황이라면 버퍼 전송을 위해 글로벌 락을 획득하는 과정에서 많은 시간을 소모하게 된다.

gc current block pin time 통계 값이 차지하는 비중이 지나치게 높은 경우에는 핫 블록의 존 재 여부를 확인해 보아야 하며, 블록 경합이 지나치게 자주 발생하지 않는지 점검해 보아야 한다. buffer busy waits 대기 이벤트와 gc current block busy 대기 이벤트와 연계해서 분석하면 더욱 정확한 진단을 내릴 수 있다. 또한 V$CURRENT_BLOCK_SERVER 뷰를 활용하면 Current 블록에 대한 락 획득의 성능 문제를 좀 더 세밀하게 분석할 수 있다.

[편집] gc current block flush time

다른 인스턴스의 Current 블록 요청으로 인해 Current 블록을 전송하는 과정에서 리두 플러시(Redo Flush)에 소요된 시간을 의미한다. 단위는 1/100 초(cs)이다. 전송 대상인 Current 블록이 현재 더티(Dirty) 상태라면 리두 로그에 변경 내역을 기록한 후 전송해야 한다. 만일 리두 플러시에 많은 시간이 소모된다면 LGWR 프로세스의 성능이나 리두 로그 파일의 I/O 성능에 대한 점검이 필요하다. gcs log flush sync 대기 이벤트와 gc current block busy 대기 이벤트와 연관해서 분석하면 더욱 정확한 진단을 내릴 수 있다. 또한 V$CURRENT_BLOCK_SERVER 뷰를 참조하면 Current 블록에 대한 리두 플러시의 성능 문제를 좀 더 세밀하게 분석할 수 있다.

[편집] gc current clock send time

다른 인스턴스의 Current 블록 요청으로 인해 블록을 전송하는 과정에서 네트워크 전송(Send)에 소요된 시간을 의미한다. 단위는 1/100 초(cs)이다.

[편집] gc cr blocks received

다른 인스턴스에 CR 블록 전송을 요청한 후 전송 받은 블록 수를 의미한다. gc cr blocks received 통계 값은 gc cr blocks served 통계 값과 일대 일의 관계를 지닌다. 만일 두 개의 인스턴스로 이루어진 RAC 시스템이라면 다음과 같은 관계를 지닌다.

[1번 인스턴스의 gc cr blocks received ≈ 2번 인스턴스의 gc cr blocks served]
gc cr blocks served 통계 값에서 설명한 바와 같이 CR 블록 전송 과정에서 Light Weight Rule이 적용된 경우에는 불완전한 버전의 CR 블록을 전송 받는다. 이 경우에는 요청 인스턴스에서 CR 블록 구성 작업을 마무리하게 된다. 특히 리모트 인스턴스에서 빈번한 블록 변경 작업이 발생했다면 Light Weight Rule이 자주 적용되게 된다. 불완전한 CR 블록을 전송 받은 요청 인스턴스는 CR 블록을 완성하기 위해서 디스크에서 언두 이미지를 읽거나 언두 세그먼트 헤더 블록 정보를 다시 리모트 인스턴스로부터 전송 받는 일련의 추가적인 작업을 수행해야 한다. Light Weight Rule은 홀더 인스턴스의 LMS 프로세스의 부하를 줄이는 대신, 그 부담을 요청 인스턴스의 서버 프로세스가 나누어 가지는 것으로 이해할 수 있다.

[편집] gc cr block receive time

다른 인스턴스에 CR 블록 전송을 요청한 후 전송 받을 때까지 소요된 시간을 의미한다. 단위는 1/100 초(cs)이다. gc cr block receive time 통계 값은 gc cr block build time, gc cr block flush time, gc cr block send time 통계 값에 실제 네트워크 송수신에 소모된 시간을 합친 값으로 이해하면 된다. 만일 두 개의 인스턴스로 이루어진 RAC 시스템이라면 다음과 같은 관계를 지닌다.

[1번 인스턴스의 gc cr block receive time = 2번 인스턴스의 gc cr block build time + gc cr block flush time + gc cr block send time + 전송 요청을 전달하는데 걸린 시간 + 요청에 대한 응답을 전달하는데 걸린 시간]

만일 네트워크 전송 성능이 느리다면 요청 인스턴스가 실제 블록을 받을 때까지 걸린 시간이 홀더 인스턴스가 전송하는데 걸린 시간에 비해 매우 높게 나올 수 있다. 따라서 이런 경우에는 네트워크 성능을 점검해 보아야 한다.

[편집] gc current blocks received

다른 인스턴스에 Current 블록 전송을 요청한 후 전송 받은 블록 수를 의미한다. gc current blocks received 통계 값은 gc current blocks served 통계 값과 일대 일의 관계를 지닌다. 만일 두 개의 인스턴스로 이루어진 RAC 시스템이라면 다음과 같은 관계를 지닌다.
[1번 인스턴스의 gc current blocks received ≈ 2번 인스턴스의 gc current blocks served]

[편집] gc current block receive time

다른 인스턴스에 Current 블록 전송을 요청한 후 전송 받을 때까지 소요된 시간을 의미한다. 단위는 1/100 초(cs)이다. gc current block receive time 통계 값은 gc current block build time, gc current block flush time, gc current block send time 통계 값에 실제 네트워크 송수신에 소모된 시간을 합친 값으로 이해하면 된다. 만일 두 개의 인스턴스로 이루어진 RAC 시스템이라면 다음과 같은 관계를 지닌다.
[1번 인스턴스의 gc current block receive time = 2번 인스턴스의 gc current block pin time + gc current block flush time + gc current block send time + 전송 요청을 전달하는데 걸린 시간 + 요청에 대한 응답을 전달하는데 걸린 시간]

만일 네트워크 전송 성능이 느리다면 요청 인스턴스가 실제 블록을 받을 때까지 걸린 시간이 홀더 인스턴스가 전송하는데 걸린 시간에 비해 매우 높게 나올 수 있다. 따라서 이런 경우에는 네트워크 성능을 점검해 보아야 한다.

[편집] gc blocks lost

블록 전송 과정에서 유실(Lost)된 블록의 수를 의미한다. 블록 유실은 RAC 시스템의 성능에 결정적인 영향을 미치기 때문에 gc blocks lost 통계 값은 가능한 낮은 수치를 유지해야 한다. 만일 gc blocks lost 통계 값이 증가한다면 다음과 같은 확인 절차를 거쳐야 한다.
네트워크 설정이나 하드웨어 설정에 이상은 없는가를 점검한다. netstat와 같은 툴을 이용해서 네트워크 패킷 에러가 발생하지 않는지 점검하고, 네트워크 파라미터가 지나치게 작게 설정되어 있지 않는지 확인한다. 네트워크 버퍼 크기를 크게 하고, MTU의 크기를 크게 하는 것 등도 해결 방법이 될 수 있다.
잘못된 네트워크 프로토콜을 사용하고 있지 않은가를 점검한다. 대부분의 OS에서 오라클은 UDP를 기본 프로토콜로 사용할 것을 권장한다. 많은 종류의 프로토콜에 대해 RAC 성능 테스트와 적용이 이루어졌지만, UDP에서 가장 안정적으로 작동하는 것이 경험적으로 검증되었다. 만일 특정 벤더가 제공하는 특정 프로토콜을 사용한다면 반드시 오라클로부터 검증을 거쳐야 한다.
지나치게 인터커넥트 부하가 높은 경우에는 패킷 유실은 피할 수 없다. 이 경우에는 네트워크 대역폭을 높이거나 SQL/어플리케이션 튜닝을 통해 블록 전송 수를 줄여야 한다.

[편집] blocks corrupt

블록 전송 과정에서 손상(Corrupt)이 발생한 블록 수를 의미한다. 블록 손상 여부는 체크섬(Checksum) 값을 통해 확인된다. 블록 손상은 RAC 시스템의 성능에 결정적인 영향을 미치기 때문에 blocks corrupt계 값은 가능한 낮은 수치를 유지해야 한다. 블록 손상은 RAC 자체의 문제라기보다는 대부분 좀 더 하부 레이어, 즉 네트워크 설정이나 하드웨어 설정에 의해 발생하는 문제로 봐야 한다. 만일 gc blocks corrupt 통계 값이 증가한다면, 비현실적인 네트워크 파라미터나 하드웨어 설정은 없는지 점검해야 한다.

[편집] gc CPU used by this session

글로벌 캐시 동기화 작업에 사용한 CPU 시간을 의미한다. 단위는 1/100 초(cs)이다. 이 값을 전체 CPU 사용 시간과 비교하면 글로벌 캐시 동기화 작업에 얼마나 많은 CPU 자원을 사용하는지 추측할 수 있다. 오라클이 통계 값(Stats)으로 제공하는 CPU 사용 시간은 총 네 가지로 다음과 같다.

  • CPU used by this session: 전체 CPU 사용 시간
  • IPC CPU used by this session: IPC 작업을 수행하는데 사용한 CPU 시간
  • global enqueue CPU used by this session: 글로벌 락 동기화 작업을 수행하는데 사용한 CPU 시간
  • gc CPU used by this session: 글로벌 캐시 동기화 작업을 수행하는데 사용한 CPU 시간

위의 값들을 비교해서 특정 작업의 CPU 자원이 전체 CPU 사용 시간 대비 얼마나 사용되는지 확인할 수 있다.

오라클 10g부터 제공되는 타임 모델(Time Model)을 사용하면 더욱 풍부한 CPU 사용 시간 정보를 얻을 수 있다. 아래 스크립트는 V$SYS_TIME_MODEL 뷰를 통해 DB 작업의 소요 시간(Elapsed Time)을 추출한 것이다. 값의 단위는 1/1,000,000 (micros) 로, 각 DB 작업이 전체 소요 시간(DB Time)이나, CPU 사용 시간(DB CPU)에 비해 얼마나 높은 비중을 차지 하는지 분석할 수 있다. DB Time 통계 값과 CPU used by this session 통계 값은 정확하게 일치하지는 않지만 비교적 비슷한 값을 제공한다.
SQL> SELECT STAT_NAME, VALUE FROM V$SYS_TIME_MODEL;
STAT_NAME                                                               VALUE
-------------------------------------------------------          -----------------------
DB time					11716336545654
DB CPU					560565103783
background elapsed time			2494917554431
background cpu time			                204519278273
sequence load elapsed time			13122182762
parse time elapsed			                9245428546
hard parse elapsed time			1134663273
sql execute elapsed time			11539973552003
connection management call elapsed time	                46516094792
failed parse elapsed time			919444
failed parse (out of shared memory) elapsed time          0
hard parse (sharing criteria) elapsed time	                4293820
hard parse (bind mismatch) elapsed time	                1665127
PL/SQL execution elapsed time		                2342550484
inbound PL/SQL rpc elapsed time                                  0
PL/SQL compilation elapsed time		                15225474
Java execution elapsed time			0

[편집] Analysis Case