본문 바로가기
02. SQLP 스터디/03. 기출

SQLP 53회 후기 모음

notion9142 2025. 8. 24. 22:34

https://positivemh.tistory.com/893

 

오라클 19c 파티션 Exchange 방법

OS환경 : Oracle Linux 7.6 (64bit) DB 환경 : Oracle Database 19.16.0.0 방법 : 오라클 19c 파티션 Exchange 방법 오라클에서 파티션 테이블의 기간이 오래되서 데이터를 지워야하거나, 어떤 이유에 의해 특정 파티

positivemh.tistory.com

https://blog.naver.com/hanajava/220732766356

 

PE(Partition Exchange)를 이용해 대량의 Delete를 대신하기

대량의 데이터에 대한 Delete 작업이 필요한 경우가 있다. 가령 다음과 같이... Table tab1의 Column c1...

blog.naver.com

 

  저는 시험은 보지 않았지만, 여기저기 후기글들을 보니 친절한 SQL 튜닝 456~459페이지를 응용한 문제가 출제된 듯합니다. 파티션 Exchange를 이용한 대량 데이터 변경
  실기는 솔직히 제대로 쓰지를 못했습니다.
​
1번 문제는 Plan 보고 SQL 작성하는 문제 였고,
2번 문제는 Merge문 튜닝하는 문제인데 CTAS문을 만들고 파티션 Exchange 하는 문 만들기 였는데,
​
막상 문제 보니 하얗게 머리가 비어 버려서 ㅠㅠ
​
물론 합격을 하고자 시험을 응시한게 아니지만은, 많이 아쉬웠습니다.
​
시험보고 많이 반성하면서도 어떻게 공부를 해야겠다는 방향제시를 해주는거 같아서 많은걸 느꼈습니다.
​
지금까지 공부는
​
1. SQL 기본과정 수강(2023년)
2. 친절한 SQL 튜닝
3. 성능 고도화 1,2권
4. SQLP 자격검정 핵심노트 1,2권
5. SQLP 고급반 수강(2025/06월 수강)
​
이렇게 준비하며 공부했습니다.
​
이번에 SQLP 고급반 수강하면서,
​
강사님이 시험을 목표로 공부하지 말라고 말씀하신부분이 강하게 제 뇌리에 박혔습니다.

자격증을 위한 공부가 나한테 무슨 소용이 있는가? 많이 반성하게 하는 한 부분이었습니다.
​
현재 직무는 DBA 업무를 하고 있습니다.
​
업무하면서, DBA가 직접 쿼리를 짜는 부분이 많이 없습니다. 아니 없습니다.(물론 성능이나, 오브젝트 관리를 위한 쿼리는 짜지만요)
​
그래서 쿼리 부분은 DBA가 많이 약하다고 생각됩니다. 개발자보다는...
​
물론 쿼리를 잘 짜시는 DBA 분들도 많이 있습니다.
​
전 개인적으로 SQLP 공부를 하면서 DBA 업무중 튜닝 부분은 많은 도움이 됐습니다.(튜닝 성과도 많이 이뤘습니다.)
​
일단 내년 3월 목표로 SQLP 도전은 다시 할 생각입니다.
(자격증을 위한 도전은 아닙니다. ㅎㅎㅎ)
​
SQLP 고급반 수강과, SQLP 시험으로 어떻게 공부를 해야할지 방향을 제시받은거 같아서 나름 성과가 있었다고 생각됩니다.
​
두서 없이 글을 썼는데 아무튼 제가 하고 싶은 말은 SQLP 시험 어렵다 입니다.
  실기 1번은 그나마 "튜닝 후 실행계획"을 보여주고 푸는 문제라
실행계획 따라가며 어느정도 작성했는 데,
실기 2번은 30분 넘게 붙잡았다가 결국엔 포기(?)하다시피 했네요.
​
찾아보니 "PARTITION EXCHANGE" 관련 문제인것 같은 데,
부끄럽지만 여지껏 제가 오라클을 접하면서 처음 들어본 영역이네요.
인터넷을 뒤져가며 관련 정보를 찾아 보고 있지만, 왠지 이 영역은
실무 경험이 많은 사람이 아닌 저처럼 시험이나 학습 목적으로 한
사람에게는 생소하리라 생각됩니다.
​
앞으로 시험은 재도전하겠지만 공부 수준을 어느 정도까지
더 들어가야 할 지는 고민을 많이 해야 할 것 같습니다.
여하튼 SQLP, 만만한 시험은 아니네요.
​
아무쪼록 오늘 시험 보신 분들 모두 고생하셨습니다.
​
​
  객관식
1과목
​
​
a+b 키가 잇는데 a 로 줄엿을때 이걸 뭐라하는가?
답 최소성
​
2과목
피벗 1문제, 정규식2문제 substr관련 {3,5} a, aa, aaa, aaaa,
​
3과목
실제 과장개수가 5개인데
where 과장=:과장
했을때 예상 갯수 몇개냐고물어보는 문제
정답은 4개임
​
실기1
t1 t2 t3 t4
​
문제 쿼리
select *
​
(
select 1 as tp, b.nm
from t1 a, t3 b
union all
select 2 as tp
from t2 a, t3 b
)
order by tp, id) a
where exists (select 1 from t4 where cd=a.cd) and rownum <=10
​
인덱스
t1 dt+id 일반인덱스
t2 dt+id 일반인덱스
t3 유니크인덱스 id
t4 유니크 인덱스 cd
​
​
유니온 올(각각 스탑키) + 전체스탑키
변경후 실행게획과 똑같이구현
​
​
작성한 쿼리
select /*+ leading(a) nlj_batching(b) */
tp, b.nm
from
(select 1 as tp, a.*
From t1 a, t4 b
where a.dt = DATE '2025-01-01'
and a.cd = b.cd)
union all
select 2 as tp, a.*
From t2 a, t4 b
where a.dt = DATE '2025-01-01'
and a.cd = b.cd)
​
오더바이 중간에 넣은걸로기억
인덱스에 의해 실행겜획에서 생략
​
rownum <=10
​
​
​
​
​
​
실행계획
select
stop key
view
nested loops
nested loops

​
​
실기2
머지문 먼저 확인
업데이트 90퍼
삭제10펴
추가10퍼
​
merge /*+ leading(b) into t1 a
using t2 b
on(a.dt = and b.id =a.id)
when matched then
update
​
insert
​
when not matched then
delete
​
202501 요녀석<<
202502
테이블 + 인덱스 생성 후
파티션 익스체인지 해야함
​
​
내가 구현해야할 실행계획
load
view
partition
table access
table access
​
 
 
  https://cafe.naver.com/common/storyphoto/viewer.html?src=https%3A%2F%2Fcafeptthumb-phinf.pstatic.net%2FMjAyNTA4MjNfMjMx%2FMDAxNzU1OTMwNTAxODMw.xwodKQsvtOcowfC4gqatVIqwPwoiNC6bxB_KBAFwZSIg.ugjZ5VpJ42u5gH5Q6idOiwJS9Qy3qswy1_h-ERqsRkcg.PNG%2Fimage.png%3Ftype%3Dw1600
튜닝
튜닝후 실행계획
  튜닝후 SQL
​
​
튜닝 후가 제가 작성한 답안입니다.
튜닝 전은 저 둘 중 하나였는데 명확하지 않아 둘다 적습니다.
​
​
실기 2번
​
파티션 익스체인지 문제였고 MERGE문의 update/delete/insert를 ctas full outer join으로 풀어내서 익스체인지 하는거였습니다.(nologging 사용금지, 임시테이블 인덱스 사용해서 파티션 익스체인지).
  실기 1번 아래와 같은 DDL이 주어졌던 것 같습니다.

CREATE TABLE t1 (dt DATE NOT NULL, cd NUMBER NOT NULL, id NUMBER NOT NULL);
CREATE TABLE t2 (dt DATE NOT NULL, cd NUMBER NOT NULL, id NUMBER NOT NULL);
CREATE TABLE t3 (id NUMBER NOT NULL, nm varchar(50) NOT NULL);
CREATE TABLE t4 (cd NUMBER NOT NULL);

CREATE INDEX t1_x1 ON t1(dt,id);
CREATE INDEX t2_x1 ON t2(dt,id);
CREATE UNIQUE INDEX t3_x1 ON t3(id);
CREATE UNIQUE INDEX t4_x1 ON t4(cd);
튜닝 후 실행계획
  아마도 id 5,6 번은 실제 실기에서는 안 보였던 것 같습니다.
기억을 더듬어 비슷하게 유도해보았는데 정확하진 않을 것 같아요.

(아 그리고 Id, Operation, Name만 주어졌던 것 같습니다)

여기서 (4),5,6id는 없고 18id가 7id랑같은 레벨이었던걸로 기억합니다. 실행계획이 생각보다 좀 애매하게 나왔던거같습니다.
  여행조아유오혹시 이런 실행계획이었나요? 제 기억과 가장 유사한 버전이에요


union all 안에 있는 count key 내부에 view를 봤던 것 같은데 이것도 7이랑 18이랑 같은 라인은 아니네요
 
  돌려보니까 id 1번에 sort order by가 보여서 정답은 아닌 것 같습니다 ㅎㅎ...

union all 위 아래의 인라인 뷰에는 rownum, order by가 있어서 뷰 머징 대상은 아닌 것 같아서 no_merge 힌트는 주지 않았습니다.
 
  실기 2에서 기억나는 부분들입니다.

-- 아래 SQL을 변경 후 실행계획이 나오도록 SQL을 수정하고 힌트를 작성하시오.
-- 아래 SQL 실행 시 수정 80%, 수정 10%, 변경 10%가 일어나서 redo, undo 로깅에 비효율이 있다.
-- 병렬, nologging은 고려하지 않는다.

CREATE TABLE t1 (
dt DATE NOT NULL,
id NUMBER NOT NULL,
val NUMBER NOT NULL
)
PARTITION BY RANGE (dt)
(
PARTITION p2025_01 VALUES LESS THAN (DATE'2025-02-01'),
PARTITION p2025_02 VALUES LESS THAN (DATE'2025-03-01'),
PARTITION p2025_03 VALUES LESS THAN (DATE'2025-04-01'),
PARTITION p2025_04 VALUES LESS THAN (DATE'2025-05-01'),
PARTITION p2025_05 VALUES LESS THAN (DATE'2025-06-01'),
PARTITION p2025_06 VALUES LESS THAN (DATE'2025-07-01'),
PARTITION p2025_07 VALUES LESS THAN (DATE'2025-08-01'),
PARTITION p2025_08 VALUES LESS THAN (DATE'2025-09-01'),
PARTITION p2025_09 VALUES LESS THAN (DATE'2025-10-01'),
PARTITION p2025_10 VALUES LESS THAN (DATE'2025-11-01'),
PARTITION p2025_11 VALUES LESS THAN (DATE'2025-12-01'),
PARTITION p2025_12 VALUES LESS THAN (DATE'2026-01-01'),
PARTITION p2025_max VALUES LESS THAN (MAXVALUE)
);

CREATE TABLE s1(dt DATE, id NUMBER NOT NULL, val NUMBER NOT null);

-- 변경 전 SQL
MERGE INTO t1
USING s1 ON (
t1.dt = s1.dt
AND s1.id = t1.id --------> 여기 DATE '2025-01-01' 같은 조건절이 있었던가요...
)
WHEN MATCHED THEN
UPDATE
SET val = t1.val + s1.val
DELETE
WHERE val <= 100
WHEN NOT MATCHED THEN
INSERT (dt, id, val)
VALUES (s1.dt, s1.id, s1.val);

[확실한 것]
t1이 date range 파티션 테이블이었고, 파티션 키 컬럼으로 구성된 Local patition index를 가지고 있었습니다.

[기억이 안 나는 것]
not null 같은 제약은 기억이 안 나서 정확하지 않을 수 있어요.
s1은 비파티션 이었고 인덱스가 하나 있던 것 같습니다.
  CTAS 실행계획이었고,

VIEW
HASH JOIN FULL OUTER

이런 키워드가 보였어요.
  VW_FOJ_0 이라는 내부적으로 만든 뷰(?)가 보였던 것 같습니다.
 
  1번 실기 뷰 안에 유니온 되는 테이블들
NO_Nlj_batching 설정해주셔야 튜닝후 실행계획과 같고
T3 조인시 nlj_batching 해야 같은 실행계획 나타납니다.
  실기 1문제
문제 : 아래의 쿼리를 실행결과와 동일하게 구현하기
SELECT *
FROM (SELECT 1 as tp, a.*, b.nm
FROM t1 a, t3 b
WHERE b.id = a.id
UNION ALL
SELECT 1 as tp, a.*, b.nm
FROM t2 a, t3 b
WHERE b.id = a.id
) a, t4 b
WHERE b.cd = a.cd
AND ROWNUM <= 10

실행결과
SELECT STATEMENT
COUNT STOPKEY
NESTED LOOPS
NESTED LOOPS
VIEW
UNION ALL
COUNT STOPKEY
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID 'T1'
INDEX RANGE SCAN 'T1_U1'
INDEX RANGE SCAN 'T4_U1'
COUNT STOPKEY
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID 'T2'
INDEX RANGE SCAN 'T2_U1'
INDEX RANGE SCAN 'T4_U1'
INDEX RANGE SCAN 'T3_U1'
TABLE ACCES BY INDEX ROWID 'T3'

답변
SELECT /*+ LEADING(A) USE_NL(B) */ a.*, b.nm
FROM (SELECT *
FROM (
SELECT /*+ NO_MERGE LEADING(A) USE_NL(B) INDEX(a T1_U1) INDEX(b T4_U1) */
1 as tp, a.*
FROM t1 a, t4 b
WHERE b.cd = a.cd
ORDER BY a.cd)
WHERE ROWNUM <= 5
UNION ALL
SELECT *
FROM (
SELECT /*+ NO_MERGE LEADING(A) USE_NL(B) INDEX(a T2_U1) INDEX(b T4_U1) 8/
1 as tp, a.*, b.nm
FROM t2 a, t3 b
WHERE b.id = a.id
ORDER BY a.cd)
WHERE ROWNUM <= 5
) a, t4 b
WHERE b.cd = a.cd
AND ROWNUM <= 10


실기 2문제
문제 : 대량 DML 최적화 -> CTAS + 파티션 교체 전략 (MERGE 문을 이용해 t1과 t2 통합해야 하지만 대량의 redo/undo 발생)
조건 : PARALLEL, NOLOGGING 사용하지 않음
MERGE INTO t1
USING t2 s
ON (t.id = s.id)
WHEN MATCHED THEN
UPDATE SET t1.sal = t1.sal + s.sal
DELETE WHERE t1.sal <= 100
WHEN NOT MATCHED THEN
INSERT (id, sla) VALUES (s.id, s.sal);

실행결과
LOAD AS SELECT
HASH JOIN OUTER
PARTITION RANGE SINGLE
TABLE ACCESS FULL 'T1'
TABLE ACCESS FULL 'T2'

답변
1) MERGE → CTAS 구문으로 대체
CREATE TABLE t1_new
AS
SELECT *
FROM t1 a
LEFT JOIN t2 b
ON (a.dt = b.dt
a.id = b.id);

2) 인덱스 생성 및 삭제 구문 (UPDATE 90% 처리)
CREATE INDEX ix_t1_01 ON (dt,id) NOLOGGING;
DROP INDEX ix_t1_01;

3) 파티션 교체 구문
ALTER TABLE t1
EXCHANGE PARTITION p202502
WITH TABLE t1_new
INCLUDING INDEXES
WITHOUT VALIDATION;
 
 
 
 
 
  실기 1번은 파이팅해야지님이 적어주신게 제일 비슷한 것 같습니다.
정리하자면

문제 1번
CREATE TABLE t1 (dt DATE NOT NULL, cd NUMBER NOT NULL, id NUMBER NOT NULL);
CREATE TABLE t2 (dt DATE NOT NULL, cd NUMBER NOT NULL, id NUMBER NOT NULL);
CREATE TABLE t3 (id NUMBER NOT NULL, nm varchar(50) NOT NULL);
CREATE TABLE t4 (cd NUMBER NOT NULL);

CREATE INDEX t1_x1 ON t1(dt,id);
CREATE INDEX t2_x1 ON t2(dt,id);
CREATE UNIQUE INDEX t3_x1 ON t3(id);
CREATE UNIQUE INDEX t4_x1 ON t4(cd);
 
  실기 2번

문제 :
대량 DML을 하는데에 부하가 너무 심하다. 갱신은 80%, 삽입 10% 삭제10%정도로 작업된다.
단, PARALLEL, NOLOGGING 사용하지 않음
MERTGE문을 CTAS로 구현하고 인덱스 생성 및 파티션 exchange구문을 작성하여라.
정확한 구현을 위해 힌트를 작성하여라.


CREATE TABLE t1 (
dt DATE NOT NULL,
id NUMBER NOT NULL,
val NUMBER NOT NULL
)
PARTITION BY RANGE (dt)
(
PARTITION p2025_01 VALUES LESS THAN (DATE'2025-02-01'),
PARTITION p2025_02 VALUES LESS THAN (DATE'2025-03-01'),
PARTITION p2025_03 VALUES LESS THAN (DATE'2025-04-01'),
PARTITION p2025_04 VALUES LESS THAN (DATE'2025-05-01'),
PARTITION p2025_05 VALUES LESS THAN (DATE'2025-06-01'),
PARTITION p2025_06 VALUES LESS THAN (DATE'2025-07-01'),
PARTITION p2025_07 VALUES LESS THAN (DATE'2025-08-01'),
PARTITION p2025_08 VALUES LESS THAN (DATE'2025-09-01'),
PARTITION p2025_09 VALUES LESS THAN (DATE'2025-10-01'),
PARTITION p2025_10 VALUES LESS THAN (DATE'2025-11-01'),
PARTITION p2025_11 VALUES LESS THAN (DATE'2025-12-01'),
PARTITION p2025_12 VALUES LESS THAN (DATE'2026-01-01'),
PARTITION p2025_max VALUES LESS THAN (MAXVALUE)
);


CREATE TABLE t2 (dt,id,val); (t1과 컬럼이 동일하게 구성된 일반 테이블)

CREATE INDEX T1_PK (dt,id) local;
CREATE INDEX T2_PK (dt,id);

<MERGE문>
MERGE INTO t1 partition(p2025_01) t
USING t2 s
ON (t.id = s.id)
WHEN MATCHED THEN
UPDATE SET t1.sal = t1.sal + s.sal
DELETE WHERE t1.sal <= 100
WHEN NOT MATCHED THEN
INSERT (t.id, t.sal) VALUES (s.id, s.sal);

<변경 후 실행계획>
CREATE
LOAD AS SELECT
VIEW (VW_FOJ_0 )
HASH JOIN FULL OUTER
PARTITION RANGE SINGLE
TABLE ACCESS FULL 'T1'
TABLE ACCESS FULL 'T2'
  파티션 Exchange가 시험에 나왔나 보네요 마침 오늘 업무 중에 확인할 것이 있어서^^
저희는 파티션을 high compress로 압축하는데 따로 임시 테이블로 빼내서 압축후 교환하는데 씁니다.
빠르게 압축할 수 있는 방법으로 만드신 거 같네요

https://datacloud.tistory.com/14
  https://bae9086.tistory.com/575

https://bae9086.tistory.com/575

 

Lob Partition 의 partition과 lob partition의 default attributes 설정 변경하여 자동으로 추가되는 파티션 압

구문일반 테이블 영역 default attributes 변경 구문ALTER TABLE 테이블명 MODIFY DEFAULT ATTRIBUTES COMPRESS 압축옵션;lob 테이블 영역 default attributes 변경 구문ALTER TABLE 테이블명 MODIFY DEFAULT ATTRIBUTES LOB(LOB 컬럼명

bae9086.tistory.com

 

구문
일반 테이블 영역 default attributes 변경 구문
lob 테이블 영역 default attributes 변경 구문
 
테스트를 위해 CLOB이 포함된 테이블 하나를 생성하고 옵션 설정 전/후를 비교하여 추가된 파티션이 압축옵션을 가지고 있는지 테스트해보겠습니다.

1.테스트테이블 생성
 
CREATE TABLE LOB_PART_TEST (
ID VARCHAR2(10) NOT NULL,
NAME VARCHAR2(10) NOT NULL,
MSG CLOB,
SEQ NUMBER
)
TABLESPACE USERS
LOB(MSG) STORE AS SECUREFILE
PARTITION BY RANGE (ID)
(
PARTITION PT_LOB_PART_TEST_P1 VALUES LESS THAN ('10')
TABLESPACE USERS
)
;


2.상태 확인
둘다 compress관련된 부분에 설정이 되어 있지 않습니다.
 
SELECT owner,table_name,PARTITIONING_TYPE,PARTITION_COUNT,DEF_COMPRESSION,DEF_COMPRESS_FOR FROM dba_part_tables WHERE table_name='LOB_PART_TEST';
OWNER |TABLE_NAME   |PARTITIONING_TYPE|PARTITION_COUNT|DEF_COMPRESSION|DEF_COMPRESS_FOR|
------+-------------+-----------------+---------------+---------------+----------------+
SYSTEM|LOB_PART_TEST|RANGE            |              2|NONE           |                |

SELECT TABLE_owner,table_name,column_name,lob_name,DEF_COMPRESS FROM dba_part_lobs WHERE table_name='LOB_PART_TEST';

TABLE_OWNER|TABLE_NAME   |COLUMN_NAME|LOB_NAME                 |DEF_COMPRESS|
-----------+-------------+-----------+-------------------------+------------+
SYSTEM     |LOB_PART_TEST|MSG        |SYS_LOB0000077784C00003$$|NO          |

3.파티션 add 하여 옵션 확인
ALTER TABLE LOB_PART_TEST ADD PARTITION PT_LOB_PART_TEST_P2 VALUES less than ('20');




4.파티션 확인
추가된 PT_LOB_PART_TEST_P2는 테이블영역과 LOB영역 둘다 압축이 되지 않고 추가되었습니다.
 
SELECT table_owner,table_name,partition_name,high_value,tablespace_name,compression,compress_for FROM dba_tab_partitions WHERE table_name='LOB_PART_TEST';
TABLE_OWNER|TABLE_NAME   |PARTITION_NAME     |HIGH_VALUE|TABLESPACE_NAME|COMPRESSION|COMPRESS_FOR|
-----------+-------------+-------------------+----------+---------------+-----------+------------+
SYSTEM     |LOB_PART_TEST|PT_LOB_PART_TEST_P1|'10'      |USERS          |DISABLED   |            |
SYSTEM     |LOB_PART_TEST|PT_LOB_PART_TEST_P2|'20'      |USERS          |DISABLED   |            |

SELECT table_owner,table_name,lob_name,tablespace_name,compression FROM dba_lob_partitions WHERE table_name='LOB_PART_TEST';

TABLE_OWNER|TABLE_NAME   |LOB_NAME                 |TABLESPACE_NAME|COMPRESSION|
-----------+-------------+-------------------------+---------------+-----------+
SYSTEM     |LOB_PART_TEST|SYS_LOB0000077784C00003$$|USERS          |NO         |
SYSTEM     |LOB_PART_TEST|SYS_LOB0000077784C00003$$|USERS          |NO         |
 

5. 설정변경
 
ALTER TABLE LOB_PART_TEST MODIFY DEFAULT ATTRIBUTES COMPRESS FOR OLTP;
ALTER TABLE LOB_PART_TEST MODIFY DEFAULT ATTRIBUTES LOB(MSG) (COMPRESS HIGH);
 

SELECT owner,table_name,PARTITIONING_TYPE,PARTITION_COUNT,DEF_COMPRESSION,DEF_COMPRESS_FOR FROM dba_part_tables WHERE table_name='LOB_PART_TEST';
OWNER |TABLE_NAME   |PARTITIONING_TYPE|PARTITION_COUNT|DEF_COMPRESSION|DEF_COMPRESS_FOR|
------+-------------+-----------------+---------------+---------------+----------------+
SYSTEM|LOB_PART_TEST|RANGE            |              2|ENABLED        |ADVANCED        |

SELECT TABLE_owner,table_name,column_name,lob_name,DEF_COMPRESS FROM dba_part_lobs WHERE table_name='LOB_PART_TEST';
TABLE_OWNER|TABLE_NAME   |COLUMN_NAME|LOB_NAME                 |DEF_COMPRESS|
-----------+-------------+-----------+-------------------------+------------+
SYSTEM     |LOB_PART_TEST|MSG        |SYS_LOB0000077784C00003$$|HIGH        |


6.파티션 add하여 추가된 파티션 설정 확인
 
ALTER TABLE LOB_PART_TEST ADD PARTITION PT_LOB_PART_TEST_P3 VALUES less than ('30');

SELECT table_owner,table_name,partition_name,high_value,tablespace_name,compression,compress_for FROM dba_tab_partitions WHERE table_name='LOB_PART_TEST';
TABLE_OWNER|TABLE_NAME   |PARTITION_NAME     |HIGH_VALUE|TABLESPACE_NAME|COMPRESSION|COMPRESS_FOR|
-----------+-------------+-------------------+----------+---------------+-----------+------------+
SYSTEM     |LOB_PART_TEST|PT_LOB_PART_TEST_P1|'10'      |USERS          |DISABLED   |            |
SYSTEM     |LOB_PART_TEST|PT_LOB_PART_TEST_P2|'20'      |USERS          |DISABLED   |            |
SYSTEM     |LOB_PART_TEST|PT_LOB_PART_TEST_P3|'30'      |USERS          |ENABLED    |ADVANCED    |
SELECT table_owner,table_name,lob_name,tablespace_name,compression FROM dba_lob_partitions WHERE table_name='LOB_PART_TEST';
TABLE_OWNER|TABLE_NAME   |LOB_NAME                 |TABLESPACE_NAME|COMPRESSION|
-----------+-------------+-------------------------+---------------+-----------+
SYSTEM     |LOB_PART_TEST|SYS_LOB0000077784C00003$$|USERS          |NO         |
SYSTEM     |LOB_PART_TEST|SYS_LOB0000077784C00003$$|USERS          |NO         |
SYSTEM     |LOB_PART_TEST|SYS_LOB0000077784C00003$$|USERS          |HIGH       |


새로 추가된 파티션은 COMPRESS가 잘 되서 생성되었습니다.
 
참고로 LOB 의 compress 옵션에는 LOW/MEDIUM/HIGH가 있습니다.
압축률에 따른 차이로 보이며 성능에도 차이가 있을 수있습니다. 아무래도 압축률이 높은 HIGH로 수행하면 성능이 안나올 수 있을것도 같네요.
 
 
 
 
   
   

'02. SQLP 스터디 > 03. 기출' 카테고리의 다른 글

SQLP 46 [2022.09.04]  (3) 2025.04.07
SQLP 47  (0) 2025.04.07
SQLP 48-2  (0) 2025.04.07
SQLP 48-1  (0) 2025.04.07
SQLP 49-2  (0) 2025.04.06

'02. SQLP 스터디/03. 기출' Related Articles

티스토리툴바