http://blog.naver.com/zoom7810/50028001703
1. 오라클 데이터 구조
1) 데이터 구조 관계
☞ Tablespace
- 데이터 1개 이상의 데이터 파일을 이용하여 생성
- 하부의 논리적인 구조로 1개 이상의 세그먼트로 구성
☞ Segment
- 테이블세그먼트, 인덱스 세그먼트, 언두 세그먼트, 롤백 세그먼트, 템포러리 세그먼트 등
- 사용자가 하나의 테이블을 생성하는 것은 하나의 테이블 세그먼트를 만드는 것과 동일
- 테이블이나 인덱스는 세그먼트의 한 종류
- 세그먼트는 하나 이상의 익스텐트로(Extent)로 구성되며 하나의 Extent는 연속적으로 할당된
공간을 의미
- 모든 Segment 는 적어도 하나의 Extent 를 가지며 Rollback Segment의 경우엔 최소 2개의
Extent를 요구
☞ Extent
- 일정한 수의 연속된 Oracle Block 들
- 일정한 수라는 의미는 사용자가 지정한 값
(예)CREATE TABLE 문장에서 STORAGE OPTION중 INITIAL_EXTENT를 10K로 지정하면
DB_BLOCK_SIZE가 2K 일 경우 5Block 이 됨.
즉, 5개의 Oracle Block 이 하나의 Extent로 구성됨을 의미
☞ Oracle Block(=Data Block)
- Data Block 은 Logical Block, Oracle Block 또는 page라는 용어로 불림
- Oracle Block size는 OS Block 의 N배수로 이루어진다
- Database가 생성될 때 지정된 Oracle Block 은 다시 변경이 불가능 하다
- SGA의 Database Buffer에 I/O가 일어나는 기본단위가 된다
- init.ora file의 DB_BLOCK_SIZE로 지정한다
2) DMT(Dictionary-Managed TableSpace)와
LMT(Locally Managed TableSpace)
(1) DMT(Dictionary-Managed TableSpace)
- 오라클 8.1.5 이전에는 TableSpace에서 Extent 할당을 관리하는 방법을 오직 딕셔너리로
관리되는 TableSpace만 존재
- 하나의 테이블스페이스에 속하는 공간은 데이터 딕셔너리 테이블에서 관리
- 이 방법은 새로운 Extent 의 할당이 필요한 시점에 오라클은 Data Dictionary Table에
질의를 하여 어느 extent 가 할당 가능한지 파악 후 이를 할당하는 기법
- 이 가용공간을 얻기위해 실행하는 연산은 Recursive SQL로 매우 비싼 연산
==> 자원에 대한 많은 경합이 발생
==> 딕셔너리에 대한 Free Space 확인이 있어야 하므로 Slow Operation의 특징
==> PCTFREE, PCTUSED, PCTINCREASE, FREELIST와 같은 저장 파라미터를 이용하여
segment space에 일일이 관리
(2) LMT(Locally Managed TableSpace)
- 데이터 딕셔너리 테이블에 의한 관리 대신에 지역적으로 관리되는 지역공간 관리방법 도입
- 딕셔너리 관리로 생기는 오버헤드를 줄인 방법
- 각 데이터 파일에 저장되는 비트맵이 Extent 를 관리하는데 사용
- 하나의 Extent를 얻기 위해 해야 할일은 단지 비트냄의 한 비트를 '1' 로 Setting 하면 되는
것이며 빈 공간은 반대로 '0' 으로 Setting 하면 됩니다.
- Oracle 9i에서 기본적으로 TableSpace관리방법
- 수행 속도 면에서 딕셔너리르 통한 방법보다 훨씬 뛰어남
- autoallocate 문을 통해 extent 를 자동으로 할당 할 수 있으며 segment 의 경우
segment space management auto 옵션으로 세그먼트 관리를 자동으로 할 수 있고,
FreeSpace에 대한 colaesce(합치는 것) 이 불필요함
[LMT의 특징 참고]
+ 공간 정보 관리를 위한 내부 작업이 감소한다
+ 데이터 딕셔너리 테이블에 대한 경합이 감소된다.
+ 익스텐트 관리와 관련된 관련 rollback 생성이 되지 않는다.
+ Tablespace에 대한 주기적인 coalesce작업을 하지 않아도 된다. 이것은 해당 테이블
스페이스내의 모든 Extent에 대한 정보를 Bit로 표현하기 때문에 가능하다.
+ 해당 테이블스페이스 내의 모든 Extent 는 동일한 크기의 Extent를 할당하게 된다
(3) ASSM(Automatic Segment Space Management) 의 기능
- 세그먼트 내의 영역 관리를 자동으로 처리
- Oracle 9i 이전에는 FREELISTS, FREELIST GROUP, PCTUSED 같은 세그먼트 속성들이
수동으로 구성되어야 했는데 ASSM을 사용하면 수동구성이나 재구성 작업을 할 필요가 없음
- ASSM은 각 데이터 블록내의 사용량 관리를 위해 FREESISTS 를 사용하는 대신
비트맵FREELIST를 사용함으로써 세그먼트내의 영역관리를 투명하게 만들어 주기 때문
- ASSM은 데이터 블록의 영역 사용을 향상
- 가변적인 크기를 가진 행과 함께 세그먼트를 위해 사용가능한 영역의 보다 나은 재사용
- ASSM을 사용하면 비트맵의 다른 부분이 사용가능 영역 참조를 위한 직렬화를 없애주며
동시에 사용될 수 있으므로 현재의 DML 처리 성능을 대폭 향상
2. ASSM(Automatic Segment Space Management)
1) Freelist 와 Bitmap Freelist
(1) Freelist
오라클 8i까지의 버전에서 segment 의 free block 들은 항상 freelist를 통해 관리 되었습니다.
block 들이 freelist로 연결되어있어 insert 가 필요하면 이 freelist를 segment header 에서부터
뒤지면서 블럭내에 빈공에 insert 하게 된다. 또한 freelist내의 free block에 대한 정보가
segment header 내에 정보를 저장하고 있는 것이 아니라 linked list 형태로 free block 이
다음 free block 을 지정하는 혀태라 쉽게 freelist에 대한 정보를 확인 하는 것도 불가능 했다. 
* MFL(Master Free List)
* HDR(Segment Header)
* HWM(High-Water Mark)
- Multiple-Freelist는 다량의 트랜잭션이 한곳에 집중될 때 기존보다 성능이 항샹
(2) Bitmap Freelist
- 테이블스페이스가 반드시 LMT 방식이어야 함
- 블럭헤더에 다음과 같은 4 비트정보를 포함하고 있음
(3) Multiple-Freelist 와 Bitmap-Freelist
- 여러개의 DML문이 하나의 세그먼트에서 발생한다면 먼저 메모리에 존재하는 데이터를 버퍼에 쓰
- 버퍼 영역에 있는 내용을 세그먼트에 쓰기 위해 해당 세그먼트의 FreeList를 검색하여 빈 데이터
블록에 쓴다
- FreeList가 점유되어 데이터를 쓰고 있는동안 다른 DML문은 대기하게 되는데 이를
buffer-busy-wait 라고 한다
- Bitmap-freelist 의 경우에는 freelist 자체가 각각의 블록내에 존재하기 때문에 이러한
buffer-busy-wait현상은 전혀 없음
[참고]
buffer-busy-wait 현상이란 freelist가 점유되어 데이터가 쓰여지는 동안 다른 트랜잭션에서는
버퍼에서 세그먼트 블록으로 데이터를 옮기지 못하고 기다리게 되는 현상
2) Online Segment Shrink(자동 세그먼트 정리)
(1) 기존의 세그먼트 관리
- Online Shrink 는 Oracle 10g에서 새로 도입된 기능
- 빈번한 삽입 및 삭제 DML활동을 겪는 세그먼트들은 내부적으로 단편화(fragmented) 되고
데이터 블록내를 사용 불가능한 영역을 만듬
- 이러한 데이터 낭비 현상을 방지 하기 위해 테이블 무브나 리오그 작업을 통하여 블럭 단편화
현상을 없애야 함
(2) Online Segment Shrink
- 낭비된 영역을 가진 세그먼트들은 수축을 통해 영역 회수 가능
- 세그먼트 수축기능이란?
+ 낭비된 영역을 채우기 위해 행 조각들을 이동시키는 작업
+ 가능한 곳이면 어디든지 행 체인화를 없애주므로 해당 세그먼트에 대한 읽기 처리시의 성능향상
+ 수축 처리가 시행되는 동안 세그먼트 상의 활동이 계속될 수 있으며, 임시 데이터를 저장하기
위해서 추가적인 영역 불필요
☞ [예] Shrink 수행
☞ [예] High Water Mark 의 이동
3. ASSM의 예측기능
1) 인덱스 크기 예측
(1) BMS 패키지의 create_index_cost 함수 이용
- 다음의 PL/SQL 문을 실행시키면 인덱스 크기를 예측 할 수 있다
declare
l_used_bytes number;
l_alloc_bytes number;
begin
dbms_space.create_index_cost(
'create index idx_my_test01 on MY_TEST' || '(my_id, my_name) tablespace users',
l_used_bytes,
l_alloc_bytes
);
dbms_output.put_line('Used Bytes =' || l_used_bytes);
dbms_output.put_line('Allocated Bytes =' || l_alloc_bytes);
/
==>결과
Used Bytes = 8602126
Allocated Bytes = 14562223
(2) 인덱스 크기를 예측하기 위한 조건
- Segment Space Management 값이 Auto로 설정
+ sql문을 통해 헌재 자신이 생성한 테이블스페이스의 segment space management 의 값을
확인할 수 있다.
SQL> select tablespace_name, segment_space_management from dba_tablespace;
- 인덱스를 생성할 테이블에 대한 통계정보 생성
+ 마찬가지로 DBMS패키지의 gather_table_stats 함수를 사용하면 최신의 통계정보로
업데이트 됩니다.
SQL> exec dbms_stats.gather_table_stats('테이블 owner','테이블명');
2) 테이블 크기 예측
(1) create_table_cost 함수를 이용
- 다음의 PL/SQL 문을 실행시키면 테이블 크기를 예측 할 수 있다
declare
l_used_bytes number;
l_alloc_bytes number;
begin
dbms_space.create_table_cost(
'USERS, //테이블스페이스명
50, //1개의 row의 총합. 각 컬럼들의 바이트 총합
1000, //삽입될 row 의 개수
l_used_bytes,
l_alloc_bytes
);
dbms_output.put_line('Used Bytes =' || l_used_bytes);
dbms_output.put_line('Allocated Bytes =' || l_alloc_bytes);
/
==>결과
Used Bytes = 531264
Allocated Bytes = 89028
(3) 세그먼트 크기 예측
- 세그먼트 예측이 중요한 이유
+ 테이블이나 인덱스가 앞으로 어떠한 증가 추이를 보이는지 히스토리 테이터를 토대로
예상함으로써 스토리지 관리를 보다 계획적으로 관리 할 수 있기 때문
+ 사용함후 : DBMS_SPACE 패키지의 OBJECT_GROWTH_THREND 함수를 통해 예상
+ OBJECT_GROWTH_THREND 함수는 AWR(Automatic Workload Repository) 에 의해
수집된 통계정보를 바탕으로 세그먼트의 크기를 계산
- 조회
select * from table(dbms_space.OBJECT_GROWTH_TREND('테이블스페이스명','테이블명'));
[출처] [오라클10g] 세그먼트 관리|작성자 모카빵
'wif LiNoUz > Oracle,Sql' 카테고리의 다른 글
| INDEX_SKIP 예제 (0) | 2015.05.26 |
|---|---|
| INDEX_SKIP 예제 (0) | 2015.05.26 |
| [DB 성능관리 2% 채우기] ③ 프로그래밍 통한 성능개선 사례 (0) | 2015.01.23 |
| [DB 성능관리 2% 채우기] ① 자동화 툴의 한계 (0) | 2015.01.23 |
| [DB 성능관리 2% 채우기] ② 테이블 파티셔닝의 재발견 (0) | 2015.01.23 |