by-nc-sa     개발자, DBA가 함께 만들어가는 구루비 지식창고!

A. RAC for BMT




  • RAC시스템의 성능을 극대화하기 위해 오라클 및 OS설정 등에서 적용 가능한 방법론을 논의한다.

1. 오라클 파라메터

1.1 _INTERCONNECT_CHECKSUM = FALSE

  • _INTERCONNECT_CHECKSUM : 인터커넥트를 통해 주고 받은 블록의 유효성 확인 여부
    • TRUE : 기본값
    • FALSE : 블록의 유효성을 체크하는 작업이 생략되므로 CPU사용률 및 성능이 개선된다.
  • DB_BLOCK_CHECKSUM : 블록에 데이터를 기록할 때 체크섬 정보를 저장할지 여부
    • TRUE : 기본값
    • FALSE : SYSTEM 테이블스페이스를 제외한 모든 테이블스페이스의 블록에 대한 체크섬 정보 저장 및 확인 작업을 생략한다. 블록 이미지 손상 감지가 안되어 운영 환경에서는 적절하지 않다.

1.2 _OS_SCHED_HIGH_PRIORITY = 1( 10gR2 only ) : LMS 프로세스의 실시간 스케줄링 여부

  • 1 : 기본값, 실시간 스케줄링 사용한다.
  • 0 : 실시간 스케줄링이 아닌 시분할 스케줄링을 사용한다. renice명령을 통해 LMS프로세스의 우선순위를 높여준다.
  • 2이상 : 기본값 이상의 높은 우선순위를 부여받는다. 인터커넥트의 사용이 극단적으로 많을 경우 2이상을 고려해 볼 수 있지만 LMS프로세가 CPU를 지나치케 많이 점유할 수 있다.

1.3 _GC_DEFER_TIME = 0

  • _GC_DEFER_TIME 클린아웃 작업이 예상되는 current 블록의 전송을 지정한 시간만큼 기다린후 전송하여 블록 전송을 지연시키는 역활을 한다. 0으로 변경하면 지연 없이 즉시 블록을 전송한다.
  • 기본값 : 3ms
  • GC_DEFER_TIME 파라메터 값을 0으로 변경하면 로컬 캐시의 효율성은 낮아지는 반면, 큰 값을 지정하면 로컬 노드에서의 클린아웃 작업을 효율적으로 처리할 수 있다.
  • gc current block 2-way 이벤트 대기 시간이 높게 나온다면 GC_DEFER_TIME 파라메터 값을 줄이거나 0으로 변경한다.
  • 블록 클린 아웃 참조 : http://wiki.gurubee.net/pages/viewpage.action?pageId=3900271

1.4 _FAIRNESS_THRESHOLD=1

1.5 _GC_AFFINITY_TIME = 0 : 리소스 리마스터링을 수행하지 않는다. 리마스터링에 대한 오버헤드 감소.

1.6 STATISTICS_LEVEL = BASIC

  • 오라클 성능 정보 수집 범위 결정
  • 기본값 : TYPICAL
  • BASIC으로 변경하면 성능 정보 수집의 오버헤드가 감소하지만, 성능 분석을 위해 필요한 데이터 수집이 되지 않는다.

1.7 _RELIABLE_BLOCK_SENDS = TRUE

  • 신뢰성 있는 프로토콜이 사용 중인지 여부를 지정하는 파라메터
  • 기본값 : FALSE ( 신뢰성이 없으므로 오라클이 직접 신뢰성 검사를 수행하도록 지정. 신뢰성 검사를 수행하는 오버헤드 발생)
  • 데이터 신뢰성이 보장되는 프로토콜을 사용한다면 TRUE로 변경하여 오버헤드를 줄일 수 있다. ( RAC 인터커넥트에서 보편적으로 사용하는 UDP는 데이터가 100%전송된다는 것은 신뢰할 수 없는 프로토콜이다.)

1.8 COMMIT_WRITE = 'BATCH,NOWAIT' ( 10gR2 only )

  • 커밋 동작 방식을 결정하는 파라메터
  • 기본값 : 'IMMEDIATE,WAIT' ( 'IMMEDIATE - 커밋 요청시 즉시 처리한다, WAIT - LGWR 프로세스가 리두로그에 기록을 완료할 때까지 기다린다.)
  • 'BATCH,NOWAIT'로 지정하면 리두 로그 기록에 의한 대기 현상이 사라지고, 사용자 응답 시간이 개선된다. 단 사용자 변경작업이 반드시 리두 로그에 리록된다는 보장이 되지 않기 떄문에 인스턴스 장애 발생시 데이터 복구에 실패할 수 있다.
  • 시스템, 세션, 트랜잭션 레벨에서 커밋 방식 변경이 가능한다.
  • 10gR2 이전 버전에서 _WAIT_FOR_SYNC = FALSE와 비슷한 효과
  • BATCH방식의 커밋은 GROUP COMMIT 과 유사 : ( http://wiki.gurubee.net/pages/viewpage.action?pageId=6259824 )

1.9 DML_LOCKS = 0

  • TM락 개수를 지정하는 파라메터
  • 0으로 설정하면 오라클은 TM락을 사용하지 않는다. 테이블 DML수행해도 TM락을 획득할 필요하 없다. TM락을 사용하지 않는 대신에 이미 존재하는 테이블에 대한 DDL이 허용되지 않는다.

2. OS 파라메터 및 설정 ( 3장 내용 정리 )

1. UDP 버퍼사이즈를 충분히 크게한다. 최소 256K ~ 2M
2. MTU 크기를 가능한 크게 한다. 9000바이트 MTU사용
3. LMS프로세스에 대해 가능한 실시간 스케줄링을 적용한다.

3. 오라클 세그먼트/오브젝트 설정 ( 4장 내용 정리 )

1. 자주 사용되는 시퀀스는 캐쉬 크기를 충분히 크게 한다. ( 시퀀스 값 글로벌 동기화 부담 감소 )
2. 시퀀스 생성시 가능한 NOORDER 속성을 부여한다. ( 노드간 동기화 작업 불필요 )
3. 데이터 추가가 잦은 세그먼트에 대해서는 큰 크기의 익스텐트를 사용한다.
4. 가능한 ASSM 사용한다.
5. 인덱스 생성시 가능한 해시 파티션을 부여한다. ( 노드간 분산 효과, 동일 리프 블록 경합 방지 )
6. 읽기 전용 데이터들은 읽기 전용 테이블스페이스를 사욯한다. ( 글로볼 캐시 동기화 발생 안함 )
7. 병렬 작업시 불필요하게 노드 간의 작업을 분배하지 않는다. ( 인터커넥트 부담 감소 )

4. 스토리지

1. 가능한 로 디바이스를 사용한다.
2. 가능한 Direct I/O를 사용하며, 비동기 I/O를 사용한다. ( 로 디바이스, ASM )
3. 스트라이핑을 최대한으로 적용한다. ( 핫 스팟 방지 )
4. 액세스가 많은 데이터들은 디스크의 바깥쪽에 위치시키는 것을 고려한다. ( HOW? )
5. 리두 데이터가 많은 시스템에서는 리두 로드를 별도의 독립적은 디스크로 분산한다.

문서정보

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. 5월 18, 2011

    이경화 says:

    10g, 11g에서의 리소스 리마스터링 관련 히든 파라메터 조회. – 지난번 소개해주신 _lm_dynamic_lms로 했으때는 FAL...

    10g, 11g에서의 리소스 리마스터링 관련 히든 파라메터 조회.
    – 지난번 소개해주신 _lm_dynamic_lms로 했으때는 FALSE로 나오는데요..실제 _gc_affinity_time 으로는 리소스 리마스터링을 활성화한것으로 보여집니다.
    – v$gcspfmaster_info 조회해보니, 리소스 리마스터링은 되고 있네요.

    1) 10gR2
    SQL> set linesize 120
    SQL> col Parameter format a30
    SQL> col "Session Value" format a20
    SQL> col "Instance Value" format a20
    SQL> SELECT a.ksppinm "Parameter", b.ksppstvl "Session Value", c.ksppstvl "Instance Value"
    2 FROM x$ksppi a, x$ksppcv b, x$ksppsv c
    3 WHERE a.indx = b.indx AND a.indx = c.indx AND a.ksppinm LIKE '/_%' escape '/'
    4 AND a.ksppinm like 'gc_affinity%';

    Parameter Session Value Instance Value
    ------------------------------ -------------------- --------------------
    _gc_affinity_time 10 10
    _gc_affinity_limit 50 50
    _gc_affinity_minimum 6000 6000

    SQL> SELECT
    2 a.ksppinm "Parameter",
    3 b.ksppstvl "Session Value",
    4 c.ksppstvl "Instance Value"
    5 FROM
    6 x$ksppi a,
    7 x$ksppcv b,
    8 x$ksppsv c
    9 WHERE
    10 a.indx = b.indx
    11 AND
    12 a.indx = c.indx
    13 AND
    14 a.ksppinm ='_lm_dynamic_lms';

    Parameter Session Value Instance Value
    ------------------------------ -------------------- --------------------
    _lm_dynamic_lms FALSE FALSE

    2) 11gR1
    SQL> set linesize 120
    SQL> col Parameter format a30
    SQL> col "Session Value" format a20
    SQL> col "Instance Value" format a20
    SQL> SELECT a.ksppinm "Parameter", b.ksppstvl "Session Value", c.ksppstvl "Instance Value"
    2 FROM x$ksppi a, x$ksppcv b, x$ksppsv c
    3 WHERE a.indx = b.indx AND a.indx = c.indx AND a.ksppinm LIKE '/_%' escape '/'
    4 AND a.ksppinm like 'gc_affinity%';

    Parameter Session Value Instance Value
    ------------------------------ -------------------- --------------------
    _gc_affinity_ratio 50 50
    _gc_affinity_locking TRUE TRUE
    _gc_affinity_locks TRUE TRUE

    SQL> set linesize 120
    SQL> col Parameter format a30
    SQL> col "Session Value" format a20
    SQL> col "Instance Value" format a20
    SQL> SELECT a.ksppinm "Parameter", b.ksppstvl "Session Value", c.ksppstvl "Instance Value"
    2 FROM x$ksppi a, x$ksppcv b, x$ksppsv c
    3 WHERE a.indx = b.indx AND a.indx = c.indx AND a.ksppinm LIKE '/_%' escape '/'
    4 AND a.ksppinm like 'gc_policy%';

    Parameter Session Value Instance Value
    ------------------------------ -------------------- --------------------
    _gc_policy_time 10 10
    _gc_policy_minimum 1500 1500

    SQL> SELECT
    2 a.ksppinm "Parameter",
    3 b.ksppstvl "Session Value",
    4 c.ksppstvl "Instance Value"
    5 FROM
    6 x$ksppi a,
    7 x$ksppcv b,
    8 x$ksppsv c
    9 WHERE
    10 a.indx = b.indx
    11 AND
    12 a.indx = c.indx
    13 AND
    14 a.ksppinm ='_lm_dynamic_lms';

    Parameter Session Value Instance Value
    ------------------------------ -------------------- --------------------
    _lm_dynamic_lms FALSE FALSE

  2. 5월 18, 2011

    장태길 says:

    실제 다이나믹 리소스 결과는 이 뷰를 보시면 확인 하실수 있을꺼에요 ( V$GCSPFMASTER_INFO ) 말씀하신 _gc_affinity_...

    실제 다이나믹 리소스 결과는 이 뷰를 보시면 확인 하실수 있을꺼에요 ( V$GCSPFMASTER_INFO )
    말씀하신 _gc_affinity_time 이 뷰를 어차피 다이나믹리소스 마스터링 발생에 대한 임계치 지정, 얼마나 자주 수행할지 여부 결정.
    그리고 지금 찾아봤는데 못차겠는데 _lm_dynamic_lms 파라미터가 10g 에서는 false 로하면 다이나믹 리소스 마스터링이 비활성화 되구요..
    ( 저희 환경도 그렇구.. 요 포스트 함 보세요 http://kr.blog.yahoo.com/dbacool/44 )
    11g 에서는 _lm_dynamic_lms 가 더이상 작동하지 않는다는 정보도 있는데 출처가 어딘지 못찾겠네요..
    보통 오라클에서 신기능 출시하면서 핸들링 할수 있는 히든 파라미터를 내놓고,, 잘못되면 바로 false 조치 (10g)
    안정화 되면, 그 히든 파라미터 기능을 죽이는 것 같습니다. ㅎㅎ