Oracle12.2의 아키텍처 이해: 파일 시스템 및 멀티 테넌시
- WBOY앞으로
- 2024-01-29 10:39:111233검색
- RVWR: Recovery Writer 프로세스. 데이터베이스가 플래시백 영역을 설정할 때 프로세스는 정기적으로 메모리의 플래시백 데이터, 특히 공유 풀의 플래시백 버퍼를 플래시백 로그에 씁니다.
- 결과 캐시 –> RCBG:결과 캐시는 SQL 문이나 plsql 함수를 실행하는 동안 원래 데이터 작업의 결과를 저장하는 데 사용됩니다. 컴퓨팅 자원의 낭비를 피하기 위해 직접 획득합니다.
- ASH 버퍼 –>MMNL: ASH 버퍼는 SQL 실행 상태, 애플리케이션 연결 상태, 대기 이벤트 등 활성 세션의 통계 정보를 저장하는 데 사용됩니다. ASH 버퍼가 가득 차면 MMNL 프로세스는 버퍼의 데이터를 디스크에 쓰는 작업을 담당합니다.
- 인 메모리 실행 취소(IMU): 공유 풀에서 임시 실행 취소를 저장할 영역을 엽니다. 트랜잭션에서 여러 데이터 조각이 수정되면 버퍼 캐시의 실행 취소 데이터 블록은 더 이상 수정되지 않지만 IMU 녹화를 위해 노드가 추가됩니다. 주로 실행 취소로 인해 발생하는 다시 실행을 줄이기 위한 것입니다.
- Private Redo 로그 버퍼: 주로 IMU에서 생성된 임시 Redo를 관리하고, 트랜잭션의 Redo 정보를 공유 풀에 저장하며, Redo 로그 버퍼의 소비를 줄이는 데 사용됩니다.
- 플래시 캐시: 전체 이름은 데이터베이스 스마트 플래시 캐시입니다. 11.2에서 개발된 플래시 메모리 최적화 기술로, 기존의 느린 디스크 장치를 플래시 메모리로 대체하여 일부를 저장하는 것을 목표로 합니다. 데이터의 IOPS를 향상시키고 데이터베이스의 성능을 향상시키는 것이 목적입니다.
플래시 캐시는 다음과 같이 작동합니다:
Flash Cache에 저장된 콘텐츠는 두 가지 방법으로 제어됩니다.
1. Flash Cache의 지능형 선택 알고리즘: 데이터 블록과 인덱스 블록의 액세스 빈도를 평가하여 결정합니다.
2. 데이터베이스 개체의 cell_flash_cache 속성을 수정합니다.
Flash Cache 저장 콘텐츠의 기본 표준
주로 소규모 IO 작업과 데이터 블록, 인덱스 블록, 파일 헤더, 제어 파일 등이 캐시됩니다.
RMAN 백업 IO 작업, 데이터 펌프 IO 작업, ASM 미러링 작업 및 테이블 공간 포맷 등은 캐시되지 않습니다.전체 테이블 스캔에 대한 IO 작업의 캐시 우선순위는 상대적으로 낮습니다.
플래시 캐시에 데이터를 저장할 때 주로 쿼리 속도를 향상시키기 위한 것입니다. 즉, 메모리 외에 버퍼 캐시 영역의 일부를 추가하는 것과 같지만 성능이 더 좋고 속도도 더 좋습니다. 더 나은. 그러면 Buffer Cache와 마찬가지로 Flash Cache의 데이터가 가득 차거나 어느 정도 기록이 되었을 때 새로운 연산 데이터를 위한 공간을 확보하기 위해 해당 데이터를 디스크에 기록해야 합니다.
점유된 전체 캐시 크기의 백분율을 나타내는 캐시 플러시 시작 및 중지 수준 값을 구성할 수 있습니다. 디스크에 기록되지 않은 캐시의 데이터가 플러시 시작 값에 도달하면 컨트롤러는 플러시를 시작합니다(캐시에서 디스크로 기록). 캐시에 기록되지 않은 디스크 데이터의 양이 플러시 중지 값보다 낮으면 플러시 프로세스가 중지됩니다. 플러싱 시작 수준을 높게 설정하면 메모리에 기록되지 않은 데이터를 더 많이 캐시할 수 있습니다. 이는 쓰기 작업의 성능을 향상시키는 데 도움이 되지만 데이터 보호가 희생됩니다. 데이터를 보호하려면 더 낮은 시작 및 중지 값을 사용할 수 있습니다.
테스트 결과 닫기 시작 및 중지 세척 수준을 사용할 때 성능이 더 좋은 것으로 나타났습니다. 중지 레벨 값이 시작 값보다 훨씬 낮으면 플러싱 중에 디스크 정체가 발생합니다스마트 플래시 로깅 오랫동안 Redo 로그의 IO 병목 현상은 OLTP 시스템을 괴롭힌 주요 문제였습니다. Redo의 쓰기 지연이 전체 시스템은 물론 전체 클러스터의 응답 속도를 직접적으로 저하시키기 때문입니다.
기존 데이터베이스 아키텍처에서는 일부 DBA가 읽기 및 쓰기 지연 시간이 짧은 작은 블록 스토리지를 Redo에 별도로 할당합니다.
11204부터 Oracle은 플래시 메모리 영역에 Redo 전용 영역을 여는 새로운 솔루션을 제안했습니다. 임시 재실행.플래시 캐시에 열 저장소를 배치하여 자주 작동하는 열 저장소 개체에 대한 쓰기 IO를 개선합니다
- 변경 추적 파일:증분 백업에서 블록 변경 사항을 감지하고 이를 파일에 기록합니다. 녹음 단위가 블록입니다.
- wallet: Oracle Wallet은 키를 저장하는 데 사용되는 컨테이너입니다. 쉽게 말하면 비밀번호 상자입니다. 이 비밀번호 상자를 통해 원래 비밀번호를 입력해야 하는 상황에서 비밀번호를 입력하지 않고도 사용할 수 있어 계정 비밀번호 등 민감한 정보를 보호하고 보안을 강화하며 더욱 편리하게 사용할 수 있습니다. 사용.
애플리케이션 컨테이너는 12.2에서 제안된 새로운 구성 요소입니다. 동일한 애플리케이션에 속한 데이터베이스 시스템을 하위 컨테이너로 나누어 멀티 테넌트의 동일한 관리를 보장하는 동시에 상대적인 비즈니스 격리 및 데이터 보안을 달성합니다.
PDB에는 자체 실행 취소 테이블스페이스가 있습니다12.2부터 각 PDB에는 자체 실행 취소 테이블스페이스가 있습니다. 이는 여러 PDB 간의 경합을 제거하여 플래시백 또는 타임스탬프 기반 복구를 수행하려는 경우 자체 실행 취소 데이터만 검색하면 효율성이 향상됩니다.
PDB를 생성하는 유연한 방법1. PDB$seed(또는 애플리케이션 루트)에서 생성: 파일을 복사하여
2. 핫클론을 통해 기존 PDB가 생성됩니다
참고: 12.1에서는 PDB를 기반으로 새 PDB를 생성할 때 원본 라이브러리를 읽기 전용 모드로 열어야 합니다.
12.2에서는 원본 라이브러리가 영향을 받지 않고 계속해서 DML 작업을 수행할 수 있습니다.
복제가 완료되면 데이터가 새 데이터베이스에 지속적으로 새로 고쳐집니다.
3. 다른 CDB의 PDB에서 마이그레이션: 재배치
프런트 엔드는 재배치에서 플러그형 데이터베이스 생성과 같은 명령을 실행하고, 백그라운드는 자동으로 원격 핫 클론을 실행하고 원격 파일을 복사 및 동기화합니다.
4. ASM 디스크 파일의 섀도 복사본을 통해 새 PDB를 생성합니다.
PDB 메모리 리소스 관리
멀티 테넌트 환경에서는 여러 PDB가 메모리 리소스를 공유합니다. PDB가 버퍼 캐시를 처리해야 할 경우 전체 공유 리소스에서 검색해야 하는데 이는 매우 불편합니다. 12.2에서 Oracle은 일부 리소스에 대해 PDB 기반 도메인 분할을 구현했습니다.
12.1의 메모리 리소스 해시 목록은 다음과 같습니다.
12.2의 모습은 다음과 같습니다.
PDB의 더 많은 새로운 기능
1. 문자 집합: 12.2에서는 CDB의 문자 집합이 상위 집합, 즉 AL32UTF8인 경우 다른 문자 집합을 가진 PDB가 지원됩니다. 동시에 프록시 PDB를 통해 서로 다른 문자 집합을 가진 PDB를 쿼리할 수 있습니다. 프록시는 잘못된 문자 없이 두 당사자의 문자 집합을 식별하고 호환되도록 만듭니다.
멀티 테넌트 기술은 사용자들 사이에서 널리 사용되고 있으며, 데이터 서비스 업계의 선두주자인 Yunhe Enmo는 zData 솔루션과 Oracle 멀티 테넌트의 결합을 통해 사용자가 Internet+ 시대에 시스템 클라우드 전환을 달성할 수 있도록 지원해 왔습니다.
멀티 테넌시의 새로운 기능에 대한 자세한 설명은
를 참조하세요.
YH9: Oracle 다중 테넌트 기술 자료
멀티 테넌트 기술은 사용자가 널리 사용하고 있습니다. 데이터 서비스 업계의 선두주자인 Yunhe Enmo는 zData 솔루션과 Oracle 멀티 테넌트의 결합을 통해 사용자가 Internet+ 시대에 시스템의 클라우드 전환을 실현하도록 도왔습니다.
WeChat 공개 계정의 기사: 데이터 및 클라우드
위 내용은 Oracle12.2의 아키텍처 이해: 파일 시스템 및 멀티 테넌시의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!