Cache Fusion은 Oracle ® RAC(RealApplication Clusters)의 두 인스턴스 간의 블록 전송에 불과하며 RAC의 주요 기능이며 가장 중요한 기능입니다.
소개
Oracle RAC Cache Fusion의 Oracle에 따르면 RAC 클러스터의 각 "인스턴스에는 캐시 기능을 수행하는 자체 로컬 버퍼 캐시가 있습니다. 그러나 여러 사용자가 서로 다른 노드에 연결되어 있는 경우 [사용자는 종종] [다른] 인스턴스가 소유한 데이터 블록에 액세스하거나 잠글 필요가 있습니다.
“이러한 경우 [요청하는] 인스턴스는 해당 데이터 블록에 대한 보유 인스턴스를 요청하고 [인] 상호 연결 메커니즘을 통해 액세스합니다. 이 개념을 캐시 융합이라고 합니다. .”
단일 인스턴스
Cache Fusion을 살펴보기 전에 데이터 차단 요청이 발생할 때 non-RAC 데이터베이스가 어떻게 작동하는지 살펴보겠습니다.
다음은 단일 인스턴스의 4단계 트랜잭션 프로세스입니다(Gopi의 Cache Fusion 블로그 게시물에서 가져옴:
- 사용자가 최근에 수정된 블록을 읽으면 해당 블록에서 활성 트랜잭션을 찾을 수 있습니다.
- 사용자는 트랜잭션이 커밋되었는지 여부를 결정하기 위해 실행 취소 세그먼트 헤더를 읽어야 합니다.
- 트랜잭션이 커밋되지 않은 경우 프로세스는 블록의 데이터와 실행 취소 세그먼트에 저장된 데이터를 사용하여 버퍼 캐시에 블록의 일관된 읽기(CR) 버전을 생성합니다.
- 실행 취소 세그먼트에 트랜잭션이 커밋된 것으로 표시되면 프로세스는 블록을 다시 방문하여 블록을 정리하고 변경 사항에 대한 다시 실행을 생성해야 합니다.
이제 Cache Fusion이라고 하는 2개의 인스턴스 클러스터가 있는 RAC에서 동일한 시나리오를 살펴보겠습니다.
캐시 퓨전
Gopi는 계속해서 “RAC에는 [동일한 저장소(예:ASM)에 있는] 동일한 데이터베이스 파일에 액세스하는 [2] 이상의 인스턴스가 있습니다. 각 인스턴스에는 자체 SGA, 백그라운드 프로세스가 있습니다. 즉, 각 인스턴스에는 자체 버퍼 캐시(각 인스턴스에 로컬)가 있습니다. 이러한 버퍼 캐시는 인스턴스 수준에서 개별적으로 작동하고 데이터베이스 수준에서 함께 융합되어 단일 엔티티(글로벌 캐시)를 형성하여 그들 사이에서 데이터 블록을 공유합니다. 이것이 바로 캐시 융합입니다. . Cache Fusion은 고속 IPC 상호 연결을 사용하여 클러스터의 인스턴스 간에 데이터 블록의 캐시 간 전송을 제공합니다. 이 데이터 블록 배송은 디스크 I/O를 제거하고 읽기/쓰기 동시성을 최적화합니다.”
이러한 이해는 인스턴스 간의 블록 전송을 담당하는 글로벌 캐시 서비스(GCS)로 이어집니다.
다음은 Gopi의 게시물에 언급된 GCS 백그라운드 프로세스입니다.
- 글로벌 캐시 서비스 프로세스(LMSn)
- Global Enqueue Service Daemon(LMD)
Gopi는 계속해서 다음과 같이 말합니다. “이러한 백그라운드 프로세스에 앞서 [원문 그대로] Oracle이 데이터 블록을 처리하는 방법과 데이터 블록을 관리하는 방법을 살펴보겠습니다.
“오라클은 데이터 블록을 자원으로 취급합니다. 이러한 각 리소스는 데이터 무결성을 유지하기 위한 중요한 메커니즘인 무관한 모드로 유지될 수 있습니다. 이러한 모드는 리소스 보유자가 데이터를 수정하거나 데이터를 읽을 것인지에 따라 [세 가지] 유형으로 분류됩니다.”
Gopi는 다음과 같이 모드를 나열합니다.
- 널(N) 모드 :Null 모드는 일반적으로 자리 표시자로 유지됩니다.
- 공유(S) 모드 :이 모드에서 데이터 블록은 다른 세션에 의해 수정되지 않지만 동시 공유 액세스를 허용합니다.
- 독점(X) 모드 :이 레벨은 보유 프로세스에 독점 액세스 권한을 부여합니다. 다른 프로세스는 리소스에 쓸 수 없습니다. 일관된 읽기 블록이 있을 수 있습니다.
글로벌 캐시 서비스 데몬(LMSn)
인스턴스에서 요청이 있을 때 Gopi는 "GCS는 블록 복사본을 메모리에 유지하여 다른 인스턴스로 블록 배송을 구성합니다. 이러한 각 사본을 과거 이미지(PI)라고 합니다. [...] 더티 단계에서 블록이 요청된 횟수에 따라 데이터 블록의 [하나] 이상의 PI를 가질 수도 있습니다.”
참고: Gopi는 "데이터 블록을 읽으려면 일관된 상태에서 읽어야 합니다. 다른 사람이 변경한 내용을 읽을 수 없습니다."
글로벌 인큐 서비스 데몬(LMD)
Gopi는 다음과 같이 설명합니다. “GES(Globalenqueue Service)는 모든 Oracle 대기열 메커니즘의 상태를 추적합니다. GES는 사전 캐시 잠금, 라이브러리 캐시 잠금 및 트랜잭션에 대한 동시성 제어를 수행합니다. 둘 이상의 인스턴스에서 액세스하는 리소스에 대해 이 작업을 수행합니다. GES는 데이터 파일 및 제어 파일에 대한 액세스를 제어하지만 데이터 블록에 대한 액세스는 제어하지 않습니다. "
다음은 Gopi가 공유하는 GES 관리 리소스입니다.
- 트랜잭션 잠금 :트랜잭션이 변경(삽입, 업데이트 등)을 시작할 때 배타적 모드에서 획득됩니다. 잠금은 트랜잭션이 커밋되거나 롤백될 때까지 유지됩니다.
- 라이브러리 캐시 잠금 :SQL, DML, DDL, PL/SQL, Java 문을 구문 분석하거나 컴파일하는 동안 데이터베이스 개체(예:테이블, 뷰, 패키지, packagebody, [...] 등)가 참조되면 구문 분석 또는 명령문을 컴파일하면 올바른 모드에서 라이브러리 캐시 잠금이 획득됩니다.
- 사전 캐시 잠금 :클러스터 데이터베이스 모드에서 전역 대기열이 사용됩니다. 데이터 사전 구조는 클러스터 데이터베이스의 모든 Oracle 인스턴스에 대해 동일합니다.
- 테이블 잠금 :전체 테이블을 보호하는 GES 잠금입니다. 트랜잭션은 테이블이 수정될 때 테이블 잠금을 획득합니다. 테이블 잠금은 널(N), 행 공유(RS), 행 독점(RX), 공유 잠금(S), 공유 행 독점(SRX) 또는 독점(X)과 같은 여러 모드에서 유지될 수 있습니다.
과거 및 일관된 읽기 이미지
메인 시나리오로 넘어가기 전에 과거 이미지(PI)와 일관성 읽기(CR) 이미지를 이해해야 합니다.
과거 이미지
Rohit Gupta는 Oracle RAC Cache Fusion의 기사에서 "과거 이미지의 개념은 RAC 설정과 매우 관련이 있습니다. 업데이트를 위해 데이터 블록에 대한 배타적 잠금을 보유하는 인스턴스를 고려하십시오. RAC의 다른 인스턴스에 블록이 필요한 경우 Holdinginstance는 버퍼 캐시에 블록의 PI(과거 이미지)를 유지하여 블록을 디스크에 쓰는 대신 요청 인스턴스에 보낼 수 있습니다. 기본적으로 PI는 블록이 디스크에 기록되기 전의 데이터 블록의 복사본입니다.”
일관된 읽기 이미지:
Gupta는 계속해서 “특정 블록이 트랜잭션[A1]에 의해 액세스/수정되고 동시에 다른 트랜잭션[A2]이 블록에 액세스/읽기를 시도할 때 일관된 읽기가 필요합니다. [A1]이 커밋되지 않은 경우 [A2]는 계속 진행하기 위해 블록의 일관된 읽기 [(수정되지 않은 블록)] 복사본이 필요합니다. 해당 블록에 대한 UNDO 데이터를 사용하여 CR 사본이 생성됩니다.”
캐시 퓨전 시나리오
Cache Fusion에는 세 가지 시나리오가 있습니다.
- 읽기-읽기 시나리오
- 읽기-쓰기 시나리오
- 쓰기-쓰기 시나리오
읽기-읽기 시나리오:
차단을 요청하는 인스턴스와 요청을 차단하는 인스턴스가 모두 읽기 트랜잭션을 요청하기 때문에 이것은 중요하지 않은 시나리오입니다. 여기서는 배타적 잠금이 발생하지 않습니다. 인스턴스 B가 GCS에 읽기 블록을 요청합니다. GCS는 인스턴스 A가 소유한 블록의 가용성을 확인하고 공유 잠금을 획득합니다. 이제 GCS는 Instance Aship이 요청된 블록을 Instance B로 보내도록 요청합니다.
읽기-쓰기 시나리오:
이것은 중요한 시나리오입니다.
인스턴스 A는 데이터 블록을 업데이트 중이므로 배타적 잠금을 획득해야 합니다. 얼마 후 인스턴스 B는 동일한 데이터 블록에 대한 읽기 요청을 GCS로 보냅니다.
GCS는 인스턴스가 동일한 블록에 대해 배타적 잠금을 획득했는지 확인하고 찾습니다. 따라서 GCS는 인스턴스 A에게 블록을 해제하도록 요청합니다. 이제 인스턴스 A는 자체 버퍼 캐시에 CR 이미지를 생성하고 이에 따라 GCS에 통지하여 인스턴스 B로 전송합니다.
GCS는 CR 이미지 생성에 관여하고 Cache Fusion이 작동하는 요청된 인스턴스로 전달합니다.
쓰기-쓰기 시나리오
인스턴스 A와 인스턴스 B가 모두 데이터 블록에 대한 배타적 잠금을 얻으려고 합니다.
인스턴스 B는 GCS에 차단 요청을 보냅니다. GCS는 가용성을 확인하고 인스턴스 A가 잠금을 획득했는지 찾습니다. 따라서 GCS는 인스턴스 A에 인스턴스 B에 대한 블록을 해제하도록 요청합니다. 이제 인스턴스 A는 버퍼에 자체 현재 블록의 PI를 생성하고 다시 실행 항목을 만들고 GCS에 해당 블록을 인스턴스 B로 배송하도록 알립니다.
인스턴스 B는 이제 블록을 사용하고 평소와 같이 변경합니다.
CR과 PI의 주요 차이점
Gupta는 PI 대 CR 이미지에 대해 다음과 같은 최종 생각을 추가합니다. “[The] CR 이미지는 [a] 읽기-쓰기 유형의 경합을 피하기 위해 제공되었습니다. 요청 인스턴스가 쓰기 작업을 수행하기를 원하지 않기 때문에 블록에 대한 독점 잠금. 따라서 읽기 작업의 경우 블록의 CR 이미지로 충분합니다. 쓰기-쓰기 경합의 경우 요청하는 인스턴스도 데이터 블록에 대한 배타적 잠금을 획득해야 합니다. [To] 쓰기 작업에 대한 잠금을 획득하려면 CR 이미지가 아닌 실제 블록이 필요합니다. 따라서 보유 인스턴스는 실제 블록을 보내지만 블록이 디스크에 기록될 때까지 블록의 PI를 유지할 수 있습니다. 따라서 인스턴스 실패 또는 충돌이 있는 경우 Oracle은 RAC 인스턴스 전체에서 PIfrom을 사용하여 블록을 구축할 수 있습니다. 블록이 디스크에 기록되면 충돌 시 복구가 필요하지 않으므로 관련 PI를 삭제할 수 있습니다."
데이터 서비스에 대해 자세히 알아보세요.
피드백 탭을 사용하여 의견을 작성하거나 질문하십시오. 저희와 대화를 시작할 수도 있습니다.