Reference : 11. Physical Storage Structures
*GPT 번역 기반으로 내용이 정확하지 않을 수 있습니다.
11장 물리적 저장 구조
Oracle 데이터베이스의 물리적 데이터베이스 구조는 운영 체제 수준에서 볼 수 있습니다.
이 장에서는 다음 섹션을 다룹니다:
- 물리적 저장 구조 소개
- 데이터 파일 개요
- 제어 파일 개요
- 온라인 리두 로그 개요
물리적 저장 구조 소개
RDBMS의 한 가지 특성은 테이블, 뷰, 인덱스와 같은 논리적 데이터 구조가 물리적 저장 구조와 독립적이라는 것입니다.
물리적 구조와 논리적 구조가 분리되어 있으므로 논리적 구조에 대한 접근에 영향을 주지 않고 데이터의 물리적 저장을 관리할 수 있습니다. 예를 들어 데이터베이스 파일 이름을 변경해도 그 안에 저장된 테이블의 이름은 변경되지 않습니다.
Oracle 데이터베이스는 Oracle 데이터가 영구 저장소에 저장되는 파일 세트입니다. 이 섹션에서는 CREATE DATABASE 명령을 실행할 때 생성되는 데이터베이스 파일에 대해 논의합니다:
데이터 파일 및 임시 파일
데이터 파일은 Oracle 데이터베이스에 의해 생성된 영구 저장소의 물리적 파일로, 테이블 및 인덱스와 같은 데이터 구조를 포함합니다. 임시 파일은 임시 테이블스페이스에 속하는 데이터 파일입니다. 데이터베이스는 이러한 파일에 Oracle 고유 형식으로 데이터를 씁니다. 이 형식은 다른 프로그램에서 읽을 수 없습니다.
제어 파일
제어 파일은 데이터베이스의 물리적 구성 요소를 추적하는 루트 파일입니다.
온라인 리두 로그 파일
온라인 리두 로그는 데이터에 대한 변경 사항을 기록한 파일 세트입니다.
데이터베이스 인스턴스는 데이터베이스 파일을 관리하는 메모리 구조 세트입니다. 다음 그림은 인스턴스와 그 인스턴스가 관리하는 파일 간의 관계를 보여줍니다.
그림 11-1 데이터베이스 인스턴스 및 데이터베이스 파일
그림 11-1 설명은 다음과 같습니다:
"그림 11-1 데이터베이스 인스턴스 및 데이터베이스 파일" 설명
참고 자료:
- 데이터베이스 생성 방법은 Oracle Database Administrator’s Guide를 참조하십시오.
- CREATE DATABASE 구문 및 문법은 Oracle Database SQL Language Reference를 참조하십시오.
데이터베이스 파일을 저장하는 메커니즘
이러한 파일의 저장 공간 할당 및 관리를 위한 여러 메커니즘이 있습니다.
가장 일반적인 메커니즘은 다음과 같습니다:
Oracle 자동 저장 관리(Oracle ASM)
Oracle ASM은 Oracle 데이터베이스 전용으로 설계된 파일 시스템을 포함합니다.
운영 체제 파일 시스템
대부분의 Oracle 데이터베이스는 파일 시스템에 파일을 저장합니다. 파일 시스템은 연속적인 디스크 주소 공간 내부에 구축된 데이터 구조입니다. 모든 운영 체제에는 파일 시스템 내에서 파일로 디스크 공간을 할당하고 할당 해제하는 파일 관리자가 있습니다.
파일 시스템은 디스크 공간을 여러 파일에 할당할 수 있습니다. 각 파일에는 이름이 있으며 Oracle 데이터베이스와 같은 애플리케이션에 연속적인 주소 공간으로 나타납니다. 데이터베이스는 파일을 생성, 읽기, 쓰기, 크기 조정 및 삭제할 수 있습니다.
파일 시스템은 일반적으로 논리적 볼륨 관리자(LVM)라는 소프트웨어 패키지에 의해 구성된 논리적 볼륨 위에 구축됩니다. LVM은 여러 물리적 디스크의 조각을 하나의 디스크로 나타나게 하는 연속적인 주소 공간으로 결합합니다.
클러스터 파일 시스템
클러스터 파일 시스템은 클라이언트에게 고성능 서비스를 제공하기 위해 협력하는 서버 클러스터로 구성된 분산 파일 시스템입니다. Oracle RAC 환경에서는 클러스터 파일 시스템이 공유 저장소를 클러스터된 여러 컴퓨터가 공유하는 파일 시스템으로 나타나게 합니다. 클러스터 파일 시스템에서는 클러스터 내 컴퓨터의 장애가 파일 시스템을 사용할 수 없게 만들지 않습니다. 그러나 운영 체제 파일 시스템에서는 NFS 또는 기타 수단을 통해 파일을 공유하는 컴퓨터가 장애를 일으키면 파일 시스템을 사용할 수 없게 됩니다.
데이터베이스는 앞서 언급한 여러 저장 메커니즘을 조합하여 사용합니다. 예를 들어, 데이터베이스는 제어 파일과 온라인 리두 로그 파일을 전통적인 파일 시스템에 저장하고 일부 사용자 데이터 파일은 원시 파티션에, 나머지 데이터 파일은 Oracle ASM에 저장하며 아카이브된 리두 로그 파일은 클러스터 파일 시스템에 저장할 수 있습니다.
참고 자료:
- "Oracle 자동 저장 관리(Oracle ASM)"
- Oracle Database 2 Day DBA는 Oracle Enterprise Manager Database Express(EM Express)를 사용하여 데이터베이스 저장 구조를 보는 방법을 배울 수 있습니다.
- 데이터베이스 뷰를 쿼리하여 데이터베이스 저장 구조를 보는 방법은 Oracle Database Administrator’s Guide를 참조하십시오.
Oracle 자동 저장 관리(Oracle ASM)
Oracle ASM은 Oracle 데이터베이스 파일을 위한 고성능, 관리 용이성의 저장 솔루션입니다. Oracle ASM은 볼륨 관리자 역할을 하며 데이터베이스 전용으로 설계된 파일 시스템을 제공합니다.
Oracle ASM은 다음과 같은 이점을 제공합니다:
- 데이터베이스 생성 및 레이아웃, 디스크 공간 관리와 같은 저장 관련 작업을 단순화합니다.
- 물리적 디스크 전반에 데이터를 분산하여 핫스팟을 제거하고 디스크 전반에 균일한 성능을 제공합니다.
- 저장 구성 변경 후 데이터를 자동으로 재조정합니다.
Oracle ASM을 사용하려면 스트라이핑 및 미러링에 대한 선호도로 파티션된 디스크를 Oracle 데이터베이스에 할당합니다. Oracle ASM은 디스크 공간을 관리하고 모든 사용 가능한 리소스에 I/O 부하를 분산하여 성능을 최적화하면서 수동 I/O 튜닝의 필요성을 제거합니다. 예를 들어, 데이터베이스의 디스크 크기를 늘리거나 데이터베이스의 일부를 새로운 장치로 이동할 때 데이터베이스를 종료할 필요가 없습니다.
Oracle ASM 저장 구성 요소
Oracle 데이터베이스는 Oracle ASM 디스크 그룹 내에서 Oracle ASM 파일로 데이터 파일을 저장할 수 있습니다. 디스크 그룹 내에서 Oracle ASM은 데이터베이스 파일에 대한 파일 시스템 인터페이스를 제공합니다.
다음 그림은 Oracle ASM을 사용하는 데이터베이스의 저장 구성 요소 간의 관계를 보여줍니다. 이 다이어그램은 Oracle ASM 파일과 데이터 파일 간의 관계를 나타내지만 Oracle ASM은 다른 유형의 파일도 저장할 수 있습니다. 갈매기발 기호는 일대다 관계를 나타냅니다.
그림 11-2 Oracle ASM 구성 요소
그림 11-2 설명은 다음과 같습니다:
"그림 11-2 Oracle ASM 구성 요소" 설명
그림 11-2는 다음과 같은 Oracle ASM 개념을 설명합니다:
Oracle ASM 디스크
Oracle ASM 디스크는 Oracle ASM 디스크 그룹에 할당된 저장 장치입니다. Oracle ASM 디스크는 물리적 디스크 또는 파티션, 스토리지 배열의 논리적 장치 번호(LUN), 논리적 볼륨 또는 네트워크 연결 파일일 수 있습니다.
Oracle ASM 디스크는 데이터베이스가 실행 중일 때 디스크 그룹에 추가하거나 제거할 수 있습니다. 디스크 그룹에 디스크를 추가할 때 디스크 이름을 지정하거나 디스크는 자동으로 Oracle ASM 디스크 이름을 부여받습니다.
Oracle ASM 디스크 그룹
Oracle ASM 디스크 그룹은 논리적 단위로 관리되는 Oracle ASM 디스크 모음입니다. 디스크 그룹의 데이터 구조는 자가 포함되어 있으며 디스크 그룹 내에서 일부 디스크 공간을 소비합니다.
디스크 그룹 내에서 Oracle ASM은 Oracle 데이터베이스 파일에 대한 파일 시스템 인터페이스를 제공합니다. 디스크 그룹에 저장된 파일의 내용은 핫스팟을 제거하고 디스크 전반에 균일한 성능을 제공하기 위해 고르게 분산(스트라이핑)됩니다.
Oracle ASM 파일
Oracle ASM 파일은 Oracle ASM 디스크 그룹에 저장된 파일입니다. Oracle 데이터베이스는 파일 단위로 Oracle ASM과 통신합니다. 데이터베이스는 데이터 파일, 제어 파일, 온라인 리두 로그 파일 및 다른 유형의 파일을 Oracle ASM 파일로 저장할 수 있습니다. 데이터베이스 요청 시 Oracle ASM은 Oracle ASM 파일을 생성하고 +DISK1과 같은 디스크 그룹 이름이 포함된 이름을 부여합니다.
참고: Oracle ASM 파일은 타사 파일 시스템과 같은 다른 저장 관리 옵션과 공존할 수 있습니다. 이 기능은 기존 환경에 Oracle ASM을 통합하는 것을 단순화합니다.
Oracle ASM 익스텐트
Oracle ASM 익스텐트는 Oracle ASM 파일의 섹션입니다. Oracle ASM 파일은 하나 이상의 파일 익스텐트로 구성됩니다. 각 Oracle ASM 익스텐트는 특정 디스크의 하나 이상의 할당 단위로 구성됩니다.
참고: Oracle ASM 익스텐트는 세그먼트에 데이터를 저장하는 데 사용되는 익스텐트와 다릅니다.
Oracle ASM 할당 단위
Oracle ASM 할당 단위는 디스크
그룹 내에서 할당의 기본 단위입니다. 할당 단위는 Oracle ASM이 할당하는 가장 작은 연속적인 디스크 공간입니다. 하나 이상의 할당 단위가 모여 Oracle ASM 익스텐트를 형성합니다.
참고 자료:
- Oracle 자동 저장 관리 관리자 가이드는 Oracle ASM에 대해 더 자세히 배우기 위한 자료입니다.
Oracle ASM 인스턴스
Oracle ASM 인스턴스는 Oracle ASM 디스크를 관리하는 특수한 Oracle 인스턴스입니다.
Oracle ASM 인스턴스와 데이터베이스 인스턴스는 모두 Oracle ASM 디스크 그룹의 디스크에 대한 공유 액세스가 필요합니다. Oracle ASM 인스턴스는 디스크 그룹의 메타데이터를 관리하고 데이터베이스 인스턴스에 파일 레이아웃 정보를 제공합니다. 데이터베이스 인스턴스는 Oracle ASM 인스턴스를 거치지 않고 Oracle ASM 디스크에 직접 I/O를 수행합니다.
Oracle ASM 인스턴스는 데이터베이스 인스턴스와 동일한 기술을 기반으로 구축되었습니다. 예를 들어, Oracle ASM 인스턴스는 시스템 글로벌 영역(SGA)과 데이터베이스 인스턴스와 유사한 백그라운드 프로세스를 가지고 있습니다. 그러나 Oracle ASM 인스턴스는 데이터베이스를 마운트할 수 없으며 데이터베이스 인스턴스보다 수행하는 작업이 적습니다.
그림 11-3은 하나의 Oracle ASM 인스턴스와 두 개의 데이터베이스 인스턴스가 있는 단일 노드 구성을 보여줍니다. 각 데이터베이스 인스턴스는 다른 단일 인스턴스 데이터베이스와 연관되어 있습니다. Oracle ASM 인스턴스는 메타데이터를 관리하고 두 데이터베이스의 데이터를 저장하는 Oracle ASM 파일에 대한 공간 할당을 제공합니다. 하나의 Oracle ASM 디스크 그룹에는 네 개의 Oracle ASM 디스크가 있고 다른 하나에는 두 개의 디스크가 있습니다. 두 데이터베이스 인스턴스는 디스크 그룹에 접근할 수 있습니다.
그림 11-3 Oracle ASM 인스턴스 및 데이터베이스 인스턴스
그림 11-3 설명은 다음과 같습니다:
"그림 11-3 Oracle ASM 인스턴스 및 데이터베이스 인스턴스" 설명
참고 자료:
- Oracle 자동 저장 관리 관리자 가이드는 Oracle ASM에 대해 더 자세히 배우기 위한 자료입니다.
Oracle 관리 파일 및 사용자 관리 파일
Oracle 관리 파일은 데이터베이스 객체를 파일 이름 대신 지정할 수 있는 파일 이름 지정 전략입니다. 예를 들어, 테이블스페이스를 생성할 때 데이터 파일의 이름을 지정하지 않아도 됩니다.
Oracle 관리 파일은 관리자에게 데이터베이스의 운영 체제 파일을 직접 관리할 필요성을 제거합니다. Oracle ASM은 Oracle 관리 파일을 필요로 합니다.
참고: 이 기능은 추적 파일, 감사 파일 및 경고 로그와 같은 관리 파일의 생성 또는 이름 지정에 영향을 미치지 않습니다.
사용자 관리 파일을 사용하면 데이터베이스의 운영 체제 파일을 직접 관리할 수 있습니다. 파일 구조 및 이름에 관한 결정을 직접 내립니다. 예를 들어, 테이블스페이스를 생성할 때 테이블스페이스 데이터 파일의 이름과 경로를 설정합니다.
초기화 매개 변수를 통해 특정 유형의 파일에 대한 파일 시스템 디렉토리를 지정합니다. Oracle 관리 파일 기능은 데이터베이스가 고유 파일을 생성하고 더 이상 필요 없을 때 삭제하도록 보장합니다. 데이터베이스는 데이터 파일 및 임시 파일, 제어 파일 및 빠른 복구 영역에 저장된 복구 관련 파일에 대해 파일을 생성하고 삭제하기 위해 내부적으로 표준 파일 시스템 인터페이스를 사용합니다.
Oracle 관리 파일은 기존 기능을 제거하지 않습니다. 수동으로 관리하는 기존 파일을 유지하면서 새로운 파일을 생성할 수 있습니다. 따라서 데이터베이스에는 Oracle 관리 파일과 사용자 관리 파일이 혼합될 수 있습니다.
참고 자료:
- "진단 파일 개요"
- Oracle Database Administrator’s Guide는 Oracle 관리 파일을 사용하는 방법을 배우기 위한 자료입니다.
데이터 파일 개요
운영 체제 수준에서 Oracle Database는 데이터 파일이라는 구조에 데이터베이스 데이터를 저장합니다. 모든 Oracle 데이터베이스는 최소한 하나의 데이터 파일을 가져야 합니다.
데이터 파일의 사용
Oracle Database는 테이블스페이스 데이터를 물리적으로 데이터 파일에 저장합니다.
각 비파티션 스키마 객체와 객체의 각 파티션은 고유의 세그먼트에 저장되며, 이는 단 하나의 테이블스페이스에만 속합니다. 예를 들어, 비파티션 테이블의 데이터는 하나의 세그먼트에 저장되며, 이 세그먼트는 하나의 테이블스페이스에 저장됩니다. 테이블스페이스와 데이터 파일은 밀접하게 관련되어 있지만 중요한 차이점이 있습니다:
- 각 테이블스페이스는 하나 이상의 데이터 파일로 구성되며, 이는 Oracle Database가 실행되는 운영 체제에 맞춰집니다.
- 데이터베이스의 데이터는 데이터베이스의 각 테이블스페이스에 위치한 데이터 파일에 집합적으로 저장됩니다.
- 세그먼트는 하나 이상의 데이터 파일에 걸쳐 있을 수 있지만 여러 테이블스페이스에 걸쳐 있을 수는 없습니다.
- 데이터베이스는 SYSTEM 및 SYSAUX 테이블스페이스를 반드시 가져야 합니다. Oracle Database는 데이터베이스 생성 시 자동으로 SYSTEM 테이블스페이스를 위한 첫 번째 데이터 파일을 할당합니다.
SYSTEM 테이블스페이스는 데이터 딕셔너리를 포함하며, 이는 데이터베이스 메타데이터를 포함하는 테이블 세트입니다. 일반적으로 데이터베이스에는 또한 언두 테이블스페이스와 임시 테이블스페이스(보통 TEMP로 명명됨)가 있습니다.
다음 그림은 테이블스페이스, 데이터 파일 및 세그먼트 간의 관계를 보여줍니다.
그림 11-4 데이터 파일과 테이블스페이스
그림 11-4 설명은 다음과 같습니다:
"그림 11-4 데이터 파일과 테이블스페이스" 설명
참고 자료:
- "테이블스페이스 개요"
- 데이터 파일 관리 방법은 Oracle Database Administrator’s Guide를 참조하십시오.
영구 및 임시 데이터 파일
영구 테이블스페이스는 영구적인 스키마 객체를 포함합니다. 영구 테이블스페이스의 객체는 데이터 파일에 저장됩니다.
임시 테이블스페이스는 세션 동안만 존재하는 스키마 객체를 포함합니다. 로컬로 관리되는 임시 테이블스페이스는 임시 파일(temp files)을 가지며, 이는 해시, 정렬 및 기타 작업에서 데이터를 저장하기 위해 설계된 특별한 파일입니다. 임시 파일은 또한 메모리에 충분한 공간이 없을 때 결과 집합 데이터를 저장합니다.
임시 파일은 영구 데이터 파일과 유사하지만 다음과 같은 예외가 있습니다:
- 테이블과 같은 영구 데이터베이스 객체는 임시 파일에 저장되지 않습니다.
- 임시 파일은 항상 NOLOGGING 모드로 설정되어 있어 리두가 생성되지 않습니다. 미디어 복구는 임시 파일을 인식하지 않습니다.
- 임시 파일을 읽기 전용으로 만들 수 없습니다.
- ALTER DATABASE 문을 사용하여 임시 파일을 생성할 수 없습니다.
- 임시 파일을 생성하거나 크기를 조정할 때, 파일 크기에 지정된 디스크 공간 할당이 항상 보장되는 것은 아닙니다. Linux 및 UNIX와 같은 파일 시스템에서는 임시 파일이 희소 파일로 생성됩니다. 이 경우, 디스크 블록은 파일 생성 또는 크기 조정 시가 아니라 블록이 처음 액세스될 때 할당됩니다.
참고: 희소 파일은 임시 파일 생성 및 크기 조정을 빠르게 하지만, 나중에 임시 파일에 액세스할 때 디스크 공간이 부족할 수 있습니다.
임시 파일 정보는 데이터 딕셔너리 뷰 DBA_TEMP_FILES와 동적 성능 뷰 VDATAFILE 뷰에는 표시되지 않습니다.
참고 자료:
- "임시 테이블스페이스"
- 임시 파일 관리 방법은 Oracle Database Administrator’s Guide를 참조하십시오.
온라인 및 오프라인 데이터 파일
모든 데이터 파일은 온라인(사용 가능) 또는 오프라인(사용 불가) 상태 중 하나입니다.
개별 데이터 파일이나 임시 파일을 오프라인으로 전환하거나 온라인으로 전환하여 가용성을 변경할 수 있습니다. 데이터베이스는 데이터 파일이 오프라인 상태인 동안에는 해당 파일에 액세스할 수 없습니다.
오프라인 백업 수행이나 블록 손상 등 여러 이유로 데이터 파일을 오프라인으로 전환할 수 있습니다. 데이터베이스는 해당 파일에 쓸 수 없는 경우 자동으로 데이터 파일을 오프라인으로 전환합니다.
데이터 파일과 마찬가지로 테이블스페이스 자체도 오프라인 또는 온라인 상태가 됩니다. 온라인 테이블스페이스에서 데이터 파일을 오프라인으로 전환하면 테이블스페이스 자체는 여전히 온라인 상태로 유지됩니다. 테이블스페이스 자체를 오프라인으로 전환하여 테이블스페이스의 모든 데이터 파일을 일시적으로 사용할 수 없게 만들 수 있습니다.
Oracle Database 12c부터는 ALTER DATABASE MOVE DATAFILE 문을 사용하여 데이터베이스가 열려 있고 파일에 액세스하는 동안 하나의 물리적 파일에서 다른 파일로 온라인 데이터 파일을 이동할 수 있습니다. 이 기술을 사용하여 다음 목표를 달성할 수 있습니다:
- 한 종류의 저장소에서 다른 종류의 저장소로 테이블스페이스 이동
- 자주 액세스되지 않는 데이터 파일을 저비용 저장소로 이동
- 테이블스페이스를 읽기 전용으로 설정하고 데이터를 쓰기 일회성 저장소(WORM 드라이브)로 이동
- Oracle ASM으로 데이터베이스 이동
참고 자료:
- "온라인 및 오프라인 테이블스페이스"
- 데이터 파일 가용성 변경 방법은 Oracle Database Administrator’s Guide를 참조하십시오.
- 온라인 데이터 파일을 이동하는 방법은 Oracle Database Administrator’s Guide를 참조하십시오.
- ALTER DATABASE ... MOVE DATAFILE에 대한 자세한 내용은 Oracle Database SQL Language Reference를 참조하십시오.
데이터 파일 구조
Oracle Database는 지정된 디스크 공간 양과 데이터 파일 헤더 오버헤드를 할당하여 테이블스페이스에 대한 데이터 파일을 생성합니다. Oracle Database가 실행되는 운영 체제는 데이터베이스에 파일을 할당하기 전에 이전 정보와 권한을 제거할 책임이 있습니다.
데이터 파일 헤더에는 데이터 파일의 크기 및 체크포인트 SCN과 같은 메타데이터가 포함됩니다. 각 헤더에는 데이터베이스 내에서 데이터 파일을 고유하게 식별하는 절대 파일 번호와 테이블스페이스 내에서 데이터 파일을 고유하게 식별하는 상대 파일 번호가 포함됩니다.
Oracle Database가 처음으로 데이터 파일을 생성할 때, 할당된 디스크 공간은 형식화되지만 사용자 데이터는 포함되지 않습니다. 그러나 데이터베이스는 관련 테이블스페이스의 향후 세그먼트를 위한 데이터를 저장할 공간을 예약합니다. 테이블스페이스의 데이터가 증가함에 따라 Oracle Database는 데이터 파일의 여유 공간을 사용하여 세그먼트를 위한 익스텐트를 할당합니다.
다음 그림은 데이터 파일의 다양한 공간 유형을 보여줍니다. 익스텐트는 사용 중인 공간(세그먼트 데이터를 포함함) 또는 여유 공간(재사용 가능)입니다. 시간이 지남에 따라 테이블스페이스 내 객체의 업데이트 및 삭제로 인해 새로운 데이터를 저장하기에는 개별적으로 충분하지 않은 빈 공간이 생길 수 있습니다. 이러한 유형의 빈 공간을 조각화된 여유 공간이라고 합니다.
그림 11-5 데이터 파일 내 공간
그림 11-5 설명은 다음과 같습니다:
"그림 11-5 데이터 파일 내 공간" 설명
참고 자료:
- 데이터 파일 정보를 보는 방법은 Oracle Database Administrator’s Guide를 참조하십시오.
제어 파일 개요
데이터베이스 제어 파일은 하나의 데이터베이스와만 연결된 작은 바이너리 파일입니다. 각 데이터베이스는 하나의 고유한 제어 파일을 가지고 있지만, 동일한 복사본을 여러 개 유지할 수 있습니다.
제어 파일의 사용
Oracle Database는 제어 파일을 사용하여 데이터베이스 파일의 위치를 찾고 데이터베이스의 상태를 일반적으로 관리합니다.
제어 파일에는 다음과 같은 정보가 포함됩니다:
- 데이터베이스 이름과 데이터베이스 고유 식별자(DBID)
- 데이터베이스 생성 타임스탬프
- 데이터 파일, 온라인 리두 로그 파일, 아카이브 리두 로그 파일에 대한 정보
- 테이블스페이스 정보
- RMAN 백업
제어 파일은 다음과 같은 목적을 수행합니다:
- 데이터베이스를 열기 위해 필요한 데이터 파일, 온라인 리두 로그 파일 등에 대한 정보를 포함합니다.
- 데이터베이스의 구조적 변경 사항을 추적합니다. 예를 들어, 관리자가 데이터 파일이나 온라인 리두 로그 파일을 추가, 이름 변경 또는 삭제할 때 데이터베이스는 이 변경 사항을 반영하도록 제어 파일을 업데이트합니다.
- 데이터베이스가 열려 있지 않을 때 접근할 수 있어야 하는 메타데이터를 포함합니다.
예를 들어, 제어 파일에는 체크포인트를 포함하여 데이터베이스를 복구하는 데 필요한 정보가 포함되어 있습니다. 체크포인트는 인스턴스 복구를 시작해야 하는 리두 스트림의 SCN을 나타냅니다. 체크포인트 SCN 이전에 커밋된 모든 변경 사항은 데이터 파일에 디스크에 저장되는 것이 보장됩니다. 체크포인트 프로세스는 온라인 리두 로그의 체크포인트 위치에 대한 정보를 제어 파일에 최소한 3초마다 기록합니다.
Oracle Database는 데이터베이스 사용 중에 제어 파일을 지속적으로 읽고 쓰며, 데이터베이스가 열려 있을 때 언제든지 쓰기 가능해야 합니다. 예를 들어, 데이터베이스를 복구할 때는 데이터베이스에 포함된 모든 데이터 파일의 이름을 제어 파일에서 읽습니다. 데이터 파일 추가와 같은 다른 작업은 제어 파일에 저장된 정보를 업데이트합니다.
참고 자료:
- "인스턴스 복구 개요"
- "체크포인트 프로세스(CKPT)"
- 제어 파일 관리 방법은 Oracle Database Administrator’s Guide를 참조하십시오.
다중 제어 파일
Oracle Database는 여러 동일한 제어 파일을 동시에 열고 동일한 데이터베이스에 쓰는 것을 허용합니다. 다른 디스크에 제어 파일을 다중화하면 데이터베이스는 중복성을 달성하여 단일 장애 지점을 피할 수 있습니다.
참고: Oracle은 각기 다른 디스크에 여러 개의 제어 파일 복사본을 유지할 것을 권장합니다.
제어 파일이 사용 불가능해지면, 데이터베이스 인스턴스는 손상된 제어 파일에 액세스하려고 할 때 실패합니다. 다른 최신 제어 파일 복사본이 존재하면 데이터베이스를 다시 마운트하고 미디어 복구 없이 열 수 있습니다. 그러나 데이터베이스의 모든 제어 파일이 손실되면 데이터베이스 인스턴스가 실패하고 미디어 복구가 필요합니다. 최신 제어 파일 복사본이 없을 때 이전 백업을 사용하여 복구하는 것은 간단하지 않습니다.
참고 자료:
- 다중 제어 파일 유지 관리 방법은 Oracle Database Administrator’s Guide를 참조하십시오.
- 제어 파일 백업 및 복구 방법은 Oracle Database Backup and Recovery User’s Guide를 참조하십시오.
제어 파일 구조
데이터베이스에 대한 정보는 제어 파일의 다양한 섹션에 저장됩니다. 각 섹션은 데이터베이스의 특정 측면에 대한 기록 세트입니다.
예를 들어, 제어 파일의 한 섹션은 데이터 파일을 추적하고 각 데이터 파일에 대한 기록 세트를 포함합니다. 각 섹션은 여러 논리적 제어 파일 블록에 저장됩니다. 기록은 섹션 내에서 블록을 넘나들 수 있습니다.
제어 파일에는 다음과 같은 유형의 기록이 포함됩니다:
순환 재사용 기록
순환 재사용 기록은 필요할 경우 덮어쓸 수 있는 비중요 정보를 포함합니다. 사용 가능한 모든 기록 슬롯이 가득 차면 데이터베이스는 새 기록을 위한 공간을 확보하기 위해 제어 파일을 확장하거나 가장 오래된 기록을 덮어씁니다. 예로는 아카이브된 리두 로그 파일 및 RMAN 백업에 대한 기록이 있습니다.
비순환 재사용 기록
비순환 재사용 기록은 자주 변경되지 않으며 덮어쓸 수 없는 중요한 정보를 포함합니다. 예로는 테이블스페이스, 데이터 파일, 온라인 리두 로그 파일 및 리두 스레드에 대한 정보가 있습니다. Oracle Database는 해당 객체가 테이블스페이스에서 삭제되지 않는 한 이 기록을 재사용하지 않습니다.
동적 성능 뷰(V$ 뷰)라고도 하는 뷰를 쿼리하여 제어 파일에 저장된 정보를 볼 수 있습니다. 예를 들어 V$DATABASE를 쿼리하여 데이터베이스 이름과 DBID를 얻을 수 있습니다. 그러나 데이터베이스만이 제어 파일의 정보를 수정할 수 있습니다.
제어 파일 블록을 읽고 쓰는 것은 데이터 블록을 읽고 쓰는 것과 다릅니다. 제어 파일의 경우 Oracle Database는 디스크에서 프로그램 글로벌 영역(PGA)으로 직접 읽고 씁니다. 각 프로세스는 제어 파일 블록을 위한 PGA 메모리의 일정량을 할당합니다.
참고 자료:
- "동적 성능 뷰 개요"
- V$CONTROLFILE_RECORD_SECTION 뷰에 대한 자세한 내용은 Oracle Database Reference를 참조하십시오.
- CONTROL_FILE_RECORD_KEEP_TIME 초기화 매개 변수에 대한 자세한 내용은 Oracle Database Reference를 참조하십시오.
온라인 리두 로그 개요
복구를 위해 가장 중요한 구조는 온라인 리두 로그입니다. 이는 데이터베이스에 변경이 발생할 때 이를 저장하는 사전 할당된 두 개 이상의 파일로 구성됩니다. 온라인 리두 로그는 데이터 파일에 대한 변경 사항을 기록합니다.
온라인 리두 로그의 사용
데이터베이스는 데이터 손실을 방지하기 위해 온라인 리두 로그 파일을 유지합니다. 특히 인스턴스 장애 후에, 온라인 리두 로그 파일은 Oracle Database가 아직 데이터 파일에 쓰지 않은 커밋된 데이터를 복구할 수 있게 해줍니다.
서버 프로세스는 모든 트랜잭션을 리두 로그 버퍼에 동기적으로 기록하며, LGWR 프로세스는 이를 온라인 리두 로그에 씁니다. 온라인 리두 로그의 내용에는 커밋되지 않은 트랜잭션과 스키마 및 객체 관리 명령이 포함됩니다.
데이터베이스가 언두 세그먼트에 변경을 가할 때, 데이터베이스는 이러한 변경 사항을 온라인 리두 로그에도 기록합니다. 따라서 온라인 리두 로그에는 항상 영구 객체에 대한 언두 데이터가 포함됩니다. 데이터베이스를 구성하여 임시 객체에 대한 모든 언두 데이터를 임시 언두 세그먼트에 저장하여 공간을 절약하고 성능을 향상시킬 수 있으며, 또는 데이터베이스가 영구 및 임시 언두 데이터를 모두 온라인 리두 로그에 저장하도록 할 수 있습니다.
Oracle Database는 온라인 리두 로그를 복구 목적으로만 사용합니다. 그러나 관리자는 Oracle LogMiner 유틸리티의 SQL 인터페이스를 통해 온라인 리두 로그 파일을 쿼리할 수 있습니다(참고: "Oracle LogMiner"). 리두 로그 파일은 데이터베이스 활동에 대한 역사적 정보를 제공하는 유용한 소스입니다.
참고 자료:
- "인스턴스 복구 개요"
- "임시 언두 세그먼트"
- Oracle 프로세스에 대해 배우려면 "프로세스 아키텍처"를 참조하십시오.
- 임시 언두 세그먼트 관리 방법은 Oracle Database Administrator’s Guide를 참조하십시오.
- TEMP_UNDO_ENABLED 초기화 매개 변수에 대한 자세한 내용은 Oracle Database Reference를 참조하십시오.
Oracle Database가 온라인 리두 로그에 쓰는 방법
데이터베이스 인스턴스의 온라인 리두 로그는 리두 스레드라고 합니다.
단일 인스턴스 구성에서는 하나의 인스턴스만 데이터베이스에 액세스하므로 하나의 리두 스레드만 존재합니다. 그러나 Oracle Real Application Clusters (Oracle RAC) 구성에서는 여러 인스턴스가 동시에 데이터베이스에 액세스하며, 각 인스턴스는 고유한 리두 스레드를 가집니다. 각 인스턴스에 대해 별도의 리두 스레드를 사용하면 단일 온라인 리두 로그 파일 세트에 대한 경쟁을 피할 수 있습니다.
온라인 리두 로그는 두 개 이상의 온라인 리두 로그 파일로 구성됩니다. Oracle Database는 최소 두 개의 파일이 필요합니다. 이는 하나의 파일이 지워지거나 아카이브되는 동안 항상 하나의 파일을 쓸 수 있도록 보장하기 위함입니다.
참고 자료:
- Oracle RAC에서 온라인 리두 로그 그룹에 대해 배우려면 Oracle Real Application Clusters Administration and Deployment Guide를 참조하십시오.
온라인 리두 로그 스위치
Oracle Database는 한 번에 하나의 온라인 리두 로그 파일만 사용하여 리두 로그 버퍼에서 기록을 저장합니다.
로그 라이터 프로세스(LGWR)가 적극적으로 쓰고 있는 온라인 리두 로그 파일을 현재 온라인 리두 로그 파일이라고 합니다.
로그 스위치는 데이터베이스가 하나의 온라인 리두 로그 파일에 쓰는 것을 중지하고 다른 파일에 쓰기 시작할 때 발생합니다. 일반적으로 스위치는 현재 온라인 리두 로그 파일이 가득 차서 쓰기를 계속해야 할 때 발생합니다. 그러나 현재 온라인 리두 로그 파일이 가득 차지 않더라도 로그 스위치를 정기적으로 발생하도록 구성할 수 있으며, 수동으로 로그 스위치를 강제할 수 있습니다.
로그 라이터는 온라인 리두 로그 파일에 순환적으로 씁니다. 로그 라이터가 사용할 수 있는 마지막 온라인 리두 로그 파일을 채우면, 프로세스는 첫 번째 로그 파일에 쓰기 시작하여 사이클을 재시작합니다. 그림 11-6은 리두 로그의 순환 쓰기를 보여줍니다.
그림 11-6 온라인 리두 로그 파일의 재사용
그림 11-6 설명은 다음과 같습니다:
"그림 11-6 온라인 리두 로그 파일의 재사용" 설명
그림 11-6에서 숫자는 LGWR이 각 온라인 리두 로그 파일에 쓰는 순서를 보여줍니다. 데이터베이스는 로그가 전환될 때 각 파일에 새로운 로그 시퀀스 번호를 할당합니다. 데이터베이스가 온라인 리두 로그 파일을 재사용할 때, 이 파일은 다음 사용 가능한 로그 시퀀스 번호를 받습니다.
채워진 온라인 리두 로그 파일은 아카이브 모드에 따라 재사용 가능 여부가 달라집니다:
- 아카이브가 비활성화된 경우, 즉 데이터베이스가 NOARCHIVELOG 모드에 있는 경우, 채워진 온라인 리두 로그 파일은 데이터베이스 라이터(DBW)가 해당 파일에 기록된 변경 사항을 디스크에 체크포인트한 후에 사용 가능합니다.
- 아카이브가 활성화된 경우, 즉 데이터베이스가 ARCHIVELOG 모드에 있는 경우, 채워진 온라인 리두 로그 파일은 변경 사항이 데이터 파일에 기록되고 파일이 아카이브된 후에 로그 라이터가 사용할 수 있습니다.
일부 상황에서는 로그 라이터가 기존의 온라인 리두 로그 파일을 재사용하지 못할 수 있습니다. 인스턴스 복구에 필요한 활성 온라인 리두 로그 파일과 인스턴스 복구에 필요하지 않은 비활성 온라인 리두 로그 파일이 있습니다. 또한, 온라인 리두 로그 파일이 지워지는 중일 수도 있습니다.
참고 자료:
- "백그라운드 프로세스 개요"
- 온라인 리두 로그 관리 방법은 Oracle Database Administrator’s Guide를 참조하십시오.
온라인 리두 로그 파일의 여러 복사본
Oracle Database는 서로 다른 위치에 두 개 이상의 동일한 온라인 리두 로그 복사본을 자동으로 유지할 수 있습니다.
온라인 리두 로그 그룹은 온라인 리두 로그 파일과 그 중복 복사본으로 구성됩니다. 각 동일한 복사본은 온라인 리두 로그 그룹의 멤버입니다. 각 그룹은 그룹 1, 그룹 2 등 번호로 정의됩니다.
온라인 리두 로그 그룹의 여러 멤버를 유지하면 리두 로그 손실을 방지할 수 있습니다. 이상적으로, 멤버의 위치는 서로 다른 디스크에 있어 하나의 디스크 장애가 전체 온라인 리두 로그 손실을 초래하지 않도록 해야 합니다.
그림 11-7에서 A_LOG1과 B_LOG1은 그룹 1의 동일한 멤버이며, A_LOG2와 B_LOG2는 그룹 2의 동일한 멤버입니다. 그룹 내 각 멤버는 동일한 크기여야 합니다. LGWR은 그룹 1(A_LOG1 및 B_LOG1 멤버)에 동시에 쓰고, 그룹 2(A_LOG2 및 B_LOG2 멤버)에 동시에 쓰고, 다시 그룹 1에 쓰는 순서로 진행됩니다. LGWR은 절대 다른 그룹의 멤버에게 동시에 쓰지 않습니다.
그림 11-7 온라인 리두 로그 파일의 여러 복사본
그림 11-7 설명은 다음과 같습니다:
"그림 11-7 온라인 리두 로그 파일의 여러 복사본" 설명
참고: Oracle은 온라인 리두 로그를 다중화할 것을 권장합니다. 로그 파일 손실은 복구가 필요할 경우 치명적일 수 있습니다. 온라인 리두 로그를 다중화하면 데이터베이스가 수행하는 I/O 양이 증가합니다. 시스템에 따라 이러한 추가 I/O가 전체 데이터베이스 성능에 영향을 미칠 수 있습니다.
참고 자료:
- 여러 복사본의 온라인 리두 로그 파일을 유지 관리하는 방법은 Oracle Database Administrator’s Guide를 참조하십시오.
- Data Guard 구성의 멤버 간 리두 데이터 자동 전송에 대해 배우려면 Oracle Data Guard Concepts and Administration을 참조하십시오.
아카이브 리두 로그 파일
아카이브 리두 로그 파일은 온라인 리두 로그 그룹의 채워진 멤버의 복사본입니다. 이 파일은 데이터베이스의 일부로 간주되지 않지만 데이터베이스에 의해 생성되고 사용자 지정 위치에 쓰여진 온라인 리두 로그 파일의 오프라인 복사본입니다.
아카이브 리두 로그 파일은 백업 및 복구 전략의 중요한 부분입니다. 아카이브 리두 로그 파일을 사용하여 다음 작업을 수행할 수 있습니다:
- 데이터베이스 백업 복구
- 대기 데이터베이스 업데이트
- Oracle LogMiner 유틸리티를 사용하여 데이터베이스의 역사에 대한 정보 얻기
아카이브 리두 로그 파일을 생성하는 작업을 아카이빙이라고 합니다. 이 작업은 자동 또는 수동으로 수행될 수
있습니다. 데이터베이스가 ARCHIVELOG 모드에 있을 때만 가능합니다.
아카이브 리두 로그 파일에는 리두 항목과 온라인 리두 로그 그룹의 동일한 멤버의 로그 시퀀스 번호가 포함됩니다. "온라인 리두 로그 파일의 여러 복사본"에서 A_LOG1과 B_LOG1은 그룹 1의 동일한 멤버입니다. 데이터베이스가 ARCHIVELOG 모드에 있고 자동 아카이빙이 활성화된 경우, 아카이버 프로세스(ARCn)가 이 파일 중 하나를 아카이브합니다. A_LOG1이 손상된 경우 프로세스는 B_LOG1을 아카이브할 수 있습니다. 아카이브된 리두 로그에는 아카이빙을 활성화한 시점부터 존재했던 모든 리두 로그 그룹의 복사본이 포함됩니다.
참고 자료:
- "Oracle LogMiner"
- "데이터 파일 복구"
- 아카이브 리두 로그 관리 방법은 Oracle Database Administrator’s Guide를 참조하십시오.
- 대기 리두 로그 아카이빙 구성에 대해 배우려면 Oracle Data Guard Concepts and Administration을 참조하십시오.
온라인 리두 로그의 구조
온라인 리두 로그 파일에는 리두 레코드가 포함됩니다.
리두 레코드는 데이터 블록에 대한 변경 사항을 설명하는 변경 벡터 그룹으로 구성됩니다. 예를 들어, employees 테이블의 급여를 업데이트하면 테이블의 데이터 세그먼트 블록, 언두 세그먼트 데이터 블록 및 언두 세그먼트의 트랜잭션 테이블에 대한 변경 사항을 설명하는 리두 레코드가 생성됩니다.
리두 레코드에는 다음을 포함하여 변경 사항에 대한 모든 관련 메타데이터가 포함됩니다:
- 변경 사항의 SCN 및 타임스탬프
- 변경을 생성한 트랜잭션의 트랜잭션 ID
- 트랜잭션이 커밋되었을 경우 커밋된 SCN 및 타임스탬프
- 변경을 만든 작업 유형
- 수정된 데이터 세그먼트의 이름 및 유형
참고 자료:
- "데이터 블록 개요"
