본문으로 바로가기

[Database] Re-Organization / Re-Build

category Back-end 2019. 3. 22. 11:49
1. Re-Organization
1.1 데이타 블록 관리
- 그림 1과 같은 형태로 채워진 세그먼트를 가정해 봅시다. 작업이 수행되면서 그림 2와 같이 일부 로우(row)가 삭제되고 나면 낭비되는 공간이 생기게 됩니다.


- 낭비되는 공간은 남아있는 블록의 마지막 영역과 기존 테이블의 마지막 영역의 사이에서, 그리고 로우가 부분적으로만 삭제된 블록 내부에서 발생합니다. 
- DB는 이 영역에 대한 할당을 바로 해제하지 않고, 새로운 insert 작업 및 기존 로우의 확장에 대비한 예비 공간으로 활용합니다. 지금까지의 점유되었던 공간의 최고점을 High Water Mark(HWM)이라 부릅니다


- 문제점 발생

- 사용자의 쿼리가 풀 테이블 스캔을 발생시키는 경우, DB는 HWM 아래쪽의 모든 영역을 스캔합니다. 이로 인해 풀 테이블 스캔에 소요되는 시간이 길어질 수 있습니다.

- 로우가 direct path 정보와 함께 insert 되는 경우 (예를 들어 APPEND 힌트를 사용한 Insert, 또는 SQL*Loader direct path를 통해 insert 되는 경우) 새로 추가 되는 데이타 블록은 HWM의 위쪽 영역에 추가됩니다. 

- 따라서 HWM의 아래쪽 영역은 낭비된 채로 남게 됩니다.


1.2 Re-Org ?

- 대상 Table의 Data를 Physical하게 재편성하여 DML 작업으로 인한 Fragmentation을 제거하는 작업 입니다.
- 테이블이 여러 번 수정되어 데이터가 분할되고 액세스 성능이 현저하게 느려지게 되면 REORG TABLE 명령이 최우선적인 튜닝 요소로 지적 됩니다.
- Reorg 명령은 조각난 데이터 및 인덱스를 조각나지 않은 실제로 연속된 페이지로 재 빌드 함으로써, 복잡하고 불필요하게 공간을 차지하고 있는 오브젝트(테이블 및 인덱스)들을 최적화 할 수 있으며, 이로 인해 액세스 되는 블록도 감소시켜 SQL 쿼리의 성능 향상도 어느 정도 꾀 할 수 있습니다.

1.3 Re-Org 필요성

- 운영중인 DB에 계속적인 Insert / Update / Delete 발생으로 인한 Fragmentation 발생하면, Chained Row가 발생하여 Disk I/O가 증가되며, 결과적으로 서비스 성능이 저하됩니다.
- 대량의 Data 삭제 후 실제 Table Data는 감소하였으나 Data High Water Mark가 기존 Table Size와 같으므로 Full Table Scan 등의 작업 성능이 저하됩니다.

2. Re-Build
2.1 Index ?

- 인덱스는 지정한 컬럼들을 기준으로 메모리 영역에 일종의 목차를 생성하는 것입니다. 
- insert, update, delete (Command)의 성능을 희생하고 대신 select (Query)의 성능을 향상시킵니다. 
- 여기서 주의하실 것은 update, delete 행위가 느린것이지, update, delete를 하기 위해 해당 데이터를 조회하는것은 인덱스가 있으면 빠르게 조회가 됩니다. 
- 인덱스의 갯수는 테이블 당 5 개 이하 정도가 적당합니다.



2.2 Re-Build가 필요한 상황

- 인덱스 정보 중 blevel(Branch Level)값은 인덱스 트리의 depth를 의미하고, leaf_blocks은 트리구조에서 최하위 레벨의 블럭 수를 나타냅니다. 중간의 블럭들은 leaf block을 찾아가기 위한 branch block이라고 합니다.
- 인덱스를 빨리 찾아가기 위해서는 blevel값이 작아야 합니다.




댓글을 달아 주세요

대마도사 블로그
블로그 이미지 대마도사 님의 블로그
MENU
VISITOR 오늘8 / 전체13,351