[오라클] Oracle® Database Concepts 챕터 12 한글 번역

torch·2024년 7월 23일

db oracle

Oracle

목록 보기

12/13

Reference : 12. Logical Storage Structures

*GPT 번역 기반으로 내용이 정확하지 않을 수 있습니다.

12 논리적 저장 구조

이 장에서는 논리적 저장 구조의 성격과 관계를 설명합니다. 이러한 구조는 Oracle Database에 의해 생성 및 인식되며 운영 체제에서는 인식되지 않습니다.

이 장에는 다음 섹션이 포함됩니다:

논리적 저장 구조 소개
데이터 블록 개요
익스텐트 개요
세그먼트 개요
테이블스페이스 개요

논리적 저장 구조 소개

Oracle Database는 데이터베이스의 모든 데이터에 대해 논리적 공간을 할당합니다.

데이터베이스 공간 할당의 논리적 단위는 데이터 블록, 익스텐트, 세그먼트 및 테이블스페이스입니다. 물리적 수준에서는 데이터가 디스크의 데이터 파일에 저장됩니다. 데이터 파일의 데이터는 운영 체제 블록에 저장됩니다.

다음 그림은 물리적 및 논리적 저장소에 대한 엔터티-관계 다이어그램입니다. 까마귀 발 표기법은 일대다 관계를 나타냅니다.

그림 12-1 논리적 및 물리적 저장

그림 12-1의 설명이 뒤따릅니다
그림 12-1 논리적 및 물리적 저장의 설명
참고:

"물리적 저장 구조"

논리적 저장 계층

세그먼트는 하나 이상의 익스텐트를 포함하며, 각 익스텐트는 여러 데이터 블록을 포함합니다.

다음 그림은 테이블스페이스 내에서 데이터 블록, 익스텐트 및 세그먼트 간의 관계를 보여줍니다. 이 예에서는 세그먼트가 다른 데이터 파일에 저장된 두 개의 익스텐트를 가지고 있습니다.

그림 12-2 테이블스페이스 내의 세그먼트, 익스텐트 및 데이터 블록

그림 12-2의 설명이 뒤따릅니다
그림 12-2 테이블스페이스 내의 세그먼트, 익스텐트 및 데이터 블록의 설명
Oracle Database는 데이터 저장의 가장 낮은 수준에서 가장 높은 수준에 이르기까지 데이터를 저장합니다.

데이터 블록은 Oracle Database에서 데이터 저장의 가장 작은 논리적 단위입니다.

하나의 논리적 데이터 블록은 예를 들어 2KB와 같은 특정 바이트 수의 물리적 디스크 공간에 해당합니다. 데이터 블록은 Oracle Database가 사용할 수 있거나 할당할 수 있는 가장 작은 저장 단위입니다.

익스텐트는 특정 유형의 정보를 저장하기 위해 할당된 논리적으로 연속된 데이터 블록 집합입니다.

앞의 그래픽에서 24KB 익스텐트는 12개의 데이터 블록을 가지고 있으며, 72KB 익스텐트는 36개의 데이터 블록을 가지고 있습니다.

세그먼트는 특정 데이터베이스 객체를 위해 할당된 익스텐트 집합입니다.

예를 들어, employees 테이블의 데이터는 자체 데이터 세그먼트에 저장되며, employees의 각 인덱스는 자체 인덱스 세그먼트에 저장됩니다. 저장을 소비하는 모든 데이터베이스 객체는 단일 세그먼트로 구성됩니다.

테이블스페이스는 하나 이상의 세그먼트를 포함하는 데이터베이스 저장 단위입니다.

각 세그먼트는 하나의 테이블스페이스에만 속합니다. 따라서 세그먼트의 모든 익스텐트는 동일한 테이블스페이스에 저장됩니다. 테이블스페이스 내에서 세그먼트는 여러 데이터 파일에서 익스텐트를 포함할 수 있습니다. 예를 들어, 세그먼트의 하나의 익스텐트는 users01.dbf에 저장되고 다른 하나는 users02.dbf에 저장될 수 있습니다. 단일 익스텐트는 절대 데이터 파일을 넘을 수 없습니다.

참고:

"데이터 파일 개요"

논리적 공간 관리

Oracle Database는 테이블스페이스 내에서 익스텐트를 추적하고 할당하기 위해 논리적 공간 관리를 사용해야 합니다.

데이터베이스 객체가 익스텐트를 필요로 할 때, 데이터베이스는 이를 찾고 제공하는 방법을 가지고 있어야 합니다. 유사하게, 객체가 더 이상 익스텐트를 필요로 하지 않을 때, 데이터베이스는 여유 익스텐트를 사용할 수 있게 만드는 방법을 가지고 있어야 합니다.

Oracle Database는 생성한 테이블스페이스 유형에 따라 테이블스페이스 내에서 공간을 관리합니다. 다음 유형의 테이블스페이스를 생성할 수 있습니다:

로컬 관리 테이블스페이스(기본값)

데이터베이스는 테이블스페이스 자체의 비트맵을 사용하여 익스텐트를 관리합니다. 따라서 로컬 관리 테이블스페이스는 비트맵을 위한 테이블스페이스의 일부를 할당합니다. 테이블스페이스 내에서 데이터베이스는 자동 세그먼트 공간 관리(ASSM) 또는 수동 세그먼트 공간 관리(MSSM)를 사용하여 세그먼트를 관리할 수 있습니다.
사전 관리 테이블스페이스

데이터베이스는 데이터 사전을 사용하여 익스텐트를 관리합니다.

그림 12-3 테이블스페이스에서의 논리적 공간 관리

그림 12-3의 설명이 뒤따릅니다
그림 12-3 테이블스페이스에서의 논리적 공간 관리의 설명
참고:

"데이터 사전 개요"

로컬 관리 테이블스페이스

로컬 관리 테이블스페이스는 데이터 파일 헤더에서 비트맵을 유지하여 데이터 파일 본체의 사용 및 비사용 공간을 추적합니다.

각 비트는 블록 그룹에 해당합니다. 공간이 할당되거나 해제될 때, Oracle Database는 블록 상태를 반영하도록 비트맵 값을 변경합니다.

다음 그래픽은 비트맵 관리 저장소의 개념적 표현입니다. 헤더의 1은 사용된 공간을 나타내고, 0은 비어 있는 공간을 나타냅니다.

그림 12-4 비트맵 관리 저장소

그림 12-4의 설명이 뒤따릅니다
그림 12-4 비트맵 관리 저장소의 설명
로컬 관리 테이블스페이스는 다음과 같은 이점이 있습니다:

익스텐트 관리를 위해 데이터 사전을 사용하지 않음

익스텐트의 공간 소비나 해제가 데이터 사전 테이블이나 롤백 세그먼트에서 또 다른 공간 소비나 해제를 초래할 수 있는 경우 사전 관리 테이블스페이스에서 재귀 작업이 발생할 수 있습니다.
인접한 여유 공간을 자동으로 추적

이렇게 하면 데이터베이스는 여유 익스텐트를 병합할 필요가 없습니다.
로컬 관리 익스텐트의 크기를 자동으로 결정

또는 모든 익스텐트는 동일한 크기를 가질 수 있으며 객체 저장 옵션을 무시할 수 있습니다.

참고: Oracle은 자동 세그먼트 공간 관리를 사용하는 로컬 관리 테이블스페이스의 사용을 강력히 권장합니다.
세그먼트 공간 관리는 세그먼트를 포함하는 테이블스페이스에서 상속된 속성입니다. 로컬 관리 테이블스페이스 내에서 데이터베이스는 세그먼트를 자동으로 또는 수동으로 관리할 수 있습니다. 예를 들어, users 테이블스페이스의 세그먼트는 자동으로 관리되고 tools 테이블스페이스의 세그먼트는 수동으로 관리될 수 있습니다.

자동 세그먼트 공간 관리

자동 세그먼트 공간 관리(ASSM) 방법은 비트맵을 사용하여 테이블스페이스의 공간을 관리합니다.

비트맵은 다음과 같은 이점을 제공합니다:

간소화된 관리

ASSM은 많은 저장소 매개 변수를 수동으로 결정할 필요를 없애줍니다. 공간 할당을 제어하는 중요한 SQL 매개 변수는 PCTFREE 하나뿐입니다. 이 매개 변수는 향후 업데이트를 위해 블록에 예약할 공간의 비율을 지정합니다(데이터 블록의 여유 공간 비율 참조).
증가된 동시성

여러 트랜잭션이 별도의 여유 데이터 블록 목록을 검색할 수 있으므로 경쟁 및 대기가 줄어듭니다. 많은 표준 워크로드에 대해 ASSM을 사용하는 애플리케이션의 성능은 잘 조정된 MSSM을 사용하는 애플리케이션의 성능보다 더 좋습니다.
Oracle Real Application Clusters(Oracle RAC) 환경에서 인스턴스에 대한 공간의 동적 친화성

ASSM은 더 효율적이며 영구적이고 로컬 관리되는 테이블스페이스에 대해 기본값입니다.

참고: 이 장에서는 논리적 저장 공간에 대한 모든 논의에서 ASSM의 사용을 가정합니다.

수동 세그먼트 공간 관리

기존의 수동 세그먼트 공간 관리(MSSM) 방법은 자유 목록이라는 연결 리스트를 사용하여 세그먼트의 여유 공간을 관리합니다.

여유 공간이 있는 데이터베이스 객체의 경우, 자유 목록은 사용된 공간과 사용되지 않은 공간을

나누는 고수위 마크(HWM) 아래의 블록을 추적합니다. 블록이 사용됨에 따라 데이터베이스는 필요에 따라 블록을 자유 목록에 추가하거나 제거합니다.

PCTFREE 외에도 MSSM에서는 PCTUSED, FREELISTS 및 FREELIST GROUPS와 같은 SQL 매개 변수를 사용하여 공간 할당을 제어해야 합니다. PCTUSED는 데이터베이스가 블록을 자유 목록에 올리기 위해 블록에 존재해야 하는 여유 공간의 비율을 설정합니다. 예를 들어, CREATE TABLE 문에서 PCTUSED를 40으로 설정하면 블록 공간의 40% 미만이 사용될 때까지 세그먼트의 블록에 행을 삽입할 수 없습니다.

예를 들어, 테이블에 행을 삽입한다고 가정합니다. 데이터베이스는 테이블의 자유 목록에서 사용 가능한 첫 번째 블록을 확인합니다. 행이 블록에 맞지 않고 블록의 사용된 공간이 PCTUSED 이상이면 데이터베이스는 블록을 목록에서 제거하고 다른 블록을 검색합니다. 블록에서 행을 삭제하면 데이터베이스는 블록의 사용된 공간이 이제 PCTUSED보다 작은지 확인합니다. 그렇다면 데이터베이스는 블록을 자유 목록의 시작 부분에 둡니다.

객체는 여러 자유 목록을 가질 수 있습니다. 이로 인해 테이블에서 DML을 수행하는 여러 세션이 다른 목록을 사용할 수 있으며, 이는 경쟁을 줄일 수 있습니다. 각 데이터베이스 세션은 세션 기간 동안 하나의 자유 목록만 사용합니다.

다음 그림과 같이 객체를 하나 이상의 자유 목록 그룹으로 만들 수도 있습니다. 각 그룹은 개별 프로세스 자유 목록을 관리하는 마스터 자유 목록을 가지고 있습니다. 특히 자유 목록 그룹의 경우 자유 목록의 공간 오버헤드는 상당할 수 있습니다.

그림 12-5 자유 목록 그룹

그림 12-5의 설명이 뒤따릅니다
그림 12-5 자유 목록 그룹의 설명
세그먼트 공간을 수동으로 관리하는 것은 복잡할 수 있습니다. 행 마이그레이션을 줄이고 공간 낭비를 방지하기 위해 PCTFREE 및 PCTUSED를 조정해야 합니다. 예를 들어, 세그먼트의 모든 사용된 블록이 절반 가득 차고 PCTUSED가 40이면 데이터베이스는 이러한 블록에 삽입을 허용하지 않습니다. 공간 할당 매개 변수를 세밀하게 조정하는 것이 어렵기 때문에, Oracle은 ASSM을 강력히 권장합니다. ASSM에서는 PCTFREE가 블록에 새 행을 삽입할 수 있는지 여부를 결정하지만, 자유 목록을 사용하지 않으며 PCTUSED를 무시합니다.

참고:

"체인 및 마이그레이션된 행"

Oracle Database Administrator’s Guide에서 로컬 관리 테이블스페이스에 대해 알아보기

Oracle Database Administrator’s Guide에서 자동 세그먼트 공간 관리에 대해 자세히 알아보기

Oracle Database SQL Language Reference에서 PCTFREE 및 PCTUSED와 같은 저장소 매개 변수에 대해 알아보기

사전 관리 테이블스페이스

사전 관리 테이블스페이스는 데이터 사전을 사용하여 익스텐트를 관리합니다.

Oracle Database는 익스텐트를 할당하거나 재사용을 위해 해제할 때마다 데이터 사전의 테이블을 업데이트합니다. 예를 들어, 테이블이 익스텐트를 필요로 할 때 데이터베이스는 데이터 사전 테이블을 쿼리하고 여유 익스텐트를 검색합니다. 데이터베이스가 공간을 찾으면 하나의 데이터 사전 테이블을 수정하고 다른 테이블에 행을 삽입합니다. 이렇게 해서 데이터베이스는 데이터를 수정하고 이동하여 공간을 관리합니다.

데이터베이스가 데이터베이스 객체에 대한 공간을 확보하기 위해 백그라운드에서 실행하는 SQL은 재귀 SQL입니다. 재귀 SQL의 빈번한 사용은 데이터 사전을 업데이트해야 하므로 성능에 부정적인 영향을 미칠 수 있습니다. 기본값인 로컬 관리 테이블스페이스는 이러한 성능 문제를 피합니다.

참고:

Oracle Database Administrator’s Guide에서 사전 관리 테이블스페이스를 로컬 관리 테이블스페이스로 마이그레이션하는 방법을 알아보기

데이터 블록 개요

Oracle Database는 데이터 파일의 논리적 저장 공간을 데이터 블록이라는 단위로 관리합니다. 데이터 블록은 Oracle 블록 또는 페이지라고도 합니다. 데이터 블록은 데이터베이스 I/O의 최소 단위입니다.

데이터 블록과 운영 체제 블록

물리적 수준에서 데이터베이스 데이터는 운영 체제 블록으로 구성된 디스크 파일에 저장됩니다.

운영 체제 블록은 운영 체제가 읽거나 쓸 수 있는 최소 데이터 단위입니다. 반면, Oracle 블록은 운영 체제에서 알 수 없는 크기와 구조를 가진 논리적 저장 구조입니다.

다음 그림은 운영 체제 블록과 데이터 블록의 크기가 다를 수 있음을 보여줍니다. 데이터베이스는 운영 체제 블록이 아닌 데이터 블록의 배수로 데이터를 요청합니다.

그림 12-6 데이터 블록과 운영 체제 블록

그림 12-6의 설명이 뒤따릅니다
그림 12-6 데이터 블록과 운영 체제 블록의 설명
데이터베이스가 데이터 블록을 요청하면 운영 체제는 이 작업을 영구 저장 장치의 데이터 요청으로 변환합니다. 데이터 블록을 운영 체제 블록과 논리적으로 분리하면 다음과 같은 의미가 있습니다:

응용 프로그램은 디스크의 데이터 물리적 주소를 결정할 필요가 없습니다.
데이터베이스 데이터는 여러 물리적 디스크에 스트라이프되거나 미러링될 수 있습니다.

데이터베이스 블록 크기

모든 데이터베이스에는 데이터베이스 블록 크기가 있습니다.

DB_BLOCK_SIZE 초기화 매개 변수는 데이터베이스 생성 시 데이터 블록 크기를 설정합니다. 이 크기는 SYSTEM 및 SYSAUX 테이블스페이스에 설정되며, 다른 모든 테이블스페이스의 기본값입니다. 데이터베이스 블록 크기는 데이터베이스를 재생성하지 않는 한 변경할 수 없습니다.

DB_BLOCK_SIZE가 설정되지 않으면 기본 데이터 블록 크기는 운영 체제에 따라 다릅니다. 데이터베이스의 표준 데이터 블록 크기는 4 KB 또는 8 KB입니다. 데이터 블록과 운영 체제 블록의 크기가 다르면 데이터 블록 크기는 운영 체제 블록 크기의 배수여야 합니다.

참고:

Oracle Database Reference에서 DB_BLOCK_SIZE 초기화 매개 변수에 대해 알아보기

Oracle Database Administrator’s Guide 및 Oracle Database Performance Tuning Guide에서 블록 크기를 선택하는 방법에 대해 알아보기

테이블스페이스 블록 크기

DB_BLOCK_SIZE 설정과 다른 블록 크기를 가진 개별 테이블스페이스를 생성할 수 있습니다.

비표준 블록 크기는 전송 가능한 테이블스페이스를 다른 플랫폼으로 이동할 때 유용할 수 있습니다.

참고:

Oracle Database Administrator’s Guide에서 테이블스페이스에 대해 비표준 블록 크기를 지정하는 방법에 대해 알아보기

데이터 블록 형식

모든 데이터 블록은 블록의 데이터와 여유 공간을 추적할 수 있도록 데이터베이스가 관리할 수 있는 형식 또는 내부 구조를 가지고 있습니다. 이 형식은 데이터 블록이 테이블, 인덱스 또는 테이블 클러스터 데이터를 포함하든 유사합니다.

다음 그림은 압축되지 않은 데이터 블록의 형식을 보여줍니다.

그림 12-7 데이터 블록 형식

그림 12-7의 설명이 뒤따릅니다
그림 12-7 데이터 블록 형식의 설명
참고:

"데이터 블록 압축"에서 압축된 블록에 대해 알아보기

데이터 블록 오버헤드

Oracle Database는 블록 자체를 관리하기 위해 블록 오버헤드를 사용합니다. 블록 오버헤드는 사용자 데이터를 저장하는 데 사용할 수 없습니다.

"데이터 블록 형식"에서 보여지듯이, 블록 오버헤드에는 다음 부분이 포함됩니다:

블록 헤더

이 부분은 디스크 주소 및 세그먼트 유형을 포함한 블록에 대한 일반 정보를 포함합니다. 트랜잭션 관리 블록의 경우, 블록 헤더는 활성 및 기록된 트랜잭션 정보를 포함합니다.

블록을 업데이트하는 모든 트랜잭션에는 트랜잭션 항목이 필요합니다. Oracle Database는 처음에 블록 헤더에 트랜잭션 항목을 위한 공간을 예약합니다. 트랜잭션 변경을 지원하는 세그먼트에 할당된 데이터 블록에서는 헤더 공간이 부족할 때 여유 공간이 트랜잭션 항목을 보유할 수 있습니다. 트랜잭션 항목에 필요한 공간은 운영 체제에 따라 다릅니다. 그러나 대부분의 운영 체제에서는 트랜잭션 항목에 약 23 바이트가 필요합니다.
테이블 디렉터리

힙 구성 테이블의 경우, 이 디렉터리는 이 블록에 저장된 테이블의 메타데이터를 포함합니다. 테이블 클러스터에서는 여러 테이블이 동일한 블록에 행을 저장할 수 있습니다.
행 디렉터리

힙 구성 테이블의 경우, 이 디렉터리는 블록의 데이터 부분에 있는 행의 위치를 설명합니다. 데이터베이스는 행을 블록의 하단 아무 곳에나 배치할 수 있습니다. 행 주소는 행 디렉터리 벡터의 슬롯 중 하나에 기록됩니다.

rowid는 특정 파일, 블록 및 행 번호를 가리킵니다. 예를 들어, rowid가 AAAPecAAFAAAABSAAA인 경우, 마지막 AAA는 행 번호를 나타냅니다. 행 번호는 행 디렉터리 항목의 인덱스입니다. 행 디렉터리 항목은 데이터 블록의 행 위치에 대한 포인터를 포함합니다. 데이터베이스가 블록 내에서 행을 이동하면 데이터베이스는 포인터를 수정하기 위해 행 디렉터리 항목을 업데이트합니다. rowid는 그대로 유지됩니다.

데이터베이스가 행 디렉터리에 공간을 할당한 후, 행을 삭제해도 이 공간을 회수하지 않습니다. 따라서 현재 비어 있지만 이전에 50개의 행이 있던 블록은 행 디렉터리에 100바이트가 계속 할당됩니다. 데이터베이스는 이 공간을 새로운 행을 블록에 삽입할 때만 재사용합니다.

블록 오버헤드의 일부는 고정 크기이지만 전체 크기는 가변적입니다. 평균적으로 블록 오버헤드는 총 84에서 107 바이트입니다.

행 형식

블록의 행 데이터 부분은 테이블 행 또는 인덱스 키 항목과 같은 실제 데이터를 포함합니다. 모든 데이터 블록에 내부 형식이 있는 것처럼, 모든 행에는 데이터베이스가 행의 데이터를 추적할 수 있도록 하는 행 형식이 있습니다.

Oracle Database는 행을 가변 길이 레코드로 저장합니다. 하나의 행은 하나 이상의 섹션으로 구성됩니다. 각 섹션은 행 조각이라고 합니다. 각 행 조각에는 행 헤더와 열 데이터가 있습니다.

다음 그림은 행 조각의 형식을 보여줍니다.

그림 12-8 행 조각의 형식

그림 12-8의 설명이 뒤따릅니다
그림 12-8 행 조각의 형식의 설명

행 헤더

Oracle Database는 블록에 저장된 행 조각을 관리하기 위해 행 헤더를 사용합니다.

행 헤더에는 다음과 같은 정보가 포함됩니다:

행 조각의 열
다른 데이터 블록에 위치한 행의 조각

전체 행을 단일 데이터 블록에 삽입할 수 있다면, Oracle Database는 행을 하나의 행 조각으로 저장합니다. 그러나 모든 행 데이터를 단일 블록에 삽입할 수 없거나 업데이트로 인해 기존 행이 블록을 초과하면 데이터베이스는 행을 여러 행 조각으로 저장합니다. 데이터 블록에는 보통 하나의 행 조각만 포함됩니다.

테이블 클러스터의 클러스터 키

단일 블록에 완전히 포함된 행은 최소 3바이트의 행 헤더를 가집니다.

참고:

"체인 및 마이그레이션된 행"

"테이블 클러스터 개요"

열 데이터

행 헤더 다음으로 열 데이터 섹션에는 행의 실제 데이터가 저장됩니다. 행 조각은 보통 CREATE TABLE 문에 나열된 순서대로 열을 저장하지만, 이 순서는 보장되지 않습니다. 예를 들어, LONG 유형의 열은 마지막에 생성됩니다.

"행 형식" 그림에 표시된 것처럼, 행 조각의 각 열에 대해 Oracle Database는 열 길이와 데이터를 별도로 저장합니다. 필요한 공간은 데이터 유형에 따라 다릅니다. 열의 데이터 유형이 가변 길이인 경우, 값의 크기가 업데이트에 따라 커지거나 줄어들 수 있습니다.

각 행에는 데이터 블록 헤더의 행 디렉터리에 슬롯이 있습니다. 슬롯은 행의 시작 부분을 가리킵니다.

참고:

"테이블 저장소" 및 "인덱스 저장소"

Rowid 형식

Oracle Database는 rowid를 사용하여 행을 고

유하게 식별합니다. 내부적으로 rowid는 데이터베이스가 행에 접근하는 데 필요한 정보를 포함하는 구조체입니다. rowid는 데이터베이스에 물리적으로 저장되지 않지만, 데이터가 저장된 파일 및 블록에서 유추됩니다.

확장 rowid는 데이터 객체 번호를 포함합니다. 이 rowid 유형은 각 행의 물리적 주소를 기반 64 인코딩으로 사용합니다. 인코딩 문자는 A-Z, a-z, 0-9, + 및 /입니다.

예제 12-1 ROWID 의사 열

다음 예제는 employees 테이블의 직원 100 행에 대한 확장 rowid를 표시하기 위해 ROWID 의사 열을 쿼리합니다.

SQL> SELECT ROWID FROM employees WHERE employee_id = 100;
 
ROWID
------------------
AAAPecAAFAAAABSAAA

다음 그림은 확장 rowid의 형식을 보여줍니다.

그림 12-9 ROWID 형식

그림 12-9의 설명이 뒤따릅니다
그림 12-9 ROWID 형식의 설명
확장 rowid는 OOOOOOFFFBBBBBBRRR 형식의 네 부분 형식으로 표시되며, 형식은 다음 구성 요소로 나뉩니다:

OOOOOO

데이터 객체 번호는 세그먼트(data object AAAPec in the sample query)를 식별합니다. 데이터 객체 번호는 모든 데이터베이스 세그먼트에 할당됩니다. 동일한 세그먼트의 스키마 객체, 예를 들어 테이블 클러스터는 동일한 데이터 객체 번호를 가집니다.
FFF

테이블스페이스 상대 데이터 파일 번호는 행이 포함된 데이터 파일을 식별합니다(파일 AAF in the sample query).
BBBBBB

데이터 블록 번호는 행이 포함된 블록을 식별합니다(블록 AAAABS in the sample query). 블록 번호는 테이블스페이스가 아닌 데이터 파일에 상대적입니다. 따라서 동일한 블록 번호를 가진 두 행은 동일한 테이블스페이스의 다른 데이터 파일에 있을 수 있습니다.
RRR

행 번호는 블록의 행을 식별합니다(행 AAA in the sample query).

rowid가 행 조각에 할당된 후, 특수한 상황에서 rowid가 변경될 수 있습니다. 예를 들어, 행 이동이 활성화된 경우, 파티션 키 업데이트, Flashback Table 작업, 테이블 축소 작업 등으로 인해 rowid가 변경될 수 있습니다. 행 이동이 비활성화된 경우, rowid는 Oracle Database 유틸리티를 사용하여 행이 내보내지고 가져오기된 경우 변경될 수 있습니다.

참고: 내부적으로 데이터베이스는 행 이동을 행이 물리적으로 삭제되고 재삽입된 것처럼 수행합니다. 그러나 행 이동은 트리거에 영향을 미치는 업데이트로 간주됩니다.
참고:

"Rowid 데이터 유형"

Oracle Database SQL Language Reference에서 rowid에 대해 알아보기

데이터 블록 압축

데이터베이스는 테이블 압축을 사용하여 데이터 블록의 중복 값을 제거할 수 있습니다. 이 섹션에서는 압축을 사용하는 데이터 블록의 형식을 설명합니다.

기본 테이블 및 고급 행 압축을 사용하는 데이터 블록의 형식은 본질적으로 압축되지 않은 블록과 동일합니다. 차이점은 블록의 시작 부분에 있는 심볼 테이블이 행과 열의 중복 값을 저장한다는 것입니다. 데이터베이스는 이러한 값의 발생을 심볼 테이블에 대한 짧은 참조로 대체합니다.

예제 12-2 압축 데이터 블록의 형식

다음 행이 7열의 sales 테이블의 데이터 블록에 저장되어 있다고 가정합니다:

2190,13770,25-NOV-00,S,9999,23,161
2225,15720,28-NOV-00,S,9999,25,1450
34005,120760,29-NOV-00,P,9999,44,2376
9425,4750,29-NOV-00,I,9999,11,979
1675,46750,29-NOV-00,S,9999,19,1121

이 테이블에 기본 테이블 또는 고급 행 압축이 적용되면 데이터베이스는 중복 값을 심볼 참조로 대체합니다. 다음 개념적 압축 표현은 29-NOV-00을 *로, 9999를 %로 대체합니다:

2190,13770,25-NOV-00,S,%,23,161
2225,15720,28-NOV-00,S,%,25,1450
34005,120760,*,P,%,44,2376
9425,4750,*,I,%,11,979
1675,46750,*,S,%,19,1121

표 12-1 심볼 테이블

심볼	값	열	행
*	29-NOV-00	3	958-960
%	9999	5	956-960

참고:

"테이블 압축"

데이터 블록의 공간 관리

데이터베이스가 블록을 하단부터 채우면, 행 데이터와 블록 헤더 사이의 여유 공간이 줄어듭니다.

데이터 블록의 여유 공간은 업데이트 중에도 줄어들 수 있습니다. 예를 들어, 후행 null 값을 비null 값으로 변경할 때 그렇습니다. 데이터베이스는 성능을 최적화하고 공간 낭비를 방지하기 위해 데이터 블록의 여유 공간을 관리합니다.

참고: 이 섹션에서는 자동 세그먼트 공간 관리를 사용하는 것을 가정합니다.

데이터 블록의 여유 공간 비율

PCTFREE SQL 매개 변수는 기존 행을 업데이트하기 위해 데이터 블록의 최소 비율을 여유 공간으로 예약합니다. PCTFREE는 행 마이그레이션을 방지하고 공간 낭비를 피하는 데 중요합니다.

예를 들어, 기존 데이터의 크기를 거의 증가시키지 않는 드문 업데이트가 필요한 테이블을 생성한다고 가정합니다. CREATE TABLE 문 내에서 PCTFREE 매개 변수를 다음과 같이 지정합니다:

CREATE TABLE test_table (n NUMBER) PCTFREE 20;

그림 12-10은 PCTFREE 설정이 공간 관리에 미치는 영향을 보여줍니다. 데이터베이스는 시간이 지나면서 블록에 행을 추가하여 행 데이터가 블록 헤더를 향해 위쪽으로 성장하게 합니다. PCTFREE 설정은 데이터 블록의 최소 20%가 여유 공간으로 예약되도록 보장합니다. 예를 들어, 데이터베이스는 행 데이터와 헤더가 총 블록 공간의 90%를 차지하여 10%만 여유 공간으로 남기는 삽입 문을 방지합니다.

그림 12-10 PCTFREE

그림 12-10의 설명이 뒤따릅니다
그림 12-10 PCTFREE의 설명
참고: 이 논의는 PCTFREE 저장 매개 변수를 사용하지 않거나 자유 목록을 사용하지 않는 LOB 데이터 유형에는 적용되지 않습니다.

참고:

"LOB 개요"

Oracle Database SQL Language Reference에서 PCTFREE 매개 변수의 구문 및 의미에 대해 알아보기

데이터 블록의 여유 공간 최적화

여유 공간 비율은 PCTFREE보다 작을 수 없지만, 여유 공간의 양은 더 클 수 있습니다. 예를 들어, PCTFREE를 20%로 설정하면 여유 공간의 총량이 블록의 5%로 떨어지는 것을 방지하지만, 블록의 50%가 여유 공간으로 남을 수 있습니다.

여유 공간을 증가시켜 최적화

일부 DML 문은 데이터 블록의 여유 공간을 증가시킬 수 있습니다.

다음 문은 공간을 증가시킬 수 있습니다:

DELETE 문
기존 값을 더 작은 값으로 업데이트하거나 기존 값을 증가시켜 행을 마이그레이션하는 UPDATE 문
고급 행 압축을 사용하는 테이블에서의 INSERT 문

INSERT 문이 데이터를 블록에 채우면, 데이터베이스는 블록 압축을 호출하여 블록이 더 많은 여유 공간을 가지게 할 수 있습니다.

릴리스된 공간은 다음 조건에서 INSERT 문에 사용할 수 있습니다:

INSERT 문이 동일한 트랜잭션 내에 있으며, 공간을 해제한 문 이후에 있는 경우 해당 문은 공간을 사용할 수 있습니다.
INSERT 문이 공간을 해제한 문과 다른 트랜잭션(다른 사용자가 실행했을 수 있음) 내에 있으며, 공간이 필요하다면 다른 트랜잭션이 커밋된 후에만 사용 가능합니다.

참고:

Oracle Database Administrator’s Guide에서 고급 행 압축에 대해 알아보기

조각난 공간을 병합하여 최적화

릴리스된 공간은 데이터 블록의 주요 여유 공간 영역과 인접하지 않을 수 있습니다. 비연속적인 여유 공간을 조각난 공간이라고 합니다.

다음 그림은 조

각난 여유 공간을 가진 데이터 블록을 보여줍니다.

그림 12-11 조각난 공간이 있는 데이터 블록

그림 12-11의 설명이 뒤따릅니다
그림 12-11 조각난 공간이 있는 데이터 블록의 설명
Oracle Database는 다음 조건이 충족될 때만 데이터 블록의 여유 공간을 자동으로 병합합니다:

INSERT 또는 UPDATE 문이 새로운 행 조각을 포함할 수 있는 충분한 여유 공간이 있는 블록을 사용하려고 합니다.
여유 공간이 조각나서 행 조각을 블록의 연속된 섹션에 삽입할 수 없습니다.

병합 후, 여유 공간의 양은 작업 전과 동일하지만, 이제 공간은 연속적입니다. 그림 12-12는 공간이 병합된 후의 데이터 블록을 보여줍니다.

그림 12-12 여유 공간을 병합한 후의 데이터 블록

그림 12-12의 설명이 뒤따릅니다
그림 12-12 여유 공간을 병합한 후의 데이터 블록의 설명
Oracle Database는 성능 저하를 방지하기 위해 연속적으로 데이터 블록의 여유 공간을 병합하지 않기 때문에, 앞에서 설명한 상황에서만 병합을 수행합니다.

체인 및 마이그레이션된 행

Oracle Database는 단일 블록에 맞지 않는 행을 관리하기 위해 체인과 마이그레이션을 사용합니다.

참고: 표준 테이블의 체인된 행은 블록체인 테이블의 행 체인과 다릅니다. Oracle Database는 블록체인 테이블의 행을 관리하기 위해 다른 기술을 사용합니다.
다음 상황이 가능합니다:

행이 처음 삽입될 때 단일 데이터 블록에 맞지 않습니다.

행 체인에서는 Oracle Database가 세그먼트에 예약된 하나 이상의 데이터 블록 체인에 행의 데이터를 저장합니다. 행 체인은 주로 큰 행에서 발생합니다. 예를 들어, LONG 또는 LONG RAW 데이터 유형의 열을 포함한 행이나 엄청난 수의 열이 있는 행 등이 있습니다. 이러한 경우의 행 체인은 피할 수 없습니다.
원래 하나의 데이터 블록에 맞던 행이 업데이트되어 전체 행 길이가 증가하지만, 업데이트된 행을 수용할 충분한 여유 공간이 없습니다.

행 마이그레이션에서는 Oracle Database가 전체 행을 새로운 데이터 블록으로 이동합니다. 이동된 행의 원래 행 조각에는 마이그레이션된 행이 포함된 새로운 블록에 대한 포인터 또는 "포워딩 주소"가 포함됩니다. 마이그레이션된 행의 rowid는 변경되지 않습니다.
행에 255개 이상의 열이 있습니다.

Oracle Database는 하나의 행 조각에 255개의 열만 저장할 수 있습니다. 따라서 1000개의 열이 있는 테이블에 행을 삽입하면 데이터베이스는 일반적으로 여러 블록에 걸쳐 체인된 4개의 행 조각을 생성합니다.

그림 12-13은 큰 행을 데이터 블록에 삽입하는 것을 보여줍니다. 행이 왼쪽 블록에 맞지 않아서 데이터베이스는 첫 번째 행 조각을 왼쪽 블록에, 두 번째 행 조각을 오른쪽 블록에 배치하여 행을 체인합니다.

그림 12-13 행 체인

그림 12-13의 설명이 뒤따릅니다
그림 12-13 행 체인의 설명
그림 12-14에서는 왼쪽 블록에 행이 업데이트되어 행이 이제 블록에 맞지 않게 됩니다. 데이터베이스는 전체 행을 오른쪽 블록으로 이동하고 왼쪽 블록에 마이그레이션된 행에 대한 포인터를 남깁니다.

그림 12-14 행 마이그레이션

그림 12-14의 설명이 뒤따릅니다
그림 12-14 행 마이그레이션의 설명
행이 체인되거나 마이그레이션되면 데이터를 검색하는 데 필요한 I/O가 증가합니다. 이 상황은 Oracle Database가 행 정보를 검색하기 위해 여러 블록을 스캔해야 하기 때문에 발생합니다. 예를 들어, 데이터베이스가 인덱스를 읽기 위해 하나의 I/O를 수행하고 비마이그레이션된 테이블 행을 읽기 위해 하나의 I/O를 수행하는 경우, 마이그레이션된 행의 데이터를 얻기 위해 추가 I/O가 필요합니다.

Segment Advisor는 수동 및 자동으로 실행할 수 있는 Oracle Database 구성 요소로, 재사용 가능한 공간이 있는 세그먼트를 식별합니다. 어드바이저는 유의미한 여유 공간이나 너무 많은 체인된 행을 가진 객체에 대한 조언을 제공할 수 있습니다.

참고:

"행 저장소" 및 "행 조각의 rowid"

"블록체인 테이블 개요"

Oracle Database Administrator’s Guide에서 낭비된 공간을 회수하는 방법에 대해 알아보기

Oracle Database Performance Tuning Guide에서 체인된 및 마이그레이션된 행을 줄이는 방법에 대해 알아보기

인덱스 블록 개요

인덱스 블록은 테이블 블록과는 다르게 공간을 관리하는 특별한 유형의 데이터 블록입니다. Oracle Database는 인덱스의 논리적 저장 공간을 관리하기 위해 인덱스 블록을 사용합니다.

인덱스 블록의 유형

인덱스는 루트 블록, 브랜치 블록 및 리프 블록을 포함합니다.

블록 유형은 다음과 같이 정의됩니다:

루트 블록

이 블록은 인덱스로의 진입점을 식별합니다.
브랜치 블록

데이터베이스는 인덱스 키를 검색할 때 브랜치 블록을 통해 탐색합니다.
리프 블록

이 블록은 인덱싱된 키 값 rowid를 포함하여 관련된 행을 가리킵니다. 리프 블록은 키 값을 정렬된 순서로 저장하여 데이터베이스가 키 값 범위 내의 모든 행을 효율적으로 검색할 수 있도록 합니다.

인덱스 항목의 저장

인덱스 항목은 데이터 블록의 테이블 행과 같은 방식으로 인덱스 블록에 저장됩니다. 블록 부분의 인덱스 항목은 이진 순서로 저장되지 않고 힙에 저장됩니다.

데이터베이스는 데이터 블록의 디렉터리와는 다르게 인덱스 블록의 행 디렉터리를 관리합니다. 행 디렉터리의 항목(인덱스 블록 본문의 항목이 아님)은 키 값에 따라 정렬됩니다. 예를 들어, 행 디렉터리에서 인덱스 키 000000의 디렉터리 항목은 인덱스 키 111111의 디렉터리 항목보다 앞에 위치합니다.

행 디렉터리의 항목 정렬은 인덱스 스캔의 효율성을 향상시킵니다. 범위 스캔에서는 데이터베이스가 범위 내의 모든 인덱스 키를 읽어야 합니다. 데이터베이스는 첫 번째 키를 포함하는 리프 블록을 식별하기 위해 브랜치 블록을 탐색합니다. 행 디렉터리의 항목이 정렬되어 있기 때문에 데이터베이스는 범위 내의 첫 번째 인덱스 키를 찾기 위해 이진 검색을 사용할 수 있으며, 그런 다음 행 디렉터리의 항목을 순차적으로 진행하여 마지막 키를 찾을 때까지 진행합니다. 이렇게 하면 데이터베이스가 리프 블록 본문의 모든 키를 읽는 것을 피할 수 있습니다.

참고:

"데이터 블록 오버헤드"

인덱스 블록의 슬롯 재사용

데이터베이스는 인덱스 블록 내의 공간을 재사용할 수 있습니다.

예를 들어, 응용 프로그램이 열에 값을 삽입한 다음 값을 삭제할 수 있습니다. 행이 공간을 필요로 할 때 데이터베이스는 삭제된 값이 차지했던 인덱스 슬롯을 재사용할 수 있습니다.

인덱스 블록에는 일반적으로 힙 구성 테이블 블록보다 더 많은 행이 있습니다. 단일 인덱스 블록에 많은 행을 저장할 수 있는 능력은 데이터베이스가 인덱스를 유지 관리하기 쉽게 만듭니다. 왜냐하면 새로운 데이터를 저장하기 위해 블록을 자주 분할할 필요가 없기 때문입니다.

인덱스는 자체적으로 병합할 수 없지만, REBUILD 또는 COALESCE 옵션을 사용하여 ALTER INDEX 문으로 수동으로 병합할 수 있습니다. 예를 들어, 1에서 500000까지의 값을 열에 채우고 짝수 값을 포함하는 행을 삭제하면 인덱스에는 250,000개의 빈 슬롯이 포함됩니다. 데이터베이스는 빈 슬롯이 있는 인덱스 블록에 데이터를 삽입할 수 있을 때만 슬롯을 재사용합니다.

인덱스 블록 병합

인덱스 병합은 기존 인덱스 데이터를 제자리에 압축하고, 재구성된 블록

이 블록을 해제할 경우 인덱스 구조에 여유 블록을 남겨둡니다. 따라서 병합은 인덱스 블록을 다른 용도로 해제하거나 인덱스가 블록을 재할당하는 것을 유발하지 않습니다.

Oracle Database는 인덱스를 자동으로 압축하지 않습니다: REBUILD 또는 COALESCE 옵션을 사용하여 ALTER INDEX 문을 실행해야 합니다.

그림 12-15는 인덱스가 병합되기 전 employees.department_id 열의 인덱스를 보여줍니다. 첫 번째 세 리프 블록은 회색 채움선으로 표시된 대로 부분적으로만 채워져 있습니다.

그림 12-15 병합 전 인덱스

그림 12-15의 설명이 뒤따릅니다
그림 12-15 병합 전 인덱스의 설명
그림 12-16은 인덱스가 병합된 후 그림 12-15의 인덱스를 보여줍니다. 첫 두 리프 블록은 이제 회색 채움선으로 표시된 대로 가득 차 있으며, 세 번째 리프 블록은 해제되었습니다.

그림 12-16 병합 후 인덱스

그림 12-16의 설명이 뒤따릅니다
그림 12-16 병합 후 인덱스의 설명
참고:

Oracle Database Administrator’s Guide에서 인덱스를 병합하고 재구성하는 방법에 대해 알아보기

Oracle Database SQL Language Reference에서 COALESCE 문에 대해 알아보기

익스텐트 개요

익스텐트는 논리적으로 연속된 데이터 블록으로 구성된 데이터베이스 저장 단위입니다. 데이터 블록은 RAID 스트라이핑과 파일 시스템 구현으로 인해 디스크에 물리적으로 분산될 수 있습니다.

익스텐트 할당

기본적으로 데이터베이스는 세그먼트가 생성될 때 데이터 세그먼트에 대한 초기 익스텐트를 할당합니다. 익스텐트는 항상 하나의 데이터 파일에 포함됩니다.

세그먼트에 데이터가 추가되지 않았더라도 초기 익스텐트의 데이터 블록은 이 세그먼트에만 예약됩니다. 모든 세그먼트의 첫 번째 데이터 블록에는 세그먼트 내 익스텐트 디렉터리가 포함됩니다. 그림 12-17은 이전에 데이터가 포함되지 않은 데이터 파일에서 세그먼트의 초기 익스텐트를 보여줍니다.

그림 12-17 세그먼트의 초기 익스텐트

그림 12-17의 설명이 뒤따릅니다
그림 12-17 세그먼트의 초기 익스텐트의 설명
초기 익스텐트가 가득 차고 더 많은 공간이 필요하면 데이터베이스는 이 세그먼트에 대해 자동으로 증분 익스텐트를 할당합니다. 증분 익스텐트는 세그먼트에 대해 생성된 후속 익스텐트입니다.

할당 알고리즘은 테이블스페이스가 로컬 관리인지 사전 관리인지에 따라 다릅니다. 로컬 관리의 경우, 데이터베이스는 데이터 파일의 비트맵에서 인접한 여유 블록을 검색합니다. 데이터 파일에 충분한 공간이 없으면 데이터베이스는 다른 데이터 파일을 찾습니다. 세그먼트의 익스텐트는 항상 동일한 테이블스페이스에 있지만 다른 데이터 파일에 있을 수 있습니다.

그림 12-18은 데이터베이스가 테이블스페이스 내의 어떤 데이터 파일에서든 세그먼트에 대한 익스텐트를 할당할 수 있음을 보여줍니다. 예를 들어, 세그먼트는 users01.dbf에 초기 익스텐트를 할당하고, users02.dbf에 첫 번째 증분 익스텐트를 할당한 다음, users01.dbf에 다음 익스텐트를 할당할 수 있습니다.

그림 12-18 세그먼트의 증분 익스텐트

그림 12-18의 설명이 뒤따릅니다
그림 12-18 세그먼트의 증분 익스텐트의 설명
새로 할당된 익스텐트의 블록은 비어 있지 않을 수 있습니다. ASSM에서는 Oracle Database가 익스텐트를 사용하기 시작할 때 필요에 따라 새로 할당된 익스텐트의 블록을 포맷합니다.

참고: 이 섹션은 하나의 서버 프로세스가 문을 구문 분석하고 실행하는 일련의 작업에 적용됩니다. 병렬 SQL 문에서는 데이터베이스가 익스텐트를 다르게 할당합니다.

참고:

"세그먼트 공간과 고수위 마크"

Oracle Database Administrator’s Guide에서 익스텐트를 수동으로 할당하는 방법에 대해 알아보기

익스텐트 해제

일반적으로 사용자 세그먼트의 익스텐트는 객체를 DROP 문을 사용하여 삭제하지 않는 한 테이블스페이스로 돌아가지 않습니다.

예를 들어, 테이블의 모든 행을 삭제하면 데이터베이스는 테이블스페이스의 다른 객체에서 사용할 데이터 블록을 회수하지 않습니다. DBMS_SPACE_ADMIN 패키지를 사용하여 세그먼트를 삭제할 수도 있습니다.

참고: 언두 세그먼트에서는 Oracle Database가 OPTIMAL 크기가 지정되었거나 데이터베이스가 자동 언두 관리 모드일 때 주기적으로 하나 이상의 익스텐트를 해제합니다.

일부 상황에서는 수동으로 공간을 해제할 수 있습니다. Oracle Segment Advisor는 객체의 단편화 수준을 기준으로 회수 가능한 공간이 있는지 여부를 판단하는 데 도움이 됩니다. 다음 기술은 익스텐트를 해제할 수 있습니다:

세그먼트 축소를 온라인으로 수행하여 세그먼트의 단편화된 공간을 회수합니다. 세그먼트 축소는 온라인으로, 제자리에서 수행되는 작업입니다. 일반적으로 데이터 압축은 더 나은 캐시 활용을 이끌어 내며 전체 테이블 스캔 시 더 적은 블록을 읽는 데 필요합니다.
비파티션 테이블이나 테이블 파티션의 데이터를 새 세그먼트로 이동하고, 선택적으로 할당량이 있는 다른 테이블스페이스로 이동합니다.
인덱스를 재구성하거나 병합합니다.
테이블이나 테이블 클러스터를 잘라내어 모든 행을 제거합니다. 기본적으로 Oracle Database는 MINEXTENTS 저장 매개 변수로 지정된 공간을 제외하고 제거된 행이 사용한 모든 공간을 해제합니다. Oracle Database 11g 릴리스 2 (11.2.0.2)부터는 TRUNCATE를 DROP ALL STORAGE 옵션과 함께 사용하여 전체 세그먼트를 삭제할 수도 있습니다.
사용하지 않는 공간을 해제하여 데이터베이스 세그먼트의 고수위 마크 끝에 있는 사용되지 않는 공간을 해제하고, 이 공간을 테이블스페이스의 다른 세그먼트에 사용할 수 있게 합니다.

익스텐트가 해제되면, Oracle Database는 로컬 관리 테이블스페이스의 데이터 파일에 있는 비트맵을 수정하여 회수된 익스텐트를 사용 가능한 공간으로 반영합니다. 해제된 익스텐트의 블록에 있는 데이터는 접근할 수 없게 됩니다.

참고:

"인덱스 블록 병합"

"언두 테이블스페이스"

"세그먼트 공간과 고수위 마크"

Oracle Database Administrator’s Guide에서 세그먼트 공간을 회수하는 방법에 대해 알아보기

익스텐트를 위한 저장 매개 변수

모든 세그먼트는 익스텐트 단위로 표현된 저장 매개 변수에 의해 정의됩니다. 이러한 매개 변수는 Oracle Database가 세그먼트를 위해 여유 공간을 할당하는 방식을 제어합니다.

저장 설정은 다음 우선순위 순서로 결정되며, 목록 상단의 설정이 목록 하단의 설정을 무효화합니다:

세그먼트 저장 절
테이블스페이스 저장 절
Oracle Database 기본값

로컬 관리 테이블스페이스는 고정된 익스텐트 크기나 시스템이 자동으로 결정한 가변 익스텐트 크기를 가질 수 있습니다:

고정된 익스텐트의 경우, 익스텐트 크기를 지정하거나 1MB의 기본 크기를 사용할 수 있습니다. 테이블스페이스의 모든 익스텐트는 이 크기를 가집니다. 로컬 관리 임시 테이블스페이스는 이 유형의 할당만 사용할 수 있습니다.
자동 할당된 익스텐트의 경우, Oracle Database는 추가 익스텐트의 최적 크기를 결정합니다.

로컬 관리 테이블스페이스의 경우, 일부 저장 매개 변수는 테이블스페이스 수준에서 지정할 수 없습니다. 그러나 세그먼트 수준에서 이러한 매개 변수를 지정할 수 있습니다. 이 경우, 데이터베이스는 모든 매개 변수를 함께 사용하여 세그먼트의 초기 크기를 계산합니다. 내부 알고리즘은 각 익스텐트의 후속 크기를 결정합니다.

참고:

Oracle Database Administrator’s Guide에서 로컬 관리 테이블스페이스를 생성할 때 익스텐트 관리 고려 사항에 대해 알아보기

Oracle Database SQL Language Reference에서 저장 절의 옵션에 대해 알아보기

세그먼트 개요

세그먼트는 테이블스페이스 내의 논리적 저장 구조에 대한 모든 데이터를 포함하는 익스텐트 집합입니다.

예를 들어, Oracle Database는 테이블의 데이터 세그먼트를 형성하기 위해 하나 이상의 익스텐트를 할당합니다. 또한, 데이터베이스는 테이블에 대한 인덱스 세그먼트를 형성하기 위해 하나 이상의 익스텐트를 할당합니다.

Oracle Database는 세그먼트 공간을 자동 또는 수동으로 관리합니다. 이 섹션에서는 ASSM(Automatic Segment Space Management)을 사용하는 것으로 가정합니다.

참고:

"논리적 공간 관리"에서 ASSM에 대해 더 알아보기

사용자 세그먼트

데이터베이스의 단일 데이터 세그먼트는 하나의 사용자 객체에 대한 데이터를 저장합니다.

세그먼트에는 다양한 유형이 있습니다. 사용자 세그먼트의 예로는 다음이 포함됩니다:

테이블, 테이블 파티션 또는 테이블 클러스터
LOB 또는 LOB 파티션
인덱스 또는 인덱스 파티션

각 비파티션 객체와 객체 파티션은 자체 세그먼트에 저장됩니다. 예를 들어, 인덱스가 5개의 파티션을 가지고 있다면, 5개의 세그먼트가 인덱스 데이터를 포함합니다.

사용자 세그먼트 생성

기본적으로 데이터베이스는 테이블, 인덱스 및 파티션을 생성할 때 데이터베이스 메타데이터만 업데이트하는 지연된 세그먼트 생성을 사용합니다.

사용자가 테이블 또는 파티션에 첫 번째 행을 삽입하면, 데이터베이스는 테이블 또는 파티션, 해당 LOB 열 및 인덱스에 대한 세그먼트를 생성합니다. 지연된 세그먼트 생성은 불필요하게 데이터베이스 리소스를 사용하는 것을 방지합니다. 예를 들어, 애플리케이션을 설치할 때 수천 개의 객체를 생성하여 상당한 디스크 공간을 소비할 수 있습니다. 이러한 객체 중 많은 수가 실제로 사용되지 않을 수 있습니다.

DBMS_SPACE_ADMIN 패키지는 비어 있는 객체에 대한 세그먼트를 관리합니다. 이 PL/SQL 패키지를 사용하여 다음 작업을 수행할 수 있습니다:

세그먼트가 생성되지 않은 비어 있는 테이블이나 파티션에 대해 세그먼트를 수동으로 물질화합니다.
현재 비어 있는 세그먼트가 할당된 비어 있는 테이블이나 파티션에서 세그먼트를 제거합니다.

객체 생성과 세그먼트 생성 간의 관계를 가장 잘 설명하기 위해 지연된 세그먼트 생성이 비활성화된 것으로 가정합니다. 다음과 같이 테이블을 생성합니다:

CREATE TABLE test_table (my_column NUMBER);

그림 12-19에서 볼 수 있듯이, 데이터베이스는 테이블에 대해 하나의 세그먼트를 생성합니다.

그림 12-19 사용자 세그먼트 생성

그림 12-19의 설명이 뒤따릅니다
그림 12-19 사용자 세그먼트 생성의 설명
기본 키 또는 고유 키가 있는 테이블을 생성할 때 Oracle Database는 이 키에 대해 자동으로 인덱스를 생성합니다. 다시 지연된 세그먼트 생성이 비활성화된 것으로 가정합니다. 다음과 같이 테이블을 생성합니다:

CREATE TABLE lob_table (my_column NUMBER PRIMARY KEY, clob_column CLOB);

그림 12-20은 lob_table의 데이터가 하나의 세그먼트에 저장되고, 암시적으로 생성된 인덱스가 다른 세그먼트에 있으며, CLOB 데이터가 자체 세그먼트에 저장되고, 관련 CLOB 인덱스도 자체 세그먼트에 저장됨을 보여줍니다. 따라서 CREATE TABLE 문은 네 개의 다른 세그먼트를 생성합니다.

그림 12-20 여러 세그먼트

그림 12-20의 설명이 뒤따릅니다
그림 12-20 여러 세그먼트의 설명
참고: 테이블과 이 테이블에 대한 인덱스의 세그먼트는 동일한 테이블스페이스를 차지할 필요는 없습니다.
데이터베이스는 세그먼트가 생성될 때 하나 이상의 익스텐트를 할당합니다. 객체에 대한 저장 매개 변수가 각 세그먼트의 익스텐트를 할당하는 방식을 결정합니다. 이 매개 변수는 객체와 관련된 데이터 세그먼트의 데이터 검색 및 저장 효율성에 영향을 미칩니다.

참고:

"내부 LOB"

"익스텐트를 위한 저장 매개 변수"

Oracle Database Administrator’s Guide에서 지연된 세그먼트 생성 관리에 대해 알아보기

Oracle Database SQL Language Reference에서 CREATE TABLE 구문에 대해 알아보기

임시 세그먼트

쿼리를 처리할 때, Oracle Database는 SQL 문 실행의 중간 단계에 대해 종종 임시 작업 공간을 필요로 합니다.

일반적으로 임시 세그먼트를 필요로 하는 작업에는 정렬, 해싱 및 비트맵 병합이 포함됩니다. 인덱스를 생성할 때도 Oracle Database는 인덱스 세그먼트를 임시 세그먼트에 배치한 후 인덱스가 완료되면 이를 영구 세그먼트로 변환합니다.

작업이 메모리에서 수행될 수 있는 경우 Oracle Database는 임시 세그먼트를 생성하지 않습니다. 그러나 메모리 사용이 불가능한 경우 데이터베이스는 디스크에 임시 세그먼트를 자동으로 할당합니다.

쿼리에 대한 임시 세그먼트 할당

Oracle Database는 사용자 세션 동안 필요한 경우 쿼리에 대해 임시 세그먼트를 할당하고 쿼리가 완료되면 이를 삭제합니다. 임시 세그먼트에 대한 변경 사항은 임시 세그먼트에 대한 공간 관리 작업을 제외하고는 온라인 리두 로그에 기록되지 않습니다.

데이터베이스는 사용자에게 할당된 임시 테이블스페이스에 임시 세그먼트를 생성합니다. 테이블스페이스의 기본 저장 특성이 임시 세그먼트의 익스텐트 특성을 결정합니다. 임시 세그먼트의 할당 및 해제가 자주 발생하기 때문에, 임시 세그먼트를 위한 특수 테이블스페이스를 최소한 하나 이상 생성하는 것이 가장 좋습니다. 데이터베이스는 디스크 간의 I/O를 분산시키고 SYSTEM 및 기타 테이블스페이스의 단편화를 피합니다.

참고: SYSTEM이 로컬 관리되는 경우 데이터베이스 생성 시 기본 임시 테이블스페이스를 정의해야 합니다. 로컬 관리 SYSTEM 테이블스페이스는 기본 임시 저장에 사용할 수 없습니다.

참고:

"온라인 리두 로그 개요"
Oracle Database Administrator's Guide에서 임시 테이블스페이스 생성 방법에 대해 알아보기

Oracle Database SQL Language Reference에서 CREATE TEMPORARY TABLESPACE 구문 및 의미에 대해 알아보기

임시 테이블 및 인덱스에 대한 세그먼트 할당

Oracle Database는 임시 테이블과 해당 인덱스에 대한 임시 세그먼트를 할당할 수 있습니다.

임시 테이블은 트랜잭션 또는 세션 동안에만 존재하는 데이터를 보유합니다. 각 세션은 자신에게 할당된 익스텐트에만 접근할 수 있으며 다른 세션에 할당된 익스텐트에는 접근할 수 없습니다.

Oracle Database는 첫 번째 INSERT가 발생할 때 글로벌 임시 테이블에 대한 세그먼트를 할당하며, 필요한 경우에만 프라이빗 임시 테이블에 대한 세그먼트를 할당합니다. 삽입은 명시적으로 발생할 수 있으며 CREATE TABLE AS SELECT로 인해 발생할 수도 있습니다. 데이터베이스는 테이블 및 해당 인덱스에 대한 세그먼트를 할당하고, 인덱스의 루트 페이지를 생성하며, 필요한 모든 LOB 세그먼트를 할당합니다.

현재 사용자의 임시 테이블스페이스는 임시 테이블에 대한 세그먼트를 할당합니다. 예를 들어, user1에게 할당된 임시 테이블스페이스는 temp1이고 user2에게 할당된 임시 테이블스페이스는 temp2입니다. 이 경우, user1은 temp1 세그먼트에 임시 데이터를 저장하고, user2는 temp2 세그먼트에 임시 데이터를 저장합니다.

참고:

"임시 테이블 개요"

Oracle Database Administrator’s Guide에서 임시 테이블 생성 방법에 대해 알아보기

언두 세그먼트

Oracle Database는 트랜잭션의 작업 기록을 유지하며 이를 언두 데이터라고 합니다.

Oracle Database는 언두 데이터를 사용하여 다음을 수행합니다:

활성 트랜잭션 롤백
종료된 트랜잭션 복구
일관된 읽기 제공
일부 논리적 플래시백 작업 수행

Oracle Database는 언두 데이터를 외부 로그가 아닌 데이터베이스 내에 저장합니다. 언두 데이터는 데이터 블록과 마찬가지로 블록에 저장되며, 이 블록의 변경 사항은 리

두 레코드를 생성합니다. 이렇게 해서 Oracle Database는 외부 로그를 읽을 필요 없이 효율적으로 언두 데이터에 접근할 수 있습니다.

영구 객체에 대한 언두 데이터는 언두 테이블스페이스에 저장됩니다. Oracle Database는 언두 세그먼트와 언두 테이블스페이스의 공간을 관리하는 자동화된 메커니즘을 제공하며 이를 자동 언두 관리 모드라고 합니다.

데이터베이스는 언두 데이터를 두 개의 스트림으로 분리합니다. 임시 언두 스트림은 임시 객체의 변경으로 생성된 언두 레코드만 포함하며, 영구 언두 스트림은 영구 객체의 언두 레코드만 포함합니다. 데이터베이스는 임시 및 영구 언두를 독립적으로 관리합니다. 언두 분리는 다음과 같은 방법으로 저장소를 줄이고 성능을 향상시킵니다:

영구 및 언두 테이블스페이스 크기를 워크로드에 맞게 구성할 수 있습니다.
온라인 리두 로그에 기록되는 리두의 크기를 줄입니다.
임시 언두 데이터를 백업할 필요가 없습니다.

Active Data Guard 인스턴스에서는 글로벌 임시 테이블에 대한 DML이 임시 언두 세그먼트에서 언두를 생성해야 합니다.

참고:

"온라인 리두 로그 사용"

"임시 언두 세그먼트"

Oracle Database Administrator’s Guide에서 임시 언두 세그먼트에 대해 알아보기

Oracle Database Reference에서 TEMP_UNDO_ENABLED 초기화 매개 변수에 대해 알아보기

언두 세그먼트와 트랜잭션

트랜잭션이 시작되면 데이터베이스는 트랜잭션을 현재 언두 테이블스페이스의 언두 세그먼트(따라서 트랜잭션 테이블)에 바인딩(할당)합니다. 드문 경우로 데이터베이스 인스턴스에 지정된 언두 테이블스페이스가 없으면 트랜잭션은 시스템 언두 세그먼트에 바인딩됩니다.

여러 활성 트랜잭션이 동일한 언두 세그먼트 또는 다른 세그먼트에 동시에 기록할 수 있습니다. 예를 들어, 트랜잭션 T1과 T2가 모두 언두 세그먼트 U1에 기록하거나 T1은 U1에, T2는 언두 세그먼트 U2에 기록할 수 있습니다.

개념적으로 언두 세그먼트의 익스텐트는 링을 형성합니다. 트랜잭션은 하나의 언두 익스텐트에 기록한 다음 링의 다음 익스텐트에 기록하는 방식으로 순환합니다. 그림 12-21은 두 트랜잭션 T1과 T2가 언두 세그먼트의 세 번째 익스텐트(E3)에서 기록을 시작하여 네 번째 익스텐트(E4)로 계속 기록하는 것을 보여줍니다.

그림 12-21 언두 세그먼트의 할당된 익스텐트 링

그림 12-21의 설명이 뒤따릅니다
그림 12-21 언두 세그먼트의 할당된 익스텐트 링의 설명
어느 시점에서든 트랜잭션은 트랜잭션에 대한 현재 익스텐트로 알려진 하나의 익스텐트에 순차적으로 기록합니다. 여러 활성 트랜잭션이 동일한 현재 익스텐트 또는 다른 현재 익스텐트에 동시에 기록할 수 있습니다. 그림 12-21은 트랜잭션 T1과 T2가 동시에 익스텐트 E3에 기록하는 것을 보여줍니다. 언두 익스텐트 내에서 데이터 블록은 하나의 트랜잭션에 대한 데이터만 포함합니다.

현재 언두 익스텐트가 가득 차면, 공간이 필요한 첫 번째 트랜잭션은 링의 다음 할당된 익스텐트의 가용성을 확인합니다. 다음 익스텐트에 활성 트랜잭션의 데이터가 포함되어 있지 않으면 이 익스텐트가 현재 익스텐트가 됩니다. 이제 공간이 필요한 모든 트랜잭션이 새 현재 익스텐트에 기록할 수 있습니다. 그림 12-22에서 E4가 가득 차면 T1과 T2는 E1에 기록을 계속하여 E1의 비활성 언두 데이터를 덮어씁니다.

그림 12-22 언두 세그먼트에서 할당된 익스텐트의 순환적 사용

그림 12-22의 설명이 뒤따릅니다
그림 12-22 언두 세그먼트에서 할당된 익스텐트의 순환적 사용의 설명
다음 익스텐트에 활성 트랜잭션의 데이터가 포함되어 있으면 데이터베이스는 새 익스텐트를 할당해야 합니다. 그림 12-23은 T1과 T2가 E4에 기록하고 있는 시나리오를 보여줍니다. E4가 가득 차면 트랜잭션은 E1에 기록을 계속할 수 없으므로 E1에는 활성 언두 항목이 포함됩니다. 따라서 데이터베이스는 이 언두 세그먼트에 새 익스텐트(E5)를 할당합니다. 트랜잭션은 E5에 기록을 계속합니다.

그림 12-23 언두 세그먼트에 대한 새 익스텐트 할당

그림 12-23의 설명이 뒤따릅니다
그림 12-23 언두 세그먼트에 대한 새 익스텐트 할당의 설명
참고:

Oracle Database Administrator’s Guide에서 언두 세그먼트를 관리하는 방법에 대해 알아보기

트랜잭션 롤백

ROLLBACK 문이 발행되면 데이터베이스는 언두 레코드를 사용하여 커밋되지 않은 트랜잭션에 의해 데이터베이스에 적용된 변경 사항을 롤백합니다.

복구 중에 데이터베이스는 온라인 리두 로그에서 데이터 파일로 적용된 커밋되지 않은 변경 사항을 롤백합니다. 언두 레코드는 다른 사용자가 데이터를 변경하는 동안 데이터를 액세스하는 사용자에게 데이터의 이전 이미지를 유지하여 읽기 일관성을 제공합니다.

임시 언두 세그먼트

임시 언두 세그먼트는 임시 언두 데이터 전용의 선택적 공간 관리 컨테이너입니다.

임시 테이블에 대한 변경 사항에 대한 언두 레코드는 세션별이며 읽기 일관성 및 트랜잭션 롤백에만 유용합니다. Oracle Database 12c 이전에는 데이터베이스가 항상 이러한 레코드를 온라인 리두 로그에 저장했습니다. 임시 객체의 변경 사항은 온라인 리두 로그에 기록되지 않으므로, 임시 언두 세그먼트에 임시 객체의 언두를 기록하면 온라인 리두 로그 및 아카이브 리두 로그 파일의 공간을 절약할 수 있습니다. 데이터베이스는 언두 변경 사항이나 임시 테이블의 변경 사항을 기록하지 않으므로 성능이 향상됩니다.

TEMP_UNDO_ENABLED 초기화 매개 변수를 설정하여 임시 테이블이 임시 언두 세그먼트에 언두 데이터를 저장하도록 할 수 있습니다. 이 매개 변수가 TRUE인 경우, 데이터베이스는 임시 테이블스페이스에서 임시 언두 세그먼트를 할당합니다.

참고:

Oracle Database Administrator’s Guide에서 임시 언두 세그먼트에 대해 알아보기

Oracle Database Reference에서 TEMP_UNDO_ENABLED 초기화 매개 변수에 대해 알아보기

세그먼트 공간과 고수위 마크

공간을 관리하기 위해 Oracle Database는 세그먼트의 블록 상태를 추적합니다. 고수위 마크(HWM)는 세그먼트에서 데이터 블록이 포맷되지 않았고 사용된 적이 없는 지점을 나타냅니다.

MSSM은 자유 목록을 사용하여 세그먼트 공간을 관리합니다. 테이블 생성 시 세그먼트의 블록은 포맷되지 않습니다. 세션이 테이블에 처음 행을 삽입하면 데이터베이스는 사용 가능한 블록을 찾기 위해 자유 목록을 검색합니다. 데이터베이스가 사용 가능한 블록을 찾지 못하면 블록 그룹을 미리 포맷하고 이를 자유 목록에 추가한 다음 블록에 데이터를 삽입하기 시작합니다. MSSM에서는 전체 테이블 스캔이 HWM 이하의 모든 블록을 읽습니다.

ASSM은 자유 목록을 사용하지 않으므로 공간을 다르게 관리해야 합니다. 세션이 테이블에 데이터를 처음 삽입할 때 데이터베이스는 MSSM에서와 같이 블록 그룹을 미리 포맷하는 대신 단일 비트맵 블록을 포맷합니다. 비트맵은 세그먼트의 블록 상태를 추적하여 자유 목록을 대체합니다. 데이터베이스는 비트맵을 사용하여 여유 블록을 찾고, 각 블록을 포맷한 후 데이터를 채웁니다. ASSM은 동시성 문제를 피하기 위해 블록 간의 삽입을 분산시킵니다.

ASSM 세그먼트의 모든 데이터 블록은 다음 상태 중 하나에 있습니다:

WM 위

이 블록은 포맷되지 않았으며 사용된 적이 없습니다.

HWM 아래

이 블록은 다음 상태 중 하나에 있습니다:
- 할당되었지만 현재 포맷되지 않고 사용되지 않음
- 포맷되어 데이터가 포함됨
- 데이터가 삭제되어 포맷되었지만 비어 있음

그림 12-24는 ASSM 세그먼트를 가로로 배열된 블록 시리즈로 보여줍니다. 테이블 생성 시 HWM은 왼쪽의 세그먼트 시작 지점에 있습니다. 아직 데이터가 삽입되지 않았기 때문에 세그먼트의 모든 블록은 포맷되지 않았고 사용된 적이 없습니다.

그림 12-24 테이블 생성 시 HWM

그림 12-24의 설명이 뒤따릅니다
그림 12-24 테이블 생성 시 HWM의 설명
세그먼트에 행을 삽입한다고 가정합니다. 데이터베이스는 행을 저장하기 위해 블록 그룹을 할당해야 합니다. 할당된 블록은 HWM 아래에 있습니다. 데이터베이스는 이 그룹에서 비트맵 블록을 포맷하여 메타데이터를 저장하지만 나머지 블록은 미리 포맷하지 않습니다.

그림 12-25에서 HWM 아래의 블록은 할당되었지만, HWM 위의 블록은 할당되거나 포맷되지 않았습니다. 삽입이 발생하면 데이터베이스는 여유 공간이 있는 블록에 기록할 수 있습니다. 낮은 고수위 마크(low HWM)는 모든 블록이 데이터가 포함되어 있거나 데이터가 포함되었던 포맷된 지점을 나타냅니다.

그림 12-25 HWM과 낮은 HWM

그림 12-25의 설명이 뒤따릅니다
그림 12-25 HWM과 낮은 HWM의 설명
그림 12-26에서 데이터베이스는 HWM과 낮은 HWM 사이의 블록을 선택하여 기록합니다. 데이터베이스는 여유 공간이 있는 HWM과 낮은 HWM 사이의 다른 블록이나 낮은 HWM 이하의 여유 공간이 있는 블록을 선택할 수 있습니다. 그림 12-26에서 새로 채워진 블록의 양쪽 블록은 포맷되지 않았습니다.

그림 12-26 HWM과 낮은 HWM

그림 12-26의 설명이 뒤따릅니다
그림 12-26 HWM과 낮은 HWM의 설명
낮은 HWM은 전체 테이블 스캔에서 중요합니다. HWM 이하의 블록은 사용될 때만 포맷되므로 일부 블록은 포맷되지 않을 수 있습니다. 이러한 이유로 데이터베이스는 비트맵 블록을 읽어 낮은 HWM의 위치를 확인합니다. 데이터베이스는 포맷된 것으로 알려진 낮은 HWM까지의 모든 블록을 읽고, HWM과 낮은 HWM 사이의 포맷된 블록만 신중하게 읽습니다.

새 트랜잭션이 테이블에 행을 삽입하지만 비트맵이 HWM 아래에 충분한 여유 공간이 없음을 나타낸다고 가정합니다. 그림 12-27에서 데이터베이스는 HWM을 오른쪽으로 이동하여 새로운 포맷되지 않은 블록 그룹을 할당합니다.

그림 12-27 HWM과 낮은 HWM의 이동

그림 12-27의 설명이 뒤따릅니다
그림 12-27 HWM과 낮은 HWM의 이동의 설명
HWM과 낮은 HWM 사이의 블록이 가득 차면 HWM은 오른쪽으로 이동하고 낮은 HWM은 이전 HWM의 위치로 이동합니다. 데이터베이스가 시간이 지남에 따라 데이터를 삽입하면 HWM은 계속 오른쪽으로 이동하고 낮은 HWM은 항상 그 뒤를 따릅니다. 객체를 수동으로 재구성, 잘라내기 또는 축소하지 않는 한 HWM은 결코 후퇴하지 않습니다.

참고:

Oracle Database Administrator’s Guide에서 온라인으로 세그먼트를 축소하는 방법에 대해 알아보기

Oracle Database SQL Language Reference에서 TRUNCATE TABLE 구문 및 의미에 대해 알아보기

테이블스페이스 개요

테이블스페이스는 세그먼트를 위한 논리적 저장소입니다. 세그먼트는 저장 공간을 소비하는 테이블 및 인덱스와 같은 데이터베이스 객체입니다. 물리적 수준에서 테이블스페이스는 하나 이상의 데이터 파일 또는 임시 파일에 데이터를 저장합니다.

데이터베이스에는 SYSTEM 및 SYSAUX 테이블스페이스가 반드시 필요합니다. 다음 그림은 일반적인 데이터베이스의 테이블스페이스를 보여줍니다. 다음 섹션에서는 테이블스페이스 유형을 설명합니다.

그림 12-28 테이블스페이스

그림 12-28의 설명이 뒤따릅니다
그림 12-28 테이블스페이스의 설명

영구 테이블스페이스

영구 테이블스페이스는 지속적인 스키마 객체를 그룹화합니다. 테이블스페이스 내 객체의 세그먼트는 물리적으로 데이터 파일에 저장됩니다.

각 데이터베이스 사용자에게는 기본 영구 테이블스페이스가 할당됩니다. 매우 작은 데이터베이스는 기본 SYSTEM 및 SYSAUX 테이블스페이스만 필요할 수 있습니다. 그러나 Oracle은 사용자 및 애플리케이션 데이터를 저장할 하나 이상의 테이블스페이스를 생성할 것을 권장합니다. 테이블스페이스를 사용하여 다음과 같은 목표를 달성할 수 있습니다:

데이터베이스 데이터에 대한 디스크 공간 할당 제어
데이터베이스 사용자에게 할당량(공간 허용량 또는 제한)을 할당
전체 데이터베이스의 가용성에 영향을 주지 않고 개별 테이블스페이스를 온라인 또는 오프라인으로 전환
개별 테이블스페이스의 백업 및 복구 수행
Oracle Data Pump 유틸리티를 사용하여 애플리케이션 데이터 가져오기 또는 내보내기
테이블스페이스를 다른 데이터베이스로 복사하거나 이동할 수 있는 이동 가능한 테이블스페이스 생성

테이블스페이스를 이동하면 데이터 파일 복사 및 테이블스페이스 메타데이터 통합만 필요하므로 동일한 데이터의 내보내기/가져오기 또는 언로드/로드보다 훨씬 빠를 수 있습니다. 테이블스페이스를 이동할 때 인덱스 데이터도 이동할 수 있습니다.

참고:

"Oracle Data Pump 내보내기 및 가져오기"

Oracle Database Administrator’s Guide에서 테이블스페이스를 이동하는 방법에 대해 알아보기

Oracle Database Utilities에서 Oracle Data Pump에 대해 알아보기

SYSTEM 테이블스페이스

SYSTEM 테이블스페이스는 데이터베이스 생성 시 포함되는 필수 관리 테이블스페이스입니다. Oracle Database는 SYSTEM을 사용하여 데이터베이스를 관리합니다.

SYSTEM 테이블스페이스에는 다음 정보가 포함되며, 모두 SYS 사용자가 소유합니다:

데이터 사전
데이터베이스에 대한 관리 정보를 포함하는 테이블 및 뷰
트리거, 프로시저 및 패키지와 같은 컴파일된 저장 객체

SYSTEM 테이블스페이스는 다른 테이블스페이스와 동일하게 관리되지만 더 높은 수준의 권한이 필요하며 몇 가지 제한이 있습니다. 예를 들어, SYSTEM 테이블스페이스의 이름을 변경하거나 삭제할 수 없습니다.

기본적으로 Oracle Database는 새로 생성된 모든 사용자 테이블스페이스를 로컬 관리로 설정합니다. 로컬 관리 SYSTEM 테이블스페이스가 있는 데이터베이스에서는 사전 관리 테이블스페이스를 생성할 수 없습니다(사전 관리 테이블스페이스는 사용 중지됨). 그러나 CREATE DATABASE 문을 수동으로 실행하고 기본값을 수락하면 SYSTEM 테이블스페이스가 사전 관리됩니다. 기존 사전 관리 SYSTEM 테이블스페이스를 로컬 관리 형식으로 마이그레이션할 수 있습니다.

참고: Oracle은 Database Configuration Assistant(DBCA)를 사용하여 새 데이터베이스를 생성하여 모든 테이블스페이스, 특히 SYSTEM이 기본적으로 로컬 관리되도록 할 것을 강력히 권장합니다.

참고:

"온라인 및 오프라인 테이블스페이스"에서 SYSTEM 테이블스페이스의 영구 온라인 상태에 대한 정보

"데이터베이스 설치 및 구성 도구"에서 DBCA에 대해 알아보기

Oracle Database Administrator’s Guide에서 로컬 관리 SYSTEM 테이블스페이스를 생성하거나 마이그레이션하는 방법에 대해 알아보기

Oracle Database SQL Language Reference에서 CREATE DATABASE 구문 및 의미에 대해 알아보기

SYSAUX 테이블스페이스

SYSAUX 테이블스페이스는 SYSTEM 테이블스페이스의 보조 테이블스페이스입니다.

SYSAUX는 이전에 자체 테이블스페이스가 필요했던 많은 Oracle Database 기능 및 제품의 기본 테이블스페이스이므로 데이터베이스에서 필요한 테이블스페이스 수를 줄입니다. 또한 SYSTEM 테이블스페이스의 부하를 줄입니다.

데이터베이스 생성 또는 업그레이드 시 SYSAUX 테이블스페이스가 자동으로 생성됩니다. 정상적인 데이터베이스 운영 중에는 SYSAUX 테이블스페이스를 삭제하거나 이름을 변경할 수 없습니다. SYSAUX 테이블스페이스가 사용 불가능해지면 핵심 데이터베이스 기능은 계속 작동하지만, SYSAUX 테이블스페이스를 사용하는 데이터베이스 기능은 실패하거나 제한된 기능으로 작동할 수 있습니다.

참고:

Oracle Database Administrator’s Guide에서 SYSAUX 테이블스페이스에 대해 알아보기

언두 테이블스페이스

언두 테이블스페이스는 시스템 관리 언두 데이터에 예약된 로컬 관리 테이블스페이스입니다.

다른 영구 테이블스페이스와 마찬가지로 언두 테이블스페이스는 데이터 파일을 포함합니다. 이 파일의 언두 블록은 익스텐트로 그룹화됩니다.

참고:

"언두 세그먼트"

자동 언두 관리 모드

언두 테이블스페이스는 데이터베이스가 기본 자동 언두 모드에 있어야 합니다.

자동 모드는 언두 세그먼트를 수동으로 관리하는 복잡성을 제거합니다. 데이터베이스는 장시간 실행되는 쿼리에 필요한 언두 데이터를 최상의 보존하기 위해 자동으로 조정됩니다.

새 Oracle Database 설치는 자동으로 언두 테이블스페이스를 생성합니다. 이전 버전의 Oracle Database는 언두 테이블스페이스를 포함하지 않으며 수동 언두 관리 모드라고 하는 레거시 롤백 세그먼트를 사용합니다. Oracle Database 11g 이상으로 업그레이드할 때 자동 언두 관리 모드를 활성화하고 언두 테이블스페이스를 생성할 수 있습니다. Oracle Database는 언두 환경에 대한 조언을 제공하고 자동화하는 언두 어드바이저를 포함합니다.

데이터베이스는 여러 언두 테이블스페이스를 포함할 수 있지만, 한 번에 하나만 사용할 수 있습니다. 인스턴스가 데이터베이스를 열려고 시도할 때 Oracle Database는 자동으로 첫 번째 사용 가능한 언두 테이블스페이스를 선택합니다. 사용 가능한 언두 테이블스페이스가 없으면 인스턴스는 언두 테이블스페이스 없이 시작되며 SYSTEM 테이블스페이스에 언두 데이터를 저장합니다. SYSTEM에 언두 데이터를 저장하는 것은 권장되지 않습니다.

참고:

Oracle Database Administrator’s Guide에서 자동 언두 관리에 대해 알아보기

Oracle Database Upgrade Guide에서 자동 언두 관리 모드로 마이그레이션하는 방법에 대해 알아보기

자동 언두 보존

언두 보존 기간은 Oracle Database가 오래된 언두 데이터를 덮어쓰지 않고 유지하려고 시도하는 최소 시간입니다.

언두 보존은 중요합니다. 장시간 실행되는 쿼리는 일관된 읽기를 제공하기 위해 오래된 블록 이미지를 필요로 할 수 있습니다. 또한 일부 Oracle Flashback 기능은 언두 데이터의 가용성에 의존할 수 있습니다.

일반적으로 오래된 언두 데이터를 가능한 한 오래 유지하는 것이 바람직합니다. 트랜잭션이 커밋되면 언두 데이터는 롤백이나 트랜잭션 복구에 더 이상 필요하지 않습니다. 언두 테이블스페이스에 새 트랜잭션을 위한 공간이 있는 경우 데이터베이스는 오래된 언두 데이터를 유지할 수 있습니다. 사용 가능한 공간이 적으면 데이터베이스는 커밋된 트랜잭션의 오래된 언두 데이터를 덮어쓰며 시작합니다.

Oracle Database는 현재 언두 테이블스페이스에 대해 최상의 언두 보존을 자동으로 제공합니다. 데이터베이스는 사용 통계를 수집하고 이러한 통계 및 언두 테이블스페이스 크기에 따라 보존 기간을 조정합니다. 언두 테이블스페이스가 AUTOEXTEND 옵션으로 구성되어 있고 최대 크기가 지정되지 않은 경우 언두 보존 조정이 다릅니다. 이 경우 데이터베이스는 가능한 경우 가장 오래 실행되는 쿼리보다 약간 더 긴 언두 보존 기간을 조정합니다.

참고:

Oracle Database Administrator’s Guide에서 자동 언두 보존 조정에 대한 자세한 내용

쉐도우 테이블스페이스

쉐도우 테이블스페이스는

쉐도우 손실 쓰기 보호를 위한 빅파일 테이블스페이스입니다.

참고: 쉐도우 손실 쓰기 보호는 DB_LOST_WRITE_PROTECT 초기화 매개 변수 및 대기 데이터베이스로 구성된 손실 쓰기 보호와 관련이 없습니다.

쉐도우 테이블스페이스의 목적

쉐도우 손실 쓰기 보호는 손실 쓰기를 빠르게 감지하고 즉각적인 대응을 제공합니다.

데이터 블록 손실 쓰기는 I/O 하위 시스템이 블록 쓰기 완료를 확인했지만 실제로 쓰기가 발생하지 않거나 이전 이미지가 현재 이미지를 덮어쓸 때 발생합니다.

감지되지 않은 손실 쓰기는 잘못된 데이터가 다른 DML 트랜잭션에 사용될 수 있으므로 데이터 손상으로 이어질 수 있습니다. 예를 들어, 트랜잭션이 한 테이블에서 오래되고 잘못된 데이터를 읽고 이 데이터를 기반으로 수백 개의 다른 테이블을 업데이트할 수 있습니다. 이렇게 하면 데이터 손상이 데이터베이스 전체로 확산될 수 있습니다.

쉐도우 손실 쓰기 보호는 다음과 같은 이점을 제공합니다:

표준 DML, SQL*Loader 일반 경로 로드, 직접 경로 로드 및 RMAN 백업에 대해 손실 쓰기 전에 감지합니다.
Oracle Database 11g에 도입된 손실 쓰기 보호와 달리 대기 데이터베이스가 필요하지 않습니다.
특정 테이블스페이스 및 데이터 파일에 대해 쉐도우 손실 쓰기 보호를 활성화할 수 있습니다. 모든 데이터를 추적할 필요가 없습니다.
쉐도우 테이블스페이스를 다른 테이블스페이스로 대체하여 구성이나 위치를 변경할 수 있습니다.
테이블스페이스나 데이터 파일에 대해 쉐도우 손실 쓰기 보호를 일시 중지하고 다시 시작할 수 있습니다.
ALTER DATABASE ... LOST WRITE TRACKING 문을 사용하여 전체 비 CDB 또는 PDB에 대해 이를 활성화하거나 비활성화할 수 있습니다. PROP$ 테이블은 PDB에 대해 추적이 활성화되었는지 여부를 나타냅니다.

참고:

Oracle Database SQL Language Reference에서 LOST WRITE TRACKING 절에 대해 더 알아보기

쉐도우 테이블스페이스 작동 방식

손실 쓰기 보호에는 쉐도우 테이블스페이스와 쉐도우 테이블스페이스가 추적하는 블록이 있는 비 쉐도우 테이블스페이스가 필요합니다.

다음 그림은 샘플 시나리오를 제공합니다. 테이블스페이스 TBS1 및 TBS2의 데이터 파일은 쉐도우 테이블스페이스에 의해 추적됩니다. 테이블스페이스 TBS3의 데이터 파일 DBF6만이 쉐도우 테이블스페이스에 의해 추적됩니다.

설명 cncpt390.eps 뒤따릅니다
일러스트레이션 cncpt390.eps의 설명
하나의 추적된 데이터 파일은 쉐도우 테이블스페이스의 하나의 쉐도우 익스텐트에 매핑됩니다. 추적된 데이터 파일의 모든 데이터 블록은 쉐도우 블록에 해당 항목을 가지고 있습니다. 이 항목에는 추적된 데이터 블록의 SCN이 포함됩니다. 추적된 데이터 블록이 디스크에서 읽힐 때 쉐도우 손실 쓰기 보호는 쉐도우 테이블스페이스의 블록 SCN과 추적된 데이터 블록의 최신 쓰기의 SCN을 비교합니다. 쉐도우 항목의 SCN이 읽히는 데이터 블록보다 크면 손실 쓰기가 발생하여 오류가 발생합니다.

쉐도우 익스텐트는 데이터 파일의 자동 크기 조정이 쉐도우 익스텐트가 너무 커지는 것을 방지하기 위해 상당한 여유 공간으로 크기가 조정됩니다. 추적된 데이터 파일이 수동으로 또는 자동으로 크기 조정되고 쉐도우 익스텐트가 커져야 하는 경우 데이터베이스는 추적 데이터를 크기 조정하려고 시도합니다. 쉐도우 테이블스페이스에 충분한 공간이 없으면 데이터베이스는 경고를 경고 로그에 기록하고 가능한 많은 데이터 블록을 추적합니다.

참고:

Oracle Database Administrator’s Guide에서 쉐도우 손실 쓰기 보호를 관리하는 방법에 대해 알아보기

쉐도우 테이블스페이스 사용자 인터페이스

ALTER DATABASE 명령을 사용하여 쉐도우 손실 쓰기 보호를 활성화하고 비활성화합니다.

특정 테이블스페이스 또는 데이터 파일에 대해 쉐도우 손실 쓰기 보호를 활성화하려면 다음 조건이 충족되어야 합니다:

ALTER DATABASE ENABLE LOST WRITE PROTECTION 문을 사용하여 전체 비 CDB 또는 PDB에 대해 쉐도우 손실 쓰기 보호를 활성화해야 합니다.
PDB에서는 루트에서 쉐도우 손실 쓰기 보호를 활성화하더라도 PDB는 이를 상속하지 않습니다. 보호하려는 각 PDB에 대해 쉐도우 손실 쓰기 보호를 활성화해야 합니다.
ENABLE LOST WRITE PROTECTION 절을 사용하여 보호하려는 테이블스페이스 또는 데이터 파일에 대해 쉐도우 손실 쓰기 보호를 활성화해야 합니다.

테이블스페이스에 대해 쉐도우 손실 쓰기 보호를 활성화하면 테이블스페이스의 모든 데이터 파일이 보호되며 테이블스페이스에 추가된 데이터 파일도 보호됩니다. 임시 테이블스페이스나 다른 손실 쓰기 테이블스페이스에 손실 쓰기 보호를 활성화할 수 없습니다.

CREATE BIGFILE TABLESPACE 문을 사용하여 LOST WRITE PROTECTION 절과 함께 하나 이상의 쉐도우 테이블스페이스를 생성해야 합니다.

Oracle Database는 추적된 데이터 파일을 특정 쉐도우 테이블스페이스에 자동으로 할당합니다. 특정 데이터 파일에 사용되는 쉐도우 테이블스페이스를 지정할 수 없습니다.

다음 데이터 사전 뷰는 쉐도우 테이블스페이스를 모니터링합니다:

DBA_TABLESPACES

쿼리를 통해 어떤 테이블스페이스가 쉐도우 테이블스페이스인지 보여줍니다.
DBA_DATA_FILES.LOST_WRITE_PROTECT

데이터 파일에 손실 쓰기 보호가 활성화되어 있는지 여부를 보여줍니다.
USER_TABLESPACES.LOST_WRITE_PROTECT

특정 테이블스페이스에 손실 쓰기 보호가 켜져 있는지 여부를 보여줍니다. DBA_DATA_FILES는 테이블스페이스에 손실 쓰기가 켜져 있는지 여부를 나타내지 않습니다. 대신 USER_TABLESPACES를 확인해야 합니다.

참고:

"데이터 손상"

Oracle Database Administrator’s Guide에서 쉐도우 테이블스페이스를 관리하는 방법에 대해 알아보기

Oracle Database SQL Language Reference에서 CREATE TABLESPACE 문에 대해 알아보기

Oracle Database Reference에서 DBA_TABLESPACES에 대해 알아보기

예: 손실 쓰기 보호 구성

이 예는 특정 테이블스페이스에 대해 쉐도우 손실 쓰기 추적을 활성화합니다.

이 예에서는 비 CDB 내에서 salestbs 및 hrtbs 테이블스페이스를 보호하는 것을 목표로 합니다. 또한 oetbs 테이블스페이스 내의 oetbs01.dbf 데이터 파일만 보호하려고 합니다. 다음 작업을 수행합니다:

SYSTEM으로 데이터베이스에 로그인합니다.

다음과 같이 단일 쉐도우 테이블스페이스를 생성합니다:

CREATE BIGFILE TABLESPACE shadow_lwp1 
  DATAFILE 'shadow_lwp1_df' SIZE 10M LOST WRITE PROTECTION;

다음과 같이 전체 데이터베이스에 대해 손실 쓰기 보호를 활성화합니다:

ALTER DATABASE ENABLE LOST WRITE PROTECTION;

다음과 같이 salestbs 및 hrtbs 테이블스페이스에 대해 쉐도우 손실 쓰기 보호를 활성화합니다:

ALTER TABLESPACE salestbs ENABLE LOST WRITE PROTECTION;
ALTER TABLESPACE hrtbs ENABLE LOST WRITE PROTECTION;

다음과 같이 oetbs01.dbf 데이터 파일에 대해 쉐도우 손실 쓰기 보호를 활성화합니다:

ALTER DATABASE DATAFILE 'oetbs01.dbf' ENABLE LOST WRITE PROTECTION;

참고:

Oracle Database Administrator’s Guide에서 쉐도우 테이블스페이스를 관리하는 방법에 대해 알아보기

Oracle Database SQL Language Reference에서 CREATE TABLESPACE 문에 대해 알아보기

임시 테이블스페이스

임시 테이블스페이스는 세션 동안만 지속되는 일시적인 데이터를 포함합니다. 영구 스키마 객체는 임시 테이블스페이스에 있을 수 없습니다. 임시 테이블스페이스 데이터는 임시 파일에 저장됩니다.

임시 테이블스페이스는 메모리에 맞지 않는 여러 정렬 작업의 동시성을 향상시킬 수 있습니다. 이러한 테이블스페이스는 정렬 중 공간 관리 작업의 효율성도 향상시킵니다.

공유 및 로컬 임시 테이블스페이스

임시 테

이블스페이스는 공유 또는 로컬입니다.

공유 임시 테이블스페이스는 모든 데이터베이스 인스턴스에서 액세스할 수 있도록 공유 디스크에 임시 파일을 저장합니다. 반면, 로컬 임시 테이블스페이스는 각 데이터베이스 인스턴스에 대해 별도의 공유되지 않은 임시 파일을 저장합니다. 로컬 임시 테이블스페이스는 Oracle Real Application Clusters 또는 Oracle Flex Clusters에 유용합니다.

참고: 로컬 임시 테이블스페이스는 Oracle Database 12c 릴리스 2 (12.2)에 새롭게 도입되었습니다. 이전 릴리스에서는 공유 임시 테이블스페이스가 임시 테이블스페이스라고 불렸습니다. 이번 릴리스부터는 달리 명시되지 않는 한 임시 테이블스페이스라는 용어는 공유 임시 테이블스페이스를 의미합니다.
읽기 전용 및 읽기/쓰기 데이터베이스 인스턴스 모두에 대해 로컬 임시 테이블스페이스를 생성할 수 있습니다. 여러 읽기 전용 인스턴스가 단일 데이터베이스에 액세스할 때 로컬 임시 테이블스페이스는 정렬, 해시 집계 및 조인을 포함한 쿼리의 성능을 향상시킬 수 있습니다. 장점은 다음과 같습니다:

공유 디스크 스토리지 대신 로컬 스토리지를 사용하여 I/O 성능 향상
비용이 많이 드는 인스턴스 간 임시 공간 관리 회피
디스크 공간 메타데이터 관리를 제거하여 인스턴스 시작 성능 향상

다음 표는 공유 및 로컬 임시 테이블스페이스의 특성을 비교합니다.

공유 임시 테이블스페이스	로컬 임시 테이블스페이스
CREATE TEMPORARY TABLESPACE 문으로 생성됨	CREATE LOCAL TEMPORARY TABLESPACE 문으로 생성됨
데이터베이스에 단일 임시 테이블스페이스 생성	각 데이터베이스 인스턴스에 별도의 임시 테이블스페이스 생성
테이블스페이스 그룹을 지원함	테이블스페이스 그룹을 지원하지 않음
컨트롤 파일에 임시 파일 메타데이터 저장	컨트롤 파일에 모든 인스턴스에 공통된 임시 파일 메타데이터 저장, SGA에 인스턴스별 메타데이터 저장

참고:

"Oracle Database 인스턴스 소개"

기본 임시 테이블스페이스

모든 데이터베이스 사용자 계정에는 기본 공유 임시 테이블스페이스가 할당됩니다. 데이터베이스에 로컬 임시 테이블스페이스가 포함된 경우, 각 사용자 계정에는 기본 로컬 임시 저장소도 할당됩니다.

CREATE USER 또는 ALTER USER 문을 사용하여 사용자 계정에 다른 임시 테이블스페이스를 지정할 수 있습니다. Oracle Database는 다른 임시 테이블스페이스를 지정하지 않은 사용자에게 시스템 수준의 기본 임시 테이블스페이스를 사용합니다.

참고:

Oracle Database SQL Language Reference에서 CREATE USER 문에 대해 알아보기

기본 임시 테이블스페이스 생성

데이터베이스를 생성할 때, 기본 임시 저장소는 SYSTEM 테이블스페이스가 로컬 관리되는지 여부에 따라 다릅니다.

다음 표는 데이터베이스 생성 시 Oracle Database가 기본 임시 테이블스페이스를 선택하는 방식을 보여줍니다.

SYSTEM 테이블스페이스가 로컬 관리됩니까?	CREATE DATABASE 문에서 기본 임시 테이블스페이스를 지정합니까?	그러면 데이터베이스는 ...
예	예	지정된 테이블스페이스를 기본값으로 사용
예	아니요	임시 테이블스페이스 생성
아니요	예	지정된 테이블스페이스를 기본값으로 사용
아니요	아니요	기본 임시 저장소로 SYSTEM 사용. 기본 임시 테이블스페이스가 권장된다는 경고를 경고 로그에 기록

데이터베이스 생성 후 ALTER DATABASE DEFAULT TEMPORARY TABLESPACE 문을 사용하여 데이터베이스의 기본 임시 테이블스페이스를 변경할 수 있습니다.

참고: 기본 임시 테이블스페이스를 영구적으로 만들 수 없습니다.

참고:

"영구 및 임시 데이터 파일"

Oracle Database Administrator's Guide에서 기본 임시 테이블스페이스를 생성하는 방법에 대해 알아보기

Oracle Database SQL Language Reference에서 CREATE DATABASE 및 ALTER DATABASE의 DEFAULT TEMPORARY TABLESPACE 절 구문에 대해 알아보기

임시 저장소 접근

사용자에게 임시 테이블스페이스가 할당된 경우, 데이터베이스는 먼저 이를 접근합니다. 그렇지 않으면 데이터베이스는 기본 임시 테이블스페이스에 접근합니다. 데이터베이스는 쿼리에 대해 임시 테이블스페이스에 접근한 후 다른 테이블스페이스로 전환하지 않습니다.

사용자 쿼리는 공유 또는 로컬 임시 저장소에 접근할 수 있습니다. 또한 사용자는 읽기 전용 인스턴스에 대해 기본 로컬 임시 테이블스페이스를, 읽기/쓰기 인스턴스에 대해 다른 기본 로컬 임시 테이블스페이스를 할당할 수 있습니다.

읽기/쓰기 인스턴스의 경우 데이터베이스는 공유 임시 테이블스페이스에 더 높은 우선순위를 둡니다. 읽기 전용 인스턴스의 경우 데이터베이스는 로컬 임시 테이블스페이스에 더 높은 우선순위를 둡니다. 데이터베이스 인스턴스가 읽기/쓰기인 경우 데이터베이스는 다음 순서로 공간을 검색합니다:

사용자에게 공유 임시 테이블스페이스가 할당되었습니까?
사용자에게 로컬 임시 테이블스페이스가 할당되었습니까?
데이터베이스 기본 임시 테이블스페이스에 공간이 있습니까?

이전 질문 중 하나라도 예인 경우, 데이터베이스는 검색을 중지하고 지정된 테이블스페이스에서 공간을 할당합니다. 그렇지 않으면 데이터베이스 기본 로컬 임시 테이블스페이스에서 공간을 할당합니다.

데이터베이스 인스턴스가 읽기 전용인 경우 데이터베이스는 다음 순서로 공간을 검색합니다:

사용자에게 로컬 임시 테이블스페이스가 할당되었습니까?
데이터베이스 기본 로컬 임시 테이블스페이스에 공간이 있습니까?
사용자에게 공유 임시 테이블스페이스가 할당되었습니까?

이전 질문 중 하나라도 예인 경우, 데이터베이스는 검색을 중지하고 지정된 테이블스페이스에서 공간을 할당합니다. 그렇지 않으면 데이터베이스 기본 공유 임시 테이블스페이스에서 공간을 할당합니다.

테이블스페이스 모드

테이블스페이스 모드는 테이블스페이스의 접근 가능성을 결정합니다.

읽기/쓰기 및 읽기 전용 테이블스페이스

모든 테이블스페이스는 쓰기 모드에서 데이터 파일에 쓸 수 있는지 여부를 지정합니다.

상호 배타적인 모드는 다음과 같습니다:

읽기/쓰기 모드

사용자는 테이블스페이스에 읽기 및 쓰기할 수 있습니다. 모든 테이블스페이스는 처음에 읽기/쓰기로 생성됩니다. SYSTEM 및 SYSAUX 테이블스페이스와 임시 테이블스페이스는 영구적으로 읽기/쓰기이며, 읽기 전용으로 만들 수 없습니다.
읽기 전용 모드

테이블스페이스의 데이터 파일에 대한 쓰기 작업이 방지됩니다. 읽기 전용 테이블스페이스는 DVD 또는 WORM 드라이브와 같은 읽기 전용 미디어에 있을 수 있습니다.

읽기 전용 테이블스페이스는 대규모, 정적인 데이터베이스 부분의 백업 및 복구 필요성을 제거합니다. 읽기 전용 테이블스페이스는 변경되지 않으므로 반복적인 백업이 필요하지 않습니다. 미디어 실패 후 데이터베이스를 복구하는 경우 읽기 전용 테이블스페이스를 복구할 필요가 없습니다.

참고:

Oracle Database Administrator’s Guide에서 테이블스페이스를 읽기 전용 또는 읽기/쓰기 모드로 변경하는 방법에 대해 알아보기

Oracle Database SQL Language Reference에서 ALTER TABLESPACE 구문 및 의미에 대해 알아보기

Oracle Database Backup and Recovery User’s Guide에서 복구에 대한 자세한 정보

온라인 및 오프라인 테이블스페이스

데이터베이스가 열려 있을 때 테이블스페이스는 온라인(접근 가능) 또는 오프라인(접근 불가능)일 수 있습니다.

테이블스페이스는 일반적으로 데이터가 사용자에게 사용 가능하도록 온라인 상태입니다. SYSTEM 테이블스페이스와 임시 테이블스페이스는 오프라인으로 전환할 수 없습니다.

테이블스페이스는 자동으로 또는 수동으로 오프라인이 될 수 있습니다. 예를 들어, 유지 관리 또는 백업 및 복구를 위해 테이블스

페이스를 오프라인으로 전환할 수 있습니다. 데이터베이스는 데이터 파일에 쓰기 시도가 여러 번 실패할 때와 같은 특정 오류가 발생하면 자동으로 테이블스페이스를 오프라인으로 전환합니다. 오프라인 테이블스페이스에 있는 테이블에 접근하려고 시도하는 사용자는 오류를 받습니다.

테이블스페이스가 오프라인이 되면 데이터베이스는 다음 작업을 수행합니다:

데이터베이스는 후속 DML 문이 오프라인 테이블스페이스의 객체를 참조하는 것을 허용하지 않습니다. 오프라인 테이블스페이스는 Oracle Database 외의 어떤 유틸리티로도 읽거나 편집할 수 없습니다.
해당 테이블스페이스의 데이터를 참조하는 완료된 문이 있는 활성 트랜잭션은 트랜잭션 수준에서 영향을 받지 않습니다.
데이터베이스는 SYSTEM 테이블스페이스의 지연 언두 세그먼트에 해당 완료된 문과 관련된 언두 데이터를 저장합니다. 테이블스페이스가 온라인으로 전환되면 데이터베이스는 필요한 경우 테이블스페이스에 언두 데이터를 적용합니다.

참고:

"온라인 및 오프라인 데이터 파일"

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

Oracle Database Administrator’s Guide에서 테이블스페이스 가용성을 변경하는 방법에 대해 알아보기

테이블스페이스 파일 크기

테이블스페이스는 빅파일 테이블스페이스 또는 스몰파일 테이블스페이스입니다. 이러한 테이블스페이스는 데이터 파일 또는 임시 파일을 명시적으로 참조하지 않는 SQL 문 실행 측면에서 구별되지 않습니다.

차이점은 다음과 같습니다:

스몰파일 테이블스페이스는 여러 데이터 파일 또는 임시 파일을 포함할 수 있지만, 파일 크기는 빅파일 테이블스페이스에 비해 작을 수 없습니다. 이것이 기본 테이블스페이스 유형입니다.
빅파일 테이블스페이스는 하나의 매우 큰 데이터 파일 또는 임시 파일을 포함합니다. 이 유형의 테이블스페이스는 다음과 같은 작업을 수행할 수 있습니다:
- 데이터베이스의 저장 용량 증가
- 데이터 파일의 최대 수가 제한되어 있으므로 각 데이터 파일의 크기를 증가시키면 전체 저장 용량이 증가합니다.
- 많은 데이터 파일 및 임시 파일 관리를 줄입니다.
- Oracle Managed Files 및 Automatic Storage Management (Oracle ASM)로 파일 관리가 단순화되어 새로운 파일을 추가하고 여러 파일을 처리할 필요가 없습니다.
- 개별 파일 대신 테이블스페이스 작업 수행
- 빅파일 테이블스페이스는 테이블스페이스를 디스크 공간 관리, 백업 및 복구 등의 주요 단위로 만듭니다.

빅파일 테이블스페이스는 ASSM과 로컬 관리 테이블스페이스에만 지원됩니다. 그러나 로컬 관리 언두 및 임시 테이블스페이스는 세그먼트가 수동으로 관리되는 경우에도 빅파일 테이블스페이스가 될 수 있습니다.

참고:

"백업 및 복구"

Oracle Database Administrator’s Guide에서 빅파일 테이블스페이스를 관리하는 방법에 대해 알아보기

torch

비전공 개발 공부 이야기

이전 포스트

[오라클] Oracle® Database Concepts 챕터 11 한글 번역

다음 포스트