테이블 스페이스는 크게 두 가지 구성으로 Tibero의 데이터를 저장한다.

테이블 스페이스의 논리적 구성

다음은 테이블 스페이스의 논리적 구성을 나타내는 그림이다.

[그림 3.1] 테이블 스페이스의 논리적 구성

테이블 스페이스는 [그림 3.1]과 같이 세그먼트(Segment), 익스텐트(Extent), 데이터 블록(Block)으로 구성된다.

테이블 스페이스의 물리적 구성

다음은 테이블 스페이스의 물리적 구성을 나타내는 그림이다.

[그림 3.2] 테이블 스페이스의 물리적 구성

테이블 스페이스는 [그림 3.2]와 같이 물리적으로 여러 개의 데이터 파일로 구성된다. Tibero는 데이터 파일 외에도 컨트롤 파일과 로그 파일을 이용하여 데이터를 저장할 수 있다.

빈번하게 사용되는 두 테이블 스페이스(예: 테이블과 인덱스)는 물리적으로 서로 다른 디스크에 저장하는 것이 좋다. 왜냐하면 한 테이블 스페이스를 액세스하는 동안에 디스크의 헤드가 그 테이블 스페이스에 고정되어 있기 때문에 다른 테이블 스페이스를 액세스할 수 없다.

따라서 서로 다른 디스크에 각각의 테이블 스페이스를 저장하여 동시에 액세스하는 것이 데이터베이스 성능을 향상시키는 데 도움이 된다.

테이블 스페이스는 생성되는 유형에 따라 시스템 테이블 스페이스(System Tablespace)와 비시스템 테이블 스페이스(Non System Tablespace)로 구분된다.

시스템 테이블 스페이스는 데이터베이스가 생성될 때 자동으로 생성되는 테이블 스페이스이며, 비시스템 테이블 스페이스는 일반 사용자가 생성한 테이블 스페이스이다.

본 절에서는 비시스템 테이블 스페이스를 생성하고 제거하는 방법을 설명한다.

테이블 스페이스의 생성

테이블 스페이스를 생성하기 위해서는 CREATE TABLESPACE 문을 사용해야 한다. 테이블 스페이스의 이름, 테이블 스페이스에 포함되는 데이터 파일과 데이터 파일의 크기, 익스텐트의 크기 등을 설정할 수 있다.

다음은 하나의 데이터 파일 my_file.dtf로 구성되는 테이블 스페이스 my_space를 생성하는 예이다.

CREATE TABLESPACE my_space
    DATAFILE '/usr/tibero/dtf/my_file.dtf' SIZE 50M
    EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K; 

데이터 파일 my_file.dtf는 SQL 문장을 실행함과 동시에 생성된다. 만약 동일한 이름의 파일이 이미 사용 중이라면, 에러를 반환하게 된다. 데이터 파일 my_file.dtf의 크기는 50MB이며, 테이블 스페이스의 크기도 50MB가 된다.

Tibero에서는 하나의 테이블 스페이스 내의 모든 익스텐트의 크기를 항상 일정하게 관리한다. 예를 들어 하나의 익스텐트의 크기가 256KB이고, 데이터 블록의 크기가 4KB라고 한다면 하나의 익스텐트에는 총 64개의 데이터 블록이 포함된다. 또한 하나의 테이블 스페이스를 두 개 이상의 데이터 파일로 구성할 수도 있다.

예를 들면 다음과 같다.

CREATE TABLESPACE my_space2
    DATAFILE '/usr/tibero/dtf/my_file21.dtf' SIZE 20M,   ... ① ...
             '/usr/tibero/dtf/my_file22.dtf' SIZE 30M    ... ② ...
    EXTENT MANAGEMENT LOCAL UNIFORM SIZE 64K;            ... ③ ...

① 20MB 크기의 데이터 파일 my_file21.dtf를 정의한다.

② 30MB 크기의 데이터 파일 my_file22.dtf를 정의한다. 테이블 스페이스 my_space2의 전체 크기는 총 50MB가 된다.

③ 테이블 스페이스 my_space2는 하나의 익스텐트의 크기를 64KB로 설정한다.

하나의 테이블 스페이스에 포함되는 데이터 파일의 개수는 데이터베이스와 시스템 환경에 따라 달라진다. 하나의 테이블 스페이스에 많은 데이터가 저장되면 여러 개의 데이터 파일로 테이블 스페이스를 생성해야 한다. 단, 운영체제에 따라 동시에 처리할 수 있는 데이터 파일의 최대 개수가 달라질 수 있으므로 범위 내에서 데이터 파일의 개수를 조정해야 한다.

데이터 파일의 크기는 데이터베이스의 크기를 추정하여 설정해야 한다. 테이블 스페이스를 생성할 때 설정된 크기보다 더 많은 공간이 필요할 것에 대비하여 데이터 파일의 크기가 자동으로 확장되도록 설정할 수도 있다.

다음은 CREATE TABLESPACE 문의 DATAFILE 절에 AUTOEXTEND 절을 추가하고 저장 공간이 더 필요할 것에 대비하여 1MB씩 확장하도록 설정하는 예이다.

CREATE TABLESPACE my_space
    DATAFILE '/usr/tibero/dtf/my_file.dtf' SIZE 50M
    AUTOEXTEND ON NEXT 1M
    EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K;

Tibero에서는 데이터 블록을 할당한 정보를 테이블 스페이스에 비트맵 형태로 저장한다. 따라서 테이블 스페이스 내의 익스텐트의 최대 개수는 "테이블 스페이스의 크기 / 익스텐트의 크기"보다 작은 값이 된다.

테이블 스페이스의 제거

테이블 스페이스를 제거하기 위해서는 DROP TABLESPACE 문을 사용해야 한다. 단, 테이블 스페이스를 제거하면 그 안에 포함되어 있는 모든 스키마 객체가 제거되므로 주의해야 한다.

다음은 테이블 스페이스를 제거하는 예이다.

DROP TABLESPACE my_space;

이 SQL 문장을 실행하면 데이터베이스에서 테이블 스페이스는 제거되지만 테이블 스페이스를 구성하는 데이터 파일은 삭제되지 않는다. 데이터 파일까지 제거하려면 다음과 같이 INCLUDING 절을 삽입하여 DROP TABLESPACE 문을 실행해야 한다.

DROP TABLESPACE my_space INCLUDING CONTENTS AND DATAFILES;

테이블 스페이스의 저장 공간이 더 필요한 경우 데이터 파일이 자동으로 확장하도록 설정하는 방법도 있지만 ALTER TABLESPACE 문에서 ADD DATAFILE 절을 삽입하여 새로운 데이터 파일을 테이블 스페이스에 추가하는 방법도 있다.

다음은 테이블 스페이스 my_space에 새로운 데이터 파일 my_file02.dtf를 추가하는 예이다.

ALTER TABLESPACE my_space ADD DATAFILE 'my_file02.dtf' SIZE 20M;

데이터 파일을 추가할 때 위의 예처럼 절대 경로를 명시하지 않으면 디폴트로 설정된 디렉터리에 데이터 파일이 생성된다. 이때 생성되는 데이터 파일의 개수는 하나 이상이 될 수 있으며, 각 데이터 파일에 대한 크기를 자동으로 확장하도록 설정할 수 있다.

또한 데이터 파일은 ALTER DATABASE 문을 통해 크기를 변경할 수도 있다. ALTER DATABASE 문을 사용하면 데이터 파일의 크기를 늘리거나 줄이는 것이 모두 가능하다. 단, 데이터 파일의 크기를 줄이는 경우에는 데이터 파일 안에 저장되어 있는 스키마 객체의 전체 크기보다 작을 때 에러가 발생된다.

다음은 데이터 파일 my_file01.dtf의 크기를 변경하는 예이다.

ALTER DATABASE DATAFILE 'my_file01.dtf' RESIZE 100M;

특정 테이블 스페이스에 읽고 쓰는 모든 접근을 허용하지 않으려면 ALTER TABLESPACE 문에서 OFFLINE 절을 이용하여 테이블 스페이스를 오프라인 상태로 변경하면 된다.

테이블 스페이스 오프라인은 NORMAL과 IMMEDIDATE 두 가지 모드를 지원한다.

다음은 테이블 스페이스 my_space를 NORMAL 모드로 오프라인 상태를 만든 후 다시 온라인 상태로 만드는 예이다.

ALTER TABLESPACE my_space OFFLINE [NORMAL]; 
ALTER TABLESPACE my_space ONLINE;

다음은 테이블 스페이스 my_space를 IMMEDIATE 모드로 오프라인 상태를 만든 후 미디어 복구를 수행한 뒤 다시 온라인 상태로 만드는 예이다.

ALTER TABLESPACE my_space OFFLINE IMMEDIATE; 
ALTER DATABASE RECOVER AUTOMATIC TABLESPACE my_space;
ALTER TABLESPACE my_space ONLINE;

Tibero에서는 테이블 스페이스를 효율적으로 관리하기 위해 다음 표에 나열된 뷰(정적 뷰, 동적 뷰 포함)를 통해 테이블 스페이스의 정보를 제공하고 있다.

테이블 스페이스 내의 익스텐트의 크기 및 개수, 할당된 서버, 포함된 데이터 파일의 이름 및 크기, 세그먼트의 이름 및 종류, 크기 등의 정보를 제공한다.

로그 멤버는 기본적으로 하나의 로그 파일이다. Redo 로그를 구성할 때 각 로그 그룹과 로그 멤버에 서로 다른 로그 파일을 할당해야 한다. 로그 파일은 데이터 파일과 서로 다른 디스크에 저장할 것을 권장한다. 로그 파일과 데이터 파일을 같은 디스크에 저장하는 경우 디스크에 장애가 발생한다면 데이터베이스를 다시 복구할 수 없게 된다. 각 로그 그룹이 여러 개의 로그 멤버로 구성된다면 최소한 로그 멤버 하나는 데이터 파일과 다른 디스크에 저장되어야 한다.

로그 멤버의 다중화

로그 그룹 하나에 포함된 로그 멤버는 시스템의 성능을 위해 서로 다른 디스크에 저장하는 것이 좋다. 같은 로그 그룹 내의 모든 멤버는 같은 로그 레코드를 저장해야 한다. 모든 로그 멤버가 서로 다른 디스크에 존재하게 된다면 로그 레코드를 저장하는 과정을 동시에 수행할 수 있다.

다음은 같은 로그 그룹의 모든 로그 멤버를 서로 다른 디스크에 배치한 그림이다.

[그림 3.4] 로그 멤버의 다중화

[그림 3.4]에서 Log Member 1-1은 로그 그룹 1의 첫 번째 로그 멤버라는 의미이다. 하나의 디스크에 같은 그룹의 로그 멤버가 존재한다면 동시에 같은 로그 레코드를 저장할 수 없다. 이 때문에 데이터베이스 시스템의 성능이 저하되는 원인이 되기도 한다.

로그 아카이브 모드를 ARCHIVELOG로 설정했을 때 Redo 로그 안에 활성화된 로그 그룹의 로그가 저장됨과 동시에 비활성화된 로그 그룹 중 하나에 대해서 아카이브가 수행된다. 활성화된 로그 그룹과 아카이브 중인 로그 그룹이 한 디스크에 존재하게 된다면 이 또한 데이터베이스 시스템의 성능이 저하되는 원인이 된다. 따라서 서로 다른 로그 그룹의 로그 파일은 각각 다른 디스크에 저장하는 것이 시스템 성능을 높이는 데 도움이 된다.

로그 그룹의 다중화

다음은 두 개의 로그 멤버로 구성된 두 개의 로그 그룹을 서로 다른 디스크에 분리하여 배치한 그림이다.

[그림 3.5] 로그 그룹의 다중화

[그림 3.5]에서 Log Member 1-1은 로그 그룹 1의 첫 번째 로그 멤버라는 의미이다.

로그 그룹의 크기와 개수를 정할 때는 아카이브 작업을 충분히 고려해야 한다. 로그 그룹의 크기는 제3의 저장 장치에 빠르게 전달하고 저장 공간을 효율적으로 사용할 수 있도록 설정해야 한다. 또한 로그 그룹의 개수는 아카이브 중인 로그 그룹을 대기하는 경우가 발생하지 않도록 해야 한다.

로그 그룹의 크기와 개수는 데이터베이스를 실제로 운영하면서 변경해야 한다. 즉, 데이터베이스에 최적화된 파라미터를 설정한 후 로그 그룹의 크기와 개수를 증가시켜가면서 데이터베이스 처리 성능에 무리가 가지 않는 범위에서 변경해야 한다.

아카이브 로그의 저장과 다중화

아카이브된 로그가 저장되는 위치는 초기화 파라미터 LOG_ARCHIVE_DEST로 지정한다. 필요한 아카이브 로그를 찾지 못하면 미디어 복구를 할 수 없기 때문에 아카이브 로그를 잘 보관하는 것이 중요하다.

아카이브 로그 역시 다중화하여 여러 위치에 저장할 수 있다. 아카이브 로그를 다중화할 때는 초기화 파라미터 LOG_ARCHIVE_DEST_1, LOG_ARCHIVE_DEST_2, ..., LOG_ARCHIVE_DEST_9를 사용한다. 파라미터 문자열에서 'location='으로 저장위치를 지정하고, mandatory나 optional로 다중화 아카이브 로그 저장에 실패하는 경우 동작을 지정한다(지정하지 않으면 optional로 처리된다).

mandatory로 지정된 경우 해당위치에 다중화된 아카이브 로그 저장을 성공할 때까지 계속 시도하고, 만약 계속 실패할 경우 Redo 로그 그룹이 재사용되지 않아 데이터베이스 전체가 멈출 수 있다. 반면 optional로 지정된 위치는 아카이브 로그 저장에 실패하더라도 재시도하지 않으며, 다른 작업이 정상적으로 계속 진행된다.

LOG_ARCHIVE_DEST =   "/usr/tibero/log/archive"
LOG_ARCHIVE_DEST_1 = "location=/usr/tibero/archive1 mandatory"
LOG_ARCHIVE_DEST_2 = "location=/usr/tibero/archive2 mandatory"
LOG_ARCHIVE_DEST_3 = "location=/usr/tibero/archive3"
LOG_ARCHIVE_DEST_4 = "location=/usr/tibero/archive4 optional" 

새로운 로그 그룹 또는 로그 그룹에 포함되어 있는 로그 멤버를 생성하거나 제거하려면 ALTER DATABASE 문을 사용해야 한다. 단, ALTER DATABASE 문을 사용하기 위해서는 시스템 특권이 필요하다.

로그 파일의 생성

새로운 로그 그룹을 생성하려면 ALTER DATABASE 문에 ADD LOGFILE 절을 삽입해야 한다.

즉, ADD LOGFILE 절은 로그 파일을 추가할 때 사용하며 로그 파일을 추가할 때 로그 그룹 단위로만 해야 한다. 이때 로그 멤버의 크기의 최소값은 512KB이고, 최대값은 4GB-1(4294967295B)이다.

다음은 두 개의 로그 멤버로 구성된 로그 그룹을 추가하는 예이다. 본 예제에서는 두 로그 멤버의 크기를 512KB로 설정한다. 이때 두 로그 멤버의 크기는 항상 같아야 한다.

ALTER DATABASE ADD LOGFILE (
        '/usr/tibero/log/my_log21.log',
        '/usr/tibero/log/my_log22.log') SIZE 512K

또한 ADD LOGFILE 절에 로그 그룹의 번호를 지정할 수 있는 GROUP 옵션을 추가할 수 있다. 로그 그룹의 번호를 설정하면 이후에 특정한 로그 그룹을 지칭하여 로그 멤버를 추가하는 등의 작업을 수행할 수 있다. 다음은 로그 그룹에 번호를 설정하는 예이다.

ALTER DATABASE ADD LOGFILE GROUP 5 (
        '/usr/tibero/log/my_log21.log',
        '/usr/tibero/log/my_log22.log') SIZE 512K 

기존의 로그 그룹에 새로운 로그 멤버를 추가하려면 ADD LOGFILE MEMBER 절을 삽입해야 한다. 이때 로그 파일에 할당된 서버 프로세스를 반드시 명시해야 한다.

다음의 SQL 문장은 로그 그룹 5에 새로운 로그 멤버를 추가하는 예이다.

ALTER DATABASE ADD LOGFILE MEMBER
        '/usr/tibero/log/my_log25.log' TO GROUP 5

새로운 로그 멤버를 추가할 때에는 로그 파일의 크기를 지정하면 안 된다. 로그 파일의 크기는 같은 로그 그룹 내의 로그 멤버의 크기와 동일하게 설정한다.

로그 파일의 제거

로그 그룹을 제거하려면 DROP LOGFILE 절을 삽입해야 한다.

다음의 SQL 문장은 로그 그룹 5를 제거하는 예이다.

ALTER DATABASE DROP LOGFILE GROUP 5;

다음은 로그 그룹을 제거하기 전에 고려해야 할 사항이다.

로그 그룹 내의 하나의 로그 멤버를 제거하기 위해서는 DROP LOGFILE MEMBER 절을 삽입해야 한다. 로그 그룹이 할당된 서버를 명시해야 하며 로그 그룹은 명시하지 않아도 된다.

다음의 SQL 문장은 로그 멤버 하나를 제거하는 예이다.

ALTER DATABASE DROP LOGFILE MEMBER '/usr/tibero/log/my_log25.log' 

로그 멤버도 로그 그룹을 제거할 때처럼 로그 그룹 내에 남겨진 로그 멤버가 하나도 없는 경우 에러를 반환하게 된다. 뿐만 아니라 현재 활성화되어 사용 중이거나 ARCHIVELOG 모드에서 아카이브 되지 않은 로그 그룹 내의 로그 멤버도 제거되지 않는다.

Tibero에서는 Redo 로그 관리에 도움을 주기 위해 다음 표에 나열된 동적 뷰를 제공하고 있다.

Redo 로그의 그룹별 로그 파일, 다중화 정보, 갱신 날짜 등의 정보를 제공하며 DBA나 일반 사용자 모두가 이 뷰를 사용할 수 있다.

DBA는 컨트롤 파일의 복사본을 추가하거나 제거할 수 있다. 컨트롤 파일은 DBMS에 대한 메타데이터이므로 데이터베이스를 운영 중일 때에는 컨트롤 파일의 변경이 불가능하다. 따라서 컨트롤 파일의 복사본을 추가 또는 제거하기 위한 SQL 문장은 존재하지 않는다. 반드시 데이터베이스를 종료한 후 컨트롤 파일을 변경해야 한다.

이처럼 컨트롤 파일을 추가 또는 제거하기 위한 SQL 문장이 존재하지 않기 때문에 일반적인 운영체제 명령어를 사용하여 변경 작업을 수행해야 한다. 그 다음 변경된 내용을 $TB_SID.tip 파일에 반영한다.

다음은 UNIX Command에서 컨트롤 파일을 복사하는 예이다.

$ cp /usr1/tibero/control01.ctl /usr3/tibero/control03.ctl

위의 예에서 usr1과 usr3은 서로 다른 디스크에 존재하는 디렉터리이다.

Tibero는 데이터베이스를 다시 기동하면서 $TB_SID.tip 파일을 읽고, 변경된 내용에 따라 컨트롤 파일의 갱신을 수행한다. 이때 유의할 점은 $TB_SID.tip 파일 내에 설정된 컨트롤 파일의 이름은 절대 경로를 포함한 이름이어야 한다. 만약 디스크 에러 등의 원인으로 일부 컨트롤 파일에 장애가 발생했을 경우에도 하나 이상의 컨트롤 파일이 정상이면 Tibero는 문제없이 운영된다.

컨트롤 파일의 백업은 논리적 백업만을 지원한다. 따라서 컨트롤 파일을 생성하는 SQL 문장을 백업해야 한다. 특히 테이블 스페이스, 데이터 파일, Redo 로그를 새로 생성하거나 변경 또는 제거를 수행한 경우에는 바로 컨트롤 파일을 백업하는 것이 관리 측면에서 안전하다. 물론 데이터베이스 전체를 백업할 때에도 컨트롤 파일 자체를 백업해야 한다.

다음의 SQL 문장은 컨트롤 파일을 백업하는 예이다.

SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS
          '/tibero5/backup/ctrlfile1.sql' REUSE NORESETLOGS;

위 예에서 보듯이 백업할 컨트롤 파일의 복사본(ctrlfile1.sql)은 기존의 복사본과 다른 디스크에 저장해야 하므로 반드시 절대 경로를 포함한 이름을 명시해야 한다.

Tibero에서는 컨트롤 파일을 관리하는 데 도움을 주기 위해 다음 표에 동적 뷰를 제공하고 있다.

데이터베이스 생성 시간, 체크포인트 정보 등의 정보를 제공하며, DBA나 일반 사용자 모두가 이 뷰를 사용할 수 있다.