Freelist Tuning(Freelist의 contention 확인 방법)
==================================================


PURPOSE
---------
Freelist Tuning은 Process Freelist 와 Freelist Group의 contention을 최소화하기 위한 것이다.


Explanation
-----------
1. Freelist의 종류(Bul. 11101)
: Freelist는 master freelist, process freelist, transaction freelist가 있다.

(1) Master freelist: Oracle의 내부 메커니즘에 의해 자동으로 생성되며
모든 process가 access할 수 있고 commit된 transaction에 의해
transaction freelist의 free block을 포함한다.

(2) Process freelist: Create시에 storage option에 freelist 설정시 생성되는 freelist로
process는 자신에게 할당되어 있는 process freelist에 대해서만 사용 가능하다.
master freelist 와 마찬가지로 committed free blicks을 포함하며,
동시작업이 많은 환경에서 master freelist의 header의 contention을
줄이위한 목적으로 사용된다.(8.1.6 이상 부터는 alter command로 freelist 변경이 가능하다.)

(3) Transaction freelist: 모든 transaction에게 할당되는 freelist로
하나의 segment에 최소한 16개의 transaction free list가 있으며,
블럭이 찰 때까지 필요에 따라 증가된다.
transaction내의 update/delete작업에 의해 free된 블럭을 포함하며,
current(active) transaction 만이 자신의 freelist를 사용하게 된다.
transaction이 commit이 되면, transaction freelist에 있던 block은
master나 process freelist로 옮겨진다.


2. Process freelist contention
: Single intance에서 한개의 master freelist만을 사용하게 될 경우
freelist contention이 발생될 수 있다.
그러므로 object생성시에 여러개의 process freelist를 사용하도록
freelist를 설정하게 되면 한 table에 대해 동시에 free block를 찾게 됨으로써
발생하는 contention을 줄일 수 있다.

: Freelist를 효과적으로 이용하려면 oracle에 의해
extent가 자동으로 allocation되는것을 최소화하고
extent를 object 생성시에 정의를 하는 것이 좋다.
이유는 table에 자동으로 extent가 할당되는 경우 master pool(common pool)에
block을 추가하게 되므로 contention을 야기시킬 수 있다.


3. Freelist group contention
: OPS환경에서 instance간의 freelist contention을 줄이기 위해 freelist group를
설정할 수 있다. group의 수는 OPS의 node수와 동일하게 설정하는것이 일반적이다.


4. Freelist Tuning Parameter
1) PCTUSED
2) PCTFREE
3) Process freelist
4) Fresslist group


5. Freelist contention 확인 방법
: v$waitstat와 v$system_event에서 buffer busy wait event를 찾고
v$session_wait에서 waiting중인 session의 file#, block# 를 통해
object name과 freelist 갯수를 알아낸다.

1) v$waitstat 에서 data block, segment header value가 높고
v$system_event에서 buffer busy waits 에서 total_wait, total_time이 높으면
freelist contention 을 의심해 보아야 한다.

SVRMGR> select * from v$waitstat;
SVRMGR> select * from v$system_Event;

2) v$session_wait에서 buffer busy waits 에서
대기중인 session의 P1(file#), P2(block#), P3(id)를 찾아
object name과 freelist 갯수를 찾는다.

SVRMGR> select * from v$session_Wait;
SVRMGR> select segment_name, segment_type
from dba_extents
where file_id=file#
and block between id and id + block#;

위에서 확인한 segment_name과 segment_type을 이용하여
freelist 갯수를 확인한다.

SVRMGR> select segment_name, freelists
from dba_segments
where segment_name=segment
and segment_type=type;

3) Freelist tuning
: Freelist 의 default 갯수는 1이고 적절한 갯수는 동시에 동일한 table(index, cluster...)에
insert를 할 수 있는 process의 갯수로 지정하는것이 적당하다.
일반적으로 CPU 수 만큼 설정하면 충분하다.


6. 그외 event
(1) select * From v$waitstat; 에서 buffer busy wait 인 class가 data block일 경우
Solution) pctfree/pctused를 바꾸거나 DB_BLOCK_SIZE를 줄여서 block당 rows수를 줄인다.

(2) select * From v$waitstat; 에서 class가 segment header일 경우
Solution) freelists를 사용하시거나 freelists의 수를 늘려준다.
table이 정기적으로 커지는 경우 너무 작은 extent size는 header에 contention을 일으킬수 있다.
이럴경우 table의 extent size를 늘려 주시는 것을 고려해 보아야 한다.

(3) select * From v$waitstat; 에서 class가 undo header일 경우
Solution) rollback segment당 transaction수를 줄이기 위해서
rollback segments 를 더 추가한다.

(4) select * From v$waitstat; 에서 class가 undo block일경우
Solution) exclusive mode에서 rollback segments를 더 크게 만들어야 한다.


출처 : otn