• 1
  
• -> 여러대에 DB에 각 서버에서 발생한 트랜잭션데이터를 상호복제 -> 실시간 동기화시 부하 발생으로 분산효가가 힘듬
• 2
• -> 업무영역별로 DB를 따로 두고 Remote 쿼리를 이용회 조회 -> 분산 쿼리로 자주 액세스 되는 공통역의 범위에 따라 성능 좌우
• 3
• -> 같은 테이블 구조를 사용하면서 자료의 영역 (ex. 중고 수험정보 관리할때 시도별로 서버를 각각 두고 사용)
  -> 분할된 데이터간 의존성이 늦을때 성공적인 모델이지만 서버간 데이터이동시 처리 방안필요

• 공유 디스크 (Shared Disk)방식의 데이터베이스 클러스터링 기법이 도입
• 데이터 베이스를 하나로 통합하고 액세스하는 인스턴스를 여러개 둠
• 오라클 RAC는 공유디스크에 인스턴스간의 버퍼 캐시까지 공유하는 캐시 퓨전 기술로 발전
  

오라클 RAC

• 장점
• 고가용성, 확장성 , 부하 분삭 측면에서 성공적인 모델
• 데이터를 하나의 데이터베이스에 통합 모델로 관리함으로써 높은 정합성 유지
• 단점
• 튜닝이 잘되지 않아 많은 블록 I/O를 발생시키는 AP의 경우 단일 인스턴스보다 심각한 성능저하 현상 발생
• 여러 인스턴스에 놓인 프로세스까리 하나의 데이터를 동시에 읽고 쓰려는 경합이 심하게 발생
• 동시 액세스를 직렬화 하려면 추가적인 동기화 메커니즘 필요

캐시 퓨전 프로세싱 원리

• 글로벌 캐시(Global Cache)
• 클러스터링 돼 있는 모든 인스턴스 노드의 버퍼 캐시를 하나의 버퍼 캐시로 간주
• 필요한 데이터 블록이 Local Cahce에 없고 다른 노드의 캐시오대 있으면 그것을 가져와서 읽고 씀

• 모든 데이터 블록에 대해 마스터 노드가 정해져 있음
• 마스터 노드를 통해 글로벌 캐시에 캐싱돼 있는 블록의 상태와 Lock정보를 관리
• 마스터 노드는 각 블록 주소(DBA)의 해시 값에 의해 인스턴스가 기동되는 시점에 동적으로 정해짐

• 캐시 퓨전
• 로컬 캐시에 업을때 마스터 노드에 전송요청
• 마스터 노드는 해당 블록을 캐싱하고 있는 노드에 블록 요청 노드에 전손하도록 지시
• 어느 노드에도 캐싱돼 있지 않으면 직접 디스크에서 읽도록 권한 부여

• Current 블록
• 디스크로 부터 읽혀진 후 사용자의 갱신 사항이 반영된 최종 상태의 원본 블록
• CR 블록
• Current 블록에 대한 복사본, 여러개 존재가능, Current 블록은 오직 한개

•  RAC 환경에서 Current 블록
• Shared 모드 Current (SCur)
• Exclusive 모드 Current (XCur)
• SCur 상태의 블록은 동시에 여러 노드에 캐싱 가능
• XCur 상태의 블록은 단 하나의 노드에만 존재
• 자주 읽히는 데이터블록은각 노드가 SCur 모드로 캐싱하고 있을때 가장 효율적인 상태
• Xcur모드로 한노드가 업그래드 요청시 다른 노드의 Scur블록은 모두 Null모드로 다운그레이드
  -> PI (Pase Image) 블록 (사용불가능)

• RAC 노드간 버퍼 캐시를 공유하면서 블록을 주고 받는 전송 메커니즘
• 전송 없는 읽기:  Read with No Transfer
• 읽기/읽기 전송: Read to Read Transfer
• 읽기/쓰기 전송: Read to Write Transfer
• 쓰기/쓰기 전송: Write to Write Transfer
• 쓰기/읽기 전송: Write to Read Transfer

(1) 전송 없는 읽기 :Read with No Transfer

Instance A에서 K블록을 읽으려고 할때 어떤노드에도 캐싱돼 있지 않음
K블록의 SCN: 123

1. Instance A는 K블록의 Resource Master인 Instance B에 전송 요청 , gc cr request 이벤트에서 대기
2. B 는 어떤 Instance도 K블록을 캐싱하지 있지 않음을 확인하고 A에게 SCur 모드로 읽을수 있도록 권한 부여
3. A는 디스크에서 블록을 읽어 로컬 캐시에 캐싱

(2) 읽기/읽기 전송: Read to Read Transfer

A 가 K블록을 SCur 모드로 캐싱, C 가 K블록을 SCur모드로 읽기

1. C는 B에게 K블록 전송요청, gc cr request 이벤트 대기
2. B는 현재 K 블록을 A가 캐싱확인 A에게 C에게 블록 전송 지시
3. A는 C에게 블록전송
4. C는 블록을 전송받아 SCur모드로 캐싱, 마스터노드인 B에게 메시지 전송

(3) 읽기/쓰기 전송: Read to Write Transfer

A와 C모두 K블록을 SCur 모드로 캐싱, C가 K블록을 XCur모드로 업그레이드, 블록갱신
1. B에가 K블록을 XCur모드로 업그레이드 요청
2. B는 현재 K블를 A도 캐싱 확인, Null모드로 다운그레이드 지시
3. A는 C에게 Null 로 다운그레이드 확인
4. C는 K블록을 XCur모드로 업그레이드하고 결과를 마스터노드인 B에게  확인,
  A의 블록이 Nul 모드로 다운그레이드 사실까지 통보

C노드가 XCur 모드로 K블록을 얻고 변경했으므로 SCN이 123에서 154로 증가

(4) 쓰기/쓰기 전송 : Write to Write Transfer

A 는 K 블록을 Null모드, C 는 Xcur 모드
C노드 Current SCN 154, 데이터파일의 블록 SCN 은 123으로 Dirty 버퍼 상태
A 가 K 블록을 XCur로 읽음(갱신)

1. 마스터인 B에게 K블록을 XCur모드로 요청
2. B는 블록 K 를 C 가 XCur 모드로 캐싱 확인, A 노드에게 전송 지시
3. C는 A 에게 블록전송 , 자신의 블록은 Null 모드로 다운그레이드,
C가 갖고 있던 XCur 블록을 아직 커밋되지 않아 로우 Lock이 걸린 상태일수 있음
4. A는 K블록을 Xcur모드로 캐싱했음을 B에게 통보

• 다른 인스턴스가 갱신중인 블록을 읽고자 할때 로우 Lock이 해제될때 까지 기다기 않고
  로우 Lock이 설정된채 블록을 주고 받음
• A가 XCur모드로 K블록을 얻고 변경했으므로 블록 SCN은 154에서 168로 증가

(5) 쓰기/읽기 전송: Write to Read Transfer

A가 K블록을 XCur 모드로 보유, C는 Null모드, A노드 SCN 은 168, 데이터파일의 블록 SCn 123, Dirty 버퍼 상태
C가 K블록을 SCur모드로 읽음

1. B에가 K블록을 SCur모드로 요청
2. B는 K블록을 A가 XCur모드로 캐싱 확인 C에게 전송지시
3. A는 C에게 전송, Scur모드로 다운그레이드
4. C는 K블록을 SCur모드로 캐싱함을 B에게 확인, A에 캐싱되 있던 블록이 SCur모드로 다운그레이드 된 사실까지 함께 통보

• K블록이 커밋 되지 않았다면 Current 블록을 전송하지 않고 CR Copy를 만들어서 전송
• C는 읽기를 원하므로 Current를 보낼필요 없음 ,A에서 갱신진행중

• K 블록이 커밋된경우도 최초 CR Copy만 전송하다가 일정 횟수 이상 요청이 반복적으로 들어오면 Current 블록 전송, 즉각 Current 블록 전송할경우 다시 갱신이 시작되면 여러노드에서 Null 모드 다운그레이드가 발생하여 부하 발생 가능성의 최소화

• CR Copy 횟수
  
• _fairness_threshold 파라미터, default 4
• 커밋된 XCur 블록을 보유하고 있는 노드는 블록 전송 요청시마다 CR Copy를 전송하고 값을 1씩 증가,
  값이 4에 도달하면 Redo 로그 버퍼를 비우고 XCur을 Scur로 다운그레이드
• 읽기가 주 작업이라면  _fairness_threshold 파라미터를 낮게 설정하는게 좋음
• 0 으로 설정하면 CR Copt 전송 없이 SCur 모드로 다운그레이드 하고 Current 블록 전송

• 다운그레이드 Ratio가 높다면 Current 모드로 공유할 수 밖에 없음에도 CR을 만들어 보내주므로 시스템에 부하가 많음을 의미

select data_requests, fairness_down_converts, round(fairness_down_converts / decode(data_requests,0,1,data_requests) * 100) "DOWNGRADE RATIO (%) "
from v$cr_block_server

• RAC구성시 데이터 가공 instance와 읽기 instance를 분리하는것은 성능에 좋지 않음

• dynamic remastering
• 리소스 친화도에 따라 마스터 노드가 동적으로 변함
• A Instance가 ownershop이라도 B Instance가 반복적으로 요청하면 마스터가 B로  변경
• 블록 읽기 요청 횟수가 많으면 디스크 I/O 관련 이벤트가 증가하는 만큼 rac 관련 이벤트도 증가
• 블록 읽기 요청 횟수를 줄여 인터커넥트를 통한 데이터 전송량을 감소시키는 것이 근본적 해결

d