공간 관리 공간을 효율적으로 관리하는 것은 데이터베이스의 성능에 중요한 일입니다. 이 장에서는 데이터베이스에서 익스텐트와 블록을 관리하는 방법을 다룹니다. 블록 오라클에서, 블록은 데이터 파일 I/O의 가장 작은 단위이자 할당될 수 있는 공간의 가장 작은 단위입니다. 오라클 블록은 하나이상의 연속적인 운영체제 블록으로 이루어져 있습니다. 익스텐트 익스텐트는 여러 연속적인 데이터 블록으로 만들어진 데이터베이스 저장장소 공간 할당의 논리적 단위입니다. 하나 이상의 익스텐트가 모여 세그먼트를 이룹니다. 세그먼트에서 기존 공간이 완전히 사용되면, 오라클은 세그먼트에 대해 새로운 익스텐트를 할당합니다. 세그먼트 세그먼트는 테이블스페이스 내의 특정 논리적 저장구조에 대한 모든 데이터를 포함하는 익스텐트의 집합입니다. 예를 들어, 오라클은 각 테이블에 대해 하나 이상의 익스텐트를 할당하여, 그 테이블에 대한 데이터 세그먼트를 형성합니다. 인덱스에 대해서는 하나 이상의 익스텐트를 할당하여, 인덱스 세그먼트를 형성합니다.

데이터베이스 작업으로 인해 데이터가 증가하여 할당된 공간을 초과할 때, 오라클은 세그먼트를 확장합니다. INSERT나 UPDATE 문을 실행시킬 때 세그먼트를 확장하여 동적으로 확장이 이루어지게 되면 성능은 감소합니다. 서버가 여유 공간을 찾고 데이터 딕셔너리에 익스텐트를 추가하기 위하여 여러 순환적(recursive) SQL문을 실행하기 때문입니다.    

동적인 확장을 피하기 위하여 다음을 수행합니다:

• 다음을 통해 세그먼트의 크기를 적절하게 조정합니다:
  -  객체의 최대 크기 결정
  -  객체를 생성할 때 모든 데이터를 충분히 수용할 수 있는 크기의 익스텐트를 할당하는 저장장소 파라미터 선택
  
  세그먼트 크기를 결정할 때, DBA는 데이터의 증가를 허용해야 합니다. 예를 들어,현재의 데이터와 다음 해 동안 세그먼트에 삽입될 데이터에 대해서도 충분한 공간을 할당하십시오. 테이블에 대해 허용해야 할 공간의 양을 예측하기 위해 사용하는 공식에 관해서는 ‘ Oracle8 서버 관리자의 안내’를 보십시오.
   
• 동적으로 확장하려 하는 세그먼트에 대해 데이터베이스를 감시한 다음, ALTER TABLE/INDEX/CLUSTER 명령을 사용하여 이들 세그먼트를 확장시키십시오.

공간을 쉽게 관리하기 위하여, DBA는 적절한 크기의 세그먼트와 익스텐트로 객체를 생성합니다. 일반적으로, 작은 익스텐트 보다는 큰 익스텐트가 선호됩니다.

크기가 큰 익스텐트의 장점

• 익스텐트의 크기가 큰 세그먼트는 확장할 필요가 적기 때문에, 큰 익스텐트는 동적인 익스텐트를 피하게 됩니다.
   
• 오라클은 작은 크기의 많은 익스텐트를 읽기 보다는 블록 수가 더 적은 디스크에서 하나의 큰 익스텐트를 읽을 수 있기 때문에, 더 큰 익스텐트가 약간의 성능 이점이 있습니다. 부분적인 여러 블록을 읽는 것을 피하기 위해서는, 5*DB_FILE_MULTIBLOCK_READ_COUNT의 배수로 익스텐트 크기를 설정하십시오. 5를 곱하는 것은 오라클이 익스텐트를 5개의 블록씩 할당하기 때문입니다. 익스텐트 크기를 I/O   및 공간 할당 크기에 맞춤으로써, 한 세그먼트 당 많은 익스텐트가 할당되어 드는 성능  비용은 최소로 될 것입니다. 그러나, 결코 전체 테이블 스캔 작업을 하지 않는 테이블에서는, 테이블이 하나의 익스텐트를 갖고 있든 여러 개의 익스텐트를 갖고 있든 질의 성능 면에서는  차이가 없습니다.
   
• 크기가 매우 큰 테이블에 대해서는, 파일 크기에 대한 운영체제의 제한으로 인하여 DBA는 여러 익스텐트가 있는 객체를 할당해야 할 것입니다.
  
  
• 인덱스를 사용하는 검색의 경우, 성능은 인덱스가 갖고 있는 익스텐트의 수에 의해 영향받지 않습니다.
  
  
• 익스텐트 맵은 특정 세그먼트의 모든 익스텐트 목록을 나타냅니다. MAXEXTENTS  UNLIMITED의 경우, 이들 맵은 여러 블록에 위치해 있습니다. 최상의 성능을 얻기 위해서는,   익스텐트 맵을 단일 I/O로 읽을 수 있어야 합니다. 전체 테이블 스캔 시 익스텐트 맵을 갖는데  여러 I/O를 필요로 하는 경우 성능은 저하됩니다. 또한, 각 익스텐트가 딕셔너리 캐쉬에 있는 공간을 사용하기 때문에, 익스텐트가 많을 경우 데이터 딕셔너리 성능을 저하시킬 수  있습니다.  

크기가 큰 익스텐트의 단점

• 큰 익스텐트는 더 많은 연속 블록을 요구하기 때문에, 오라클이 이들 블록을 저장할 충분한 연속 블록을 찾는데 어려움이 있을 것입니다.
  
• DBA는 증가에 대비하여 세그먼트 크기를 조정하기 때문에, 세그먼트에 할당된 공간의  일부는 초기에 사용되지 않을 것입니다.

큰 익스텐트를 적게 할당할 것인가 아니면 작은 익스텐트를 많이 할당할 것인가를 결정할 때에는, 테이블의 증가와 사용에 대한 계획에 맞추어 각각의 이점과 결함을 고려해야 합니다.

데이터베이스 튜닝 목표 중의 하나는 액세스되는 블록의 수를 최소화하는 것입니다. 이 목표를 달성하기 위하여, 개발자는 애플리케이션과 SQL 문을 튜닝하고, DBA는 다음을 통해 블록 액세스를 감소시킵니다:

• 더 큰 블록 크기 사용
• 블록을 가능한 촘촘하게 압축
• 행 이전(row migration) 예방

불행하게도, DBA에게 마지막 2개의 목표는 서로 상충됩니다. 즉, 많은 데이터를 블록으로 압축시키면, 행 이전이 증가하기 때문입니다

블록 크기의 특성은 다음과 같습니다:

• 데이터베이스가 생성될 때, 블록 크기는 DB_BLOCK_SIZE 파라미터 값으로 설정됩니다.
  
  
• 블록 크기는 데이터 파일을 읽기 위한 최소 I/O 단위입니다.
  
  
• 대부분의 오라클 플랫폼에서 디폴트 블록 크기는 2 또는 4 kilobytes 입니다.
  
  
• 현재 일부 운영체제는 블록 크기를 최대 64 kilobytes까지 허용합니다. 특정 운영체제에 관한 문서를 확인하십시오. 특히, 플랫폼에 관한 오라클의 설치 및 구성 안내 부분을 확인하십시오.
  
  
• 크기는 데이터베이스를 재생성하거나 복사하지 않고는 변경할 수 없습니다. 따라서, 블록 크기가 다른 애플리케이션을 테스트하는 것은 어렵습니다.
  
  
• 블록 크기는 운영체제 블록 크기의 배수이어야 합니다.
  
  
• 운영체제가 연속 읽기 동안 다음 블록을 계속하여 읽고, 애플리케이션이 전체 테이블 스캔 작업을 많이 수행한다면, 운영체제 I/O 크기는 데이터베이스 블록 크기와 같거나 더 커야 합니다.

선택된 블록 크기는 성능에 영향을 미칩니다. 일반적인 Guideline은 다음과 같습니다:

• OLTP 환경에서처럼 큰 객체에 임의로 액세스할 때에는 작은 블록이 선호되고,
• DSS 환경에서처럼 대량의 데이터에 연속으로 액세스할 때에는 큰 블록이 선호됩니다.

작은 오라클 블록

장점

• 작은 블록은 블록 당 행수가 더 적기 때문에 블록 경합을 감소시킵니다.
• 작은 블록은 작은 행에 유용합니다.
  
• 블록이 메모리로 읽혀진 후 재사용될 가능성이 거의 없어 더 작은 블록 크기가 버퍼 캐쉬를 더 효율적으로 사용하기 때문에, 임의로 액세스할 때는 작은 블록이 유용합니다. 이것은, 데이터베이스 버퍼 캐쉬의 크기가 제한되어 있기 때문에 메모리 자원이 부족할 때 특히 중요합니다.

단점

• 작은 블록의 경우 오버헤드가 비교적 큽니다.
  
• 행의 크기에 따라, 블록 당 행 수를 적게 저장하게 될 것입니다. 이로 인하여 추가 I/O가  발생할 것입니다.
  
• 이것은 더 많은 인덱스 블록을 읽을 수도 있습니다
•  

큰 오라클 블록

장점

• 비교적 오버헤드가 적기 때문에 유용한 데이터를 저장할 여유가 더 많습니다.
  
• 큰 블록은 연속 읽기에 유용합니다.
  
• 큰 블록은 매우 큰 행에 유용합니다.
  
• 더 큰 블록은 인덱스의 읽기 성능을 향상시킵니다. 더 큰 블록은 큰 인덱스의 레벨 수를 감소시키는 각 블록에 더 많은 인덱스 엔트리를 유지할 수 있습니다. 인덱스 레벨이 더 적을수록 인덱스 분기를 이동할 때 I/O 횟수가 더 적게 됩니다.

단점

• 큰 블록 크기는 OLTP 유형의 환경에서 사용되는 인덱스 블록에 대해서는 유용하지 않습니다. 인덱스 리프(leaf) 블록에서 블록 경합을 증가시키기 때문입니다.
  
• 작은 행에 임의로 액세스하고 큰 블록 크기를 갖고 있다면, 버퍼 캐쉬에 있는 공간은 낭비될  것입니다. 예를 들어, 블록 크기가 8 kilobyte이고 행 크기가 50 byte일 경우, 임의 액세스를 수행할 때 버퍼 캐쉬에서 7,950 byte를 낭비하게 될 것입니다.

데이터베이스 블록의 크기를 재조정하는데 추가 메모리가 없을 경우, DB_BLOCK_BUFFERS를 재설정할 필요가 있습니다. 이것은 캐쉬 적중율에 영향을 미칠 것입니다.

기술적 주의사항

• DBA는 큰 테이블의 행을 읽는데 작은 블록 크기를 사용하지 않고, 재활용 버퍼 풀을 사용할 수 있습니다.
  
• DBA는 인덱스 I/O을 감소시키는데 큰 블록 크기를 사용하지 않고, 유지 버퍼 풀을 사용할 수 있습니다.

Guidelines

• PCTFREE와 PCTUSED를 설정할 때, 다음 공식을 사용합니다:
  -  PCTFREE = 100 * upd(upd+ins)
  -  PCTUSED = 100 - PCTFREE - 100 * rows * (ins + upd) / blocksize
  
  여기에서: upd는 갱신 시 추가되는 평균 양이며 바이트로 표시됩니다.
                 ins는 삽입 시의 평균 초기 행 길이입니다.
                 rows는 freelist관리가 발생되기 전에 삭제된 행 수입니다.
  
  
• 갱신 작업과 한 행 추가 분에 대해 블록 공간이 충분히 여유가 있을 때, PCTUSED에 대한   공식을 사용하여 테이블에 삽입할 수 있습니다.
  
  
• PCTUSED는 삭제 작업을 수행하는 테이블에만 관련이 있습니다. 그러나, 많은 테이블에서,  PCTUSED를 디폴트(40%) 보다 높게 설정하여 행들을 블록으로 더 촘촘하게 압축할 수 있을  것입니다.
  
  
• 삽입 작업이 많이 발생하는 테이블에 대해, PCTUSED를 변경하면 블록 저장장소 성능을 향상시킬 것입니다.  자주 사용되는 블륵들은 freelist 경합을 발생시킬 수 있습니다, 그러나 더 적은 수의 블록이 필요하게 되고, 테이블이 더 작고, 읽기 작업이 더 빨라집니다.
  서로 다른 두 종류의 성능의 조화를 위해서 PCTUSED 값을 조금 크게 하거나 작게 할 수있습니다.
  
  
• 기존 테이블에 대해 PCTFREE와 PCTUSED를 변경하더라도, 블록에 즉시 영향을 미치지  않습니다.  그러나, 이후 DML 활동은 테이블에 대해 새로운 규칙을 사용합니다. 

다음과 같은 두 가지 상황에서는, 테이블 행의 데이터가 너무 크기 때문에 단일 데이터 블록에 다 들어가지 않을 것입니다.

• 첫째, 연쇄화(chaining)라고 하는 경우에는, 행이 너무 커서 빈 데이터 블록에 다 저장되지   않습니다. 이 경우, 오라클은 행의 데이터를 하나 이상의 연결된 블록에 저장합니다. 이러한  연쇄화 현상은 행이 삽입되거나 갱신될 때 발생할 수 있습니다. 행 연쇄화는 보통 LOB를 포함하는 행과 같은 큰 행에서 발생합니다. 이러한 경우의 행 연쇄화는 피할 수 없습니다.
  
  
• 그러나, 이전(migration)이라고 하는 경우에는, UPDATE 문이 행의 데이터 양을 증가시키기 때문에 행이 한 데이터 블록에 더 이상 다 저장되지 않습니다. 오라클은 전체 행을 유지하기에 충분한 여유 공간이 있는 다른 블록을 찾으려 합니다. 그러한 블록이 가능하면, 오라클은 전체 행을 새로운 블록으로 이동시킵니다. 오라클은 새로운 블록을 가리키도록 이전 된 행의 원래 부분을 유지합니다. 이전된 행의 ROWID가 변하지 않기 때문에 가능합니다. 이때, 인덱스는 갱신되지 않기 때문에, 원래 행의 위치를 가리킵니다.

이전 및 연쇄화는 다음과 같이 성능에 부정적인 영향을 미칩니다:

• 이전 및 연쇄화를 유발시키는INSERT와 UPDATE 문은 추가 처리 작업을 수행하기 때문에,  좋은 성능을 낼 수 없습니다.
  
  
• 인덱스를 사용하여 이전 또는 연쇄화를 선택하는 질의는 추가 I/O작업을 수행해야 합니다.

이전 현상은 PCTFREE가 너무 낮게 설정 되었을 때 발생합니다. 갱신 작업을 수행하는데 충분한 여유 메모리가 없기 때문입니다. 이전 현상을 피하기 위해서는, 갱신되는 모든 테이블은 블록 공간이 갱신 작업에 충분하도록 PCTFREE를 설정해야 합니다.  

ANALYZE …COMPUTE STATISTICS
ANALYZE 문의 COMPUTE STATISTICS option을 사용하면 테이블이나 클러스터 내에 이전 및 연쇄화 된 행이 존재하는지 알 수 있습니다.  이 명령어는 이전 및 연쇄화 된 행의 수를 세어 DBA_TABLES의 CHAIN_CNT열에 기록합니다.

NUM_ROWS열은 분석된 테이블 또는 클러스터에 저장된 총 행수를 가집니다.이전된 행을 제거해야 할 지를 결정하기 위해서 전체 행 수에 대한 이전 및 연쇄화
된 행의 비율을 계산하십시오.

Table Fetch Continued Row Statistic
또한 V$SYSSTAT이나 report.txt의 Table Fetch Continued Row 통계정보를 확인하여 이전 및 연결 된 행이 있는지를 알 수 있습니다.

Guidelines
PCTFREE를 증가시켜, 이전되는 행을 피하십시오. 블록에 이용할 수 있는 더 많은 여유 공간이 있다면, 행은 증가하는데 필요한 공간을 갖게 될 것입니다.  또한 많은 삭제가 있는 테이블이나 인덱스를 재구성(재생성) 할 수 있습니다. 

ANALYZE ... LIST CHAINED ROW
LIST CHAINED ROWS 옵션과 함께 ANALYZE 명령을 사용하여, 테이블 또는 클러스터에서 이전되었거나 연결된 행을 식별할 수 있습니다. 이 명령은 이전되었거나 연결된 각 행에 대한 정보를 수집하여 특정 출력 테이블에 놓습니다. 연결된 행을 포함하는 테이블을 생성하기 위해서는, UTLCHAIN.SQL 스크립트를 실행시키십시오.

  create table CHAINED_ROWS(
     owner_name         varchar2(30),
     table_name         varchar2(30),
     cluster_name       varchar2(30),
     partition_name     varchar2(30),
     head_rowid         rowid,
     analyze_timestamp  date);

이 테이블을 수동으로 생성할 경우, 테이블의 열 이름, 데이터 유형, 크기는 CHAINED_ROWS 테이블의 것과 같아야 합니다.

다음의 SQL*Plus 스크립트를 사용하여 이전된 행을 삭제할 수 있습니다:
 
   /* Get the name of the table with migrated rows */
   accept table_name prompt ‘Enter the name of the table with migrated rows:’
   /* Clean up from last execution */
   set echo off
   drop table migrated_rows;
   drop table chained_rows;

   /* Create the CHAINED_ROWS table */
   @?/rdbms/admin/utlchain
   set echo on
   spool fix_mig
   /* List the chained & migrated rows */
   analyze table &table_name list chained rows;
   /* Copy the chained/migrated rows to another table */
   create table migrated_rows as
       select   orig.*  
           from   &table_name orig, chained_rows  cr
           where    orig.rowid = cr.head_rowid;
           and     cr.table_name = upper (‘&table_name’);

   /* Delete the chained/migrated rows from the orignial table */
   delete from &table_name
       where rowid in ( select head_rowid  from  chained_rows);

   /*  Copy the chained/migrated rows back into the original table */
   insert into &table_name select * from  migrated_rows;

   spool off

이 스크립트를 사용할 때에는, 행이 삭제 시 위반하게 될 외부키(foreign key) 제약조건을 출력할 필요가 있습니다.

최고 수위 표시 위의 공간은 다음 명령을 사용하여 테이블 레벨에서 이용할 수 있습니다:

   ALTER TABLE <table_name> DEALLOCATE UNUSED…

전체 테이블 스캔 시, 오라클은 최고 수위 표시 아래의 모든 블록을 읽습니다. 최고 수위 표시 위의 빈 블록은 공간을 낭비할 수는 있지만, 성능을 저하시키지는 않습니다. 그러나, 최고 수위 표시 아래의 사용된 블록 이하는 성능을 저하시킬 것입니다.

통계를 수집하고 데이터 딕셔너리 저장장소에 저장하기 위하여, 테이블, 인덱스, 클러스터의 저장장소 특성을 분석할 수 있습니다. 이들 통계를 사용하여 테이블이나 인덱스가 사용되지 않은 공간을 갖고 있는지의 여부를 결정할 수 있습니다.

DBA_TABLES 뷰를 질의하여 결과 통계 자료를 보십시오.

열	설명
NUM_ROWS	테이블의 행 수
BLOCKS	최고 수위 표시 아래의 블록 수
EMPTY_BLOCKS	최고 수위 표시 위의 블록 수
AVG_SPACE	최고 수위 표시 아래 블록의 평균 여유공간
AVG_ROW_LEN	행 오버헤드를 포함한, 평균 행 길이
CHAIN_CNT	테이블의 이전된 또는 연결된 행 수

EMPTY_BLOCKS는 이전에는 완전 사용되었지만  현재는 비워있는 블록을 나타내는 것이 아니라, 아직 사용되지 않은 블록을 나타냅니다.

기술적 주의사항
오라클은 SAMPLE 절이 생략될 경우에는 1064 행을 샘플로 하고, 데이터의 반 이상이 SAMPLE 수치에 의해 지정되었을 경우에는 ESTIMATE가 아니라 COMPUTE를 사용합니다.

또한 지원되는 위의 패키지를 사용하여 세그먼트의 공간 사용에 관한 정보를 얻을 수 있습니다. 이 패키지에는 2개의 프로시저가 포함되어 있습니다:

• UNUSED_SPACE는 객체(테이블, 인덱스, 또는 클러스터)의 사용되지 않은 공간에 관한  정보를 반환합니다. 사양은 다음과 같습니다:
  
    unused_space (segment_owner IN varchar2,
       segment_name IN    varchar2,
       segment_type IN    varchar2,
       total_blocks OUT   number,
       unused_blocks OUT  number,
       unused_bytes OUT   number,
       last_used_extent_file_id OUT    number,
       last_used_extent_block_id OUT   number,
       last_used_block OUT             number);
   
• FREE_BLOCKS은 객체(테이블,인덱스,클러스터)의 여유 블록에 대한 정보를 반환합니다. 그 사양은 다음과 같습니다:
  
    free_block(segment_owner IN varchar2
       segment_name IN          varchar2,
       segment_type IN          varchar2,
       freelist_group_id IN     number,
       free_blks OUT            number,
       scan_limit IN            number DEFAULT NULL);

이들 프로시저는 catproc.sql에 의해 실행되는 dbmsutil.sql 스크립트에 의해 생성되어 문서화됩니다. 이 패키지를 실행시킬 때, FREE_LIST_GROUP_ID 값을 제공해야 합니다. Oracle Parallel Server를 사용하지 않을 경우, 1을 사용하십시오.

이 스크립트는 사용자에게 테이블 소유자와 테이블명에 관한 정보를 제공하고, DBMS_SPACE.UNUSED_SPACE를 실행시키며, 공간 관련 통계를 출력합니다.

 Declare
   owner       varchar2(30);  
   name        varchar2(30)
   seq_type    varchar2(30)
   tblock      number;
   uBlock      number;
   ubyte       number;
   lue_fid     number;
   lue_bid     number;
   lublock     number;
BEGIN
   dbms_space.unused_space (‘&owner’, ‘&table_name’, ‘TABLE’,
        tblock, tbyte, ublock, ubyte, lue_fid, lue_bid, lublock);
   dbms_output.put_line (‘Total blocks allocated to table = ‘
        || to_char(tblock));
   dbms_output.put_line (‘Total blocks allocated to table = ‘
        || to_char(tbyte));
   dbms_output.put_line (‘Unused blocks(above HWM)        = ‘
        || to_char(ublock));
   dbms_output.put_line (‘Unused blocks(above HWM)        = ‘
        || to_char(ubyte));
   dbms_output.put_line (‘Last extent used file id        = ‘
        || to_char(lue_fid));
   dbms_output.put_line (‘Last extent used beginning block id = ‘
        || to_char(lue_bid));
   dbms_output.put_line (‘Last extent block in last extent    = ‘
        || to_char(lublock));
END;

휘발성 테이블에 대한 인덱스 또한 성능 문제를 나타낼 수 있습니다.  

데이터 블록에서, 오라클은 삭제된 행을 삽입된 행으로 교체합니다. 그러나, 인덱스 블록에서는, 엔트리들을 순서대로 정열합니다. 값은 동일한 범위의 다른 값들과 함께 적당한 블록으로 갑니다.

많은 애플리케이션은 오름차순 인덱스 순서로 삽입하고 이전 값을 삭제합니다. 그러나, 블록이 한 엔트리만을 포함하더라도, 이 블록은 유지되어야 합니다. 이러한 경우에, 인덱스를 규칙적으로 재구축해야 할 필요가 있을 것입니다.

인덱스 블록의 모든 엔트리를 삭제할 경우, 오라클은 이 블록을 free list에 다시 놓습니다.

다음 명령을 사용하여 인덱스에 의해 사용되는 공간을 감시할 수 있습니다.

  SQL> ANALYZE INDEX index_name VALIDATE STRUCTURE;

그런 다음 INDEX_STATS 뷰를 질의하십시오:

열	설명
LF_ROWS	현재 인텍스에 있는 값의 수
LF_ROWS_LEN	모든 값의 길이의 바이트 합
DEL_LF_ROWS	인덱스에서 삭제된 값의 수
DEL_LF_ROWS_LEN	모든 삭제된 값의 길이

        
주의: INDEX_STATS 뷰는 가장 마지막에 분석된 인덱스를 보여줍니다. 만인 동일 사용자로 다른 세션으로 접속하였다면 뷰는 그 뷰를 질의하는 세션에서 분석된 인덱스를 보여 줍니다.

인덱스 재구성(REBUILD)
애플리케이션과 우선순위에 따라 다르겠지만, 삭제된 엔트리가 현재 엔트리의 20% 또는 그 이상을 나타낼 경우 재구축할 것을 결정할 것입니다. 위의 질의를 사용하여 비율을 찾을 수 있습니다. ALTER INDEX REBUILD 문을 사용하여, 기존 인덱스를 재구성하거나 압축하든지, 또는 저장장소 특성을 변경하십시오. REBUILD 문은 기존 인덱스를 사용하여 새로운 인덱스를 구축합니다. STORAGE(익스텐트 할당에 대해), TABLESPACE(인덱스를 새로운 테이블스페이스로 이동시키기 위해), INITRANS(초기 엔트리의 수를 변경하기 위해)와 같은 모든 인덱스 저장장소 명령어가 지원됩니다.또한, 인덱스를 구축할 때, 다음 키워드를 사용하여 재구축하는데 소요되는 시간을 감소시킬 수 있습니다:

• PARALLEL 또는 NONPARALLEL (NONPARALLEL 이 디폴트)
• RECOVERABLE 또는 UNRECOVERABLE (RECOVERABLE 이 디폴트)
  - UNRECOVERABLE 옵션은 리두 로그 엔트리를 작성하지 않기 때문에 더 빠릅니다.
  - 이 절은 객체에 대한 영구 속성을 설정하는 것이 아니라, 생성 작업 동안에만 유효합니다;    그러므로 딕셔너리에는 나타나지 않습니다.
  - 이 속성은 변경할 수 없습니다.
  - 이 속성은 객체의 생성 또는 재구성(REBUILD) 시에만 사용 가능 합니다.
  - 이 속성은 디폴트로 LOGGING을 내포합니다, 즉 이후의 삽입은 logging됩니다.
  - 만일 복구 중에 인덱스가 재생성 되어야 한다면, 그 인덱스는 복구 할 수 없습니다.
• LOGGING 또는 NOLOGGING
  -  NOLOGGING 옵션은 리두 로그 엔트리를 기록하지 않기 때문에 더 빠릅니다.
  - 이것은 영구적인 속성이고 따라서 딕셔너리에 나타납니다.
  - 이것은 언제라도 변경(ALTER INDEX NOLOGGING/LOGGING) 가능합니다.

UNRECOVERATBLE과 NOLOGGING은 동일하지 않습니다.

주의: Oracle8의 초기버전에서는 UNRECOVERABLE 옵션을 사용할 수 있었지만, 그것은  NOLOGGING 옵션으로 대체되었습니다.

UNRECOVERABLE 절처럼 사용하기 위하여, NOLOGGING 옵션으로 객체를 생성한 후 ALTER 명령으로 LOGGING으로 변경하십시오. RECOVERABLE 절처럼 사용하기 위하여, LOGGING 옵션으로 객체를 생성하십시오.

ALTER INDEX REBUILD는 일반적으로 빠른 전체 스캔 기능을 이용하기 때문에 인덱스를 해제하고 재생성하는 것보다 훨씬 더 빠릅니다. 따라서, ALTER INDEX REBUILD는 복수 블록 I/O를 사용하여 모든 인덱스 블록을 읽은 다음 분기 블록은 삭제합니다. 이러한 접근법의 더 나은 장점은 재구축 작업이 진행 되는 동안에도 이전의 인덱스를 질의(DML에 대해서는 안됨)에 여전히 사용할 수 있다는 것입니다.

기술적 주의사항
ANALYZE 명령의 변형으로 인덱스가 손상될 경우, 인덱스를 재구축해야 합니다.

문맥	참조
초기화 파라메터	None
동적인 성능 뷰	V$SYSSTAT  V$SESSTAT  V$MYSTAT
데이터 딕셔너리 뷰	USER_, ALL_, DBA_CLUSTERS  USER_, ALL_, DBA_INDEXES  USER_, ALL_, DBA_TABLES  INDEX_STATS
명령어	ALTER/CREATE INDEX/TABLE/CLUSTER  ALTER INDEX … REBUILD  TRUNCATE  ANALYZE … COMPUTE STATISTICS  ANALYZE … LIST CHAINED ROWS
패키지된 프로시저 및 함수	DBMS_SPACE
스크립트	dbmsutil.sql, utlchain.sql
진단팩 애플리케이션	Performance Manager

• Analyze를 해 보니 1주일 전보다 인덱스 엔트리가 현저하게 줄었다. 어떤 조치를 취해야 하나?
  A. 필요없으므로 Drop한다.
  B. Deallocate unused를 사용하여 필요없는 공간을 반납한다.
  C. 인덱스를 재 생성한다.
  D. 엔트리의 저하는 성능을 크게 좌우하지 않으므로 그대로 사용한다.
  답

• B-Tree Index의 branch level로서 적정한 값은 ?
  A. 4 level보다 작게
  B. 8 level 보다 작게
  C. 4 level보다 크게
  D. 1 level보다 크게
  답

• Freelist에 대한 경합을 줄이는 방법으로 적당한 것은?
  A. 버퍼캐쉬의 크기를 늘린다.Increasing the size of the buffer cache.
  B. 리두로그 버퍼의 크기를 늘린다.
  C. 해당 세그먼트의 freelist parameter를 늘린다.
  D. 해당 세그먼트를 삭제하고 더 많은 freelist를 갖도록 지정하여 다시 생성한다.
  답

• PCTFREE가 높은 경우에대한 설명으로 맞는 것은?
  A. block내 data가 많이 저장되어 공간활용이 좋다.
  B. OLTP, DSS 시스템 모두 적용하기에 좋다.
  C. 버퍼캐쉬의 성능을 최대화 시킬 수 있다.
  D. data migration.을 줄일 수 있다.
  답

• ROW MIGRATION을 해결하기 위해 하는 작업의 순서는?(예:ABCD와 같이 먼저 수행되어야 하는 작업을 먼저 적고, 대문자로 답함)
  A. CHAINED_ROWS 테이블의 ROWID에 해당하는 ROW로 임시 테이블을 만든다.
  B. 임시테이블에 있는 ROW를 원래의 테이블로 다시 INSERT한다.
  C. CHAINED_ROWS 테이블의 ROWID에 해당하는 ROW를 원래의 테이블에서 삭제.
  D. ANALYZE TABLE ~ LIST CHAINED ROWS 답

• UPDATE가 자주 일어날 때 ROW MIGRATION을 줄이고 UPDATE를 위한 공간을 확보하고자 할 경우 어떻게 SPACE사용을 제어하여야 하는가?
  A. PCTFREE를 작게한다
  B. PCTFREE를 크게한다
  C. PCTUSED를 작게한다
  D. PCTUSED를 크게한다
  답

• row migration을 찾아내는 방법으로 적당한 것은?
  A. UTLBSTAT/UTLESTAT 을 사용한다.
  B. ANALYZE TABLE <table> LIST CHAINED ROWS INTO <schema>.table;을 사용한다.
  C. v$chain이라는 동적성능뷰를 조회한다.
  D. Server Manager Utility에서 SHOW PARAMETER BLOCK를 수행한다.
  답