Oracle 8/8i Performance Tuning Tips

프로그래밍/DB

by 라제폰 2009. 3. 9. 14:10

데이타베이스 환경에서 Memory/CPU 활용률을 높이고 I/O와 프로세싱 병목을 해결함으로써 성능을 높이는 것은 데이타베이스 운영자의 주요 과제 중 하나일 것이다. Oracle8/8i는 Multiple Buffer Pool, Multiple I/O Slaves, Space Management 등의 다양한 기능들을 제공함으로써 데이타베이스 성능 향상에 기여하고 있다.
이들 기능의 운영 원리와 구현 방법, 활용 방안에 대해서 알아본다.

글| 전한태 (한국오라클 고객지원 2팀)
htjeon@kr.oracle.com

개요

고객의 업무를 안정적으로 구현하기 위한 시스템을 구축하기 위해서는 도입 시에 업무의 부하 정도와 운영 여건을 종합적으로 고려하는 Capacity Planning에 근거한 자원을 확보해야 하지만, 아직은 현실적으로 미흡한 부분이 많은 것이 사실이다.

그러나 주어진 자원을 가지고 데이타베이스를 운영하는 시스템 환경에서 제공되는 기능을 최대한으로 활용함으로써 성능을 향상시키려는 노력이 부단히 이루어지고 있다.

전체적인 시스템 성능 향상을 위해 고려해야 할 주요 요소로는 Memory/CPU Usage와 I/O & Processing Bottleneck 등이 있다.

Oracle8/8i는 데이타베이스 성능을 개선시키기 위해 새롭게 또는 보완된 다양한 기능들을 제공하고 있다.

따라서 이 글에서는 새로운 특성으로 제공되는 Multiple Buffer Pool, Multiple I/O Slaves(DBWR, LGWR, ARCH), Space Manage-ment 등의 운영 원리와 구현 방법은 물론 그 활용 방안을 제시함으로써 운영중인 시스템 자원의 활용도를 극대화할 수 있는 효과적인 성능 개선의 기회를 제공하고자 한다.

효율적인 메모리 할당을 위한 Multiple Buffer Pool

Oracle 인스턴스에 대한 데이타와 제어 정보를 가지고 있는 공유 메모리 영역내의 데이타베이스 버퍼는 한정된 자원의 운용 효율성을 높이기 위해 가장 최근에 사용된 데이타 블록을 저장, 유지함을 원칙으로 하며, 인스턴스에 있는 일련의 데이타베이스 버퍼를 데이타베이스 버퍼 캐시라고 한다.

버퍼 캐시는 수정되지 않은 블록뿐만 아니라 수정된 블록도 포함하며 가장 최근에 가장 자주 사용된 데이타를 메모리에 유지함으로써 디스크 I/O 양을 줄이고 최선의 성능을 유지한다.

일반적으로 고객의 다양한 업무 운영 환경에서 생성되어 있는 오브젝트들은 액세스 형태에 따라 다양한 방식으로 참조되고 있다. 즉, 버퍼 캐시의 접근 방식과 액세스 빈도가 상이하다는 것이다.

그러나 Oracle 버전 7까지의 버퍼 캐시는 하나의 틀로서 운영되는 상황으로서 그러한 차별성에 대한 구현이 어려웠다. 하지만 Oracle8 이상에서 제공하는 Multiple Buffer Pool은 바로 그러한 오브젝트 액세스의 다양성과 빈도의 차별성을 구분하여 버퍼 캐시의 세밀한 운영을 가능하게 하는 새로운 기능을 제공한다.

이러한 Multiple Buffer Pool의 캐시 운영 형태는 keep, recycle, default로 구분된다.

Multiple Buffer Pool 운영

| 그림 1 |에서와 같이 SGA 영역내의 데이타 버퍼 캐시를 구현의 목적에 따라 분리해 운영, 관리할 수 있으며, 각각의 버퍼 풀에 버퍼 수와 래치 수를 별도로 할당할 수 있다.

예를 들어 KEEP 버퍼 풀에는 14,000개의 버퍼와 하나의 래치를, RECYCLE 버퍼 풀에는 2,000개의 버퍼와 3개의 래치를 필요에 따라 차등 적용할 수 있다.
다음은 각 버퍼 풀에 대한 세부적인 내용이다.

- KEEP
재사용률이 아주 높은 오브젝트를 대상으로 해당 오브젝트의 모든 블록이 항상 메모리에 상주하도록 설정한다. 즉, 액세스 빈도가 아주 높은 오브젝트들에 대해 디스크 I/O를 극소화시켜 성능 향상을 도모하는 영역이다.

- RECYCLE
재사용 가능성이 비교적 낮은 특정 오브젝트의 블록들을 액세스 직후 바로 메모리에서 제거하도록 관리된다. 그럼으로써 RECYCLE 영역을 필요로 하는 다른 오브젝트들이 언제나 즉시 필요한 버퍼를 할당받을 수 있도록 유지한다.

- DEFAULT
기존의 단독 버퍼 캐시와 동일한 관리 체계를 갖는 기본 영역이다.

Multiple Buffer Pool 정의

Multiple Buffer Pool의 정의는 패러미터로써 가능하며 Oracle 인스턴스에 관련된 모든 패러미터는 initSID.ora 파일에 설정한다.
...

DB_BLOCK_BUFFERS = 30000
DB_BLOCK_LRU_LATCHES = 6
BUFFER_POOL_KEEP = (BUFFERS:12000, LRU_LATCHES:1)
BUFFER_POOL_RECYCLE = (BUFFERS:3000 LRU_LATCHES:3)

각각의 버퍼 풀에는 버퍼의 수와 LRU 래치의 수를 다르게 정의할 수 있다.

DB_BLOCK_LRU_LATCHS는 전체 인스턴스에 대한 LRU 래치의 총수이다.

KEEP, RECYCLE, DEFAULT 버퍼 풀에 정의한 총 버퍼 수는 DB_BLOCK_BUFFERS와 같다.

KEEP, RECYCLE, DEFAULT 버퍼 풀에 정의한 총 래치의 수는 DB_BLOCK_ LRU_LATCHES와 같다

하나의 래치는 최소 50개 이상의 블록을 관리한다.

전체 DB_BLOCK_BUFFERS 총계 중에서 KEEP, RECYCLE POOL에 각각 할당된 버퍼 수 외의 나머지 버퍼는 모두 DEFAULT POOL로 자동 할당된다.

Multiple Buffer Pool 설정

Multiple Buffer Pool의 설정은 CREATE, ALTER TABLE, INDEX, CLUSTER ....등의 형태로 오브젝트 Storage 절에 정의가 가능하며 Syntax는 다음과 같다.

BUFFER_POOL{KEEP|RECYCLE|DEFAULT}

CREATE INDEX cust_idx ...
     STORAGE (BUFFER_POOL KEEP ...) ;
ALTER TABLE customer
     STORAGE (BUFFER_POOL RECYCLE) ;
ALTER INDEX cust_name_idx
     REBUILD
     STORAGE (BUFFER_POOL KEEP ...) ;

버퍼 풀을 정의하지 않은 오브젝트들은 기본적으로 DEFAULT POOL을 사용하는 것이 원칙이며 ALTER 시 문장 실행 전에 버퍼 캐시에 올라와 있던 블록들은 기존 메모리 버퍼 풀에 그대로 유지되고 그 이후에 디스크로부터 다시 읽혀질 때 변경된 버퍼 풀에 유지된다.

버퍼 풀 가이드라인

- KEEP

SQL> ANALYZE TABLE codes ESTIMATE STATISTICS ;

Table analyzed
SQL> SELECT table_name, blocks
2       FROM dba_tables
3       WHERE owner = HR AND table_name = CODES ;

TABLE_NAME        BLOCKS
-------------     -------------
CODES                 14

액세스가 다양하고 빈번하게 이루어지는 핵심 오브젝트의 모든 또는 가능한 대부분의 블록들을 메모리에 상주시키는 영역이다. 따라서 현재 운영중인 업무의 성격과 액세스 형태 및 그 빈도에 대한 분석을 통해 대상 오브젝트들을 선정해야 하고 가용한 메모리 자원의 한계에 따라 적절한 수를 제한한다.

기본적으로 해당 세그먼트의 크기가 DEFAULT 버퍼 풀의 10% 이내인 것을 대상으로 하는 것이 원칙이나 절대적인 기준은 아니다.

일반적으로 액세스가 빈번한 코드성 오브젝트가 일차적인 고려의 대상이 될 수 있으며, 코드 성격은 아니라도 그에 준하는 빈도와 메모리 상주의 필요가 있을 때 KEEP 버퍼 풀 영역의 대상이 된다.

다음은 특정 오브젝트의 전체 블록 수를 알아보는 문장이다.

다시 말해 KEEP 영역의 대상 오브젝트들의 전체 블록의 수가 KEEP 버퍼 풀에 할당하는 버퍼의 수가 되며 그에 따른 적정한 래치 수를 설정해야 한다.

- RECYCLE

트랜잭션의 완료 후 해당 블록들을 메모리에서 즉시 제거하고자 하는 영역으로 재사용 빈도가 비교적 낮은 오브젝트들의 Active 블록들의 크기만큼 유지해야 한다. 따라서 현재 운영중인 업무의 성격과 액세스 형태 및 그 빈도에 대한 상세 분석을 통해 대상 오브젝트들을 선정해야 하고 가용한 메모리 자원의 한계에 따라 적절한 수를 제한한다.

기본적으로 해당 세그먼트의 크기가 다음과 같은 것을 대상으로 하는 것이 원칙이나 절대적인 기준은 아니다.

세그먼트 크기 > 2 * (DEFAULT BUFFER POOL)

SUM(BLOCKS) of Recycle Objects / 4

다음은 현재 메모리 버퍼 캐시에 상주하고 있는 오브젝트와 Active 블록의 총수를 알 수 있는 문장이다.

SQL> @catparr
...
SQL> SELECT owner#, name, count(*) blocks
   2 FROM v$cache
   3 GROUP BY owner#, name ;
OWNER#       NAME        BLOCKS
----------   ------------   --------
       5         CUSTOMER     147

다시 말해 RECYCLE 영역의 대상 오브젝트들의 Active 블록의 총계가 RECYCLE 버퍼 풀에 할당하는 버퍼의 수가 되며 그에 따른 적정한 래치 수를 설정해야 한다.

- 적중률(Hit Ratio)

각 버퍼 풀에 대한 적중률은 v$buffer_pool_statistics를 통해 확인할 수 있으며 v$buffer_pool_statistics 뷰가 존재하지 않을 때에는 관리자 권한의 사용자로 Oracle_Home/rdbms/admin/catperf.sql을 실행시키면 생성된다.

SELECT name,
              1 - (physical_reads / (db_block_gets +
                            consistent_gets)) HIT_RATIO
    FROM v$buffer_pool_statistics
    WHERE db_block_gets + consistent_gets > 0 ;

NAME                    HIT_RATIO
--------------------    -----------
KEEP                      .983520845
RECYCLE                  .503866235
DEFAULT                  .790350047

- Dictionary Views

아래에서 v$buffer_pool 뷰는 각 버퍼 풀에 할당된 버퍼 수와 래치 수를 보여주고 있다.

SQL> SELECT     *
2      FROM     v$buffer_pool
3      WHERE   id <> 0 ;

ID      NAME LO_SETID HI_SETID SET_COUNT BUFFERS LO_BNUM HI_BNUM
-- ------- --------- --------- ---------- -------- -------- --------
1        KEEP             3              3                   1       14000              0       13999
2 RECYCLE              4              6                   3        2000       14000        15999
3 DEFAULT               1              2                  2        4000        16000       19999

SET_COUNT는 각 버퍼 풀에 할당된 래치 수이고 LO_BNUM ~ HI_BNUM은 각 버퍼 풀에 설정된 버퍼의 범위를 가르킨다.

I/O 병목 해결을 위한 Multiple I/O Slaves

데이타베이스 버퍼 캐시의 수정된 블록을 데이타 파일에 기록하는 DBWR(Database Writer)는 특정 시점에 고효율의 일괄 기록을 수행하고 있는데, 새로운 버퍼 캐시의 확보를 원하는 서버 프로세스의 요구가 과다할 경우 DB Writer의 성능이 저하되므로 데이타 분석에 의해 필요하다고 판단될 때 다중 DBWR을 설정하고 있다.

Oracle7까지는 DB_WRITERS 패러미터를 이용하여 다중 DB Writer로 운영하도록 하였고 Oracle8 이상에서는 DB_WRITER_PROCESSES로 설정하며 최대 10개(DBW0 ~ DBW9)까지 지정할 수 있으나 불필요한 DB Writer의 다중 설정은 그 관리부담의 증가가 수반되므로 신중하게 고려해야 한다.

이러한 다중 DB Writer의 설정은 SMP(Multi-CPU) 시스템에서 매우 유용하지만, 하드웨어에서 제공하는 Asynchronous I/O 기능과 동시에 사용하지 못하며 Oracle8 이상부터 지원되는 Multiple I/O Slaves와의 동시 사용도 할 수 없다.

그러나 Nonblocking Asynchronous I/O 처리를 가능하게 하는 Multiple I/O Slaves는 I/O 성능 개선에 효과적인 기능을 제공함은 물론 하드웨어 플랫폼에서 제공하는 Async. I/O와의 병용이 가능하다.

적용 대상
Multiple I/O Slaves의 적용은 DBWR, LGWR, ARCH, BACKUP 프로세스들에 가능하며, 이 중에서 DBWR은 인스턴스가 시작할 때 지정된 수만큼 기동되고 LGWR, ARCH, BACKUP 등의 프로세스는 기본적으로 하나로 운영되다가 부하의 정도에 따라 필요한 시점에 자동적으로 추가되는 방식으로 관리된다.

Naming Rule은 ora_iNnn_<SID> 형식이다. 예를 들어 dbwr_io_slaves = 3으로 설정한다면 기동되는 프로세스는 ora_i101_SID, ora_i102_SID, ora_i103_SID으로 확인이 가능하다.

Initialization Parameters

I/O Slaves

DBWR, LGWR, ARCH, BACKUP 프로세스들의 I/O Slaves에 대한 전개 여부는 다음의 패러미터에 의해 필요시 다중으로 정의할 수 있다.

DBWR_IO_SLAVES
LGWR_IO_SLAVES
ARCH_IO_SLAVES
BACKUP_DISK_IO_SLAVES
BACKUP_TAPE_IO_SLAVES

특히 BACKUP_DISK_IO_SLAVES는 RMAN(Recovery Manager)에 의해 백업, 복구시 사용되는 I/O Slave의 수를 지정하는 것으로, RMAN 채널별로 개별적인 지정이 가능하다.

Asynchronous I/O

표준 Unix 특성으로 일반화되어 있는 AIO 기능은 하나의 프로세스가 동시에 다수의 디스크를 액세스하게 함으로써 디스크 I/O의 전체적인 생산성을 높이는 것이다.

하드웨어 플랫폼에서 제공하는 AIO의 채택 여부는 다음의 패러미터에 의해 정의된다.

DISK_ASYNCH_IO = TRUE or FALSE
TAPE_ASYNCH_IO = TRUE or FALSE

이러한 AIO 기능은 하드웨어 플랫폼에서 기능을 제공하지 못하거나 기본적으로 기능은 제공하지만, 버그 또는 이용시 효율적이지 못한 상황에서는 AIO 기능의 채택은 신중할 필요가 있다.

LGWR & ARCH I/O Slaves

LGWR_IO_SLAVES는 LGWR에 의해 사용되는 I/O Slave의 수이며 ARCH_IO_SLAVES는 ARCH에 의해 사용되는 I/O Slave의 수이다. 기본값은 0이고 I/O Slave는 사용하지 않는다. 다중으로 사용하고자 할 때에는 I/O시의 병목 현상 발생 가능성을 면밀하게 분석한 후 필요한 수를 설정한다.

특히 AIO를 지원하지 않거나 사용하기 어려운 상황에서의 채택시 유의해야 한다. |그림 2|

자원 경합을 해결하는 기능들

한정된 자원을 놓고 벌어지는 치열한 경쟁을 해결하기 위해 Oracle8/8i는 다양한 기능들을 제공하는데, 이를 Redo Log와 LRU Latch, Freelist 측면에서 살펴보자.

Redo Log 경합
Redo Log Space

LGWR(Log Writer)가 리두 로그 버퍼에서 디스크상의 리두 로그 파일로 리두 엔트리를 저장할 때 또 다른 사용자 프로세스들은 메모리상에 새로운 다수의 엔트리들을 생성하는데, 일반적으로 LGWR는 새로운 엔트리를 위한 버퍼상의 가용한 영역을 확보시키기에 충분한 속도로 엔트리들을 기록한다.

그러나 리두 로그 버퍼의 가용한 버퍼 영역이 부족하면 사용자 프로세스들은 대기 상태로 빠지며 이는 성능에 악영향을 끼칠 수 있다.
이 때 Performance View V$SYSSTAT를 통해 사용자 프로세스의 대기여부를 확인하고 대응하는 조치를 취할 수 있다.

SQL> SELECT name, value
2      FROM v$sysstat
3      WHERE NAME = redo buffer allocation retries ;

Redo buffer allocation retries는 사용자 프로세스가 가용한 버퍼 영역을 확보하기 위해 대기한 수를 나타내는데, 0에 가까운 수치를 반드시 유지하도록 해야 하며 이러한 대기 수치가 클 경우 LOG_BUFFER 패러미터의 값을 증가시킨다.

Note
   Multiple Archive Processes는 권장하지 않는다 하나의 독립적인 ARCH 프로세스가 LGWR 프로세스와의 연계 기능을 충분히 수행할 수 있으므로 다중 프로세스를 기동시킬 경우에는 매우 신중히 고려해야 한다.

Redo Log Latch

사용자 프로세스가 변경된 정보를 저장하기 위해 리두 로그 버퍼를 액세스할 때에는 다음 두 가지 형태의 래치 획득이 필수이다.

Redo Allocation Latch

Redo Allocation Latch는 리두 로그 버퍼 안에 리두 엔트리를 기록하기 위한 영역의 할당을 관리하는 래치로서 Oracle 사용자 프로세스가 버퍼내에 가용 영역을 할당받기 위해 반드시 획득해야 할 리두 로그 래치이다.

이 Redo Allocation Latch는 데이타베이스에 단 하나만이 존재하므로 특정 시점에 한 명의 사용자 프로세스만이 버퍼내에 가용 영역을 할당받을 수 있는 순차적인 방식의 관리가 불가피하다.

리두 엔트리를 위한 버퍼 영역을 할당받은 후 정해진 임계치보다 작은 리두 엔트리일 경우에 Redo Allocation Latch를 이용해 복사한다.

Redo Copy Latches

사실 사용자 프로세스가 생성한 로그 엔트리를 로그 버퍼에 복사하기 위해서는 먼저 Redo Copy Latch부터 획득해야 한다.

그런 후에 Redo Allocation Latch를 획득해 복사할 가용 영역을 확보하고 Redo Allocation Latch는 즉시 해제시킨다.

다음에 Copy Latches를 이용해 로그 엔트리를 로그 버퍼에 복사한 뒤 Copy Latches를 해제시키는 순서를 거친다.

이러한 Redo Allocation Latch와 Redo Copy Latches의 사용 여부는 패러미터 LOG_SIMULTANEOUS_COPIES의 설정값에 따라 달라진다.

LOG_SIMULTANEOUS_COPIES = 0인 경우

사용자 프로세스는 Redo Allocation Latch를 이용하여 로그 엔트리를 위한 버퍼 영역을 할당하고 복사 기능도 수행한다.

LOG_SIMULTANEOUS_COPIES > 0인 경우

사용자 프로세스는 Redo Allocation Latch를 이용하여 로그 엔트리를 위한 버퍼 영역만을 할당하고 지정된 수만큼의 Redo Copy Latches가 복사 기능을 수행한다. 이 경우에도 로그 엔트리가 임계치보다 작은 리두 엔트리일 경우에 Redo Allocation Latch를 이용해 복사한다.

- 리두 엔트리 임계치 = log_small_entry_max_size (Oracle8i까지)

= _log_small_entry_max_size (Oracle8i)

결론적으로 SMP 시스템에서는 리두 로그 엔트리 처리시 Redo Allocation Latch를 이용하여 로그 엔트리를 위한 버퍼 영역을 할당하는 역할만 수행하게 하고 복사 기능은 Redo Copy Latches에 분담시켜 자원 경합의 가능을 줄여야 성능 개선을 기대할 수 있다.

Redo Log Latch 가이드라인

SQL> select ln.name, misses, gets,
2 immediate_misses imdt_misses, immediate_gets imdt_gets,
sleeps
3 form v$latch l, v$latchname ln
4 where ln.name in (redo allocation, redo copy)
5 and ln.latch# = l.latch#
6 order by ln.name desc ;

NAME                    GETS MISSES IMMEDIATE_GETS IMMEDIATE_MISSES
--------------- ------- ------- --------------- ------------------
redo allocation    252867         83                            0                               0
redo copy                    0           0                     22830                               0

다음 문장의 결과 Misses나 Immediate_Misses의 비율이 항상 1%보다 작도록 유지한다.

그 비율이 1% 보다 클 경우 즉, Redo Log Latch에 경합이 발생하면 LOG_SMALL_ENTRY_MAX_SIZE의 크기를 줄여서 Copy Latch의 활용성을 높임과 동시에 LOG_SIMULTA NEOUS_ COPIES의 수를 증가(일반적으로 CPU*2)시켜 다중화함으로써 성능을 개선시킨다.

LRU Latch 경합
LRU Latch

데이타베이스 블록 버퍼는 System Sets으로 불리는 LRU Pair(LRU/LRUW)에 의해 관리된다. 다시 말해 모든 버퍼는 System Sets에 할당되어 있고 round-robin 방식으로 관리하며 LRU 래치를 획득해야 액세스가 가능하다.

LRU : Least Recently Used List
LRUW : LRU Write List = Dirty List

즉, LRU(Least Recently Used) 래치는 버퍼 캐시를 구성하는 모든 버퍼들의 운용을 관리하는 것으로, SMP에서 유용하며 일반적으로 CPU 수만큼의 값으로 설정한다.

LRU 래치의 수는 DB_BLOCK_LRU_LATCHES 패러미터로 설정이 가능하며 다음의 내용을 고려한다.

설정할 수 있는 범위 : 1~2*CPU
래치 하나당 최소 50버퍼 이상 할당
1CPU 시스템일 경우 다수의 래치 불필요
업무 부하가 큰 인스턴스의 운영시에 반드시 다수의 래치로 운영

실제로 SMP상에서 LRU 래치의 경합은 성능에 지대한 영향을 미치는 요소가 될 수 있으므로 V$LATCH, V$SYSTEM_EVENT, v$SESSION_EVENT 등의 뷰를 통해 경합의 여부와 정도를 분석한다.

관련된 뷰들인 V$LATCHNAME,
V$LATCH_CHILDREN, V$LATCH_MISSES 등을 통해 보다 세밀한 래치 현황을 확인할 수 있다.

Freelists & Freelist Groups 경합

Freelists & Freelist Groups

테이블의 헤더에는 그 테이블에 확보된 Extent 영역 중 사용자 요구시 할당이 가능한 Free Block에 대한 리스트가 기록 및 관리되는데, 그 리스트가 바로 Freelist이며 기본적으로 테이블에는 하나가 설정된다. 또한 그러한 Freelist는 다수로 설정할 수 있고 그것을 Freelist Group이라 부르며 이러한 Freelist Group도 관리자의 정의에 의해 다수로 설정할 수 있다.
Free Block을 필요로 하는 사용자의 작업요구(Insert 또는 길이가 늘어나는 Update 요구)가 동시에 발생되면 Oracle은 순차적으로 Free Block을 할당해줄 수밖에 없으므로 Freelist에 대한 경합이 유발되어 처리 성능에 영향을 미치는 것이 사실이다. 더구나 여러 인스턴스를 통해 다수의 사용자가 동시에 대상 테이블에 대해 위의 작업을 요구하면 상당한 성능 저하의 요인이 되므로 동시 사용자 수만큼의 Freelist와 Instance 수만큼의 Freelist Group은 반드시 정의해야 한다.
| 그림 3 |에서 Extent 1은 오브젝트 생성시 정의한 Initial Extent이며 Extent 6은 Extent 1~5의 영역내에서 가용한 Free Block을 할당할 수 없을 때 Oracle이 정의된 Next Extent 값에 의해 자동적으로 일으킨 Extent로서 이들은 공통적으로 사용하는 Master Free List에 기록된다.

SQL> create table table_name
            (aa varchar2(10) ..............)
            tablespace tablespace_name
            initrans 3
            storage ( initial 10m next 2m pctincrease 0
                           freelists 10 freelist groups 2

이와는 달리 Extent 2와 5는 인스턴스 X에 Extent 3과 4는 인스턴스 Y로 매핑되도록 정의되어 있고 Freelist Group이 다수로 정의되어 있으므로 각각의 그룹별로 서로 다른 Extent에 대한 Free Block List를 가지게 되어 인스턴스별로 물리적, 논리적인 분리가 보장될 수 있다.

결론적으로 보다 효과적인 운영을 위해 Extent를 특정 인스턴스에 귀속시킬 수 있으며 이러한 경우 하나의 테이블 데이타라도 인스턴스별 처리 대상 데이타는 물리적으로 완전히 독립적인 운영이 가능하므로 입/출력의 분산 및 인스턴스간의 경합이 최소화되어 성능 향상을 기대할 수 있다.