[Oracle] Cache Fusion 이란? (RAC 구조/DB Buffer Cache와 관계)
일단, RAC의 구조를 알아야 Cache Fusion에 대해 설명할 수 있다.
cache fusion이라는 기능은 8i OPS에서 소개가 된 기능이지만, 제약 사항들이 있었고, 디스크 기반의 동기화를 사용했었다. 디스크를 거치지 않게 된 것은 Oracle 9i 버전부터이며 아래 그림은 Oracle 9i RAC 구조이다.
- public network(public 망) : ip 3개 중 관리자가 유지, 보수할 때 쓰는 것으로, public 망에 붙여 쓰는게 vip인데, service ip임.
- inter connect = private network(private 망): instance1과 instance2를 연결하는 망.
interconnect를 통해 이동하는 정보는 GCS(Global Enqueue service) /GES(Global Cache Service)관련 정보, 실제 데이터 블록, Parallel Query 관련 정보가 있다.
- Global Cache Service(GCS)
cache fusion 기능이 구현되기 위한 필수 서비스로서 어떤 사용자가 자신의 instance에서 원하는 데이터를 찾지 못해서 다른 instance에 있는 데이터를 요청했을때 interconnect를 통해서 데이터를 전달해주는 서비스입니다. (물리적으로 떨어져있는 각각의 instance이지만 마치 하나의 Database Buffer Cache인 것처럼 사용할 수 있는 서비스)
- Null(N) 모드: 해당 블록을 사용중인 사용자가 없다는 것을 뜻
- Share(S) 모드: 해당 블록을 select하고 있는 세션이 있다는 뜻(여러 instance에서 동시에 select할 수 있다)
- Exclusive(X) 모드: 해당 블록을 누군가가 변경하고 있다는 뜻(반드시 1개의 instance에서만 변경할 수 있다.)
RAC 구조에서 instance를 좀더 자세히 알아보자.
Cache Fusion과 DB Buffer Cache의 관계
DB Buffer cache는 유저가 요청한 SQL문을 수행하기 위해서 필요한 Data Block을 Disk로부터 메모리로 올리는 캐싱(Caching)을 하는 영역이다. 그때, Cache Fusion은 서로 다른 Instance의 DB Buffer Cache에서 Block을 이동시키는 부분에서 발생한다.
-Node는 하나의 DB에 연결된 server를 의미한다. 2 Node RAC는 2대의 물리적인 서버가 하나의 DB에 연결된 경우며, 하나의 Instance는 여러 Node에 중복 존재할 수 없지만 하나의 Node는 여러개의 Instance로 구성할 수 있다.
- 인스턴스는 반드시 하나의 SGA를 가진다.
Cache Fusion
Cache Fusion은 OPS의 Block Transformation의 문제를 극복하기 위해 나타난 아키텍쳐이며, 이를 통해 Oracle RAC은 성능적으로 안정성을 갖추게 되었다.
* OPS(Oracle Parallel Server) : 하나의 storage에 두 개의 instance가 연결되어 있는 구성으로, 사용자가 각각 다른 instance에 접속을 해도 storage가 하나이므로, 같은 데이터를 조회, 변경할 수 있다.
-두 노드 모두가 Active 상태로 동작하기에 이론적으로는 부하가 50%로 분산될 수 있고, 서비스 속도도 두 배 빨라질 수 있다.
-OPS의 경우에는 CTF나 TAF라는 설정이 되어있을 경우 기존 서버에 장애가 발생했을 경우 작업을 그대로 다른 서버로 이전시킬 수 있다.
-1개의 storage를 공유하므로 한 서버에서 변경된 작업을 다른 서버에서도 그대로 반영이 된다.
-OPS나 RAC은 이론적으로 서버수의 제한이 없어 확장이 가능함.
-Down Time을 획기적으로 줄일 수 있다.
-RAC Ping이라는 현상으로 심각한 성능저하가 발생함.
Cache Fusion 수행 방식
① Instance 2에 접속한 A 프로세스는 Instance 1에 존재하는 1번 Block을 액세스하기 위해 호출한다.
② Instance 1에 존재하는 1번 Block은 Instance 2의 호출에 응답하기 위해 Instance 2의 SGA의 DB Buffer Cache로 이동해야 한다. 이동을 위해 공유 Storage에 존재하는 DB를 이용하지 않고 Instance 사이의 Inter connect를 이용한다.
③ Interconnect를 이용하여 Instance 2로 캐싱된 1번 Block을 A 프로세스가 액세스할 수 있게 된다.
예를 들어보자.
instance1에서 A user가 홍길동을 강감찬으로 update 후 commit 수행한 후 B user가 원래 홍길동이었던 deptno=10번을 조회할 경우, instance1에서 변경된 데이터를 디스크를 거치지 않고 interconnect을 통해서 즉시 instance2로 전달된다. 그러면 RAC ping현상을 없앨 수 있다.
(1) 해당블록을 최초에 select 할 경우
- node1 사용자가 SCN1번인 홍길동 데이터가 들어있는 블록을 select한다.
- 가장 먼저 해당 블록의 master node인 node2번에 해당 블록의 상태를 문의한다.
- 요청을 받은 node2가 블록을 아무도 사용하지 않고 있으면, 해당 블록을 조회할 수 있는 S권한을 node1에게 허락.
- S권한을 받은 node1은 storage에 가서 해당 블록을 자신의 buffer cache로 복사한다.
(2) 다른 사용자가 동일 블록을 select할 경우
- node1에서 SCN1번인 홍길동 데이터의 블록이 위치해 있다.
- node3이 홍길동 데이터의 마스터노드인 node2에게 홍길동 데이터의 블록 상태를 확인.
- master node가 해당블록이 node1의 DB cache에 있다는 것을 알고 node1에게 블록을 node3에게 보낼 것을 지시.
- node1이 해당 블록을 interconnect를 통해 node3에게 전송 (Cache Fusion)
- 원하는 블록을 전송받은 node3이 해당 블록에 select할 수 있는 S권한을 master node로부터 할당받음.
(3) 기존 node에서 데이터의 변경이 발생
- 현재 node1과 node3에 동일한 scn을 가진 홍길동 데이터가 존재하는 상황이다.
- node3이 홍길동을 일지매로 update하기 위해 master node에게 X모드를 요청한다.
- X모드는 특징상 S모드와 동시에 사용될 수 없으므로, masternode는 S모드를 가지고 있는 node1에게 S모드를 N모드로 다운그레이드 하라고 지시.
- node1은 S모드를 N모드로 다운그레이드 한 후, 그 결과를 node3에게 알려줍니다.
- node3은 자신의 모드를 X모드로 변경하고 나서, node1이 N모드로 다운그레이드 되고, 자신이 X모드로 변경되었다는 내용을 Master node에게 홍보한다.
- 위 과정이 끝난 후 node3은 홍길동을 일지매로 업데이트 한다 →node3에는 일지매 데이터가 존재하고, node1과 storage에는 홍길동 데이터가 저장되어 잇는 상황이 된다.
(4) 새로운 node에서 데이터 변경이 발생하는 경우
- node4는 가장 최근 데이터인 강감찬 데이터를 소유하며, node3은 일지매 데이터, node1과 storage는 홍길동을 소유 중인 상태.
- node1에서 강감찬 데이터를 조회하기 위해, 자신이 가지고 있는 해당 블록의 모드를 본 후, N모드일 경우 master node에게 해당 블록에 대한 정보를 요청
- master node는 해당 블록의 최신 정보를 node4가 가진고 있다는 것을 알고 있으므로 node4에게 X모드를 S모드로 다운그레이드 한 후 해당 블록을 node1으로 전송하라고 요청하여 node4는 자신이 가지고 있던 해당 블록에 대한 X모드를 N모드로 변경
- node4가 해당 블록을 node1으로 전송
- node1이 자신이 가지고 있는 해당 블록에 대한 모드를 N모드에서 S모드로 업그레이드
- node1이 업그레이드한 내역을 master node에게 알림.
D.O.N.E!!!
