투씨에스지 기술 블로그

11g에서 암호화시 유의할점 본문

Oracle/Security

11g에서 암호화시 유의할점

TOCSG 2012.03.28 14:00

근래들어 11g를 사용하는 사이트가 부쩍 많아졌다.

10g도 desupport 되었으니.. 당연한건지도 모르겠지만...

11g에서는 플랜의 많은 변화가 생겼다. 쿼리 트랜스포메이션되는 것도 더 좋아졌고..ㅎㅎ

DB 암호화와 관련해서 11g에서 버그가 하나 있다..

 

NL 조인과 관련하여  11g부터 새로 생긴 Index Vector I/O 가 있다..

(새로워진 NL 조인에 대한 참고자료:  http://scidb.tistory.com/entry/Nested-Loop-Join-성능향상과-관련된-2가지-원리 )

 

자, 아래 간단한 쿼리를 보자..

 

select /*+ ordered use_nl(d) index(d) nlj_batching(d) */
*
from t_emp2 e, t_dept2 d
where d.no=e.no
and d.deptno=e.deptno


 

Execution Plan
--------------------------------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=14K Card=14K Bytes=757K)
   1    0   NESTED LOOPS
   2    1     NESTED LOOPS (Cost=14K Card=14K Bytes=757K)
   3    2       TABLE ACCESS (FULL) OF 'T_EMP2' (TABLE) (Cost=30 Card=14K Bytes=266K)
   4    2       INDEX (UNIQUE SCAN) OF 'T_DEPT_PK' (INDEX (UNIQUE)) (Cost=0 Card=1)
   5    1     TABLE ACCESS (BY INDEX ROWID) OF 'T_DEPT2' (TABLE) (Cost=1 Card=1 Bytes=37

 

 NL 조인이 두개 생기면서 index vector I/O 가 됨.. (nlj_batching 가 됨..)

 

[T_EMP2]

   Column Name                      Nullable Column Type     Distinct    Buckets
  -------------------------------- -------- ------------- ---------- ----------
  EMPNO                 NOT NULL    NUMBER(4)                         
  ENAME                                    VARCHAR2(10)                      
  JOB                                         VARCHAR2(9)                       
  MGR                                        NUMBER(4)                         
  HIREDATE                                DATE                              
  SAL                                         NUMBER(7,2)                       
  COMM                                     NUMBER(7,2)                       
  DEPTNO                                   NUMBER(2)                         
  NO                                         VARCHAR2(10)  

[T_DEPT2]

  Column Name                      Nullable Column Type     Distinct    Buckets
  -------------------------------- -------- ------------- ---------- ----------
  DEPTNO               NOT NULL    NUMBER(2)                         
  DNAME                                   VARCHAR2(14)                      
  LOC                                       VARCHAR2(13)                      
  NO                                         VARCHAR2(10) 

 

 

암호화를 하게 되면 컬럼 사이즈가 4000 으로 되는 경우가 있다.

컬럼 length 만 4000 으로 바꾸고 다시 플랜을 보자..

alter table t_emp2 modify  no varchar2(4000) ;

alter table t_dept2 modify  no varchar2(4000) ;

 

NO 컬럼이 varchar2(4000) 으로 변경된 상태에서 다시 플랜 확인

select /*+ ordered use_nl(d) index(d) nlj_batching(d) */
*
from t_emp2 e, t_dept2 d
where d.no=e.no
and d.deptno=e.deptno

 

Execution Plan
--------------------------------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=14K Card=14K Bytes=53M)
   1    0   NESTED LOOPS (Cost=14K Card=14K Bytes=53M)
   2    1     TABLE ACCESS (FULL) OF 'T_EMP2' (TABLE) (Cost=30 Card=14K Bytes=27M)
   3    1     TABLE ACCESS (BY INDEX ROWID) OF 'T_DEPT2' (TABLE)
   4    3       INDEX (UNIQUE SCAN) OF 'T_DEPT_PK' (INDEX (UNIQUE)) (Cost=0 Card=1)

헉;; 정통적인 예전 NL 조인 방식으로 돌아가 버렸다..

암호화 이후 배치에서 성능이 나빠졌던 원인중 하나가 바로 이거였던 것이다..

 

정확한 원인은 모르겠다.. 길이를 3950 으로 해도 index vector io 가 발생이 되는데.. 4000은 안된다..

버그가 아닐까? 하는 생각도 든다.. (원인을 찾아내면 다시 올리겠음)

일단 11g에서는 플랜의 변화가 심하게 일어날 수 있어 가급적이면 4000 자리를 그냥 쓰는건

위험할 수 있다..

 

 

 


 

 

 

'Oracle > Security' 카테고리의 다른 글

Oralce TDE  (0) 2015.03.13
DB 암호화 BMT 참고사항 및 평가항목  (0) 2012.10.16
11g에서 암호화시 유의할점  (0) 2012.03.28
암호화 전문 솔루션 cubeone vs oracle TDE 비교자료  (0) 2012.03.23
0 Comments
댓글쓰기 폼