Database 파일 및 데이터 관리

데이터 저장 구조

Tibero의 데이터를 저장하는 구조는 아래와 같이 두 가지 영역으로 나뉩니다.

논리적 저장 영역

데이터베이스의 스키마 객체를 저장하는 영역 입니다.

물리적 저장 영역

운영체제와 관련된 파일을 저장하는 영역 입니다.

테이블 스페이스

테이블 스페이스는 논리적 저장 영역과 물리적 저장 영역에 공통적으로 포함됩니다.

논리적 저장 영역에는 Tibero의 모든 데이터가 저장되며, 물리적 저장 영역에는 데이터 파일이 하나 이상 저장됩니다. 테이블 스페이스는 논리적 저장 영역과 물리적 저장 영역을 연관시키기 위한 단위입니다.

테이블 스페이스 구성

테이블 스페이스는 아래와 같이 크게 두 가지 구성으로 Tibero 데이터를 저장합니다.

논리적 구성

테이블 스페이스는 세그먼트(Segment), 익스텐트(Extent), 데이터 블록(Block)으로 구성됩니다.

물리적 구성

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

빈번하게 사용되는 두 테이블 스페이스(예: 테이블과 인덱스)는 물리적으로 서로 다른 디스크에 저장하는 것이 좋습니다. 한 테이블 스페이스를 액세스하는 동안에 디스크의 헤드가 그 테이블 스페이스에 고정되어 있으므로 다른 테이블 스페이스를 액세스할 수 없습니다. 그러므로 서로 다른 디스크에 각각의 테이블 스페이스를 저장하여 동시에 액세스하는 것이 데이터베이스 성능을 향상시키는 데 도움이 됩니다.

테이블 스페이스 생성 및 제거

테이블 스페이스는 생성되는 유형에 따라 시스템 테이블 스페이스(System Tablespace)와 비시스템 테이블 스페이스(Non System Tablespace)로 구분됩니다. 시스템 테이블 스페이스는 데이터베이스가 생성될 때 자동으로 생성되는 테이블 스페이스이며, 비시스템 테이블 스페이스는 일반 사용자가 생성한 테이블 스페이스 입니다.

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

테이블 스페이스 생성

테이블 스페이스는 CREATE TABLESPACE 문을 사용해 생성 합니다.

• 테이블 스페이스의 이름, 테이블 스페이스에 포함되는 데이터 파일과 데이터 파일의 크기, 익스텐트의 크기 등을 설정할 수 있습니다.

• UNIFORM SIZE 옵션을 설정하면 일정한 크기로 익스텐트를 할당합니다. 해당 옵션을 설정하지 않으면 기본 방식인 auto allocate를 사용합니다.

• auto allocate는 세그먼트 크기에 따라 할당할 익스텐트의 크기를 유동적으로 결정하여 익스텐트를 할당하는 방식입니다.

기본 옵션

아래는 하나의 데이터 파일 my_file.dtf로 구성되는 테이블 스페이스 my_space를 기본 옵션으로 생성하는 예시입니다. UNIFOMR SIZE를 설정하지 않으면 auto allocate 방식으로 익스텐트를 할당합니다.

CREATE TABLESPACE my_space DATAFILE '/usr/tibero/dtf/my_file.dtf' SIZE 50M;

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

데이터블록 크기 8KB 기준, 세그먼트 크기 별 할당하는 익스텐트 크기는 아래와 같습니다.

UNIFORM SIZE 옵션

UNIFORM SIZE 옵션을 설정하면 하나의 테이블 스페이스 내의 모든 익스텐트의 크기를 항상 일정하게 관리할 수 있습니다.

아래는 하나의 데이터 파일 my_file.dtf로 구성되는 테이블 스페이스 my_space를 생성하면서 UNIFORM SIZE를 설정하는 예시 입니다. UNIFORM SIZE를 통해 할당할 익스텐트 크기를 256KB로 고정합니다.

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가 됩니다.

예를 들어 하나의 익스텐트의 크기가 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과 IMMEDIATE 두 가지 모드를 지원합니다.

아래는 테이블 스페이스 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 로그를 저장하는 파일입니다.

Redo 로그는 데이터베이스에서 발생하는 모든 변경 내용을 포함하며, 데이터베이스에 치명적인 오류가 발생한 경우 커밋된 트랜잭션의 갱신된 내용을 복구하는 핵심적인 데이터 구조 입니다.

Redo 로그

위[그림 4] 과같이 Redo 로그는 두 개 이상의 로그 그룹(Log Group)으로 구성됩니다. Tibero에서는 이러한 로그 그룹을 순환적(Circular)으로 사용합니다.

세 개의 로그 그룹으로 Redo 로그를 구성하는 예시

1. 로그 그룹 1에 로그를 저장

2. 로그 그룹 1에 로그가 가득 차면, 그 다음 로그 그룹 2, 3에 로그를 저장

3. 로그 그룹 3까지 로그가 가득 차면 로그 그룹 1부터 다시 저장

이처럼 하나의 로그 그룹을 모두 사용하고 그 다음 로그 그룹을 사용하는 것이 로그 전환(Log Switch) 입니다.

Redo 로그에는 하나 이상의 로그 레코드(Log Record)가 저장됩니다. 로그 레코드에는 데이터베이스에서 발생하는 모든 변경 내용이 포함되어 있으며, 이전에 변경된 값과 새로운 변경 값이 함께 저장됩니다.

Tibero는 동시에 하나의 로그 그룹만을 사용하는 데 현재 사용 중인 로그 그룹을 활성화(active)된 로그 그룹이라고 한다. 하나의 로그 그룹은 하나 이상의 로그 멤버로 구성할 수 있고, 이러한 구성을 다중화(multiplexing)라고 합니다.

하나의 로그 그룹을 여러 로그 멤버로 구성하는 이유는, 일부 로그 멤버가 손상되더라도 다른 로그 멤버를 사용하기 위함입니다. 디스크가 대단히 신뢰성이 높거나 데이터가 손실되어도 큰 문제가 없다면 다중화를 하지 않아도 됩니다.

ARCHIVELOG 모드 설정

Redo 로그에 저장된 내용을 제3의 저장 장치에 반영구적으로 저장할 수 있습니다. 디스크 상에 로그 파일이 손상될 경우를 대비하는 작업으로, 이러한 과정을 아카이브(Archive)라고 합니다. 아카이브에 사용되는 저장 장치로는 대용량 하드 디스크 또는 테이프 등이 있습니다.

Tibero에서는 Redo 로그를 사용하지 않을 때나 데이터베이스와 함께 사용 중인 경우에도 동시에 아카이브를 수행할 수 있습니다. Redo 로그를 사용하는 중에 아카이브를 하려면 로그 아카이브 모드를 ARCHIVELOG로 설정합니다. 아래 SQL문 실행을 통해 마운트(MOUNT) 상태에서 ARCHIVELOG 모드를 설정할 수 있습니다.

SQL> ALTER DATABASE ARCHIVELOG;

ARCHIVELOG 모드에서는 아카이브가 되지 않은 로그 그룹은 재사용되지 않습니다.

로그 그룹 1 전부 사용 후 로그 그룹 2를 사용할 경우의 예시

• 로그 그룹 2 이전에 저장된 로그가 아카이브가 되지 않은 경우: 로그 그룹 2가 아카이브가 될 때까지 대기 필요, 이때 읽기 전용이 아닌 모든 트랜잭션은 실행은 잠시 중지

• 로그 그룹 2가 아카이브가 되면 바로 활성화되어 로그를 저장, 잠시 중지되었던 트랜잭션도 모두 다시 실행

NOARCHIVELOG 모드 설정

Redo 로그를 사용하는 중에 아카이브를 수행하지 않으려면, 로그 아카이브 모드를 NOARCHIVELOG로 설정합니다. NOARCHIVELOG 모드에서는 아카이브가 수행되지 않으며, 로그 그룹을 순환적으로 활성화하기 전에 아카이브되기를 기다리는 경우가 발생하지 않으므로 데이터베이스의 성능이 향상됩니다.

그러나 데이터베이스와 Redo 로그 자체에 문제가 발생하여 동시에 복구할 수 없는 경우라면 이전에 커밋된 트랜잭션에 의해 갱신된 데이터를 모두 잃어버리게 됩니다.

로그 파일 구성

로그 멤버는 기본적으로 하나의 로그 파일 입니다.

• Redo 로그를 구성할 때 각 로그 그룹과 로그 멤버에 서로 다른 로그 파일을 할당해야 합니다.

• 로그 파일은 데이터 파일과 서로 다른 디스크에 저장할 것을 권장합니다.

• 로그 파일과 데이터 파일을 같은 디스크에 저장하는 경우 디스크에 장애가 발생한다면 데이터베이스를 다시 복구할 수 없게 됩니다. 각 로그 그룹이 여러 개의 로그 멤버로 구성된다면 최소한 로그 멤버 하나는 데이터 파일과 다른 디스크에 저장되어야 합니다.

로그 멤버의 다중화

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

아래는 같은 로그 그룹의 모든 로그 멤버를 서로 다른 디스크에 배치한 그림 입니다.

위 [그림 5]에서 Log Member 1-1은 로그 그룹 1의 첫 번째 로그 멤버를 의미합니다.

하나의 디스크에 같은 그룹의 로그 멤버가 존재한다면 동시에 같은 로그 레코드를 저장할 수 없으므로 데이터베이스 시스템의 성능이 저하되는 원인이 되기도 합니다.

로그 아카이브 모드를 ARCHIVELOG로 설정했을 때 Redo 로그 안에 활성화된 로그 그룹의 로그가 저장됨과 동시에 비활성화된 로그 그룹 중 하나에 대해서 아카이브가 수행됩니다.

활성화된 로그 그룹과 아카이브 중인 로그 그룹이 한 디스크에 존재하게 된다면 이 또한 데이터베이스 시스템의 성능이 저하되는 원인이 되므로 서로 다른 로그 그룹의 로그 파일은 각각 다른 디스크에 저장하는 것이 시스템 성능을 높이는 데 도움이 됩니다.

로그 그룹의 다중화

아래는 두 개의 로그 멤버로 구성된 두 개의 로그 그룹을 서로 다른 디스크에 분리하여 배치한 그림 입니다.

위 [그림 6]에서 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로 지정된 위치는 아카이브 로그 저장에 실패하더라도 재시도하지 않으며, 다른 작업이 정상적으로 계속 진행됩니다.

tip 설정 예시

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 문에 ADD LOGFILE 절을 삽입합니다. 이 절은 로그 파일을 추가할 때 사용하며, 로그 파일 추가 시 로그 그룹 단위로만 해야 합니다. 로그 멤버의 크기의 최소값은 512KB, 최대값은 2TB 입니다.

아래는 두 개의 로그 멤버로 구성된 로그 그룹을 추가하는 예시입니다.

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 절을 삽입합니다.

로그 그룹 5 제거 예시

ALTER DATABASE DROP LOGFILE GROUP 5; 

로그 그룹 제거 전 고려사항

• 로그 그룹이 둘 이상인가? Tibero는 로그 그룹을 최소한 두 개 이상 가져야 합니다.

• 로그 그룹을 제거한 후 남은 로그 그룹의 개수가 하나인가? 남은 로그 그룹의 개수가 하나이면 오류를 반환합니다.

• 현재 활성화되어 사용 중인 로그 그룹인가? 로그 그룹은 제거되지 않습니다.

• ARCHIVELOG 모드에서 아카이브 되지 않은 로그 그룹인가? 로그 그룹은 제거되지 않습니다.

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

하나의 로그 멤버 제거 예시

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

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

로그 파일 정보 조회

Tibero에서는 Redo 로그 관리에 도움을 주기 위해 아래 표에 나열된 동적 뷰를 제공합니다.

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

컨트롤 파일

컨트롤 파일은 데이터베이스 자체의 메타데이터를 보관하고 있는 바이너리 파일 입니다.

• 최초의 컨트롤 파일은 Tibero를 설치할 때 함께 생성되며 최초로 설정된 컨트롤 파일에 대한 정보는 $TB_SID.tip 파일에 저장됩니다.

• 컨트롤 파일은 Tibero에 의해서만 생성과 갱신을 할 수 있으며 DBA가 컨트롤 파일의 내용을 조회하거나 갱신할 수 없습니다.

컨트롤 파일 포함정보

Tibero에서는 데이터베이스를 다시 기동할 때마다 먼저 컨트롤 파일을 참조합니다.

컨트롤 파일 참조 절차

1. 테이블 스페이스와 데이터 파일의 정보 습득

2. 데이터베이스에 실제 저장된 데이터 사전과 스키마 객체의 정보 습득

3. 필요한 데이터 읽기

Tibero에서 컨트롤 파일은 같은 크기, 같은 내용의 파일을 두 개 이상 유지하기를 권장합니다. 이는 Redo 로그 멤버를 다중화하는 방법과 유사합니다.

같은 로그 그룹 내의 로그 멤버를 서로 다른 디스크에 설치하는 것처럼 컨트롤 파일의 복사본을 서로 다른 디스크에 저장하는 것이 좋습니다. 이는 데이터베이스의 시스템 성능과 안정성을 유지하는 데 매우 필요합니다.

예를 들어 한 디스크에 컨트롤 파일의 복사본이 존재하는 경우 문제가 발생할 수 있습니다. 만약 이 디스크를 영구적으로 사용할 수 없게 된다면 컨트롤 파일은 복구할 수 없는 상태가 되므로, 컨트롤 파일은 Redo 로그와 연관하여 배치하는 것이 좋습니다.

컨트롤 파일의 다중화

위 그림에서 보듯이 디스크마다 하나의 로그 그룹에 여러 로그 멤버를 배치한 것처럼 컨트롤 파일의 복사본을 같은 위치에 배치합니다. Tibero에서는 컨트롤 파일로부터 정보를 확인할 때 여러 복사본 중에서 하나만 읽습니다. 그리고 테이블 스페이스의 변경 등의 이유로 컨트롤 파일을 갱신해야 하는 경우에는 모든 복사본을 동시에 갱신합니다.

컨트롤 파일의 갱신을 유발하는 SQL 문장은 모두 DDL 문장입니다. DDL 문장의 특징은 하나의 문장이 하나의 트랜잭션이 되는것이므로 DDL 문장을 실행하면 바로 커밋되며, 갱신된 내용은 바로 디스크에 반영됩니다.

컨트롤 파일 변경

DBA는 컨트롤 파일의 복사본을 추가하거나 제거할 수 있습니다.

컨트롤 파일은 DBMS에 대한 메타데이터이므로 데이터베이스를 운영 중일 때에는 컨트롤 파일의 변경이 불가능합니다. 반드시 데이터베이스를 종료한 후 컨트롤 파일을 변경해야 합니다.

따라서 컨트롤 파일의 복사본을 추가 또는 제거하기 위한 SQL 문장은 존재하지 않습니다. 그러므로 일반적인 운영체제 명령어를 사용하여 변경 작업을 수행해야 합니다. 그 다음 변경된 내용을 $TB_SID.tip 파일에 반영합니다.

아래는 UNIX Command에서 컨트롤 파일을 복사하는 예시입니다.

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

위의 예에서 usr1과 usr3은 서로 다른 디스크에 존재하는 디렉터리 입니다.Tibero는 데이터베이스를 다시 기동하면서 $TB_SID.tip 파일을 읽고, 변경된 내용에 따라 컨트롤 파일의 갱신을 수행합니다.

컨트롤 파일의 백업은 물리적 백업과 논리적 백업을 지원합니다.

물리적 백업은 수동으로 모든 데이터 파일들도 함께 백업을 해야하며 절차가 매우 중요합니다. 절차를 제대로 지키지 않았을 시 추후 데이터 복구가 불가능하기 때문에, 실수할 확률이 있는 물리적 백업은 보통 권장하지 않으며 책임져주지 않습니다. 따라서 논리적 백업 방법으로 컨트롤 파일을 생성하는 SQL 문장을 백업하는 것이 일반적입니다.

또한 테이블 스페이스, 데이터 파일, Redo 로그를 새로 생성하거나 변경 또는 제거를 수행한 경우에는 바로 컨트롤 파일을 백업하는 것이 관리 측면에서 안전합니다.

아래의 SQL 문장은 컨트롤 파일을 물리적 백업하는 예시입니다.

SQL> ALTER DATABASE BACKUP CONTROLFILE TO
          '/tibero7/backup/ctrlfile1.ctl';

아래의 SQL 문장은 컨트롤 파일을 논리적 백업하는 예시입니다.

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

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

컨트롤 파일 정보 조회

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

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