태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

Library Cache Latch가 사라졌다!

오라클 2009.03.31 20:09

Tanel Poder는 Oracle 11g에서 Library Cache와 관련된 대부분의 Latch가 사라졌다는 사실을 공표했다.
 

DBA나 개발자들에게는 좋은 소식 이지만, 나처럼 Latch 경합 문제 해결을 업으로 삼는 사람들에게는 슬픈 소식이라고 하겠다.

그래서, 내가 아직 죽지 않았다는 것을 간단한게 증명해보겠다.

-- 이 Query는 Child가 하나뿐이다.
@shared_cursor 'select /* cursor_share_1 */ * fro t1 where c1 = :b1%'

SQL_TEXT                       = select /* cursor_share_1 */ * from t1 where c1
= :b1
SQL_ID                         = 6jf82h3bq1tzr
ADDRESS                        = 2B3F7078
CHILD_ADDRESS                  = 2B3F6F34
CHILD_NUMBER                   = 0
--------------------------------------------------                             

PL/SQL procedure successfully completed.


-- 이 Query는 Child가 다섯개이다.
@shared_cursor 'select /* cursor_share */ * from t1 where c1 = :b1%'

SQL_TEXT                       = select /* cursor_share */ * from t1 where c1 =
:b1
SQL_ID                         = 2zu6xb9130t89
ADDRESS                        = 2B38369C
CHILD_ADDRESS                  = 2AC50F60
CHILD_NUMBER                   = 0
--------------------------------------------------
SQL_TEXT                       = select /* cursor_share */ * from t1 where c1 =
:b1
SQL_ID                         = 2zu6xb9130t89
ADDRESS                        = 2B38369C
CHILD_ADDRESS                  = 2A652B48
CHILD_NUMBER                   = 1
OPTIMIZER_MODE_MISMATCH        = Y
--------------------------------------------------
SQL_TEXT                       = select /* cursor_share */ * from t1 where c1 =
:b1
SQL_ID                         = 2zu6xb9130t89
ADDRESS                        = 2B38369C
CHILD_ADDRESS                  = 2A3C7968
CHILD_NUMBER                   = 2
BIND_MISMATCH                  = Y
--------------------------------------------------
SQL_TEXT                       = select /* cursor_share */ * from t1 where c1 =
:b1
SQL_ID                         = 2zu6xb9130t89
ADDRESS                        = 2B38369C
CHILD_ADDRESS                  = 2A1EFD0C
CHILD_NUMBER                   = 3
BIND_MISMATCH                  = Y
--------------------------------------------------
SQL_TEXT                       = select /* cursor_share */ * from t1 where c1 =
:b1
SQL_ID                         = 2zu6xb9130t89
ADDRESS                        = 2B38369C
CHILD_ADDRESS                  = 2A1DA0F0
CHILD_NUMBER                   = 4
BIND_MISMATCH                  = Y
OPTIMIZER_MODE_MISMATCH        = Y
--------------------------------------------------

PL/SQL procedure successfully completed.


Soft Parse를 과도하게 발생시켜서, Child LCO가 하나인 경우와 Child LCO가 다섯개인 경우에 대해 Latch 획득에서 얼마나 차이가 있는지 확인해보자.

@mon_on userenv('sid')

declare
  v_cursor      number;
begin
  for idx in 1 .. 200000 loop
    v_cursor := dbms_sql.open_cursor;
    dbms_sql.parse(v_cursor, 'select /* cursor_share_1 */ * from t1 where c1 = :b1', dbms_sql.native);
    dbms_sql.close_cursor(v_cursor);
  end loop;
end;
/

@mon_off

declare
  v_cursor      number;
begin
  for idx in 1 .. 200000 loop
    v_cursor := dbms_sql.open_cursor;
    dbms_sql.parse(v_cursor, 'select /* cursor_share */ * from t1 where c1 = :b1', dbms_sql.native);
    dbms_sql.close_cursor(v_cursor);
  end loop;
end;
/

@mon_off2
@mon_show2

10g 에서는 Child LCO가 다섯개인 경우에 1.5M + 0.8M + 0.8M = 3.1M 만큼 Library Cache Latch를 더 획득한 것을 알 수 있다.

LATCH_NAME                         D_GETS   D_MISSES   D_SLEEPS  D_IM_GETS
------------------------------ ---------- ---------- ---------- ----------
library cache                     1599584         -9         -1          0
library cache lock                 799878          0          0          0
library cache pin                  799743          1          0          0
session allocation                  -1497          0          0          0
shared pool                          -517          0          0          0
...


반면, 11g에서는 Child LCO가 다섯가인 경우가 단지 0.4M의 Shared Pool Latch를 더 획득한 것을 알 수 있다.

LATCH_NAME                         D_GETS   D_MISSES   D_SLEEPS  D_IM_GETS
------------------------------ ---------- ---------- ---------- ----------
shared pool                        399866          3          1          0
cache buffers chains                 -175          0          0         -7
enqueue hash chains                    58          0          0          0
enqueues                               57          0          0          0
row cache objects                     -46          0          0          0
shared pool simulator                 -40          0          0          0
...

Oracle 11g에서는 Library Cache Chain을 탐색하기 위해 더 이상 Library Cache Latch를 획득할 필요가 없다는 것을 잘 알 수 있다. Oracle 11g는 Library Cache Chain, Library Cache Lock, Library Cache Pin을 획득하기 위해 Library Cache Latch가 아닌 Mutex를 사용한다.

Mutex는 Latch에 비해 더 가볍고, 개수가 더 많기 때문에 동시성 문제에 있어서 훨씬 뛰어난 성능을 보장한다. Oracle 11g의 주요한 성능 향상 중 하나이다.

PS) Oracle의 Mutex는 Unix System에서 제공하는 Mutex와는 다른 Oracle이 구현한 독자적인 동기화 객체이다. 단, OS가 제공하는 API를 사용하기 때문에 OS에 따라 미세한 차이를 보일 순 있겠다.



신고
Trackback 0 : Comments 2
  1. 이민규 2009.05.20 17:19 신고 Modify/Delete Reply

    mutex는 10g 부터 사용하는 것으로 알고 있습니다. (_kks_use_mutex_pin) 10R2에서 버그가 있어
    초기에는 false로 했었는데요. mutex 메카니즘도 개선 된것 같습니다.

  2. 욱짜 2009.05.20 19:35 신고 Modify/Delete Reply

    Mutex는 10g에서 소개되어서 점점 용도가 증가하고 있습니다.

    10g에서는 Cursor Pin이나 Cursor Stats 에 대한 Latch를 대신하는 용도에서
    11g에서는 더 확장되어 Library Cache Latch, Library cache lock latch, library cache pin latch 등이 모두 Mutex로 대체되고 있네요. Mutex는 Latch보다 가볍지만, Monitoring하기는 더 까다로워졌습니다.

    참고로 10g에서 Mutex가 문제가 많이 된 것은 특정 OS에서 Low Level의 API 사용에 문제가 있기 때문으로 알고 있습니다. 아마 최근에는 많은 개선이 이루어졌을 겁니다. 하지만 11g를 시범적으로 사용하는 시스템에서 Mutex 관련 버그들이 종종 보고되고 있는 것으로 보아 여전히 유심히 Monitoring해야할 필요가 있을 것 같습니다.

Write a comment

티스토리 툴바