1. 테이블스페이스 암호화
2. 테이블스페이스 암호화 사용법
3. 테이블스페이스 암호화가 적용된 데이터 저장
   1. 디스크에 저장
   2. SGA에 저장
4. 테이블스페이스 암호화의 성능 영향도 측정

테이블스페이스 암호화

1. 11gR1에서 도입
2. 테이블스페이스 내의 모든 세크먼트를 암호화해서 저장
3. 컬럼 레벨 암호화의 제약(통계정보 제약, 인덱스 제약, 참조키 제약)은 테이블스페이스 레벨의 암호화에는 없다.

테이블스페이스 암호화 사용법

1. 컬럼 레벨 암호화와 같이 wallet을 생성하고 release
2. 문법
   1. USING algorithm: 3DES168, AES128, AES192, AES256 중 선택(AES128이 디폴트)
   2. 볼드체로 표현된 부분은 꼭 작성이 필요
      

테이블스페이스 암호화가 적용된 데이터 저장

디스크에 저장

1. 모든 데이터베이스 블록은 16바이트의 배수로 되어 있기 때문에 데이터를 추가 변환할 필요가 없다.
2. 모든 데이터베이스 블록은 유일한 실체이기 때문에 SALT와 같은 옵션으로 값을 추가할 필요가 없다.
3. 비암호화 테이블스페이스/암호화 테이블스페이스가 차지하는 다스크 스토리지 공간은 같다.

SGA에 저장

1. 컬럼 레벨 암호화와 달리 암호화 테이블스페이스의 데이터는 암호화되지 않은 상태로 SGA에 저장된다.
2. 데이터베이스 블록이 디스크에서 버퍼 캐시로 읽혀질때 복호화를 하며 다시 디스크에 저장될때 DBWR이 암호화를 한다.
   
3. 데이터가 암호화 되지 않은 상태에서 캐시에 저장되기 때문에 복호화에 대한 추가 비용이 발생되지 않는다. (성능개선)
   1. 언두/리두가 암호화되어 생성되기 때문에 이에 따른 약간의 부하는 있다.
   2. temporary 데이터도 암호화되어 생성되기 때문에 PGA크기가 적절하지 않다면 이에 따른 부하가 발생한다.
4. 데이터가 암호화되지 않은상태로 SGA에 저장된다는 것은 SGA를 도용한다면 데이터를 볼 수 있다는 것이지만 데이터 암호화의 목적은 데이터파일내의 정적 데이터를 보호하기 위한 것임을 기억하자. (버퍼 캐시까지 암호화하고 싶다면 컬럼 레벨의 암호화 선택)

테이블스페이스 암호화의 성능 영향도 측정

1. 역시 암호화에 대한 부하 + 애플리케이션에서의 액세스 빈도/사용방법을 함께 고려해야 한다.
2. 예제 테스트
   1. 암호화 테이블스페이스와 비암호화 테이블스페이스 생성
      
   2. 사용할 테이블/인덱스 생성
      
      
      
   3. CPU/REDO 효율성을 체크할 프로시저 생성
      컬럼 레벨 암호와와 동일하게 생성했으나 달라진 부분은 강조 표시
      
   4. conventinal path 로드로 벌크 로드
      1. CPU는 거의 차이 없음
      2. 리두 생성도 거의 차이 없음
      3. 작업은 거의 버퍼캐시에서 수행되었으며 그로인해 큰 차이를 볼 수 없다.
         
   5. direct path 로드(버퍼캐시를 경유하지 않고 디스크 바로 사용)
      1. CPU는 이전보다 차이가 나기는 하지만 큰 차이 없음
         
   6. row별 INSERT 성능 확인
      1. 대부분 버퍼 캐시에서 작업이 발생하기 때문에 큰 차이는 거의 없다.
         
   7. 조회 성능 확인(기본키 값으로 각 테이블 로우 조회)
      1. 대부분 버퍼 캐시로부터 추출되기 때문에 암호화로 인한 불이익은 전혀 없다.
         
         
   8. 통계정보 확인
      1. 컬럼 레벨 암호화와 달리 암호화 전후의 예상 로우수가 다르지 않다.
      2. DBMS_STATS는 버퍼 캐시내의 블록 상의 통계정보를 수집하기 때문이다.