반응형

pctfree 

 

 a) 수정 시 늘어나는 데이타를 수용하기 위한 공간이다.     

 b) 디풀트는 10이나 빈번히 수정이 되면서 null 이었다가 데이타가 채워지는 경우는 

   이 값을 약 20 혹은 30 까지 크게 설정한다.  

PCTFREE(20%) : 블록은 80% 찰때까지 행을 삽입할수 있고 20%는 기존 행 갱신할경우를 위해
빈영역으로 남겨둔다. default 10%

 

pctused 

 

재사용되기 위해 필요한 블럭의 사용량을 설정한다.디폴트는 60이나 입력,

삭제가 자주 발생하지 않는 경우는 90 정도로 큰 값을 설정하고,

수정작업이 자주 발생하면서 로우 사이즈가 증가할 때에는 40 정도로 낮은 값을 설정한다.

PCTUSED(60%) : 사용된 영역이 40%보다 작아져야 새로운 행을 삽입할수 있다.

 

freelist 

 

 a) insert 작업 시 미리 사용 가능한 블럭을 리스트하고 있다가 할당하는 곳이다.     

 b) insert 작업이 많이 발생하는 테이블이나 인덱스에서는 이 값을 증가시켜 빈 블럭을 

   할당 받기 위해 대기하는 일이 없도록 한다.

 

freelists 와 Free List Group(OPS에서만 사용됨)은

주로 OPS에서 쓰여집니다.

늘리는 것은 결과치가 1%이하나 적당한 값이 나올때까지 허용하는 한도내에서 조금씩 늘립니다.

 

그럼 이제부터 쉽게 설명해 보겠습니다.

 

PCTUSED, PCTFREE 모두 Block에 대해서 지정하는 옵션 파라미터입니다.
오라클 데이타 입출력의 최소 단위는 Block인 것은 알고 계시리라 생각합니다.
PCTFREE는 update로 인해 기존 row가 커질 경우를 대비해서 예약해두는 공간입니다.
주로 varchar2 같이 가변 길이 자료형의 경우 업데이트를 통해서 row가 커질 수 있습니다. 그래서 update로 인해 자료 사이즈가 커질 수 있는 경우에는 pctfree를 크게 주라고 이야기합니다. 너무 크게 주면 한 블록에 들어갈 수 있는 row 수가 적어지므로 비효율적이겠지요.

비유를 해볼까요? 우리가 술잔에 술을 따를 때 넘치게 따르지 않습니다. 어느 정도 여유를 두고 따르죠.
그리고 애기들 옷살 때도 몸에 꼭맞는걸 사는게 아니라 약간 큰걸 사죠. 그래야... 애기가 커서도 입을 수 있으니까요. 

PCTUSED는 데이타를 삭제했을 경우에 필요한 파라미터입니다.
PCTFREE가 10%인 블록에 row를 계속해서 insert 해서 90%까지 차게되면 이 블록은 더 이상 insert를 하지 않고 다음 블록으로 넘어가게 됩니다. 그렇다면 다시 블록에 row를 delete로 삭제하면, 이 블록이 바로 재활용이 될까요? 아닙니다. 언제 다시 Freelist로 등록되어서 다음 insert 시 사용될 수 있을지를 지정하는 것이 pctused입니다.

말이 어려운 것 같아도 비유를 해봅시다.
앞서 비유와 같이 술잔을 10% 남겨두고 90%까지 채웠습니다. 
(PCTFREE 10%)
그런데 같이 술마시던 친구가 40%를 남겨두고 한모금에 마셨습니다.
그럼 한잔을 더 따라줘야 해야할까요? 말아야할까요?
어느 시점에서 술을 더 따라줘야할지 정해주는게 PCTUSED입니다.
PCTUSED가 40%라면 40% 이하로 친구가 술잔을 비우면 더 따라줘야합니다. (즉, Block을 delete 해서 사용량이 40% 이하로 내려갔을 때...)
한국 사람은 이 수위가 더 낮지요. 첨잔을 금기시하는 음주 문화라... ^^;
한국 사람의 경우 PCTUSED가 10%쯤 될까요? 거의 바닥이 보이게 되면 그제서야 "친구 한잔 더 받게"하면서 따라주죠.

그럼 Freelist는 뭘까요?
위에선 2명이서 마셨지만... 이제 동창회 모임이라서 20명이 한꺼번에 마십니다. 기억력이 나쁜 저는 어느 친구의 잔이 비었는지 목록이 필요해집니다. 즉, insert 의후보로 쓰일 수 있는 가용한 Block의 목록을 가지고 있는게 freelist입니다. 
pctused 이하로 술잔이 비워진 친구들의 목록을 기록해두는 장부라고 해두죠.
마지막으로 freelist에 가용한 블록이 전혀 없다면 어떻게 될까요?
그러면 extents를 추가로 더 할당받아야하겠죠. 그리고 다른 새로운 블록을 할당받아야합니다. HWM(High Water Mark)도 올라가겠지요.

그럼 PCTUSED와 PCTFREE 설정의 기준을 간략히 말하자면..


1. 오로지 insert만 되는 테이블 :  이 경우에는 PCTFREE를 아주 낮게 설정하는게 한 블록을 꽉꽉 채울 수 있으므로 더 효율적이겠지요.
전혀 업데이트가 없다면 PCTFREE 0%도 가능합니다.

2. insert와 delete가 반복되는 테이블 : 위에서는 insert만 이루어졌지만 이번에는 delete 가 됩니다. 그러면 pctfree  도 낮게 설정되어야하겠지만 pctused도 낮게 설정하는게 좋습니다.
pctused가 높다는 이야기는 블록의 데이타가 조금만 delete되어도 바로 freelist에 등록되어서 다음 insert의 후보로 사용된다는 이야기고...
왔다갔다하는 빈도수가 잦아지므로 좋지 않습니다. 

3. update 로 인해 row가 커질 수 있는 경우 : 위에서 언급한 바와 같이 pctfree를 Row migration이 안생기는 수준까지 키워주는게 좋습니다.

PCTUSED가 Delete로 인해서 40% 이하로 떨어지면 Freelist에 등록이 됩니다. 즉, 이 블록은 이제 재사용해도 좋다라는 허가가 떨어집니다.
이제 insert를 하면 다시 PCTFREE 10%를 남겨놓고 90%까지는 insert가 가능해집니다.

9i부터는 ASSM(Automatic Segment Space Management) 기능을 통해서 PCTUSED와 FREELIST를 없앴습니다.
(물론 이전처럼 사용하실 수도 있습니다만...)
어쨌거나 ASSM에서는 빈블록의 목록을 Freelist가 가지고 있는게 아니라... 세그먼트의 처음 3블록이 bitmap으로 가지고 있습니다.
즉, freelist를 일일이 뒤져보지 않아도 bitmap만 보면 그 블록이 얼마나  찼는지 알 수가 있습니다.
그래서 ASSM기능을 사용할 경우 PCTUSED와 Freelist는 사용하실 수가 없으며 PCTFREE만 DBA가 지정해주면 됩니다.
freelist를 뒤지는건 순차적인 작업이므로 동시에 DML 되는게 많다면 상당한 오버헤드였거든요.
특히 다수의 노드가 하나의 스토리지를 바라다보는 RAC 클러스터 같은 환경에선 ASSM이 Manual 에 비해서 35% 정도 빠르다는 오라클 내부 벤치마크 결과가 있습니다.
저는 ASSM을 권장하는 편입니다. Freelist, pctused를 제대로 설정한다는건 경험많은 DBA에게도 쉽지 않은 일이고... freelist를 뒤지는 오버헤드도 무시할 수가 없기 때문입니다.
ASSM 기능을 사용하시려면 9iR2 버젼에 9.2.0.4 이상의 패치셋을 반드시 적용하신 후 사용하시기 바랍니다.
(LOB Type 의 경우 corruption 문제가 있고 bitmap index관련해서도 버그가 리포트 되었습니다.)



반응형

+ Recent posts