DB스터디 - 사용자 기여 [ko]

대문

2026-09-16T09:02:38Z

Dbstudy: /* 오라클 LOB 원리와구조 */

__notoc__
https://dbstudy.co.kr/w/resources/assets/dbstudy_iconx1.png
= Welcome To DB STUDY - {{CURRENTYEAR}}.{{CURRENTMONTHNAME}}.{{CURRENTDAY}}({{CURRENTDAYNAME}}) =
= 전문가가 되고 싶다면 기본에 충실 하라. (Return To Basics) =
* {{SERVER}}
* 게시글 총 : {{NUMBEROFPAGES}} 건 , 사용자 : {{NUMBEROFUSERS}} 명 ,

<p sizes="(max-width: 600px) 480px,800px">
https://dbstudy.co.kr/w/images/dbstudy_logo.jpg
</p>
{{틀:타이틀 라운드
|제목=[[:Category:oracle|오라클]]: {{PAGESINCATEGORY: oracle}} 건 , [[:Category:postgresql|PostgreSql]] : {{PAGESINCATEGORY: postgresql}} 건 , [[:Category:mysql|MySQL]]: {{PAGESINCATEGORY: mysql}} 건, [[:Category:linux|LINUX]]: {{PAGESINCATEGORY: linux}} 건
|아이콘=emoji_objects
}}
----
= 최근 등록/수정글 =
{{Special:RecentChanges|days=50}}
----

= ORACLE =
== [[ORACLE SQL 튜닝]] ==
=== [[튜닝 개론]]===
:::# [[카디널리티 와 셀렉티비티|카디널리티(cardinality) 와 셀렉티비티(선택도,selectivity)]]
:::# [[성능을 고려한 설계]]
:::# [[효율적인 SQL 작성법]]

=== [[튜닝 환경 구축]] ===
:::# [[DBMS_XPLAN 사용법]]
:::# [[REAL PLAN 사용법]]
:::# [[SQL 트레이스 방법]]

=== [[인덱스 설계]] ===
:::# [[인덱스 아키텍처]]
:::# [[오라클 인덱스 종류|인덱스 종류]]
:::# [[엑세스 패스]]

=== [[옵티마이져]] ===
==== [[JPPD(Join Predicate PushDown,조인절 PUSHDOWN)]]====
==== [[View pushed predicate (조건절 PUSHDOWN)]]====

=== [[튜닝 힌트]] ===
:::# [[튜닝 힌트 no merge|NO_MERGE 힌트]]

=== [[대용량 데이터 튜닝]] ===
==== [[병렬 쿼리 튜닝]] ====
=== [[ORACLE 튜닝 대상 조회]] ===
=== [[성능 문제 식별 방법론과 튜닝 접근법]]===
----

== [[ORACLE 아키텍쳐의 이해]] ==
=== [[테이블 조인 방식|오라클 조인 과 알고리즘 ]] ===
==== [[NL 조인]]====
==== [[HASH 조인]]====
==== [[MERGE 조인|SORT MERGE 조인]]====
==== [[세미조인]] ====
==== [[안티조인]] ====
=== [[파라미터 설계]] ===
=== [[오라클 테이블의 구조]]===
==== [[ORACLE LOB|오라클 LOB 원리와튜닝]] ====

=== [[오라클 파티션테이블의 구조]] ===
=== [[데이터 블럭의 구조]] ===
=== [[오라클 컬럼의 구조]] ===
==== [[오라클 컬럼의 저장순서]] ====
==== [[컬럼의 순서가 변경시 ROW의 물리적 구조변화|컬럼 순서 변경시 ROW의 물리구조 변화]]====
==== [[오라클 컬럼저장 방식 개선 (12c 업그레이드) ]] ====
=== [[오라클 인덱스의 구조]] ===

----

= [[DBA_수행_방법론_(공공/대기업_SI_프로젝트)]]=
== [[DBA_수행_방법론_(공공/대기업_SI_프로젝트)#개요|개요]] ==
== [[단계별 수행 방법론]] ==
=== [[분석 단계]] ===
==== [[산출물]] ====
==== [[주요 작업 TASK]] ====
=== [[설계 단계]] ===
==== [[산출물]] ====
==== [[주요 작업 TASK]] ====
=== [[구축 단계]] ===
==== [[산출물]] ====
==== [[주요 작업 TASK]] ====
=== [[테스트 단계]] ===
==== [[산출물]] ====
==== [[주요 작업 TASK]] ====
=== [[전개 단계]] ===
==== [[산출물]] ====
==== [[주요 작업 TASK]] ====

----

대문

2026-09-16T09:02:19Z

Dbstudy: /* 오라클 테이블의 구조 */

__notoc__
https://dbstudy.co.kr/w/resources/assets/dbstudy_iconx1.png
= Welcome To DB STUDY - {{CURRENTYEAR}}.{{CURRENTMONTHNAME}}.{{CURRENTDAY}}({{CURRENTDAYNAME}}) =
= 전문가가 되고 싶다면 기본에 충실 하라. (Return To Basics) =
* {{SERVER}}
* 게시글 총 : {{NUMBEROFPAGES}} 건 , 사용자 : {{NUMBEROFUSERS}} 명 ,

<p sizes="(max-width: 600px) 480px,800px">
https://dbstudy.co.kr/w/images/dbstudy_logo.jpg
</p>
{{틀:타이틀 라운드
|제목=[[:Category:oracle|오라클]]: {{PAGESINCATEGORY: oracle}} 건 , [[:Category:postgresql|PostgreSql]] : {{PAGESINCATEGORY: postgresql}} 건 , [[:Category:mysql|MySQL]]: {{PAGESINCATEGORY: mysql}} 건, [[:Category:linux|LINUX]]: {{PAGESINCATEGORY: linux}} 건
|아이콘=emoji_objects
}}
----
= 최근 등록/수정글 =
{{Special:RecentChanges|days=50}}
----

= ORACLE =
== [[ORACLE SQL 튜닝]] ==
=== [[튜닝 개론]]===
:::# [[카디널리티 와 셀렉티비티|카디널리티(cardinality) 와 셀렉티비티(선택도,selectivity)]]
:::# [[성능을 고려한 설계]]
:::# [[효율적인 SQL 작성법]]

=== [[튜닝 환경 구축]] ===
:::# [[DBMS_XPLAN 사용법]]
:::# [[REAL PLAN 사용법]]
:::# [[SQL 트레이스 방법]]

=== [[인덱스 설계]] ===
:::# [[인덱스 아키텍처]]
:::# [[오라클 인덱스 종류|인덱스 종류]]
:::# [[엑세스 패스]]

=== [[옵티마이져]] ===
==== [[JPPD(Join Predicate PushDown,조인절 PUSHDOWN)]]====
==== [[View pushed predicate (조건절 PUSHDOWN)]]====

=== [[튜닝 힌트]] ===
:::# [[튜닝 힌트 no merge|NO_MERGE 힌트]]

=== [[대용량 데이터 튜닝]] ===
==== [[병렬 쿼리 튜닝]] ====
=== [[ORACLE 튜닝 대상 조회]] ===
=== [[성능 문제 식별 방법론과 튜닝 접근법]]===
----

== [[ORACLE 아키텍쳐의 이해]] ==
=== [[테이블 조인 방식|오라클 조인 과 알고리즘 ]] ===
==== [[NL 조인]]====
==== [[HASH 조인]]====
==== [[MERGE 조인|SORT MERGE 조인]]====
==== [[세미조인]] ====
==== [[안티조인]] ====
=== [[파라미터 설계]] ===
=== [[오라클 테이블의 구조]]===
==== [[ORACLE LOB|오라클 LOB 원리와구조]] ====

=== [[오라클 파티션테이블의 구조]] ===
=== [[데이터 블럭의 구조]] ===
=== [[오라클 컬럼의 구조]] ===
==== [[오라클 컬럼의 저장순서]] ====
==== [[컬럼의 순서가 변경시 ROW의 물리적 구조변화|컬럼 순서 변경시 ROW의 물리구조 변화]]====
==== [[오라클 컬럼저장 방식 개선 (12c 업그레이드) ]] ====
=== [[오라클 인덱스의 구조]] ===

----

= [[DBA_수행_방법론_(공공/대기업_SI_프로젝트)]]=
== [[DBA_수행_방법론_(공공/대기업_SI_프로젝트)#개요|개요]] ==
== [[단계별 수행 방법론]] ==
=== [[분석 단계]] ===
==== [[산출물]] ====
==== [[주요 작업 TASK]] ====
=== [[설계 단계]] ===
==== [[산출물]] ====
==== [[주요 작업 TASK]] ====
=== [[구축 단계]] ===
==== [[산출물]] ====
==== [[주요 작업 TASK]] ====
=== [[테스트 단계]] ===
==== [[산출물]] ====
==== [[주요 작업 TASK]] ====
=== [[전개 단계]] ===
==== [[산출물]] ====
==== [[주요 작업 TASK]] ====

----

틀:개요

2026-09-16T08:59:04Z

Dbstudy:

틀:개요

2026-09-16T08:58:34Z

Dbstudy:

틀:개요

2026-09-16T08:57:59Z

2026-09-16T08:49:19Z

Dbstudy:

== LOB(BLOB/CLOB)대용량 데이터 ==
=== 개요 ===
{{개요
|개요=LOB(BLOB/CLOB)이 대용량 데이터를 저장하는 핵심 원리는 '''"포인터(로케이터) + 별도 세그먼트 분리 저장"''' 구조
}}
<source>
LOB
├── Internal LOB (DB 내부 저장)
│ ├── CLOB (Character LOB) - 문자 데이터
│ ├── NCLOB (National CLOB) - 다국어 문자셋
│ └── BLOB (Binary LOB) - 바이너리 데이터
└── External LOB
└── BFILE - OS 파일시스템 참조 (읽기 전용)
</source>

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

=== LOB 저장 구조 (핵심) ===
:::<source>
Table Row
│
▼
┌─────────────┐
│ LOB LOCATOR │ ← 테이블 로우에 실제 저장되는 것 (포인터/핸들)
│ (약 4KB↓) │
└─────────────┘
│
▼
┌─────────────┐
│ LOB INDEX │ ← LOB 청크들을 관리하는 B-Tree 인덱스
└─────────────┘
│
▼
┌─────────────┐
│ LOB SEGMENT │ ← 실제 데이터가 저장되는 세그먼트 (CHUNK 단위)
└─────────────┘
</source>

=== LOB 로케이터(LOCATOR) ===
# 테이블 로우에는 실제 데이터가 아니라 LOB 데이터를 가리키는 40바이트 내외의 로케이터(포인터)만 저장됨
# 실제 데이터는 별도의 LOB 세그먼트에 존재하고, 애플리케이션은 이 로케이터를 통해 스트리밍 방식(READ/WRITE by chunk)으로 데이터에 접근함

=== In-row vs Out-of-row ===
:::- 데이터 크기가 작으면(기본 임계값 관련, ENABLE STORAGE IN ROW) 로우 내부에 직접 저장
:::- 임계값을 넘으면 별도의 LOB 세그먼트(out-of-row)에 체인 형태로 저장되고 로우에는 포인터만 남음
:::- 이 덕분에 4000바이트 제한을 가진 VARCHAR2/RAW와 달리 최대 4GB(BasicFile) ~ (LOB) 단위까지 저장 가능
::<source>
CLOB 데이터 크기 확인
│
├── 4000 bytes 이하 (기본값)
│ └── ENABLE STORAGE IN ROW
│ → 로우 내부에 직접 저장 (Inline)
│ → LOB Locator + 실제 데이터가 로우에 존재
│
└── 4000 bytes 초과 (또는 DISABLE STORAGE IN ROW)
└── OUT OF ROW 강제 이동
→ 로우에는 LOB Locator만 존재
→ 실제 데이터는 별도 LOB Segment에 저장
</source>

* 저장 방식 확인 테스트
<source lang=sql>
CREATE TABLE lob_test (
id NUMBER,
doc CLOB
) LOB (doc) STORE AS (
ENABLE STORAGE IN ROW -- 4000바이트 이하는 인라인
CHUNK 8192 -- 청크 크기
PCTVERSION 10 -- 버전 유지 비율
NOCACHE -- 버퍼캐시 사용 안함
LOGGING
);
</source>
* 성능 함정: 4000바이트 근처의 데이터가 빈번하게 업데이트되면 in-row ↔ out-of-row 전환이 발생하여 Row Migration과 유사한 오버헤드 발생.

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

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

=== LOB 인덱스 ===
LOB 세그먼트의 CHUNK 위치를 추적하기 위해 별도의 LOB 인덱스가 존재합니다(B-tree 구조로 CHUNK 매핑 관리).

* LOB 데이터가 여러 CHUNK에 걸쳐 저장될 때, 이 청크들의 순서와 위치를 관리하는 B-Tree 기반 인덱스.

<source>
LOB Locator (SETID + LENGTH 정보 포함)
│
▼
LOB Index (CHUNK 순서 매핑)
│
├── CHUNK 1 (위치: block#100)
├── CHUNK 2 (위치: block#105)
└── CHUNK 3 (위치: block#250)
</source>

* 왜 중요 한가?
# LOB의 부분 읽기/쓰기(Partial Read/Write) 시 이 인덱스를 통해 필요한 청크만 접근
# DBMS_LOB.READ(lob, amount, offset) 호출 시 인덱스를 스캔하여 offset에 해당하는 청크로 직행

=== PCTVERSION과 RETENTION (읽기 일관성) ===
==== 일반 테이블 vs LOB의 읽기 일관성 차이 ====
{| class="wikitable"
|+ 캡션 텍스트
|-
! 구분 !! 일반 테이블 !! LOB
|-
| 메커니즘 || UNDO Segment || LOB 자체 버전 관리
|-
| 위치 || 별도 UNDO 테이블스페이스 || LOB Segment 내부
|}

* 핵심: LOB은 UNDO를 사용하지 않고, 자체적으로 이전 버전 데이터를 LOB 세그먼트 내에 보관합니다.

==== PCTVERSION vs RETENTION ====
<source>
-- 방식 1: 공간 비율 기반 (전통적 방식)
PCTVERSION 10 -- 전체 LOB 세그먼트의 10%를 old version 유지에 사용
-- 초과 시 오래된 버전부터 재사용(overwrite)

-- 방식 2: 시간 기반 (Oracle 10g 이후 권장)
RETENTION -- UNDO_RETENTION 파라미터 값을 따름
-- 자동 스페이스 관리(ASSM) tablespace 필요
</source>
* 실무 팁: 대용량 LOB이 빈번히 업데이트되는 시스템에서 PCTVERSION이 너무 낮으면 ORA-22924 에러(snapshot too old 유사 현상) 발생 가능.

=== LOB 세그먼트 정보 확인 ===
<source lang=sql>
SELECT table_name, column_name, segment_name, index_name,
chunk, pctversion, cache, logging, in_row
FROM user_lobs -- dba_lobs
WHERE table_name = 'YOUR_TABLE';
</source>

=== SecureFile vs BasicFile ===
:- BasicFile: 전통적 방식, LOB 세그먼트에 체인 저장
:- SecureFile(11g+): ASSM 기반, 압축/중복제거/암호화 지원, 성능 개선된 구조로 대부분 권장

즉, "행 안에 다 넣지 않고 별도 세그먼트에 청크 단위로 분산 저장 + 로케이터로 참조"하는 것이 대용량 저장의 핵심 메커니즘입니다.
{| class="wikitable"
|+ 아키텍처 차이
|-
! 구분 !! BasicFile (Legacy) !! SecureFile (Modern)
|-
| 저장 구조 || 고정 청크 기반|| 가변 블록 + B-Tree 유사 구조
|-
| 압축 || 불가 || COMPRESS 옵션 지원
|-
| 중복제거 || 불가 || DEDUPLICATE 지원
|-
| 암호화 || 불가 || ENCRYPT 지원
|-
| 성능 || 불가 || 대폭 개선 (특히 순차 접근)
|}

----
# Oracle 19c LOB 저장 속성 정리

## LOB STORAGE 절 기본 구조
<source lang=sql>
LOB (column_name) STORE AS [SECUREFILE|BASICFILE] [lob_segment_name]
(
TABLESPACE ...
ENABLE|DISABLE STORAGE IN ROW
CHUNK n
PCTVERSION n | RETENTION [AUTO|MAX n|MIN n]
FREEPOOLS n
CACHE | NOCACHE | CACHE READS
LOGGING | NOLOGGING
COMPRESS [LOW|MEDIUM|HIGH] -- SecureFile 전용 기능
DEDUPLICATE | KEEP_DUPLICATES -- 동일 LOB 데이터 중복 제거 선택
ENCRYPT ... | DECRYPT
)
</source>

## 속성별 정리
{| class="wikitable"
|+ 캡션 텍스트
|-
! 속성 !! 설명 !! 비고
|-
| **SECUREFILE / BASICFILE** || LOB 저장 방식 선택 || SecureFile 권장(기본값은 DB_SECUREFILE 파라미터에 따름)
|-
| **ENABLE/DISABLE STORAGE IN ROW** || 로우 내 인라인 저장 여부 || 임계값 이하 데이터는 IN ROW 저장
|-
| **CHUNK** || LOB 저장 최소 단위(바이트) || 블록사이즈 배수, 기본 8K
|-
| **PCTVERSION** || (BasicFile 전용) 이전 버전 유지 공간 % || Undo 방식과 다른 read consistency
|-
| **RETENTION [AUTO/MAX/MIN]** || (SecureFile 전용) 버전 보존 정책 || AUTO가 일반적
|-
| **CACHE / NOCACHE / CACHE READS** || 버퍼캐시 사용 여부 || 대용량은 보통 NOCACHE
|-
| **LOGGING / NOLOGGING** || Redo 생성 여부 || 대량 초기 적재시 NOLOGGING 고려
|-
| **COMPRESS [LOW/MEDIUM/HIGH]** || (SecureFile 전용) 압축 레벨 || ACO(Advanced Compression) 라이선스 필요
|-
| **DEDUPLICATE / KEEP_DUPLICATES** || (SecureFile 전용) 중복 제거 || ACO 라이선스 필요
|-
| **ENCRYPT / DECRYPT** || (SecureFile 전용) 투명 암호화 | TDE 필요
|-
| **FREEPOOLS** || (SecureFile 전용) 동시성 향상용 free space pool 분리 || RAC 환경 동시 write 성능
|}
## 🆕 19c 관련 New Feature / 변경사항

**1. `DB_SECUREFILE` 파라미터 기본값 변경 없음, 단 SecureFile이 사실상 표준화**
- 12c부터 BasicFile은 "desupported"(deprecated) 상태 유지, 19c에서도 동일하게 BasicFile은 신규 개발에 비권장

**2. LOB 관련 초기화 파라미터 정리 지속**
- `DB_SECUREFILE` 파라미터 값: `PERMITTED`(기본), `ALWAYS`, `FORCE`, `NEVER`, `IGNORE`
- 19c에서도 동일 옵션 유지, ALWAYS/FORCE 사용시 BasicFile 문법도 자동으로 SecureFile로 생성

**3. JSON 관련 LOB 활용 강화 (19c 특징)**
- 19c의 확장된 JSON 지원(다중 JSON 컬럼, 부분 업데이트 등)이 내부적으로 SecureFile LOB 기반으로 동작 — LOB 자체의 새 절이라기보다는 LOB을 활용하는 상위 기능 확장

**4. In-Memory 관련**
- 19c에서 `INMEMORY` 절은 LOB 자체에는 직접 적용 불가(LOB은 IM 컬럼 스토어 미지원) — 이 제약은 계속 유지됨(신규 아님, 혼동 주의사항으로 정리)

**참고**: 19c 자체에서 LOB STORE AS 문법 자체에 **완전히 새로운 키워드가 추가된 것은 없고**, 12c~18c에서 도입된 SecureFile 관련 옵션들이 19c에서도 그대로 유지·강화되는 흐름입니다. 12c 이후 큰 변화는 없었고, 오히려 "BasicFile 지양, SecureFile 표준화"라는 정책적 방향이 19c에서 더 굳어진 것으로 보시면 됩니다.

특정 옵션(예: COMPRESS, DEDUPLICATE의 라이선스 조건이나 RAC FREEPOOLS 튜닝)에 대해 더 깊게 필요하시면 말씀해주세요.

==== CACHE / NOCACHE / CACHE READS ====
:* 소량/빈번 접근 LOB: CACHE (예: 사용자 프로필 이미지 썸네일)
:* 대량/1회성 접근 LOB: NOCACHE (예: 로그 파일, 대용량 첨부파일)

::<source>
-- 옵션 1: CACHE
-- LOB 데이터를 Buffer Cache에 정상적으로 캐싱 (일반 테이블처럼)
CACHE

-- 옵션 2: NOCACHE (기본값)
-- Direct Path I/O 사용, Buffer Cache 우회
-- 대용량 LOB에 적합 (캐시 오염 방지)
NOCACHE

-- 옵션 3: CACHE READS
-- 쓰기는 NOCACHE처럼, 읽기는 CACHE처럼 동작
CACHE READS
</source>

=== LOB과 트랜잭션 - Locator의 실체 ===
* LOB Locator 내부 구조 (개념적)
<source>
LOB Locator = {
LOB Type (CLOB/BLOB/BFILE)
LOB Length
Chunk Size
Position (현재 커서 위치 - 세션 내에서만 유효)
... (내부 메타데이터)
}
</source>

* 핵심 함정: LOB Locator의 생명주기
** 잘못된 사용 예 - LOB Locator를 커밋 후 재사용
**:<source lang=sql>
DECLARE
l_clob CLOB;
BEGIN
SELECT doc INTO l_clob FROM lob_test WHERE id=1;
COMMIT; -- ← 이 시점 이후 l_clob 사용 시 위험할 수 있음
DBMS_LOB.READ(l_clob, ...); -- ORA-22990 가능성
END;
</source>

* 원리: LOB Locator는 트랜잭션과 밀접하게 연관되어 있으며, 특정 상황(특히 원격 LOB이나 트랜잭션 경계를 넘는 경우)에서 무효화될 수 있습니다.

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

2026-09-16T08:31:04Z

Dbstudy:

== Cardinality (카디널리티) 와 Selectivity (선택도) ==
{{핵심
|제목= <big>'''핵심: High Cardinality = Low Selectivity = 인덱스 효과적 = 성능 좋음'''</big>
* '''Cardinality (카디널리티,고유값 수)'''
** 특정 연산이나 조건에서 반환되는 예상 행의 개수
** 절대적인 수치 (행 개수)
** 실행 계획의 “Rows” 컬럼에 표시됨
:: 예시:
성별 컬럼: Cardinality = 2 (남, 여)
주민번호 컬럼: Cardinality = 1,000,000 (100만 명이면 100만)

::* '''Selectivity (선택도)'''
** 전체 행 중에서 조건을 만족하는 행의 비율 (선택된 row 수 / 전체 row 수)
** 상대적인 비율 (0 ~ 1 사이의 값, 또는 0% ~ 100%)
** 조건의 “선택적” 정도를 나타냄
:: 예시:
성별='남': Selectivity = 0.5 (50%)
특정 주민번호: Selectivity = 0.000001 (0.0001%)

|내용 =실무에서 사용하는 방식

"이 컬럼 카디널리티가 높아서 인덱스 효과 좋을 거야"
= "이 컬럼 고유값이 많아서 인덱스 효과 좋을 거야"

"성별 컬럼은 카디널리티가 2야"
= "성별 컬럼은 고유값이 2개야"

"카디널리티 체크해봐"= "고유값 개수 확인해봐"
}}

::<source lang=sql>
Cardinality = Total Rows × Selectivity

Selectivity = Cardinality / Total Rows
</source>

=== 실무 예제 ===

:::* 예제 1: 단순 테이블
::::<source lang=sql>
-- 직원 테이블
CREATE TABLE employees (
emp_id NUMBER,
dept_id NUMBER,
salary NUMBER,
status VARCHAR2(20)
);

-- 통계 정보
-- Total Rows: 10,000명
-- dept_id = 10: 500명
-- salary > 5000: 3,000명
-- status = 'ACTIVE': 9,000명
</source>

::::-- Query 1
::::<source lang=sql>
SELECT * FROM employees WHERE dept_id = 10;
</source>

::::* Selectivity = 500 / 10,000 = 0.05 (5%)
::::* Cardinality = 500 (행)

::::-- Query 2
::::<source lang=sql>
SELECT * FROM employees WHERE salary > 5000;
</source>

::::* Selectivity = 3,000 / 10,000 = 0.3 (30%)
::::* Cardinality = 3,000 (행)

::::-- Query 3
::::<source lang=sql>
SELECT * FROM employees WHERE status = 'ACTIVE';
</source>

::::* Selectivity = 9,000 / 10,000 = 0.9 (90%)
::::* Cardinality = 9,000 (행)

=== 실행 계획 확인 ===
:::<source lang=sql>
-- 통계 수집
EXEC DBMS_STATS.GATHER_TABLE_STATS('SCOTT', 'EMPLOYEES');

-- 실행 계획 확인
EXPLAIN PLAN FOR
SELECT * FROM employees WHERE dept_id = 10;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
</source>

:::*실행 계획 결과:
:::<source lang=sql>
-------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
-------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 500 | 5000 | 10 (0)|
|* 1 | TABLE ACCESS FULL| EMPLOYEES | 500 | 5000 | 10 (0)|
-------------------------------------------------------------------------

Predicate Information:
1 - filter("DEPT_ID"=10)

Rows = 500 ← 이것이 Cardinality
</source>

=== Selectivity 계산 공식===
:::1. 등호(=) 조건
:::<source lang=sql>
-- WHERE column = value

Selectivity = 1 / NUM_DISTINCT

예: dept_id의 distinct 값이 20개
Selectivity = 1 / 20 = 0.05
</source>

:::2. 범위 조건
:::<source lang=sql>
-- WHERE column > value

Selectivity = (MAX_VALUE - value) / (MAX_VALUE - MIN_VALUE)

예: salary BETWEEN 3000 AND 10000
조건: salary > 5000
Selectivity = (10000 - 5000) / (10000 - 3000) = 5000/7000 ≈ 0.71
</source>

:::3. NULL 조건
:::<source lang=sql>
-- WHERE column IS NULL

Selectivity = NUM_NULLS / NUM_ROWS

예: 10,000행 중 500개가 NULL
Selectivity = 500 / 10,000 = 0.05
</source>

:::4. 복합 조건 (AND)
:::<source lang=sql>
-- WHERE col1 = 10 AND col2 = 'A'

Selectivity = Selectivity(col1) × Selectivity(col2)

예:
Selectivity(col1) = 0.05
Selectivity(col2) = 0.1
Total Selectivity = 0.05 × 0.1 = 0.005 (0.5%)
Cardinality = 10,000 × 0.005 = 50
</source>

:::5. 복합 조건 (OR)
:::<source lang=sql>
-- WHERE col1 = 10 OR col2 = 'A'

Selectivity = Sel(col1) + Sel(col2) - (Sel(col1) × Sel(col2))

예:
Selectivity(col1) = 0.05
Selectivity(col2) = 0.1
Total Selectivity = 0.05 + 0.1 - (0.05 × 0.1) = 0.145
Cardinality = 10,000 × 0.145 = 1,450
</source>

=== 통계 정보에서 확인 ===
:::<source lang=sql>
-- Selectivity 관련 통계
SELECT table_name,
column_name,
num_distinct, -- distinct 값 개수
num_nulls, -- NULL 개수
density, -- 1/num_distinct (Selectivity)
num_rows -- 전체 행 수
FROM user_tab_col_statistics
WHERE table_name = 'EMPLOYEES';
</source>

:::* 결과 예시:
:::<source lang=sql>
COLUMN_NAME NUM_DISTINCT NUM_NULLS DENSITY NUM_ROWS
---------------------------------------------------------
EMP_ID 10000 0 0.0001 10000
DEPT_ID 20 0 0.05 10000 ← Selectivity
SALARY 500 100 0.002 10000
STATUS 2 0 0.5 10000
</source>

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

-- 좋은 경우 (Selectivity: 0.001%)
CREATE INDEX idx_emp_id ON employees(emp_id);
-- emp_id는 고유값, 조회 시 1-2건만 반환

-- 나쁜 경우 (Selectivity: 90%)
CREATE INDEX idx_status ON employees(status);
-- status는 ACTIVE/INACTIVE 2개 값, 조회 시 9000건 반환
-- Full Table Scan이 더 효율적
</source>
::# 조인 순서 결정
::#: <source lang=sql>
-- Cardinality가 작은 테이블을 먼저 처리

SELECT /*+ LEADING(d e) */ *
FROM departments d
JOIN employees e ON d.dept_id = e.dept_id
WHERE d.location = 'SEOUL';

-- d 테이블의 Cardinality: 10 (Selectivity 1%)
-- e 테이블의 Cardinality: 10000 (Selectivity 100%)
-- → departments를 먼저 필터링하는 것이 효율적
</source>
::# 통계 정확도 확인
::#: <source lang=sql>
-- 실제 Cardinality vs 예상 Cardinality
SELECT /*+ GATHER_PLAN_STATISTICS */ *
FROM employees
WHERE dept_id = 10;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(format=>'ALLSTATS LAST'));
</source>
::# 결과:
::#: <source lang=sql>
-------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | ...
-------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 520 | ...
|* 1 | TABLE ACCESS FULL | EMP | 1 | 500 | 520 | ...
-------------------------------------------------------------------

E-Rows: 500 ← 예상 Cardinality (Estimated)
A-Rows: 520 ← 실제 Cardinality (Actual)
차이: 4% (통계가 정확함)
</source>

{{결론
|내용= [결론]
Cardinality vs. Selectivity
* 실무 팁: Selectivity가 5% 이하일 때 인덱스 사용이 효과적이고, Cardinality는 조인 순서와 메모리 할당에 영향을 미친다.
}}

{| class="wikitable"
|-
!구분 !! Cardinality !! Selectivity
|-
|의미 ||반환되는 행의 개수 ||선택되는 행의 비율
|-
|단위 ||행 (rows) ||비율 (0~1)
|-
|타입 ||절대값 ||상대값
|-
|사용처||실행 계획, Cost 계산||조건 효율성 판단
|-
|예시 ||500 rows ||5% (0.05)
|-
|}

Dbstudy: /* 실무 예제 */

== Cardinality (카디널리티) 와 Selectivity (선택도) ==
{{핵심
|제목= <big>'''핵심: High Cardinality = Low Selectivity = 인덱스 효과적 = 성능 좋음'''</big>
* '''Cardinality (카디널리티,고유값 수)'''
** 특정 연산이나 조건에서 반환되는 예상 행의 개수
** 절대적인 수치 (행 개수)
** 실행 계획의 “Rows” 컬럼에 표시됨
:: 예시:
성별 컬럼: Cardinality = 2 (남, 여)
주민번호 컬럼: Cardinality = 1,000,000 (100만 명이면 100만)

::* '''Selectivity (선택도)'''
** 전체 행 중에서 조건을 만족하는 행의 비율 (선택된 row 수 / 전체 row 수)
** 상대적인 비율 (0 ~ 1 사이의 값, 또는 0% ~ 100%)
** 조건의 “선택적” 정도를 나타냄
:: 예시:
성별='남': Selectivity = 0.5 (50%)
특정 주민번호: Selectivity = 0.000001 (0.0001%)

|내용 =실무에서 사용하는 방식

"이 컬럼 카디널리티가 높아서 인덱스 효과 좋을 거야"
= "이 컬럼 고유값이 많아서 인덱스 효과 좋을 거야"

"성별 컬럼은 카디널리티가 2야"
= "성별 컬럼은 고유값이 2개야"

"카디널리티 체크해봐"= "고유값 개수 확인해봐"
}}

::<source lang=sql>
Cardinality = Total Rows × Selectivity

Selectivity = Cardinality / Total Rows
</source>

=== 실무 예제 ===

:::* 예제 1: 단순 테이블
:::<source lang=sql>
-- 직원 테이블
CREATE TABLE employees (
emp_id NUMBER,
dept_id NUMBER,
salary NUMBER,
status VARCHAR2(20)
);

-- 통계 정보
-- Total Rows: 10,000명
-- dept_id = 10: 500명
-- salary > 5000: 3,000명
-- status = 'ACTIVE': 9,000명
</source>

-- Query 1
<source lang=sql>
SELECT * FROM employees WHERE dept_id = 10;
</source>

* Selectivity = 500 / 10,000 = 0.05 (5%)
* Cardinality = 500 (행)

-- Query 2
<source lang=sql>
SELECT * FROM employees WHERE salary > 5000;
</source>

* Selectivity = 3,000 / 10,000 = 0.3 (30%)
* Cardinality = 3,000 (행)

-- Query 3
<source lang=sql>
SELECT * FROM employees WHERE status = 'ACTIVE';
</source>

* Selectivity = 9,000 / 10,000 = 0.9 (90%)
* Cardinality = 9,000 (행)

=== 실행 계획 확인 ==

<source lang=sql>
-- 통계 수집
EXEC DBMS_STATS.GATHER_TABLE_STATS('SCOTT', 'EMPLOYEES');

-- 실행 계획 확인
EXPLAIN PLAN FOR
SELECT * FROM employees WHERE dept_id = 10;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
</source>

*실행 계획 결과:

<source lang=sql>
-------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
-------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 500 | 5000 | 10 (0)|
|* 1 | TABLE ACCESS FULL| EMPLOYEES | 500 | 5000 | 10 (0)|
-------------------------------------------------------------------------

Predicate Information:
1 - filter("DEPT_ID"=10)

Rows = 500 ← 이것이 Cardinality
</source>

=== Selectivity 계산 공식===
:::1. 등호(=) 조건
:::<source lang=sql>
-- WHERE column = value

Selectivity = 1 / NUM_DISTINCT

예: dept_id의 distinct 값이 20개
Selectivity = 1 / 20 = 0.05
</source>

:::2. 범위 조건
:::<source lang=sql>
-- WHERE column > value

Selectivity = (MAX_VALUE - value) / (MAX_VALUE - MIN_VALUE)

예: salary BETWEEN 3000 AND 10000
조건: salary > 5000
Selectivity = (10000 - 5000) / (10000 - 3000) = 5000/7000 ≈ 0.71
</source>

:::3. NULL 조건
:::<source lang=sql>
-- WHERE column IS NULL

Selectivity = NUM_NULLS / NUM_ROWS

예: 10,000행 중 500개가 NULL
Selectivity = 500 / 10,000 = 0.05
</source>

:::4. 복합 조건 (AND)
:::<source lang=sql>
-- WHERE col1 = 10 AND col2 = 'A'

Selectivity = Selectivity(col1) × Selectivity(col2)

예:
Selectivity(col1) = 0.05
Selectivity(col2) = 0.1
Total Selectivity = 0.05 × 0.1 = 0.005 (0.5%)
Cardinality = 10,000 × 0.005 = 50
</source>

:::5. 복합 조건 (OR)
:::<source lang=sql>
-- WHERE col1 = 10 OR col2 = 'A'

Selectivity = Sel(col1) + Sel(col2) - (Sel(col1) × Sel(col2))

예:
Selectivity(col1) = 0.05
Selectivity(col2) = 0.1
Total Selectivity = 0.05 + 0.1 - (0.05 × 0.1) = 0.145
Cardinality = 10,000 × 0.145 = 1,450
</source>

=== 통계 정보에서 확인 ===
:::<source lang=sql>
-- Selectivity 관련 통계
SELECT table_name,
column_name,
num_distinct, -- distinct 값 개수
num_nulls, -- NULL 개수
density, -- 1/num_distinct (Selectivity)
num_rows -- 전체 행 수
FROM user_tab_col_statistics
WHERE table_name = 'EMPLOYEES';
</source>

:::* 결과 예시:
:::<source lang=sql>
COLUMN_NAME NUM_DISTINCT NUM_NULLS DENSITY NUM_ROWS
---------------------------------------------------------
EMP_ID 10000 0 0.0001 10000
DEPT_ID 20 0 0.05 10000 ← Selectivity
SALARY 500 100 0.002 10000
STATUS 2 0 0.5 10000
</source>

=== 실무에서의 중요성 ===

1. 인덱스 생성 판단

<source lang=sql>
-- Selectivity가 낮을수록 (선택적일수록) 인덱스 효과 좋음

-- 좋은 경우 (Selectivity: 0.001%)
CREATE INDEX idx_emp_id ON employees(emp_id);
-- emp_id는 고유값, 조회 시 1-2건만 반환

-- 나쁜 경우 (Selectivity: 90%)
CREATE INDEX idx_status ON employees(status);
-- status는 ACTIVE/INACTIVE 2개 값, 조회 시 9000건 반환
-- Full Table Scan이 더 효율적
</source>

2. 조인 순서 결정

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

SELECT /*+ LEADING(d e) */ *
FROM departments d
JOIN employees e ON d.dept_id = e.dept_id
WHERE d.location = 'SEOUL';

-- d 테이블의 Cardinality: 10 (Selectivity 1%)
-- e 테이블의 Cardinality: 10000 (Selectivity 100%)
-- → departments를 먼저 필터링하는 것이 효율적
</source>

3. 통계 정확도 확인

<source lang=sql>
-- 실제 Cardinality vs 예상 Cardinality
SELECT /*+ GATHER_PLAN_STATISTICS */ *
FROM employees
WHERE dept_id = 10;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(format=>'ALLSTATS LAST'));
</source>

* 결과:

<source lang=sql>
-------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | ...
-------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 520 | ...
|* 1 | TABLE ACCESS FULL | EMP | 1 | 500 | 520 | ...
-------------------------------------------------------------------

E-Rows: 500 ← 예상 Cardinality (Estimated)
A-Rows: 520 ← 실제 Cardinality (Actual)
차이: 4% (통계가 정확함)
</source>

=== 핵심 차이점 요약 ===
:::{| class="wikitable"
|+ 캡션 텍스트
|-
!구분 !! Cardinality !! Selectivity
|-
|의미 ||반환되는 행의 개수 ||선택되는 행의 비율
|-
|단위 ||행 (rows) ||비율 (0~1)
|-
|타입 ||절대값 ||상대값
|-
|사용처||실행 계획, Cost 계산||조건 효율성 판단
|-
|예시 ||500 rows ||5% (0.05)
|-
|}

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