Oracle Database

Oracle Database의 Tablespace에 대한 여러 이야기 제1화

열린기술자·2016년 7월 15일·조회 5,968

이번 주에는 간단히 Tablespace에 대하여 정리해 볼까 한다. 실습은 없지만, 그렇다고 퍼온 글도 아니다. 모두 내가 한 땀 한 땀 타이핑한 내용이다.

Tablespace는 물리적인 존재인 Datafile을 하나 이상 모아 놓은 논리적인 저장 공간이라고 정리할 수 있다. 사용자는 테이블이나 인덱스 같은 객체를 Tablespace 단위로 배치하고 관리하지만, 실제 데이터는 그 Tablespace에 속한 Datafile에 저장된다.

Tablespace의 종류

1. SYSTEM Tablespace

Dictionary 정보, 즉 데이터베이스의 메타 정보가 저장되어 있다. 아주 중요한 정보이다.

  • Static Dictionary: 이름과 같이 실시간으로 내용을 바꿀 수 없는 Dictionary이다. DBA_xxx, ALL_xxx, USER_xxx 등이 이에 해당한다.
  • Dynamic Dictionary: 실시간으로 변경되는 내용을 볼 수 있다. v$xxx가 이에 해당한다.

운영 관점에서는 일반 사용자 테이블이나 인덱스를 SYSTEM Tablespace에 두지 않는 것이 좋다. SYSTEM은 데이터베이스의 핵심 메타 정보를 관리하는 공간이므로, 애플리케이션 데이터는 별도의 Tablespace를 만들어 분리하는 편이 안전하다.

2. SYSAUX Tablespace

10g부터 추가되었다. 성능 튜닝과 각종 데이터베이스 컴포넌트에서 사용하는 보조 데이터들이 저장되어 있다. 즉, 9i 이전에는 SYSTEM 혼자 이런 역할을 많이 담당했다고 생각하면 된다.

3. Undo Tablespace

DML 작업 시 변경 전 원본 데이터를 저장하는 Segment가 Undo Segment이다. 이 Undo Segment를 담고 있는 공간이 바로 Undo Tablespace이다. Undo 정보는 rollback, 읽기 일관성(read consistency), 장애 복구 등에 사용된다.

  • Undo Tablespace는 한 데이터베이스에 여러 개 만들 수 있지만, 일반적으로 한 인스턴스가 한 시점에 사용하는 Undo Tablespace는 하나이다.
  • 관리 방법에 따라 자동 모드(AUM, Automatic Undo Management)와 수동 모드가 있다.

예를 들어 어떤 사용자가 데이터를 수정했지만 아직 commit하지 않았다면, 다른 사용자는 Undo 정보를 이용해 변경 전의 일관된 데이터를 읽을 수 있다. 또한 rollback을 수행할 때도 이 Undo 정보가 필요하다.

4. Temporary Tablespace

임시 자료를 저장하는 Tablespace이다. 주로 정렬, 해시 작업, 인덱스 생성 등에서 메모리만으로 처리하기 어려운 중간 결과를 저장할 때 사용한다. 보통 sort 작업, 예를 들어 ORDER BY 처리 시 작업 영역이 부족하면 Temporary Tablespace를 사용한다. Sort Merge Join 같은 작업에서도 사용될 수 있다.

예전에는 sort_area_size 같은 파라미터로 정렬 영역을 설명하는 경우가 많았다. 이 영역은 공용 영역이 아니라 사용자 프로세스별 작업 영역이며, SGA 영역에 속하지 않는다. 최신 환경에서는 PGA 자동 관리 설정에 따라 정렬과 해시 작업에 사용할 메모리가 조정되는 경우가 많다.

아무튼 Temporary Tablespace를 사용한다는 것은 대체로 메모리만으로 처리하지 못하고 디스크 I/O가 발생했다는 의미이므로 성능이 느려질 수 있다. 다만 모든 Temporary Tablespace 사용이 문제라는 뜻은 아니고, 사용량이 비정상적으로 크거나 반복적으로 병목이 되는지 확인하는 것이 중요하다.

5. 기타 Tablespace

일반적인 사용자 Tablespace이다. 애플리케이션에서 사용하는 테이블, 인덱스, LOB 데이터 등을 목적에 맞게 분리해서 저장할 수 있다. 예를 들어 업무 데이터용 Tablespace와 인덱스용 Tablespace를 나누면 관리와 모니터링이 조금 더 편해진다.

Tablespace 관리 방식

1. DMT(Dictionary Managed Tablespace)

Extent 정보를 Dictionary Table에서 관리한다. 요즘 이 방식은 거의 사용하지 않는다.

2. LMT(Locally Managed Tablespace)

Datafile 헤더 부분의 bitmap 정보를 통해 extent 정보를 자체 관리한다. 따라서 성능이 좋다. 그 이유는 DMT에 비해 Dictionary Contention이 적기 때문이다. Tablespace 생성 시 EXTENT MANAGEMENT LOCAL 절을 사용한다.

만약 ASSM(Automatic Segment Space Management) 기능을 사용하려면 반드시 LMT 방식이어야 한다. Tablespace 생성 시 SEGMENT SPACE MANAGEMENT AUTO 절을 사용한다. 참고로 ASSM을 사용하면 Segment 내부의 빈 공간 관리를 자동화할 수 있으며, PCTUSED, FREELISTS, FREELIST GROUPS 같은 골치 아픈 옵션을 신경 쓰지 않아도 된다.

간단히 확인해 볼 만한 Dictionary View

실습을 길게 하지는 않더라도, 아래와 같은 Dictionary View를 조회하면 현재 데이터베이스의 Tablespace 구성을 확인할 수 있다.

  • DBA_TABLESPACES: Tablespace의 종류와 관리 방식 등을 확인할 수 있다.
  • DBA_DATA_FILES: 일반 Tablespace에 연결된 Datafile 정보를 확인할 수 있다.
  • DBA_TEMP_FILES: Temporary Tablespace에 연결된 Tempfile 정보를 확인할 수 있다.
  • DBA_FREE_SPACE: Tablespace의 여유 공간을 확인할 때 사용한다.

정리하면, Tablespace는 논리적인 저장 공간이고 Datafile은 실제 물리 파일이다. SYSTEM, SYSAUX, Undo, Temporary, 사용자 Tablespace가 각각 어떤 역할을 하는지 구분해 두면 Oracle 저장 구조를 이해하기가 훨씬 쉬워진다.

댓글 4

로그인 후 댓글을 남길 수 있습니다.

  • · 2016년 7월 15일
    관리 테크닉중 하나인데 TEMP tablespace가 유저에게 부여되잖아요. 혹시 개인계정들과 운영계정들간에 TEMP에 대한 경합을 없애고자 하는 경우 TEMP tablespace를 각각 만들고 운영용, 개인용 이렇게 용도를 부여한 후 각각 TEMP tablespace를 지정해준답니다.
  • 열린기술자열린기술자· 2016년 7월 15일
    우와 앤님의 꿀팁 고맙습니다! 그런데 개인용으로 나눈다는 것은 개인계정 별로 다 분리를 하는 것이 좋을까요?
  • durecatdurecat· 2016년 7월 15일
    정리 감사합니다. ㅎㅎ 제 생각에 개인 계정 별로 다 분리 하면 TEMP 를 너무 많이 만들어야 할 것같습니다. 운영용, 개인용 정도면 괜찮을 것 같아요. 덧 붙여서 RAC 환경의 경우 ST 관련 이벤트가 너무 많이 발생하면 노드별로 TEMP를 따로 만들어 주는 것도 괜찮은 방법입니다.
  • · 2016년 7월 15일
    네 맞습니다. 두레캣님이 잘 정리해주셨어요~