Oracle 데이터베이스 아키텍처에 대한 자세한 그래픽 설명

이 기사에서는 Oracle에 대한 관련 지식을 제공하며, 주로 데이터베이스 아키텍처와 관련된 문제를 소개합니다. Oracle DB 서버는 Oracle DB와 하나 이상의 데이터베이스 인스턴스로 구성됩니다. 인스턴스는 메모리 구조와 백엔드 프로세스 구성으로 구성됩니다. 모든 사람에게 도움이 되기를 바랍니다.

추천 튜토리얼: "Oracle Tutorial"

Overview

Oracle DB 서버는 Oracle DB와 하나 이상의 데이터베이스 인스턴스로 구성됩니다. 인스턴스는 메모리 구조와 백그라운드 프로세스로 구성됩니다. 인스턴스가 시작될 때마다 SGA(System Global Area)라는 공유 메모리 영역이 할당되고 백그라운드 프로세스가 시작됩니다.
데이터베이스에는 물리적 구조와 논리적 구조가 포함됩니다. 물리적 구조와 논리적 구조가 분리되어 있기 때문에 데이터의 물리적 저장을 관리할 때 논리적 저장 구조에 대한 접근은 영향을 받지 않습니다.

Oracle 인스턴스는 메모리 구조와 프로세스를 사용하여 데이터베이스를 관리하고 액세스합니다. 모든 메모리 구조는 데이터베이스 서버를 구성하는 컴퓨터의 기본 메모리에 존재합니다. 프로세스는 이러한 컴퓨터의 메모리에서 실행되는 작업입니다. 프로세스는 일련의 단계를 실행하는 운영 체제의 "제어 스레드" 또는 메커니즘으로 정의됩니다.

메모리 구조

Oracle 인스턴스에는 두 가지 관련 기본 메모리 구조가 있습니다.
1. SGA(시스템 전역 영역)
SGA 구성 요소라고 하는 공유 메모리 구조 그룹 이러한 구성 요소에는 Oracle DB 인스턴스 정보의 데이터와 제어가 포함됩니다. . SGA는 모든 서버와 백그라운드 프로세스에서 공유됩니다. SGA에 저장된 데이터의 예로는 캐시된 데이터 블록과 공유 SQL 영역이 있습니다.
SGA는 인스턴스의 데이터와 제어정보를 담고 있는 메모리 영역입니다. SGA에는 다음과 같은 데이터 구조가 포함되어 있습니다.
• 데이터베이스 버퍼 캐시: 데이터베이스에서 검색된 데이터 블록을 캐시하는 데 사용됩니다.
• 리두 로그 버퍼: 기록될 수 있을 때까지 인스턴스 복구에 사용되는 리두 정보를 캐시하는 데 사용됩니다. 디스크에 저장된 물리적 리두 로그 파일
• 공유 풀: 사용자 간에 공유할 수 있는 다양한 구조를 캐시하는 데 사용됩니다.
• 대규모 풀: 특정 대규모 프로세스(예: Oracle 백업 및 복구 작업) 및 I/O 서버에 사용됩니다. 프로세스는 대규모 메모리 할당의 선택적 영역을 제공합니다.
• Java 풀: JVM(Java Virtual Machine)의 모든 세션별 Java 코드 및 데이터에 사용됩니다.
• 스트림 풀: Oracle Streams에서 캡처 및 애플리케이션 작업에 필요한 정보를 저장하는 데 사용됩니다.

2 프로그램 글로벌 영역(PGA) )
서버 프로세스나 백그라운드 프로세스에 대한 데이터와 제어 정보를 담고 있는 메모리 영역입니다.
PGA는 서버 프로세스나 백그라운드 프로세스가 시작될 때 Oracle DB가 생성하는 비공유 메모리입니다. PGA에 대한 서버 프로세스 액세스는 상호 배타적입니다. 각 서버 프로세스와 백그라운드 프로세스에는 자체 PGA가 있습니다.
PGA(Program Global Area)는 각 서버 프로세스에 대한 데이터 및 제어 정보를 포함하는 메모리 영역입니다. Oracle 서버는 서비스 클라이언트 요청을 처리합니다. 각 서버 프로세스에는 서버 프로세스가 시작될 때 생성되는 자체 전용 PGA가 있습니다. PGA에 대한 액세스는 해당 서버 프로세스로 제한되며 해당 서버 프로세스를 대신하여 Oracle 코드로만 읽고 쓸 수 있습니다.

Oracle DB는 초기화 매개변수를 사용하여 메모리 구조를 생성하고 관리합니다. 메모리를 관리하는 가장 간단한 방법은 데이터베이스가 자동으로 메모리를 관리하고 최적화하도록 하는 것입니다. 이를 수행하려면(다음은 대부분의 플랫폼에서 작동함) 대상 메모리 크기 초기화 매개변수(MEMORY_TARGET)와 최대 메모리 크기 초기화 매개변수(MEMORY_MAX_TARGET)를 설정하기만 하면 됩니다.

데이터베이스 버퍼 캐시

데이터베이스 버퍼 캐시는 SGA의 일부이며 데이터 파일에서 읽은 데이터 블록의 복사본을 저장하는 데 사용됩니다. 인스턴스에 병렬로 연결된 모든 사용자는 데이터베이스 버퍼 캐시에 대한 액세스를 공유합니다.
Oracle DB 사용자 프로세스에 처음으로 특정 데이터 조각이 필요할 때 데이터베이스 버퍼 캐시에서 해당 데이터를 검색합니다.
프로세스가 캐시에서 데이터를 찾으면(캐시 적중이라고 함) 메모리에서 직접 데이터를 읽습니다. 프로세스가 캐시에서 데이터를 찾을 수 없는 경우(캐시 미스라고 함) 데이터에 액세스하기 전에 디스크에 있는 데이터 파일의 데이터 블록을 캐시의 버퍼에 복사해야 합니다. 캐시 적중 시 데이터에 액세스하는 것이 캐시 미스 시 데이터에 액세스하는 것보다 빠릅니다.
캐시의 버퍼는 LRU(최근 사용 횟수) 목록과 도크 계산 메커니즘의 조합을 사용하는 복잡한 알고리즘으로 관리됩니다.

Redo Log Buffer

리두 로그 버퍼는 데이터베이스 변경 사항에 대한 정보를 보유하는 SGA의 순환 버퍼입니다. 이 정보는 리두 항목에 저장됩니다. Redo 항목에는 DML, DDL 또는 내부 작업에 의해 데이터베이스에 적용된 변경 사항을 다시 작성(또는 다시 실행)하는 데 필요한 정보가 포함됩니다. 필요한 경우 데이터베이스 복구에 리두 항목이 사용됩니다.
서버 프로세스가 버퍼 캐시를 변경하면 시스템은 리두 항목을 생성하고 생성된 리두 항목을 SGA의 리두 로그 버퍼에 씁니다. Redo 항목은 버퍼에서 연속적인 순차 공간을 차지합니다. LGWR 백그라운드 프로세스는 디스크의 활성 리두 로그 파일(또는 파일 그룹)에 리두 로그 버퍼를 기록합니다.

Shared Pool

SGA의 공유 풀 부분에는 라이브러리 캐시, 데이터 사전 캐시, SQL 쿼리 결과 캐시, PL/SQL 함수 결과 캐시, 병렬 실행 메시지용 버퍼 및 제어 구조가 포함됩니다.
"데이터 사전"은 데이터베이스, 구조 및 사용자에 대한 참조 정보가 포함된 데이터베이스 테이블 및 뷰의 모음입니다. SQL 문을 구문 분석하는 동안 Oracle DB는 데이터 사전에 자주 액세스합니다. 이 액세스 작업은 Oracle DB의 지속적인 작동에 매우 중요합니다.
Oracle DB는 데이터 사전에 매우 자주 액세스하므로 사전 데이터를 저장하기 위해 메모리에 두 개의 특별한 위치가 지정됩니다.
"데이터 사전 캐시"라고 불리는 영역으로, 버퍼 형식이 아닌 행 형식으로 데이터를 저장하기 때문에 "행 캐시"라고도 합니다(버퍼는 완전한 데이터 블록을 저장하는 데 사용됩니다). 사전 데이터에 사용되는 또 다른 메모리 영역을 "라이브러리 캐시"라고 합니다. 모든 Oracle DB 사용자 프로세스는 데이터 사전 정보에 액세스하기 위해 이 두 캐시를 공유합니다.
Oracle DB는 공유 SQL 영역(PGA에 예약된 전용 SQL 영역 포함)을 사용하여 실행되는 각 SQL 문을 나타냅니다. Oracle DB는 두 명의 사용자가 동일한 SQL 문을 실행하는 경우를 인식하고 해당 사용자에 대해 공유 SQL 영역을 재사용합니다.
"공유 SQL 영역"에는 특정 SQL 문에 대한 구문 분석 트리와 실행 계획이 포함됩니다. Oracle DB는 여러 번 실행되는 SQL 문에 대해 공유 SQL 영역을 사용하여 메모리를 절약합니다. 많은 사용자가 동일한 애플리케이션을 실행하면 동일한 SQL 문이 여러 번 실행되는 경우가 많습니다.
새로운 SQL 문을 구문 분석할 때 Oracle DB는 공유 SQL 영역에 해당 문을 저장하기 위해 공유 풀에서 메모리를 할당합니다. 이 메모리의 크기는 문의 복잡성에 따라 달라집니다.
Oracle DB는 개별 SQL 문을 처리하는 것과 거의 동일한 방식으로 PL/SQL 프로그램 단위(프로시저, 함수, 패키지, 익명 블록 및 데이터 트리거)를 처리합니다. Oracle DB는 프로그램 단위를 구문 분석되고 컴파일된 형태로 저장하기 위해 공유 영역을 할당합니다. Oracle DB는 로컬 변수, 전역 변수, 패키지 변수("패키지 인스턴스화"라고도 함) 등 프로그램 단위가 실행되는 세션에 특정한 값을 저장하고 SQL 실행에 사용되는 버퍼를 저장하기 위해 전용 영역을 할당합니다. . 여러 사용자가 동일한 프로그램 단위를 실행하는 경우 모든 사용자는 동일한 공유 영역을 사용하지만 자신의 세션에 특정한 값을 보유하기 위해 자신의 전용 SQL 영역에 대한 별도의 복사본을 유지 관리합니다.
PL/SQL 프로그램 단위에 포함된 개별 SQL 문은 다른 SQL 문과 유사하게 처리됩니다.
PL/SQL 프로그램 단위에 있는 이러한 SQL 문의 원본에 관계없이 모두 공유 영역을 사용하여 구문 분석 표현을 보관하고 해당 문이 실행되는 각 세션에 대한 전용 영역을 사용합니다.
SQL 쿼리 결과 캐시와 PL/SQL 함수 결과 캐시는 Oracle Database 11g의 새로운 기능입니다.
동일한 인프라를 공유하고, 동일한 동적 성능(V$) 보기에 표시되며, 동일한 제공 패키지를 사용하여 관리됩니다.
쿼리 결과 및 쿼리 조각은 "SQL 쿼리 결과 캐시"의 메모리에 캐시될 수 있습니다. 이러한 방식으로 데이터베이스는 캐시된 결과를 사용하여 나중에 이러한 쿼리 및 쿼리 조각 실행에 응답할 수 있습니다. SQL 쿼리 결과 캐시에서 결과를 검색하는 것이 쿼리를 다시 실행하는 것보다 훨씬 빠르기 때문에 자주 실행되는 쿼리의 결과를 캐싱하면 해당 쿼리의 성능이 크게 향상될 수 있습니다.
이 함수는 계산에 대한 입력이 PL/SQL 함수에서 실행된 하나 이상의 매개변수화된 쿼리인 경우 계산 결과를 반환하는 데 사용되기도 합니다. 경우에 따라 이러한 쿼리는 함수가 호출되는 빈도에 비해 거의 변경되지 않는 데이터에 액세스합니다.
PL/SQL 함수의 소스 텍스트에 구문을 포함하여 함수 결과가 "PL/SQL 함수 결과 캐시"에 캐시되고 테이블 목록의 테이블에서 DML이 발견되면 캐시가 지워지도록 요청할 수 있습니다. (올바른 정확성을 보장하기 위해).

대형 풀

데이터베이스 관리자는 "대형 풀"이라는 선택적 메모리 영역을 구성하여 다음에 대한 대규모 메모리 할당을 제공할 수 있습니다.
• 공유 서버 세션 메모리 및 여러 데이터베이스와 상호 작용할 때 사용되는 Oracle)
• I/O 서버 프로세스
• Oracle DB 백업 및 복원 작업
Oracle DB는 공유 서버, Oracle XA 또는 병렬 쿼리 버퍼를 위해 대규모 풀에서 세션 메모리를 할당하여 공유 풀을 주로 사용할 수 있으며, 축소로 인한 성능 오버헤드를 방지할 수 있습니다. 공유 SQL 캐시.
또한 Oracle DB 백업 및 복원 작업, I/O 서버 프로세스 및 병렬 버퍼에 사용되는 메모리는 수백 KB의 버퍼에 할당됩니다. 대규모 풀은 공유 풀보다 대규모 메모리 요청을 더 잘 처리합니다.
대규모 풀에는 LRU 목록이 없습니다. 이는 공유 풀에서 할당된 다른 메모리와 동일한 LRU 목록을 사용하는 공유 풀의 예약된 공간과 다릅니다.

java pool과 stream pool

모든 세션별 Java 코드와 데이터를 JVM에 저장하는 서버 메모리는 Java Pool 메모리를 사용한다. Java 풀 메모리는 Oracle DB의 운영 모드에 따라 여러 가지 방법으로 사용될 수 있습니다.
Java 풀 지침 통계는 Java용 라이브러리 캐시 메모리에 대한 정보를 제공하고 Java 풀 크기의 변화가 구문 분석 속도에 미치는 영향을 예측합니다. Statistics_level이 TYPICAL 이상으로 설정되면 Java 풀 지침이 내부적으로 켜집니다. 이 통계는 가이드를 닫으면 재설정됩니다.
스트림 풀은 Oracle Streams에서만 사용됩니다. 스트림 풀은 버퍼링된 대기열 메시지를 저장하고 Oracle Streams 캡처 프로세스 및 애플리케이션 프로세스에 메모리를 제공합니다.
스트림 풀을 특별히 구성하지 않는 한 크기는 0부터 시작됩니다. Oracle Streams를 사용하는 경우 풀 크기는 필요에 따라 동적으로 커집니다.

프로그램 전역 영역(PGA)

프로그램 전역 영역(PGA)은 서버 프로세스에 대한 데이터 및 제어 정보가 포함된 전용 메모리 영역입니다. 각 서버 프로세스에는 자체 PGA가 있습니다. PGA는 해당 서버 프로세스에서만 액세스할 수 있으며 해당 서버 프로세스를 대신하여 작동하는 Oracle 코드만 PGA를 읽을 수 있습니다. 개발자 코드는 PGA에 액세스할 수 없습니다.
각 PGA에는 스택 공간이 있습니다. 전용 서버 환경에서는 데이터베이스 인스턴스에 연결하는 각 사용자마다 별도의 서버 프로세스가 있습니다. 이러한 유형의 연결을 위해 PGA에는 UGA(사용자 전역 영역)라는 메모리 하위 부분이 포함되어 있습니다. UGA는 다음 부분으로 구성됩니다.
• 커서에 대한 런타임 정보를 저장하는 데 사용되는 커서 영역
• 세션에 대한 제어 정보를 저장하는 데 사용되는 사용자 세션 데이터 저장소
• 다음을 포함하여 SQL 문을 처리하는 데 사용되는 SQL 작업 공간

• ORDER BY 및 GROUP BY와 같은 데이터를 정렬하는 기능에 사용되는 정렬 영역
• 테이블의 해시 조인을 수행하는 데 사용되는 해시 영역
• 데이터 웨어하우스에서 일반적으로 사용되는 비트맵 인덱스를 생성하는 데 사용되는 비트맵 생성 영역
• 비트맵 비트맵 인덱스 계획의 실행을 구문 분석하는 데 사용되는 병합 영역
  공유 서버 환경에서는 여러 클라이언트 사용자가 서버 프로세스를 공유합니다. 이 모드에서는 UGA가 SGA(공유 풀 또는 구성된 경우 대형 풀)로 이동되고 PGA에는 스택 공간만 포함됩니다.

프로세스 구조

Oracle DB 시스템의 프로세스는 크게 두 그룹으로 나뉩니다.
1. 애플리케이션 또는 Oracle 도구 코드를 실행하는 사용자 프로세스
Oracle DB 구성이 다르면 운영 체제에 따라 사용자 프로세스 구조가 다릅니다. 그리고 선택된 OracleDB 옵션. 연결된 사용자를 위한 코드는 전용 서버 또는 공유 서버로 구성할 수 있습니다.
• 전용 서버: 각 사용자에 대해 데이터베이스 애플리케이션을 실행하는 사용자 프로세스는 Oracle DB 서버 코드를 실행하는 전용 서버 프로세스에 의해 제공됩니다.
• 공유 서버: 연결마다 전용 서버 프로세스가 필요하지 않습니다. 디스패처는 여러 개의 수신 네트워크 세션 요청을 공유 서버 프로세스 풀로 보냅니다. 공유 서버 프로세스는 모든 클라이언트 요청을 서비스합니다.
2. Oracle DB 서버 코드를 실행하는 Oracle DB 프로세스(서버 프로세스 및 백그라운드 프로세스 포함)
2.1. 서버 프로세스
Oracle DB는 인스턴스에 연결된 사용자 프로세스의 요청을 처리하기 위해 서버 프로세스를 생성합니다. 사용자 프로세스는 Oracle DB에 연결하는 애플리케이션이나 도구를 나타냅니다. 이는 Oracle DB와 동일한 컴퓨터에 있을 수도 있고 Oracle DB에 액세스하기 위해 네트워크를 사용하는 원격 클라이언트에 있을 수도 있습니다. 사용자 프로세스는 먼저 전용 환경에서 서버 프로세스를 생성하는 리스너 프로세스와 통신합니다.
각 사용자의 애플리케이션을 나타내기 위해 생성된 서버 프로세스는 다음 중 하나 이상을 수행할 수 있습니다.
• 애플리케이션을 통해 발행된 SQL 문을 구문 분석하고 실행합니다.
• 디스크의 데이터 파일에서 SQL 문을 검색합니다. 필요한 데이터 블록을 SGA의 공유 데이터베이스 버퍼(이러한 데이터 블록이 현재 SGA에 없는 경우)
• 애플리케이션이 정보를 처리할 수 있도록 결과가 반환됩니다.

2.2, 백그라운드 프로세스
성능을 최대화하고 여러 사용자의 요구를 충족하려면 다중 프로세스 Oracle DB 시스템은 "백그라운드 프로세스"라고 불리는 여러 가지 추가 Oracle DB 프로세스를 사용합니다. Oracle DB 인스턴스에는 여러 백그라운드 프로세스가 있을 수 있습니다.
비RAC, 비ASM 환경의 일반적인 백그라운드 프로세스는 다음과 같습니다.
• 데이터베이스 쓰기 프로세스(DBWn)
• 로그 쓰기 프로세스(LGWR)
• 체크포인트 프로세스(CKPT)
• 시스템 모니터 프로세스(SMON)
• 프로세스 모니터 프로세스(PMON)
• 복구 프로세스(RECO)
• 작업 큐 코디네이터(CJQ0)
• 작업 슬레이브 프로세스(Jnnn)
• 아카이브 프로세스(ARCn)
• 큐 모니터 프로세스(QMNn)
고급 다른 배경이 있을 수 있음 구성 프로세스(예: RAC) 백그라운드 프로세스에 대한 자세한 내용은 V$BGPROCESS 보기를 참조하세요.
일부 백그라운드 프로세스는 인스턴스를 시작할 때 자동으로 생성되는 반면 다른 프로세스는 요청 시 생성됩니다.
다른 프로세스 구조는 단일 데이터베이스에만 국한되지 않지만 동일한 서버의 여러 데이터베이스 간에 공유될 수 있습니다. 그리드 인프라 프로세스와 네트워크 프로세스가 이 범주에 속합니다.
Linux 및 UNIX 시스템의 Oracle Grid 인프라 프로세스에는 다음이 포함됩니다.
• ohasd: Oracle Clusterware 프로세스 시작을 담당하는 Oracle 고가용성 서비스 데몬
• ocssd: 클러스터 동기화 서비스 데몬
• diskmon: HP 입력 및 모니터링을 담당하는 디스크 모니터링 데몬 Oracle Exadata Storage Server의 출력
• cssdagent: CSS 데몬 ocssd의 상태를 시작, 중지 및 확인
• oraagent: Oracle 특정 요구 사항 및 복잡한 리소스를 지원하도록 클러스터웨어 확장
• orarootagent: 전용 Oracle 에이전트 프로세스로 도움을 줄 수 있음 루트 사용자가 소유한 리소스(예: 네트워크)를 관리하세요

데이터베이스 쓰기 프로세스(DBWn)

데이터베이스 쓰기 프로세스(DBWn)는 버퍼의 내용을 데이터 파일에 쓸 수 있습니다. DBWn 프로세스는 데이터베이스 버퍼 캐시의 수정된 버퍼(회색 데이터 버퍼)를 디스크에 쓰는 작업을 담당합니다. 대부분의 시스템에서는 하나의 데이터베이스 쓰기 프로세스(DBW0)로 충분하지만 시스템에서 데이터를 자주 수정해야 하는 경우 쓰기 성능을 향상시키기 위해 추가 프로세스(DBW1~DBW9 및 DBWa~DBWz)를 구성할 수 있습니다. 이러한 추가 DBWn 프로세스는 단일 프로세서 시스템에서는 유용하지 않습니다.
데이터베이스 버퍼 캐시의 버퍼가 수정되면 시스템은 이를 그레이 데이터 버퍼로 표시하고 SCN 순서로 체크포인트 큐의 헤드에 추가합니다. 따라서 순서는 변경된 버퍼에 대한 리두 항목이 리두 로그에 기록되는 순서와 일치합니다. 버퍼 캐시의 여유 버퍼 수가 일부 내부 임계값(서버 프로세스가 여유 버퍼를 얻기 어렵다고 간주하는 지점) 아래로 떨어지면 DBWn은 자주 사용되지 않는 버퍼를 데이터 파일에 기록합니다. LRU 목록을 통해 프로세스는 필요에 따라 버퍼를 교체할 수 있습니다. DBWn은 또한 앞으로 이동하는 체크포인트를 보호하기 위해 체크포인트 큐의 끝 부분에서 쓰기를 수행합니다.
SGA에는 인스턴스 실패 시 복구가 시작되는 리두 스트림 위치의 리두 바이트 주소(RBA)를 보유하는 메모리 구조가 있습니다. 이 구조는 다시 실행에 대한 포인터 역할을 하며 3초마다 한 번씩 CKPT 프로세스에 의해 제어 파일에 기록됩니다. DBWn은 SCN 순서로 그레이 데이터 버퍼를 쓰고, SCN 순서로 redo를 수행하므로 DBWn이 LRUW 목록에서 그레이 데이터 버퍼를 쓸 때마다 SGA 메모리 구조에 있는 포인터도 앞으로 이동하여 인스턴스 복구를 용이하게 합니다. 필요한 경우) 대략적인 정확한 위치에서 읽기 다시 실행을 시작하고 불필요한 I/O를 피하십시오. 이를 "증분 체크포인트"라고 합니다.
참고: DBWn이 쓰기 작업을 수행할 수 있는 다른 상황이 있습니다(예: 테이블스페이스가 읽기 전용으로 설정되거나 오프라인이 되는 경우). 이러한 경우 해당 데이터 파일에만 속하는 그레이 데이터 버퍼가 데이터베이스에 기록되는 순서는 SCN 순서와 무관하므로 증분 체크포인트가 발생하지 않습니다.
LRU 알고리즘은 더 자주 액세스되는 블록을 버퍼 캐시에 유지하여 디스크 읽기를 최소화합니다. 테이블과 함께 CACHE 옵션을 사용하면 블록을 메모리에 더 오래 유지할 수 있습니다.
DB_WRITER_PROCESSES 초기화 매개변수는 DBWn 프로세스 수를 지정합니다. 최대 DBWn 프로세스 수는 36개입니다. 사용자가 시작 중에 이 프로세스 수를 지정하지 않으면 Oracle DB는 CPU 및 프로세서 그룹 수를 기반으로 DB_WRITER_PROCESSES를 설정하는 방법을 결정합니다.
DBWn 프로세스는 다음 조건에서 회색 데이터 버퍼를 디스크에 씁니다.
• 서버 프로세스가 임계값 수의 버퍼를 스캔한 후 재사용 가능한 깨끗한 버퍼를 찾을 수 없으면 DBWn에 쓰기 작업을 수행하라는 알림이 전달됩니다. DBWn은 다른 처리를 수행하는 동안 회색 데이터 버퍼를 디스크에 비동기적으로 씁니다.
• 체크포인트를 진행하기 위한 DBWn 쓰기 버퍼. 체크포인트는 인스턴스 복구를 수행하는 데 사용되는 리두 스레드(로그)의 시작 위치입니다. 로그 위치는 버퍼 캐시에서 가장 오래된 회색 데이터 버퍼에 의해 결정됩니다. 모든 경우에 DBWn은 효율성을 높이기 위해 일괄(다중 블록) 쓰기 작업을 수행합니다. 다중 블록 쓰기 작업에서 기록되는 블록 수는 운영 체제에 따라 다릅니다.

로그 쓰기 프로세스(LGWR)

로그 쓰기 프로세스(LGWR)는 리두 로그 버퍼 항목을 디스크의 리두 로그 파일에 기록하여 리두 로그 버퍼를 관리하는 역할을 담당합니다. LGWR은 마지막 쓰기 이후 버퍼에 복사된 모든 리두 항목을 씁니다.
리두 로그 버퍼는 순환 버퍼입니다. LGWR이 리두 로그 버퍼의 리두 항목을 리두 로그 파일에 기록한 후 서버 프로세스는 디스크에 기록된 항목 위에 새 항목을 리두 로그 버퍼에 복사할 수 있습니다. LGWR의 쓰기 속도는 일반적으로 리두 로그에 대한 액세스가 많을 때에도 버퍼에 새 항목을 위한 공간이 항상 남아 있도록 충분히 빠릅니다. LGWR은 버퍼의 연속 부분을 디스크에 씁니다.
LGWR은 다음과 같은 경우 쓰기 작업을 수행합니다.
• 사용자 프로세스가 트랜잭션을 커밋할 때
• 리두 로그 버퍼의 1/3이 가득 찼을 때
• DBWn 프로세스가 수정된 버퍼를 디스크에 쓸 때(필요한 경우)
• 매 3 초
버퍼 변경 사항과 관련된 모든 리두 레코드는 DBWn이 수정된 버퍼를 디스크에 쓰기 전에 디스크에 기록되어야 합니다(미리 쓰기 프로토콜). DBWn이 일부 리두 레코드가 아직 기록되지 않은 것을 발견하면 LGWR
에 이러한 리두 레코드를 디스크에 기록하고 데이터 버퍼에 쓰기 전에 LGWR이 리두 로그 버퍼의 쓰기 작업을 완료할 때까지 기다리도록 알립니다. LGWR은 현재 로그 그룹에 기록합니다. 그룹의 파일이 손상되거나 사용할 수 없게 되면 LGWR은 그룹의 다른 파일에 계속 쓰고 LGWR 추적 파일 및 시스템 경고 로그에 오류를 기록합니다. 그룹의 모든 파일이 손상되었거나 그룹이 보관되지 않아 사용할 수 없는 경우 LGWR은 계속 작동할 수 없습니다.
사용자가 COMMIT 문을 실행하면 LGWR은 리두 로그 버퍼에 커밋 레코드를 배치하고 트랜잭션의 리두 로그와 함께 해당 레코드를 즉시 디스크에 씁니다. 데이터 블록에 대한 해당 변경 사항은 보다 효율적으로 기록될 수 있을 때까지 지연됩니다. 이것을 "빠른 커밋 메커니즘"이라고 합니다. 트랜잭션 커밋 레코드가 포함된 리두 항목의 원자성 쓰기는 트랜잭션이 커밋되었는지 여부를 결정하는 단일 이벤트입니다.
Oracle DB는 데이터 버퍼가 아직 디스크에 기록되지 않은 경우에도 커밋된 트랜잭션에 대한 성공 코드를 반환합니다.
더 많은 버퍼 공간이 필요한 경우 LGWR은 때때로 트랜잭션을 커밋하기 전에 리두 로그 항목을 작성합니다. 이러한 항목은 트랜잭션이 나중에 커밋되는 경우에만 영구적이 됩니다. 사용자가 트랜잭션을 커밋하면 트랜잭션에 SCN(시스템 변경 번호)이 할당됩니다. 이 번호는 Oracle DB가 트랜잭션의 리두 항목과 함께 리두 로그에 기록합니다. SCN은 REDO 로그에 기록되므로 Real Application Clusters와 분산 데이터베이스 간에 복구 작업을 동기화할 수 있습니다.
활동이 높을 때 LGWR은 그룹 커밋을 사용하여 리두 로그 파일을 작성할 수 있습니다. 예를 들어, 사용자가 거래를 제출했다고 가정합니다. LGWR은 이 트랜잭션에 대한 리두 항목을 디스크에 기록해야 합니다. 이런 일이 발생하면 다른 사용자는 COMMIT 문을 발행하게 됩니다. 그러나 LGWR은 이전 쓰기 작업이 완료될 때까지 이러한 트랜잭션을 커밋하기 위해 리두 로그 파일에 쓸 수 없습니다. 첫 번째 트랜잭션의 항목이 리두 로그 파일에 기록된 후 보류 중인(아직 커밋되지 않은) 트랜잭션에 대한 리두 항목의 전체 목록이 단일 작업으로 디스크에 기록될 수 있으며 이는 개별 트랜잭션 항목을 개별적으로 처리하는 것보다 빠릅니다. O는 필수입니다. 결과적으로 Oracle DB는 디스크 I/O를 최소화하고 LGWR의 성능을 극대화할 수 있습니다. 커밋 요청 비율이 지속적으로 높으면 리두 로그 버퍼(LGWR에서 수행)의 각 쓰기 작업에 여러 커밋 레코드가 포함될 수 있습니다.

체크포인트 프로세스(CKPT)

"체크포인트"는 데이터베이스의 다시 실행 스레드에서 SCN(시스템 변경 번호)을 정의하는 데이터 구조입니다. 체크포인트는 제어 파일과 각 데이터 파일의 헤더에 기록됩니다. 이는 복구 작업의 중요한 요소입니다.
체크포인트가 발생하면 Oracle DB는 체크포인트의 세부 정보를 기록하기 위해 모든 데이터 파일의 헤더를 업데이트해야 합니다. 이는 CKPT 프로세스에 의해 수행됩니다. CKPT 프로세스는 디스크에 블록을 쓰지 않으며 해당 작업은 DBWn에 의해 수행됩니다. 파일 헤더에 기록된 SCN은 해당 SCN 이전의 데이터베이스 블록에 대한 모든 변경 사항이 디스크에 기록되도록 보장합니다.
Oracle Enterprise Manager의 SYSTEM_STATISTICS 모니터는 완료된 체크포인트 요청 수를 나타내는 DBWR 체크포인트 통계를 표시합니다.

시스템 모니터 프로세스(SMON)

시스템 모니터 프로세스(SMON)는 인스턴스가 시작될 때(필요한 경우) 복구를 수행합니다. SMON은 더 이상 사용하지 않는 임시 세그먼트를 정리하는 역할도 담당합니다. 파일 읽기 또는 오프라인 오류로 인해 인스턴스 복구 중에 종료된 트랜잭션을 건너뛰는 경우 SMON은 테이블스페이스 또는 파일이 다시 온라인 상태가 될 때 해당 트랜잭션을 재개합니다.
SMON에서는 해당 프로세스가 필요한지 주기적으로 확인하고 있습니다. 다른 프로세스도 SMON의 필요성을 감지하면 이를 호출할 수 있습니다.

프로세스 모니터 프로세스

프로세스 모니터 프로세스(PMON)는 사용자 프로세스가 실패할 때 프로세스 복구를 수행합니다. PMON은 데이터베이스 버퍼 캐시를 지우고 사용자 프로세스가 차지한 리소스를 해제하는 역할을 담당합니다. 예를 들어, PMON은 활성 트랜잭션 테이블의 상태를 재설정하고 잠금을 해제하며 활성 프로세스 목록에서 프로세스 ID를 제거합니다.
PMON은 정기적으로 디스패처 및 서버 프로세스의 상태를 확인하고 실행이 중지된 모든 디스패처 및 서버 프로세스를 다시 시작합니다(OracleDB에 의해 의도적으로 종료되지 않는 한). PMON은 또한 인스턴스 및 디스패처 프로세스에 대한 정보를 네트워크 리스너에 등록합니다.
SMON과 마찬가지로 PMON은 실행이 필요한지 주기적으로 확인하여 필요하다고 판단되면 다른 프로세스도 이를 호출할 수 있습니다.

Recoverer 프로세스

RECO(복구 프로세스)는 분산 트랜잭션 처리와 관련된 오류를 자동으로 해결하는 분산 데이터베이스 구성의 백그라운드 프로세스입니다. 인스턴스의 RECO 프로세스는 문제의 분산 트랜잭션 처리와 관련된 다른 데이터베이스에 자동으로 연결됩니다. RECO 프로세스는 관련된 데이터베이스 서버 간의 연결을 다시 설정하면 문제가 있는 모든 트랜잭션을 자동으로 해결하고 해결된 문제가 있는 트랜잭션에 해당하는 모든 트랜잭션을 각 데이터베이스의 보류 중인 트랜잭션 테이블에서 제거합니다.
RECO 프로세스가 원격 서버에 연결할 수 없는 경우 RECO는 일정 시간 후에 자동으로 다시 연결을 시도합니다. 그러나 RECO는 연결을 다시 시도하기 전에 점점 더 많은 시간(기하급수적으로)을 기다립니다.

아카이빙 프로세스(ARCn)

로그 전환이 발생한 후 아카이빙 프로세스(ARCn)는 리두 로그 파일을 지정된 저장 장치에 복사합니다. ARCn 프로세스는 데이터베이스가 ARCHIVELOG 모드이고 자동 보관이 활성화된 경우에만 존재합니다.
대량의 보관 작업 부하(예: 데이터 일괄 로드 중)가 예상되는 경우 LOG_ARCHIVE_MAX_PROCESSES 초기화 매개변수를 사용하여 최대 보관 프로세스 수를 늘릴 수 있습니다. ALTER SYSTEM 문은 이 매개변수의 값을 동적으로 변경하여 ARCn 프로세스 수를 늘리거나 줄일 수 있습니다.

Storage Structure

Oracle DB를 구성하는 파일은 다음과 같은 카테고리로 나눌 수 있습니다.
• 제어 파일: 데이터베이스 자체와 관련된 데이터, 즉 물리적인 데이터베이스 구조 정보를 담고 있습니다. 이러한 파일은 데이터베이스에 중요합니다. 이러한 파일이 없으면 데이터 파일을 열어 데이터베이스의 데이터에 액세스할 수 없습니다.
• 데이터 파일: 데이터베이스의 사용자 또는 애플리케이션 데이터와 메타데이터 및 데이터 사전이 포함됩니다.
• 온라인 리두 로그 파일: 데이터베이스의 인스턴스 복구에 사용됩니다. 데이터베이스 서버가 충돌했지만 데이터 파일이 손실되지 않은 경우 인스턴스는 이러한 파일의 정보를 사용하여 데이터베이스를 복구할 수 있습니다.
다음 추가 파일은 데이터베이스를 성공적으로 실행하는 데 매우 중요합니다.
• 매개변수 파일: 인스턴스가 시작될 때 구성을 정의하는 데 사용됩니다.
• 비밀번호 파일: sysdba, sysoper 및 sysasm이 인스턴스에 원격으로 연결하고 관리 작업을 수행할 수 있도록 합니다.
• 백업 파일: 데이터베이스 복구를 수행하는 데 사용됩니다. 백업 파일은 일반적으로 미디어 오류나 사용자 오류로 인해 원본 파일이 손상되거나 삭제된 경우 복원됩니다.
• 보관된 리두 로그 파일: 인스턴스에서 발생한 데이터 변경(리두)의 실시간 기록을 포함합니다. 이러한 파일 및 데이터베이스 백업을 사용하면 손실된 데이터 파일을 복구할 수 있습니다. 즉, 아카이브 로그는 복원된 데이터 파일을 복원할 수 있다.
• 추적 파일: 각 서버 및 백그라운드 프로세스는 관련 추적 파일에 쓸 수 있습니다. 프로세스가 내부 오류를 감지하면 프로세스는 오류에 대한 정보를 적절한 추적 파일에 덤프합니다. 추적 파일에 기록된 정보 중 일부는 데이터베이스 관리자에게 제공되고 다른 정보는 Oracle 지원 서비스에 제공됩니다.
• 경고 로그 파일: 이 파일에는 특별한 추적 항목이 포함되어 있습니다. 데이터베이스의 경고 로그는 메시지 로그와 오류 로그를 시간순으로 나열한 것입니다. 오라클에서는 경고 로그를 주기적으로 검토할 것을 권장합니다.

논리적 및 물리적 데이터베이스 구조

데이터베이스, 테이블스페이스 및 데이터 파일

이 슬라이드에서는 데이터베이스, 테이블스페이스 및 데이터 파일 간의 관계를 설명합니다. 각 데이터베이스는 논리적으로 두 개 이상의 테이블스페이스로 구분됩니다. 테이블스페이스의 모든 논리적 구조의 데이터를 물리적으로 저장하기 위해 각 테이블스페이스에 하나 이상의 데이터 파일이 명시적으로 생성됩니다. TEMPORARY 테이블스페이스의 경우 데이터 파일은 생성되지 않지만 임시
파일이 생성됩니다. 테이블스페이스 데이터 파일은 지원되는 모든 스토리지 기술을 사용하여 물리적으로 저장할 수 있습니다.

테이블스페이스

데이터베이스는 관련 논리적 구조 또는 데이터 파일을 그룹화하는 데 사용되는 "테이블스페이스"라는 여러 논리적 저장 단위로 구분됩니다. 예를 들어, 테이블스페이스는 일반적으로 일부 관리 작업을 단순화하기 위해 애플리케이션의 모든 세그먼트를 하나의 그룹으로 그룹화합니다.
데이터베이스는 관련 논리 구조를 함께 그룹화하는 데 사용할 수 있는 논리 저장 단위인 "테이블 공간"으로 구분됩니다. 각 데이터베이스는 논리적으로 두 개 이상의 테이블스페이스(SYSTEM 및 SYSAUX 테이블스페이스)로 구분됩니다. 테이블스페이스의 모든 논리적 구조의 데이터를 물리적으로 저장하기 위해 각 테이블스페이스에 하나 이상의 데이터 파일이 명시적으로 생성됩니다.
160KB 크기의 세그먼트는 두 개의 데이터 파일에 걸쳐 있으며 두 개의 익스텐트로 구성됩니다. 첫 번째 확장 영역은 첫 번째 데이터 파일에 있으며 크기는 64KB입니다. 두 번째 확장 영역은 두 번째 데이터 파일에 있고 크기가 96KB입니다. 두 익스텐트는 여러 개의 연속된 8Kb Oracle 블록으로 구성됩니다.
참고: 일반적으로 매우 큰 파일이 하나만 있는 대용량 파일 테이블스페이스를 생성할 수 있습니다. 파일은 행 ID 아키텍처에서 허용하는 최대 크기까지 가능합니다. 이 최대 크기는 테이블스페이스의 블록 크기에 236을 곱한 값이며, 블록 크기가 32KB인 경우 최대 크기는 128TB입니다. 기존의 작은 파일 테이블스페이스(기본값)는 여러 데이터 파일을 포함할 수 있지만 이러한 파일은 그다지 크지 않습니다.

데이터 블록

Oracle DB 데이터는 가장 낮은 수준의 세분성인 "데이터 블록"에 저장됩니다. 데이터 블록은 디스크의 특정 바이트 수의 물리적 공간에 해당합니다. 각 테이블스페이스의 데이터 블록 크기는 테이블스페이스 생성 시 지정됩니다. 데이터베이스는 Oracle 데이터 블록 단위로 여유 데이터베이스 공간을 사용하고 할당합니다.

District

논리적 데이터베이스 공간의 다음 수준은 "District"입니다. 익스텐트는 특정 유형의 정보를 저장하는 데 사용되는 특정 개수의 Oracle 데이터 연속 블록(단일 할당에서 얻음)입니다. 익스텐트 내의 Oracle 데이터 블록은 논리적으로 연속되어 있지만 물리적으로 디스크의 다른 위치에 분산될 수 있습니다(RAID 스트라이핑 및 파일 시스템 구현으로 인해 이 동작이 발생할 수 있음).

Segment

논리적인 데이터베이스 저장 영역의 상위 레벨을 "세그먼트"라고 합니다. 세그먼트는 특정 논리적 구조에 할당된 영역 집합입니다. 예:
• 데이터 세그먼트: 모든 비클러스터형, 비인덱스 구성 테이블에는 데이터 세그먼트가 있습니다. 단, 외부 테이블, 전역 임시 테이블, 분할된 테이블은 각각 ​​하나 이상의 부분으로 구성됩니다. 테이블의 모든 데이터는 해당 데이터 세그먼트의 범위에 저장됩니다. 분할된 테이블의 경우 각 파티션마다 하나의 데이터 세그먼트가 있습니다. 각 클러스터에는 데이터 세그먼트도 있습니다. 클러스터의 각 테이블에 대한 데이터는 클러스터의 데이터 세그먼트에 저장됩니다.
• 인덱스 세그먼트: 모든 인덱스에는 모든 데이터를 저장하는 인덱스 세그먼트가 있습니다. 분할된 인덱스의 경우 각 파티션마다 하나의 인덱스 세그먼트가 있습니다.
• Undo 세그먼트: 시스템은 각 데이터베이스 인스턴스에 대해 UNDO 테이블스페이스를 생성합니다. 이 테이블스페이스에는 복원 정보를 임시로 저장하는 데 사용되는 다수의 복원 세그먼트가 포함되어 있습니다. 복원 세그먼트의 정보는 데이터베이스 복구 중에 사용자 커밋되지 않은 트랜잭션을 롤백하기 위해 읽기 일관성이 있는 데이터베이스 정보를 생성하는 데 사용됩니다.
• 임시 세그먼트: SQL 문 실행을 완료하기 위해 임시 작업 영역이 필요한 경우 Oracle DB에서 임시 세그먼트를 생성합니다. 명령문 실행이 완료된 후 임시 세그먼트의 범위는 나중에 사용할 수 있도록 인스턴스로 반환됩니다. 각 사용자에 대해 기본 임시 테이블스페이스를 지정하거나 데이터베이스 범위 내에서 사용되는 기본 임시 테이블스페이스를 지정할 수 있습니다.
참고: 위에 나열되지 않은 다른 유형의 세그먼트도 있습니다. 또한 뷰, 패키지, 트리거 등 일부 스키마 객체는 데이터베이스 객체임에도 불구하고 세그먼트로 간주되지 않습니다. 세그먼트에는 별도의 디스크 공간 할당이 있습니다. 다른 개체는 시스템 메타데이터 세그먼트에 행으로 저장됩니다.
Oracle DB 서버는 동적으로 공간을 할당합니다. 세그먼트의 기존 확장 영역이 가득 찬 경우 추가 확장 영역이 추가됩니다. 익스텐트는 필요에 따라 할당되므로 세그먼트의 익스텐트는 디스크에서 인접할 수도 있고 인접하지 않을 수도 있으며 동일한 테이블스페이스에 속하는 다른 데이터 파일에서 나올 수도 있습니다.

자동 스토리지 관리

ASM(자동 스토리지 관리)은 Oracle DB 파일에 대한 파일 시스템 및 볼륨 관리자 수직 통합을 제공합니다. ASM은 단일 SMP(Symmetric Multiprocessing) 컴퓨터 또는 Oracle Real Application Clusters(RAC)를 지원하는 클러스터의 여러 노드를 관리할 수 있습니다.
ACFS(Oracle ASM Cluster File System)는 ASM의 기능을 확장하여 실행 파일, 보고서, BFILE, 비디오, 오디오 등 Oracle DB 외부의 애플리케이션 파일을 지원하는 확장 가능한 다중 플랫폼 파일 시스템 및 스토리지 관리 기술입니다. 텍스트, 이미지, 기타 범용 애플리케이션 파일 데이터입니다.
ASM은 사용 가능한 모든 리소스에 입출력(I/O) 로드를 분산시켜 I/O의 수동 최적화를 제거하고 성능을 최적화합니다. ASM은 DBA가 데이터베이스를 종료하지 않고도 데이터베이스 크기를 늘려 스토리지 할당을 조정할 수 있도록 함으로써 DBA가 동적 데이터베이스 환경을 관리하는 데 도움을 줍니다.
ASM은 내결함성을 제공하기 위해 중복된 데이터 복사본을 유지하거나 공급업체가 제공한 스토리지 메커니즘 위에 구축할 수 있습니다. 파일별로 수동으로 상호 작용하는 대신 각 데이터 유형에 필요한 안정성 및 성능 지표를 선택하여 데이터 관리를 수행합니다.
ASM 기능은 수동으로 수행되는 스토리지 작업을 자동화함으로써 DBA 시간을 절약하여 관리자가 더 많은 규모의 데이터베이스를 더 효율적으로 관리할 수 있는 능력을 향상시킵니다.

ASM은 기존 데이터베이스 기능을 방해하지 않습니다. 기존 데이터베이스는 평소대로 작동할 수 있습니다. 새 파일을 ASM 파일로 생성할 수 있으며, 기존 파일을 있는 그대로 관리하거나 ASM으로 마이그레이션할 수 있습니다.
위 다이어그램은 Oracle DB 데이터 파일과 ASM 스토리지 구성 요소 간의 관계를 보여줍니다. 까마귀 발 표시는 일대다 관계를 나타냅니다. Oracle DB 데이터 파일과 운영 체제의 파일 시스템에 저장된 파일 또는 ASM 파일 간에는 일대일 관계가 있습니다.
Oracle ASM 디스크 그룹은 논리 단위로 관리되는 하나 이상의 Oracle ASM 디스크 모음입니다. 디스크 그룹의 데이터 구조는 독립적이며 메타데이터 요구 사항을 위해 공간의 일부를 사용합니다. Oracle ASM 디스크는 Oracle ASM 디스크 그룹용으로 프로비전된 저장 장치이며 물리적 디스크, 파티션, 저장소 배열의 논리 장치 번호(LUN), 논리 볼륨(LV) 또는 네트워크에 연결된 파일일 수 있습니다. 각 ASM 디스크는 ASM이 할당할 수 있는 최소 연속 디스크 공간인 ASM 할당 단위(AU)의 수로 나뉩니다. ASM 디스크 그룹을 생성할 때 디스크 그룹의 호환성 수준에 따라 ASM 할당 단위 크기를 1, 2, 4, 8, 16, 32 또는 64MB로 설정할 수 있습니다. 하나 이상의 ASM 할당 단위가 ASM 영역을 형성합니다. Oracle ASM 영역은 Oracle ASM 파일의 내용을 저장하는 데 사용되는 원시 스토리지입니다. Oracle ASM 파일은 하나 이상의 파일 범위로 구성됩니다. 매우 큰 ASM 파일을 지원하기 위해 AU 크기의 1x, 4x 및 16x에 해당하는 가변 크기 익스텐트를 사용할 수 있습니다.

추천 튜토리얼: "

Oracle Video Tutorial"

위 내용은 Oracle 데이터베이스 아키텍처에 대한 자세한 그래픽 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!