cubrid 관리 유틸리티

cubrid 관리 유틸리티의 사용법(구문)은 다음과 같다.

cubrid utility_name
utility_name :
    createdb [option] <database_name>   --- 데이터베이스 생성
    deletedb [option] <database_name>   --- 데이터베이스 삭제
    installdb [option] <database-name>   --- 데이터베이스 설치
    renamedb [option] <source-database-name> <target-database-name>  --- 데이터베이스 이름 변경
    copydb [option] <source-database-name> <target-database-name>  --- 데이터베이스 복사
    backupdb [option] <database-name>  --- 데이터베이스 백업
    restoredb [option] <database-name>  --- 데이터베이스 복구
    addvoldb [option] <database-name>  --- 데이터베이스 볼륨 파일 추가
    spacedb [option] <database-name>  --- 데이터베이스 공간 정보 출력
    lockdb [option] <database-name>  --- 데이터베이스의 lock 정보 출력
    tranlist [option] <database-name>  --- 트랜잭션 확인
    killtran [option] <database-name>  --- 트랜잭션 제거
    optimizedb [option] <database-name>  --- 데이터베이스 통계 정보 갱신
    statdump [option] <database-name>  --- 데이터베이스 서버 실행 통계 정보 출력
    compactdb [option] <database-name>  --- 사용되지 않는 영역을 해제, 공간 최적화
    diagdb [option] <database-name>  --- 내부 정보 출력
    checkdb [option] <database-name>  --- 데이터베이스 일관성 검사
    alterdbhost [option] <database-name>  --- 데이터베이스 호스트 변경
    plandump [option] <database-name>  --- 쿼리 플랜 캐시 정보 출력
    loaddb [option] <database-name>  --- 데이터 및 스키마 가져오기(로드)
    unloaddb [option] <database-name>  --- 데이터 및 스키마 내보내기(언로드)
    paramdump [option] <database-name>  --- 데이터베이스의 설정된 파라미터 값 확인
    changemode [option] <database-name>  --- 서버의 HA 모드 출력 또는 변경
    copylogdb [option] <database-name>  --- HA 구성을 위해 트랜잭션 로그를 다중화하는 도구
    applylogdb [option] <database-name>  --- HA 구성을 위해 트랜잭션 로그에서 복제 로그를 읽고 적용하는 도구
    applyinfo [option] <database-name>   --- HA 환경에서 트랜잭션 로그 반영 정보를 확인하는 도구
    synccolldb [option] <database-name>  --- DB 콜레이션을 시스템 콜레이션에 맞게 변경하는 도구
    genlocale [option] <database-name>  --- 사용하고자 하는 로캘 정보를 컴파일하는 도구
    dumplocale [option] <database-name>   --- 컴파일된 바이너리 로캘 정보를 사람이 읽을 수 있는 텍스트로 출력하는 도구

데이터베이스 사용자

CUBRID 데이터베이스 사용자는 동일한 권한을 갖는 멤버를 가질 수 있다. 사용자에게 권한 A 가 부여되면, 상기 사용자에게 속하는 모든 멤버에게도 권한 A 가 동일하게 부여된다. 이와 같이 데이터베이스 사용자와 그에 속한 멤버를 '그룹'이라 하고, 멤버가 없는 사용자를 '사용자'라 한다.

CUBRID는 DBAPUBLIC 이라는 사용자를 기본으로 제공한다.

  • DBA 는 모든 사용자의 멤버가 되며 데이터베이스의 모든 객체에 접근할 수 있는 최고 권한 사용자이다. 또한, DBA 만이 데이터베이스 사용자를 추가, 편집, 삭제할 수 있는 권한을 갖는다.
  • DBA 를 포함한 모든 사용자는 PUBLIC 의 멤버가 되므로 모든 데이터베이스 사용자는 PUBLIC 에 부여된 권한을 가진다. 예를 들어, PUBLIC 사용자에 권한 B 를 추가하면 데이터베이스의 모든 사용자에게 일괄적으로 권한 B 가 부여된다.

databases.txt 파일

CUBRID에 존재하는 모든 데이터베이스의 위치 정보는 databases.txt 파일에 저장하는데, 이를 데이터베이스 위치 정보 파일이라 한다. 이러한 데이터베이스 위치 정보 파일은 데이터베이스의 생성, 이름 변경, 삭제 및 복사에 관한 유틸리티를 수행하거나 각 데이터베이스를 구동할 때에 사용되며, 기본으로는 설치 디렉터리의 databases 디렉터리에 위치하고, CUBRID_DATABASES 환경 변수로 디렉터리 위치를 지정할 수 있다.

db_name db_directory server_host logfile_directory

데이터베이스 위치 정보 파일의 라인별 형식은 구문에 정의된 바와 같으며, 데이터베이스 이름, 데이터베이스 경로, 서버 호스트 및 로그 파일의 경로에 관한 정보를 저장한다. 다음은 데이터베이스 위치 정보 파일의 내용을 확인한 예이다.

% more databases.txt

dist_testdb /home1/user/CUBRID/bin d85007 /home1/user/CUBRID/bin
dist_demodb /home1/user/CUBRID/bin d85007 /home1/user/CUBRID/bin
testdb /home1/user/CUBRID/databases/testdb d85007 /home1/user/CUBRID/databases/testdb
demodb /home1/user/CUBRID/databases/demodb d85007 /home1/user/CUBRID/databases/demodb

데이터베이스 위치 정보 파일의 저장 디렉터리는 기본적으로 설치 디렉터리의 databases 디렉터리로 지정되며, 시스템 환경 변수 CUBRID_DATABASES 의 설정을 변경하여 기본 디렉터리를 변경할 수 있다. 데이터베이스 위치 정보 파일의 저장 디렉터리 경로가 유효해야 데이터베이스 관리를 위한 cubrid 유틸리티가 데이터베이스 위치 정보 파일에 접근할 수 있게 된다. 이를 위해서 사용자는 디렉터리 경로를 정확하게 입력해야 하고, 해당 디렉터리 경로에 대해 쓰기 권한을 가지는지 확인해야 한다. 다음은 CUBRID_DATABASES 환경 변수에 설정된 값을 확인하는 예이다.

% set | grep CUBRID_DATABASES
CUBRID_DATABASES=/home1/user/CUBRID/databases

만약 CUBRID_DATABASES 환경 변수에서 유효하지 않은 디렉터리 경로가 설정되는 경우에는 에러가 발생하며, 설정된 디렉터리 경로는 유효하나 데이터베이스 위치 정보 파일이 존재하지 않는 경우에는 새로운 위치 정보 파일을 생성한다. 또한, CUBRID_DATABASES 환경 변수가 아예 설정되지 않은 경우에는 현재 작업 디렉터리에서 위치 정보 파일을 검색한다.

데이터베이스 생성, 볼륨 추가, 삭제

데이터베이스 생성

cubrid createdb 유틸리티는 CUBRID 시스템에서 사용할 데이터베이스를 생성하고 미리 만들어진 CUBRID 시스템 테이블을 초기화한다. 데이터베이스에 권한이 주어진 초기 사용자를 정의할 수도 있다. 일반적으로 데이터베이스 관리자만이 cubrid createdb 유틸리티를 사용한다. 로그와 데이터베이스의 위치도 지정할 수 있다.

Warning

데이터베이스를 생성할 때 CUBRID_CHARSET(설치 시 기본값 en_US, ISO-88591 문자셋 사용)을 반드시 지정해야 하며, 문자셋에 따라 문자열 타입의 크기, 문자열 비교 연산 등에 영향을 끼친다. 데이터베이스 생성 시 지정된 문자셋은 변경할 수 없으므로 지정에 주의해야 한다.

문자셋, 로캘 및 콜레이션 설정과 관련된 자세한 내용은 다국어 지원을 참고한다.

cubrid createdb [options] database_name
  • cubrid: CUBRID 서비스 및 데이터베이스 관리를 위한 통합 유틸리티이다.
  • createdb: 새로운 데이터베이스를 생성하기 위한 명령이다.
  • database_name: 데이터베이스가 생성될 디렉터리 경로명을 포함하지 않고, 생성하고자 하는 데이터베이스의 이름을 고유하게 부여한다. 이 때, 지정한 데이터베이스 이름이 이미 존재하는 데이터베이스 이름과 중복되는 경우, CUBRID는 기존 파일을 보호하기 위하여 데이터베이스 생성을 더 이상 진행하지 않는다.

데이터베이스 이름의 최대 길이는 영문 17자이다.

다음은 cubrid createdb 에 대한 [options]이다.

--db-volume-size=SIZE

데이터베이스를 생성할 때 첫 번째 데이터베이스 볼륨의 크기를 지정하는 옵션으로, 기본값은 cubrid.conf에 지정된 시스템 파라미터 db_volume_size의 값이다. 최소값은 20M이다. K, M, G, T로 단위를 설정할 수 있으며, 각각 KB(kilobytes), MB(megabytes), GB(gigabytes), TB(terabytes)를 의미한다. 단위를 생략하면 바이트 단위가 적용된다.

다음은 첫 번째로 생성되는 testdb의 볼륨 크기를 512MB로 지정하는 구문이다.

cubrid createdb --db-volume-size=512M testdb
--db-page-size=SIZE

데이터베이스 페이지 크기를 지정하는 옵션으로서, 최소값은 4K, 최대값은 16K(기본값)이다. K는 KB(kilobytes)를 의미한다. 데이터베이스 페이지 크기는 4K, 8K, 16K 중 하나의 값이 된다. 4K와 16K 사이의 값을 지정할 경우 지정한 값의 올림값으로 설정되며, 4K보다 작으면 4K로 설정되고 16K보다 크면 16K로 설정된다.

다음은 testdb를 생성하고, testdb의 데이터베이스 페이지 크기를 16K로 지정하는 구문이다.

cubrid createdb --db-page-size=16K testdb
--log-volume-size=SIZE

생성되는 데이터베이스의 로그 볼륨 크기를 지정하는 옵션으로, 기본값은 데이터베이스 볼륨 크기와 같으며 최소값은 20M이다. K, M, G, T로 단위를 설정할 수 있으며, 각각 KB(kilobytes), MB(megabytes), GB(gigabytes), TB(terabytes)를 의미한다. 단위를 생략하면 바이트 단위가 적용된다.

다음은 testdb 를 생성하고, testdb 의 로그 볼륨 크기를 256M로 지정하는 구문이다.

cubrid createdb --log-volume-size=256M testdb
--log-page-size=SIZE

생성되는 데이터베이스의 로그 볼륨 페이지 크기를 지정하는 옵션으로, 기본값은 데이터 페이지 크기와 같다. 최소값은 4K, 최대값은 16K이다. K는 KB(kilobytes)를 의미한다. 데이터베이스 페이지 크기는 4K, 8K, 16K 중 하나의 값이 된다. 4K와 16K 사이의 값을 지정할 경우 지정한 값의 올림값으로 설정되며, 4K보다 작으면 4K로 설정되고 16K보다 크면 16K로 설정된다.

다음은 testdb 를 생성하고, testdb의 로그 볼륨 페이지 크기를 8kbyte로 지정하는 구문이다.

cubrid createdb -log-page-size=8K testdb
--comment=COMMENT

데이터베이스의 볼륨 헤더에 지정된 주석을 포함하는 옵션으로, 문자열에 공백이 포함되면 큰 따옴표로 감싸주어야 한다.

다음은 testdb 를 생성하고, 데이터베이스 볼륨에 이에 대한 주석을 추가하는 구문이다.

cubrid createdb --comment "a new database for study" testdb
-F, --file-path=PATH

새로운 데이터베이스가 생성되는 디렉터리의 절대 경로를 지정하는 옵션으로, -F 옵션을 지정하지 않으면 현재 작업 디렉터리에 새로운 데이터베이스가 생성된다.

다음은 testdb 라는 이름의 데이터베이스를 /dbtemp/new_db라는 디렉터리에 생성하는 구문이다.

cubrid createdb -F "/dbtemp/new_db/" testdb
-L, --log-path=PATH

데이터베이스의 로그 파일이 생성되는 디렉터리의 절대 경로를 지정하는 옵션으로, -L 옵션을 지정하지 않으면 -F 옵션에서 지정한 디렉터리에 생성된다. -F 옵션과 -L 옵션을 둘 다 지정하지 않으면 데이터베이스와 로그 파일이 현재 작업 디렉터리에 생성된다.

다음은 testdb 라는 이름의 데이터베이스를 /dbtemp/newdb라는 디렉터리에 생성하고, 로그 파일을 /dbtemp/db_log 디렉터리에 생성하는 구문이다.

cubrid createdb -F "/dbtemp/new_db/" -L "/dbtemp/db_log/" testdb
-B, --lob-base-path=PATH

BLOB / CLOB 데이터를 사용하는 경우, LOB 데이터 파일이 저장되는 디렉터리의 경로를 지정하는 옵션으로, 이 옵션을 지정하지 않으면 <데이터베이스 볼륨이 생성되는 디렉터리>/lob 디렉터리에 LOB 데이터 파일이 저장된다.

다음은 testdb 를 현재 작업 디렉터리에 생성하고, LOB 데이터 파일이 저장될 디렉터리를 로컬 파일 시스템의 "/home/data1" 로 지정하는 구문이다.

cubrid createdb --lob-base-path "file:/home1/data1" testdb
--server-name=HOST

CUBRID의 클라이언트/서버 버전을 사용할 때 특정 데이터베이스에 대한 서버가 지정한 호스트 상에 구동되도록 하는 옵션이다. 이 옵션으로 지정된 서버 호스트의 정보는 데이터베이스 위치 정보 파일( databases.txt )에 기록된다. 이 옵션이 지정되지 않으면 기본값은 현재 로컬 호스트이다.

다음은 testdbaa_host 호스트 상에 생성 및 등록하는 구문이다.

cubrid createdb --server-name aa_host testdb
-r, --replace

-r 은 지정된 데이터베이스 이름이 이미 존재하는 데이터베이스 이름과 중복되더라도 새로운 데이터베이스를 생성하고, 기존의 데이터베이스를 덮어쓰도록 하는 옵션이다.

다음은 testdb 라는 이름의 데이터베이스가 이미 존재하더라도 기존의 testdb 를 덮어쓰기하고 새로운 testdb 를 생성하는 구문이다.

cubrid createdb -r testdb
--more-volume-file=FILE

데이터베이스가 생성되는 디렉터리에 추가 볼륨을 생성하는 옵션으로 지정된 파일에 저장된 명세에 따라 추가 볼륨을 생성한다. 이 옵션을 이용하지 않더라도, cubrid addvoldb 유틸리티를 이용하여 볼륨을 추가할 수 있다.

다음은 testdb 를 생성함과 동시에 vol_info.txt에 저장된 명세를 기반으로 볼륨을 추가 생성하는 구문이다.

cubrid createdb --more-volume-file vol_info.txt testdb

다음은 위 구문으로 vol_info.txt에 저장된 추가 볼륨에 관한 명세이다. 각 볼륨에 관한 명세는 라인 단위로 작성되어야 한다.

#xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
# NAME volname COMMENTS volcmnts PURPOSE volpurp NPAGES volnpgs
NAME data_v1 COMMENTS "데이터 정보 볼륨" PURPOSE data NPAGES 1000
NAME data_v2 COMMENTS "데이터 정보 볼륨" PURPOSE data NPAGES 1000
NAME data_v3 PURPOSE data NPAGES 1000
NAME index_v1 COMMENTS "인덱스 정보 볼륨" PURPOSE index NPAGES 500
NAME temp_v1 COMMENTS "임시 정보 볼륨" PURPOSE temp NPAGES 500
NAME generic_v1 COMMENTS "일반 정보 볼륨" PURPOSE generic NPAGES 500
#xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

예제 파일에서와 같이 각 볼륨에 관한 명세는 다음과 같이 구성된다.

NAME volname COMMENTS volcmnts PURPOSE volpurp NPAGES volnpgs
  • volname: 추가 생성될 볼륨의 이름으로 Unix 파일 이름 규약을 따라야 하고, 디렉터리 경로를 포함하지 않는 단순한 이름이어야 한다. 볼륨명에 관한 명세는 생략할 수 있으며, 이 경우 시스템에 의해 "생성될 데이터베이스 이름_볼륨 식별자"로 볼륨명이 생성된다.
  • volcmnts: 볼륨 헤더에 기록되는 주석 문장으로, 추가 생성되는 볼륨에 관한 정보를 임의로 부여할 수 있다. 볼륨 주석에 관한 명세 역시 생략할 수 있다.
  • volpurp: 볼륨 저장의 목적으로, data, index, temp, generic 중 하나여야 한다. 볼륨 목적에 관한 명세는 생략할 수 있으며, 이 경우 기본값은 generic 이다.
  • volnpgs: 추가 생성되는 볼륨의 페이지 수이다. 볼륨 페이지 수에 관한 명세는 생략할 수 없으며, 반드시 지정해야 한다.
--user-definition-file=FILE

생성하고자 하는 데이터베이스에 대해 권한이 있는 사용자를 추가하는 옵션으로, 파라미터로 지정된 사용자 정보 파일에 저장된 명세에 따라 사용자를 추가한다. --user-definition-file 옵션을 이용하지 않더라도 사용자 관리 구문을 이용하여 사용자를 추가할 수 있다.

다음은 testdb 를 생성함과 동시에 user_info.txt에 정의된 사용자 정보를 기반으로 testdb 에 대한 사용자를 추가하는 구문이다.

cubrid createdb --user-definition-file=user_info.txt testdb

사용자 정보 파일의 구문은 아래와 같다.

USER user_name [ <groups_clause> | <members_clause> ]

<groups_clause>:
    [ GROUPS <group_name> [ { <group_name> }... ] ]

<members_clause>:
    [ MEMBERS <member_name> [ { <member_name> }... ] ]
  • user_name: 데이터베이스에 대해 권한을 가지는 사용자 이름이며, 공백이 포함되지 않아야 한다.
  • GROUPS 절: 옵션이며, <group_name> 은 지정된 <user_name>을 포함하는 상위 그룹의 이름이다. 이 때, <group_name>은 하나 이상이 지정될 수 있으며, USER 로 미리 정의되어야 한다.
  • MEMBERS 절: 옵션이며, <member_name> 은 지정된 <user_name>에 포함되는 하위 멤버의 이름이다. 이 때, <member_name>은 하나 이상이 지정될 수 있으며, USER 로 미리 정의되어야 한다.

사용자 정보 파일에서는 주석을 사용할 수 있으며, 주석 라인은 연속된 하이픈(--)으로 시작된다. 공백 라인은 무시된다.

다음 예제는 그룹 sedangrandeursonata 가, 그룹 suvtuscan 이, 그룹 hatchbacki30 가 포함되는 것을 정의하는 사용자 정보 파일이다. 사용자 정보 파일명은 user_info.txt로 예시한다.

--
--    사용자 정보 파일의 예1
--
USER sedan
USER suv
USER hatchback
USER grandeur GROUPS sedan
USER sonata GROUPS sedan
USER tuscan GROUPS suv
USER i30 GROUPS hatchback

위 예제와 동일한 사용자 관계를 정의하는 파일이다. 다만, 아래 예제에서는 MEMBERS 절을 이용하였다.

--
-- 사용자 정보 파일의 예2
--
USER grandeur
USER sonata
USER tuscan
USER i30
USER sedan MEMBERS sonata grandeur
USER suv MEMBERS tuscan
USER hatchback MEMBERS i30
--csql-initialization-file=FILE

생성하고자 하는 데이터베이스에 대해 CSQL 인터프리터에서 구문을 실행하는 옵션으로, 파라미터로 지정된 파일에 저장된 SQL 구문에 따라 스키마를 생성할 수 있다.

다음은 testdb 를 생성함과 동시에 table_schema.sql에 정의된 SQL 구문을 CSQL 인터프리터에서 실행시키는 구문이다.

cubrid createdb --csql-initialization-file table_schema.sql testdb
-o, --output-file=FILE

데이터베이스 생성에 관한 메시지를 파라미터로 지정된 파일에 저장하는 옵션이며, 파일은 데이터베이스와 동일한 디렉터리에 생성된다. -o 옵션이 지정되지 않으면 메시지는 콘솔 화면에 출력된다. -o 옵션은 데이터베이스가 생성되는 중에 출력되는 메시지를 지정된 파일에 저장함으로써 특정 데이터베이스의 생성 과정에 관한 정보를 활용할 수 있게 한다.

다음은 testdb 를 생성하면서 이에 관한 유틸리티의 출력을 콘솔 화면이 아닌 db_output 파일에 저장하는 구문이다.

cubrid createdb -o db_output testdb
-v, --verbose

데이터베이스 생성 연산에 관한 모든 정보를 화면에 출력하는 옵션으로서, -o 옵션과 마찬가지로 특정 데이터베이스 생성 과정에 관한 정보를 확인하는데 유용하다. 따라서, -v 옵션과 -o 옵션을 함께 지정하면, -o 옵션의 파라미터로 지정된 출력 파일에 cubrid createdb 유틸리티의 연산 정보와 생성 과정에 관한 출력 메시지를 저장할 수 있다.

다음은 testdb 를 생성하면서 이에 관한 상세한 연산 정보를 화면에 출력하는 구문이다.

cubrid createdb -v testdb

Note

  • temp_file_max_size_in_pages 는 복잡한 질의문이나 정렬 수행에 사용되는 일시적 임시 볼륨(temporary temp volume)을 디스크에 저장하는 데에 할당되는 페이지의 최대 개수를 설정하는 파라미터이다. 기본값은 -1 로, temp_volume_path 파라미터가 지정한 디스크의 여유 공간까지 일시적 임시 볼륨(temporary temp volume)이 커질 수 있다. 0이면 일시적 임시 볼륨이 생성되지 않으므로 cubrid addvoldb 유틸리티를 이용하여 영구적 임시 볼륨(permanent temp volume)을 충분히 추가해야 한다. 볼륨을 효율적으로 관리하려면 용도별로 볼륨을 추가하는 것을 권장한다.
  • cubrid spacedb 유틸리티를 사용하여 각 용도별 볼륨의 남은 공간을 검사할 수 있으며, cubrid addvoldb 유틸리티를 사용하여 데이터베이스 운영 중에도 필요한 만큼 볼륨을 추가할 수 있다. 데이터베이스 운영 중에 볼륨을 추가하려면 가급적 시스템 부하가 적은 상태에서 추가할 것을 권장한다. 해당 용도의 볼륨 공간이 모두 사용되면 범용(generic) 볼륨이 생성되므로 여유 공간이 부족할 것으로 예상되는 용도의 볼륨을 미리 추가해 놓을 것을 권장한다.

다음은 데이터베이스를 생성하고 볼륨 용도를 구분하여 데이터(data), 인덱스(index), 임시(temp) 볼륨을 추가하는 예이다.

cubrid createdb --db-volume-size=512M --log-volume-size=256M cubriddb
cubrid addvoldb -p data -n cubriddb_DATA01 --db-volume-size=512M cubriddb
cubrid addvoldb -p data -n cubriddb_DATA02 --db-volume-size=512M cubriddb
cubrid addvoldb -p index -n cubriddb_INDEX01 cubriddb --db-volume-size=512M cubriddb
cubrid addvoldb -p temp -n cubriddb_TEMP01 cubriddb --db-volume-size=512M cubriddb

데이터베이스 볼륨 추가

데이터베이스 볼륨을 추가한다.

cubrid addvoldb [options] database_name
  • cubrid: CUBRID 서비스 및 데이터베이스 관리를 위한 통합 유틸리티이다.
  • addvoldb: 지정된 데이터베이스에 지정된 페이지 수만큼 새로운 볼륨을 추가하기 위한 명령이다.
  • database_name: 데이터베이스가 생성될 디렉터리 경로명을 포함하지 않고, 볼륨을 추가하고자 하는 데이터베이스의 이름을 지정한다.

다음은 데이터베이스를 생성하고 볼륨 용도를 구분하여 데이터(data), 인덱스(index), 임시(temp) 볼륨을 추가하는 예이다.

cubrid createdb --db-volume-size=512M --log-volume-size=256M cubriddb
cubrid addvoldb -p data -n cubriddb_DATA01 --db-volume-size=512M cubriddb
cubrid addvoldb -p data -n cubriddb_DATA02 --db-volume-size=512M cubriddb
cubrid addvoldb -p index -n cubriddb_INDEX01 cubriddb --db-volume-size=512M cubriddb
cubrid addvoldb -p temp -n cubriddb_TEMP01 cubriddb --db-volume-size=512M cubriddb

다음은 cubrid addvoldb에 대한 [options]이다.

--db-volume-size=SIZE

추가되는 데이터베이스 볼륨의 크기를 지정하는 옵션으로, 기본값은 cubrid.conf 에 지정된 시스템 파라미터 db_volume_size 의 값이다. K, M, G, T로 단위를 설정할 수 있으며, 각각 KB(kilobytes), MB(megabytes), GB(gigabytes), TB(terabytes)를 의미한다. 단위를 생략하면 바이트 단위가 적용된다.

다음은 testdb 에 데이터 볼륨을 추가하며 볼륨 크기를 256MB로 지정하는 구문이다.

cubrid addvoldb -p data --db-volume-size=256M testdb
-n, --volume-name=NAME

지정된 데이터베이스에 대하여 추가될 볼륨의 이름을 지정하는 옵션이다. 볼륨명은 운영체제의 파일 이름 규약을 따라야 하고, 디렉터리 경로나 공백을 포함하지 않는 단순한 이름이어야 한다. -n 옵션을 생략하면 추가되는 볼륨의 이름은 시스템에 의해 "데이터베이스 이름_볼륨 식별자"로 자동 부여된다. 예를 들어, 데이터베이스 이름이 testdb이면 자동 부여된 볼륨명은 testdb_x001이 된다.

다음은 독립모드(standalone) 상태에서 testdb라는 데이터베이스에 256MB 볼륨을 추가하는 구문이며, 생성되는 볼륨명은 testdb_v1이 된다.

cubrid addvoldb -S -n testdb_v1 --db-volume-size=256M testdb
-F, --file-path=PATH

지정된 데이터베이스에 대하여 추가될 볼륨이 저장되는 디렉터리 경로를 지정하는 옵션이다. -F 옵션을 생략하면, 시스템 파라미터인 volume_extension_path의 값이 기본값으로 사용된다.

다음은 독립모드(standalone) 상태에서 testdb라는 데이터베이스에 256MB 볼륨을 추가하는 구문이며, 추가 볼륨은 /dbtemp/addvol 디렉터리에 생성된다. 볼륨명에 관한 -n 옵션을 지정하지 않았으므로, 생성되는 볼륨명은 testdb_x001 이 된다.

cubrid addvoldb -S -F /dbtemp/addvol/ --db-volume-size=256M testdb
--comment=COMMENT

추가된 볼륨에 관한 정보 검색을 쉽게 하기 위하여 볼륨에 관한 정보를 주석으로 처리하는 옵션이다. 이때 주석의 내용은 볼륨을 추가하는 DBA의 이름이나 볼륨 추가의 목적을 포함하는 것이 바람직하며, 큰따옴표로 감싸야 한다.

다음은 독립모드(standalone) 상태에서 testdb라는 데이터베이스에 256MB 볼륨을 추가하는 구문이며, 해당 볼륨에 관한 정보를 주석으로 남긴다.

cubrid addvoldb -S --comment "데이터 볼륨 추가_김철수" --db-volume-size=256M testdb
-p, --purpose=PURPOSE

추가할 볼륨의 사용 목적에 따라 볼륨의 종류를 지정하는 옵션이다. 이처럼 볼륨의 사용 목적에 맞는 볼륨을 지정해야 볼륨 종류별로 디스크 드라이브에 분리 저장할 수 있어 I/O 성능을 높일 수 있다. -p 옵션의 파라미터로 가능한 값은 data, index, temp, generic 중 하나이며, 기본값은 generic 이다. 각 볼륨 용도에 관해서는 데이터베이스 볼륨 구조 를 참조한다.

다음은 독립모드(standalone) 상태에서 testdb 라는 데이터베이스에 256MB 인덱스 볼륨을 추가하는 구문이다.

cubrid addvoldb -S -p index --db-volume-size=256M testdb
-S, --SA-mode

서버 프로세스를 구동하지 않고 데이터베이스에 접근하는 독립 모드(standalone)로 작업하기 위해 지정되며, 인수는 없다. -S 옵션을 지정하지 않으면, 시스템은 클라이언트/서버 모드로 인식한다.

cubrid addvoldb -S --db-volume-size=256M testdb
-C, --CS-mode

서버 프로세스와 클라이언트 프로세스를 각각 구동하여 데이터베이스에 접근하는 클라이언트/서버 모드로 작업하기 위한 옵션이며, 인수는 없다. -C 옵션을 지정하지 않더라도 시스템은 기본적으로 클라이언트/서버 모드로 인식한다.

cubrid addvoldb -C --db-volume-size=256M testdb
--max_writesize-in-sec=SIZE

데이터베이스에 볼륨을 추가할 때 디스크 출력량을 제한하여 시스템 운영 영향을 줄이도록 하는 옵션이다. 이 옵션을 통해 1초당 쓸 수 있는 최대 크기를 지정할 수 있으며, 단위는 K(kilobytes), M(megabytes)이다. 최소값은 160K이며, 이보다 작게 값을 설정하면 160K로 바뀐다. 단, 클라이언트/서버 모드(-C)에서만 사용 가능하다.

다음은 2GB 볼륨을 초당 1MB씩 쓰도록 하는 예이다. 소요 시간은 35분( = (2048MB / 1MB) / 60초 ) 정도가 예상된다.

cubrid addvoldb -C --db-volume-size=2G --max-writesize-in-sec=1M testdb

데이터베이스 삭제

cubrid deletedb 는 데이터베이스를 삭제하는 유틸리티이다. 데이터베이스가 몇 개의 상호 의존적 파일들로 만들어지기 때문에, 데이터베이스를 제거하기 위해 운영체제 파일 삭제 명령이 아닌 cubrid deletedb 유틸리티를 사용해야 한다.

cubrid deletedb 유틸리티는 데이터베이스 위치 파일( databases.txt )에 지정된 데이터베이스에 대한 정보도 같이 삭제한다. cubrid deletedb 유틸리티는 오프라인 상에서 즉, 아무도 데이터베이스를 사용하지 않는 상태에서 독립 모드로 사용해야 한다.

cubrid deletedb [options] database_name
  • cubrid: CUBRID 서비스 및 데이터베이스 관리를 위한 통합 유틸리티이다.
  • deletedb: 데이터베이스 및 관련 데이터, 로그, 백업 파일을 전부 삭제하기 위한 명령으로, 데이터베이스 서버가 구동 정지 상태인 경우에만 정상적으로 수행된다.
  • database_name: 디렉터리 경로명을 포함하지 않고, 삭제하고자 하는 데이터베이스의 이름을 지정한다

다음은 cubrid deletedb 에 대한 [options]이다.

-o, --output-file=FILE

데이터베이스를 삭제하면서 출력되는 메시지를 인자로 지정한 파일에 기록하는 명령이다. cubrid deletedb 유틸리티를 사용하면 데이터베이스 위치 정보 파일( databases.txt )에 기록된 데이터베이스 정보가 함께 삭제된다.

cubrid deletedb -o deleted_db.out testdb

만약, 존재하지 않는 데이터베이스를 삭제하는 명령을 입력하면 다음과 같은 메시지가 출력된다.

cubrid deletedb testdb
Database "testdb" is unknown, or the file "databases.txt" cannot be accessed.
-d, --delete-backup

데이터베이스를 삭제하면서 백업 볼륨 및 백업 정보 파일도 함께 삭제할 수 있다. -d 옵션을 지정하지 않으면 백업 볼륨 및 백업 정보 파일은 삭제되지 않는다.

cubrid deletedb -d testdb

데이터베이스 이름 변경, 호스트 변경, 복사/이동, 등록

데이터베이스 이름 변경

cubrid renamedb 유틸리티는 존재하는 데이터베이스의 현재 이름을 변경한다. 정보 볼륨, 로그 볼륨, 제어 파일들이 새로운 이름과 일치되게 이름을 변경한다.

이에 비해 cubrid alterdbhost 유틸리티는 지정된 데이터베이스의 호스트 이름을 설정하거나 변경한다. 즉, databases.txt 에 있는 호스트 이름을 변경한다.

cubrid renamedb [options] src_database_name dest_database_name
  • cubrid: CUBRID 서비스 및 데이터베이스 관리를 위한 통합 유틸리티이다.
  • renamedb: 현재 존재하는 데이터베이스의 이름을 새로운 이름으로 변경하기 위한 명령으로, 데이터베이스가 구동 정지 상태인 경우에만 정상적으로 수행된다. 관련된 정보 볼륨, 로그 볼륨, 제어 파일도 함께 새로 지정된 이름으로 변경된다.
  • src_database_name: 이름을 바꾸고자 하는 현재 존재하는 데이터베이스의 이름이며, 데이터베이스가 생성될 디렉터리 경로명을 포함하지 않는다.
  • dest_database_name: 새로 부여하고자 하는 데이터베이스의 이름이며, 현재 존재하는 데이터베이스 이름과 중복되어서는 안 된다. 이 역시, 데이터베이스가 생성될 디렉터리 경로명을 포함하지 않는다.

다음은 cubrid renamedb 에 대한 [options]이다.

-E, --extented-volume-path=PATH

확장 볼륨의 이름을 변경한 후 새 디렉터리 경로로 이동하는 명령으로서, -E 옵션을 이용하여 변경된 이름을 가지는 확장 볼륨을 이동시킬 새로운 디렉터리 경로(예: /dbtemp/newaddvols/)를 지정한다.

-E 옵션을 주지 않으면, 확장 볼륨은 기존 위치에서 이름만 변경된다. 이때, 기존 데이터베이스 볼륨의 디스크 파티션 외부에 있는 디렉터리 경로 또는 유효하지 않은 디렉터리 경로가 지정되는 경우 데이터베이스 이름 변경 작업은 수행되지 않으며, -i 옵션과 병행될 수 없다.

cubrid renamedb -E /dbtemp/newaddvols/ testdb testdb_1
-i, --control-file FILE

각 볼륨 또는 파일에 대하여 일괄적으로 데이터베이스 이름을 변경하면서 디렉터리 경로를 상이하게 지정하기 위해 디렉터리 정보가 저장된 입력 파일을 지정하는 명령으로서, -i 옵션을 이용한다. 이때, -i 옵션은 -E 옵션과 병행될 수 없다.

cubrid renamedb -i rename_path testdb testdb_1

다음은 개별적 볼륨들의 이름과 현재 디렉터리 경로, 그리고 변경된 이름의 볼륨들이 저장될 디렉터리 경로를 포함하는 파일의 구문 및 예시이다.

volid   source_fullvolname   dest_fullvolname
  • volid: 각 볼륨을 식별하기 위한 정수이며, 데이터베이스 볼륨 정보 제어 파일(database_name_vinf)를 통해 확인할 수 있다.
  • source_fullvolname: 각 볼륨에 대한 현재 디렉터리 경로이다.
  • dest_fullvolname: 이름이 변경된 새로운 볼륨이 이동될 목적지 디렉터리 경로이다. 만약, 목적지 디렉터리가 유효하지 않은 경우 데이터베이스 이름 변경 작업은 수행되지 않는다.
-5  /home1/user/testdb_vinf    /home1/CUBRID/databases/testdb_1_vinf
-4  /home1/user/testdb_lginf   /home1/CUBRID/databases/testdb_1_lginf
-3  /home1/user/testdb_bkvinf   /home1/CUBRID/databases/testdb_1_bkvinf
-2  /home1/user/testdb_lgat   /home1/CUBRID/databases/testdb_1_lgat
 0  /home1/user/testdb   /home1/CUBRID/databases/testdb_1
 1  /home1/user/backup/testdb_x001   /home1/CUBRID/databases/backup/testdb_1_x001
-d, --delete-backup

데이터베이스의 이름을 변경하면서 데이터베이스와 와 동일 위치에 있는 모든 백업 볼륨 및 백업 정보 파일을 함께 강제 삭제하는 명령이다. 일단, 데이터베이스 이름이 변경되면 이전 이름의 백업 파일은 이용할 수 없으므로 주의해야 한다. 만약, -d 옵션을 지정하지 않으면 백업 볼륨 및 백업 정보 파일은 삭제되지 않는다.

cubrid renamedb -d testdb testdb_1

데이터베이스 호스트 변경

cubrid alterdbhost 유틸리티는 지정된 데이터베이스의 호스트 이름을 설정하거나 변경한다. 즉, databases.txt 에 있는 호스트 이름을 변경한다.

cubrid alterdbhost [<option>] database_name
  • cubrid: CUBRID 서비스 및 데이터베이스 관리를 위한 통합 유틸리티이다.
  • alterdbhost: 현 데이터베이스의 호스트 이름을 새로운 이름으로 변경하기 위한 명령이다.

cubrid alterdbhost 에서 사용하는 옵션은 다음과 같다.

-h, --host=HOST

뒤에 변경할 호스트 이름을 지정하며, 옵션을 생략하면 호스트 이름으로 localhost를 지정한다.

데이터베이스 복사/이동

cubrid copydb 유틸리티는 데이터베이스를 한 위치에서 다른 곳으로 복사 또는 이동하며, 인자로 원본 데이터베이스 이름과 새로운 데이터베이스 이름이 지정되어야 한다. 이때, 새로운 데이터베이스 이름은 원본 데이터베이스 이름과 다른 이름으로 지정되어야 하고, 새로운 데이터베이스에 대한 위치 정보는 databases.txt 에 등록된다.

cubrid copydb 유틸리티는 원본 데이터베이스가 정지 상태일 때(오프라인)에만 실행할 수 있다.

cubrid copydb [<options>] src-database-name dest-database-name
  • cubrid: CUBRID 서비스 및 데이터베이스 관리를 위한 통합 유틸리티이다.
  • copydb: 원본 데이터베이스를 새로운 위치로 이동 또는 복사하는 명령이다.
  • src-database-name: 복사 또는 이동하고자 하는 원본 데이터베이스 이름이다.
  • dest-database-name: 새로운 데이터베이스 이름이다.

[options]를 생략하면 원본 데이터베이스를 현재 작업 디렉터리에 복사한다.

cubrid copydb 에 대한 [options]는 다음과 같다.

--server-name=HOST

새로운 데이터베이스의 서버 호스트 이름을 명시하며, 이는 databases.txtdb-host 항목에 등록된다. 이 옵션을 생략하면, 로컬 호스트가 등록된다.

cubrid copydb --server-name=cub_server1 demodb new_demodb
-F, --file-path=PATH

새로운 데이터베이스 볼륨이 저장되는 특정 디렉터리 경로를 지정할 수 있다. 절대 경로로 지정해야 하며, 존재하지 않는 디렉터리를 지정하면 에러를 출력한다. 이 옵션을 생략하면 현재 작업 디렉터리에 새로운 데이터베이스의 볼륨이 생성된다. 이 경로는 databases.txtvol-path 항목에 등록된다.

cubrid copydb -F /home/usr/CUBRID/databases demodb new_demodb
-L, --log-path=PATH

새로운 데이터베이스 로그 볼륨이 저장되는 특정 디렉터리 경로를 지정할 수 있다. 절대 경로로 지정해야 하며, 존재하지 않는 디렉터리를 지정하면 에러를 출력한다. 이 옵션을 생략하면 새로운 데이터베이스 볼륨이 저장되는 경로에 로그 볼륨도 함께 생성된다. 이 경로는 databases.txtlog-path 항목에 등록된다.

cubrid copydb -L /home/usr/CUBRID/databases/logs demodb new_demodb
-E, --extended-volume-path=PATH

새로운 데이터베이스의 확장 정보 볼륨이 저장되는 특정 디렉터리 경로를 지정할 수 있다. 이 옵션을 생략하면 새로운 데이터베이스 볼륨이 저장되는 경로 또는 제어 파일에 등록된 경로에 확장 정보 볼륨이 저장된다. -i 옵션과 병행될 수 없다.

cubrid copydb -E home/usr/CUBRID/databases/extvols demodb new_demodb
-i, --control-file=FILE

대상 데이터베이스에 대한 복수 개의 볼륨들을 각각 다른 디렉터리에 복사 또는 이동하기 위해서, 원본 볼륨의 경로 및 새로운 디렉터리 경로 정보를 포함하는 입력 파일을 지정할 수 있다. 이때, -i 옵션은 -E 옵션과 병행될 수 없다. 아래 예제에서는 copy_path라는 입력 파일을 예로 사용했다.

cubrid copydb -i copy_path demodb new_demodb

다음은 각 볼륨들의 이름과 현재 디렉터리 경로, 그리고 새로 복사할 디렉터리 및 새로운 볼륨 이름을 포함하는 입력 파일의 예시이다.

# volid   source_fullvolname   dest_fullvolname
0 /usr/databases/demodb        /drive1/usr/databases/new_demodb
1 /usr/databases/demodb_data1  /drive1/usr/databases/new_demodb new_data1
2 /usr/databases/ext/demodb index1 /drive2//usr/databases/new_demodb new_index1
3 /usr/ databases/ext/demodb index2  /drive2/usr/databases/new_demodb new_index2
  • volid : 각 볼륨을 식별하기 위한 정수이며, 데이터베이스 볼륨 정보 제어 파일( database_name_vinf )를 통해 확인할 수 있다.
  • source_fullvolname : 원본 데이터베이스의 각 볼륨이 존재하는 현재 디렉터리 경로이다.
  • dest_fullvolname : 새로운 데이터베이스의 각 볼륨이 저장될 디렉터리 경로이며, 유효한 디렉터리를 지정해야 한다.
-r, --replace

새로운 데이터베이스 이름이 기존 데이터베이스 이름과 중복되더라도 에러를 출력하지 않고 덮어쓴다.

cubrid copydb -r -F /home/usr/CUBRID/databases demodb new_demodb
-d 또는 --delete-source

새로운 데이터베이스로 복사한 후, 원본 데이터베이스를 제거한다. 이 옵션이 주어지면 데이터베이스 복사 후 cubrid deletedb 를 수행하는 것과 동일하다. 단, 원본 데이터베이스에 LOB 데이터를 포함하는 경우, 원본 데이터베이스 대한 LOB 파일 디렉터리 경로가 새로운 데이터베이스로 복사되어 databases.txtlob-base-path 항목에 등록된다.

cubrid copydb -d -F /home/usr/CUBRID/databases demodb new_demodb
--copy-lob-path=PATH

원본 데이터베이스에 대한 LOB 파일 디렉터리 경로를 새로운 데이터베이스의 LOB 파일 경로로 복사하고, 원본 데이터베이스를 복사한다. 이 옵션을 생략하면, LOB 파일 디렉터리 경로를 복사하지 않으므로, databases.txt 파일의 lob-base-path 항목을 별도로 수정해야 한다. 이 옵션은 -B 옵션과 병행할 수 없다.

cubrid copydb --copy-lob-path=/home/usr/CUBRID/databases/new_demodb/lob demodb new_demodb
-B, --lob-base-path=PATH

-B 옵션을 사용하여 특정 디렉터리를 새로운 데이터베이스에 대한 LOB 파일 디렉터리 경로를 지정하면서 원본 데이터베이스를 복사한다. 이 옵션은 --copy-lob-path 옵션과 병행할 수 없다.

cubrid copydb -B /home/usr/CUBRID/databases/new_lob demodb new_demodb

데이터베이스 등록

cubrid installdb 유틸리티는 데이터베이스 위치 정보를 저장하는 databases.txt 에 새로 설치된 데이터베이스 정보를 등록한다. 이 유틸리티의 실행은 등록 대상 데이터베이스의 동작에 영향을 끼치지 않는다.

cubrid installdb [<options>] database_name
  • cubrid: CUBRID 서비스 및 데이터베이스 관리를 위한 통합 유틸리티이다.
  • installdb: 이동 또는 복사된 데이터베이스의 정보를 databases.txt 에 등록하는 명령이다.
  • database_name: databases.txt 에 등록하고자 하는 데이터베이스의 이름이다.

[options]를 생략하는 경우, 해당 데이터베이스가 존재하는 디렉터리에서 명령을 수행해야 한다.

cubrid installdb 에 대한 [options]는 다음과 같다.

--server-name=HOST

대상 데이터베이스의 서버 호스트 정보를 지정된 호스트 명으로 databases.txt 에 등록한다. 이 옵션을 생략하면, 현재의 호스트 정보가 등록된다.

cubrid installdb --server-name=cub_server1 testdb
-F, --file-path=PATH

대상 데이터베이스 볼륨의 디렉터리 경로를 databases.txt 에 등록한다. 이 옵션을 생략하면 기본값인 현재 디렉터리 경로가 등록된다.

cubrid installdb -F /home/cubrid/CUBRID/databases/testdb testdb
-L, --log-path=PATH

대상 데이터베이스 로그 볼륨의 디렉터리 경로를 databases.txt 에 등록한다. 이 옵션을 생략하면 데이터베이스 볼륨의 디렉터리 경로가 등록된다.

cubrid installdb -L /home/cubrid/CUBRID/databases/logs/testdb testdb

데이터베이스 백업

데이터베이스 백업은 CUBRID 데이터베이스 볼륨, 제어 파일, 로그 파일을 저장하는 작업으로 cubrid backupdb 유틸리티 또는 CUBRID 매니저를 이용하여 수행된다. DBA 는 저장 매체의 오류 또는 파일 오류 등의 장애에 대비하여 데이터베이스를 정상적으로 복구할 수 있도록 주기적으로 데이터베이스를 백업해야 한다. 이 때 복구 환경은 백업 환경과 동일한 운영체제 및 동일한 버전의 CUBRID가 설치된 환경이어야 한다. 이러한 이유로 데이터베이스를 새로운 버전으로 마이그레이션한 후에는 즉시 새로운 버전의 환경에서 백업을 수행해야 한다.

cubrid backupdb 유틸리티는 모든 데이터베이스 페이지들, 제어 파일들, 데이터베이스를 백업 시와 일치된 상태로 복구하기 위해 필요한 로그 레코드들을 복사한다.

cubrid backupdb [options] database_name

다음은 cubrid backupdb 유틸리티와 결합할 수 있는 옵션을 정리한 표이다. 대소문자가 구분됨을 주의한다.

-D, --destination-path=PATH

지정된 디렉터리에 백업 파일이 저장되도록 하며, 현재 존재하는 디렉터리가 지정되어야 한다. 그렇지 않으면 지정한 이름의 백업 파일이 생성된다. -D 옵션이 지정되지 않으면 백업 파일은 해당 데이터베이스의 위치 정보를 저장하는 파일인 databases.txt 에 명시된 디렉터리에 생성된다.

cubrid backupdb -D /home/cubrid/backup demodb

-D 옵션을 이용하여 현재 디렉터리에 백업 파일이 저장되도록 한다. -D 옵션의 인수로 "."을 입력하면 현재 디렉터리가 지정된다.

cubrid backupdb -D . demodb
-r, --remove-archive

활성 로그(active log)가 꽉 차면 활성 로그를 새로운 보관 로그 파일에 기록한다. 이때 백업을 수행하여 백업 볼륨이 생성되면, 백업 시점 이전의 보관 로그는 추후 복구 작업에 필요 없다. -r 옵션은 백업을 수행한 후에, 추후 복구 작업에 더 이상 사용되지 않을 보관 로그 파일을 제거하는 옵션이다. -r 옵션은 백업 시점 이전의 불필요한 보관 로그만 제거하므로 복구 작업에는 영향을 끼치지 않지만, 관리자가 백업 시점 이후의 보관 로그까지 제거하는 경우 전체 복구가 불가능할 수도 있다. 따라서 보관 로그를 제거할 때에는 추후 복구 작업에 필요한 것인지 반드시 검토해야 한다.

-r 옵션을 사용하여 증분 백업(백업 수준 1 또는 2)을 수행하는 경우, 추후 데이터베이스의 정상 복구가 불가능할 수도 있으므로 -r 옵션은 전체 백업 수행 시에만 사용하는 것을 권장한다.

cubrid backupdb -r demodb
-l, --level=LEVEL

지정된 백업 수준으로 증분 백업을 수행한다. -l 옵션이 지정되지 않으면 전체 백업이 수행된다. 백업 수준에 대한 자세한 내용은 증분 백업 을 참조한다.

cubrid backupdb -l 1 demodb
-o, --output-file=FILE

대상 데이터베이스의 백업에 관한 진행 정보를 info_backup이라는 파일에 기록한다.

cubrid backupdb -o info_backup demodb

다음은 info_backup 파일 내용의 예시로서, 스레드 개수, 압축 방법, 백업 시작 시간, 영구 볼륨의 개수, 백업 진행 정보, 백업 완료 시간 등의 정보를 확인할 수 있다.

[ Database(demodb) Full Backup start ]
- num-threads: 1
- compression method: NONE
- backup start time: Mon Jul 21 16:51:51 2008
- number of permanent volumes: 1
- backup progress status
-----------------------------------------------------------------------------
 volume name                  | # of pages | backup progress status    | done
-----------------------------------------------------------------------------
 demodb_vinf                  |          1 | ######################### | done
 demodb                       |      25000 | ######################### | done
 demodb_lginf                 |          1 | ######################### | done
 demodb_lgat                  |      25000 | ######################### | done
-----------------------------------------------------------------------------
# backup end time: Mon Jul 21 16:51:53 2008
[Database(demodb) Full Backup end]
-S, --SA-mode

독립 모드, 즉 오프라인으로 백업을 수행한다. -S 옵션이 생략되면 클라이언트/서버 모드에서 백업이 수행된다.

cubrid backupdb -S demodb
-C, --CS-mode

클라이언트/서버 모드에서 백업을 수행하며, demodb를 온라인 백업한다. -C 옵션이 생략되면 클라이언트/서버 모드에서 백업이 수행된다.

cubrid backupdb -C demodb
--no-check

대상 데이터베이스의 일관성을 체크하지 않고 백업을 수행한다.

cubrid backupdb --no-check demodb
-t, --thread-count=COUNT

관리자가 임의로 스레드의 개수를 지정함으로써 병렬 백업을 수행한다. -t 옵션의 인수를 지정하지 않더라도 시스템의 CPU 개수만큼 스레드를 자동 부여하여 병렬 백업을 수행한다.

cubrid backupdb -t 4 demodb
-z, --compress

대상 데이터베이스를 압축하여 백업 파일에 저장한다. -z 옵션을 사용하면, 백업 파일의 크기 및 백업 시간을 단축시킬 수 있다.

cubrid backupdb -z demodb
-e, --except-active-log

대상 데이터베이스의 활성 로그(active log)를 포함하지 않고 백업을 수행한다. -e 옵션을 이용하면 활성 로그를 생성하지 않고 백업이 이루어지므로 백업 시간을 단축시킬 수 있으나, 백업 시점 이후 최근 시점까지의 데이터를 복구할 수 없으므로 상당한 주의를 요한다.

cubrid backupdb -e demodb
--sleep-msecs=NUMBER

대상 데이터베이스를 백업하는 도중 쉬는 시간을 설정한다. 단위는 밀리초이며, 기본값은 0 이다. 1MB의 파일을 읽을 때마다 설정한 시간만큼 쉰다. 백업 작업이 과도한 디스크 I/O를 유발하기 때문에, 운영 중인 서비스에 백업 작업으로 인한 영향을 줄이고자 할 때 이 옵션이 사용된다.

cubrid backupdb --sleep-msecs=5 demodb

백업 정책 및 방식

백업을 진행할 때 고려해야 할 사항은 다음과 같다.

  • 백업할 대상 데이터 선별
    • 보존 가치가 있는 유효한 데이터인지 판단한다.
    • 데이터베이스 전체를 백업할 것인지, 일부만 백업할 것인지 결정한다.
    • 데이터베이스와 함께 백업해야 할 다른 파일이 있는지 확인한다.
  • 백업 방식 결정
    • 증분 백업, 온라인 백업 방식을 결정한다. 부가적으로 압축 백업, 병렬 백업 모드 사용 여부를 결정한다.
    • 사용 가능한 백업 도구 및 백업 장비를 준비한다.
  • 백업 시기 판단
    • 데이터베이스 사용이 가장 적은 시간을 파악한다.
    • 보관 로그의 양을 파악한다.
    • 백업할 데이터베이스를 이용하는 클라이언트 수를 파악한다.

온라인 백업

온라인 백업(또는 핫 백업)은 운영 중인 데이터베이스에 대해 백업을 수행하는 방식으로, 특정 시점의 데이터베이스 이미지의 스냅샷을 제공한다. 운영 중인 데이터베이스를 대상으로 백업을 수행하기 때문에 커밋되지 않은 데이터가 저장될 우려가 있고, 다른 데이터베이스 운영에도 영향을 줄 수 있다.

온라인 백업을 하려면 cubrid backupdb -C 명령어를 사용한다.

오프라인 백업

오프라인 백업(또는 콜드 백업)은 정지 상태인 데이터베이스에 대해 백업을 수행하는 방식으로 특정 시점의 데이터베이스 이미지의 스냅샷을 제공한다.

오프라인 백업을 하려면 cubrid backupdb -S 명령어를 사용한다.

증분 백업

증분 백업(incremental backup)은 전체 백업에 종속적으로 수행되는 백업으로 이전에 수행된 백업 이후의 변경된 사항만을 선택적으로 백업하는 방식이다. 이는 전체 백업보다 백업 볼륨이 적고, 백업 소요 시간이 짧다는 장점이 있다. CUBRID는 0, 1, 2의 백업 수준을 제공하며, 낮은 백업 수준으로 백업을 수행한 이후에만 순차적으로 다음 수준의 백업을 수행할 수 있다.

증분 백업을 하려면 cubrid backupdb -l LEVEL 명령어를 사용한다.

다음은 증분 백업에 관한 예시로서, 이를 참조하여 백업 수준에 관해 상세하게 살펴보기로 한다.

../_images/image11.png
  • 전체 백업(백업 수준 0) : 백업 수준 0은 모든 데이터베이스 페이지를 포함하는 전체 백업이다.

    데이터베이스에 최초 시도되는 백업 수준은 당연히 수준 0이 된다. DBA 는 복구 상황을 대비하여 정기적으로 전체 백업을 수행해야 하며, 예시에서는 12월 31일과 1월 5일에 전체 백업을 수행하였다.

  • 1차 증분 백업(백업 수준 1) : 백업 수준 1은 수준 0의 전체 백업 이후의 변경 사항만 저장하는 증분 백업으로서, 이를 "1차 증분 백업"이라 한다.

    주의할 점은 예시의 <1-1>, <1-2>, <1-3>과 같이 1차 증분 백업이 연속적으로 시도되더라도 언제나 수준 0의 전체 백업을 기본으로 증분 백업을 수행한다는 점이다.

    만약, 동일 디렉터리에서 백업 파일이 생성된다고 할 때, 1월 1일에 이미 1차 증분 백업 <1-1>이 수행되고, 1월 2일에 또다시 1차 증분 백업 <1-2>가 시도되면, <1-1>에서 생성된 증분 백업 파일을 덮어쓰게 된다. 1월 3일에 1차 증분 백업이 다시 수행되었으므로, 최종 증분 파일은 이 때 생성된다.

    그러나, 1월 1일이나 1월 2일의 상태로 데이터베이스를 복구해야 하는 상황이 발생될 수 있으므로, DBA 는 최종 증분 파일로 덮어쓰기 전에 <1-1>과 <1-2> 각각의 증분 백업 파일을 저장 매체에 별도로 보관하는 것이 좋다.

  • 2차 증분 백업(백업 수준 2) : 백업 수준 2는 1차 증분 백업 이후의 변경 사항만 저장하는 증분 백업으로 이를 "2차 증분 백업"이라 한다.

    1차 증분 백업이 선행되어야만 2차 증분 백업을 수행할 수 있으므로, 1월 4일에 시도한 2차 증분 백업 시도는 성공할 것이고, 1월 6일에 시도한 2차 증분 백업 시도는 당연히 허용되지 않을 것이다.

    이러한 백업 수준 0, 1, 2로 생성된 백업 파일들은 모두 데이터베이스를 복구할 때 필요하므로, 2차 증분 백업이 완료된 1월 4일의 상태로 데이터베이스를 복구하기 위해서는 <2-1>에서 생성된 2차 증분 백업 파일, <1-3>에서 생성된 1차 증분 백업 파일, <0-1>에서 생성된 전체 백업 파일이 모두 필요하다. 즉, 완전한 복구를 위해서는 직전에 생성된 증분 백업 파일로부터 이전 최종으로 생성된 전체 백업 파일이 요구된다.

압축 백업 모드

압축 백업(compress backup)은 데이터베이스를 압축하여 백업을 수행하기 때문에 백업 볼륨의 크기가 줄어들어 디스크 I/O 비용을 감소시킬 수 있고, 디스크 공간을 절약할 수 있다.

압축 백업을 하려면 cubrid backupdb -z | --compress 명령어를 사용한다.

병렬 백업 모드

병렬 백업 또는 다중 백업(multi-thread backup)은 지정된 스레드 개수만큼 동시 백업을 수행하기 때문에 백업 시간을 크게 단축시켜 준다. 기본적으로 시스템의 CPU 수만큼 스레드를 부여하게 된다.

병렬 백업을 하려면 cubrid backupdb -t | --thread-count 명령어를 사용한다.

백업 파일 관리

백업 대상 데이터베이스의 크기에 따라 하나 이상의 백업 파일이 연속적으로 생성될 수 있으며, 각각의 백업 파일의 확장자에는 생성 순서에 따라 000, 001~0xx와 같은 유닛 번호가 순차적으로 부여된다.

백업 작업 중 디스크 용량 관리

백업 작업 도중, 백업 파일이 저장되는 디스크 용량에 여유가 없는 경우 백업 작업을 진행할 수 없다는 안내 메시지가 화면에 나타난다. 안내 메시지에는 백업 대상이 되는 데이터베이스의 이름과 경로명, 백업 파일명, 백업 파일의 유닛 번호, 백업 수준이 표시된다. 백업 작업을 계속 진행하려는 관리자는 다음과 같이 옵션을 선택할 수 있다.

  • 옵션 0 : 백업 작업을 더이상 진행하지 않을 경우, 0을 입력한다.
  • 옵션 1 : 백업 작업을 진행하기 위해 관리자는 현재 장치에 새로운 디스크를 삽입한 후 1을 입력한다.
  • 옵션 2 : 백업 작업을 진행하기 위해 관리자는 장치를 변경하거나 백업 파일이 저장되는 디렉터리 경로를 변경한 후 2를 입력한다.
******************************************************************
Backup destination is full, a new destination is required to continue:
Database Name: /local1/testing/demodb
     Volume Name: /dev/rst1
        Unit Num: 1
    Backup Level: 0 (FULL LEVEL)
Enter one of the following options:
Type
   -  0 to quit.
   -  1 to continue after the volume is mounted/loaded. (retry)
   -  2 to continue after changing the volume's directory or device.
******************************************************************

보관 로그 관리

운영체제의 파일 삭제 명령(rm, del)을 사용하여 보관 로그(archive log)를 임의로 삭제해서는 안 되며, 시스템의 설정, cubrid backupdb 유틸리티 또는 서버 프로세스에 의해 보관 로그가 삭제되어야 한다. 보관 로그가 삭제될 수 있는 경우는 다음의 3가지이다.

  • HA 환경에서 force_remove_log_archives 를 no로 설정하고, log_max_archives 개수를 지정하여 삭제한다(복제 반영 후 삭제됨).
  • HA가 아닌 환경에서 force_remove_log_archives 를 yes(기본값)로 설정하고, log_max_archives 개수를 지정하여 삭제한다(처음 제품 설치 시 log_max_archives 의 개수는 0으로 설정됨).
  • cubrid backupdb -r 로 삭제한다(HA 환경에서는 사용하면 안 됨).

즉, 데이터베이스 운영 중에 보관 로그 볼륨을 가급적 남기고 싶지 않다면 cubrid.conf 에 설정하는 시스템 파라미터인 log_max_archives 의 값을 0 또는 작은 값으로 설정하고, force_remove_log_archives 의 값을 yes로 설정한다. 단, HA 환경에서는 force_remove_log_archives 의 값이 yes이면 슬레이브 노드에 복제되지 않은 보관 로그가 삭제되어 복제가 잘못될 수 있으므로, no로 설정할 것을 권장한다. force_remove_log_archives 의 값이 no이더라도 복제 반영이 끝난 파일은 HA 관리 프로세스에 의해 삭제될 수 있다.

데이터베이스 복구

데이터베이스 복구는 동일 버전의 CUBRID 환경에서 수행된 백업 작업에 의해 생성된 백업 파일, 활성 로그 및 보관 로그를 이용하여 특정 시점의 데이터베이스로 복구하는 작업이다. 데이터베이스 복구를 진행하려면 cubrid restoredb 유틸리티 또는 CUBRID 매니저를 사용한다.

cubrid restoredb 유틸리티는 백업이 수행된 이후에 모든 보관 및 활동 로그들에 기록된 정보들을 이용하여 데이터베이스 백업으로부터 데이터베이스를 복구한다.

cubrid restoredb [options] database_name

어떠한 옵션도 지정되지 않은 경우 기본적으로 마지막 커밋 시점까지 데이터베이스가 복구된다. 만약, 마지막 커밋 시점까지 복구하기 위해 필요한 활성 로그/보관 로그 파일이 없다면 마지막 백업 시점까지만 부분 복구된다.

cubrid restoredb demodb

다음은 cubrid restoredb 유틸리티와 결합할 수 있는 옵션을 정리한 표이다. 대소문자가 구분됨을 주의한다.

-d, --up-to-date=DATE

-d 옵션으로 지정된 날짜-시간까지 데이터베이스를 복구한다. 사용자는 dd-mm-yyyy:hh:mi:ss(예: 14-10-2008:14:10:00)의 형식으로 복구 시점을 직접 지정할 수 있다. 만약 지정한 복구 시점까지 복구하기 위해 필요한 활성 로그/보관 로그 파일이 없다면 마지막 백업 시점까지만 부분 복구된다.

cubrid restoredb -d 14-10-2008:14:10:00 demodb

backuptime 이라는 키워드를 복구 시점으로 지정하면 데이터베이스를 마지막 백업이 수행된 시점까지 복구한다.

cubrid restoredb -d backuptime demodb
--list

대상 데이터베이스의 백업 파일에 관한 정보를 화면에 출력하며 복구는 수행하지 않는다.

cubrid restoredb --list demodb

다음은 --list 옵션에 의해 출력되는 백업 정보의 예로서, 복구 작업을 수행하기 이전에 대상 데이터베이스의 백업 파일이 최초 저장된 경로와 백업 수준을 검증할 수 있다.

*** BACKUP HEADER INFORMATION ***
Database Name: /local1/testing/demodb
 DB Creation Time: Mon Oct 1 17:27:40 2008
         Pagesize: 4096
Backup Level: 1 (INCREMENTAL LEVEL 1)
        Start_lsa: 513|3688
         Last_lsa: 513|3688
Backup Time: Mon Oct 1 17:32:50 2008
 Backup Unit Num: 0
Release: 8.1.0
     Disk Version: 8
Backup Pagesize: 4096
Zip Method: 0 (NONE)
        Zip Level: 0 (NONE)
Previous Backup level: 0 Time: Mon Oct 1 17:31:40 2008
(start_lsa was -1|-1)
Database Volume name: /local1/testing/demodb_vinf
     Volume Identifier: -5, Size: 308 bytes (1 pages)
Database Volume name: /local1/testing/demodb
     Volume Identifier: 0, Size: 2048000 bytes (500 pages)
Database Volume name: /local1/testing/demodb_lginf
     Volume Identifier: -4, Size: 165 bytes (1 pages)
Database Volume name: /local1/testing/demodb_bkvinf
     Volume Identifier: -3, Size: 132 bytes (1 pages)

--list 옵션을 이용하여 출력된 백업 정보를 확인하면, 백업 파일이 백업 수준 1로 생성되었고, 이전 백업 수준 0의 전체 백업이 수행된 시점을 확인할 수 있다. 따라서, 예시된 데이터베이스의 복구를 위해서는 백업 수준 0인 백업 파일과 백업 수준 1인 백업 파일이 준비되어야 한다.

-B, --backup-file-path=PATH

백업 파일이 위치하는 디렉터리를 지정할 수 있다. 만약, 이 옵션이 지정되지 않으면 시스템은 데이터베이스 위치 정보 파일인 databases.txt 에 지정된 log-path 디렉터리에서 대상 데이터베이스를 백업했을 때 생성된 백업 정보 파일(dbname _bkvinf)을 검색하고, 백업 정보 파일에 지정된 디렉터리 경로에서 백업 파일을 찾는다. 그러나, 백업 정보 파일이 손상되거나 백업 파일의 위치 정보가 삭제된 경우라면 시스템이 백업 파일을 찾을 수 없으므로, 관리자가 -B 옵션을 이용하여 백업 파일이 위치하는 디렉터리 경로를 직접 지정해야 한다.

cubrid restoredb -B /home/cubrid/backup demodb

데이터베이스의 백업 파일이 현재 디렉터리에 있는 경우, 관리자는 -B 옵션을 이용하여 백업 파일이 위치하는 디렉터리를 지정할 수 있다.

cubrid restoredb -B . demodb
-l, --level=LEVEL

대상 데이터베이스의 백업 수준(0, 1, 2)을 지정하여 복구를 수행한다. 백업 수준에 대한 자세한 내용은 증분 백업 을 참조한다.

cubrid restoredb -l 1 demodb
-p, --partial-recovery

사용자 응답을 요청하지 않고 부분 복구를 수행하라는 명령이다. 백업 시점 이후에 기록된 활성 로그나 보관 로그가 완전하지 않을 때 기본적으로 시스템은 로그 파일이 필요하다는 것을 알리면서 실행 옵션을 입력하라는 요청 메시지를 출력하는데, -p 옵션을 이용하면 이러한 요청 메시지의 출력 없이 직접 부분 복구를 수행할 수 있다. 따라서, -p 옵션을 이용하여 복구를 수행하면 언제나 마지막 백업 시점까지 데이터가 복구된다.

cubrid restoredb -p demodb

-p 옵션이 지정되지 않은 경우, 사용자에게 실행 옵션을 선택하라는 요청 메시지는 다음과 같다.

***********************************************************
Log Archive /home/cubrid/test/log/demodb_lgar002
 is needed to continue normal execution.
   Type
   -  0 to quit.
   -  1 to continue without present archive. (Partial recovery)
   -  2 to continue after the archive is mounted/loaded.
   -  3 to continue after changing location/name of archive.
***********************************************************
  • 옵션 0 : 복구 작업을 더이상 진행하지 않을 경우, 0을 입력한다.
  • 옵션 1 : 로그 파일 없이 부분 복구를 진행하려면, 1을 입력한다.
  • 옵션 2 : 복구 작업을 진행하기 위해 관리자는 현재 장치에 보관 로그를 위치시킨 후 2를 입력한다.
  • 옵션 3 : 복구 작업을 계속하기 위해 관리자는 로그 위치를 변경한 후 3을 입력한다.
-o, --output-file=FILE

대상 데이터베이스의 복구에 관한 진행 정보를 info_restore라는 파일에 기록하는 명령이다.

cubrid restoredb -o info_restore demodb
-u, --use-database-location-path

데이터베이스 위치 정보 파일(databases.txt)에 지정된 경로에서 대상 데이터베이스를 복구하는 구문이다. -u 옵션은 A 서버에서 백업을 수행하고 B 서버에서 백업 파일을 복구하고자 할 때 사용할 수 있는 유용한 옵션이다.

cubrid restoredb -u demodb

복구 정책과 절차

데이터베이스를 복구할 때 고려해야 할 사항은 다음과 같다.

  • 백업 파일 준비
    • 백업 파일 및 로그 파일이 저장된 디렉터리를 파악한다.
    • 증분 백업으로 대상 데이터베이스가 백업된 경우, 각 백업 수준에 따른 백업 파일이 존재하는지를 파악한다.
    • 백업이 수행된 CUBRID 데이터베이스의 버전과 복구가 이루어질 CUBRID 데이터베이스 버전이 동일한지를 파악한다.
  • 복구 방식 결정
    • 부분 복구인지 전체 복구인지를 결정한다.
    • 증분 백업 파일을 이용한 복구인지를 결정한다.
    • 사용 가능한 복구 도구 및 복구 장비를 준비한다.
  • 복구 시점 판단
    • 데이터베이스 서버가 종료된 시점을 파악한다.
    • 장애 발생 전에 이루어진 마지막 백업 시점을 파악한다.
    • 장애 발생 전에 이루어진 마지막 커밋 시점을 파악한다.

데이터베이스 복구 절차

다음은 백업 및 복구 작업의 절차를 시간별로 예시한 것이다.

  1. 2008/8/14 04:30분에 운영이 중단된 demodb 를 전체 백업을 수행한다.
  2. 2008/8/14 10:00분에 운영 중인 demodb 를 1차 증분 백업 수행한다.
  3. 2008/8/14 15:00분에 운영 중인 demodb 를 1차 증분 백업을 수행한다. 2번의 1차 증분 백업 파일을 덮어쓴다.
  4. 2008/8/14 15:30분에 시스템 장애가 발생하였고, 관리자는 demodb 의 복구 작업을 준비한다. 장애 발생 이전의 마지막 커밋 시점이 15:25분이므로 이를 복구 시점으로 지정한다.
  5. 관리자는 1.에서 생성된 전체 백업 파일 및 3.에서 생성된 1차 증분 백업 파일, 활성 로그 및 보관 로그를 준비하여 마지막 커밋 시점인 15:25 시점까지 demodb 를 복구한다.
Time Command 설명
2008/8/14 04:25 cubrid server stop demodb demodb 운영을 중단한다.
2008/8/14 04:30 cubrid backupdb -S -D /home/backup -l 0 demodb 오프라인에서 demodb 를 전체 백업하여 지정된 디렉터리에 백업 파일을 생성한다.
2008/8/14 05:00 cubrid server start demodb demodb 운영을 시작한다.
2008/8/14 10:00 cubrid backupdb -C -D /home/backup -l 1 demodb 온라인에서 demodb 를 1차 증분 백업하여 지정된 디렉터리에 백업 파일을 생성한다.
2008/8/14 15:00 cubrid backupdb -C -D /home/backup -l 1 demodb 온라인에서 demodb 를 1차 증분 백업하여 지정된 디렉터리에 백업 파일을 생성한다. 10:00에 생성된 1차 증분 백업파일을 덮어쓴다.
2008/8/14 15:30   시스템 장애가 발생한 시각이다.
2008/8/14 15:40 cubrid restoredb -l 1 -d 08/14/2008:15:25:00 demodb 전체 백업 파일, 1차 증분 백업 파일, 활성 로그 및 보관 로그를 기반으로 demodb 를 복구한다. 전체 백업 파일, 1차 증분된 백업 파일, 활성 로그 및 보관 로그에 의해 15:25 시점까지 복구된다.

다른 서버로의 데이터베이스 복구

다음은 A 서버에서 demodb 를 백업하고, 백업된 파일을 기반으로 B 서버에서 demodb 를 복구하는 방법이다.

백업 환경과 복구 환경

A 서버의 /home/cubrid/db/demodb 디렉터리에서 demodb 를 백업하고, B 서버의 /home/cubrid/data/demodb 디렉터리에 demodb 를 복구하는 것으로 가정한다.

../_images/image12.png
  1. A 서버에서 백업

    A 서버에서 demodb 를 백업한다. 이전에 백업을 수행하였다면 이후 변경된 부분만 증분 백업을 수행할 수 있다. 백업 파일이 생성되는 디렉터리는 -D 옵션에 의해 지정하지 않으면, 기본적으로 로그 볼륨이 저장되는 위치에 생성된다. 다음은 권장되는 옵션을 사용한 백업 명령이며, 옵션에 관한 보다 자세한 내용은 데이터베이스 백업 을 참조한다.

    cubrid backupdb -z demodb
    
  2. B 서버에서 데이터베이스 위치 정보 파일 편집

    동일한 서버에서 백업 및 복구 작업이 이루어지는 일반적인 시나리오와는 달리, 타 서버 환경에서 백업 파일을 복구하는 시나리오에서는 B 서버의 데이터베이스 위치 정보 파일(databases.txt)에서 데이터베이스를 복구할 위치 정보를 추가해야 한다. 위 그림에서는 B 서버(호스트명은 pmlinux)의 /home/cubrid/data/demodb 디렉터리에 demodb 를 복구하는 것을 가정하였으므로, 이에 따라 데이터베이스 위치 정보 파일을 편집하고, 해당 디렉터리를 B 서버에서 생성한다.

    데이터베이스 위치 정보는 한 라인으로 작성하고, 각 항목은 공백으로 구분한다. 한 라인은 [데이터베이스명] [데이터볼륨경로] [호스트명] [로그볼륨경로]의 형식으로 작성한다. 따라서 다음과 같이 demodb 의 위치 정보를 작성한다.

    demodb /home/cubrid/data/demodb pmlinux /home/cubrid/data/demodb
    
  3. B 서버로 백업 파일 및 로그 파일 전송

    복구를 위해서는 대상 데이터베이스의 백업 파일(예: demodb_bk0v000) 및 백업 정보 파일(예:demodb_bkvinf)이 필수적으로 준비되어야 하고, 마지막 커밋 시점까지 전체 데이터를 복구하기 위해서는 활성 로그(예: demodb_lgat) 및 보관 로그(예: demodb_lgar000)가 준비되어야 한다. 따라서, A 서버에서 생성된 백업 파일, 백업 정보 파일, 활성 로그 파일, 보관 로그 파일을 B 서버에 전송한다. 즉, B 서버의 임의 디렉터리(예: /home/cubrid/temp)에는 백업 파일, 백업 정보 파일, 활성 로그 파일, 보관 로그 파일이 위치해야 한다.

  4. B 서버에서 복구

    B 서버로 전송한 백업 파일, 백업 정보 파일, 활성 로그 파일, 보관 로그 파일이 있는 디렉터리에서 cubrid restoredb 유틸리티를 호출하여 데이터베이스 복구 작업을 수행한다. -u 옵션에 의해 databases.txt 에 지정된 디렉터리 경로에 demodb 가 복구된다.

    cubrid restoredb -u demodb
    

    만약, 다른 위치에서 cubrid restoredb 유틸리티를 호출하려면, 다음과 같이 -B 옵션을 이용하여 백업 파일이 위치하는 디렉터리 경로를 지정해야 한다.

    cubrid restoredb -u -B /home/cubrid/temp demodb
    
  5. B 서버에서 복구한 데이터베이스를 다시 백업

    대상 데이터베이스의 복구가 완료되면, 해당 데이터베이스를 구동하여 정상적으로 복구되었는지를 확인한다. 또한, 복구한 데이터베이스를 안정적으로 관리하기 위해서는 B 서버 환경에서 대상 데이터베이스를 새로 백업하는 것이 좋다.

내보내기와 가져오기

신규 버전의 CUBRID 데이터베이스를 사용하기 위해서는 기존 버전의 CUBRID 데이터베이스를 신규 버전의 CUBRID 데이터베이스로 이전하는 작업을 진행해야 할 경우가 있다. 이때 CUBRID에서 제공하는 텍스트 파일로 내보내기와 텍스트 파일에서 가져오기 기능을 활용할 수 있다.

데이터베이스 내보내기(unload)

데이터베이스를 언로드/로드하는 목적은 다음과 같다.

  • 데이터베이스 볼륨을 재구성하여 데이터베이스 재구축
  • 시스템이 다른 환경에서 마이그레이션 수행
  • 버전이 다른 DBMS에서 마이그레이션 수행
cubrid unloaddb [options] database_name

cubrid unloaddb 가 생성하는 파일은 다음과 같다.

  • 스키마 파일(database-name_schema): 해당 데이터베이스에 정의된 스키마 정보를 포함하는 파일이다.
  • 객체 파일(database-name_objects): 해당 데이터베이스에 포함된 인스턴스 정보를 포함하는 파일이다.
  • 인덱스 파일(database-name_indexes): 해당 데이터베이스에 정의된 인덱스 정보를 포함하는 파일이다.
  • 트리거 파일(database-name_trigger): 해당 데이터베이스에 정의된 트리거 정보를 포함하는 파일이다. 만약 데이터를 로딩하는 동안 트리거가 구동되는 것을 원치 않는다면, 데이터 로딩을 완료한 후에 트리거 정의를 로딩하면 된다.

이러한 스키마, 객체, 인덱스, 트리거 파일은 같은 디렉터리에 생성된다.

다음은 cubrid unloaddb 에서 사용하는 [options]이다.

-i, --input-class-file=FILE

인수로 지정된 입력 파일에 지정된 클래스만을 대상으로 데이터베이스를 언로드한다.

cubrid unloaddb -i table_list.txt demodb

다음은 입력 파일 table_list.txt의 예이다.

table_1
table_2
..
table_n

-i 옵션이 --input-class-only 와 결합되면, 입력 파일에 포함된 테이블에 관한 스키마 파일만 생성된다.

cubrid unloaddb --input-class-only -i table_list.txt demodb

-i 옵션이 --include-reference 와 결합되면, 객체 참조도 함께 생성된다.

cubrid unloaddb --include-reference -i table_list.txt demodb
--include-reference

-i 옵션과 함께 사용되며, 객체 참조도 함께 생성한다.

--input-class-only

-i 옵션과 함께 사용되며, 입력 파일에 포함된 테이블에 관한 스키마 파일만 생성한다.

--lo-count=COUNT

한 디렉터리에 생성될 큰 객체(LO) 데이터 파일의 수를 설정한다(기본값: 0).

--estimated-size=NUMBER

언로드할 데이터베이스의 레코드 저장을 위한 해시 메모리를 사용자 임의로 할당하기 위한 옵션이다. 만약 --estimated-size 옵션이 지정되지 않으면 최근의 통계 정보를 기반으로 데이터베이스의 레코드 수를 결정하게 되는데, 만약 최근 통계 정보가 갱신되지 않았거나 해시 메모리를 크게 할당하고 싶은 경우 이 옵션을 이용할 수 있다. 따라서, 옵션의 인수로 너무 적은 레코드 개수를 정의한다면 해시 충돌로 인해 언로드 성능이 저하된다.

cubrid unloaddb --estimated-size=1000 demodb
--cached-pages=NUMBER

메모리에 캐시되는 테이블의 페이지 수를 지정하기 위한 옵션이다. 각 페이지는 4,096 바이트이며, 관리자는 메모리의 크기와 속도를 고려하여 캐시되는 페이지 수를 지정할 수 있다. 만약, 이 옵션이 지정되지 않으면 기본값은 100페이지가 된다.

cubrid unloaddb --cached-pages 500 demodb
-O, --output-path=PATH

스키마와 객체 파일이 생성될 디렉터리를 지정한다. 옵션이 지정되지 않으면 현재 디렉터리에 생성된다.

cubrid unloaddb -O ./CUBRID/Databases/demodb demodb

지정된 디렉터리가 존재하지 않는 경우 다음과 같은 에러 메시지가 출력된다.

unloaddb: No such file or directory.
-s, --schema-only

언로드 작업을 통해 생성되는 출력 파일 중 스키마 파일만 생성되도록 지정하는 옵션이다.

cubrid unloaddb -s demodb
-d, --data-only

언로드 작업을 통해 생성되는 출력 파일 중 데이터 파일만 생성되도록 지정하는 옵션이다.

cubrid unloaddb -d demodb
--output-prefix=PREFIX

언로드 작업에 의해 생성되는 스키마 파일과 객체 파일의 이름 앞에 붙는 prefix를 지정하기 위한 옵션이다. 예제를 수행하면 스키마 파일명은 abcd_schema 가 되고, 객체 파일명은 abcd_objects 가 된다. 만약, --output-prefix 옵션을 지정하지 않으면 언로드할 데이터베이스 이름이 prefix로 사용된다.

cubrid unloaddb --output-prefix abcd demodb
--hash-file=FILE

해시 파일의 이름을 지정한다.

-v, --verbose

언로드 작업이 진행되는 동안 언로드되는 데이터베이스의 테이블 및 인스턴스에 관한 상세 정보를 화면에 출력하는 옵션이다.

cubrid unloaddb -v demodb
--use-delimiter

식별자의 시작과 끝에 겹따옴표(")를 기록한다. 기본 설정은 식별자의 시작과 끝에 겹따옴표를 기록하지 않는다.

-S, --SA-mode

독립 모드에서 데이터베이스를 언로드한다.

cubrid unloaddb -S demodb
-C, --CS-mode

클라이언트/서버 모드에서 데이터베이스를 언로드한다.

cubrid unloaddb -C demodb
--datafile-per-class

언로드 작업으로 생성되는 데이터 파일을 각 테이블별로 생성되도록 지정하는 옵션이다. 파일 이름은 <데이터베이스 이름>_<테이블 이름>_objects 로 생성된다. 단, 객체 타입의 칼럼 값은 모두 NULL 로 언로드되며, 언로드된 파일에는 %id class_name class_id 부분이 작성되지 않는다. 자세한 내용은 가져오기용 파일 작성 방법 을 참고한다.

cubrid unloaddb --datafile-per-class demodb

데이터베이스 가져오기(load)

데이터베이스 로드는 다음과 같은 경우에 cubrid loaddb 유틸리티를 이용하여 수행된다.

  • 이전 버전의 CUBRID 데이터베이스를 새로운 버전의 데이터베이스로 마이그레이션하는 경우
  • 타 DBMS의 데이터베이스를 CUBRID 데이터베이스로 마이그레이션하는 경우
  • INSERT 구문 실행보다 빠른 성능으로 대용량 데이터를 입력하는 경우

일반적으로 cubrid loaddb 유틸리티는 cubrid unloaddb 유틸리티가 생성한 파일(스키마 정의 파일, 객체 입력 파일, 인덱스 정의 파일)을 사용한다.

cubrid loaddb [options] database_name

입력 파일

  • 스키마 파일(database-name_schema): 언로드 작업에 의해 생성된 파일로서, 데이터베이스에 정의된 스키마 정보를 포함하는 파일이다.
  • 객체 파일(database-name_objects): 언로드 작업에 의해 생성된 파일로서, 데이터베이스에 포함된 레코드 정보를 포함하는 파일이다.
  • 인덱스 파일(database-name_indexes): 언로드 작업에 의해 생성된 파일로서, 데이터베이스에 정의된 인덱스 정보를 포함하는 파일이다.
  • 트리거 파일(database-name_trigger): 언로드 작업에 의해 생성된 파일로서, 데이터베이스에 정의된 트리거 정보를 포함하는 파일이다.
  • 사용자 정의 객체 파일(user_defined_object_file) : 대용량 데이터 입력을 위해 사용자가 테이블 형식으로 작성한 입력 파일이다(가져오기용 파일 작성 방법 참고).

다음은 cubrid loaddb 에서 사용하는 [options]이다.

-u, --user=ID

레코드를 로딩할 데이터베이스의 사용자 계정을 지정한다. 옵션을 지정하지 않으면 기본값은 PUBLIC 이 된다.

cubrid loaddb -u admin -d demodb_objects newdb
-p, --password=PASS

레코드를 로딩할 데이터베이스의 사용자 암호를 지정한다. 옵션을 지정하지 않으면 암호 입력을 요청하는 프롬프트가 출력된다.

cubrid loaddb -p admin -d demodb_objects newdb
--data-file-check-only

demodb_objects에 포함된 데이터의 구문이 정상인지 확인만 하며 데이터를 데이터베이스에 로딩하지 않는다.

cubrid loaddb --data-file-check-only -d demodb_objects newdb
-l, --load-only

로딩할 데이터의 구문을 확인하지 않고 곧바로 데이터를 로딩한다. -l 옵션을 사용하면 demodb_objects에 포함된 데이터의 구문을 확인하지 않고 곧바로 데이터를 로딩하기 때문에 속도는 빠르지만, 오류가 발생할 수도 있다.

cubrid loaddb -l -d demodb_objects newdb
--estimated-size=NUMBER

언로드할 레코드의 수가 기본값인 5,000개보다 많은 경우 로딩 성능 향상을 위해 사용할 수 있다. 이 옵션을 통해 레코드 저장을 위한 해시 메모리를 크게 할당함으로써 로드 성능을 향상시킬 수 있다.

cubrid loaddb --estimated-size 8000 -d demodb_objects newdb
-v, --verbose

데이터베이스 로딩 작업이 진행되는 동안, 로딩되는 데이터베이스의 테이블 및 레코드에 관한 상세 정보를 화면에 출력한다. 진행 단계, 로딩되는 클래스, 입력된 레코드의 개수와 같은 상세 정보를 확인할 수 있다.

cubrid loaddb -v -d demodb_objects newdb
-c, --periodic-commit=COUNT

지정한 개수의 레코드가 데이터베이스에 입력될 때마다 커밋을 주기적으로 실행한다. 만약, -c 옵션을 지정하지 않으면 데이터 파일에 포함된 모든 레코드가 데이터베이스로 로딩된 후에 트랜잭션이 커밋된다. 또한, -c 옵션이 -s 옵션이나 -i 옵션과 함께 사용하는 경우에는 100개의 DDL문이 로딩될 때마다 커밋을 주기적으로 실행한다.

권장되는 커밋 주기는 로딩되는 데이터에 따라 다른데, 스키마 로딩의 경우에는 -c의 인수를 50으로 설정하고, 레코드로딩의 경우에는 1,000으로 설정하며, 인덱스 로딩의 경우에는 1로 설정하는 것이 바람직하다.

cubrid loaddb -c 100 -d demodb_objects newdb
--no-oid

demodb_objects에 포함된 OID를 무시하고 레코드를 newdb로 로딩하는 명령이다.

cubrid loaddb --no-oid -d demodb_objects newdb
--no-statistics

demodb_objects를 로딩한 후 newdb의 통계 정보를 갱신하지 않는 명령이다. 특히, 대상 데이터베이스의 데이터 용량에 비해 매우 적은 데이터만 로딩할 경우 이 옵션을 이용하여 로드 성능을 향상시킬 수 있다.

cubrid loaddb --no-statistics -d demodb_objects newdb
-s, --schema-file=FILE[:LINE]

스키마 파일의 LINE번째부터 정의된 스키마 정보를 새로 생성한 newdb에 로딩하는 구문이다. 다음 예제에서 demodb_schema 파일은 언로드 작업에 의해 생성된 파일이며 언로드된 데이터베이스의 스키마 정보를 포함한다. -s 옵션을 이용하여 스키마 정보를 먼저 로딩한 후, 실제 레코드를 로딩할 수 있다.

cubrid loaddb -u dba -s demodb_schema newdb

Start schema loading.
Total       86 statements executed.
Schema loading from demodb_schema finished.
Statistics for Catalog classes have been updated.

다음은 demodb에 정의된 트리거 정보를 새로 생성한 newdb에 로딩하는 구문이다. demodb_trigger 파일은 언로드 작업에 의해 생성된 파일이며, 언로드된 데이터베이스의 트리거 정보를 포함한다. 레코드를 모두 로딩한 후, -s 옵션을 이용하여 트리거를 생성할 것을 권장한다.

cubrid loaddb -u dba -s demodb_trigger newdb
-i, --index-file=FILE[:LINE]

인덱스 파일의 LINE번째부터 정의된 인덱스 정보를 데이터베이스에 로딩하는 명령이다. 다음 예제에서, demo_indexes 파일은 언로드 작업에 의해 생성된 파일이며 언로드된 데이터베이스의 인덱스 정보를 포함한다. -d 옵션을 이용하여 레코드를 로딩한 후, -i 옵션을 이용하여 인덱스를 생성할 수 있다.

cubrid loaddb -c 100 -d demodb_objects newdb
cubrid loaddb -u dba -i demodb_indexes newdb
-d, --data-file=FILE

-d 옵션을 이용하여 데이터 파일 또는 사용자 정의 객체 파일을 지정함으로써 레코드 정보를 newdb로 로딩하는 명령이다. demodb_objects 파일은 언로드 작업에 의해 생성된 객체 파일이거나, 사용자가 대량의 데이터 로딩을 위하여 작성한 사용자 정의 객체 파일 중 하나이다.

cubrid loaddb -u dba -d demodb_objects newdb
-t, --table=TABLE

로딩할 데이터 파일에 테이블 이름 헤더가 생략되어 있는 경우, 이 옵션 뒤에 테이블 이름을 지정한다.

cubrid loaddb -u dba -d demodb_objects -t tbl_name newdb
--error-control-file=FILE

데이터베이스 로드 작업 중에 발생하는 에러 중 특정 에러를 처리하는 방식에 관해 명세한 파일을 지정하는 옵션이다.

cubrid loaddb --error-control-file=error_test -d demodb_objects newdb

서버 에러 코드 이름은 $CUBRID/include/dbi.h 파일을 참고하도록 한다.

에러 코드(에러 번호) 별 에러 메시지는 $CUBRID/msg/<문자셋 이름>/cubrid.msg 파일의 $set 5 MSGCAT_SET_ERROR 이하에 있는 번호들을 참고하도록 한다.

vi $CUBRID/msg/en_US/cubrid.msg

$set 5 MSGCAT_SET_ERROR
1 Missing message for error code %1$d.
2 Internal system failure: no more specific information is available.
3 Out of virtual memory: unable to allocate %1$ld memory bytes.
4 Has been interrupted.
...
670 Operation would have caused one or more unique constraint violations.
...

특정 에러 명세 파일의 형식은 다음과 같다.

  • -<에러 코드> : <에러 코드>에 해당하는 에러를 무시하도록 설정 (loaddb 수행 중 해당 에러가 발생해도 계속 수행)
  • +<에러 코드> : <에러 코드>에 해당하는 에러를 무시하지 않도록 설정 (loaddb 수행 중 해당 에러가 발생하면 작업을 종료함)
  • +DEFAULT : 24번부터 33번까지의 에러를 무시하지 않도록 설정

--error-control-file 옵션으로 에러 명세 파일을 설정하지 않을 경우, loaddb 유틸리티는 기본적으로 24번부터 33번까지의 에러를 무시하도록 설정되어 있다. 이들은 데이터베이스 볼륨의 여유 공간이 얼마 남지 않았다는 경고성 에러로서, 이후 할당된 데이터베이스 볼륨의 여유 공간이 없어지면 자동으로 범용 볼륨(generic volume)을 생성하게 된다.

다음은 에러 명세 파일을 작성한 예이다.

  • +DEFAULT를 설정하여, 24번부터 33번까지의 DB 볼륨 여유 공간 경고성 에러는 무시되지 않는다.

  • 앞에서 -2를 설정했으나, 뒤에서 +2를 설정했기 때문에 2번 에러 코드는 무시되지 않는다.

  • -670을 설정하여, 670번 에러인 고유성 위반 에러(unique violation error)는 무시된다.

  • #-115는 앞에 #이 있어 커멘트 처리되었다.

    vi error_file
    
    +DEFAULT
    -2
    -670
    #-115 --> comment
    +2
    
--ignore-class-file=FILE

로딩 작업 중 무시할 클래스 목록을 명세한 파일을 지정한다. 지정된 파일에 포함된 클래스를 제외한 나머지 클래스의 레코드만 로딩된다.

cubrid loaddb --ignore-class-file=skip_class_list -d demodb_objects newdb

Warning

--no-logging 옵션을 사용하면 loaddb 를 수행하면서 트랜잭션 로그를 저장하지 않으므로 데이터 파일을 빠르게 로드할 수 있다. 그러나 로드 도중 파일 형식이 잘못되거나 시스템이 다운되는 등의 문제가 발생했을 때 데이터를 복구할 수 없으므로 데이터베이스를 새로 구축해야 한다. 즉, 데이터를 복구할 필요가 없는 새로운 데이터베이스를 구축하는 경우를 제외하고는 사용하지 않도록 주의한다. 이 옵션을 사용하면 고유 위반 등의 오류를 검사하지 않아 기본 키에 값이 중복되는 경우 등이 발생할 수 있으므로, 사용 시 이러한 문제를 반드시 감안해야 한다.

가져오기용 파일 작성 방법

cubrid loaddb 유틸리티에서 사용되는 객체 입력 파일을 직접 작성하여 사용하면 데이터베이스에 대량의 데이터를 보다 신속하게 추가할 수 있다. 객체 입력 파일은 간단한 테이블 모양의 형식으로 구성되며 주석, 명령 라인, 데이터 라인으로 이루어진 텍스트 파일이다.

주석

CUBRID에서는 주석은 두 개의 연속된 하이픈(--)을 이용하여 처리한다.

-- This is a comment!

명령 라인

명령 라인은 퍼센트(%) 문자로 시작하며, 명령어로는 클래스를 정의하는 %class 명령어와, 클래스 식별을 위해 사용하는 별칭(alias)이나 식별자(identifier)를 정의하는 %id 명령어가 있다.

클래스에 식별자 부여

%id 를 이용하여 참조 관계에 있는 클래스에 식별자를 부여할 수 있다.

%id class_name class_id
class_name:
    identifier
class_id:
    integer

%id 명령어에 의해 명시된 class_name 은 해당 데이터베이스에 정의된 클래스 이름이며, class_id 는 객체 참조를 위해 부여한 숫자형 식별자를 의미한다.

%id employee 2
%idoffice 22
%id project 23
%id phone 24

클래스 및 속성 명시

%class 명령어를 이용하여 데이터가 로딩될 클래스(테이블) 및 속성(칼럼)을 명시하며, 명시된 속성의 순서에 따라 데이터 라인이 작성되어야 한다. cubrid loaddb 유틸리티를 실행할 때 -t 옵션으로 클래스 이름을 제공하는 경우에는 데이터 파일에 클래스 및 속성을 명시하지 않아도 된다. 단, 데이터가 작성되는 순서는 클래스 생성 시의 속성 순서를 따라야 한다.

%class class_name ( attr_name [attr_name... ] )

데이터를 로딩하고자 하는 데이터베이스에는 이미 스키마가 정의되어 있어야 한다.

%class 명령어에 의해 명시된 class_name 은 해당 데이터베이스에 정의된 클래스 이름이며, attr_name 는 정의된 속성 이름을 의미한다.

다음은 employee 라는 클래스에 데이터를 입력하기 위하여 %class 명령으로 클래스 및 3개의 속성을 명시한 예제이다. %class 명령 다음에 나오는 데이터 라인에서는 3개의 데이터가 입력되어야 하며, 이는 참조 관계 설정 을 참조한다.

%class employee (name age department)

데이터 라인

데이터 라인은 %class 명령 라인 다음에 위치하며, 입력되는 데이터는 %class 명령에 의해 명시된 클래스 속성과 타입이 일치해야 한다. 만약, 명시된 속성과 타입이 일치하지 않으면 데이터 로드 작업은 중지된다.

또한, 각각의 속성에 대응되는 데이터는 적어도 하나의 공백에 의해 분리되어야 하며, 한 라인에 작성되는 것이 원칙이다. 다만, 입력되는 데이터가 많은 경우에는 첫 번째 데이터 라인의 맨 마지막 데이터 다음에 플러스 기호(+)를 명시하여 다음 라인에 데이터를 연속적으로 입력할 수 있다. 이 때, 맨 마지막 데이터와 플러스 기호 사이에는 공백이 허용되지 않음을 유의한다.

인스턴스 입력

다음과 같이 명시된 클래스 속성과 타입이 일치하는 인스턴스를 입력할 수 있다. 각각의 데이터는 적어도 하나의 공백에 의해 구분된다.

%class employee (name)
'jordan'
'james'
'garnett'
'malone'

인스턴스 번호 부여

데이터 라인의 처음에 '번호:'의 형식으로 해당 인스턴스에 대한 번호를 부여할 수 있다. 인스턴스 번호는 명시된 클래스 내에서 유일한 양수이며, 번호와 콜론(:) 사이에는 공백이 허용되지 않는다. 이와 같이 인스턴스 번호를 부여하는 이유는 추후 객체 참조 관계를 설정하기 위함이다.

%class employee (name)
1: 'jordan'
2: 'james'
3: 'garnett'
4: 'malone'

참조 관계 설정

@ 다음에 참조하는 클래스를 명시하고, 수직바(|) 다음에 참조하는 인스턴스의 번호를 명시하여 객체 참조 관계를 설정할 수 있다.

@class_ref | instance_no
class_ref:
     class_name
     class_id

@ 다음에는 클래스명 또는 클래스 id를 명시하고, 수직바(|) 다음에는 인스턴스 번호를 명시한다. 수직바(|)의 양쪽에는 공백을 허용하지 않는다.

다음은 paycheck 클래스에 인스턴스를 입력하는 예제이며, name 속성은 employee 클래스의 인스턴스를 참조한다. 마지막 라인과 같이 앞에서 정의되지 아니한 인스턴스 번호를 이용하여 참조 관계를 설정하는 경우 해당 데이터는 NULL 로 입력된다.

%class paycheck(name department salary)
@employee|1   'planning'   8000000
@employee|2   'planning'   6000000
@employee|3   'sales'   5000000
@employee|4   'development'   4000000
@employee|5   'development'   5000000

클래스에 식별자 부여 에서 %id 명령어로 employee 클래스에 21이라는 식별자를 부여했으므로, 위의 예를 다음과 같이 작성할 수 있다.

%class paycheck(name department salary)
@21|1   'planning'   8000000
@21|2   'planning'   6000000
@21|3   'sales'   5000000
@21|4   'development'   4000000
@21|5   'development'   5000000

데이터베이스 마이그레이션

신규 버전의 CUBRID 데이터베이스를 사용하기 위해서는 기존 버전의 CUBRID 데이터베이스를 신규 버전의 CUBRID 데이터베이스로 이전하는 작업을 진행해야 할 경우가 있다. 이때 CUBRID에서 제공하는 텍스트 파일로 내보내기와 텍스트 파일에서 가져오기 기능을 활용할 수 있다.

cubrid unloaddbcubrid loaddb 유틸리티를 이용하는 마이그레이션 절차를 설명한다.

권장 시나리오 및 절차

기존 버전의 CUBRID가 운영 중인 상태에서 적용할 수 있는 마이그레이션 시나리오를 설명한다. 데이터베이스 마이그레이션을 위해서는 cubrid unloaddbcubrid loaddb 유틸리티를 사용한다. 자세한 내용은 데이터베이스 내보내기(unload)데이터베이스 가져오기(load) 를 참조한다.

  1. 기존 CUBRID 서비스 종료

    cubrid service stop 을 실행하여 기존 CUBRID로 운영되는 모든 서비스 프로세스를 종료한 후, CUBRID 관련 프로세스들이 모두 정상 종료되었는지 확인한다.

    CUBRID 관련 프로세스들이 모두 정상 종료되었는지 확인하려면, Linux에서는 ps -ef|grep cub_를 실행한다. cub_로 시작하는 프로세스가 없으면 정상적으로 종료된 것이다. Windows에서는 <Ctrl + Alt + Delete> 키를 누른 후 [작업 관리자 시작]을 선택한다. [프로세스] 탭에 cub_로 시작하는 프로세스가 없으면 정상적으로 종료된 것이다. CUBRID 서비스 종료 후에도 관련 프로세스가 존재하면 Linux에서는 kill 명령으로 강제 종료한 후 ipcs -m 명령으로 CUBRID 브로커가 사용 중이던 공유 메모리를 확인하고 삭제한다. Windows에서는 작업 관리자의 [프로세스] 탭에서 해당 이미지 이름을 마우스 오른쪽 버튼으로 클릭하고 [프로세스 끝내기]를 선택하여 강제 종료한다.

  2. 기존 데이터베이스 백업

    cubrid backupdb 유틸리티를 이용하여 기존 버전의 데이터베이스 백업을 수행한다. 그 이유는 데이터베이스 언로드/로드 작업 중 발생 가능한 장애에 대비하기 위함이다. 데이터베이스 백업에 관한 자세한 내용은 데이터베이스 백업을 참조한다.

  3. 기존 데이터베이스 언로드

    cubrid unloaddb 유틸리티를 이용하여 기존 버전의 CUBRID에서 생성된 데이터베이스를 언로드한다. 데이터베이스 언로드에 관한 자세한 내용은 데이터베이스 내보내기(unload) 를 참조한다.

  4. 기존 CUBRID의 환경 설정 파일 보관

    CUBRID/conf 디렉터리 아래의 cubrid.conf, cubrid_broker.conf, cm.conf 등의 환경 설정 파일을 보관한다. 이는 기존 CUBRID 데이터베이스 환경에 적용된 파라미터 설정값을 신규 CUBRID 데이터베이스 환경에서 편리하게 적용할 수 있기 때문이다.

  5. 신규 버전의 CUBRID 설치

    기존 버전의 CUBRID에서 생성된 데이터의 백업 및 언로드 작업이 완료되었으므로, 기존 버전의 CUBRID 및 데이터베이스를 삭제하고 신규 버전의 CUBRID를 설치한다. CUBRID 설치에 대한 자세한 내용은 시작하기을 참조한다.

  6. 신규 CUBRID의 환경 설정

    기존 CUBRID의 환경 설정 파일 보관하기 에서 보관한 기존 데이터베이스의 환경 설정 파일을 참고하여 신규 버전의 CUBRID 환경을 설정할 수 있다. 환경 설정에 대한 자세한 내용은 "CUBRID 시작"의 설치와 실행을 참조한다.

  7. 신규 데이터베이스 로드

    cubrid createdb 유틸리티를 이용하여 데이터베이스를 생성하고, cubrid loaddb 유틸리티를 이용하여 언로드한 데이터를 해당 데이터베이스에 로드한다. 데이터베이스 생성에 대한 자세한 내용은 "관리자 안내서"의 데이터베이스 생성 을 참조하고, 데이터베이스 로드에 대한 자세한 내용은 데이터베이스 가져오기(load)를 참조한다.

  8. 신규 데이터베이스 백업

    신규 데이터베이스에 데이터 로딩이 완료되면, cubrid backupdb 유틸리티를 이용하여 신규 버전의 CUBRID 환경에서 생성된 데이터베이스를 백업한다. 그 이유는 기존 버전의 CUBRID 환경에서 백업한 데이터를 신규 버전의 CUBRID 환경에서 복구할 수 없기 때문이다. 데이터베이스 백업에 대한 자세한 내용은 데이터베이스 백업을 참조한다.

Warning

같은 버전이라 하더라도 백업 및 복구 시 32비트 데이터베이스 볼륨과 64비트 데이터베이스 볼륨 간에는 상호 호환을 보장하지 않는다. 따라서 32비트 CUBRID에서 백업한 데이터베이스를 64비트 CUBRID에서 복구하거나, 이와 반대로 작업하는 것을 권장하지 않는다.

데이터베이스 공간 확인,공간 정리

사용 공간 확인

cubrid spacedb 유틸리티는 사용 중인 데이터베이스 볼륨의 공간을 확인하기 위해서 사용된다. cubrid spacedb 유틸리티는 데이터베이스에 있는 모든 영구 데이터 볼륨의 간략한 설명을 보여준다. cubrid spacedb 유틸리티에 의해 반환되는 정보는 볼륨 ID와 이름, 각 볼륨의 목적, 각 볼륨과 관련된 총(total) 공간과 빈(free) 공간이다.

cubrid spacedb [options] database_name
  • cubrid: CUBRID 서비스 및 데이터베이스 관리를 위한 통합 유틸리티이다.
  • spacedb: 대상 데이터베이스에 대한 공간을 확인하는 명령으로 데이터베이스 서버가 구동 정지 상태인 경우에만 정상적으로 수행된다.
  • database_name: 공간을 확인하고자 하는 데이터베이스의 이름이며, 데이터베이스가 생성될 디렉터리 경로명을 포함하지 않는다.

다음은 cubrid spacedb 에 대한 [options]이다.

-o FILE

데이터베이스의 공간 정보에 대한 결과를 지정한 파일에 저장한다.

cubrid spacedb -o db_output testdb
-S, --SA-mode

서버 프로세스를 구동하지 않고 데이터베이스에 접근하는 독립 모드(standalone)로 작업하기 위해 지정되며, 인수는 없다. -S 옵션을 지정하지 않으면, 시스템은 클라이언트/서버 모드로 인식한다.

cubrid spacedb --SA-mode testdb
-C, --CS-mode

-C 옵션은 서버 프로세스와 클라이언트 프로세스를 각각 구동하여 데이터베이스에 접근하는 클라이언트/서버 모드로 작업하기 위한 옵션이며, 인수는 없다. -C 옵션을 지정하지 않더라도 시스템은 기본적으로 클라이언트/서버 모드로 인식한다.

cubrid spacedb --CS-mode testdb
--size-unit={PAGE|M|G|T|H}

데이터베이스 볼륨의 공간을 지정한 크기 단위로 출력하기 위한 옵션이며, 기본값은 H이다. 단위를 PAGE, M, G, T, H로 설정할 수 있으며, 각각 페이지, MB(megabytes), GB(gigabytes), TB(terabytes), 자동 지정을 의미한다. 자동 지정을 의미하는 H로 설정하면 데이터베이스 크기가 1MB 이상 1024MB 미만일 때 MB 단위로, 1GB 이상 1024GB 미만일 때 GB 단위로 결정된다.

cubrid spacedb --size_unit=M testdb
cubrid spacedb --size_unit=H testdb
-s, --summarize

데이터 볼륨(DATA), 인덱스 볼륨(INDEX), 범용 볼륨(GENERIC), 임시 볼륨(TEMP), 일시적 임시 볼륨(TEMP TEMP)별로 전체 공간(total_pages), 사용 공간(used_pages), 빈 공간(free_pages)을 합산하여 출력한다.

cubrid spacedb -s testdb

사용 공간 정리

cubrid compactdb 유틸리티는 데이터베이스 볼륨 중에 사용되지 않는 공간을 확보하기 위해서 사용된다. 데이터베이스 서버가 정지된 경우(offline)에는 독립 모드(stand-alone mode)로, 데이터베이스가 구동 중인 경우(online)에는 클라이언트 서버 모드(client-server mode)로 공간 정리 작업을 수행할 수 있다.

cubrid compactdb 유틸리티는 삭제된 객체들의 OID와 클래스 변경에 의해 점유되고 있는 공간을 확보한다. 객체를 삭제하면 삭제된 객체를 참조하는 다른 객체가 있을 수 있기 때문에 삭제된 객체에 대한 OID는 바로 사용 가능한 빈 공간이 될 수 없다.

cubrid compactdb 유틸리티를 수행하면 삭제된 객체에 대한 참조를 NULL로 표시하는데, 이렇게 NULL로 표시된 공간은 OID가 재사용할 수 있는 공간임을 의미한다.

cubrid compactdb [<options>] database_name [ class_name1, class_name2, ...]
  • cubrid: 큐브리드 서비스 및 데이터베이스 관리를 위한 통합 유틸리티이다.
  • compactdb: 대상 데이터베이스에 대하여 삭제된 데이터에 할당되었던 OID가 재사용될 수 있도록 공간을 정리하는 명령으로서, 데이터베이스가 구동 정지 상태인 경우에만 정상적으로 수행된다.
  • database_name: 공간을 정리할 데이터베이스의 이름이며, 데이터베이스가 생성될 디렉터리 경로명을 포함하지 않는다.
  • class_name_list: 공간을 정리할 테이블 이름 리스트를 데이터베이스 이름 뒤에 직접 명시할 수 있으며, -i 옵션과 함께 사용할 수 없다. 클라이언트/서버 모드에서만 명시할 수 있다.

클라이언트/서버 모드에서만 -I, -i, -c, -d, -p 옵션을 사용할 수 있다.

다음은 cubrid compactdb 에 대한 [options]이다.

-v, --verbose

어느 클래스가 현재 정리되고 있는지, 얼마나 많은 인스턴스가 그 클래스를 위하여 처리되었는지를 알리는 메시지를 화면에 출력할 수 있다.

cubrid compactdb -v testdb
-S, --SA-mode

데이터베이스 서버가 구동 중단된 상태에서 독립 모드(standalone)로 공간 정리 작업을 수행하기 위해 지정되며, 인수는 없다. -S 옵션을 지정하지 않으면, 시스템은 클라이언트/서버 모드로 인식한다.

cubrid compactdb --SA-mode testdb
-C, --CS-mode

-C 옵션은 데이터베이스 서버가 구동 중인 상태에서 클라이언트/서버 모드로 공간 정리 작업을 수행하기 위해 지정되며, 인수는 없다. -C 옵션이 생략되더라도 시스템은 기본적으로 클라이언트/서버 모드로 인식한다. 클라이언트/서버 모드에서만 -I, -i, -c, -d, -p 옵션을 사용할 수 있다.

다음은 클라이언트/서버 모드에서만 사용할 수 있는 옵션이다.

-i, --input-class-file=FILE

대상 테이블 이름을 포함하는 입력 파일 이름을 지정할 수 있다. 라인 당 하나의 테이블 이름을 명시하며, 유효하지 않은 테이블 이름은 무시된다. 이 옵션을 지정하는 경우, 데이터베이스 이름 뒤에 대상 테이블 이름 리스트를 직접 명시할 수 없으므로 주의한다.

-p, --pages-commited-once=NUMBER

한 번에 커밋할 수 있는 최대 페이지 수를 지정한다. 기본값은 10 이며, 최소 값은 1, 최대 값은 10이다. 옵션 값이 작으면 클래스/인스턴스에 대한 잠금 비용이 작으므로 동시성은 향상될 수 있으나 작업 속도는 저하될 수 있고, 옵션 값이 크면 동시성은 저하되나 작업 속도는 향상될 수 있다.

cubrid compactdb --CS-mode -p 10 testdb tbl1, tbl2, tbl5
-d, --delete-old-repr

카탈로그에서 과거 테이블 표현(스키마 구조)을 삭제할 수 있다. ALTER 문에 의해 칼럼이 추가되거나 삭제되는 경우 기존의 레코드에 대해 과거의 스키마를 참조하고 있는 상태로 두면, 스키마를 업데이트하는 비용을 들이지 않기 때문에 평소에는 과거의 테이블 표현을 유지하는 것이 좋다.

-I, --Instance-lock-timeout=NUMBER

인스턴스 잠금 타임아웃 값을 지정할 수 있다. 기본값은 2 (초)이며, 최소 값은 1, 최대 값은 10이다. 설정된 시간동안 잠금 인스턴스를 대기하므로, 옵션 값이 작을수록 작업 속도는 향상될 수 있으나 처리 가능한 인스턴스 개수가 적어진다. 반면, 옵션 값이 클수록 작업 속도는 저하되나 더 많은 인스턴스에 대해 작업을 수행할 수 있다.

통계 정보 갱신, 질의 계획 확인

통계 정보 갱신

CUBRID의 질의 최적화기가 사용하는 테이블에 있는 객체들의 수, 접근하는 페이지들의 수, 속성 값들의 분산 같은 통계 정보를 갱신한다.

cubrid optimizedb [option] database_name
  • cubrid: CUBRID 서비스 및 데이터베이스 관리를 위한 통합 유틸리티이다.
  • optimizedb: 대상 데이터베이스에 대하여 비용 기반 질의 최적화에 사용되는 통계 정보를 업데이트한다. 옵션을 지정하는 경우, 지정한 클래스에 대해서만 업데이트한다.
  • database_name: 비용기반 질의 최적화용 통계 자료를 업데이트하려는 데이터베이스 이름이다.

다음은 cubrid optimizedb 에 대한 [option]이다.

-n, --class-name

-n 옵션을 이용하여 해당 클래스의 질의 통계 정보를 업데이트하는 명령이다.

cubrid optimizedb -n event_table testdb

다음은 대상 데이터베이스의 전체 클래스의 질의 통계 정보를 업데이트하는 명령이다.

cubrid optimizedb testdb

질의 수행 계획 캐시 확인

cubrid plandump 유틸리티를 사용해서 서버에 저장(캐시)되어 있는 질의 수행 계획들의 정보를 출력할 수 있다.

cubrid plandump [options] database_name
  • cubrid: CUBRID 서비스 및 데이터베이스 관리를 위한 통합 유틸리티이다.
  • plandump: 대상 데이터베이스에 대하여 현재 캐시에 저장되어 있는 질의 수행 계획을 출력하는 명령이다.
  • database_name: 데이터베이스 서버 캐시로부터 질의 수행 계획을 확인 또는 제거하고자 하는 데이터베이스 이름이다

옵션 없이 사용하면 캐시에 저장된 질의 수행 계획을 확인한다.

cubrid plandump testdb

다음은 cubrid plandump 에 대한 [options]이다.

-d, --drop

캐시에 저장된 질의 수행 계획을 제거한다.

cubrid plandump -d testdb
-o, --output-file=FILE

캐시에 저장된 질의 수행 계획 결과 파일에 저장

cubrid plandump -o output.txt testdb

서버 실행 통계 정보 출력

cubrid statdump 유틸리티를 이용해 CUBRID 데이터베이스 서버가 실행한 통계 정보를 확인할 수 있으며, 통계 정보 항목은 크게 File I/O 관련, 페이지 버퍼 관련, 로그 관련, 트랜잭션 관련, 동시성 관련, 인덱스 관련, 쿼리 수행 관련, 네트워크 요청 관련으로 구분된다.

CSQL의 해당 연결에 대해서만 통계 정보를 확인하려면 CSQL의 세션 명령어를 이용할 수 있으며 CSQL 실행 통계 정보 출력를 참고한다.

cubrid statdump [options] database_name
  • cubrid: CUBRID 서비스 및 데이터베이스 관리를 위한 통합 유틸리티이다.
  • statdump: 대상 데이터베이스 서버 실행 통계 정보를 출력하는 명령어이다. 데이터베이스가 동작 중일 때에만 정상 수행된다.
  • database_name: 통계 자료를 확인하고자 하는 대상 데이터베이스 이름이다.

다음은 cubrid statdump 에 대한 [options]이다.

-i, --interval=SECOND

지정한 초 단위로 주기적으로 출력한다. -i 옵션이 주어질 때만 정보가 갱신된다.

다음은 1초마다 누적된 정보 값을 출력한다.

cubrid statdump -i 1 -c demodb

다음은 1초 마다 0으로 리셋하고 1초 동안 누적된 값을 출력한다.

cubrid statdump -i 1 demodb

다음은 -i 옵션으로 가장 마지막에 실행한 값을 출력한다.

cubrid statdump demodb

다음은 위와 같은 결과를 출력한다. -c 옵션은 -i 옵션과 같이 쓰이지 않으면 옵션을 설정하지 않은 것과 동일하다.

cubrid statdump -c demodb

다음은 5초마다 결과를 출력한다.

cubrid statdump -i 5 testdb

Thu April 07 23:10:08 KST 2011

 *** SERVER EXECUTION STATISTICS ***
Num_file_creates              =          0
Num_file_removes              =          0
Num_file_ioreads              =          0
Num_file_iowrites             =          0
Num_file_iosynches            =          0
Num_data_page_fetches         =          0
Num_data_page_dirties         =          0
Num_data_page_ioreads         =          0
Num_data_page_iowrites        =          0
Num_data_page_victims         =          0
Num_data_page_iowrites_for_replacement =          0
Num_log_page_ioreads          =          0
Num_log_page_iowrites         =          0
Num_log_append_records        =          0
Num_log_archives              =          0
Num_log_checkpoints           =          0
Num_log_wals                  =          0
Num_page_locks_acquired       =          0
Num_object_locks_acquired     =          0
Num_page_locks_converted      =          0
Num_object_locks_converted    =          0
Num_page_locks_re-requested   =          0
Num_object_locks_re-requested =          0
Num_page_locks_waits          =          0
Num_object_locks_waits        =          0
Num_tran_commits              =          0
Num_tran_rollbacks            =          0
Num_tran_savepoints           =          0
Num_tran_start_topops         =          0
Num_tran_end_topops           =          0
Num_tran_interrupts           =          0
Num_btree_inserts             =          0
Num_btree_deletes             =          0
Num_btree_updates             =          0
Num_btree_covered             =          0
Num_btree_noncovered          =          0
Num_btree_resumes             =          0
Num_btree_multirange_optimization =      0
Num_query_selects             =          0
Num_query_inserts             =          0
Num_query_deletes             =          0
Num_query_updates             =          0
Num_query_sscans              =          0
Num_query_iscans              =          0
Num_query_lscans              =          0
Num_query_setscans            =          0
Num_query_methscans           =          0
Num_query_nljoins             =          0
Num_query_mjoins              =          0
Num_query_objfetches          =          0
Num_network_requests          =          1
Num_adaptive_flush_pages      =          0
Num_adaptive_flush_log_pages  =          0
Num_adaptive_flush_max_pages  =        900

 *** OTHER STATISTICS ***
Data_page_buffer_hit_ratio    =       0.00

다음은 위의 데이터베이스 서버 실행 통계 정보에 대한 각 항목 설명이다.

분류 항목 설명
File I/O 관련 Num_file_removes 삭제한 파일 개수
Num_file_creates 생성한 파일 개수
Num_file_ioreads 디스크로부터 읽은 횟수
Num_file_iowrites 디스크로 저장한 횟수
Num_file_iosynches 디스크와 동기화를 수행한 횟수
페이지 버퍼 관련 Num_data_page_fetches 가져오기(fetch)한 페이지 수
Num_data_page_dirties 더티 페이지 수
Num_data_page_ioreads 읽은 페이지 수
Num_data_page_iowrites 저장한 페이지 수
Num_data_page_victims 데이터 페이지에서 디스크로 내려갈 후보(victim) 데이터를 정하는 횟수
Num_data_page_iowrites_for_replacement 후보로 선정되어 디스크로 쓰여진 데이터 페이지 수
Num_adaptive_flush_pages 데이터 버퍼로부터 디스크로 내려 쓰기(flush)한 데이터 페이지 수
Num_adaptive_flush_log_pages 로그 버퍼로부터 디스크로 내려 쓰기(flush)한 로그 페이지 수
Num_adaptive_flush_max_pages 데이터 및 로그 버퍼로부터 디스크로 내려 쓰기(flush)를 허용하는 최대 페이지 수
로그 관련 Num_log_page_ioreads 읽은 로그 페이지의 수
Num_log_page_iowrites 저장한 로그 페이지의 수
Num_log_append_records 추가(append)한 로그 레코드의 수
Num_log_archives 보관 로그의 개수
Num_log_checkpoints 체크포인트 수행 횟수
Num_log_wals 현재 사용하지 않음
트랜잭션 관련 Num_tran_commits 커밋한 횟수
Num_tran_rollbacks 롤백한 횟수
Num_tran_savepoints 세이브포인트 횟수
Num_tran_start_topops 시작한 top operation의 개수
Num_tran_end_topops 종료한 top peration의 개수
Num_tran_interrupts 인터럽트 개수
동시성/잠금 관련 Num_page_locks_acquired 페이지 잠금을 획득한 횟수
Num_object_locks_acquired 오브젝트 잠금을 획득한 횟수
Num_page_locks_converted 페이지 잠금 타입을 변환한 횟수
Num_object_locks_converted 오브젝트 잠금 타입을 변환한 횟수
Num_page_locks_re-requested 페이지 잠금을 재요청한 횟수
Num_object_locks_re-requested 오브젝트 잠금을 재요청한 횟수
Num_page_locks_waits 잠금을 대기하는 페이지 개수
Num_object_locks_waits 잠금을 대기하는 오브젝트 개수
인덱스 관련 Num_btree_inserts 삽입된 항목의 개수
Num_btree_deletes 삭제된 항목의 개수
Num_btree_updates 갱신된 항목의 개수
Num_btree_covered 질의 시 인덱스가 데이터를 모두 포함한 경우의 개수
Num_btree_noncovered 질의 시 인덱스가 데이터를 일부분만 포함하거나 전혀 포함하지 않은 경우의 개수
Num_btree_resumes index_scan_oid_buffer_pages를 초과한 인덱스 스캔 횟수
Num_btree_multirange_optimization WHERE … IN … LIMIT 조건 질의문에 대해 다중 범위 최적화(multi-range optimization)를 수행한 횟수
쿼리 관련 Num_query_selects SELECT 쿼리의 수행 횟수
Num_query_inserts INSERT 쿼리의 수행 횟수
Num_query_deletes DELETE 쿼리의 수행 횟수
Num_query_updates UPDATE 쿼리의 수행 횟수
Num_query_sscans 순차 스캔(풀 스캔) 횟수
Num_query_iscans 인덱스 스캔 횟수
Num_query_lscans LIST 스캔 횟수
Num_query_setscans SET 스캔 횟수
Num_query_methscans METHOD 스캔 횟수
Num_query_nljoins Nested Loop 조인 횟수
Num_query_mjoins 병합 조인 횟수
Num_query_objfetches 객체를 가져오기(fetch)한 횟수
네트워크 요청 관련 Num_network_requests 네트워크 요청 횟수
버퍼 히트율 관련 Data_page_buffer_hit_ratio 페이지 버퍼의 Hit Ratio (Num_data_page_fetches - Num_data_page_ioreads)*100 / Num_data_page_fetches
-o, --output-file=FILE

대상 데이터베이스 서버의 실행 통계 정보를 지정된 파일에 저장한다.

cubrid statdump -o statdump.log testdb
-c, --cumulative

-c 옵션을 이용하여 대상 데이터베이스 서버의 누적된 실행 통계 정보를 출력할 수 있다. -i 옵션과 결합하면, 지정된 시간 간격(interval)마다 실행 통계 정보를 확인할 수 있다.

cubrid statdump -i 5 -c testdb
-s, --substr=STRING

-s 옵션 뒤에 문자열을 지정하면, 항목 이름 내에 해당 문자열을 포함하는 통계 정보만 출력할 수 있다.

다음 예는 항목 이름 내에 "data"를 포함하는 통계 정보만 출력한다.

cubrid statdump -s data testdb

*** SERVER EXECUTION STATISTICS ***
Num_data_page_fetches         =        135
Num_data_page_dirties         =          0
Num_data_page_ioreads         =          0
Num_data_page_iowrites        =          0
Num_data_page_victims         =          0
Num_data_page_iowrites_for_replacement =          0

 *** OTHER STATISTICS ***
Data_page_buffer_hit_ratio    =     100.00

Note

각 상태 정보는 64비트 INTEGER 로 구성되어 있으며, 누적된 값이 한도를 넘으면 해당 실행 통계 정보가 유실될 수 있다.

잠금 확인, 트랜잭션 확인, 트랜잭션 제거

잠금(Lock) 상태 확인

cubrid lockdb 는 대상 데이터베이스에 대하여 현재 트랜잭션에서 사용되고 있는 잠금 정보를 확인하는 유틸리티이다.

cubrid lockdb [<option>] database_name
  • cubrid: CUBRID 서비스 및 데이터베이스 관리를 위한 통합 유틸리티이다.
  • lockdb: 대상 데이터베이스에 대하여 현재 트랜잭션에서 사용되고 있는 잠금 정보를 확인하는 명령이다.
  • database_name: 현재 트랜잭션의 잠금 정보를 확인하는 데이터베이스 이름이다.

다음 예는 옵션 없이 testdb 데이터베이스의 잠금 정보를 화면에 출력한다.

cubrid lockdb testdb

다음은 cubrid lockdb 에 대한 [option]이다.

-o, --output-file=FILE

데이터베이스의 잠금 정보를 output.txt로 출력한다.

cubrid lockdb -o output.txt testdb

출력 내용

cubrid lockdb 의 출력 내용은 논리적으로 3개의 섹션으로 나뉘어져 있다.

  • 서버에 대한 잠금 설정
  • 현재 데이터베이스에 접속한 클라이언트들
  • 객체 잠금 테이블의 내용

서버에 대한 잠금 설정

cubrid lockdb 출력 내용의 첫 번째 섹션은 데이터베이스 서버에 대한 잠금 설정이다.

*** Lock Table Dump ***
 Lock Escalation at = 100000, Run Deadlock interval = 0

위에서 잠금 에스컬레이션 레벨은 100000레코드로, 교착 상태 탐지 간격은 0초로 설정되어 있다.

관련 시스템 파라미터인 lock_escalationdeadlock_detection_interval 에 대한 설명은 동시성/잠금 파라미터 를 참고한다.

현재 데이터베이스에 접속한 클라이언트들

cubrid lockdb 출력 내용의 두 번째 섹션은 데이터베이스에 연결된 모든 클라이언트의 정보를 포함한다. 이 정보에는 각각의 클라이언트에 대한 트랜잭션 인덱스, 프로그램 이름, 사용자 ID, 호스트 이름, 프로세스 ID, 고립 수준, 그리고 잠금 타임아웃 설정이 포함된다.

Transaction (index 1, csql, dba@cubriddb|12854)
Isolation READ COMMITTED CLASSES AND READ UNCOMMITTED INSTANCES
Timeout_period -1

위에서 트랜잭션 인덱스는 1이고, 프로그램 이름은 csql, 사용자 이름은 dba, 호스트 이름은 cubriddb, 클라이언트 프로세스 식별자는 12854, 고립 수준은 READ COMMITTED CLASSES AND READ UNCOMMITTED INSTANCES, 그리고 잠금 타임아웃은 무제한이다.

트랜잭션 인덱스가 0인 클라이언트는 내부적인 시스템 트랜잭션이다. 이것은 데이터베이스의 체크포인트 수행과 같이 특정한 시간에 잠금을 획득할 수 있지만 대부분의 경우 이 트랜잭션은 어떤 잠금도 획득하지 않을 것이다.

cubrid lockdb 유틸리티는 잠금 정보를 가져오기 위해 데이터베이스에 접속하기 때문에 cubrid lockdb 자체가 하나의 클라이언트이고 따라서 클라이언트의 하나로 출력된다.

객체 잠금 테이블

cubrid lockdb 출력 내용의 세 번째 섹션은 객체 잠금 테이블의 내용을 포함한다. 이것은 어떤 객체에 대해서 어떤 클라이언트가 어떤 모드로 잠금을 가지고 있는지, 어떤 객체에 대해서 어떤 클라이언트가 어떤 모드로 기다리고 있는지를 보여준다. 객체 잠금 테이블 결과물의 첫 부분에는 얼마나 많은 객체가 잠금되었는지가 출력된다.

Object lock Table:
    Current number of ojbects which are locked = 2001

cubrid lockdb 는 잠금을 획득한 각각의 객체에 대한 객체의 OID와 Object type, 테이블 이름을 출력한다. 추가적으로 객체에 대해서 잠금을 보유하고 있는 트랜잭션의 개수(Num holders), 잠금을 보유하고 있지만 상위 잠금으로 변환(예를 들어 U_LOCK에서 X_LOCK으로 잠금 변환)하지 못해 차단된 트랜잭션의 개수(Num blocked-holders), 객체의 잠금을 기다리는 다른 트랜잭션의 개수(Num waiters)가 출력된다. 그리고 잠금을 보유하고 있는 클라이언트 트랜잭션, 차단된 클라이언트 트랜잭션, 기다리는 클라이언트 트랜잭션의 리스트가 출력된다.

다음 예는 Object type이 instance of class, 즉 레코드인 경우, OID( 2| 50| 1)인 객체에 대해서 트랜잭션 2가 S_LOCK을 가지고 있고, 트랜잭션 1이 U_LOCK을 획득하고 있지만 트랜잭션 2가 S_LOCK을 획득하고 있기 때문에 X_LOCK으로 변환하지 못해 차단되었음을 보여준다. 그리고 트랜잭션 3은 S_LOCK을 대기하고 있지만 트랜잭션 2가 X_LOCK을 대기하고 있기 때문에 차단되었음을 보여준다.

OID = 2| 50| 1
Object type: instance of class ( 0| 62| 5) = athlete
Num holders = 1, Num blocked-holders= 1, Num waiters = 1
LOCK HOLDERS :
    Tran_index = 2, Granted_mode = S_LOCK, Count = 1
BLOCKED LOCK HOLDERS :
    Tran_index = 1, Granted_mode = U_LOCK, Count = 3
    Blocked_mode = X_LOCK
                    Start_waiting_at = Fri May 3 14:44:31 2002
                    Wait_for _nsecs = -1
LOCK WAITERS :
    Tran_index = 3, Blocked_mode = S_LOCK
                    Start_waiting_at = Fri May 3 14:45:14 2002
                    Wait_for_nsecs = -1

Object type이 Index key of class, 즉 인덱스 키인 경우 테이블의 인덱스에 대한 잠금 정보를 출력한다.

OID = -662|   572|-32512
Object type: Index key of class ( 0|   319|  10) = athlete.
Index name: pk_athlete_code
Total mode of holders =   NX_LOCK, Total mode of waiters = NULL_LOCK.
Num holders=  1, Num blocked-holders=  0, Num waiters=  0
LOCK HOLDERS:
    Tran_index =   1, Granted_mode =  NX_LOCK, Count =   1

Granted_mode는 현재 획득한 잠금의 모드를 의미하고 Blocked_mode는 차된된 잠금의 모드를 의미한다. Starting_waiting_at은 잠금을 요청한 시간을 의미하고 Wait_for_nsecs는 잠금을 기다리는 시간을 의미한다. Wait_for_nsecs의 값은 lock_timeout_in_secs 시스템 파라미터에 의해 설정된다.

Object type이 Class, 즉 테이블인 경우 Nsubgranules가 출력되는데 이것은 해당 테이블 내의 특정 트랜잭션이 획득하고 있는 레코드 잠금과 키 잠금을 합한 개수이다.

OID = 0| 62| 5
Object type: Class = athlete
Num holders = 2, Num blocked-holders= 0, Num waiters= 0
LOCK HOLDERS:
Tran_index = 3, Granted_mode = IS_LOCK, Count = 2, Nsubgranules = 0
Tran_index = 1, Granted_mode = IX_LOCK, Count = 3, Nsubgranules = 1
Tran_index = 2, Granted_mode = IS_LOCK, Count = 2, Nsubgranules = 1

트랜잭션 확인

cubrid tranlist 는 대상 데이터베이스의 트랜잭션 정보를 확인하는 유틸리티로서, DBA 또는 DBA그룹 사용자만 수행할 수 있다.

cubrid tranlist [options] database_name

옵션을 생략하면 각 트랜잭션에 대한 전체 정보를 출력한다.

"cubrid tranlist demodb"는 "cubrid killtran -q demodb"와 비슷한 결과를 출력하나, 후자에 비해 "User name"과 "Host name"을 더 출력한다. "cubrid tranlist -s demodb"는 "cubrid killtran -d demodb"와 동일한 결과를 출력한다.

다음은 cubrid tranlist 에 대한 [options]이다.

-u, --user=USER

로그인할 사용자 ID. DBA및 DBA그룹 사용자만 허용한다.(기본값 : DBA)

-p, --password=PASSWORD

사용자 비밀번호

-s, --summary

요약 정보만 출력한다(질의 수행 정보 또는 잠금 관련 정보를 생략).

$ cubrid tranlist demodb

Tran index         User name      Host name      Process id    Program name              Query time    Tran time              Wait for lock holder      SQL_ID       SQL Text
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
   1(ACTIVE)         PUBLIC          myhost           20080    query_editor_cub_cas_1          0.00         0.00                              -1     *** empty ***
   2(ACTIVE)         PUBLIC          myhost           20082    query_editor_cub_cas_3          0.00         0.00                              -1     *** empty ***
   3(ABORTED)        PUBLIC          myhost           20081    query_editor_cub_cas_2          0.00         0.00                              -1     *** empty ***
   4(ACTIVE)         PUBLIC          myhost           20083    query_editor_cub_cas_4          1.80         1.80                         2, 3, 1     cdcb58552e320   update [ta] [ta] set [ta].[a]=
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Tran index : 2
update [ta] [ta] set [a]=5 where (([ta].[a]> ?:0 ))
$ cubrid tranlist -s tdb

Tran index         User name      Host name      Process id              Program name
-------------------------------------------------------------------------------------
   1(ACTIVE)         PUBLIC          myhost            1822         broker1_cub_cas_1
   2(ACTIVE)            dba          myhost            1823         broker1_cub_cas_2
   3(COMMITTED)         dba          myhost            1824         broker1_cub_cas_3
-------------------------------------------------------------------------------------

"Tran index"에 보여지는 transaction 상태 메시지

  • ACTIVE : 활성
  • RECOVERY : 복구중인 트랜잭션
  • COMMITTED : 커밋완료되어 종료될 트랜잭션
  • COMMITTING : 커밋중인 트랜잭션
  • ABORTED : 롤백되어 종료될 트랜잭션
  • KILLED : 서버에 의해 강제 종료 중인 트랜잭션

트랜잭션 제거

cubrid killtran 은 대상 데이터베이스의 트랜잭션을 확인하거나 특정 트랜잭션을 강제 종료하는 유틸리티로서, DBA 사용자만 수행할 수 있다.

cubrid killtran [options] database_name
  • cubrid: CUBRID 서비스 및 데이터베이스 관리를 위한 통합 유틸리티이다.
  • killtran: 지정된 데이터베이스에 대해 트랜잭션을 관리하는 명령어이다.
  • database_name: 대상 데이터베이스의 이름이다.

[options]에 따라 특정 트랜잭션을 지정하여 제거하거나, 현재 활성화된 트랜잭션을 화면 출력할 수 있다. 옵션이 지정되지 않으면, -d 옵션이 기본으로 적용되어 모든 트랜잭션을 화면 출력하며, cubrid tranlist 명령에 -s 옵션을 준 것과 동일하다.

$ cubrid killtran testdb

Tran index      User name   Host name      Process id      Program name
-------------------------------------------------------------------------------
   1(ACTIVE)          dba      myhost             664           cub_cas
   2(ACTIVE)          dba      myhost            6700              csql
   3(ACTIVE)          dba      myhost            2188           cub_cas
   4(ACTIVE)          dba      myhost             696              csql
   5(ACTIVE)       public      myhost            6944              csql
-------------------------------------------------------------------------------

다음은 cubrid killtran 에 대한 [options]이다.

-i, --kill-transation-index=ID1,ID2,ID3

지정한 인덱스에 해당하는 트랜잭션을 제거한다. 쉼표(,)로 구분하여 제거하고자 하는 트랜잭션 ID 여러 개를 지정할 수 있다. 제거할 트랜잭션 리스트에 유효하지 않은 트랜잭션 ID가 지정되면 무시된다.:

$ cubrid killtran -i 1,2 demodb
Ready to kill the following transactions:

Tran index          User name      Host name      Process id      Program name
-------------------------------------------------------------------------------
   1(ACTIVE)              DBA    cdbs006.cub           15771              csql
   2(ACTIVE)              DBA    cdbs006.cub            2171              csql
-------------------------------------------------------------------------------
Do you wish to proceed ? (Y/N)y
Killing transaction associated with transaction index 1
Killing transaction associated with transaction index 2
--kill-user-name=ID

지정한 OS 사용자 ID에 해당하는 트랜잭션을 제거한다.

cubrid killtran --kill-user-name=os_user_id testdb
--kill-host-name=HOST

지정한 클라이언트 호스트의 트랜잭션을 제거한다.

cubrid killtran --kill-host-name=myhost testdb
--kill-program-name=NAME

지정한 이름의 프로그램에 해당하는 트랜잭션을 제거한다.

cubrid killtran --kill-program-name=cub_cas testdb
--kill-sql-id=SQL_ID

지정한 SQL ID에 해당하는 트랜잭션을 제거한다.

cubrid killtran --kill-sql-id=5377225ebc75a testdb
-p, --dba-password=PASSWORD

이 옵션 뒤에 오는 값은 DBA 의 암호이며 생략하면 프롬프트에서 입력해야 한다.

-d, --display

기본 지정되는 옵션으로 트랜잭션의 요약 정보를 출력한다. 아래의 예는 cubrid tranlist -s demodb를 실행한 것과 동일한 결과를 출력한다.

$ cubrid killtran -d testdb

Tran index      User name      Host name      Process id      Program name
-------------------------------------------------------------------------------
  2(ACTIVE)           dba         myhost            6700              csql
  3(ACTIVE)           dba         myhost            2188           cub_cas
  4(ACTIVE)           dba         myhost             696              csql
  5(ACTIVE)        public         myhost            6944              csql
-------------------------------------------------------------------------------
-q, --query-exec-info

SQL Text를 포함하여 트랜잭션의 질의 수행 상태를 출력한다. 상태 정보를 출력하는 예는 다음과 같다. 출력 정보 중 SQL_ID는 --kill-sql-id 옵션에서 사용될 수 있다.

$ cubrid killtran --query-exec-info testdb

Tran index   Process id  Program name  Query time Tran time  Wait for lock holder         SQL_ID     SQL Text
-------------------------------------------------------------------------------------------------------------------
  1(ACTIVE)      8536    b1_cub_cas_1        0.00      0.00  -1                                      *** empty ***
  2(ACTIVE)      8538    b1_cub_cas_3        0.00      0.00  -1                                      *** empty ***
  3(ACTIVE)      8537    b1_cub_cas_2        0.00      0.00  -1                                      *** empty ***
  4(ACTIVE)      8543    b1_cub_cas_4        1.80      1.80  3, 2, 1               5377225ebc75a     update [ta] [ta] set [a]=5 wher
  5(ACTIVE)      8264    b1_cub_cas_5        0.00      0.60  -1                                      *** empty ***
  6(ACTIVE)      8307    b1_cub_cas_6        0.00      0.00  -1                    cdcb58552e320     select [a].[index_name], ( cast
  7(ACTIVE)      8308    b1_cub_cas_7        0.00      0.20  -1                    cdcb58552e320     select [a].[index_name], ( cast
  .....

---------------------------------------------------------------------------------------------
  • Tran index: 트랜잭션 인덱스
  • Process id: 클라이언트 프로세스 ID
  • Program name: 클라이언트 프로그램 이름
  • Query time: 수행중인 질의의 총 수행 시간(단위: 초)
  • Tran time: 현재 트랜잭션의 총 수행 시간(단위: 초)
  • Wait for lock holder: 현재 트랜잭션이 락 대기중이면 해당 락을 소유하고 있는 트랜잭션의 리스트
  • SQL ID: SQL Text에 대한 ID
  • SQL Text: 수행중인 질의문(최대 30자)

위와 같이 트랜잭션 전체 정보가 출력된 후, 잠금 대기를 유발한 질의문이 다음과 같이 출력된다.

Tran index : 4
update [ta] [ta] set [a]=5 where (([ta].[a]> ?:0 ))
Tran index : 5, 6, 7
select [a].[index_name], ( cast(case when [a].[is_unique]=0 then 'NO' else 'YES' end as varchar(3))), ( cast(case when [a].[is_reverse]=0 then 'NO' else 'YES' end as varchar(3))), [a].[class_of].[class_name], [a].[key_count], ( cast(case when [a].[is_primary_key]=0 then 'NO' else 'YES' end as varchar(3))), ( cast(case when [a].[is_foreign_key]=0 then 'NO' else 'YES' end as varchar(3))), [b].[index_name], ( cast(case when [b].[is_unique]=0 then 'NO' else 'YES' end as varchar(3))), ( cast(case when [b].[is_reverse]=0 then 'NO' else 'YES' end as varchar(3))), [b].[class_of].[class_name], [b].[key_count], ( cast(case when [b].[is_primary_key]=0 then 'NO' else 'YES' end as varchar(3))), ( cast(case when [b].[is_foreign_key]=0 then 'NO' else 'YES' end as varchar(3))) from [_db_index] [a], [_db_index] [b] where (( CURRENT_USER ='DBA' or {[a].[class_of].[owner].[name]} subseteq (select set{ CURRENT_USER }+coalesce(sum(set{[t].[g].[name]}), set{}) from [db_user] [u], table([u].[groups]) [t] ([g]) where ([u].[name]= CURRENT_USER )) or {[a].[class_of]} subseteq (select sum(set{[au].[class_of]}) from [_db_auth] [au] where ({[name]} subseteq (select set{ CURRENT_USER }+coalesce(sum(set{[t].[g].[name]}), set{}) from [db_user] [u], table([u].[groups]) [t] ([g]) where ([u].[name]= CURRENT_USER )) and [au].[auth_type]= ?:0 ))) and ( CURRENT_USER ='DBA' or {[b].[class_of].[owner].[name]} subseteq (select set{ CURRENT_USER }+coalesce(sum(set{[t].[g].[name]}), set{}) from [db_user] [u], table([u].[groups]) [t] ([g]) where ([u].[name]= CURRENT_USER )) or {[b].[class_of]} subseteq (select sum(set{[au].[class_of]}) from [_db_auth] [au] where ({[name]} subseteq (select set{ CURRENT_USER }+coalesce(sum(set{[t].[g].[name]}), set{}) from [db_user] [u], table([u].[groups]) [t] ([g]) where ([u].[name]= CURRENT_USER )) and [au].[auth_type]= ?:1 ))))

화면에 출력되는 질의문은 질의 계획 캐시에 저장되어 있는 것으로, 응용 프로그램에서 수행되는 INSERT 문이나 질의 계획이 캐시되지 않는 질의문은 출력되지 않는다. 또한 출력 형태도 질의 파싱이 완료된 후의 질의문이 출력되므로, 사용자가 입력한 질의문과는 다른 형태일 수 있다.

예를 들어 사용자가 아래와 같은 질의문을 수행하면

UPDATE ta SET a=5 WHERE a > 0

출력되는 질의문은 다음과 같다.

update [ta] [ta] set [a]=5 where (([ta].[a]> ?:0 ))
-f, --force

중지할 트랜잭션을 확인하는 프롬프트를 생략한다.

cubrid killtran -f -i 1 testdb

데이터베이스 진단/파라미터 출력

데이터베이스 일관성 확인

cubrid checkdb 유틸리티는 데이터베이스를 확인하기 위해 사용된다. cubrid checkdb 유틸리티를 사용하면 인덱스와 다른 데이터 구조를 확인하기 위해 데이터와 로그 볼륨의 내부적인 물리적 일치를 확인할 수 있다. 만일 cubrid checkdb 유틸리티의 실행 결과가 불일치로 나온다면 --repair 옵션으로 자동 수정을 시도해 보아야 한다.

cubrid checkdb [options] database_name [table_name1 table_name2 ...]
  • cubrid: CUBRID 서비스 및 데이터베이스 관리를 위한 통합 유틸리티
  • checkdb: 대상 데이터베이스에 대하여 데이터의 일관성(consistency)을 확인하는 명령
  • database_name: 일관성을 확인하거나 복구하려는 데이터베이스 이름
  • table_name1 table_name2: 일관성을 확인하거나 복구하려는 테이블 이름을 나열한다.

다음은 cubrid checkdb 에 대한 [options]이다.

-S, --SA-mode

서버 프로세스를 구동하지 않고 데이터베이스에 접근하는 독립 모드(standalone)로 작업하기 위해 지정되며, 인수는 없다. -S 옵션을 지정하지 않으면, 시스템은 클라이언트/서버 모드로 인식한다.

cubrid checkdb -S testdb
-C, --CS-mode

서버 프로세스와 클라이언트 프로세스를 각각 구동하여 데이터베이스에 접근하는 클라이언트/서버 모드로 작업하기 위한 옵션이며, 인수는 없다. -C 옵션을 지정하지 않더라도 시스템은 기본적으로 클라이언트/서버 모드로 인식한다.

cubrid checkdb -C testdb
-r, --repair

데이터베이스의 일관성에 문제가 발견되었을 때 복구를 수행한다.

cubrid checkdb -r testdb
-i, --input-class-file=FILE

-i FILE 옵션을 지정하거나, 데이터베이스 이름 뒤에 테이블의 이름을 나열하여 일관성 확인 또는 복구 대상을 한정할 수 있다. 두 가지 방법을 같이 사용할 수도 있으며, 대상을 지정하지 않으면 전체 데이터베이스를 대상으로 일관성을 확인하거나 복구를 수행한다. 특정 대상이 지정되지 않으면 전체 데이터베이스가 일관성 확인 또는 복구의 대상이 된다.

cubrid checkdb testdb tbl1 tbl2
cubrid checkdb -r testdb tbl1 tbl2
cubrid checkdb -r -i table_list.txt testdb tbl1 tbl2

-i 옵션으로 지정하는 테이블 목록 파일은 공백, 탭, 줄바꿈, 쉼표로 테이블 이름을 구분한다. 다음은 테이블 목록 파일의 예로, t1부터 t10까지를 모두 일관성 확인 또는 복구를 위한 테이블로 인식한다.

t1 t2 t3,t4 t5
t6, t7 t8   t9

     t10

데이터베이스 내부 정보 출력

cubrid diagdb 유틸리티를 이용해 다양한 데이터베이스 내부 정보를 확인할 수 있다. cubrid diagdb 유틸리티가 제공하는 정보들은 현재 데이터베이스의 상태를 진단하거나 문제를 파악하는데 도움이 된다.

cubrid diagdb [option] database_name
  • cubrid: CUBRID 서비스 및 데이터베이스 관리를 위한 통합 유틸리티이다.
  • diagdb: CUBRID에 저장되는 바이너리 형태의 파일 정보를 텍스트 형태로 출력하여 현재의 데이터베이스 저장 상태를 확인하고자 할 때 사용하는 명령어이다. 데이터베이스가 구동 정지 상태인 경우에만 정상적으로 수행된다. 전체를 확인하거나 옵션을 사용하여 파일 테이블, 파일 용량, 힙 용량, 클래스 이름, 디스크 비트맵을 선택해 확인할 수 있다.
  • database_name: 내부 정보를 확인하려는 데이터베이스 이름이다.

다음은 cubrid diagdb 에서 사용하는 [option]이다.

-d, --dump-type=TYPE

testdb라는 데이터베이스의 전체 파일에 대한 기록 상태를 출력할 때 출력 범위를 지정한다. 생략하면 기본값인 1이 지정된다.

cubrid diagdb -d 1 myhost testdb

-d 옵션에 적용되는 타입은 모두 9가지로, 그 종류는 다음과 같다.

타입 설명
-1 전체 데이터베이스 정보를 출력한다.
1 파일 테이블 정보를 출력한다.
2 파일 용량 정보를 출력한다.
3 힙 용량 정보를 출력한다.
4 인덱스 용량 정보를 출력한다.
5 클래스 이름 정보를 출력한다.
6 디스크 비트맵 정보를출력한다.
7 카탈로그 정보를 출력한다.
8 로그 정보를 출력한다.
9 힙(heap) 정보를 출력한다.

서버/클라이언트에서 사용하는 파라미터 출력

cubrid paramdump 유틸리티는 서버/클라이언트 프로세스에서 사용하는 파라미터 정보를 출력한다.

cubrid paramdump [options] database_name
  • cubrid: CUBRID 서비스 및 데이터베이스 관리를 위한 통합 유틸리티이다.
  • paramdump: 서버/클라이언트 프로세스에서 사용하는 파라미터 정보를 출력하는 명령이다.
  • database_name: 파라미터 정보를 출력할 데이터베이스 이름이다.

다음은 cubrid paramdump 에서 사용하는 [options]이다.

-o, --output-file=FILE

데이터베이스의 서버/클라이언트 프로세스에서 사용하는 파라미터 정보를 지정된 파일에 저장하는 옵션이며, 파일은 현재 디렉터리에 생성된다. -o 옵션이 지정되지 않으면 메시지는 콘솔 화면에 출력한다.

cubrid paramdump -o db_output testdb
-b, --both

데이터베이스의 서버/클라이언트 프로세스에서 사용하는 파라미터 정보를 콘솔 화면에 출력하는 옵션이며, -b 옵션을 사용하지 않으면 서버 프로세스의 파라미터 정보만 출력한다.

cubrid paramdump -b testdb
-S, --SA-mode

독립 모드에서 서버 프로세스의 파라미터 정보를 출력한다.

cubrid paramdump -S testdb
-C, --CS-mode

클라이언트-서버 모드에서 서버 프로세스의 파라미터 정보를 출력한다.

cubrid paramdump -C testdb

HA 모드 변경, 로그 복제/반영

cubrid changemode 유틸리티는 서버의 HA 모드 출력 또는 변경하는 유틸리티이다.

cubrid copylogdb 유틸리티는 HA 구성을 위해 트랜잭션 로그를 다중화하는 유틸리티이다. 이 유틸리티는 cubrid heartbeat 유틸리티를 이용하여 실행된다.

cubrid applylogdb 유틸리티는 HA 구성을 위해 트랜잭션 로그에서 복제 로그를 읽고 적용하는 유틸리티이다. 이 유틸리티는 cubrid heartbeat 유틸리티를 이용하여 실행된다.

cubrid applyinfo 유틸리티는 HA 환경에서 트랜잭션 로그 반영 정보를 확인하는 유틸리티이다.

자세한 사용법은 cubrid service 유틸리티 을 참고한다.

로캘 컴파일/출력

cubrid genlocale 유틸리티는 사용하고자 하는 로캘(locale) 정보를 컴파일하는 유틸리티이다. 이 유틸리티는 make_locale.sh (Windows는 .bat) 스크립트 내에서 실행된다.

cubrid dumplocale 유틸리티는 컴파일된 바이너리 로캘 파일을 사람이 읽을 수 있는 형태로 콘솔에 출력한다. 출력 값이 매우 클 수 있으므로, 리다이렉션을 이용하여 특정 파일로 저장할 것을 권장한다.

cubrid synccolldb 유틸리티는 데이터베이스와 로캘 라이브러리 사이의 콜레이션 불일치 여부를 체크하고, 불일치하는 경우 동기화한다.

자세한 사용법은 로캘 설정 을 참고한다.