target=_blank>http://blog.naver.com/samuelc/20047868263


1. RAC 구성 프로세스
1) RAC 구성프로세스
=> CRS(Cluster Ready Service)
    - 모든 플랫폼에 대한 표준화된 클러스터 인터페이스를 제공
    - 이전 버전에 없었던 새로운 고가용 서비스를 제공
    - HW업체에서 제공하는 Cluster SW와 함께 사용되어 질수도 있으며 HW업체의 Cluster SW없이
      CRS자체만으로도 구성할 수 있음

=> CRS(Cluster Ready Service)구성을 위하여 확인해야 할 사항
    - CRS는 10g를 설치하기 전에 설치되고 실행되어야 함
    - CRS_HOME과 ORACLE_HOME은 반드시 다른디렉토리에 설치 되어야 함
    - voting 파일, OCR파일을 설치할 수 있는 공유된 디렉토리 또는 디바이스가 구성되어야 함
    - 네트워크 인터페이스가 구성되어야 함
    - RAC NODE당 1개의 CRS데몬만 실행 가능함
    - 네트워크 split이 있을 경우 시스템 Rebooting 현상이 발생 할 수 있음
    - 서비스를 중단하려면 장비 shutdown 또는 "init.crs stop" 명령을 실행

=> CRS를 구성하는 프로세스

[ CRSD 데몬의 역활 ]
- HA(High Availability) 작읍을 위한 엔진
- Application 자원관리
- Application 자원을 구동, 정지, fail over 처리
- Application 자원 구동/정지/점검 하기 위한 별도의 'actions'을 spawn
- OCR(Oracle Configuration Repository) 의 구성 프로파일 관리
- OCR의 현재 알려진 상태를 저장
- root 권한으로 실행
- RAC환경에서 가장 기본적인 NODE간의 자원상태를 감지하고 있음
- 필요한 경우 해당 NODE를 Down 하거나 Rebooting 하는 역활을 수행
- CRS데몬은 장애발생 시 자동으로 구동되도록 설정 되어 있음
- 만약 CRS데몬을 OS명령어로 kill 하게 될 경우 해당 NODE는 Rebooting 될 수 있으므로 주의

[ CSSD 데몬의 역활 ]
- CSSD는 RAC의 일부로, ASM과 함께 단일 인스턴스를 구성
- NODE멤버쉽에 대한 액세스를 제공
- 그룹 서비스 제공
- 기본적인 클러스터 lock 기능 제공
- 오라클 계정으로 실행
- CSSD데몬은 데이터베이스의 Synchronization 부분을 담당
- CSSD데몬은 하드웨어 공급 업체에서 제공하는 클러스터 소프트웨어 없이도 실행 가능함
- 장애로 인한 해당 데몬의 종료 시스템은 Rebooting 됨
    이는 split brain 현상 발생 시, 데이터 corruption 방지를 위함

[ EVMD 데몬의 역활 ]
- 특정한 사건 발생 시 이벤트 생성
- 지식 프로세스로 evmlogger를 spawn 시킴
- Evmlogger 는 필요시 자식 프로세스를 spawn 시킴
- callout directory를 스캔하고 callout 을 호출
- 오라클 계정으로 실행
- RAC환경에서 특정한 사건 발생 시 이벤트를 기록하고 모니터링 하는 역활을 수행
- 장애로 인한 종료 시 자동으로 재구동됨. 즉, OS재구동이 발생하게 되면 모두 자동으로 재구동 됨

=> OCR(Oracle Configuration Repository)
RAC를 구성하는 정보를 저장하는 저장소

- OCR정보는 RAC환경에서 매우 중요한 관리항목이므로 주기적인 백업을 받아 두어야 함
- 기본적으로는 4시간마다 자동으로 백업이 이루어 지고, 비상상황을 대비하여 3벌의 백업을
  자동적으로 유지 관리하고 있음

=> OCR 정보를 수동으로 백업받고 복구하는 방법
(1) orconfig? backuploc <directory> : 백업
(2) orconfig? showbackup : 백업현황 조회
(3) orconfig? restore <파일명> : 복구(모든 NODE중지 후 한 NODE씩 작업진행 )
(4) orconfig? export
(5) orconfig? import

=> OCR 정보를 import하는 방법
- Cluster 를 중단시키고 OCR정보를 import 하는 방법
(1) Cluster상의 모든 Node를 Shutdown 한 후 Node 한대만을 single-user mode로 올림
(2) ocrconfig? import 명령을 사용하여 import 수행
(3) Cluster 상의 모든 Node를 multi-user mode로 구동시킴

- Cluster 를 중단시키지 않고 OCR정보를 import 하는 방법
(1) 모든 Node의 initab 파일을 다른 이름으로 Copy 해 놓은 후 모든 Node상의 initab entries 를
    Update 하고 CRS관련 entry 를 제거함
(2) 모든 Node에서 /etc/init.d/init.crs stop 명령을 사용하여 CRS를 중지시킴
(3) Cluster상의 한 Node에서 ocrconfig? imprt 명령을 사용하여 OCR export를 수행
(4) 모든 Node에서 original initab file 복원
(5) 모든 Node에서 /etc/init.d/init.crs start 명령으로 CRS START
(6) /etc/init.q 명령을 실행

- OCR 파일 DUMP생성방법
ocrdump ocr_file.txt (root에서 수행)


2) 로그파일 관리
=> CRS에 무제가 발생하였는지 확인하는 방법

- $ORA_CRS_HOME/crs/log
  + 이 디렉토리는 CRS자원들에 대한 TRACE를 포함한
  + CRS에 의해 식별된 가입(joining), 탈퇴(leaving), 재구동(restarting), 재배치(relocating)와
      관련된 정보들이 기록됨

- $ORA_CRS_HOME/crs/init
  + crsd.bin 데몬과 관련된 모든 core dump가 기록됨

- $ORA_CRS_HOME/css/log
  + 재구성이나 성공하지 못한 체크인, 클라이언트의 css listener로 부터 발생한 연결 및 연결해제
    와 관련된 모든 액션을 기록함
  + 때에 따라서는 Logger에서는 (auth.crit) 유형의 메시지를 남기는데 이것은 오라클에 의해
    리부팅이 발생할 때 남게 되며, 이 정보는 Rebooting이 정확히 언제 발생했는지를 확인하는데
    사용될 수 있음

- $ORA_CRS_HOME/css/init
  + 기본적으로는 ocssd로 부터의 core dump파일을 저장
  + 프로세스의 종료가 심각한 문제로 간주되는 css데몬의 pid 정보 또한 기록됨
  + css의 비정상 재 구동이 발생할 경우 core 파일은 core.<pid> 형태로 기록됨

- $ORA_CRS_HOME/evm/log
  + evm과 evmlogger 데몬의 로그파일이 기록됨
  + CRS또는 CSS관련 디렉토리 처럼 디버깅 용도로 자주 사용되지는 않음

- $ORA_CRS_HOME/evm/init
  + EVM의 pid와 lock 파일이 저장됨
  + EVM으로 부터 발생한 core 파일 또한 이 디렉토리에 저장됨 

2. RAC 구동 및 관리
1) crs_stat 명령을 이용하여 CRS자원확인
2) srvctl 명령을 사용하여 CRS자원확인
=> CRS자원 상태확인

- 데이터베이스의 상태, 모든 인스턴스와 모든 서비스의 상태 확인
  # srvctl status database -d ORACLE -v
- 이름이 부여된 인스턴스의 상태와 현재 서비스이 상태확인
  # srvctl status instance -d ORACLE -i TEST01, TEST02 -v
- 이름이 부여된 서비스의 상태확인
  # srvctl status service -d ORACLE -s ERP -v
- 데이터베이스 Application 을 지원하는 모든 Node의 상태확인
  # srvctl status node

=> CRS자원 구동

- 데이터베이스를 모든 활성화된 인스턴스와 함께 구동
  # srvctl start database -d ORACLE
- 이름이 부여된 인스턴스의 구동
  # srvctl start instance -d ORACLE -i TEST03, RAC04
- 이름이 부여된 서비스의 구동
  # srvctl start service -d ORACLE -s CRM
- 이름이 부여된 인스턴스의 서비스의 구동
  # srvctl start service -d ORACLE -s CRM -i RAC04
- Node Application의 구동
  # srvctl start nodeapps -n myclust

=> CRS자원 정지

- 데이터베이스, 모든 인스턴스, 모든 서비스를 정지시킴
  # srvctl stop database -d ORACLE
- 이름이 부여된 인스턴스를 정지시킴. 그전에 우선 존재하는 모든 서비스를 재배치함
  # srvctl stop instance -d ORACLE -i TEST03, TEST04 
- 서비스를 정지시킴
  # srvctl stop service -d ORACLE -s CRM
- 이름이 부여된 인스턴스의 서비스를 정지시킴
  # srvctl stop service -d ORACLE -s CRM -i RAC04
- Node Application을 정지시킴, 인스턴스와 서비스 역시 정지됨
  # srvctl stop nodeapps -n myclust

=> CRS자원의 추가
- 새로운 Node추가
  # srvctl add nodeapps -n myclust-1 -o $ORACLE_HOME
- 새로운 데이터베이스의 추가
  # srvctl add database -d ORACLE -o $ORACLE_HOME
- 이미 존재하는 데이터베이스에 이름이 부여된 인스턴스 추가
  # srvctl add instance -d ORACLE -i TEST01 -n myclust-1
  # srvctl add instance -d ORACLE -i TEST02 -n myclust-2
  # srvctl add instance -d ORACLE -i TEST03 -n myclust-3
- 서비스를 이미 존재하는 데이터베이스에 추가하며, 선호되는 인스턴스를 지정(-r) 로 하고
  가용한 인스턴스를 지정함(-a)
  기론 failover 를 사용함
  # srvctl add service -d ORACLE -s STD_BATCH -r TEST01, TEST02 -a TEST03, RAC04

=> CRS자원의 제거

- 데이터베이스에 대한 Application 제거
  # srvctl remove database -d ORACLE
- 이미 존재하는 데이터베이스의 이름이 부여된 인스턴스에 대한 Application 제거
  # srvctl remove instance -d ORACLE -i TEST03
  # srvctl remove instance -d ORACLE -i RAC04
- 서비스 제거
  # srvctl remove service -d ORACLE -s STD_BATCH
- 인스턴스로 부터 서비스 제거
  # srvctl remove service -d ORACLE -s STD_BATCH -i TEST03, RAC04
- Node로 부터 모든 Node Application 제거
  # srvctl remove nodeapps -n myclust 

=> CRS자원의 변경
- 인스턴스가 다른 Node 에서 실행되도록 변경
  # srvctl modify instance -d ORACLE -n myclust
- 서비스가 다른 Node에서 실행되도록 변경
  # srvctl modify service -d ORACLE -s HOT_BATCH -i TEST01 -t TEST02
- 인스턴스가 서비스의 선호되는 인스턴스가 되도록 변경
  # srvctl modify service -d ORACLE -s HOT_BATCH -i TEST02

=> Service 의 재배치

- 서비스를 한 인스턴스에서 다른 인스턴스로 재배치
  # srvctl relocate service -d ORACLE -s CRM -i RAC04 -t TEST01


=> CRS자원의 활성화

- 데이터베이스를 활성화
  # srvctl enable database -d ORACLE
- 이름이 부여된 인스턴스의 활성화
  # srvctl enable instance -d ORACLE -i TEST01, TEST02
- 서비스의 활성화
  # srvctl enable service -d ORACLE -s ERP,CRM
- 이름이 부여된 인스턴스에서 서비스의 활성화
  # srvctl enable service -d ORACLE -s CRM -i TEST03

=> CRS자원의 비활성화

- 데이터베이스를 전역(global) 비활성화
  # srvctl disable database -d ORACLE
- 이름이 부여된 인스턴스의 비활성화
  # srvctl disable instance -d ORACLE -i TEST01, TEST02
- 서비스를 전역(global) 비활성화
  # srvctl disable service -d ORACLE -s ERP, CRM
- 이름이 부여된 인스턴스상의 서비스를 비활성화
  # srvctl disable service -d ORACLE -s CRM -i TEST03, RAC04

3. RAC 진단 및 모니터링
1) RAC 진단이란
2) 통계치를 이용한 분석
=> 통계치를 이용한 분석이란
  - 오라클의 통계정보를 이용하여 진단하는 방법
  - 오라클은 내부적인 통계정보를 자동으로 생성하게 됨
  - 통계치
    : 데이터베이스가 운영되는 동안에 여러가지 중요한 값을 저장, 기록한것
    : InterConnect에 대한 정보 포함
  - Metric
    : Metric 에는 적절한 기준값이 있어서 진단 중인 시스템의 Metric값에 따라 기준에 적합한지
      확인하여 시스템의 안정성을 점검하게 됨

=> AVG CR BLOCK RECEIVE TIME
- AVG CR BLOCK RECEIVE TIME이란 한 NODE에서 다른 NODE로 부터 무결성 읽기를 하기
  위해 블럭을 받기 까지의 응답시간을 의미하는데, 보통의 경우 15ms 이하의값이 나와야 함
- 만약 스크립트 수행결과가 15ms보다 높은 값이 나온다면 CPU의 용량이 부족하거나
  Long-runnig SQL 이 수행되고 있음을 알 수 있음
  select b1.inst_id,
            b2.value "CR BLOCKS RECEIVED"  ,
            b1.value "CR BLOCKS RECEIVE TIME" ,
            ((b1.value/b2.value)*10) "AVG CR BLOCK RECEIVE TIME(ms)"
  from gv$sysstat b1, gv$sysstat b2
  where b1.name = 'global cache cr block receive time'
  and b2.name = 'global cache cr blocks received'
  and b1.inst_id = b2.inst_id;
- Long-runnig SQL은 많은 데이터 블럭들을 NODE간에 주고받게 되므로 InterConnect에 부하를
  가중하여 시간이 길어지게 됨

=> global cache lock performance
- global cache lock performance 란 RAC의 캐시에 대한 LOCK을 회기득할 때의 응답시간을
  의미하며, 20~30ms 이하의 값을 가져야 함
- 만약 이값이 20~30ms 보다 크다면 시스템 전체의 대기 이벤트 중 상위 10위에는
  'WATING SESSIONS', 'PCM LOCK BLOCKERS', 'PCM LOCK WAITERS' 이 있을것임
- 따라서 Application 파티셔닝을 해야함
  select b1.inst_id,
            (b1.value + b2.value) "GLOBAL LOCK GETS",
            b3.value "GLOBAL LOCK GET TIME",
            (b3.value / (b1.value +b2.value)*10) "AVG GLOBAL LOCK GET TIME(ms)"
  from gv$sysstat b1, gv$sysstat b2, gv$sysstat b3
  where b1.name = 'global lock sync gets'
  and b2.name = 'global lock async gets'
  and b3.name = 'global lock get time'

3) RAC에 관련된 대기정보를 이용한 분석
=> RAC에 관련된 대기정보를 이용한 분석
- 시스템의 상태와 Waiting 을 이용한 분석
- v$session_wait이나 v$system_wait 의 대기 이벤트를 이용하여 문제되는 부분을 중점적으로
  찾아 진단하는 방법
- RAC에 관련되는 대기 이벤트 : 'global cache cr requests', 'buffer busy global CR',
  'gets inquiry response'

=> 시스템 내에 현재 어떤 대기 이벤트가 있는가를 확인하는 방법
select sw.inst_id, sw.sid, sw.state, sw.event. sw.seconds_in_wait seconds, sw.p1,
        sw.p2, sw.p3, sa.sql_text last sql
from gv$session_wait sw, gv$session s, gv$sqlarea sa
where sw.event no in('rdbms ipc message','smon timer','pmon timer',
                                'SQL*Net message from client','lock manager wait for remote message',
                                'get remote message','gcs remote message','gcs for action',
                                'client message','pipe get','Null event','PX Idle Wait',
                                'single-task message','PX Deq:Execution Msg',
                                'KXFQ:kxfqdep - normal deqeue','listen endpoint status',
                                'slave wait','wakeup time manager' )

and seconds_in_wait > -
and (sw.inst_id = s.inst_id and sw.sid = s.sid)
and (s.inst_id = sa.inst_id and s.sql_address = sa.address)
order by seconds desc;

4) 오브젝트의 핑 정보를 이용한 분석

v$lock_activity 를 1분의 시간차를 두어 조회한 후
그 값들의 차이가 5000 이상이면 핑이 많이 발생한다고 볼수 있다


[출처] [오라클10g] RAC구성 및 관리|작성자 사무엘