gc buffer busy 대기이벤트의 Parameter P3의 의미
Advanced Oracle 2009/02/23 17:19
gc buffer busy와 gc current request 이벤트의 P1, P2, P3 값의 의미를 조회해 보자.
UKJA@ukja102> begin
2 print_table('select name, parameter1, parameter2, parameter3
3 from v$event_name
4 where name in (''gc buffer busy'', ''gc current request'')');
5 end;
6 /
NAME : gc buffer busy
PARAMETER1 : file#
PARAMETER2 : block#
PARAMETER3 : id#
-----------------
NAME : gc current request
PARAMETER1 : file#
PARAMETER2 : block#
PARAMETER3 : id#
-----------------
Parameter1과 Parameter2의 의미는 명확하다. Parameter3(id#)의 의미는 무엇일까? 이것이 오랜 의문 중 하나였는데, 최근에 그 의미의 일부를 알게 되었다. Tanel Poder가 OTN Forum에 올린 답변을 통해서이다.
gc cr request와 같은 대기이벤트의 경우에는 Parameter3 값을 통해 Block Class 정보를 제공하기 때문에 Block Dump를 수행하지 않고도 어떤 Block Class에서 문제가 발생하는 정확하게 알 수 있다. Block 레벨의 경합인 경우에는Block Class 정보가 필수적이다.
UKJA@ukja102> begin
2 print_table('select name, parameter1, parameter2, parameter3
3 from v$event_name
4 where name in (''gc cr request'')');
5 end;
6 /
NAME : gc cr request
PARAMETER1 : file#
PARAMETER2 : block#
PARAMETER3 : class#
-----------------
다행스러운 것은 gc current request나 gc buffer busy 이벤트의 경우에도 Parameter3 값을 통해 Block Class 정보를 얻을 수 있다는 것이다. 더 정확하게 말하면 이들 Parameter3 값의 하위 2 Byte의 값이 Block Class이다.
가령 아래와 같이 대기 이벤트가 발생했다고 가정하면
gc current request file#= 717 block#= 2 id#= 33554445
gc buffer busy file#= 1058 block#= 2 id#= 65549
다음과 같이 하위 2 Byte의 값을 구할 수 있다(16진수로 변환했을 때 하위 2자리).
UKJA@ukja102> with
2 v1 as (select to_hex(33554445) as h from dual),
3 v2 as (select to_hex(65549) as h from dual)
4 select
5 to_dec(substr(v1.h, length(v1.h)-1, 2)) as v1,
6 to_dec(substr(v2.h, length(v2.h)-1, 2)) as v2
7 from v1, v2
8 ;
V1 V2
---------- ----------
13 13
13의 의미는 아래 뷰에서 찾을 수 있다.
UKJA@ukja102> select rownum, class from v$waitstat;
ROWNUM CLASS
---------- ------------------
1 data block
2 sort block
3 save undo block
4 segment header
5 save undo header
6 free list
7 extent map
8 1st level bmb
9 2nd level bmb
10 3rd level bmb
11 bitmap block
12 bitmap index block
13 file header block <-- Here!
14 unused
15 system undo header
16 system undo block
17 undo header
18 undo block
즉, 위의 대기 이벤트는 File Header Block(LMT에서 Bitmap을 관리하는 Block)에서의 경합에 의해 발생했다는 것을 짐작할 수 있다. Block Class 정보만으로도 진단이 매우 손쉬워진 것이다. 이 정보가 없다면 Block Dump라는 귀찮은 작업이 뒤따른다.
원본 위치 <http://ukja.tistory.com/tag/gc%20current%20request>
댓글 없음:
댓글 쓰기