DB스터디 - 최근 바뀜 [ko]

Enq:hw-contention

2026-09-21T23:34:08Z

HW(High Water Mark) Enqueue가 무엇인가?

← 이전 판		2026년 9월 22일 (화) 08:34 판
8번째 줄:		8번째 줄:

	* HWM(High Water Mark)란?		* HWM(High Water Mark)란?
	:= 이 세그먼트가 지금까지 한 번이라도 사용한 적 있는 블록의 최대 경계선		: :이 세그먼트가 지금까지 한 번이라도 사용한 적 있는 블록의 최대 경계선

	<source>		<source>

Enq:hw-contention

2026-09-21T23:33:40Z

새 문서: == enq: HW - Contention == * LOB Segment 이슈와 밀접하게 연결되는 대기 이벤트입니다. * 특히 동시성 높은 환경에서 LOB 컬럼에 INSERT가 몰릴 때 자주 발생하는 이슈 ---- === HW(High Water Mark) Enqueue가 무엇인가? === * 개념: 세그먼트(Table, Index, LOB Segment 등)가 "새로운 블록 영역으로 확장" 될 때 걸리는 직렬화 락(Lock) * HWM(High Water Mark)란? := 이 세그먼트가 지금까지 한 번이라도...

새 문서

== enq: HW - Contention ==
* LOB Segment 이슈와 밀접하게 연결되는 대기 이벤트입니다.
* 특히 동시성 높은 환경에서 LOB 컬럼에 INSERT가 몰릴 때 자주 발생하는 이슈

----
=== HW(High Water Mark) Enqueue가 무엇인가? ===
* 개념: 세그먼트(Table, Index, LOB Segment 등)가 "새로운 블록 영역으로 확장" 될 때 걸리는 직렬화 락(Lock)

* HWM(High Water Mark)란?
:= 이 세그먼트가 지금까지 한 번이라도 사용한 적 있는 블록의 최대 경계선

<source>
[세그먼트 내부 이미지]
┌────────┬────────┬────────┬────────┬─────────────┐
│ 사용중 │ 사용중 │ 사용중 │ 미사용 │ 미사용 │
│ Block1 │ Block2 │ Block3 │ Block4 │ Block5 │
└────────┴────────┴────────┴────────┴─────────────┘
▲
HWM (여기까지가 "사용해본 적 있는" 경계)

→ HWM을 넘어 Block4, Block5로 최초 진입(확장)하려면
"누군가 한 명만" HWM을 이동시키는 작업을 해야 함
→ 그 "한 명만 하도록 강제"하는 직렬화 장치가 바로 enq: HW 이다
</source>

*핵심: HW 이동 자체는 원자적(Atomic)이어야 하므로, 여러 세션이 동시에 HWM을 넘기려고 시도하면 한 세션만 실제로 이동시키고 나머지는 대기합니다.
이 대기가 `enq: HW - contention`입니다.

----

=== 어떤 상황에서 자주 발생하는가? ===

# 발생 빈발 시나리오 TOP 3
#:<source>
1순위: LOB Segment 동시 INSERT (가장 빈번)
: → 여러 세션이 동시에 CLOB/BLOB 컬럼에 대량 데이터를 INSERT
: → 특히 NOCACHE + 병렬 세션 조합에서 극심

2순위: 병렬 Direct-Path INSERT (APPEND Hint)
: → 여러 병렬 슬레이브가 동시에 같은 테이블 뒤쪽에 데이터 적재

3순위: 시퀀스 없는 대량 동시 INSERT (일반 Heap 테이블)
: → ASSM(Automatic Segment Space Management)이라도
극단적으로 짧은 시간에 너무 많은 세션이 몰리면 발생 가능
</source>
#:* SecureFile LOB에 다수 세션이 동시에 대용량 데이터를 넣는 배치/API 환경이라면, LOB Segment의 HWM 확장 경쟁이 바로 이 대기 이벤트의 주요 원인

----

=== 실습으로 재현해보기 ===
# 테스트 테이블
#:<source lang=sql>
CREATE TABLE hw_contention_test (
id NUMBER,
data_lob CLOB
)
LOB (data_lob) STORE AS SECUREFILE hw_lob_seg (
DISABLE STORAGE IN ROW
NOCACHE
CHUNK 8192
);
</source>
# 다수 세션에서 동시 INSERT 발생시키기 (개념적 재현)
#: 여러 세션에서 동시에 아래를 실행 (SQL*Plus 여러 창 or 병렬 Job):
#:<source lang=sql>
-- Session 1~10 동시 실행
DECLARE
l_clob CLOB;
BEGIN
FOR i IN 1..1000 LOOP
l_clob := gen_clob(50000, 'X'); -- 50KB LOB
INSERT INTO hw_contention_test VALUES (i, l_clob);
COMMIT;
END LOOP;
END;
/
</source>
# 실시간 대기 이벤트 모니터링
#:<source lang=sql>
SELECT sid, event, state, seconds_in_wait, p1, p2, p3
FROM v$session
WHERE event = 'enq: HW - contention';
</source>
#:
#:<source lang=sql>
SID EVENT STATE SECONDS_IN_WAIT P1 P2 P3
---- ----------------------- ------- ---------------- ---------- ------ ------
145 enq: HW - contention WAITING 2 1213908993 65543 0
152 enq: HW - contention WAITING 2 1213908993 65543 0
168 enq: HW - contention WAITING 1 1213908993 65543 0
</source>
#:
#:* P1, P2 해석:
#:*:- `P1 = 1213908993` → `Type='HW'(0x48 0x57), Mode` 조합 인코딩 값
#:*:- `P2 = 65543` → 대상 세그먼트의 **Tablespace# + Relative File#** 조합 (같은 세그먼트를 다투고 있다는 증거)
#:
#:* 동일한 P2 값을 가진 세션들이 정확히 같은 세그먼트(여기서는 hw_lob_seg)에서 경쟁 중임을 의미합니다.
# 원인이 되는 세그먼트를 정확히 찾아내는 방법
#:<source lang=sql>
-- P2 값을 이용해 실제 경쟁 중인 세그먼트 역추적
SELECT s.sid, s.event,
o.owner, o.object_name, o.object_type
FROM v$session s,
v$lock l,
dba_extents e,
dba_objects o
WHERE s.event = 'enq: HW - contention'
AND l.sid = s.sid
AND l.type = 'HW'
AND e.relative_fno = MOD(l.id2, 65536)
AND e.file_id = e.relative_fno -- 환경에 맞게 조정 필요
AND o.object_id = e.segment_id
AND o.object_name = e.segment_name;
</source>
#: * 더 실무적으로 간단한 방법: P1/P2로 직접 조회하는 대신, 실시간으로 어느 세그먼트가 확장 중인지 ASH로 확인
#:<source lang=sql>
SELECT sample_time, session_id,
current_obj#,
(SELECT object_name FROM dba_objects WHERE object_id = ash.current_obj#) AS obj_name,
event
FROM v$active_session_history ash
WHERE event = 'enq: HW - contention'
ORDER BY sample_time DESC
FETCH FIRST 20 ROWS ONLY;
</source>
#:<source lang=sql>
SAMPLE_TIME SESSION_ID CURRENT_OBJ# OBJ_NAME EVENT
----------------------- ----------- ------------- --------------- ---------------------
2024-01-15 14:23:01.123 145 123457 HW_LOB_SEG enq: HW - contention
2024-01-15 14:23:01.456 152 123457 HW_LOB_SEG enq: HW - contention
2024-01-15 14:23:01.789 168 123457 HW_LOB_SEG enq: HW - contention
</source>
#:* 확인 완료 : 세 세션 모두 `HW_LOB_SEG`에서 경쟁 중임이 명확히 드러납니다.

=== 왜 이런 구조적 한계가 존재하는가? (ASSM이라도 못 피하는 이유) ===

<source>
오해: "ASSM(자동 세그먼트 공간 관리)이면
Freelist Contention이 해결됐으니 HW Contention도 없겠지?"

실제: ASSM은 "이미 HWM 아래에 있는 블록들 사이의 공간 찾기 경쟁"만 해결한다.
"HWM 자체를 넘어서 새 영역으로 처음 진입하는 순간"의
직렬화는 ASSM 여부와 무관하게 항상 존재한다.

즉, Freelist Contention(구시대) ≠ HW Contention(구조적으로 항상 존재)
</source>

# LOB Segment는 특히 취약한 이유*:
#:<source lang=sql>
일반 Table Segment
→ 여러 세션이 각기 다른 블록에 흩어져서 쓸 수 있음 (ASSM Bitmap 분산 배정)
→ HWM 확장 빈도 자체가 상대적으로 낮음

LOB Segment (특히 NOCACHE 대용량 INSERT)
→ 각 LOB 값이 통째로 CHUNK 단위(8K, 16K...)를 즉시 소비
→ 대용량 LOB을 빠르게 연속 INSERT하면 HWM이 "매우 자주" 이동해야 함
→ HWM 이동 빈도가 높을수록 Contention 발생 확률 급증
</source>

=== 해결 방안 (실전 우선순위 순) ===
# SECUREFILE의 경우 - Concurrency 관련 파라미터 확인
#:<source lang=sql>
-- 현재 LOB의 상세 스토리지 옵션 확인
SELECT table_name, column_name, securefile,
cache, logging, retention
FROM user_lobs
WHERE table_name = 'HW_CONTENTION_TEST';
</source>
#:
#:<source lang=sql>
TABLE_NAME COLUMN_NAME SECUREFILE CACHE LOGGING RETENTION
-------------------- ----------- ---------- --------- ------- ----------
HW_CONTENTION_TEST DATA_LOB YES NO YES AUTO
</source>
#:
#:*개선안: SecureFile은 내부적으로 Space Management를 위한 여러 최적화가 있지만, 극단적 동시성에서는 여전히 근본적 해결이 안 됨. 아래 항목들과 병행 필요.
# 파티셔닝으로 세그먼트 자체를 분산 (가장 효과적)
#:<source lang=sql>
-- Hash Partition으로 LOB Segment 자체를 물리적으로 분산
CREATE TABLE hw_contention_test_part (
id NUMBER,
data_lob CLOB
)
LOB (data_lob) STORE AS SECUREFILE (
DISABLE STORAGE IN ROW
NOCACHE
)
PARTITION BY HASH (id) PARTITIONS 8;
</source>
#:
#:<source lang=sql>
-- 파티션별로 별도의 LOB Segment가 생성되는지 확인
SELECT table_name, partition_name, segment_name
FROM user_lob_partitions
WHERE table_name = 'HW_CONTENTION_TEST_PART';
</source>
#:
#:<source lang=sql>
TABLE_NAME PARTITION_NAME SEGMENT_NAME
------------------------- --------------- ------------------------
HW_CONTENTION_TEST_PART SYS_P101 SYS_LOB_P101_00001$$
HW_CONTENTION_TEST_PART SYS_P102 SYS_LOB_P102_00002$$
HW_CONTENTION_TEST_PART SYS_P103 SYS_LOB_P103_00003$$
...
</source>

* 효과 : 세션들이 `id` 값에 따라 8개의 서로 다른 파티션(=서로 다른 LOB Segment)으로 흩어지므로, 동일 세그먼트를 다투는 확률이 1/8로 감소합니다.
# 동시 INSERT 세션 수 자체를 조절 (애플리케이션 레벨)
#:<source lang=sql>
-- Resource Manager로 동시 병렬도 제한 (배치 작업의 경우)
BEGIN
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
plan => 'BATCH_PLAN',
group_or_subplan => 'BATCH_GROUP',
comment => 'LOB Insert 동시성 제한',
parallel_degree_limit_p1 => 4 -- 동시 병렬도 제한
);
END;
/
</source>
# CACHE 옵션 재검토 (단, 대용량이면 신중히)
#:<source lang=sql>
-- NOCACHE → CACHE READS로 변경 시 HWM 확장 패턴이 달라질 수 있음
-- (단, Buffer Cache 압박이 커지므로 LOB이 매우 크면 비추천)
ALTER TABLE hw_contention_test MOVE LOB(data_lob) STORE AS (
CACHE READS
);
</source>
#:
# 배치 커밋 간격 조정 (Commit 빈도와 HWM 확장 빈도는 별개지만 병행 효과 있음)
#:<source lang=sql>
-- 매 row마다 COMMIT → 500 row마다 COMMIT으로 변경
-- (트랜잭션 오버헤드 감소로 전체 처리시간 단축, HW Contention 절대량은 불변이나
-- 세션 간 타이밍이 분산되어 충돌 확률 감소하는 부수 효과)
DECLARE
l_clob CLOB;
BEGIN
FOR i IN 1..1000 LOOP
l_clob := gen_clob(50000, 'X');
INSERT INTO hw_contention_test VALUES (i, l_clob);
IF MOD(i, 500) = 0 THEN
COMMIT;
END IF;
END LOOP;
COMMIT;
END;
/
</source>
# 실전 진단 체크리스트
#:<source lang=sql>
-- AWR에서 HW Contention이 Top Wait Event로 잡히는지 확인
SELECT event, total_waits, time_waited_micro/1000000 AS time_waited_sec
FROM dba_hist_system_event
WHERE event = 'enq: HW - contention'
AND snap_id BETWEEN (SELECT MIN(snap_id) FROM dba_hist_snapshot WHERE begin_interval_time > SYSDATE-1)
AND (SELECT MAX(snap_id) FROM dba_hist_snapshot)
ORDER BY time_waited_sec DESC;
</source>
#:
#:<source lang=sql>
EVENT TOTAL_WAITS TIME_WAITED_SEC
----------------------- ------------ ----------------
enq: HW - contention 8421 342.56
</source>

* 이 정도 수치(하루 5분 이상 누적 대기)라면 명백히 튜닝 대상 입니다.

----

=== 최종 정리 ===
<source lang=sql>
enq: HW - contention 핵심 요약

원인: 세그먼트의 High Water Mark를 넘어 새 영역으로 확장할 때
발생하는 필연적 직렬화 경쟁

가장 흔한 실전 상황: 다수 세션의 동시 LOB INSERT (특히 NOCACHE 대용량)

ASSM으로도 해결 안 되는 구조적 이슈 (Freelist Contention과는 다른 문제)

가장 효과적인 해결책 우선순위:
1. 파티셔닝으로 세그먼트 자체를 분산 (근본 해결)
2. 동시 세션 수/병렬도 제한 (부하 조절)
3. CACHE 옵션, 배치 커밋 조정 (보조적 완화)
</source>

RAC환경 lob 튜닝

2026-09-16T09:35:53Z

← 이전 판		2026년 9월 16일 (수) 18:35 판
(같은 사용자의 중간 판 5개는 보이지 않습니다)
21번째 줄:		21번째 줄:

	=== LOB의 3단 구조가 만드는 3중 경합 지점 ===		=== LOB의 3단 구조가 만드는 3중 경합 지점 ===
	<source lang=sql>		:::<source lang=sql>
	Instance 1 Instance 2		Instance 1 Instance 2
	│ │		│ │
127번째 줄:		127번째 줄:
	*MSSM(Manual) vs ASSM(Auto) 차이		*MSSM(Manual) vs ASSM(Auto) 차이
	{\| class="wikitable"		{\| class="wikitable"
	~~\|+ 캡션 텍스트~~
	\|-		\|-
	! 구분 !! MSSM (FREELIST) !! ASSM (Bitmap)		! 구분 !! MSSM (FREELIST) !! ASSM (Bitmap)
139번째 줄:		138번째 줄:

	==== RETENTION vs PCTVERSION - RAC에서의 실질적 차이 ====		==== RETENTION vs PCTVERSION - RAC에서의 실질적 차이 ====
			::::<source lang=sql>
	<source lang=sql>
	-- RAC 환경에서는 RETENTION 방식이 유리		-- RAC 환경에서는 RETENTION 방식이 유리
	CREATE TABLE lob_test (		CREATE TABLE lob_test (
159번째 줄:		157번째 줄:
	* SecureFile은 내부적으로 여러 개의 작은 쓰기를 병합하여 Cache Fusion 전송 횟수를 줄입니다.		* SecureFile은 내부적으로 여러 개의 작은 쓰기를 병합하여 Cache Fusion 전송 횟수를 줄입니다.

	<source lang=sql>		::::<source lang=sql>
	-- SecureFile 내부 최적화 확인 (간접적)		-- SecureFile 내부 최적화 확인 (간접적)
	SELECT name, value		SELECT name, value
430번째 줄:		428번째 줄:

	### 체크리스트		### 체크리스트
	\| 항목 \| 확인 사항 \|		{\| class=”wikitable“
	\|-~~--\|---\|~~		\|-
	\| ☑ Tablespace \| ASSM (AUTO Segment Space Management) 여부 \|		! 항목 !! 확인 사항
	\| ☑ LOB Type \| SecureFile 사용 여부 (BasicFile 지양) \|		\|-
	\| ☑ Extent 전략 \| 큰 NEXT 값으로 HW 이동 빈도 최소화 \|		\| ☑ Tablespace \|\| ASSM (AUTO Segment Space Management) 여부
	\| ☑ 파티셔닝 \| 가능하면 노드/워크로드 특성 따라 분산 \|		\|-
	\| ☑ CACHE 옵션 \| 워크로드 패턴에 맞게 선택 (기본 NOCACHE 권장) \|		\| ☑ LOB Type \|\| SecureFile 사용 여부 (BasicFile 지양)
	\| ☑ RETENTION \| PCTVERSION 대신 RETENTION 사용 검토 \|		\|-
	\| ☑ 모니터링 \| HW/gc buffer busy 이벤트 정기 추적 \|		\| ☑ Extent 전략 \|\| 큰 NEXT 값으로 HW 이동 빈도 최소화
			\|-
			\| ☑ 파티셔닝 \|\| 가능하면 노드/워크로드 특성 따라 분산
			\|-
			\| ☑ CACHE 옵션 \|\| 워크로드 패턴에 맞게 선택 (기본 NOCACHE 권장)
			\|-
			\| ☑ RETENTION \|\| PCTVERSION 대신 RETENTION 사용 검토
			\|-
			\| ☑ 모니터링 \|\| HW/gc buffer busy 이벤트 정기 추적
			\|}

	---		----

	## 핵심 요약		{{결론
			\|내용=핵심 요약

	1. HW Enqueue가 RAC + LOB 환경에서 가장 흔하고 치명적인 경합 → 큰 익스텐트 크기로 완화		1. HW Enqueue가 RAC + LOB 환경에서 가장 흔하고 치명적인 경합 → 큰 익스텐트 크기로 완화

	2. ASSM은 선택이 아닌 필수 - MSSM은 RAC에서 사실상 사용 불가 수준		2. ASSM은 선택이 아닌 필수 - MSSM은 RAC에서 사실상 사용 불가 수준

	3. SecureFile의 Write Gathering이 Cache Fusion 트래픽을 내부적으로 최적화		3. SecureFile의 Write Gathering이 Cache Fusion 트래픽을 내부적으로 최적화

	4. NOCACHE가 RAC에서는 오히려 유리한 경우가 많음 (Direct I/O로 Global Cache 우회)		4. NOCACHE가 RAC에서는 오히려 유리한 경우가 많음 (Direct I/O로 Global Cache 우회)

	5. 파티셔닝을 통한 물리적 분산이 근본적 해결책 (경합 자체를 원천 차단)		5. 파티셔닝을 통한 물리적 분산이 근본적 해결책 (경합 자체를 원천 차단)

	6. PCTVERSION보다 RETENTION이 다중 인스턴스 환경에서 예측 가능성이 높음		6. PCTVERSION보다 RETENTION이 다중 인스턴스 환경에서 예측 가능성이 높음
			}}
	더 깊이 다뤄볼 만한 주제로 Exadata Smart Scan과 LOB의 상호작용, GoldenGate/Data Guard 환경에서 SecureFile LOB 복제 시 이슈, 또는 AWR/ASH 리포트를 활용한 실전 LOB 경합 튜닝 케이스 스터디 등이 있는데, 관심 있으신 영역 있으신가요?

대문

2026-09-16T09:02:38Z

오라클 LOB 원리와구조

← 이전 판		2026년 9월 16일 (수) 18:02 판
(같은 사용자의 중간 판 하나는 보이지 않습니다)
57번째 줄:		57번째 줄:
	=== [[파라미터 설계]] ===		=== [[파라미터 설계]] ===
	=== [[오라클 테이블의 구조]]===		=== [[오라클 테이블의 구조]]===
			==== [[ORACLE LOB\|오라클 LOB 원리와튜닝]] ====

	=== [[오라클 파티션테이블의 구조]] ===		=== [[오라클 파티션테이블의 구조]] ===
	=== [[데이터 블럭의 구조]] ===		=== [[데이터 블럭의 구조]] ===

틀:개요

2026-09-16T08:59:04Z

← 이전 판		2026년 9월 16일 (수) 17:59 판
(같은 사용자의 중간 판 7개는 보이지 않습니다)
5번째 줄:		5번째 줄:
	border: 1px solid {{{보더색\|#808080}}};		border: 1px solid {{{보더색\|#808080}}};
	background-color: {{{배경색\|#808080}}};		background-color: {{{배경색\|#808080}}};
	margin: 1.0em 0 0.7em; padding: 0.2em 0.2em; font-size: 1.0em; line-height: 2.1em; overflow: visible; -moz-border-radius: 0.5em; -webkit-border-radius: 0.5em; border-radius: 0.5em;"><i class="material-icons icon-image-preview"		margin: 1.0em 0 0.7em; padding: 0.2em 0.2em; font-size: 1.0em; line-height: 2.1em; overflow: visible; -moz-border-radius: 0.5em; -webkit-border-radius: 0.5em; border-radius: 0.5em;"><span class="material-icons icon-image-preview"
	style="display: inline-block; transform: translate(-10%, 20%); color: {{{아이콘색색\|#ffa500}}};"> {{{아이콘\|list_alt}}}</i><font style="color: {{{폰트색\|#fffafa}}}">{{{개요\|개요를 넣으세요}}}		style="display: inline-block; transform: translate(-10%, 20%); color: {{{아이콘색색\|#ffa500}}};"> {{{아이콘\|list_alt}}}</span><font style="color: {{{폰트색\|#fffafa}}}">{{{개요\|개요를 넣으세요}}}
	</font>		</font></div>
	</div>

오라클 LOB 데이터 구조

2026-09-16T08:49:19Z

← 이전 판		2026년 9월 16일 (수) 17:49 판
1번째 줄:		1번째 줄:
	== LOB(BLOB/CLOB)대용량 데이터 ==		== LOB(BLOB/CLOB)대용량 데이터 ==
	=== 개요 ===		=== 개요 ===
	LOB(BLOB/CLOB)이 대용량 데이터를 저장하는 핵심 원리는 '''"포인터(로케이터) + 별도 세그먼트 분리 저장"''' 구조		{{개요
			\|개요=LOB(BLOB/CLOB)이 대용량 데이터를 저장하는 핵심 원리는 '''"포인터(로케이터) + 별도 세그먼트 분리 저장"''' 구조
			}}
	<source>		<source>
	LOB		LOB

틀:개요

2026-09-16T08:49:01Z

← 이전 판		2026년 9월 16일 (수) 17:49 판
6번째 줄:		6번째 줄:
	background-color: {{{배경색\|#808080}}};		background-color: {{{배경색\|#808080}}};
	margin: 1.0em 0 0.7em; padding: 0.2em 0.2em; font-size: 1.0em; line-height: 2.1em; overflow: visible; -moz-border-radius: 0.5em; -webkit-border-radius: 0.5em; border-radius: 0.5em;"><i class="material-icons icon-image-preview"		margin: 1.0em 0 0.7em; padding: 0.2em 0.2em; font-size: 1.0em; line-height: 2.1em; overflow: visible; -moz-border-radius: 0.5em; -webkit-border-radius: 0.5em; border-radius: 0.5em;"><i class="material-icons icon-image-preview"
	style="display: inline-block; transform: translate(-10%, 20%); color: {{{아이콘색색\|#ffa500}}};"> {{{아이콘\|list_alt}}}</i><font style="color: {{{폰트색\|#fffafa}}}">{{{제목\|~~제목을넣으세요~~}}}		style="display: inline-block; transform: translate(-10%, 20%); color: {{{아이콘색색\|#ffa500}}};"> {{{아이콘\|list_alt}}}</i><font style="color: {{{폰트색\|#fffafa}}}">{{{개요\|개요를 넣으세요}}}
	</font>		</font>
	</div>		</div>

오라클 LOB 데이터 구조

2026-09-16T08:47:47Z

← 이전 판		2026년 9월 16일 (수) 17:47 판
(같은 사용자의 중간 판 3개는 보이지 않습니다)
18번째 줄:		18번째 줄:

	=== LOB 저장 구조 (핵심) ===		=== LOB 저장 구조 (핵심) ===
	<source>		:::<source>
	Table Row		Table Row
	│		│
43번째 줄:		43번째 줄:

	=== In-row vs Out-of-row ===		=== In-row vs Out-of-row ===
	:- 데이터 크기가 작으면(기본 임계값 관련, ENABLE STORAGE IN ROW) 로우 내부에 직접 저장		:::- 데이터 크기가 작으면(기본 임계값 관련, ENABLE STORAGE IN ROW) 로우 내부에 직접 저장
	:- 임계값을 넘으면 별도의 LOB 세그먼트(out-of-row)에 체인 형태로 저장되고 로우에는 포인터만 남음		:::- 임계값을 넘으면 별도의 LOB 세그먼트(out-of-row)에 체인 형태로 저장되고 로우에는 포인터만 남음
	:- 이 덕분에 4000바이트 제한을 가진 VARCHAR2/RAW와 달리 최대 4GB(BasicFile) ~ (LOB) 단위까지 저장 가능		:::- 이 덕분에 4000바이트 제한을 가진 VARCHAR2/RAW와 달리 최대 4GB(BasicFile) ~ (LOB) 단위까지 저장 가능
	<source>		::<source>
	CLOB 데이터 크기 확인		CLOB 데이터 크기 확인
	│		│
76번째 줄:		76번째 줄:

	=== CHUNK 단위 저장 ===		=== CHUNK 단위 저장 ===
	# LOB 세그먼트는 내부적으로 CHUNK(기본 8KB, 블록 사이즈 배수) 단위로 분할 저장.		:::# LOB 세그먼트는 내부적으로 CHUNK(기본 8KB, 블록 사이즈 배수) 단위로 분할 저장.
	# 큰 데이터를 CHUNK들의 연결 리스트로 관리하기 때문에 부분 읽기/쓰기(random access)가 가능하고, 전체를 메모리에 올리지 않고도 스트리밍 처리가 가능.		:::# 큰 데이터를 CHUNK들의 연결 리스트로 관리하기 때문에 부분 읽기/쓰기(random access)가 가능하고, 전체를 메모리에 올리지 않고도 스트리밍 처리가 가능.

	* CHUNK란?		:::* CHUNK란?
	** LOB 데이터의 최소 I/O 단위		:::** LOB 데이터의 최소 I/O 단위
	** DB_BLOCK_SIZE의 배수여야 함 (기본값: DB_BLOCK_SIZE, 최대 32KB 권장)		:::** DB_BLOCK_SIZE의 배수여야 함 (기본값: DB_BLOCK_SIZE, 최대 32KB 권장)
	** 하나의 CHUNK는 여러 Oracle Block으로 구성 가능하나, 하나의 익스텐트 내에 존재		:::** 하나의 CHUNK는 여러 Oracle Block으로 구성 가능하나, 하나의 익스텐트 내에 존재
	==== CHUNK 설계 원칙 ====		==== CHUNK 설계 원칙 ====
			::::# 소량 다건 CLOB (예: 짧은 메모, 코멘트)
	# 소량 다건 CLOB (예: 짧은 메모, 코멘트)		::::#:<source> CHUNK 8192 -- DB_BLOCK_SIZE와 동일하게</source>
	#:<source> CHUNK 8192 -- DB_BLOCK_SIZE와 동일하게</source>		::::# 대용량 CLOB (예: 문서, XML)
	# 대용량 CLOB (예: 문서, XML)		::::#:<source> CHUNK 32768 -- 더 크게 설정하여 I/O 효율 극대화</source>
	#:<source> CHUNK 32768 -- 더 크게 설정하여 I/O 효율 극대화</source>

	=== LOB 인덱스 ===		=== LOB 인덱스 ===
281번째 줄:		280번째 줄:

	=== LOB 실전 튜닝 포인트 ===		=== LOB 실전 튜닝 포인트 ===
	1. Fragmentation 확인		:::# Fragmentation 확인
	<source lang=sql>		:::#:<source lang=sql>
	SELECT segment_name, bytes/1024/1024 MB, blocks		SELECT segment_name, bytes/1024/1024 MB, blocks
	FROM dba_segments		FROM dba_segments
	WHERE segment_name IN (SELECT segment_name FROM dba_lobs WHERE table_name='X');		WHERE segment_name IN (SELECT segment_name FROM dba_lobs WHERE table_name='X');
	</source>		</source>
			:::# In-row vs Out-row 비율 확인 (실제 데이터 분포)
	2. In-row vs Out-row 비율 확인 (실제 데이터 분포)		:::#:<source lang=sql>
	<source lang=sql>
	SELECT		SELECT
	CASE WHEN LENGTHB(doc) <= 4000 THEN 'IN_ROW_CANDIDATE'		CASE WHEN LENGTHB(doc) <= 4000 THEN 'IN_ROW_CANDIDATE'
298번째 줄:		296번째 줄:
	ELSE 'OUT_ROW' END;		ELSE 'OUT_ROW' END;
	</source>		</source>
			:::# Chunk 사용 효율성 (파편화 여부)
	3. Chunk 사용 효율성 (파편화 여부)		:::#:<source lang=sql>
	<source lang=sql>
	SELECT table_name, column_name, chunk		SELECT table_name, column_name, chunk
	FROM user_lobs;		FROM user_lobs;
	</source>		</source>

ORACLE LOB

2026-09-16T08:45:10Z

LOB의 구조와 원리

← 이전 판		2026년 9월 16일 (수) 17:45 판
14번째 줄:		14번째 줄:
	::# [[오라클 LOB 데이터 구조#SecureFile vs BasicFile\| SecureFile vs BasicFile ]]		::# [[오라클 LOB 데이터 구조#SecureFile vs BasicFile\| SecureFile vs BasicFile ]]
	::## [[오라클 LOB 데이터 구조#CACHE / NOCACHE / CACHE READS\| CACHE / NOCACHE / CACHE READS ]]		::## [[오라클 LOB 데이터 구조#CACHE / NOCACHE / CACHE READS\| CACHE / NOCACHE / CACHE READS ]]
	# LOB과 트랜잭션 - Locator의 실체		::# [[오라클 LOB 데이터 구조#LOB과 트랜잭션 - Locator의 실체\|LOB과 트랜잭션 - Locator의 실체 ]]
	# LOB 실전 튜닝 포인트		::# [[오라클 LOB 데이터 구조#LOB 실전 튜닝 포인트\|LOB 실전 튜닝 포인트 ]]
	=== [[Lob 테스트\|LOB 테스트(storage in row)]] ===		=== [[Lob 테스트\|LOB 테스트(storage in row)]] ===
	=== [[Lob chunk size 최적화 테스트]] ===		=== [[Lob chunk size 최적화 테스트]] ===

	== [[RAC환경 lob 튜닝]] ==		== [[RAC환경 lob 튜닝]] ==

오라클 LOB 데이터 구조

2026-09-16T08:42:53Z

CLOB vs VARCHAR2 근본적 차이

← 이전 판		2026년 9월 16일 (수) 17:42 판
14번째 줄:		14번째 줄:

	==== CLOB vs VARCHAR2 근본적 차이 ====		==== CLOB vs VARCHAR2 근본적 차이 ====
	# VARCHAR2: 최대 32767 bytes (PL/SQL , 19c 이상부터 SQL도 가능), 4000 bytes (SQL) - inline storage 강제		::::# VARCHAR2: 최대 32767 bytes (PL/SQL , 19c 이상부터 SQL도 가능), 4000 bytes (SQL) - inline storage 강제
	# CLOB: 최대 4GB * DB_BLOCK_SIZE (이론상 128TB) - out-of-line storage 가능		::::# CLOB: 최대 4GB * DB_BLOCK_SIZE (이론상 128TB) - out-of-line storage 가능


	=== LOB 저장 구조 (핵심) ===		=== LOB 저장 구조 (핵심) ===

ORACLE LOB

2026-09-16T08:42:32Z

LOB의 구조와 원리

@@ 1번째 줄: / 1번째 줄: @@
 == [[오라클 LOB 데이터 구조|LOB의 구조와 원리]] ==
 === [[Lob 테스트|LOB 테스트(storage in row)]] ===
 === [[Lob chunk size 최적화 테스트]] ===
 == [[RAC환경 lob 튜닝]] ==

틀:중요

2026-09-16T08:36:32Z

@@ 1번째 줄: / 1번째 줄: @@
-<div style="position: inherit;
+<onlyinclude>
-        top: 100px;
+	<div class="libre-notice {{{속성|}}}" {{#if:{{{id|}}}|id="{{{id}}}"}} style="margin: 8px 0; padding: 8px; border-style: solid; border-width: 2px 0; background-color: {{{배경색|#23272f}}}; border-width: {{{선굵기|2px 0}}}; border-color: {{{테두리색|#fffafa}}}; width: {{{사이즈|100%}}}; border-radius: {{{둥굴기|0px}}}; border-style: {{{스타일|solid}}}; clear: both;"><font color="{{{아이콘색|orangered}}}"><i class="material-icons icon-image-preview" style="display: inline-block;transform: translate(10%, 25%);">{{{아이콘이름|blur_on}}}</i></font> <font style="color: {{{폰트색|#fffafa}}}">{{{내용|{{{1<noinclude>|[[{{SITENAME}}]] 중요 스타일 입니다.</noinclude>}}}}}}</font></div>
-        left: 100px;
+</onlyinclude>

카디널리티 와 셀렉티비티

2026-09-16T08:31:20Z

← 이전 판		2026년 9월 16일 (수) 17:31 판
(같은 사용자의 중간 판 16개는 보이지 않습니다)
190번째 줄:		190번째 줄:

	=== 실무에서의 중요성 ===		=== 실무에서의 중요성 ===
	#::: 인덱스 생성 판단		::# 인덱스 생성 판단
			::#: <source lang=sql>
	::: <source lang=sql>
	-- Selectivity가 낮을수록 (선택적일수록) 인덱스 효과 좋음		-- Selectivity가 낮을수록 (선택적일수록) 인덱스 효과 좋음

204번째 줄:		203번째 줄:
	-- Full Table Scan이 더 효율적		-- Full Table Scan이 더 효율적
	</source>		</source>
			::# 조인 순서 결정
	::~~: 2.~~ 조인 순서 결정		::#: <source lang=sql>

	::: <source lang=sql>
	-- Cardinality가 작은 테이블을 먼저 처리		-- Cardinality가 작은 테이블을 먼저 처리

219번째 줄:		216번째 줄:
	-- → departments를 먼저 필터링하는 것이 효율적		-- → departments를 먼저 필터링하는 것이 효율적
	</source>		</source>
			::# 통계 정확도 확인
	::~~: 3.~~ 통계 정확도 확인		::#: <source lang=sql>

	::: <source lang=sql>
	-- 실제 Cardinality vs 예상 Cardinality		-- 실제 Cardinality vs 예상 Cardinality
	SELECT /+ GATHER_PLAN_STATISTICS / *		SELECT /+ GATHER_PLAN_STATISTICS / *
230번째 줄:		225번째 줄:
	SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(format=>'ALLSTATS LAST'));		SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(format=>'ALLSTATS LAST'));
	</source>		</source>
			::# 결과:
			::#: <source lang=sql>
	::: * 결과:

	::: <source lang=sql>
	-------------------------------------------------------------------		-------------------------------------------------------------------
	\| Id \| Operation \| Name \| Starts \| E-Rows \| A-Rows \| ...		\| Id \| Operation \| Name \| Starts \| E-Rows \| A-Rows \| ...
247번째 줄:		239번째 줄:
	</source>		</source>

	=~~== 핵심 차이점 요약 ===~~		{{결론
	:::{\| class="wikitable"		\|내용= [결론] Cardinality vs. Selectivity
	~~\|+ 캡션 텍스트~~		* 실무 팁: Selectivity가 5% 이하일 때 인덱스 사용이 효과적이고, Cardinality는 조인 순서와 메모리 할당에 영향을 미친다.
			}}

			{\| class="wikitable"
	\|-		\|-
	!구분 !! Cardinality !! Selectivity		!구분 !! Cardinality !! Selectivity
264번째 줄:		259번째 줄:
	\|-		\|-
	\|}		\|}

	* 실무 팁: Selectivity가 5% 이하일 때 인덱스 사용이 효과적이고, Cardinality는 조인 순서와 메모리 할당에 영향을 줍니다!