SecureFiles: 새로운LOB

간략한 개요

암호화, 압축, 중복 제거(deduplication) 등을 지원하는 등 비정형 데이터를 저장할 수 있도록 외부 파일 및 데이터베이스 LOB 환경의 최고 장점만을 제공하는 차세대 LOB: SecureFile을 사용할 수 있는 방법을 확인해 보십시오.

데이터베이스 상주 BLOBS 또는 OS 파일

Oracle Database에 무엇을 저장하고 있습니까 대부분은 정의된 패턴의 일부 형식으로 매핑이 손쉽도록 관계형 형식으로 저장되거나 고객 이름, 경상 수지, 상태 코드 등과 같이 정의된 데이터 유형으로 저장된 데이터일 것입니다. 한편, 비정형 또는 준정형 형태로 정보를 저장해야 하는 경우도 점차 늘고 있습니다. 사진, 워드 프로세싱 문서, 스프레드시트, XML 파일 등이 여기에 해당됩니다. 그렇다면 이러한 유형의 데이터는 어떻게 저장될까요

일반적으로 데이터를 LOB 필드(바이너리를 위한 BLOB 및 문자 데이터를 위한 CLOB)로서 데이터베이스에 저장하거나 데이터베이스에 저장된 파일에 대한 참조를 가진 OS 파일로 저장하는 두 가지 방법이 있습니다.

각각의 접근 방식은 장단점이 있습니다. OS 파일은 시스템 다운 이후 신속한 복구를 지원하는 OS 및 JFS(Journaled File System)에 의해 캐싱됩니다. 또한, 압축이 가능하기 때문에 일반적으로 데이터베이스의 데이터 보다 공간을 적게 차지합니다.

파일에서 패턴을 지능적으로 식별하고 보다 효율적인 저장을 위해 중복을 제거할 수 있는 툴도 있습니다. 하지만, 이들 툴은 데이터베이스 외부에 있기 때문에 데이터베이스의 속성이 적용되지 않습니다. 이들 파일은 백업 되지 않고 세분화된 보안은 이들 파일에 적용되지 않으며 이러한 파일은 트랜잭션의 일부가 아니기 때문에 읽기 일관성 같은 Oracle Database 고유의 개념은 적용되지 않습니다.

두 환경의 최고 장점만을 얻을 수 있다면 어떨까요 Oracle Database 11g의 경우, 데이터베이스 상주 LOB 및 OS 파일의 최고 기능을 제공하는 데이터베이스 내의 완전 새로운 인프라인 SecureFile에서 해답을 얻었습니다. 그 방법은 다음과 같습니다 (어쨌든 기존의 LOB는 여전히 BasicFile 형식으로 사용 가능).

ORIG_FILE 열은 바이너리 형식의 실제 파일이 저장되는 장소입니다. 다양한 매개 변수가 연산이 수행되는 동안 LOB이 캐싱 및 로깅되지 않아야 하고 테이블 행에 일치하도록 저장되어야 하며 청크(chunk) 크기가 4KB이어야 하고 USERS 테이블스페이스에 저장되어야 함을 나타내고 있습니다. 이를 명시적으로 지정하지 않았기 때문에 LOB가 Oracle Database 11g 하에서 주로 사용되던 기존 형식(BasicFile)으로 저장되었습니다.
SecureFile로 LOB를 저장하고 싶은 경우에는 아래와 같이 테이블 생성에 있어 store as securefile 절을 입력하기만 하면 됩니다.

SecureFile LOB를 생성하려면 2가지 조건을 충족해야 합니다. 하지만 두 조건 모두 기본값으로 설정되어 있기 때문에 이미 조건을 충족하고 있을 것입니다.
초기화 매개 변수 db_securefile을 허용(permitted)으로 설정해야 합니다(이미 기본값으로 설정). 이 매개 변수의 역할에 대해서는 추후 설명하겠습니다.
SecureFile 을 생성하고 있는 장소인 테이블스페이스는 ASSM(Automatic Segment Space Management)이 지원되어야 합니다. Oracle Database 11g의 경우, 테이블스페이스 생성의 기본 모드가 ASSM이기 때문에 이미 테이블스페이스에서 이 조건을 충족하고 있습니다. 그렇지 않은 경우에는 새로운 ASSM 테이블스페이스에서 SecureFile을 생성해야 합니다.
테이블이 생성되고 나면 일반적인 11g 이전 LOB (BasicFile)에서와 같은 방식으로 데이터를 로드할 수 있습니다. 애플리케이션을 변경할 필요가 없으며 몇 가지 특별 구문을 기억할 필요도 없습니다.

여기 이 테이블로 로드되는 소형 프로그램이 있습니다.

이 프로그램은contract.pdf 파일을 테이블의 100개 열에 100번 로드합니다. 여러분은 이미 contract.pdf 파일이 저장되어 있는 OS 디렉토리에 대해 SECFILE이라는 디렉토리 객체를 정의했을 것입니다. 여기 contract.pdf 파일이 /opt/oracle에 위치해 있는 예가 나와 있습니다.

일단 LOB가 SecureFile로서 저장되면 최적 연산을 위해 많은 기능을 사용할 수 있게 됩니다. 여기 매우 유용한 몇 가지 기능이 있습니다.

중복 제거

중복 제거는 데이터베이스 상주 BLOB와 달리 몇몇 하이엔드 파일 시스템에서 OS 파일의 이점을 실현한 이후 가장 널리 각광 받고 있다는 점에서 SecureFile에서 가장 인기 있는 기능임에 틀림없습니다. 각기 1개의 BLOB를 가진 5개의 레코드가 있는 테이블이 있다고 해봅시다. BLOB 가운데 3개는 동일합니다. 단 한번 BLOB를 저장하고 다른 2개의 레코드 상의 해당 복사본에 대한 참조만을 저장할 수 있다면 공간 사용을 대폭 줄일 수 있을 것입니다. OS 파일에서는 이것이 가능하지만 Oracle Database 10g LOB에서는 불가능했을 것입니다. 하지만, SecureFile에서는 중복 제거라는 속성을 통해 손쉽게 공간을 절약할 수 있습니다. 테이블 생성 시 이를 지정하거나 다음과 같이 나중에 이를 수정ww.dbguide.net/images/oracle11g_guide/selobgui080226_5.gif" alt="" width=238 height=102>

중복 제거 이후 데이터베이스는 각 행의 열 값에 대한 해시(hash) 값을 계산해서 다른 값과 비교합니다. 일치하는 해시 값은 저장되고 그렇지 않은 경우에는 실제 BLOB가 저장됩니다. 새로운 레코드가 삽입되면 해시 값이 계산되고, 다른 값과 일치하는 경우에는 해당 해시 값이 삽입이 되고 그렇지 않은 경우에는 실제 값이 저장됩니다.

지금부터는 중복 제거 이후의 공간 절약 이점에 대해 알아 보겠습니다. DBMS_SPACE 패키지를 통해 LOB 세그간 사용을 나타내는 프로그램이 나와 있습니다.

이 스크립트는 LOB에 대한 다양한 공간 관련 통계값을 보여줍니다. 중복 제거 프로세스 전의 출력은 다음과 같습니다.

위 출력에서 오직 1개의 메트릭 값만 보고도 충분히 변화를 알 수 있습니다. 즉, used_bytes는 LOB 열에 저장된 정확한 바이트를 보여줍니다. 중복 제거 전에는 4,923,392 바이트(약 5MB)였던 공간 사용이 중복 제거 이후에는 원래 값의 약 1%인 57,344 바이트(약 57KB)로 줄었습니다. 중복 제거 프로세스에서는 행들이 동일 값을 가지고 100번 반복되고(모든 행에 대한 LOB 열에 동일 값을 입력한다는 점에 유의) 오직 1개의 행만이 유지되며 다른 행들은 포인터가 되었기 때문에 이것이 가능했습니다.
중복 제거 프로세스를 역방향으로 실행할 수 있습니다.

USED_BYTES는 원래 값인 5MB에 육박했다는 점에 유의하십시오.

압축

SecureFile의 또 다른 특징은 바로 압축입니다. 아래의 SQL을 사용해 LOB에 저장된 값을 압축할 수 있습니다.

이제, used_bytes 메트릭 값이 5MB 보다 훨씬 낮은 1,646,592(약 1.5 MB)가 되었다는 점에 주목하십시오.
압 축은 중복 제거와 다릅니다. 압축은 행 내부의 LOB 열에서 수행되며, 각각의 LOB 열은 독립적으로 압축됩니다. 중복 제거에서는 모든 행을 검사해서 열의 중복 값들을 제거하고 이들을 포인터로 교체합니다. 2개의 서로 다른 행을 가지고 있는 경우, 중복 제거는 크기를 줄이지 않지만 압축은 LOB 값 내부의 공간을 최적화 하게 됩니다. 테이블을 압축하는 것은 물론 중복 제거를 할 수 있습니다.

압축은 CPU 사이클을 사용하기 때문에 압축이 가능한 데이터 크기에 따라 압축이 아무런 소용이 없을 수도 있습니다. 예를 들어 JPEG 사진을 많이 가지고 있는 경우 이들은 이미 압축이 되었기 때문에 추가 압축으로 공간이 절약되지 않습니다. 한편, CLOB로서 XML 문서를 가지고 있는 경우에는 압축을 통해 상당한 공간을 절약할 수 있습니다. SecureFile 압축은 데이터의 압축 가능 여부를 자동 탐지해서 압축의 이점이 있을 경우에만 CPU 사이클을 실행합니다.

압축된 SecureFile LOB에 Oracle Text 인덱스를 설치할 수 있습니다. 파일 시스템의 압축 파일과 달리, 이는 Oracle Database 내부의 비정형 데이터를 저장할 수 있다는 중요한 이점이 있습니다.

또한, LOB 압축은 테이블 압축과 독립적이라는 점에 유의하십시오. CONTRACTS_SEC 테이블을 압축해도 LOB가 압축되지 않습니다. LOB 압축은 위의 SQL을 발행하는 경우에만 수행됩니다.

암호화

열에서와 마찬가지로 SecureFile에서 Transparent Database Encryption을 사용할 수 있습니다. 여기 AES 128비트 암호화를 통니다.

암호화를 지원하려면 먼저 암호화 월렛(wallet)을 설정해야 합니다 (암호화 월렛에 대한 자세한 설명은 본 Oracle Magazine 기사를 참조) 여기 필요한 단계가 요약되어 있습니다.

1.월렛 위치를 지정하도록 미리 설정이 되어 있지 않은 경우에는 sqlnet.ora에서 매개 변수를 설정:

2.월렛 생성:

이 단계를통해 mypass 암호를 가진 월렛을 생성하고 이를 열 수 있습니다.

3.위 단계들은 단 한번만 수행하면 됩니다. 월렛을 생성해서 이를 열면 데이터베이스가 작동하는 동안에는 계속 열린 상태가 유지됩니다(명시적으로 종료하지 않는 한). 데이터베이스가 재시작된 경우에는 아래와 같이 월렛을 열어야 합니다.

SecureFile LOB 열이 암호화되면 해당 테이블의 모든 행의 열 값들이 암호화됩니다. 암호화 이후에는 테이블에서 기존의 익스포트/임포트를 사용할 수 없으며, 대신 데이터 펌프(Data Pump)를 사용해야 합니다.
dba_encrypted_columns 뷰를 통해 어떤 열이 어떻게 암호화 되었는지 확인할 수 있습니다

캐싱

데이터베이스 상주 객체 대신 OS 파일로 비정형 데이터를 저장할 경우 얻을 수 있는 이점 가운데 하나는 캐싱 기능입니다. 파일은 운영 체제의 파일 버퍼에서 캐싱이 가능합니다. 데이터베이스 상주 객체 역시 데이터베이스 버퍼 캐시에 캐싱될 수 있습니다. 하지만, 캐싱이 실질적으로 성능에 걸림돌이 되는 경우도 있습니다. LOB는 일반적으로 크기가 큰 대형 객체이기 때문에 이것이 버퍼 캐시로 갈 경우에는 들어오는 LOB를 위한 공간을 확보하기 위해 다른 데이터 블록 대부분이 캐시 밖으로 밀려날 수 밖에 없습니다. LOB는 이후 사용되는 일은 없겠지만, 버퍼 캐시 입력으로 인해 필요한 블록들이 쏟아져 나오게 됩니다. 따라서, 대부분의 경우 사용자들은 LOB에서 캐싱 기능을 비활성화 하고 싶어할 것입니 예에서는 캐싱 비활성화를 위해 nocache 절을 사용했습니다. LOB에서의 캐싱 활성화를 위해 테이블을 변경할 수 있습니다.

이렇게 하면 LOB 캐싱이 활성화 됩니다. 단, LOB에만 해당되는 캐싱이라는 사실에 유의하십시오. 테이블의 나머지 부분은 버퍼 캐시로 들어가서 테이블 상의 LOB 캐싱 설정에 관계 없이 다른 테이블과 동일한 로직을 따릅니다.
캐 싱의 이점은 애플리케이션에 따라 크게 좌우됩니다. 썸네일 이미지를 조작하는 애플리케이션에서는 캐싱을 통해 성능을 향상할 수 있습니다. 하지만, 대용량 문서나 이미지의 경우에는 캐싱을 비활성화 하는 것이 더 좋습니다. SecureFile의 경우 사용자가 제어권을 가지게 됩니다.

로깅

로깅 절은 LOB에서의 데이터 변경이 리두(redo) 로그 스트림에 기록되는 방법을 결정합니다. 다른 데이터의 경우와 마찬가지로 전체 로깅(full logging)으로 기본 설정되어 있지만, LOB의 데이터는 대부분 대용량이기 때문에 로깅 기능을 제거하고 싶은 경우가 있을 수 있습니다. 이를 위해서는 위의 예에서 사용된 NOLOGING 절을 사용하면 됩니다.

아래에서 알 수 있듯이 SecureFile은 filesystem_like_logging 절에 또 다른 값을 제공합니다.

굵은 글씨체로 된 라인은 LOB의 메타 데이터를 전체 LOB가 아닌 리두 로그로 로깅한다는 사실에 유의하십시오. 이는 파일 시스템에서와 비슷합니다. 파일 메타 데이터는 파일 시스템 저널에 로깅됩니다. 마찬가지로, SecureFile의 이 절은 시스템 다운 이후의 신속한 복구를 지원합니다.

관리

DBA_LOB 데이터 딕셔너리 뷰는 SecureFile을 포함한 데이터베이스의 LOB 속성을 보여줍니다. 여기 뷰의 열이 나와 있습니다.

분할된 테이블의 경우, LOB 정보는 DBA_LOB_PARTITIONS 뷰에 저장됩니다.

LOB를 SecureFile로 마이그레이션

지금까지 SecureFile의 유용성에 대해 살펴봤기 때문에 이제 여러분은 기존 테이블을 변환하기를 원할 것입니다. 가장 손쉬운 방법은 새로운 테이블을 생성해 기존 테이블에서 데이터를 로드한 다음 이름을 변경하는 것입니다 (물론, 이를 위해서는 연산이 수행되는 동안 테이블을 사용 불가 상태로 만들어야 함). 다른 방법은 dbms_redefinition 패키지를 사용해 테이블을 온라인에서 재정의하는 것으로, 가용성에 영향을 미치지 않습니다.

예를 통해 그 방법에 대해 살펴 보도록 하겠습니다. SecureFile로 저장하고자 하는 원래 테이블 CONTRACTS_BASIC을 마이그레이션 하고 싶다고 가정해 봅시다. 아래 단계를 거쳐 마이그레이션을 수행할 수 있습니다.

1.기본 키(primary key)를 가지고 있는지 확인하십시오. 기본 키가 없는 경우에는 이를 생성하십시오.

2.새로운 테이블을 구축하십시오.

3.열들을 새로운 테이블에 매핑하십시오.

4.재정의 프로세스를 시작하십시오.

이제, CONTRACTS_BASIC에서 CONTRACTS_NEW로 모든 행이 복사될 것입니다. 테이블의 행 수에 따라 장시간이 소요될 수 있습니다.

5.재정의 프로세스를 끝내십시오.

6.테이블이 변환되었는지 확인하십시오.

열에 YES가 나타났다는 것은 열이 SecureFile로 변환되었다는 뜻입니다.

7.중간 테이블인 CONTRACTS_NEW를 삭제하십시오.

보다 신속하게 복사 프로세스를 수행하기 위해 먼저 병렬 DML 지원을 시도할 수 있습니다. 여기 세션에서 병렬 DML을 지원할 수 있는 방법이 나와 있습니다.

초기화 매개 변수

초기화 매개 변수 db_securefile은 데이터베이스에서의 SecureFile 사용을 결정합니다. 여기 다양한 매개 변수 값과 그 효과가 나와 있습니다.

결론

SecureFile은 단순한 차세대 LOB가 아니며, 특히 지금까지 파일 시스템 도메인에서만 지원되었던 기능에 훨씬 많은 부가가치를 제공합니다. SecureFile은 보안을 위한 암호화와 보다 효율적인 저장을 위한 중복 제거 및 압축이 가능할 뿐만 아니라, 신속한 액세스나 버퍼 풀 공간 절약을 위해 캐싱을 수행하고 시스템 다운 이후의 신속한 복구를 위해 여러 수준에서 로깅을 수행할 수 있습니다. SecureFile을 도입함으로써 과도한 오버헤드 발생이나 OS 파일 시스템이 제공하는 중요 기능의 손실을 경험하지 않고도 데이터베이스에 보다 많은 비정형 문서를 저