1. 매우 많은 양의 데이타를 빠른 시간 내에 load하고자하는 경우 direct path load를 사용할 수 있다.
   여기에서 이러한 direct path load의 자세한 개념 및 사용방법, 사용 시 고려해야 할 점 등을 설명한다.

• 일반적인 sql*loader를 이용한 방법은 존재하는 table에 datafile 내의 data를 SQL의 INSERT command를 이용하여 insert시킨다.
  이렇게 SQL command를 이용하기 때문에 각각의 데이타를 위한 insert command가 생성되어 parsing되는 과정이 필요하며,
  먼저 bind array buffer (data block buffer) 내에 insert되는 데이타를 입력시킨 후 이것을 disk에 write하게 된다.

1. load 중에 table을 index를 이용하여 access하여야 하는 경우
   direct load중에는 index가 direct load state가 되어 사용이 불가능하다.
2. load 중에 index를 사용하지 않고 table을 update나 insert등을 수행해야 하는 경우
   direct load 중에는 table에 exclusive write(X) lock을 건다.
3. SQL*NET을 통해 load를 수행해야 하는 경우
4. clustered table에 load하여야 하는 경우
5. index가 걸려 있는 큰 table에 적은 수의 데이타를 load하고자 할 때
6. referential이나 check integrity가 정의되어 있는 큰 table에 load하고자 할 때
7. data field에 SQL function을 사용하여 load하고자 할 때

• Direct Path Loads는 다음과 같은 특징들로 인하여 매우 많은 양의 데이타를 빠른 시간에 load하고자 할 때 이용하는 것이 바람직하다.

1. SQL INSERT 문장을 generate하여 수행하지 않는다.
2. memory 내의 bind array buffer를 이용하지 않고
   database block의 format과 같은 data block을 memory에 만들어 데이타를 넣은 후 그대로 disk에 write한다.
   memory 내의 block buffer와 disk의 block은 그 format이 다르다.
3. load 시작 시에 table에 lock을 걸고 load가 끝나면 release시킨다.
4. table의 HWM (High Water Mark) 윗 부분의 block에 data를 load한다.
   HWM는 table에 data가 insert됨에 따라 계속 늘어나고 truncate 외에는 줄어들게 하지 못한다.
   그러므로, 항상 완전히 빈 새로운 block을 할당받아 data를 입력시키게 된다.
5. instance failure가 발생하여도 redo log file을 필요로 하지 않는다.
6. UNDO information을 발생시키지 않는다.
   즉 rollback segment를 사용하지 않는다.
7. OS에서 asynchronous I/O가 가능하다면, 복수개의 buffer에 의해서 동시에 data를 읽어서
   buffer에 write하면서 buffer에서 disk로 write할 수 있다.
8. parallel option을 이용하면 더욱 성능을 향상시킬 수 있다.

1. direct path load를 사용하기 위한 view들은 다음 script에 포함어 있으며,
   미리 sys user로 수행되어야 한다. 단 이 script는 catalog.sql에 포함되어 있어,
   db 구성 시에 이미 수행되어진다.

    @$ORACLE_HOME/rdbms/admin/catldr.sql 

2. direct path load를 사용하기 위해서는 일반적인 sqlload 명령문에 DIRECT=TRUE를 포함시키기만 하면 된다.
   다음과 같이 기술하면 된다.

   sqlload username/password control=loadtest.ctl direct=true

3. 이 direct path load를 사용 시에 고려할 만한 추가적인 option 및 control file 내에 기술 가능한 clause들을 살펴본다.

• conventional path load에서 rows는 default가 64이며, rows에 지정된 갯수만큼의 row가 load되면 commit이 발생한다.
  이와 비슷하게 direct load path에서는 rows option을 이용하여 data save를 이루며,
  data save가 발생하면 data는 기존 table에 포함되어 입력된 data를 잃지 않게 된다.
• 단 이 때 direct path load는 모든 data가 load된 다음에야 index가 구성되므로
  data save가 발생하여도 index는 여전히 direct load state로 사용하지 못하게 된다.
• direct path load에서 이 rows의 default값은 unlimited이며,
  지정된 값이 database block을 채우지 못하면 block을 완전히 채우는 값으로 올림하여,
  partial block이 생성되지 않도록 한다.

• control file내에 column_spec datatype_spec PIECED 순으로 기술하는 것으로서 direct path load에만 유효하다.
  LONG type과 같이 하나의 data가 maximum buffer size보다 큰 경우 하나의 data를 여러번에 나누어 load하는 것이다.
  이 option은 table의 맨 마지막 field 하나에만 적용가능하며, index column인 경우에는 사용할 수 없다.
• 그리고 load도중 data에 문제가 있는 경우 현재 load되는 data의 잘린 부분만 bad file에 기록되게 된다.
  왜냐하면 이전 조각은 이미 datafile에 기록되어 buffer에는 남아있지 않기 때문이다.

• 만약 매우 큰 data가 마지막 field가 아니거나 index의 한 부분인 경우 PIECED option을 사용할 수 없다.
  이러한 경우 buffer size를 증가시켜야 하는데 이것은 readbuffers option을 이용하면 된다.
  default buffer갯수는 4개이며, 만약 data load중 ORA-2374(No more slots for read buffer queue) message가 나타나면, buffer갯수가 부족한 것이므로 늘려주도록 한다.
• 단 일반적으로는 이 option을 이용하여 값을 늘린다하더라도 system overhead만 증가하고 performance의 향상은 기대하기 어렵다.

1. data가 table에 load된다.
2. load된 data의 key 부분이 temporary segment에 copy되어 sort된다.[나]
3. 기존에 존재하던 index와 [나]에 의해서 정렬된 key가 merge된다.[다]
4. [다]에 의해서 새로운 index가 만들어진다.
   기존에 존재하던 index와 temporary segment, 그리고 새로 만들어지는 index가 merge가 완전히 끝날 때까지 모두 존재한다.
5. old index와 temporary segment는 지워진다.

• 이와 같은 절차에 반해 conventional path load는 data가 insert될 때마다 한 row 씩 index에 첨가된다.
  그러므로 temporary storage space는 필요하지 않지만
  direct path load에 비해 index 생성 시간도 느리고, index tree의 balancing도 떨어지게 된다.

• index생성 시 필요한 temporary space는 다음과 같은 공식에 의해 예측되어질 수 있다.

  1.3 * key_storage 

  key_storage = (number_of_rows) * (10 + sum_of_column_sizes +  number_of_columns)

• 여기에서 1.3은 평균적으로 sort 시에 추가적으로 필요한 space를 위한 값이며,
  전체 data가 완전히 순서가 거꾸로 된 경우에는 2,
  전체가 미리 정렬된 경우라면 1을 적용하면 된다.

• 이와 같이 direct path load에서 index 생성 시 space를 많이 차지하는 문제점 때문에 resource가 부족한 경우에는 SINGLEROW option을 사용할 수 있다.
• 이 option은 controlfile 내에 다음과 같은 형태로 기술하며, direct path load에만 사용 가능하다.

  INTO TABLES TABLE_NAME [sorted indexes...] singlerow

• 이 option을 사용하면 전체 data가 load된 뒤에 index가 구성되는 것이 아니라 data가 load됨에 따라 data 각각이 바로 index에 추가된다.
• 이 option은 기존에 미리 index가 존재하는 경우 index를 생성하는 동안 merge를 위해 space를 추가적으로 필요로 하는 것을 막고자 하는 것이므로
  INSERT 시에는 사용하지 않고, APPEND시에만 사용하도록 하고 있다.
• 실제 새로 load할 data 보다 기존 table이 20배 이상 클 때 사용하도록 권하고 있다.
• direct path load는 rollback information을 기록하지 않지만, 이 singlerow option을 사용하면
  insert되는 index에 대해 undo 정보를 rollback segment에 기록하게 된다.
• 그러나, 중간에 instance failure가 발생하면 data는 data save까지는 보존되지만 index는 여전히 direct load state로 사용할 수 없게 된다.

• 만약 direct path load가 성공적으로 끝나지 않으면 index는 direct load state로 된다.
• 이 index를 통해 조회하고자 하면 다음과 같은 오류가 발생한다.

  ORA-01502 : index 'SCOTT.DEPT_PK' is in direct load state.

1. index가 생성되는 과정에서 space가 부족한 경우
2. SORTED INDEXES clause가 사용되었으나, 실제 data는 정렬되어 있지 않은 경우
   이러한 경우 data는 모두 load가 되고, index만이 direct load state로 된다.
3. index 생성 도중 instance failure가 발생한 경우
4. unique index가 지정되어 있는 컬럼에 중복된 data가 load되는 경우

• 특정 index가 direct load state인지를 확인하는 방법은 다음과 같다.

  SELECT index_name, STATUS
  FROM user_indexes
  WHERE TABLE_NAME = TABLE_NAME';

• 만약 index가 direct load state로 나타나면 그 index는 drop하고 재생성하여야만 사용할 수 있다.
  단, direct load 중에는 모든 index가 direct load state로 되었다가 load가 성공적으로 끝나면 자동으로 valid로 변경된다.

• direct load 시 index구성을 위해서 정렬하는 시간을 줄이기 위해 미리 index column에 대해서 data를 정렬하여 load시킬 수 있다.
  이 때 control file 내에 SORTED INDEXES option을 다음과 같이 정의한다.
• 이 option은 direct path load 시에만 유효하며, 복수 개의 index에 대해서 지정가능하다.

  INTO TABLE TABLE_NAME SORTED INDEXES (index_names_with_blank)

• 만약, 기존의 index가 이미 존재한다면, 새로운 key를 일시적으로 저장할 만큼의 temporary storage가 필요하며,
  기존 index가 없는 경우였다면, 이러한 temporary space도 필요하지 않다.
• 이와 같이 direct path load 시에 index 구성 시에는 기존 데이타가 있는 table에 load하는 경우
  space도 추가적으로 들고, load가 완전히 성공적으로 끝나지 않으면 index를 재생성하여야 하므로,
  일반적으로 direct path load 전에 미리 table의 index를 제거한 후 load가 모두 끝난 후 재생성하도록 한다.

• direct load는 기존 segment중간에 data를 insert하는 것이 아니라 완전히 새로운 block을 할당받아 정확히 write가 끝난 다음 해당 segment에 포함되기 때문에
  instance failure시에는 redo log정보를 필요로 하지 않는다.
  그러나 default로 direct load는 redo log에 입력되는 data를 기록하는데 이것은 media recovery를 위한 것이다.
  그러므로 archive log mode가 아니면 direct load에 생성된 redo log 정보는 불필요하게 되므로
  NOARCHIVELOG mode시에는 항상 control file내에 UNRECOVERABLE이라는 option을 사용하여 redo log에 redo entry를 기록하지 않도록 한다.
• data가 redo log 정보 없이 instance failure시에 data save까지는 보호되는데 반해 index는 무조건 direct load state가 되어 재생성하여야 한다.
  그리고 data save이후의 load하고자 하는 table에 할당되었던 extent는 load된 data가 user에게 보여지지는 않지만 extent가 free space로 release되지는 않는다.

1. direct path load 중 not null, unique, primary key constraint는 enable 상태로 존재한다.
   not null은 insert시에 check되고 unique는 load후 index를 구성하는 시점에 check된다.
2. 그러나 check constraint와 referential constraint는 load가 시작되면서 disable상태로 된다.
   전체 데이타가 load되고 난 후 이렇게 disable된 constraints를 enable시키려면 control file내에 REENABLE이라는 option을 지정하여야 한다.
   이 reenable option은 각 constraint마다 지정할 수는 없으며 control file에 한번 지정하면 전체 integrity/check constraint에 영향을 미치게 된다.
   만약 reenable되는 과정에서 constraint를 위배하는 data가 발견되면 해당 constraint는 enable되지 못하고 disabled status로 남게 되며,
   이렇게 위배된 data를 확인하기 위해서는 reenable clause에 exceptions option을 다음과 같이 추가하면 된다.

   reenable [exceptions table_name]

3. 이 때 table_name은 $ORACLE_HOME/rdbms/admin/utlexcpt.sql을 다른 directory로copy하여 table이름을 exceptions가 아닌 다른 이름으로 만들어 수행시키면 된다.
4. insert trigger도 integrity/check constraint와 같이 direct load가 시작하는 시점에 disable되며, load가 끝나면 자동으로 enable된다.
   단 enable되고 나서도 load에 의해 입력된 data에 대해 trigger가 fire되지는 않는다.

[펌] http://kr.forums.oracle.com/forums/thread.jspa?threadID=470778&tstart=315