GOLDILOCKS Instance 관리

본 장에서는 GOLDILOCKS instance를 관리하기 위한 기반 지식에 대해 설명한다.

Overview

GOLDILOCKS database system은 database와 instance로 구성된다. Database는 메모리상에 존재하는 dictionary data들과 사용자 data, 그리고 이에 대한 각각의 data file, 온라인 redo file 등 database를 구동하기 위한 각종 file들의 집합이다.

Database instance는 GOLDILOCKS database를 운용하기 위해 사용되는 run-time 정보들을 담고 있는 메모리 부분과 이를 운용하고 관리하는 background process를 의미한다. 각 database instance들은 shared memory를 구성할 때 사용되는 shared memory key 값과 "GOLDILOCKS_DATA" 환경 변수 값으로 구분된다.

프로퍼티 설정

$GOLDILOCKS_DATA/conf/goldilocks.property.conf 파일에는 GOLDILOCKS의 프로퍼티가 기술되어 있다. 기본 프로퍼티로도 GOLDILOCKS를 설치할 수 있는데 본 문서에서는 TBS (tablespace), LOG, CONTROL FILE 등 주요 프로퍼티에 대해서만 설명한다.

다음은 GOLDILOCKS 설치 시 주요 프로퍼티 항목과 그에 대한 설명이다.

Database나 instance의 설정을 변경하고 싶을 때는 text 프로퍼티 파일 ($GOLDILOCKS_DATA/conf/goldilocks.properties.conf)을 변경하거나 환경 변수에 GOLDILOCKS_<property_name> 형태의 변수를 새로 정의하면 된다. 프로퍼티 파일에 설정된 값이 환경 변수에 설정된 값보다 우선한다.

Background 프로세스

GOLDILOCKS는 instance를 관리하기 위한 background 프로세스 (gmaster)를 가지고 있다. gmaster는 내부적으로 여러 개의 system thread로 구성되어 있으며 그 내용은 다음과 같다.

Client 프로세스

Client/ Server 모델

Client/ Server (이하 C/S) 모델을 사용하는 응용 프로그램은 접속 요청을 기다리고 있는 listener (glsnr)에 접속하여 새로운 데이터베이스 서비스 프로세스 (gserver)를 생성하고 (dedicated 모드) 이 프로세스와의 TCP 통신으로 사용자의 요청을 처리한다. 프로세스간 통신을 통해 작업을 수행하므로 응용 프로그램 단에서 발생하는 모든 signal은 데이터베이스의 상태에 영향을 미치지 않으며, cleanup threads는 비정상적으로 종료된 응용 프로그램이 사용하던 모든 자원을 주기적으로 체크하여 반납한다.

Direct Access 모델

GOLDILOCKS는 Client/ Server (C/S) 모델과 더불어 Direct Access (D/A) 모델을 지원한다. 모든 응용 프로그램들은 GOLDILOCKS가 제공하는 서버 library를 링크하여 직접 database와 instance에 접근한다. 따라서 별도의 서비스 프로세스 없이 응용 프로그램 프로세스들만 존재한다.

D/A 모델로 작성된 응용 프로그램 프로세스가 운영 중에 발생하는 signal에 의해 비정상적으로 중단된 경우, 해당 프로세스가 사용하던 자원은 라이브러리가 connection 할 때 설정한 signal handler 함수에 의해 다음 두 단계로 정리된다.

1. 해당 프로세스의 signal handler는 자신이 사용하는 session 객체에 비정상 종료함을 표시하고 종료된다.

2. C/S 모델과 동일하게 gmaster의 cleanup thread에 의해 일정 시간 후에 database로 반환된다.

D/A 모델에서는 응용 프로그램 프로세스가 직접 데이터베이스 영역에 접근하므로 다음 사항들에 유의하여 사용해야 한다.

• D/A 모델로 운영 중이던 응용 프로그램 프로세스가 SEGV 등과 같은 치명적인 signal을 받아 바로 종료되면 library가 connection 할 때 등록한 signal handler가 사용 중이던 공유자원을 해제해야 하므로 응용 프로그램 내에 특정 시그널의 handler를 설치해야 할 경우, database에 connect 하기 전에 선언해야 한다.

• 응용 프로그램 프로세스를 강제로 종료시킬 때는 프로세스가 signal 발생을 탐지할 수 없는 SIGKILL (kill -9)을 사용하지 말고 SIGTERM, SIGQUIT 이나 SIGUSR2 등을 사용해야 한다.

Instance의 메모리 구조

Database instance가 사용하는 메모리의 크기는 프로퍼티 파일에 지정된 관련 프로퍼티들에 의해 결정된다. Instance가 사용하는 shared memory는 크게 static 영역과 테이블스페이스 영역으로 나뉜다. Static 영역은 database를 운용하기 위해 여러 프로세스 사이에 공용으로 사용되는 instance의 기본 정보들과 각 session, statement 및 transaction 정보들, redo log buffer, dictionary cache 정보, 그리고 그 외 여러 가지 운용 정보들을 담고 있다. 테이블스페이스 영역은 각 테이블스페이스의 내용을 포함하는 page frame들과 이를 제어하기 위한 page control header (PCH)들로 구성되어 있다.

응용 프로그램 프로세스의 메모리는 connect 할 때 attach한 instance 메모리 외에 프로세스 단위로 공유하는 ODBC environment와 여러 ODBC handle들, 그리고 bind 정보와 같은 기타 정보들을 포함하고 있는 heap 메모리 영역을 추가적으로 포함하고 있다.

Instance 시작과 종료

GOLDILOCKS instance를 시작하려면 SHARED_MEMORY_STATIC_KEY 프로퍼티가 다른 instance들과 다르게 설정되어 있어야 한다. 이후 gsql을 이용하여 시작할 수 있는데 다음과 같이 sysdba role을 가지도록 실행시켜야 한다.

C/S 모델의 dedicated 모드에서 GOLDILOCKS instance를 시작하거나 종료하려면 listener가 실행되어 있어야 한다.
C/S 모델의 shared 모드에서는 GOLDILOCKS instance를 시작하거나 종료할 수 없다.

% gsql sys gliese --as sysdba

Connected to GOLDILOCKS Database.

gSQL>

GOLDILOCKS instance는 다음과 같이 여러 단계의 startup phase를 갖는다.

• NOMOUNT

  • GOLDILOCKS instance를 관리하는 데몬인 gmaster 프로세스를 띄운다

• MOUNT

  • $GOLDILOCKS_DATA 환경 변수를 이용하여 프로퍼티들과 복구를 위한 control file을 읽어들인다.

• OPEN

  • 테이블스페이스의 내용을 data file들로부터 로딩한 후 redo log file들을 이용하여 복구하고 no-logging index들을 새로 build 하여 dictionary cache를 생성한 후에 사용자의 서비스 접속을 기다린다.

다음 gsql 명령으로 GOLDILOCKS instance를 startup 한다.

gSQL> ＼startup nomount
Startup success

gSQL> alter system mount database;
System altered.

gSQL> alter system open database;
System altered.

만일 바로 OPEN 단계로 진입하려면 다음과 같이 수행한다.

gSQL> ＼startup open
Startup success

GOLDILOCKS instance가 종료되면 관리 데몬 프로세스인 gmaster가 종료되어 더 이상의 접속 및 기타 database 작업을 수행할 수 없다.

GOLDILOCKS instance는 다음과 같은 네 가지 방법으로 종료할 수 있다.

• NORMAL

  • 새로운 session의 접속을 차단하고 현재 접속된 모든 session이 종료될 때까지 기다린 후, checkpoint를 수행하고 instance를 내린다.

• TRANSACTIONAL

  • 새로운 transaction의 시작을 차단하고 현재 수행 중인 transaction들이 종료될 때까지 기다린 후, checkpoint를 수행하고 instance를 내린다.

• IMMEDIATE

  • 새로운 단위 연산 (FETCH, EXECUTE 등과 같은 GOLDILOCKS database와의 통신 단위)의 수행을 차단하고 현재 수행 중인 모든 단위 연산이 종료될 때까지 기다린 후, 모든 transaction들을 rollback하고 checkpoint를 수행한 후 instance를 내린다.

• ABORT

  • 접속 중인 session들의 상태와 관계없이 바로 gmaster를 종료시켜 instance를 내린다.

Instance를 종료할 때도 sysdba role로 gsql을 수행하고 다음과 같이 \shutdown 명령을 수행한다.

% gsql sys gliese --as sysdba

Connected to GOLDILOCKS Database.

gSQL> \shutdown normal

Shutdown success

gSQL>

Listener 시작과 종료

Client/ server 환경에서 서비스하려면 listener를 구동시켜야 한다.

다음과 같이 listener를 구동한다.

% glsnr --start
 
Listener is started successfully.

%

다음과 같이 listener를 종료한다.

% glsnr --stop
 
Listener is stopped.

%

Listener 제어에 대한 자세한 설명은 glsnr을 참조한다.
Cluster system의 시작과 종료 방법은 Cluster System 시작과 종료를 참조한다.

GOLDILOCKS 설치, 삭제와 Database 생성

본 절에서는 GOLDILOCKS software를 install하고 database를 생성하는 방법에 대해 설명한다.

Overview

GOLDILOCKS software는 goldilocks-<version_no>-<os_type>-<cpu_type>.tar.gz라는 이름의 압축파일로 제공되는데 압축을 풀면 해당 위치에 필요한 software 바이너리들과 각종 sample 및 기본적인 database directory 구조가 생성된 후 install이 완료된다. Install이 끝나면 해당 package 이름의 디렉토리가 생성되며 그 아래에 goldilocks_home과 goldilocks_data 디렉토리가 생성된다.

• goldilocks_home 디렉토리

  • GOLDILOCKS product의 바이너리 홈이다.

  • GOLDILOCKS_HOME 환경 변수로 정의된다.

  • 실행 바이너리, 클라이언트용 라이브러리, 헤더 파일, 라이센스 등이 위치한다.

• goldilocks_data 디렉토리

  • GOLDILOCKS가 생성할 사용자 데이터베이스 (instance)의 홈이다.

  • GOLDILOCKS_DATA 환경 변수로 정의된다.

  • 데이터 파일, 로그파일, 프로퍼티 파일 등이 존재하는 디폴트 위치이다.

이후 $GOLDILOCKS_DATA 위치에 database를 생성하는 작업은 $GOLDILOCKS_HOME/bin 디렉토리에 존재하는 gcreatedb라는 유틸리티를 사용한다.

릴리즈 플랫폼

GOLDILOCKS는 다음과 같은 릴리즈 플랫폼에서 사용할 수 있다.

[1] CentOS 8, RHEL 8 이상에서는 사용자가 libnsl을 추가로 설치해야 한다.

시스템 요구사항

GOLDILOCKS를 install 하기 전에 다음과 같은 시스템 요구사항을 확인해야 한다.

• Physical memory와 디스크의 공간이 최소 2 G 이상 확보되어 있어야 한다.

• 충분한 양의 paging (swap) 영역이 존재해야 한다.

• Install 할 platform에 적합한 패키지 버전을 가지고 있어야 한다.

GOLDILOCKS Package 구성

GOLDILOCKS 설치 시 디렉토리의 구성 내용에 대해 설명한다.

Package 디렉토리 구성

Package 파일 목록

각 디렉토리에 포함되어 있는 파일 및 server package 또는 client package에 포함되는지 여부를 설명한다.

GOLDILOCKS를 standalone으로 사용할 때는 admin/ standalone 디렉토리 내의 생성 스크립트를 사용하고, cluster system을 구성하여 사용할 때는 admin/ cluster 디렉토리 내의 생성 스크립트를 사용한다.

GOLDILOCKS Software 설치

GOLDILOCKS를 설치하기 전에 운영체제 및 환경 설정에 대해 설명한다.

커널 파라미터

공유 메모리 (shared memory)

공유 메모리란 Inter Process Communication (IPC)의 일종으로 복수의 프로그램에서 데이터를 공유하기 위해 사용되는 메모리를 가리키는 용어이다. GOLDILOCKS에서는 공유 메모리와 함께 gsql, gloader 및 Client/ Server (C/S) 환경의 ODBC를 이용하는 사용자 프로그램을 사용한다. 또한 운영에 필요한 tablespace들이 모두 공유 메모리에 생성되기 때문에 다른 프로그램에서 권장되는 값보다 정확하게 설정해야 한다.

다음은 GOLDILOCKS 설치에 사용되는 공유 메모리에 필요한 항목과 권장값이다.

다음은 테이블스페이스의 총합이 32 G 였을 때 shmall 값의 예이다.

kernel.shmmax = 34359738368
kernel.shmmni=4096
kernel.shmall = 8388609

• shmmax 값은 32 G이며, PAGE_SIZE 4096 byte라고 가정하였다.

8388609 = (34359738368 / 4096) + 1

• 이 경우 shmall은 8388609 이상의 값을 가져야 한다.

세마포어 (semaphore)

세마포어 (semaphore)는 공유 메모리 (shared memory)와 같은 IPC의 일종으로 운영체제에서 자원을 사용하는 복수의 프로세스의 행동을 제어하는 기술이다. 세마포어는 설정에 따라 복수의 프로세스가 해당 자원을 동시에 참조하게 할 수 있고 다른 프로세스가 사용 중인 자원에 대해 해당 프로세스가 사용을 마칠 때까지 대기하도록 할 수도 있다.

GOLDILOCKS에서도 앞에서 설명한 공유 메모리에 대한 접근순서를 제어하기 위해 세마포어가 사용된다. 예를 들어, 다수의 GOLDILOCKS 클라이언트 프로그램에서 동일한 데이터 변경을 요청하는 경우 이를 적절하게 제어할 수 있어야 하기 때문이다. 세마포어의 파라미터 값은 GOLDILOCKS를 운영할 때 발생하는 세마포어 오퍼레이션에 따라 적절한 값으로 설정되어야 하며 본 문서에서는 리눅스의 일반값을 권장한다.

다음은 GOLDILOCKS 설치에 사용되는 세마포어의 권장값이다.

Redhat, Ubuntu와 같은 리눅스 기반 시스템의 systemd가 관리하는 세션 목록에서 IPC 자원 생성 사용자가 로그아웃하면 해당 IPC 자원이 자동 삭제되는 옵션이 생김에 따라 시스템을 다음과 같이 설정해 주어야 세마포어 삭제를 방지할 수 있다. (커널 3.0.0 이상)

# cp -i /etc/systemd/logind.conf /etc/systemd/logind.conf_prev

# cat /etc/systemd/logind.conf
[Login]
#NAutoVTs=6
#ReserveVT=6
...
RemoveIPC=no

• 수정 후 수행한다.

# systemctl restart systemd-logind

네트워크 (network)

Backlog는 TCP socket listen 할 때 accept 되길 기다리는 socket들의 queue 길이이다. GOLDILOCKS glsnr의 backlog는 glsnr의 config 파일의 BACKLOG로 설정한다. System에서 backlog의 최대값이 somaxconn 보다 큰 경우에는 somaxconn로 설정되므로 이 때는 somaxconn를 늘려주어야 한다.

GOLDILOCKS에서 C/S의 shared 모드로 동작할 때 사용되는 Unix Domain Socket (UDS)의 queue 길이는 max_dgram_qlen으로 설정된다. Client들이 동시에 접속할 때 이 값이 작으면 glsnr, gbalancer, gdispatcher 간의 통신에 병목이 발생한다.

다음은 GOLDILOCKS 설치에 사용되는 네트워크의 권장값이다.

파라미터 적용

일회성으로 적용할 때는 다음과 같이 적용한다. (시스템을 재기동할 때는 다시 적용해야 한다.)

[SHELL]> echo   34359738368   >  /proc/sys/kernel/shmmax
[SHELL]> echo   8388608 >   /proc/sys/kernel/shmall
[SHELL]> echo   4096   >  /proc/sys/kernel/shmmni
[SHELL]> echo   250 32000 100 128  /proc/sys/kernel/sem
[SHELL]> echo   1024   >  /proc/sys/net/core/somaxconn
[SHELL]> echo   256   >  /proc/sys/net/unix/max_dgram_qlen

시스템이 다시 시작될 때도 적용되게 하려면 /etc/sysctl.conf에 다음과 같이 기술한다.

# shared memory
kernel.shmmax = 34359738368
kernel.shmall = 8388608
kernel.shmmni = 4096

# semaphore
kernel.sem = 250 32000 100 128

# network
net.core.somaxconn = 1024
net.unix.max_dgram_qlen = 256

기술된 내용이 반영되도록 하려면 다음 명령어를 이용한다.

[SHELL]> sysctl  -p

파라미터 확인

기술된 파라미터는 다음 명령어로 확인할 수 있다.

[SHELL]> ipcs -l

------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 33554432
max total shared memory (kbytes) = 33554432
min seg size (bytes) = 1

------ Semaphore Limits --------
max number of arrays = 128
max semaphores per array = 250
max semaphores system wide = 32000
max ops per semop call = 100
semaphore max value = 32767

압축해제

GOLDILOCKS의 패키지는 압축형태로 제공되므로 압축을 해제하면 기본 설치가 끝난다.

다음은 GOLDILOCKS 패키지를 설치하는 간단한 예이다.

##  $GOLDILOCKS_HOME=/home/GOLDILOCKS/goldilocks-mercury.2.1.0-linux-x86_64/

[SHELL]> gzip –d goldilocks-mercury.2.1.0-linux-x86_64.tar.gz

[SHELL]> tar -xvf goldilocks-server-mercury.2.1.0-linux-x86_64.tar
goldilocks-server-mercury.2.1.0-linux-x86_64/goldilocks_home/include/sqlext.h
goldilocks-server-mercury.2.1.0-linux-x86_64/goldilocks_home/include/goldilocks.h
goldilocks-server-mercury.2.1.0-linux-x86_64/goldilocks_home/include/sqlca.h
…

압축 해제가 완료되면 <package_file_name>으로 생성된 디렉토리의 이름을 원하는 대로 변경할 수 있다. 이에 따라 $GOLDILOCKS_HOME과 $GOLDILOCKS_DATA 환경 변수도 변경해야 한다.

압축 해제 후 생성되는 디렉토리에 대한 설명은 GOLDILOCKS Package 구성을 참조한다.

환경 변수 설정

GOLDILOCKS package의 압축을 해제한 후에는 향후 GOLDILOCKS software를 실행하고 응용 프로그램을 개발하기 위하여 $GOLDILOCKS_HOME 디렉토리 아래에 생성된 bin과 lib를 각각 다음과 같이 PATH와 LD_LIBRARY_PATH에 추가한다. (GOLDILOCKS client 응용 프로그램을 개발할 때는 항상 컴파일 옵션의 include file directory로 $GOLDILOCKS_HOME/include를 넣어주어야 한다)

export PATH=$GOLDILOCKS_HOME/bin:$PATH
export LD_LIBRARY_PATH=$GOLDILOCKS_HOME/lib:$LD_LIBRARY_PATH

GOLDILOCKS를 사용하는데 필요한 환경 변수가 있다. 설치할 때 참조되는 변수도 있기 때문에 반드시 설치하기 전에 설정해야 한다.

##  $GOLDILOCKS_HOME=/home/GOLDILOCKS/goldilocks-mercury.2.1.0-linux-x86_64/

[SHELL]> gzip –d goldilocks-mercury.2.1.0-linux-x86_64.tar.gz

[SHELL]> tar -xvf goldilocks-server-mercury.2.1.0-linux-x86_64.tar
goldilocks-server-mercury.2.1.0-linux-x86_64/goldilocks_home/include/sqlext.h
goldilocks-server-mercury.2.1.0-linux-x86_64/goldilocks_home/include/goldilocks.h
goldilocks-server-mercury.2.1.0-linux-x86_64/goldilocks_home/include/sqlca.h
…

DATABASE 삭제

GOLDILOCKS DATABASE를 다시 생성하기 위해 기존 DATABASE를 삭제하려면 데이터 파일, 컨트롤 파일, redo log file, (archive log 사용시) archive log file을 삭제하면 된다.

다음은 GOLDILOCKS DATABASE를 삭제하는 간단한 예이다.

## $GOLDILOCKS_BASE=/home/GOLDILOCKS/goldilocks-mercury.2.1.0-linux-x86_64/
## $GOLDILOCKS_DATA=/home/GOLDILOCKS/goldilocks-mercury.2.1.0-linux-x86_64/
                    goldilocks_data/
## $GOLDILOCKS_HOME=/home/GOLDILOCKS/goldilocks-mercury.2.1.0-linux-x86_64/
                    goldilocks_home/
[SHELL]> rm -rf $GOLDILOCKS_DATA/db/*.dbf
[SHELL]> rm -rf $GOLDILOCKS_DATA/wal/*.ctl
[SHELL]> rm -rf $GOLDILOCKS_DATA/wal/*.log
[SHELL]> rm -rf $GOLDILOCKS_DATA/archive_log/*.log

데이터 파일이나 archive log file 등의 위치는 사용자 설정에 따라 다를 수 있다.

삭제

GOLDILOCKS 패키지는 압축파일 형태로 제공되므로 특별한 삭제 원칙이 필요하진 않으며 DATABASE를 종료한 후에 설치된 디렉토리를 삭제하면 된다.

다음은 GOLDILOCKS 패키지를 삭제하는 간단한 예이다.

## $GOLDILOCKS_BASE=/home/GOLDILOCKS/goldilocks-mercury.2.1.0-linux-x86_64/
## $GOLDILOCKS_DATA=/home/GOLDILOCKS/goldilocks-mercury.2.1.0-linux-x86_64/
                    goldilocks_data/
## $GOLDILOCKS_HOME=/home/GOLDILOCKS/goldilocks-mercury.2.1.0-linux-x86_64/
                    goldilocks_home/
[SHELL]> rm -rf $GOLDILOCKS_DATA
[SHELL]> rm -rf $GOLDILOCKS_HOME
[SHELL]> rm -rf $GOLDILOCKS_BASE



## ~/.bash_profile
$GOLDILOCKS_BASE=/home/GOLDILOCKS/goldilocks-mercury.2.1.0-linux-x86_64/ 1 삭제
$GOLDILOCKS_DATA=/home/GOLDILOCKS/goldilocks-mercury.2.1.0-linux-x86_64/
                    goldilocks_data/ 2 삭제
$GOLDILOCKS_HOME=/home/GOLDILOCKS/goldilocks-mercury.2.1.0-linux-x86_64/
                    goldilocks_home/ 3 삭제

Database 생성

프로퍼티 생성이 끝난 후 데이터베이스를 생성한다. 데이터베이스는 $GOLDILOCKS_HOME/bin/gcreatedb 명령어를 이용하여 생성할 수 있다. 다음은 gcreatedb 명령어를 사용하는 방법이다.

[SHELL]> gcreatedb --help
Usage 

    gcreatedb [options]

Options:

    --cluster        cluster system (if not specified, stand-alone system)
    --db_name        database name
    --db_comment     database comment
    --timezone       timezone ( {+/-}{TZH:TZM} )
    --character_set  character set
                       SQL_ASCII
                       UTF8
                       UHC
                       GB18030
    --char_length_units  char length units
                          OCTETS
                          CHARACTERS
    --member         local cluster member name
    --host           cluster ip address or host name
    --port           cluster port number
    --silent         suppresses the display of the result message
    --help           print help message

examples:

    gcreatedb --db_name="goldilocks" --db_comment="goldilocks database" --timezone="+09:00" --character_set="UTF8" --char_length_units="OCTETS" --silent

데이터베이스를 생성할 때는 $GOLDILOCKS_HOME/conf/goldilocks.properties.conf를 참조하여 각각의 ***_TABLESPACE_SIZE 값으로 goldilocks.properties.conf의 SYSTEM_TABLESPACE_DIR 경로에 tablespace file들이 생성된다.

Cluster system에 참여시킬 database를 생성할 경우에는 반드시 --cluster 옵션을 명시하여 실행하여야 한다.

다음은 gcreatedb 명령어의 실행 인자에 대한 설명이다.

데이터베이스를 생성할 때는 다음과 같은 사항을 고려하여야 한다.

• Kernel parameter shared memory 설정

  • 앞서 언급한 shared memory 설정에 명시된 사이즈가 $GOLDILOCKS_HOME/conf/goldilocks.properties.conf에 기술된 사이즈보다 작은 경우 데이터베이스를 생성할 수 없다.

• Tablespace 사이즈

  • 데이터베이스를 생성할 때 생성된 tablespace 파일들은 GOLDILOCKS를 기동할 때 그 사이즈만큼 메모리에 할당되어 사용되기 때문에 data tablespace에 실제 사용자 데이터가 없더라도 메모리를 사용한다. 따라서 shared memory는 물론 goldilocks.properties.conf를 작성할 때 GOLDILOCKS가 기동되는 장치의 가용 메모리를 고려하여 데이터베이스를 생성해야 한다.

• Cluster system 사용 여부

  • 데이터베이스를 생성할 때 해당 데이터베이스를 cluster system의 member로 참여시켜 사용할 것인지 여부를 명시해야 한다. 즉, standalone으로 사용할 경우에는 gcreatedb를 실행할 때 --cluster 옵션을 생략해야 하지만 cluster system로 사용할 경우에는 반드시 해당 옵션을 명시해야 한다.

데이터베이스 생성에 성공하면 goldilocks.properties.conf의 SYSTEM_TABLESPACE_DIR에 기술된 경로에 서 다음과 같은 tablespace 파일들을 확인할 수 있다.

[SHELL]> gcreatedb
Database created

[SHELL]> gcreatedb --db_name="TEST_DB"                   \
                   --db_commnet="test database comment"  \
                   --timezone="+09:00"                   \
                   --character_set="UHC"                 \
                   --char_length_units="OCTETS"
Database created

[SHELL]> ls $GOLDILOCKS_DATA/db
system_data.dbf  system_dict.dbf  system_undo.dbf

다음은 cluster system에서 사용될 데이터베이스를 생성하는 예이다.

[SHELL]> gcreatedb --cluster
Database created

[SHELL]> gcreatedb --cluster --member=G1N1
Database created

[SHELL]> gcreatedb --cluster --member=G1N1 --host=127.0.0.1 --port 10101
Database created

[SHELL]> gcreatedb --cluster                         \
                   --db_name="TEST_DB"               \
                   --home=$GOLDILOCKS_DATA           \
                   --host=127.0.0.1                  \
                   --port=10101                      \
                   --db_comment="g1n1 db comment"    \
                   --timezone="+09:00"               \
                   --character_set="UHC"             \
                   --char_length_units="OCTETS"
Database created

[SHELL]> ls $GOLDILOCKS_DATA/db
system_data.dbf  system_dict.dbf  system_trans.dbf system_undo.dbf

Dictionary Schema 정보 구축

시스템 및 객체 정보를 조회하기 위해 다음과 같은 스키마를 생성한다.

• DICTIONARY_SCHEMA: DBA_*, ALL_*, USER_* 등의 객체 정보를 조회하는 view 및 table로 구성된다.

• INFORMATION_SCHEMA: SQL 표준의 INFORMATION_SCHEMA에 포함되는 view 및 table로 구성된다.

• PERFORMANCE_VIEW_SCHEMA: Fixed table들의 정보를 조합하여 시스템 정보를 조회하는 view로 구성된다.

해당 스키마들에 포함된 view와 table들은 시스템의 정보를 편리하게 조회할 수 있도록 한다.

GOLDILOCKS instance를 OPEN 상태로 구동한 후에 다음과 같이 sql 파일들을 수행한다. 데이터베이스를 생성한 후에 최초 한 번은 수행해야 한다.

다음은 standalone database용 스크립트를 사용하여 dictionary schema 정보를 구축하는 방법이다.

% gsql --as sysdba --import $GOLDILOCKS_HOME/admin/standalone/DictionarySchema.sql
% gsql --as sysdba --import $GOLDILOCKS_HOME/admin/standalone/InformationSchema.sql
% gsql --as sysdba --import $GOLDILOCKS_HOME/admin/standalone/PerformanceViewSchema.sql

다음은 cluster system용 스크립트를 사용하여 dictionary schema 정보를 구축하는 방법이다.

% gsql --as sysdba --import $GOLDILOCKS_HOME/admin/cluster/DictionarySchema.sql
% gsql --as sysdba --import $GOLDILOCKS_HOME/admin/cluster/InformationSchema.sql
% gsql --as sysdba --import $GOLDILOCKS_HOME/admin/cluster/PerformanceViewSchema.sql

Database 저장구조 관리

본 절에서는 GOLDILOCKS instance를 구성하는 데이터베이스의 구성 요소들에 대해 설명한다.

Database 저장구조

GOLDILOCKS database는 크게 memory 영역과 disk 영역으로 나뉜다. Memory 영역은 하나 이상의 shared memory 집합으로 구성된 테이블스페이스들의 집합체이며 replace 작업에 의해 disk로 내려가는 경우가 발생하지 않는다.

Disk 영역은 각 테이블스페이스의 shared memory 한 개당 하나씩 존재하는 data file들과 instance의 구성 정보를 저장하고 있는 control file, instance의 환경설정이 저장된 프로퍼티 파일, 그리고 database 복구를 위해 기록되는 온라인 redo log file들로 구성되어 있다.

Control File

Control file은 database의 디스크상에 물리적인 저장 정보를 기록하고 있는 파일이며 instance를 startup할 때 가장 먼저 읽어들여 database의 상태를 파악하는 파일이다. Control file에는 다음과 같은 항목들이 기록되어 있다

• 이전에 checkpoint 할 때의 instance 상태

• 이전에 startup 할 때의 Transaction Durability Mode (CDS/ TDS)

• 온라인 redo log file 정보

• 각 테이블스페이스 별 data file 정보

온라인 Redo Log File

온라인 redo log file은 database가 비정상적으로 종료되었을 때 미처 data file에 기록되지 못한 변경 정보들을 instance를 재기동할 때 복구하기 위해 해당 instance에서 transaction들이 database 변경 연산을 수행한 모든 정보를 남긴 파일이다. 기본적으로 database가 생성될 때 LOG_FILE_SIZE 프로퍼티의 값에 해당하는 크기로 네 개가 생성되며 필요한 경우 추가할 수도 있다. 이 redo log file들은 circular 방식으로 순환하며 재사용된다.

온라인 redo log file이 다음 파일로 switching 되는 시점에는 checkpoint가 발생하여 일부 dirty 된 페이지들을 해당 data file로 내리는데 만일 checkpoint 연산이 지연되어 다음으로 사용될 온라인 redo log file에서 변경된 페이지가 아직 내려가지 못한 경우에는 (ACTIVE 상태인 경우) checkpoint가 완료될 때까지 모든 transaction들이 정지된다. 따라서 응용 프로그램의 성격에 따라 적당한 크기의 온라인 redo file을 생성하는 것이 database 시스템 성능 향상에 도움된다.

Undo Segment

Undo segment들은 부분 또는 전체 rollback을 할 때 사용하기 위해 transaction들이 변경 연산을 수행하기 이전의 이미지들을 미리 기록해 둔 segment이며 변경 연산을 수행하는 transaction당 한 개씩 할당되어 사용된다. Undo segment들은 MEM_UNDO_TBS 테이블스페이스에 저장되는 동시에 다수의 변경 transaction이 발생하거나 대량의 변경 연산이 하나의 transaction으로 수행되는 경우 (bulk delete 등)에 대비하여 충분한 undo 테이블스페이스를 확보해 두는 것이 좋다.

Data File

Data file은 테이블스페이스에 저장된 테이블/ 인덱스의 내용이 그대로 저장된 파일이다.

Data file은 다음 요소들로 구성되어 있다.

• Page

  • Database I/O의 최소 단위로써 현재 8 Kbyte로 정의되어 있다.

• Extent

  • 일정 개수의 연속된 page의 집합이다. Segment가 테이블스페이스로부터 공간을 할당해가는 최소 단위이다.

  • 각 테이블스페이스 별로 extent의 크기는 다를 수 있다.

• Segment

  • 특정 타입의 데이터들을 모아 둔 객체이다. Extent들의 집합으로 구성된다.

예외적으로 MEM_TEMP_TBS 테이블스페이스와 같은 임시 테이블스페이스는 redo logging도 하지 않으며 data file도 생성하지 않는다.

테이블스페이스

Database는 테이블과 인덱스 등을 담고 있는 논리적 구조인 테이블스페이스로 나뉘어진다. GOLDILOCKS의 테이블스페이스는 메모리 테이블스페이스와 디스크 테이블스페이스로 구분된다. 테이블스페이스의 각 데이터 파일별로 shared memory가 생성되어 페이지에 접근할 때 별도의 디스크 I/O가 발생하지 않는 것이 메모리 테이블스페이스이고 시스템의 버퍼 캐쉬를 이용하여 페이지에 접근하는 것이 디스크 테이블스페이스이다. V$TABLESPACE 테이블을 조회하면 현재 database에 존재하는 테이블스페이스들에 대한 정보가 출력된다.

GOLDILOCKS는 기본적으로 다음과 같은 테이블스페이스들을 지원한다.

테이블스페이스 타입

다음과 같이 다섯 가지 테이블스페이스 타입이 있다.

• DICT

  • Dictionary 테이블과 인덱스를 저장하기 위한 테이블스페이스 타입이다.

• DATA

  • 테이블, 인덱스와 같이 일반적인 schema 객체들을 저장하기 위한 테이블스페이스 타입이다.

  • Redo logging과 페이지 flush의 대상이 된다

• UNDO

  • Undo segment들을 저장하기 위한 테이블스페이스 타입이다.

  • Redo logging과 페이지 flush의 대상이 된다

• TEMPORARY

  • SELECT query 중에 생성되는 임시 테이블들과 no-logging index들을 저장하기 위한 테이블스페이스 타입이다.

  • Redo logging과 페이지 flush가 일어나지 않는다.

• TRANSACTION (Cluster only)

  • Cluster system에서 global transaction을 복구하기 위해 사용되는 테이블스페이스 타입이다.

Database 저장 구조 정보 확인

본 절에서는 앞서 기술한 여러 database 저장 구조에 관한 정보를 확인할 수 있는 방법을 설명한다.

Control File 정보

Control file은 바이너리 형식으로 저장되어 있기 때문에 그 내용을 확인하려면 다음과 같이 gdump라는 유틸리티를 사용해야 한다.

[SHELL]> gdump CONTROL control_0.ctl

온라인 Redo Log File 정보

gdump tool을 사용하여 control file을 조회하면 각 온라인 redo file들의 이름과 현재 상태가 표시된다.

Data File 정보

gdump tool을 사용하여 control file을 조회하면 각 테이블스페이스에 속한 데이터 파일들과 각각의 상태가 표시된다. 또한 V$DATAFILE 테이블을 조회하면 현재 상태가 표시된다.

테이블스페이스 정보

gdump tool을 사용하여 control file을 조회하면 현재 database에 존재하는 각 테이블스페이스의 이름과 상태가 표시된다. 또한 V$TABLESPACE 테이블을 SQL로 조회할 수도 있다.

프로퍼티 정보

기본적으로는 텍스트 파일인 $GOLDILOCKS_Data/conf/goldilocks.properties.conf 파일을 열어서 확인할 수 있는데 온라인 상태에서는 V$PROPERTY, , V$DB_PROPERTY 테이블을 조회하면 현재 적용 중인 프로퍼티 값들을 알 수 있다.

일반적인 데이터 저장소 작업

데이터 저장소인 테이블스페이스에는 다음과 같은 작업을 할 수 있다.

테이블스페이스 생성

메모리, 디스크 USER DATA 테이블스페이스는 다음과 같은 명령어를 사용하여 생성할 수 있다.

gSQL> CREATE TABLESPACE TEST_TBS DATAFILE 'TEST_TBS.dbf' SIZE 10M;

Tablespace created.

gSQL> CREATE MEMORY TABLESPACE TEST_TBS DATAFILE 'TEST_MEM_TBS.dbf' SIZE 10M;

Tablespace created.

gSQL> CREATE DISK TABLESPACE TEST_TBS DATAFILE 'TEST_DISK_TBS.dbf' SIZE 10M;

Tablespace altered.

gSQL> CREATE DISK TABLESPACE DISK_TBS DATAFILE 'TEST_DISK_TBS.dbf' SIZE 10M AUTOEXTEND OFF;

Tablespace altered.

TEMPORARY 테이블스페이스는 data file을 가지지 않으므로 다음과 같은 구문으로 생성한다.

gSQL> CREATE TEMPORARY TABLESPACE TEST_TEMP_TBS MEMORY 'TEST_TEMP_TBS' SIZE 10M;

Tablespace created.

테이블스페이스 공간 사용 상황 조회

테이블스페이스의 공간은 한 개 이상의 연속된 page로 구성된 extent 단위로 할당되고 해제된다. 특정 테이블스페이스의 extent 한 개의 크기 (BYTE)는 다음과 같이 조회할 수 있다.

gSQL> SELECT EXTENT_SIZE FROM V$TABLESPACE WHERE TBS_NAME = 'TEST_TBS';

EXTENT_SIZE
-----------
     262144

1 row selected.

테이블스페이스의 모든 extent 상태는 D$TABLESPACE_EXTENT 테이블을 사용하여 조회할 수 있다. 사용 중인 extent는 STATE column이 'U’로 표시되고 free 상태의 extent는 ‘F’로 표시된다. 따라서 현재 테이블스페이스의 공간 중 남은 공간의 크기 (extent의 개수)는 다음과 같이 구할 수 있다

gSQL> SELECT COUNT(*) FROM D$TABLESPACE_EXTENT('TEST_TBS') WHERE STATE = 'F';

COUNT(*)
--------
      38

1 row selected.

위의 결과를 보면 현재 TEST_TBS의 빈 공간은 38 * 262144 = 9437184 Byte인 것을 알 수 있다.

테이블스페이스 변경

테이블스페이스를 변경하는 방법에는 add/ remove data file (temporary 테이블스페이스의 경우는 memory)과 online/ offline이 있다.

Add/ Drop Data File (or Memory)

데이터베이스를 운영하는 중에 테이블스페이스의 여유 공간이 부족할 경우 다음과 같은 구문으로 DATA 테이블스페이스에 추가 공간을 할당할 수 있다.

gSQL> ALTER TABLESPACE TEST_TBS ADD DATAFILE 'TEST_TBS2.dbf' SIZE 10M;

Tablespace altered.

TEMPORARY 테이블스페이스에는 다음과 같이 공간을 추가한다. DATA 테이블스페이스와 달리 메모리의 이름을 부여하는데 이는 database 내에서 고유한 이름이어야 한다.

gSQL> ALTER TABLESPACE TEST_TEMP_TBS ADD MEMORY 'TEST_TEMP_TBS2' SIZE 10M;

Tablespace altered.

DATA 테이블스페이스의 공간은 다음과 같은 구문으로 삭제한다. 단, 해당 공간을 일부라도 사용한 경우에는 삭제할 수 없다.

gSQL> ALTER TABLESPACE TEST_TBS DROP DATAFILE 'TEST_TBS2.dbf';

Tablespace altered.

마찬가지로 TEMPORARY 테이블스페이스의 공간은 다음과 같이 회수한다.

gSQL> ALTER TABLESPACE TEST_TEMP_TBS DROP MEMORY 'TEST_TEMP_TBS2';

Tablespace altered.

테이블스페이스 Offline

테이블스페이스에 속한 data file의 위치를 변경하는 등의 작업을 수행할 때는 해당 테이블스페이스를 offline 상태로 변경하여야 한다. 다음 구문을 이용하여 offline 상태로 변경할 수 있다.

gSQL> ALTER TABLESPACE TEST_TBS OFFLINE;

Tablespace altered.

다음과 같이 다시 online 상태로 변경할 수 있다.

gSQL> ALTER TABLESPACE TEST_TBS ONLINE;

Tablespace altered.

디스크 테이블스페이스의 데이터파일 자동확장 속성 변경

디스크 테이블스페이스의 데이터파일은 초기 크기로 생성한 후 필요에 따라 최대 크기까지 자동 확장하는 방식으로 사용할 수 있는데 자동 확장 속성은 다음 구문을 이용하여 변경 (on/off) 할 수 있다. 자동 확장 속성을 변경할 때 데이터 파일의 자동 확장 크기와 최대 크기도 함께 변경할 수 있다.

gSQL> ALTER DATABASE DATAFILE 'TEST_DISK_TBS.dbf' AUTOEXTEND ON;

Database altered.

gSQL> ALTER DATABASE DATAFILE 'TEST_DISK_TBS.dbf' AUTOEXTEND OFF;

Database altered.

gSQL> ALTER DATABASE DATAFILE 'TEST_DISK_TBS.dbf' AUTOEXTEND ON NEXT 10M MAXSIZE 20M;

Database altered.

Rename

테이블스페이스의 이름을 변경하려면 다음 구문을 수행한다.

gSQL> ALTER TABLESPACE TEST_TBS RENAME TO TEST_TBS2;

Tablespace altered.

만일 테이블스페이스 내의 data file 위치를 바꾸려면 해당 테이블스페이스를 우선 offline 상태로 변경해야 하며 이후에 OS 명령어로 해당 data file을 직접 이동시킨 후 ALTER TABLESPACE 구문으로 테이블스페이스의 data file 이름을 변경한 후 테이블스페이스를 online 상태로 다시 변경해야 한다.

gSQL> ALTER TABLESPACE TEST_TBS OFFLINE;

Tablespace altered.

gSQL> ALTER TABLESPACE TEST_TBS RENAME DATAFILE 'TEST_TBS.dbf' TO 'TEST_TBS_1.dbf';

ERR-42000(16164): file does not exist : 
ALTER TABLESPACE TEST_TBS RENAME DATAFILE 'TEST_TBS.dbf' TO 'TEST_TBS_1.dbf'
                                                                         *
ERROR at line 1:

• OS 명령어로 파일 이름을 변경한다.

gSQL> ALTER TABLESPACE TEST_TBS RENAME DATAFILE 'TEST_TBS.dbf' TO 'TEST_TBS_1.dbf';

Tablespace altered.

gSQL> ALTER TABLESPACE TEST_TBS ONLINE;

Tablespace altered.

테이블스페이스 제거

필요 없어진 테이블스페이스는 다음과 같이 제거할 수 있다. INCLUDING 이하 구문은 옵션이며 이 옵션을 사용하면 해당 테이블스페이스에 존재하는 모든 내용 (schema object)들을 제거할 뿐만 아니라 data file들도 제거한다.

gSQL> DROP TABLESPACE TEST_TBS INCLUDING CONTENTS AND DATAFILES;

Tablespace dropped.

Store Mode

GOLDILOCKS는 특정 환경에서 최대의 성능을 발휘할 수 있도록 하기 위해 instance 단위로 store mode를 설정하여 사용할 수 있도록 한다. Store mode란 연산 성능을 향상시키기 위해 transaction들이 ACID 프로퍼티 중에서 어떤 부분을 포기할 것인지를 정해 놓은 것이다.

GOLDILOCKS는 현재 다음과 같은 두 가지 store mode를 지원한다.

• Transactional Data Store (TDS) Mode

  • 이 모드가 GOLDILOCKS database의 default store mode이다.

  • 해당 instance에서 수행되는 모든 transaction들이 redo 및 undo 로그들을 모두 남기는 일반적인 DBMS의 store mode이다. 따라서 transaction들을 rollback 할 수 있고 주기적으로 checkpoint가 이루어지기때문에 비정상적으로 종료되더라도 data file과 온라인 redo log file을 이용하여 복구할 수 있다.

• Concurrent Data Store (CDS) Mode

  • 해당 instance에서 수행되는 모든 transaction들이 undo 로그는 남기지만 redo 로그는 남기지 않는다. 따라서 transaction들은 모든 run-time 에러들에 대처할 수 있고 rollback도 가능하다. 단, instance가 비정상 종료되거나 shutdown abort 명령으로 종료되면 checkpoint가 발생하지 않아 수행되었던 모든 변경 정보들을 잃어버린다. (복구 기능을 제공하지 않는다) 이 모드는 transaction들 간의 동시성을 제어하기 때문에 동일한 객체에 서로 다른 transaction들이 동시에 접근해도 정상적인 동작을 보장한다.

  • 이 모드는 cache 서버와 같이 매우 빈번한 조회와 갱신이 이루어지지만 durability를 보장할 필요는 없는 run-time 정보 위주의 데이터베이스에서 주로 사용된다.

Store mode는 instance를 startup 할 때 프로퍼티 설정을 통해 작동시키는데 transaction들이 서로 다른 store mode로 동작할 수는 없다. 또한 instance가 online인 상태에서는 변경할 수도 없기 때문에 startup할 때 해당 mode를 신중하게 결정해야 한다.

Schema Object 관리

Schema Object

Schema object는 사용자가 생성한 논리적 구조물들이다. GOLDILOCKS는 table, index, synonym, view, sequence, constraint, stored procedure와 같은 schema object들을 지원한다.

Schema Object 관리 권한

현재 GOLDILOCKS는 사용자와 권한을 지원한다. 따라서 생성되는 모든 객체는 모든 사용자에게 공유될 수 없고 공유하기 위해서는 권한을 부여해야 한다.

테이블 관리

본 절에서는 테이블에 대한 개요와 테이블과 관련된 정보를 확인하는 방법, 그리고 테이블의 생성/ 변경/데이터 로딩/ 삭제 방법에 대해 설명한다.

테이블

테이블은 사용자의 데이터를 저장하는 가장 기본적인 단위이다. 테이블은 column과 row로 구성된다.

테이블 타입

현재 GOLDILOCKS는 clustered table, partitioned table을 지원하지 않기 때문에 (데이터의 저장 순서가 특정 column의 sorting order와 상관없는) 일반적인 heap table만 지원한다.

• 기본적인 heap table만 지원한다.

• Primary key/ unique/ not null constraint를 지원한다.

• 지원하는 DataTypes

  • BOOLEAN

  • SMALLINT, INTEGER, BIGINT, REAL, DOUBLE, NUERMIC, FLOAT

  • CHAR(MAX 2000), VARCHAR(MAX 4000), BINARY, VARBINARY, LONG VARCHAR, LONG VARBINARY

  • DATE, TIME, TIMESTAMP, INTERVAL (TIME/ TIMESTAMP는 WITH/ WITHOUT TIMEZONE 지원)

  • BLOB 타입은 지원하지 않는다.

• Column 수/ 인덱스 수/ constraint 수에는 제한이 없다.

• SELECT * FROM TABLES; 질의를 통해 전체 테이블 정보를 확인할 수 있다.

특정 테이블에 저장된 row가 많아져서 그 크기가 너무 커진 경우, bulk delete를 해도 빈 공간이 다시 테이블스페이스에 반납되지는 않는다. 반면 TRUNCATE 연산을 하면 기존의 공간이 모두 테이블스페이스로 반납된다.

GOLDILOCKS를 cluster system으로 구성하여 사용할 경우에는 사용자가 원하는 분배 정책에 따라 테이블의 data를 다수의 노드에 분산하여 저장하고 조회할 수 있다. 자세한 내용은 Cluster System 테이블 관리를 참조한다.

인덱스 관리

본 절에서는 인덱스 개요, 생성 및 삭제에 대해 설명한다.

인덱스 개요

인덱스는 테이블에 연계된 부가적 schema object이다. 인덱스를 사용하면 특정 조건에 해당하는 row의 위치를 찾는 성능이 향상되고 만일 얻으려는 column이 해당 인덱스의 key column일 경우 그 row의 column 값도 알아낼 수 있다.

GOLDILOCKS에서 인덱스는 필요한 만큼 테이블에 생성할 수 있다. 그러나 너무 많은 인덱스는 해당 테이블에 대한 삽입/ 변경/ 삭제 연산에 부하를 주어 성능 저하를 유발할 수도 있다.

Primary key나 unique constraint는 해당 column에 자동으로 인덱스를 생성한다.

인덱스 속성

• B-link tree 형태의 index를 지원한다.

  • GOLDILOCKS는 기본적으로 B-link tree 방식으로 구현된 index를 제공한다.

• Index node 한 개의 크기는 8 Kbyte이다.

• 최대 key column 개수는 32 개, 최대 key 길이는 2000 byte이다.

• Unique index를 지원한다.

• Ascending/ descending, NULLS FIRST, NULLS LAST를 지원한다.

  • 인덱스의 key column들을 작은 순서대로 sorting할지 (ASC), 큰 순서대로 sorting할지 (DESC) 정의할 수 있다.

  • 인덱스의 key column들에서 NULL 값들을 가장 앞에 나열할지 (NULLS FIRST) 가장 나중에 나열할지 (NULLS LAST) 정의할 수 있다.

• SELECT * FROM INDEXES; 질의를 통해 전체 인덱스 정보를 확인할 수 있다.

• 인덱스도 테이블과 동일하게 segment로 구현되므로 테이블과 유사한 방법으로 index 크기를 계산할 수 있다.

시퀀스

시퀀스는 사용자가 고유한 수를 생성하게 하는 schema 객체이다.

다음과 같이 생성한다.

gSQL> CREATE SEQUENCE customers_seq START WITH 1000 INCREMENT BY 1 NOCACHE NOCYCLE; 

Sequence created.

NEXTVAL을 이용하여 시퀀스를 사용할 수 있다.

gSQL> SELECT customers_seq.NEXTVAL FROM dual;

다음과 같이 시퀀스를 제거한다.

gSQL> DROP SEQUENCE customers_seq;

GOLDILOCKS를 cluster system으로 구성하여 사용할 경우에는 사용자가 시퀀스를 생성할 때 global 시퀀스 객체가 자동으로 생성된다. 이 객체는 cluster system에 속한 모든 member 노드가 공유하며 사용할 수 있는 시퀀스 값들의 global pool을 관리한다. 각 member 노드는 NEXTVAL을 호출할 때 global 객체로부터 정해진 개수만큼의 시퀀스 값들을 할당받아 사용한다. 자세한 내용은 Global 시퀀스를 참조한다.

사용자 관리

사용자 생성

GOLDILOCKS 데이터베이스의 사용자는 SYS 사용자와 CREATE USER ON DATABASE 권한을 가진 사용자만 생성할 수 있다. 또한 생성한 사용자에 접속하기 위해서는 CREATE SESSION ON DATABASE 권한이 필요하다.

구문은 다음과 같다.

<user definition> ::=
    CREATE USER user_identifier IDENTIFIED BY password
    [ DEFAULT TABLESPACE tablespace_name ]
    [ TEMPORARY TABLESPACE tablespace_name ]
    [ INDEX TABLESPACE tablespace_name ]

구문 규칙과 파라미터는 다음과 같다.

• user_identifier

  • 생성할 user의 이름이다.

  • 동일한 사용자 이름이나 역할 이름이 존재하지 않아야 한다

  • user_identifier의 길이는 128 byte 보다 작아야 한다

• password

  • 생성할 user의 password로 암호화되어 저장된다.

  • Password의 길이는 128 byte보다 작아야 한다.

  • Password는 대소문자를 구분한다.

• DEFAULT TABLESPACE tablespace_name

  • 생성할 user가 생성하는 테이블, 인덱스 (LOGGING) 등의 객체가 저장될 기본 tablespace를 지정한다

  • DEFAULT TABLESPACE 절을 생략할 경우, DATABASE를 생성할 때 (<database definition>) 정의한 default data tablespace (MEM_DATA_TBS)로 지정된다.

• TEMPORARY TABLESPACE tablespace_name

  • 생성할 user가 생성하는 임시 테이블, 인덱스 (NO LOGGING), 질의 처리 과정에서 생성하는 중간 결과들을 저장할 TABLESPACE를 지정한다.

  • TEMPORARY TABLESPACE 절을 생략할 경우, DATABASE를 생성할 때 (<database definition>) 정의한 default temporary tablespace (MEM_TEMP_TBS)로 지정된다.

• INDEX TABLESPACE tablespace_name

  • 생성할 user가 생성하는 인덱스 객체가 저장되는 기본 tablespace를 지정한다.

  • INDEX TABLESPACE 절을 생략할 경우, 기본값은 INDEX TABLESPACE NULL이다.

사용자 제거

GOLDILOCKS 데이터베이스에서 생성한 사용자를 제거한다. 사용자 범위와 접근 권한은 사용자 생성과 동일하다.

구문은 다음과 같다.

<drop user statement> ::=
    DROP USER [ IF EXISTS ] user_identifier [ <drop behavior> ]
    ;

<drop behavior> ::=
      RESTRICT
    | CASCADE

구문 규칙과 파라미터는 다음과 같다.

• IF EXISTS

  • 사용자가 존재하지 않더라도 에러가 발생하지 않는다.

• user_identifier

  • 제거할 데이터베이스 사용자의 이름이다.

  • Database를 생성할 때 자동으로 생성되는 SYS와 같은 사용자는 제거할 수 없다.

  • Tablespace 객체 등과 같이 user_identifier가 생성했지만 소유자가 아닌 객체는 제거하지 않는다.

• drop behavior

  • 생략할 경우, 기본값은 RESTRICT 이다

사용자 변경

GOLDILOCKS 데이터베이스에서 생성한 사용자의 정의를 변경한다. 사용자는 ALTER USER의 권한이 필요하며 user_identifier와 동일한 사용자일 경우 권한없이 수행할 수 있다.

구문은 다음과 같다.

<alter user statement> ::=
      ALTER USER user_identifier <alter user action>
    | ALTER USER PUBLIC <alter schema path>
    ;

<alter user action> ::=
      <alter password>
    | <alter profile>
    | <alter default tablespace>
    | <alter temporary tablespace>
    | <alter index tablespace>
    | <alter schema path>

<alter password> ::=
    IDENTIFIED BY new_password [ REPLACE old_password ]

<alter profile> ::=
    PROFILE { profile_name | DEFAULT | NULL }

<password expire> ::=
    PASSWORD EXPIRE

<account lock> ::=
    ACCOUNT { LOCK | UNLOCK }

<alter default tablespace> ::=
    DEFAULT TABLESPACE tablespace_name

<alter temporary tablespace> ::=
    TEMPORARY TABLESPACE tablespace_name

<alter index tablespace> ::=
    INDEX TABLESPACE { tablespace_name | NULL }

<alter schema path> ::=
    SCHEMA PATH ( { schema_name | CURRENT PATH } [, ...] )

구문 규칙과 파라미터는 다음과 같다.

• user_identifier

  • 변경할 사용자의 이름이다.

• <alter password>

  • 사용자의 password를 변경한다.

  • IDENTIFIED BY new_password

    • 새로운 password로 암호화되어 저장된다.

    • Password의 길이는 128 byte보다 작아야 한다.

    • Password는 대소문자를 구별한다.

  • REPLACE old_password

    • ALTER USER ON DATABASE 권한이 있을 경우에는 생략할 수 있다.

    • ALTER USER ON DATABASE 권한이 없을 경우에는 생략할 수 없다.

    • 사용자와 user_identifier가 동일해야 한다.

• <alter profile>

  • 비밀번호 관리 정책을 위한 profile을 변경한다.

  • PROFILE profile_name

    • 사용자가 생성한 profile_name을 할당한다.

  • PROFILE DEFAULT

    • 기본 profile "DEFAULT"를 할당한다.

  • PROFILE NULL

    • Profile을 할당하지 않는다.

• <password expire>

  • 사용자의 비밀번호를 만료시킨다.

• <account lock>

  • ACCOUNT LOCK

    • 사용자 계정을 잠근다.

  • ACCOUNT UNLOCK

    • 계정 잠금을 해제한다.

• <alter default tablespace>

  • 사용자의 기본 tablespace를 변경한다.

  • tablespace_name은 data tablespace이어야 한다.

• <alter temporary tablespace>

  • 사용자의 temporary tablespace를 변경한다.

  • tablespace_name은 temporary tablespace이어야 한다.

• <alter index tablespace>

  • 사용자의 index tablespace를 변경한다.

  • INDEX TABLESPACE tablespace_name을 지정한다.

    • Data tablespace을 지정할 경우, logging 인덱스가 된다.

    • Temporary tablespace를 지정할 경우, no-logging 인덱스가 된다.

  • INDEX TABLESPACE NULL

    • Index tablespace를 지정하지 않는다.

GOLDILOCKS 프로퍼티

GOLDILOCKS 프로퍼티는 데이터베이스를 생성할 때 적용되는 프로퍼티와 online/ offline 중에 변경할 수 있는 프로퍼티로 나뉜다. 테이블스페이스와 redo log file이 저장되는 경로는 startup 단계들 중에 MOUNT 단계에서만 변경할 수 있다.

데이터베이스 생성 시 적용되는 프로퍼티

데이터베이스 기동 시 적용되는 프로퍼티

GOLDILOCKS 데이터베이스에는 100 개 이상의 프로퍼티들이 존재한다. 그 중에서 자주 사용되는 프로퍼티는 다음과 같다.

GOLDILOCKS Utility

gcreatedb

gcreatedb 유틸리티는 GOLDILOCKS database를 초기화하고 서비스 할 준비 작업을 한다. gcreatedb는 data file, log file 등을 주어진 property에 따라 GOLDILOCKS_DATA 환경 변수의 위치에 생성한다. 구문은 다음과 같다.

[SHELL]> gcreatedb --help
Usage 

    gcreatedb [options]

Options:

    --cluster                 cluster system (if not specified, stand-alone system)
    --db_name                 database name
    --db_comment              database comment
    --timezone                timezone ( {+/-}{TZH:TZM} )
    --character_set           character set
                                SQL_ASCII
                                UTF8
                                UHC
                                GB18030
    --char_length_units       char length units
                                OCTETS
                                CHARACTERS
    --member                  local cluster member name
    --host                    cluster ip address or host name
    --port                    cluster port number
    --silent                  suppresses the display of the result message
    --help                    print help message

examples:

    gcreatedb --db_name="goldilocks" --db_comment="goldilocks database" --timezone="+09:00" --character_set="UTF8" --char_length_units="OCTETS" --silent

데이터베이스를 생성할 때 $GOLDILOCKS_HOME/conf/goldilocks.properties.conf를 참조하여 각각의 ***_TABLESPACE_SIZE 값으로 goldilocks.properties.conf의 SYSTEM_TABLESPACE_DIR 경로에 tablespace file들을 생성한다.

다음은 gcreatedb 명령어의 실행 인자에 대한 설명이다.

gsql (GOLDILOCKS interactive sql tool)

gsql은 GOLDILOCKS를 관리하기 위해 임의의 SQL을 실행시키는 interactive command line 유틸리티이다. DBA는 gsql을 이용해 초기 table schema를 생성하거나 현재 상태를 점검하는 등의 작업을 수행할 수 있다.

gsql 실행 방법은 다음과 같다.

[SHELL]> gsql <userid> <passwd>

gSQL> CREATE TABLE T1 ( COL1 INTEGER );

create success

gSQL> \q

[SHELL]>

gloader (GOLDILOCKS data upload/ download tool)

gloader는 기존의 database에 존재하는 데이터들을 text 형식으로 파일로 내리거나 기존에 text 파일로 저장된 데이터들을 새 database로 loading하는 유틸리티이다. gloader가 사용하는 text data file 형식은 Comma-Separated Value (CSV) 이다.

gloader 사용법은 다음과 같다.

gloader userid passwd [export|import] control='control_file_name' \
data='data_file_name' log='log_file_name' bad='bad_file_name'

다음은 control file 내용의 예이다.

TABLE  TEST_TBL
FIELDS TERMINATED BY ','
OPTIONALLY ENCLOSED BY '"'