2009년 1월 26일 월요일

NCHAR and NVARCHAR2 Datatypes

NCHAR and NVARCHAR2 Datatypes

NCHAR and NVARCHAR2 are Unicode datatypes that store Unicode character data. The character set of NCHAR and NVARCHAR2 datatypes can only be either AL16UTF16 or UTF8 and is specified at database creation time as the national character set. AL16UTF16 and UTF8 are both Unicode encoding.

  • The NCHAR datatype stores fixed-length character strings that correspond to the national character set.
  • The NVARCHAR2 datatype stores variable length character strings.

When you create a table with an NCHAR or NVARCHAR2 column, the maximum size specified is always in character length semantics. Character length semantics is the default and only length semantics for NCHAR or NVARCHAR2.

For example, if national character set is UTF8, then the following statement defines the maximum byte length of 90 bytes:

CREATE TABLE tab1 (col1 NCHAR(30));

This statement creates a column with maximum character length of 30. The maximum byte length is the multiple of the maximum character length and the maximum number of bytes in each character.

This section includes the following topics:

NCHAR

The maximum length of an NCHAR column is 2000 bytes. It can hold up to 2000 characters. The actual data is subject to the maximum byte limit of 2000. The two size constraints must be satisfied simultaneously at run time.

NVARCHAR2

The maximum length of an NVARCHAR2 column is 4000 bytes. It can hold up to 4000 characters. The actual data is subject to the maximum byte limit of 4000. The two size constraints must be satisfied simultaneously at run time.





다국어 저장을 위한 데이터베이스 구축

more..

참고자료 : http://www.oracle.com/technology/obe/obe9ir2/obe-nls/nchar/nchar.htm 
작성자: 시간: 댓글 없음:
라벨: , , , ,

2009년 1월 25일 일요일

Stages in Processing a SQL Statement

사용자 삽입 이미지

 oracle 11g statement

그림에 대한 해석은 나중에 .. 해석하기 구찮아서 ㅡㅡ;

작성자: 시간: 댓글 없음:
라벨: ,

2009년 1월 23일 금요일

Log Writer Process (LGWR)

Log Writer Process 는 redo log buffer disk 에 write 하는 일을 가진다.
redo log buffer 는 원형 buffer 이다.

LGWR은 redo log buffer의 내용을 redo log file로 내려 쓰는 기능을 한다
DBWR은 데이터를 디스크에 저장하는 역할을 하지만, 데이터베이스에 COMMIT이 발생할 때마다 저장되는 것이 아니기 때문에 데이터를 손실할 수도 있다. DBWR과 달리 LGWR은 COMMIT이 발생하면, LGWR이 redo log file에 기록하기 때문에 손실을 최소화 할 수 있다.

다시 말해서, 사용자가 임의의 트랜젝션(transaction)에 대하여 커밋(commit)을 수행하고 나면 LGWR가 그 시점에서의 리두 로그 버퍼에 저장되어 있는 모든 리두 로그 기록들을 리두 로그 파일로 내려쓰게 된다.

LGWR은 다음과 같은 경우에 redo log file에 기록한다 

  • COMMIT 발생시
  • redo log buffer가 1/3 이상 찼을 때
  • redo log buffer에 쓰여진 양이 1MB가 되었을 때
  • Checkpoint 발생하여 DBWR가 쓰기 작업을 하기전에 
  • 이전에 기록된 시점에서 3초가 지났을 때
http://radiocom.kunsan.ac.kr/lecture/oracle/what_is/LGWR.html 


What Is the Redo Log?

The most crucial structure for recovery operations is the redo log, which consists of two or more preallocated files that store all changes made to the database as they occur. Every instance of an Oracle Database has an associated redo log to protect the database in case of an instance failure.

Redo Threads

When speaking in the context of multiple database instances, the redo log for each database instance is also referred to as a redo thread. In typical configurations, only one database instance accesses an Oracle Database, so only one thread is present. In an Oracle Real Application Clusters environment, however, two or more instances concurrently access a single database and each instance has its own thread of redo. A separate redo thread for each instance avoids contention for a single set of redo log files, thereby eliminating a potential performance bottleneck.

This chapter describes how to configure and manage the redo log on a standard single-instance Oracle Database. The thread number can be assumed to be 1 in all discussions and examples of statements. For information about redo log groups in an Oracle Real Application Clusters environment, please refer to Oracle Real Application Clusters Administration and Deployment Guide.

Redo Log Contents

Redo log files are filled with redo records. A redo record, also called a redo entry, is made up of a group of change vectors, each of which is a description of a change made to a single block in the database. For example, if you change a salary value in an employee table, you generate a redo record containing change vectors that describe changes to the data segment block for the table, the undo segment data block, and the transaction table of the undo segments.

Redo entries record data that you can use to reconstruct all changes made to the database, including the undo segments. Therefore, the redo log also protects rollback data. When you recover the database using redo data, the database reads the change vectors in the redo records and applies the changes to the relevant blocks.

Redo records are buffered in a circular fashion in the redo log buffer of the SGA (see "How Oracle Database Writes to the Redo Log") and are written to one of the redo log files by the Log Writer (LGWR) database background process. Whenever a transaction is committed, LGWR writes the transaction redo records from the redo log buffer of the SGA to a redo log file, and assigns a system change number (SCN) to identify the redo records for each committed transaction. Only when all redo records associated with a given transaction are safely on disk in the online logs is the user process notified that the transaction has been committed.

Redo records can also be written to a redo log file before the corresponding transaction is committed. If the redo log buffer fills, or another transaction commits, LGWR flushes all of the redo log entries in the redo log buffer to a redo log file, even though some redo records may not be committed. If necessary, the database can roll back these changes.

How Oracle Database Writes to the Redo Log

The redo log of a database consists of two or more redo log files. The database requires a minimum of two files to guarantee that one is always available for writing while the other is being archived (if the database is in ARCHIVELOG mode). See "Managing Archived Redo Logs" for more information.

LGWR writes to redo log files in a circular fashion. When the current redo log file fills, LGWR begins writing to the next available redo log file. When the last available redo log file is filled, LGWR returns to the first redo log file and writes to it, starting the cycle again. Figure 10-1 illustrates the circular writing of the redo log file. The numbers next to each line indicate the sequence in which LGWR writes to each redo log file.

Filled redo log files are available to LGWR for reuse depending on whether archiving is enabled.

  • If archiving is disabled (the database is in NOARCHIVELOG mode), a filled redo log file is available after the changes recorded in it have been written to the datafiles.

  • If archiving is enabled (the database is in ARCHIVELOG mode), a filled redo log file is available to LGWR after the changes recorded in it have been written to the datafiles and the file has been archived.

Figure 10-1 Reuse of Redo Log Files by LGWR

Description of Figure 10-1 follows
Description of "Figure 10-1 Reuse of Redo Log Files by LGWR"

Active (Current) and Inactive Redo Log Files

Oracle Database uses only one redo log files at a time to store redo records written from the redo log buffer. The redo log file that LGWR is actively writing to is called the current redo log file.

Redo log files that are required for instance recovery are called active redo log files. Redo log files that are no longer required for instance recovery are called inactive redo log files.

If you have enabled archiving (the database is in ARCHIVELOG mode), then the database cannot reuse or overwrite an active online log file until one of the archiver background processes (ARCn) has archived its contents. If archiving is disabled (the database is in NOARCHIVELOG mode), then when the last redo log file is full, LGWR continues by overwriting the first available active file.

Log Switches and Log Sequence Numbers

A log switch is the point at which the database stops writing to one redo log file and begins writing to another. Normally, a log switch occurs when the current redo log file is completely filled and writing must continue to the next redo log file. However, you can configure log switches to occur at regular intervals, regardless of whether the current redo log file is completely filled. You can also force log switches manually.

Oracle Database assigns each redo log file a new log sequence number every time a log switch occurs and LGWR begins writing to it. When the database archives redo log files, the archived log retains its log sequence number. A redo log file that is cycled back for use is given the next available log sequence number.

Each online or archived redo log file is uniquely identified by its log sequence number. During crash, instance, or media recovery, the database properly applies redo log files in ascending order by using the log sequence number of the necessary archived and redo log files.


http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/onlineredo001.htm#ADMIN11305 
작성자: 시간: 댓글 없음:
라벨: , , ,

2009년 1월 22일 목요일

Database Buffer Cache

Database Buffer Cache 는 SGA 의 일부분이며, datafile 에서 읽은 data blocks 들의 copy 를 가지고 있다.

Database Buffer Cache 는 크게 두가지의 이슈를 지닌다.

 1. Organization of Database Buffer Cache
 2. LRU 알고리즘 과 Full Table Scans


 1. Organization of Database Buffer Cache
cache 안의 버퍼들은 두가지 종류로 나뉘어진다.

1) write list
2) least recently used (LRU) 최근에 사용된 list

write list 는 수정되었지만 아직 disk 에 쓰여지지 않은 dirty buffers 를 가지고 있고
LRU list 는 free buffers 와 pinned buffers 그리고 disk 에 쓰여지지 않은 수정된 버퍼인
dirty buffers 를 가지고 있다.

free buffers 는 어떠한 사용가능한 데이터를 가지고 있지 않고, 사용될수 있는 공간이다.
pinned buffers 는 현재 접근중인 ( 변경중인 ) 버퍼이다.

Oracle Database process 가 buffer 에 access 할시 process 는 buffer 를 MRU 로 이동시키고,
dirty buffer 는 시간이 지날수록 LRU list 의 끝으로 가게 된다.

첫번째로 Oracle user process 는 Database buffer cache 에서 찾고자 하는 데이터를 찾는다.
만약 데이터가 cache에 있다면 (cache hit) 메모리에서 데이터를 바로 읽어 들인다.
하지만 데이터가 cache에 없다면 (cache miss) , disk 에서 data block을 메모리로 copy 해야한다.

data block 을 cache 에서 read 하기전에 process 는 free buffer 를 찾게 된다.
process 는 LRU list 에서 free buffer 를 찾게 되는데, LRU 부분에서 부터 검색을 시작한다.
process 는 free buffer 또는 buffer 의 한계가 검색 되었을때 둘다 검색을 하게 되는데,
검색시 dirty buffer 를 LRU list 에서 찾게 된다면, dirty buffer 는 disk 에 write 하고 검색을 재개한다.

process 가 free buffer 를 찾으면, disk 에서 data block 을 메모리로 올려 free buffer 에 copy 하고,
MRU로 이동 시킨다.

만일 process가 buffer 가 꽉찾다고 감지하게 된다면 free buffer 검색을 중단하고, DBWn 에 의하여
dirty buffer 를 disk 로 write 한다.

 2. LRU 알고리즘 과 Full Table Scans

user process 가 full table scan 을 하게 된다면, disk 에서 data block을 읽여들여
MRU 대신에 LRU 리스트의 끝으로 이동하게 된다.
그 이유는 full table scan 시 오랬동안 사용되는 경우가 드물기 때문에 (오직 적은 용도로만 사용)
되도록이면 빨리 cache 에서 out 되야 하기 때문이다.

oracle 에서는 직접 full table scan 시에 cache 에서 취할 다른 행동을 정의할수 있다. (cache hint)


CACHE Hint

 CACHE hint는 full table scan이 수행됐을 때 hint에 있는 테이블에 대해 retrieve된 블록들은 버퍼 캐시에 있는 LRU list의 가장최근(most recently)에 사용되어진 것의 끝에 위치

이 option은 small lookup table에 유용하다. CACHE hint는 테이블의 default caching specification을 무시

SELECT/*+ FULL (scoot_emp) CACHE(scott_emp) */ ename
FROM scott.emp scott_emp;

NOCACHE

 NOCACHE hint는 full table scan이 수행됐을 때 hint에 있는 테이블에 대해 retrieve된 블록들은 버퍼 캐시에 있는 LRU list의 가장 오래전(least recently)에 사용되어진 것의 끝에 위치

버퍼캐수에 blocks의 일반적인 행동

SELECT/*+ FULL (scoot_emp) NOCACHE(scott_emp) */ ename
FROM scott.emp scott_emp;

cache 참조 문서

more..

작성자: 시간: 댓글 없음:
라벨: , , , ,

ORACLE Transparent Data Encryption [TDE] Reference

먼저 TDE 를 사용하기에 앞서 다음과 같은 이슈가 필요하다.

 1.  Transparent Data Encryption 의 Enabling
 2. 암호화 키를 엑세스 하기위한 Encypted Wallet Open
 3. Master Key 설정 과 재생성
 4. 암호화 컬럼을 포함한 테이블 생성
 5. 암호화 컬럼이 존재하는 테이블에 대한 설정
 6. 암호화 컬럼에 대한 인덱스 사용
 7. 암호화 컬럼에 대한 salt 사용 또는 제거



++ 마스터키 생성 ++

ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY password  // master key create


++ 마스터키 로드 ++

ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY password 

// 마스터 키를 메모리에 로딩한다 이키는 shutdown 되기전까지는 메모리에 상주한다.

++ 마스터키 Close ++

ALTER SYSTEM SET WALLET CLOSE

// 암호화된 컬럼을 Disable 시킨다.

oracle wallert 안에있는 외부 보안 모듈 암호키는 기본적으로 sqlnet.ora 파일에 명시되어있다.
만약 어떤 위치도 지정이 되지 않았다면 오라클은 default 위치를 참조하여 사용한다.

데이터베이스 컬럼을 암호화 하기전에는 반드시 마스터키를 생성하여야 한다.
ENCRYPT cluse 를 포함한 SQL 쿼리를 날렸을때 마스터키에의해 암호화된 암호키가 생성된다.

ALTER SYSTEM SET ENCRYPTION KEY certificate_id IDENTIFIED BY password


certficate_id 는 optional 한 String 값(unique) 을 가지며 보안 모듈에 저장된다.  
V$WALLET 을 이용하여 open 된 certficate_id 를 찾을수있다 .
password는 보안모듈의 패스워드를 설정하며, 만드시 설정해줘야 한다.
password 는 case sensitive 하며, double quotation marks 를 포함한다.

++ 마스터키 재생생 ++

    너무 빈번한 마스터키 재생성은 시스템 보안 향상에 도움이 되지 않는다.
    보안모듈은 큰용량을 저장할수 있지만 무한하지는 않는다.
    빈번한 마스터키 재생성은 사용가능한 스토리지용량을 고갈시킬 우려가 있다.

    ALTER SYSTEM SET ENCRYPTION KEY "j231m781098dhb345dm" IDENTIFIED BY "p3812dG9E";


++ 암호화된 컬럼에 salt 추가 ++

    salt는 암호화된 데이터의 강력한 방법중 하나이다.
    salt는 암호화되기전에 임의의 string 을 데이터에 add 한다.

    ALTER TABLE employee MODIFY  (first_name ENCRYPT SALT);


++ salt 삭제 ++

    ALTER TABLE employee MODIFY (first_name ENCRYPT NO SALT);


++ 암호화된 컬럼을 포함한 테이블의 생성 ++

    테이블을 생성할때는  3가지의 옵션을가진다.

        1. default Algorithm 을 사용하는 암호화된 컬럼의 생성
        2. NON-default Algorithm 을 사용하는 암호화된 컬럼의 생성
        3. 암호화된 컬럼을 External 테이블에 생성

        ** default Algorithm 은 AES192 를 사용한다.

1. default Algorithm 을 사용하는 암호화된 컬럼의 생성
   
    CREATE TABLE employee (
        first_name VARCHAR2(128),
        last_name VARCHAR2(128),
        empID NUMBER,
        salary NUMBER(6) ENCRYPT
        );


2. NON-default Algorithm 을 사용하는 암호화된 컬럼의 생성   

    CREATE TABLE employee (
        first_name VARCHAR2(128),
        last_name VARCHAR2(128),
        empID NUMBER ENCRYPT NO SALT,
        salary NUMBER(6) ENCRYPT USING '3DES168'
        );


3. 암호화된 컬럼을 External 테이블에 생성
    생략

++ 존재하는 테이블에 대한 암호화 ++

    존재하는 테이블에 암호화된 컬럼 추가는 3가지의 옵션은 가진다.

        1. 존재하는 테이블에 암호화된 컬럼을 add

            ALTER TABLE employee ADD (ssn VARCHAR2(11) ENCRYPT);

        2. 존재하는 컬럼에 대한 암호화

            ALTER TABLE employee MODIFY (first_name ENCRYPT);

        3. 암호화된 컬럼에 대하여 Disabling

            ALTER TABLE employee MODIFY (first_name DECRYPT);


   
++ 암호화된 컬럼에 대한 인덱스 생성 ++

    암호화된 컬럼에 대하여 인덱스를 생성하기 위해서는 CREATE INDEX 문을 사용하여야 한다.
    암호화된 컬럼에 인덱스를 생성할경우 반드시 NO SALT 로 지정해야한다.

    CREATE INDEX employee_idx on employee (empID);


++ 암호화키 알고리즘의 변경 ++

    ALTER TABLE employee REKEY;
    ALTER TABLE employee REKEY USING '3DES168';


++ 지원되는 알고리즘의 종류 ++

    Triple DES
    AES128 
     AES192 // default
    AES256


++ 암호화 가능한 DATA TYPE ++

   
   CHAR
    DATE
    INTERVAL DAY TO SECOND
    INTERVAL YEAR TO MONTH
    NCHAR
    NUMBER
    NVARCHAR2
    RAW
    TIMESTAMP
    VARCHAR2


++ Data Dictionary Views ++

    DBA_ENCRYPTED_COLUMNS
    ALL_ENCRYPTED_COLUMNS
    USER_ENCRYPTED_COLUMNS


작성자: 시간: 댓글 없음:
라벨: , , ,

2009년 1월 21일 수요일

ORACLE Transparent Data Encryption Algorithms [TDE]

1.2.1.1 Supported Encryption Algorithms

Oracle Advanced Security provides the following encryption algorithms to protect the privacy of network data transmissions:


1.2.1.1.1 RC4 Encryption:

The RC4 encryption module uses the RSA Security, Inc., RC4 encryption algorithm. Using a secret, randomly-generated key unique to each session, all network traffic is fully safeguarded including all data values, SQL statements, and stored procedure calls and results. The client, server, or both, can request or require the use of the encryption module to guarantee that data is protected. Oracle's optimized implementation provides a high degree of security for a minimal performance penalty. For the RC4 algorithm, Oracle provides encryption key lengths of 40-bits, 56-bits, 128-bits, and 256-bits.

1.2.1.1.2 DES Encryption :

Oracle Advanced Security implements the U.S. Data Encryption Standard algorithm (DES) with a standard, optimized 56-bit key encryption algorithm and also provides DES40, a 40-bit version, for backward compatibility.

1.2.1.1.3 Triple-DES Encryption :

Oracle Advanced Security also supports Triple-DES encryption (3DES), which encrypts message data with three passes of the DES algorithm. 3DES provides a high degree of message security, but with a performance penalty. The magnitude of penalty depends on the speed of the processor performing the encryption. 3DES typically takes three times as long to encrypt a data block as compared with the standard DES algorithm.

3DES is available in two-key and three-key versions, with effective key lengths of 112-bits and 168-bits, respectively. Both versions operate in outer Cipher Block Chaining (CBC) mode.

1.2.1.1.4 Advanced Encryption Standard:

Approved by the National Institute of Standards and Technology (NIST) in Federal Information Processing Standards (FIPS) Publication 197, Advanced Encryption Standard (AES) is a new cryptographic algorithm standard developed to replace DES. AES is a symmetric block cipher that can process data blocks of 128 bits, using cipher keys with lengths of 128, 192, and 256 bits, which are referred to as AES-128, AES-192, and AES-256, respectively. All three versions operate in outer-CBC mode.


http://download.oracle.com/docs/cd/B19306_01/network.102/b14268/asotrans.htm#sthref205

tde.pdf

작성자: 시간: 댓글 없음:
라벨: , , ,

oracle salt

salt

1. In cryptography, generally speaking, "salt" is a way to strengthen the security of encrypted data. Salt is a random string that is added to the data before it is encrypted. Then, it is more difficult for attackers to steal the data by matching patterns of ciphertext to known ciphertext samples. 2. Salt is also used to avoid dictionary attacks, a method that unethical hackers (attackers) use to steal passwords. It is added to passwords before the passwords are encrypted. Then it is difficult for attackers to match the hash value of encrypted passwords (sometimes called verifiers) with their dictionary lists of common password hash values. See dictionary attack


Example 3-6 Creating a New Table with an Encrypted Column Using 3DES168 and NO SALT

CREATE TABLE employee (
     first_name VARCHAR2(128),
     last_name VARCHAR2(128),
     empID NUMBER ENCRYPT NO SALT,
     salary NUMBER(6) ENCRYPT USING '3DES168'
);
작성자: 시간: 댓글 없음:
라벨: , ,

ORACLE Transparent Data Encryption [TDE] Overview

Transparent Data Encryption

사 용자들은 암호화의 효용성에 대해 엇갈린 반응을 보이곤 합니다. 암호화는 필요한 기술이지만, 키 관리의 복잡성으로 인해 올바르게 설정되지 않은 경우 효율적이지 못한 결과를 초래할 수도 있습니다. 또 대부분의 애플리케이션 설계자들은 키 값의 암호화 및 해독 과정에서 수반되는 성능 오버헤드를 우려합니다. 이러한 이유로 암호화를 적용하지 않는 대신 패스워드, 인증 메커니즘 등의 변경 보안(perimeter protection)을 강화하는 쪽을 선택하는 경우가 많습니다.

하지만, 서버(또는 디스크)를 통째로 훔쳐, 동일한 운영체제에 서버를 마운트하고 데이터에 접근하는 경우를 가정해 볼 수 있습니다. 또는 내부사용자가 업무 수행 과정에서 DBA의 권한으로 데이터베이스에 접근하여 중요한 정보를 빼내는 경우를 생각해 볼 수 있습니다. 미 캘리포니아주에서는, 이와 같은 상황이 발생한 경우, 영향 범위에 있는 모든 고객들에게 보안 침해 사실을 통보하도록 법적으로 규정하고 있습니다 (다른 주에서도 이와 유사한 법안이 발의될 예정입니다).

(흔히 경험할 수 있는 것은 아니지만 결코 무시할 수 없는) 이러한 사고에서는, 인증 메커니즘이 아무런 효과를 갖지 못합니다. 보안이 각별히 중시되는 환경에서 TDE(transparent data encryption)이 중요한 기능으로 활용되고 있는 것도 바로 이 때문입니다. TDE는 복잡한 키 관리 업무를 데이터베이스 엔진 내부에서 수행하는 암호화 기술입니다. 또 DBA는 데이터베이스 테이블의 관리에 필요한 모든 권한을 갖지만, 반면 모든 데이터를 직접 조회할 수는 없도록 통제 가능합니다.

Oracle Database 10g Release 2의 TDE는, 특정 테이블의 하나 또는 그 이상의 컬럼을 쉽게 암호화할 수 있는 기능을 제공합니다. 관리자는 코드를 전혀 작성하지 않고도 컬럼을 암호화 대상으로 정의할 수 있습니다. 암호화는 기본적으로 입력 값을 암호화하기 위한 키(key)와 알고리즘을 필요로 합니다. TDE는 암호화를 위한 키를 자동으로 생성합니다. 이러한 방식은 키 관리를 단순화해 준다는 장점이 있지만 유출의 가능성이 더 높아진다는 단점도 뒤따릅니다. 이러한 문제를 보완하기 위해 또 다른 키(master key)가 데이터베이스 레벨에서 설정됩니다. 테이블 키는 마스터 키와 함께 암호화되며, 따라서 특정 컬럼을 해독하기 위해서는 테이블 키와 마스터 키가 함께 필요합니다. (암호화 기술 및 오라클의 암호화 패키지 구현방식에 대한 자세한 정보는 필자가 기고한 오라클 매거진 기사 ?"Encrypt Your Data Assets- 를 참고하시기 바랍니다.)

마스터 키는 “wallet”이라고 부르는 데이터베이스 외부의 별도 저장소에 저장됩니다. (wallet의 디폴트 위치는 “$ORACLE_BASE/admin/$ORACLE_SID/wallet”으로 정의됩니다.) 그 개념적인 구조가 아래 그림과 같습니다.
TDE가 설정되고 나면 (좀 더 정확히 말해 wallet과 마스터 키가 설정되고 나면), 이 설정을 이용하여 데이터를 보호할 수 있습니다. 테이블의 컬럼을 암호화하려면 아래와 같은 SQL 구문을 사용해야 합니다: 
create table accounts
(
   acc_no       number       not null,
   first_name   varchar2(30) not null,
   last_name    varchar2(30) not null,
   SSN          varchar2(9)             ENCRYPT USING 'AES128',
   acc_type     varchar2(1)  not null,
   folio_id     number                  ENCRYPT USING 'AES128',
   sub_acc_type varchar2(30),
   acc_open_dt  date         not null,
   acc_mod_dt   date,
   acc_mgr_id   number
)
위 구문에서는 SSN 컬럼과 FOLIO_ID 컬럼에 TDE를 적용하여 두 컬럼의 데이터를 암호화하였습니다. 하지만 사용자가 테이블을 조회하면, 데이터가 인출되는 과정에서 자동으로 해독 작업이 수행되기 때문에 데이터는 일반 텍스트의 형태로 보여지게 됩니다. 하지만 디스크가 도난 당한 경우에는, 테이블 세그먼트에 저장된 정보가 암호화된 상태로 유지되며, 이 값을 해독하기 위해서는 테이블 키가 무엇인지 알아야 합니다. 테이블 키를 얻으려면 마스터 키가 필요하지만, 이 키는 데이터베이스 외부에 존재하므로 해독이 불가능하게 됩니다.

SSN 컬럼과 FOLIO_ID 컬럼에 대한 정의에서 128-비트 AES(Advanced Encryption Standard)를 이용한 ENCRYPT 옵션이 적용되었음을 주목하시기 바랍니다.

데이터베이스의 wallet은 사전 설정되어 있습니다. 이 wallet의 암호를 설정하기 위해서는 아래와 같은 명령을 사용합니다: 
alter system set encryption key authenticated BY "topSecret";
이 명령은 기존에 wallet이 존재하지 않는 경우 wallet을 자동생성하고, 암호를 “topSecret”로 설정합니다 (암호는 대소문자를 구별합니다). 이와 같이 설정한 후 테이블의 생성/수정 과정에서 컬럼 별로 암호화 여부를 결정할 수 있습니다.
External Table의 암호화
위 예에서는, 컬럼의 암호화를 위해 해시 테이블(hash table)을 사용했습니다. External table에 대해 TDE를 적용하는 것 또한 가능합니다. 예를 들어 ACCOUNTS 테이블의 데이터를 다른 위치에 덤프하고자 하는 경우, 다음과 같은 간단한 ENCRYPT 구문을 적용하면 됩니다.
create table account_ext
organization external
(
   type oracle_datapump
   default directory dump_dir
   location ('accounts_1_ext.dmp',
             'accounts_2_ext.dmp',
             'accounts_3_ext.dmp',
             'accounts_4_ext.dmp')
)
parallel 4
as
select 
ACC_NO,
FIRST_NAME,
LAST_NAME,
SSN           ENCRYPT IDENTIFIED BY "topSecret",
ACC_TYPE,
FOLIO_ID      ENCRYPT IDENTIFIED BY "topSecret",
SUB_ACC_TYPE,
ACC_OPEN_DT,
ACC_MOD_DT
from accounts;
accounts_*_ext.dmp 파일의 SSN 컬럼 및 FOLIO_ID 컬럼은 암호화된 형태로 저장됩니다. 이 파일을 external table로 활용하고자 하는 경우, 파일을 읽기 위한 패스워드(topSecret)를 제시해야 합니다.

지금까지 설명한 것처럼 TDE는 매우 유용한 액세스 컨트롤 메커니즘으로 활용이 가능합니다.

http://iclickyou.com/1353

- 참고자료 -

http://www.oracle.com/technology/global/kr/products/database/oracle11g/pdf/advanced-security-11g-datasheet_kor.pdf



Overview of Transparent Data Encryption The Oracle database provides security in the form of authentication, authorization, and auditing. Authentication ensures that only legitimate users gain access to the system. Authorization ensures that those users only have access to resources they are permitted to access. Auditing ensures accountability when users access protected resources. Although these security mechanisms effectively protect data in the database, they do not prevent access to the operating system files where the data is stored. Transparent data encryption enables encryption of sensitive data in database columns as it is stored in the operating system files. In addition, it provides for secure storage and management of encryption keys in a security module external to the database. Using an external security module separates ordinary program functions from those that pertain to security, such as encryption. Consequently, it is possible to divide administration duties between DBAs and security administrators, a strategy that enhances security because no administrator is granted comprehensive access to data. External security modules generate encryption keys, perform encryption and decryption, and securely store keys outside of the database. Transparent data encryption is a key-based access control system that enforces authorization by encrypting data with a key that is kept secret. There can be only one key for each database table that contains encrypted columns regardless of the number of encrypted columns in a given table. Each table's column encryption key is, in turn, encrypted with the database server's master key. No keys are stored in the database. Instead, they are stored in an Oracle wallet, which is part of the external security module. Before you can encrypt any database columns, you must generate or set a master key. This master key is used to encrypt the column encryption key which is generated automatically when you issue a SQL command with the ENCRYPT clause on a database column.

See Also: Oracle Database Advanced Security Administrator's Guide for details about using transparent data encryption
작성자: 시간: 댓글 없음:
라벨: , ,

2009년 1월 20일 화요일

2회 Mashup 경진대회 출품 (Flex 쇼핑몰)

http://softcream.kr/shop  으로 변경 되었습니다.

사용자 삽입 이미지


작성자: 시간: 댓글 2개:
라벨: , ,

OLTP [online transaction processing] / OLAP

OLTP [online transaction processing] 

네트워크상의 여러 이용자가 실시간으로 데이터베이스의 데이터를 갱신하거나 조회하는 등의 단위 작업을 처리하는 방식을 말한다. 주로 신용카드 조회 업무나 자동 현금 지급 등 금융 전산 관련 부문에서 많이 발생하기 때문에 ‘온라인 거래처리’라고도 한다. 이 방식의 특징은 기존 컴퓨터 통신에서 이용해 온 온라인 방식과 달리 다수의 이용자가 거의 동시에 이용할 수 있도록 송수신 자료를 트랜잭션(데이터 파일의 내용에 영향을 미치는 거래 ·입출고 ·저장 등의 단위 행위) 단위로 압축, 비어 있는 공간을 다른 사용자들이 함께 쓸 수 있도록 한 점이다.


주 컴퓨터와 통신 회선으로 접속되어 있는 복수의 사용자 단말에서 발생한 트랜잭션을 주 컴퓨터에서 처리하여 그 결과를 즉석에서 사용자 단말 측으로 되돌려 보내 주는 처리 형태. 트랜잭션이란, 단말에서 주 컴퓨터로 보내는 처리 단위 1회의 메시지로, 보통 여러 개의 데이터베이스 조작을 포함하는 하나의 논리 단위이다. 예를 들어, 데이터베이스 내의 어떤 표의 수치를 변경하는 경우, 그 표와 관련된 다른 표의 수치도 변경하지 않으면 데이터 무결성(data integrity)을 유지할 수 없다. 이런 경우에는 2개의 처리를 1개의 논리 단위로 연속해서 행해야 하는데, 이 논리 단위가 트랜잭션이다. 1개의 트랜잭션은 그 전체가 완전히 행해지든지, 아니면 전혀 행해지지 않든지 둘 중 하나여야 한다. 그 이유는 1개의 트랜잭션 처리 도중에 그 트랜잭션의 처리를 중지하면 데이터 무결성이 사라질 우려가 있기 때문이다. 이러한 온라인 트랜잭션 처리(OLTP)의 특성에 적합하게 개발된 컴퓨터가 내고장형 또는 무정지형 컴퓨터(FTC)이다. 그리고 이전에는 범용기 중심이던 OLTP 시스템을 유닉스에도 구축하게 되었는데, 유닉스용의 트랜잭션 처리(TP) 모니터가 여러 가지 개발되어 있어서 성능과 가용성을 높이고 있다. 최근에는 업계 표준인 분산 컴퓨팅 환경(DCE)에 대응하는 TP 모니터 제품이 많이 출현하여 유닉스 기계에 기간 업무의 OLTP 시스템을 구축하는 경향이 늘고 있다.


- OLTP와 OLAP의 비교 -


OLTP은 매일매일의 기업운영을 가능하게 하는 거래처리 시스템이고, OLAP은 다차원 분석에 의해서 기업이 나가야 할 방향을 설정할 수 있는 것이다. OLAP의 목적은 최종사용자가 기업의 전반적인 상황을 이해할 수 있게 하고 의사결정을 지원하는데 있다. OLTP와 OLAP의 비교항목을 요약하면 다음과 같다.

구분

OLTP

OLAP

데이터의 구조

복잡 (운영 시스템 계산에 적합)

단순(사업 분석에 적합)

데이터의 갱신

순간적/동적

주기적/정적

응답 시간

2, 3 초 ~ 몇 초 이내

수 초 ~ 몇 분까지도 가능

데이터의 범위

과거 30 일 ~ 90 일

과거 5 년 ~ 10 년

데이터 성격

정규/핵심 업무 데이터,
mission critical 데이터

비정규/read-only 데이터,index 에 의존

데이터의 크기

수 Giga Byte

수 Tera Byte

데이터의 내용

현재 데이터

기록 보관된, 요약/계산 데이터

데이터 특성

거래처리(transaction) 중심

주제(subject) 중심

데이터 액세스 빈도

높음

보통 혹은 낮음

데이터의 사용법

고도로 구조화된 연속 처리

고도로 비구조화 된 분석 처리

쿼리의 성격

예언 가능, 주기적

예측하기 어렵고, 특수하다 


[출처] OLTP와 OLAP의 비교|작성자 까치

작성자: 시간: 댓글 없음:
라벨: , , ,
피드 구독하기: 글 (Atom)