5장. 저장 구조 — 테이블스페이스와 블록

CREATE TABLE 한 줄이 디스크 위에서는 테이블스페이스 → 세그먼트 → 익스텐트 → 블록이라는 4단 계층으로 펼쳐집니다. 블록 안을 들여다보면 row migration과 "지웠는데 왜 느리죠?"의 답이 보입니다.

5.1 논리 계층 — 테이블은 4단 서랍장에 담긴다

Oracle은 데이터를 논리 구조와 물리 구조로 나눠서 관리합니다. SQL을 쓰는 우리는 논리 구조(테이블스페이스, 세그먼트)를 보고, OS는 물리 구조(datafile)만 봅니다. 이 분리 덕분에 "테이블을 어느 디스크 파일에 둘까"를 SQL 세계와 독립적으로 바꿀 수 있습니다.

논리 계층은 큰 것부터 작은 것 순서로 이렇습니다.

실제로 눈으로 확인해 봅시다. 딕셔너리 뷰 세 개면 계층 전체가 보입니다.

-- 테이블이 어느 테이블스페이스에, 얼마나 크게 자리 잡았나
SELECT segment_name, tablespace_name, extents, blocks, bytes/1024/1024 AS mb
FROM   user_segments
WHERE  segment_name = 'EMP';

-- extent 하나하나가 어느 파일의 몇 번 블록부터인지
SELECT extent_id, file_id, block_id, blocks
FROM   dba_extents
WHERE  segment_name = 'EMP'
ORDER BY extent_id;

-- 테이블스페이스를 구성하는 물리 파일
SELECT file_name, bytes/1024/1024 AS mb, autoextensible
FROM   dba_data_files
WHERE  tablespace_name = 'USERS';

5.2 블록 내부 해부 — 8KB 안에 무엇이 들어있나

블록은 단순한 데이터 덩어리가 아니라 잘 짜인 문서 양식입니다. 위에서 아래로 이렇게 배치됩니다.

• 블록 헤더 — 블록 주소, 담긴 세그먼트 종류(테이블/인덱스), 최근 변경 SCN 등 관리 정보.
• ITL(Interested Transaction List) — "지금 이 블록의 행을 고치는 중인 트랜잭션" 명단. Oracle 행 락의 실체가 바로 여기 있습니다. 8장에서 집중적으로 다룹니다.
• Row Directory — 각 행이 블록 안 어디서 시작하는지 가리키는 목차. ROWID의 마지막 조각(행 번호)이 이 목차의 인덱스입니다.
• Free Space — 새 행 INSERT와 기존 행이 커지는 UPDATE를 위해 남겨둔 빈 공간.
• Row Data — 실제 행. 블록의 아래쪽 끝에서 위로 채워 올라옵니다.

5.3 PCTFREE — "UPDATE를 위해 자리를 비워둬라"

행은 INSERT 이후에도 UPDATE로 커질 수 있습니다. NULL이던 컬럼에 긴 문자열이 들어오는 순간이 대표적이죠. 그래서 Oracle은 블록마다 PCTFREE(기본값 10, 단위 %)만큼을 INSERT용으로 쓰지 않고 남겨둡니다.

-- 블록의 20%를 UPDATE 대비 여유 공간으로 남긴다
CREATE TABLE emp (
  empno  NUMBER(6),
  ename  VARCHAR2(50),
  bio    VARCHAR2(4000)   -- 나중에 채워질 큰 컬럼
) PCTFREE 20 TABLESPACE users;

규칙은 간단합니다. 블록의 빈 공간이 PCTFREE 밑으로 내려가면 그 블록에는 더 이상 새 행을 INSERT하지 않습니다. 남은 공간은 오직 기존 행이 커질 때를 위해 예약됩니다.

5.4 Row Migration vs Row Chaining — 행이 블록을 넘칠 때

여유 공간을 남겨도 한계는 옵니다. UPDATE로 커진 행이 블록에 도저히 안 들어가면 어떻게 될까요? Oracle은 두 가지 다른 상황을 구분합니다.

migration/chaining이 실제로 있는지 이렇게 진단합니다.

-- 방법 1: 통계로 의심하기 — 포인터를 따라간 횟수
SELECT name, value FROM v$sysstat
WHERE  name = 'table fetch continued row';

-- 방법 2: 테이블 통계 수집 후 확인
EXEC DBMS_STATS.GATHER_TABLE_STATS('SCOTT', 'EMP');
SELECT chain_cnt, num_rows FROM user_tables WHERE table_name = 'EMP';

-- 해결: migration된 행은 테이블 재구성으로 정리
ALTER TABLE emp MOVE;          -- 주의: ROWID가 바뀌므로 인덱스 리빌드 필요
ALTER INDEX emp_pk REBUILD;

5.5 High Water Mark — "지웠는데 왜 full scan이 느리죠?"

High Water Mark(HWM)는 세그먼트에서 "여기까지는 데이터가 채워진 적이 있다"를 표시하는 수위선입니다. 홍수가 지나간 강둑의 물자국과 같습니다 — 물이 빠져도 자국은 남죠.

핵심 규칙 두 가지:

• Full table scan은 HWM 아래의 모든 블록을 읽습니다. 행이 있든 없든.
• DELETE는 HWM을 내리지 않습니다. 1억 건을 지워도 수위선은 그대로입니다.

-- 대량 DELETE 후 HWM 내리기 (온라인, 세그먼트 축소)
ALTER TABLE emp ENABLE ROW MOVEMENT;   -- 행 이동 허용 (ROWID 변경 허용)
ALTER TABLE emp SHRINK SPACE;          -- 행을 앞쪽으로 모으고 HWM 하향

-- 전부 비울 거라면 DELETE 대신 이것 — HWM이 즉시 리셋된다
TRUNCATE TABLE emp;

✍️ 이해도 체크