[Tibero교육] Tibero Database Administration

Tibero Database Administration

 

Contents

1. 데이터베이스 유지관리

2. 사용자 관리

3. 오브젝트 관리

 

1. 데이터베이스 유지관리

 

• Tibero 구조

• Tibero 기동 환경

• tbSQL 유틸리티

• Tibero 기동 종료

• Parameter File

• Controlfile 관리

• Redo Log 관리

• Tablespace 와 Datafile 관리

 

Tibero 구조

Tibero 구조 - Process

 

 Tibero 프로세스 구조

 대규모 사용자 접속을 수용하는 다중 프로세스 및 다중 스레드 기반의 아키텍쳐 구조

- Listener, 워커프로세스 (Working Process 또는 Foregroud Process) , Background Process

 Listener

 클라이언트의 새로운 접속 요청을 받아 이를 유휴한 워커 프로세스에 할당

 클라이언트와 워커 프로세스간에 중계 역할을 담당하며, 별도의 실행 파일인 tblistener를 사용하여 작업

 모니터링 프로세스에 의해서 생성되며 외부에서 강제 종료하더라도 자동으로 재 시작 됨

 Listener Port

 클라이언트의 새로운 접속 요청이 이루어지는 순서

1) Client가 접속 요청

2) Listener는 현재 빈 WTHR이 있는 프로세스를 찾아서 이 사용자의 접속 요청을 CTHR에게 넘겨줌.

3) 요청을 받은 CTHR은 자기 자신의 WTHR 상태를 체크해서 일하지 않는 WTHR에게 할당

4) WTHR은 Client와 인증 절차를 걸쳐 세션 시작

 

 워커프로세스 (Worker Processes 또는 Foregroud Process)

 클라이언트와 실제 통신을 하며, 사용자 요구 사항을 처리 하는 프로세스

 Foregroud Worker Process는 리스너를 통해 들어온 온라인 요청 처리

 Backgroud Worker Process는 Internal Task나 Job Scheduler에 등록된 배치 작업을 수행

 

 CTHR (Control Thread)

- 각 Working Process마다 하나씩 생성. 서버 시작 시에 지정된 개수의 Worker Thread를 생성.

- 시그널 처리 담당.

- I/O Multiplexing을 지원하며, 필요한 경우 워커 스레드 대신 메시지 송/수신 역할 수행.

 

 WTHR (Worker Thread).

- 각 Worker Process마다 여러 개 생성.

- Client 가 보내는 메시지를 받아 처리하고 그 결과를 리턴.

- SQL Parsing, 최적화, 수행 등 DBMS가 해야 하는 대부분의 일 처리.

 

 Background Processes

 사용자의 요청을 직접 받아들이지는 않고, 워커스레드나 다른 배경 프로세스가 요청할 때, 혹은 정해진 주기에 따라 동작하며 주로 시간이 오래 걸리는 디스크 작업 담당

 독립된 프로세스로서, 사용자의 요청과 비동기적으로 동작.

 감시 프로세스(MONP: monitor process)

 매니저 프로세스(MGWP: manager worker process)

 에이전트 프로세스(AGNT : agent process)

 데이터베이스 쓰기 프로세스(DBWR : database writer)

 복구 프로세스(RCWP : recover worker process)

감시 프로세스(MONP: monitor process)

Tibero 기동 시 최초로 생성되는 종료 시에도 마지막에 종료

Tibero 기동 시, 리스너를 포함한 다른 프로세스를 생성, 주기적으로 각 프로세스 상태 점검

교착 상태 (Deadlock)도 검사

 

매니저 프로세스(MGWP)

시스템 관리 용도 프로세스

관리자의 접속 요청을 받아 이를 시스템 관리 용도로 예약된 워커 스레드에 접속을 할당

기본적으로 워커 프로세스와 동일한 역할을 수행하지만 리스너를 거치지 않고, 스페셜 포트를 통해 직접 접속

SYS 계정만 접속이 허용, LOCAL 에서만 접속 가능

 

에이전트 프로세스(AGNT : agent process)

시스템 유지를 위해 주기적으로 처리해야 하는 Tibero 내부의 작업을 담당

- Internal Task나 Batch Job이 언제 수행되어야 하는지 판단은 AGENT 프로세스가 담당 하지만, 실제 수행은 포어그라운드 혹은 백그라운드 워커 프로세스에게 의뢰하는 구조임

다중 스레드(multi-threaded) 기반 구조로 동작하며, 서로 다른 용도의 업무를 스레드별로 나누어 수행

 

데이터베이스 쓰기 프로세스(DBWR)

데이터베이스에서 변경된 내용을 디스크에 기록하는 일과 연관된 스레드들이 모여 있는 프로세스

사용자가 변경한 블록을 디스크에 주기적으로 기록하는 스레드

리두 로그를 디스크에 기록하는 스레드

두 스레드를 통해 데이터베이스의 체크포인트 과정을 관할하는 체크포인트 스레드

 

복구 프로세스(REWP)

복구 전용 프로세스

Crash / Instance Recovery 수행

 

Tibero 구조 - Memory

 

V$SGA : 공유메모리 정보 조회

V$PARAMETERS : 메모리 크기관련 파라미터 조회

V$SESSION : 각 세션별 PGA 메모리 사용량 조회

 

DB_CACHE_SIZE 파라미터 -> BUFFER CACHE 크기를 정의함

 

EX)

전체 메모리 크기는 변경하지 않고, BUFFER CACHE 크기만 증가하고자 함.

=> DB_CACHE_SIZE= 1G

=> TOTAL_SHM_SIZE = 1300M

vi $TB_HOME/config/tibero.tip

DB_CACHE_SIZE= 1G
TOTAL_SHM_SIZE = 1300M

tbdown immediate

tbboot

 

 Tibero Shared Memory (TSM)

 인스턴스에 대한 데이터와 제어 정보를 가지는 공유 메모리 영역

 사용자가 동시에 데이터를 공유

 Database Buffer, Redo Log Buffer, SQL Cache, Data Dictionary Cache 로 구성됨.

 Backgroud Process는 인스턴스가 시작될 때 TSM 영역을 할당하고, 인스턴스가 종료하면 할당 해제

 TSM의 전체 크기는 인스턴스가 시작될 때 생성되어 고정.

Tibero 기동 환경

 

Tibero 기동을 위해서는 OS 커널파라미터 및 환경변수 그리고 Tibero 바이너리, 데이터베이스 파일이 정상적으로 설정 및 설치 가 되어 있어야 함

Tibero 는 OS 환경변수를 참조하여 구동 되므로, 적절한 값이 설정되어 있어야 한다

환경변수	설명
TB_HOME	Tibero가 설치된 디렉터리이다. 예: /tibero/tibero6
TB_SID	Tibero 인스턴스 식별자이며, 파라미터 파일의 이름, 각종 로그 생성 경로 등에 영향을 준다. 예: tibero
LD_LIBRARY_PATH	Tibero를 사용할 때 필요한 공유 라이브러리가 위치한 경로이다. 필요한 라이브러리는 모두 $TB_HOME/lib와 $TB_HOME/client/lib 안에 있고, OS별로 환경변수 가 다르게 지정된다. SunOS, Linux : LD_LIBRARY_PATH HP-UX : SHLIB_PATH AIX : LIBPATH
PATH	Tibero 의 실행파일 디렉터리 경로이다. OS 기본 $PATH 에 $TB_HOME/bin 와 $TB_HOME/client/bin 을 추가하여 설정한다 예: /tibero/tibero6/bin , /tibero/tibero6/client/bin

Tibero 서버는 다음과 같은 디렉터리로 구성되며, 구동을 위해서는 Tibero 바이너리 파일이 정상적으로 설치되어 있어야 한다

디렉토리	설명
bin	실행 파일과 서버 관리를 위한 유틸리티가 위치한 디렉터리이다. 이 디렉터리에 속한 파일 중에서 tbsvr과 tblistener는 Tibero를 구성하는 실행 파일이며, tbboot와 tbdown은 각각 Tibero를 기동하고 종료하는 역할을 담당한다.
client	클라이언트 실행 파일이 있는 디렉터리이다. 이 디렉터리에는 다음과 같은 유틸리티가 있다.( tbSQL, T-Up, tbExport, tbImport, tbLoader, tbpc )
config	환경설정 파일이 위치하는 디렉터리이다. 이 위치에 존재하는 $TB_SID.tip 파일이 Tibero의 환경설정 을 결정한다
database	데이터베이스 저장 디렉터리 기본 경로 ( 데이터베이스 정보를 별도로 설정하지 않는 한 모든 데이터 베이스 정보가 이 디렉터리와 그 하위 디렉터리에 저장된다 )
instance	인스턴스 동작시 발생하는 각종 로그를 기록하는 디렉터리이다
lib	공간(Spatial) 쿼리와 관련된 함수를 사용하기 위한 라이브러리 파일이 있는 디렉터리이다
license	라이선스 파일(license.xml)이 있는 디렉터리이다. XML 형식이므로 일반 텍스트 편집기로도 라이선스의 내용을 확인할 수 있다.
nls	시간대 파일이 있는 디렉터리이다
scripts	데이터베이스를 생성할 때 사용하는 각종 SQL script 가 있는 디렉터리이다

 

Tibero 서버 기동을 위해서는 데이터베이스 파일이 정상적으로 생성되어 있어야 한다

 Datafiles

• Tables & Indexes 들과 같은 데이터 저장 객체를 물리적으로 저장하고 있는 파일.

 Redo Log Files

• 복구를 위하여 Database에서 변경된 모든 것을 기록 하는 파일.

 Control Files

• Database의 물리적 구조와 상태를 기록 하는 파일.

 

tbSQL 유틸리티

Tibero 관리를 위해서 사용하는 기본 도구로서 tbSQL 를 제공하고 있다. tbSQL은 TEXT 모드의 대화형 SQL 명령어 처리를 지원하는 유틸리티이다. SQL 질의, 데이터 정의어, 트랜잭션과 관련된 SQL 문장 등을 실행할 수 있다.

Tibero 기동 종료

 

tbboot

• tbboot는 Tibero가 설치된 머신에서 실행해야 한다.

• tbboot를 실행하기 전에 반드시 환경변수가 제대로 설정되어 있어야 한다.

• 이 명령어와 관련된 환경변수는 $TB_HOME과 $TB_SID이다.

• tbboot는 실행 파일을 실행할 수 있는 권한이 있는 사용자라면 어느 누구든 Tibero를 기동할 수 있으므로, Tibero를 설치한 사용자만 Tibero의 실행 파일에 접근할 수 있도록 권한을 설정할 것을 권장한다.

옵션	설명
	옵션이 없는 경우 Tibero를 부트 모드(bootmode) 중 NORMAL로 기동하는 옵션이다.
-h	tbboot를 사용하기 위한 간단한 도움말을 보여주는 옵션이다.
-v	Tibero의 버전 정보를 보여주는 옵션이다.
-C	Tibero에서 사용 가능한 character set 정보와 nls_date_lang 정보를 보여주는 옵션이다.
-c	Tibero가 replication mode로 설정되어 있을 경우 replication mode를 사용하지 않는 옵션이다.
-t	Tibero 서버를 기동할 수 있는 옵션이다. 이 옵션은 생략이 가능하다.

Tibero Instance 종료 과정

 

• Database Close

– TSM에 있는 모든 Database Data와 Recovery Data를 Data File과 Redo Log File에 각각 기록.

 

• Dismounting Database

– Control File을 Close.

 

• Instance Shutdown

– TSM에 있는 Memory가 제거되고, Process가 종료.

– Abnormal Shutdown이 되었을 경우 TSM에 Memory가 상주해 있거나 Process가 종료되지 않을 수가 있다. 따라서 남아 있는 이전 Instance를 제거하거나, tbdown abort 명령어를 이용하여 새로운 Instance를 강제로 종료 하고, tbdown clean.

 

 tbdown abort

 Tibero의 프로세스를 강제로 종료하는 모드.

 ABORT는 Tibero에 SYS 사용자로 접속한 다음 Tibero의 MTHR 프로세스가 모든 프로세스를 OS의 강제 종료 시그널을 전달하여 강제로 종료시키는 모드. 따라서 이 모드는 비상 시에 사용하며. 다음 번에 TiberoRDBMS를 기동할 때 파손 복구 과정이 필요.

 

 ABORT는 Tibero가 강제로 종료시키므로 사용하던 시스템 리소스를 해제할 기회 미존재. 따라서 서버가 종료된 다음에도 공유 메모리(Shared Memory), 세마포어(Semaphore) 등의 시스템 리소스가 남아있을 수 있으며, 로그 파일이나 데이터 파일도 동일.

 

 tbdown abort 이후에 Tibero 재 기동 시 파손복구에 많은 시간이 소요 가능성 존재.

 

 ABORT 는 다음과 같은 상황에서만 사용하도록 권장.

 tbdown clean

옵션	설명
clean	Tibero 서버가 비정상 종료된 상태에서 운영중에 사용하였던 공유 메모리나 세마포어 자원들을 해제하는 옵션. Tibero 서버가 운영 중일 때는 사용 할 수 없는 옵션.

 kill 명령으로 종료한 경우, tbdown clean 를 실행.

 만약 Tibero 서버가 Kill 과 같은 시스템 내부 명령어에 의해서 비정상적으로 종료된 경우, 운영 중에 사용하였던 공유 메모리나 세마포어 자원들이 해제가 안될 수 있다. 이런 경우 Tibero 가 정상적으로 재 기동 하지않게 되므로, tbdown clean 으로 기존 자원을 해제시킨 후 tbboot 를 실행.

 

--  CLEAN 대상 조회

3가지임(ipcs -a 조회되는 2가지(재활용 가능 -> 기동가능), .proc.list 파일(재활용 불가능 -> 기동불가능))

tbboot 시 할당 및 생성

 

 

. proc.list 는 tbdown시 읽는 파일이다. (다운 대상 정보가 있음)

tbdown pid 입력시 확인 가능

.proc.list 파일을 직접 지우던가 tbdown clean 하면 된다.

 

 tbdown POST_TX

 모든 트랜잭션이 끝날 때까지 기다리고 나서 Tibero를 종료하는 모드.

 

 POST_TX는 Tibero에 SYS 사용자로 접속한 다음 모든 트랜잭션이 끝날 때까지 기다림. 그 다음 Tibero RDBMS를 종료.

 

 tbdown 실행이 시작되면 더는 데이터베이스에 접속할 수 없고, 이미 열려 있던 세션에서도 새로운 트랜잭션을 시작할 수 없음. 다만, 현재 수행 중인 트랜잭션은 Commit 혹은 Rollback 할 때까지 제한 없이 수행할 수 있으며, Commit이나 Rollback을 하는 순간 자동으로 데이터베이스 접속을 종료.

 

 tbdown 실행이 시작되면 데이터베이스에 접속한 클라이언트에게 서버 종료를 알리는 메시지를 보내지 않음

 

 tbSQL 유틸리티 등에서는 클라이언트가 서버 종료를 즉시 알지 못하고, 그 다음 명령을 실행할 때 비로소 Tibero RDBMS가 종료되었음을 알리도 됨

 

 tbdown IMMEDIATE

 현재 수행 중인 모든 작업을 강제로 중단시키며, 진행 중인 모든 트랜잭션을 롤백하고 Tibero를 종료하는 모드.

 

 IMMEDIATE는 Tibero에 SYS 사용자로 접속한 다음 현재 수행 중인 모든 작업을 강제로 종료하고, 진행 중이던 모든 트랜잭션을 롤백한 후, Tibero를 종료. 클라이언트에서 Tibero 종료를 알지 못하는 것은 POST_TX 모드와 동일.

 

 트랜잭션이 오래 걸리는 작업 중에 있었다면, 이를 모두 롤백하기 위해서 다소 시간이 걸림.

 

 사용 예

 

Parameter File

Controlfile 관리

 

 Control Files

 Control File은 작은 Binary File로 Database의 구조.

 모든 Database Files & log files들은 Control file에서 식별 가능.

 Database name은 Control file에 저장.

 Control File은 Mount, Open시에 필요.

 Recovery시 필요한 동기화된 정보를 저장.

 최소 다른 Disk상에 2개 이상의 Control Files를 가지도록 권장.

 Control File은 Database가 Open되어 졌을 때 반드시 Tibero Server가 Writing 가능하도록 설정.

 

 Control File 생성 지침

 

 제어 파일 이름 지정

– Parameter file의 CONTROL_FILES에서 지정

– CONTROL_FILES는 쉼표로 구분된 하나이상의 파일 이름 명시.

– 지정된 모든 파일에 데이터베이스 작업 내용이 기록.

 

 서로 다른 디스크 상의 제어 파일 다중화

– 모든 Tibero 데이터베이스는 최소한 두 개의 제어 파일을 보유.

– 데이터베이스 작업 중 Tibero 서버는 CONTROL_FILES 변수에 나열된 첫 번째 파일만 Read.

– 데이타베이스 작업 중 사용할 수 없는 제어 파일이 생기면 인스턴스는 더 이상 작동할 수 없으며 중지.

 

 제어 파일의 올바른 배치

– 제어 파일의 각 복사본을 각기 다른 디스크상에 저장.

– 온라인 로그 파일의 멤버와 같은 디스크에 두어서 디스크 손실 시 위험을 최소화

 

 제어 파일의 크기

– 제어 파일 크기는 CREATE DATABASE문에서 지정한 MAXDATAFILES, MAXLOGFILES,MAXLOGMEMBERS,MAXLOGHISTORY및 MAXINSTANCE의 설정 값과 운영체제마다 상이.

 

 제어 파일(Control File) 관리

 제어 파일은 데이터베이스 자체에 대한 메타 데이터를 보관하고 있는 바이너리 파일

 제어 파일은 Tibero 시스템에 의해서만 생성 및 갱신 가능

 제어 파일에 포함된 내용

정보	설명
데이터베이스	데이터베이스 이름, $TB_SID.tip 파일의 이름 또는 생성되었거나 변경된 타임스탬프 등이 존재.
테이블스페이스	테이블스페이스를 구성하는 데이터 파일 또는 생성되었거나 변경된 타임스탬프 등이 존재
데이터 파일	데이터 파일의 이름과 위치 또는 생성되었거나 변경된 타임스탬프 등이 존재.
Redo 로그	로그 그룹의 개수 및 이를 구성하는 로그 멤버(로그 파일)의 이름과 위치 또는 생성되었거나 변경된 타임스탬프 등이 존재.
체크포인트	최근 체크포인트를 수행한 타임스탬프 등이 존재.

 컨트롤 파일에 대한 정보

 Tibero에서는 여러가지 시스템 뷰를 정의하여 컨트롤 파일의 관리

뷰	설명
V$DATABASE	ARCHIVELOG 모드인지 여부, 체크포인트 등의 정보
V$CONTROLFILE	컨트롤 파일의 상태 및 파일이름 정보

Redo Log 관리

 

 리두 로그 파일 (Redo Log File)의 관리

 리두 로그 버퍼에 기록된 내용을 디스크에 기록하는 데이터베이스 구성 요소.

 리두 로그 버퍼엔 데이터베이스 장애시 복구를 수행하기 위해 모든 변경내역을 기록.

 

 리두 로그 파일의 구성 요소

▪ 리두 로그 멤버 (Redo Log Member)

▪ 리두 로그 그룹 (Redo Log Group)

 리두 로그 파일의 관리

 

 로그 그룹 추가

SQL> ALTER DATABASE ADD LOGFILE GROUP 3
('/home/tibero6/tbdata/redo31.log', '/home/tibero6/tbdata/redo32.log') SIZE 512K;

 로그 그룹 삭제

SQL> ALTER DATABASE DROP LOGFILE GROUP 3 ;

 로그 멤버 추가

SQL> ALTER DATABASE ADD LOGFILE MEMBER '/home/tibero6/tbdata/redo33.log' TO GROUP 1;

 로그 멤버 삭제

SQL> ALTER DATABASE DROP LOGFILE MEMBER '/home/tibero6/tbdata/redo33.log';

 리두 로그 파일 정보 조회

 Tibero는 리두 로그의 관리를 위해 Redo 로그에 대한 정보를 제공하는 여러가지 뷰를 정의

뷰	설명
V$LOG	로그 그룹에 대한 정보
V$LOGFILE	로그 파일에 대한 정보

 복구를 위해 사용되며, 데이터베이스 변경이 발생하면 변경내용이 기록됨

 리두 로그 파일들은 순환하며 Write

 리두 로그 그룹은 적어도 2개 이상

 만약 Database운영 Mode가 ARCHIVELOG Mode일 경우 Log Switch가 일어날 때 log_archive_dest로 Copy되어져 향후 복구 시 사용됨

 ( 인스턴스 복구시 ) 온라인 리두로그의 내용을 이용하여 아직 데이터 파일에 기록되지 않은 커밋된 데이터를 복구함

 리두로그 버퍼의 내용(커밋되지 않은 트랜잭션, 커밋된 트랜잭션, 언두 데이터, 스키마 객체 관리를 위해 사용 한 쿼리 문 등) 이 기록됨.

 Redo log File을 구성하는데 1 Group에 2개 이상의 Member를 동일 Machine상에서 다른 Disk에 분리하여 구성하기 권장.

 Multiplexed Redo Log Files는 특정 그룹에서 하나의 파일을 손실 시에 특이 사항 없음.

 그룹의 모든 Member들은 동일한 정보와 Size 를 갖음

 아카이브 리두 로그 파일은 온라인 리두로그 그룹 맴버의 복사본임

 아카이브 리두 로그 파일은 데이터베이스 파일에 속하지는 않지만 복구르 위해 사용되는 중요한 파일임

 아카이브 리두 로그의 용도

- 데이터베이스 백업 복구

- TSC( Tibero Standby Cluster) 의 Standby DB 의 데이터 업데이트

- Tmax 의 데이터복제 솔루션인 ProSync 에서 사용

 

Tablespace 와 Datafile 관리

 

 테이블스페이스(Tablespace)

 개요

- 하나 이상의 논리적 저장 영역으로 구성되어 있으며 Tibero의 모든 데이터를 저장

- 각 테이블스페이스는 물리적인 저장 영역인 데이터파일이라는 하나 이상의 파일로 구성되며, 이 데이터 파일은 운영체제의 물리적인 저장영역

 

 TABLESPACE 관리 지침

– Using Multiple Tablespaces

• Data Dictionary Data 와 유저 Data의 분리

• 어플리케이션별 분리

• I/O 경합을 줄이기 위하여 데이터 파일의 분산(디스크)

• 유저 Data 와 Rollback Segment의 분리

• 개별 테이블스페이스를 오프라인 할 수 있도록 할 것.

• 업데이트가 많은것, 읽기 전용, 임시용 등 특별한 형태별 지정

• 개별 테이블스페이스의 백업 고려

 

 테이블스페이스(Tablespace) 개요

 테이블스페이스 유형

구성요소	설명
SYSTEM TABLESPACE	데이터베이스 작업을 위해 항상 있어야 함. (항상 ON-LINE 상태 유지) 포함 내용 - 데이터 딕셔너리 정보와 저장 프로시저, 패키지, 그리고 데이터베이스 트리거의 정의. SYSTEM 롤백 세그먼트를 포함. 주의 : 사용자 데이터를 포함 할 수 있지만 그렇지 않도록 할 것.
NON SYSTEM TABLESPACE	응용프로그램 데이터/인덱스, 임시 세그먼트, 롤백 세그먼트

 테이블스페이스 영역 관리 방법

▪ Locally Managed Tablespace 방식

구성요소	설명
EXTENT_MANAGEMENT_LOCAL	EXTENT_MANAGEMENT_LOCAL의 뒷 부분에 테이블스페이스의 익스텐트가 어떻게 관리될 것인지를 명시.
AUTOALLOCAT	익스텐트의 크기를 시스템이 자동으로 설정.
UNIFORM	익스텐트의 크기를 사용자가 설정한다. 사용자가 설정한 크기대로 익스텐트가 항상 일정한 크기로 생성.
size	익스텐트의 크기를 명시, 기본값은 16이며, 8~8388608까지 명시 가능.

 

 테이블스페이스 관리

 테이블스페이스 생성

▪ System Tablespace는 데이터베이스가 생성될 때 생성

▪ Non System Tablespace 생성하기 (일반 유저가 사용하는 Tablespace)

SQL> CREATE TABLESPACE my_space
DATAFILE '/home/tibero6/tbdata/my_file001.dtf' SIZE 50M
AUTOEXTEND ON NEXT 10M MAXSIZE 3G
EXTENT MANAGEMENT LOCAL
UNIFORM SIZE 256K;

 테이블스페이스 크기 변경

▪ 테이블스페이스의 크기는 물리적인 데이터파일의 크기 변경과 데이터파일 추가로 변경 가능

▪ 데이터파일의 크기 변경

SQL> ALTER DATABASE DATAFILE 'my_file001.dtf' RESIZE 100M;

▪ 데이터파일 추가

SQL> ALTER TABLESPACE my_space ADD DATAFILE 'my_file002.dtf' SIZE 20M;

 테이블스페이스 삭제

▪ 테이블스페이스를 구성하는 데이터 파일을 함께 제거시 INCLUDING 절을 삽입

SQL> DROP TABLESPACE my_space INCLUDING CONTENTS AND DATAFILES;

 테이블스페이스 관리

 테이블스페이스 가용성 변경

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

 

▪ 예제) 테이블스페이스를 오프라인 상태로 만들고 미디어복구 수행 후 온라인으로 변경.

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

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

모드	설명
NORMAL	체크포인트를 수행한 후 테이블스페이스 오프라인을 수행. 향후 테이블스페이스 온라인을 수 행할 때 미디어 복구 불필요.
IMMEDIATE	체크포인트를 수행하지 않고 테이블스페이스 오프라인을 수행. 향후 테이블스페이스 온라인 을 수행할 때 미디어 복구가 필요. 따라서 ARCHIVELOG 모드에서만 가능.

 테이블스페이스 Read-Only

 Making a Tablespace Read-Only

– 테이블스페이스를 읽기 전용으로 만들면 파일의 쓰기 작업 방지.

– ALTER TABLESPACE의 SYSTEM 권한 필요.

– 필요조건

• 테이블 스페이스는 ONLINE 상태

• SYSTEM 테이블스페이스는 지정 불가

• 테이블스페이스에 활성 롤백 세그먼트가 없어야 함.

• 테이블스페이스가 현재 온라인 백업이 없어야 함.

– Making a Read-Only Tablespace Writeable

 ALTER TABLESPACE tablespace명 READ WRITE;

• 모든 데이터파일의 상태가 ONLINE,

• dba_tablespaces 를 조회하면 데이터파일의 상태 조회 가능.

 

 Dropping Tablespace

DROP TABLESPACE tablespace명 INCLUDING CONTENTS;

– 테이블스페이스가 비어 있으면 INCLUDING CONTENTS는 필요 없음

– CASCADE CONSTRAINTS는 하위 테이블의 FOREIGN KEY는 단계적으로 삭제됨.

 

 테이블스페이스 정보 조회

 Tibero에서는 테이블스페이스에 대한 관리를 용이하게 하기 위하여, 여러가지 뷰를 정의하여 테이블스페이스에 대한 정보를 제공

뷰	설명
DBA_TABLESPACES	티베로내의 모든 테이블스페이스에 대한 정보
USER_TABLESPACES	현재 유저에 속한 테이블스페이스에 대한 정보
V$TABLESPACE	티베로내의 모든 테이블스페이스에 대한 간략한 정보

테이블스페이스

- 테이블스페이스는 세그먼트를 저장하는 논리 저장소, 한개 이상의 데이터 파일이나 임시파일을 사용하여 데이터를 저장함

Tablespace	포함하고 있는 데이터
SYSTEM	- 데이터베이스 관리 정보를 포함한 테이블, 뷰( 데이터 사전 ) - 프로시저, 패키지, 트리거 등 컴파일된 오브젝트
UNDO	- 언두 데이터( 언두 세그먼트 )
SYSSUB	- TPR 의 스냅샷 데이터
USR	- TIBERO, TIBERO1 유저의 default tablespace
TEMP	- 정렬 작업용 데이터, 세션의 유지 기간만 저장되는 임시 데이터

세그먼트 공간관리 와 HWM(High Water Mark)

- 자동 세그먼트 공간 관리 방식으로써 BITMAP 을 이용하여 공간을 관리함

- PCTFREE 파라미터를 이용하여 블록 속성 설정 ( 다른 파라미터는 허용은 되나 무시됨)

- 데이터 입력시 블록그룹을 할당하며 세그먼트 헤더블록의 비트맵에 블록 정보를 기록합니다.

- 데이터 입력시 LOW HWM 하위의 여유공간이 있는 블록에 쓰거나, LOW HWM 과 HWM 사이의 블록을 사용함

- FULL SCAN 시에 LOW HWM 하위의 모든 블록과 LOW HWM 과 HWM 사이의 경우는 세그먼트 헤더블록의 BIT MAP 정보를 이용하여 액세스 함

 

세그먼트 생성

- 테이블, 인덱스 객체 생성시 세그먼트가 할당됩니다.

- 파티션 되어 있는 객체는 파티션마다 세그먼트가 할당됩니다.

UNDO 테이블스페이스

트랜잭션은 하나의 언두 세그먼트를 할당받음

한개의 언두 세그먼트에 여러 트랜잭션이 할당 될 수 있음

UNDO Segment 는 UNDO Tablespace 에 저장

UNDO 자동 관리

• 언두 테이블스페이스에서 언두 데이터 저정하며, 공간을 자동으로 관리함

• 공간 필요시 자동으로 언두 세그먼트에 익스텐트 추가 할당됨

• 읽기 일관성 보장을 위해 UNDO_RETENTION 시간 동안 언두데이터 유지

 

UNDO_RETENTION

• COMMIT 언두 데이터의 보존하는 기간을 설정하는 파라미터(단위: 초)

• 기본값 900초(15분) 으로, 해당 언두 익스텐트의 데이터 보장

• UNDO_RETENTION 기간이 지난 익스텐트는 진행 중인 트랜잭션을 위해 재할당 될 수 있음 RETENTION 기간 이내 인 경우 익스텐트는 재활용 될 수 없음

 

UNDO EXTENT 의 상태

• Active, Unexpired, Expired

 

UNDO TABLESPACE 에서 가용한 UNDO Extents 가 있을 경우, DML 쿼리 수행 정상 동작.

SELECT 문장이 UNDO_RETENTION 이하의 수행시간일때 정상 동작을 보장(기본값 900 Seconds (15Min.))

 

 UNDO_RETENTION 측정시점

- COMMIT 시점 이후부터 측정함

 UNDO Tablespace 크기 증가

- 기존 Expired 상태의 UNDO Extent 를 소모하고, 추가적으로 Active 상태의 UNDO Extent 가 많아지는 경우임

 

Tibero Database 파일 저장 방식

 

 RAW 장치

• Raw Device 는 파일시스템으로 포맷되어 있지 않은 디스크 파티션 혹은 논리 볼륨으로, 파일시스템과 달리 캐시를 거치지 않고 직접 I/O 를 수행할 수 있음

• Tibero TAC 환경에서 TAS 를 기반으로 데이터베이스를 생성하여 운영할 수 있음

 

 운영체제의 파일 시스템

• 일반적으로 파일시스템은 논리볼륨관리자(LVM) 에 의해 생성된 논리볼륨을 기반으로 구축되어 있고, LVM 은 서로 다른 물리적 디스크 영역을 하나의 연속된 주소 공간으로 결합하여 제공함

 

 Tibero Active Storage (TAS)

• Tibero Database 에서 사용하는 전용 파일시스템

• Tibero TAC 환경에서 TAS 를 기반으로 데이터베이스를 생성하여 운영할 수 있음

 

 클러스터 파일 시스템

• 클러스터 파일 시스템은 여러 컴퓨터에서 파일의 저장소를 공유 하는 기능을 제공함

• Tibero TAC 환경에서 클러스터 파일시스템을 기반으로 데이터베이스를 생성하여 운영할 수 있음

 

Datafiles

 Tibero Database 는 데이터 파일 이라는 구조에 데이터베이스 데이터를 저장합니다.

 Tablespace는 하나이상의 물리적인 datafile을 가지며, 하나의 datafile은 오직 하나의 Tablespace에 포함

세그먼트는 하나 이상의 데이터 파일에 걸쳐 있을 수 있지만, 여러 테이블스페이스에 걸쳐져 있는 것은 아님

 

 Datafile 관리 지침

 

 DATAFILE

– Tablespace는 하나 이상의 물리적인 datafile을 가지며, 하나의 datafile은 오직 하나의 Tablespace에 포함.

 

 DATAFILE 관리 지침

– 사용자는 datafile 을 추가할 수 있으며 다음 제한을 갖음.

• Operating system limit

• Tibero system limit

• Control file upper bound : MAXDATAFILES

– Set the Size of Datafiles

• 데이터 딕셔너리를 저장하기 위한 SYSTEM 테이블스페이스 datafile은 최소한 2M 이상을 지정.

– Store Datafiles Separately From Redo Log Files

• 데이터 파일과 리두 로그 파일의 디스크를 분리하여 지정.

 

 Tablespace에 Datafile 작성 및 추가

 

 Creating and Adding Datafiles to a Tablespace

– CREATE TABLESPACE 문에서 데이터 파일을 생성

– 생성된 테이블스페이스에 데이타 파일을 추가

ALTER TABLESPACE rb_segs 
ADD DATAFILE ‘filename.dtf’ SIZE 10M;

 Changing a Datafile’s Size

– Enabling and Disabling Automatic Extension for a Datafile

• CREATE DATABASE, CREATE TABLESPACE, ALTER TABLESPACE 명령으로 크기를 자동으로 증가할 수 있는 데이터 파 일 생성 가능.

ALTER TABLESPACE users
ADD DATAFILE ‘filename2.dtf’ size 10M
AUTOEXTEND ON
NEXT 512 K
MAXSIZE 250M;

ALTER DATABASE DATAFILE ‘filename2.dtf’ AUTOEXTEND OFF;

ALTER DATABASE DATAFILE ‘filename2.dtf’ RESIZE 100M;

 DATAFILE 가용성 변경

 Altering Datafile Availability

 

– Bringing Datafiles Online in ARCHIVELOG Mode

ALTER DATABASE DATAFILE ‘filename’ ONLINE;

– Taking Datafiles Offline in NORACHIVELOG Mode

ALTER DATABASE DATAFILE ‘filename’ OFFLINE DROP;

 

DATAFILE 정보 조회

뷰	설명
DBA_EXTENTS	테이블 스페이스 내에 포함된 Segment의 Extent 조회
DBA_SEGMENTS	테이블 스페이스 내에 포함된 Segment 조회
DBA_FREE_SPACE	테이블 스페이스 내에 사용 가능한 Extents의 정보 조회
DBA_TABLESPACE	테이블 스페이스 조회
DBA_DATA_FILES	Datafile에 대한 정보 조회
DBA_EXTENTS	테이블 스페이스 내에 포함된 Segment의 Extent 조회
V$DATAFILE	데이터 베이스 내에 Datafile에 대한 정보

 DATAFILE 이름 변경 및 위치 재지정

 

 데이터파일 이름 변경 및 위치 재지정

– Renaming and Relocating Datafiles for a Single Tablespace

• Datafiles 이 오프라인 된 non-SYSTEM 테이블스페이스 선택

• Datafiles 복사 혹은 이름 변경

• ALTER TABLESPACE 명령으로 Datafiles 이름 변경

ALTER TABLESPACE users 
RENAME DATAFILE ‘filename1’, ‘filename2’ TO ‘filename3’, ‘filename4’;

• 테이블스페이스를 온라인으로 전환

• OLD 와 NEW Datafiles이 존재 해야 함.

또한 

ALTER DATABASE BACKUP CONTROLFILE TO ‘filename’

으로 컨트롤 파일을 백업 필요.

 

 Renaming and Relocating Datafiles for a Multiple Tablespace

– 한 개 이상의 테이블스페이스의 datafile 혹은 SYSTEM 테이블스페이스의 datafile을 이름변경 혹은 위치변경.

– 데이터 베이스를 마운트 상태로 기동 (OPEN 상태가 아님)

– datafile을 새로운 위치로 복사

– ALTER DATABASE RENAME 명령을 사용하여 이름 변경

ALTER DATABASE
RENAME FILE ‘filename1’, ‘filename2’ TO ‘filename3’, ‘filename4’;

일반 테이블스페이스의 영속적인 데이터 파일

테이블, 인덱스와 같은 영구적인 스키마 객체가 포함되며, 데이터 파일에 저장 관리됨

 

임시 테이블스페이스의 임시파일(Tempfile)

세션의 또는 트랜잭션 지속 시간 동안 임시 테이블과 같은 스키마 객체의 데이터가 존재하며, 메모리에서의 해시 및 정렬 등의 작업 메모리 공간이 부족했을때의 저장소로 사용됨

일반테이블의 영구적인 데이터는 임시파일에 저장되지 않음

임시파일을 사용하는 스키마 오브젝트는 NOLOGGING 모드로 설정되며, 미디어 복구가 않됨

임시 파일은 DBA_TEMP_FILES, V$TEMPFILE 에서 모니터링 할수 있고, 일반 데이터 파일을 조회하는 DBA_DATA_FILES, V$DATAFILE 뷰에서는 표시되지 않음

 

온라인 데이터 파일 및 오프라인 데이터 파일

모든 데이터 파일은 온라인 (사용 가능) 또는 오프라인 (사용 불가능) 상태에 해당됨

 MOUNT 모드에서 데이터파일을 오프라인 변경후, 테이블스페이스를 삭제할 수 있음

테이블스페이스를 오프라인 변경하면 연결된 데이터파일 또한 오프라인 상태가 됨

데이터파일의 이름/경로를 바꾸기 위해서는 해당 테이블 스페이스를 오프라인 상태로 설정후 변경가능

 

데이터 파일의 구조

2. 사용자 관리

 

 사용자 관리

− Tibero가 설치되면 아래와 같은 사용자 계정이 자동으로 생성됨

− 데이터베이스 관리자는 기본 계정 이외에 업무에 필요한 사용자 계정을 추가 생성하고, 관리하여야 함

계정	설명
SYS	데이터베이스 관리를 위한 계정으로서 시스템 패키지, 동의어, 사용자, 역할, 가상 테이블, 시퀀스, 동적 뷰 등을 생성하고 관리한다.
SYSCAT	데이터베이스 관리를 위한 정적 카탈로그 뷰를 생성하고 관리하는 계정이다.
OUTLN	동일한 SQL을 수행할 때 항상 같은 질의 플랜(plan)으로 수행될 수 있게 관련 힌트(hint)를 저장하는 등의 일을 하는 계정이다.
SYSGIS	GIS(Geographic Information System)와 관련된 테이블 생성 및 관리를 하는 계정이다.
TIBERO	CONNECT, RESOURCE, DBA 역할이 부여된 샘플 사용자 계정이다.
TIBERO1	CONNECT, RESOURCE, DBA 역할이 부여된 샘플 사용자 계정이다.

 사용자 계정

− Tibero 내부의 데이터에 접근하기 위해서는 사용자 계정(Account)이 필요하다.

− 각 계정은 패스워드(Password)를 통해 보안이 유지된다

▪ 패스워드는 사용자 계정을 생성할 때 설정됨

▪ 사용자 계정이 생성된 이후에 변경할 수 있음

▪ 패스워드는 데이터 사전(Data Dictionary)에 암호화된 형태로 저장됨

− 하나의 사용자 계정은 하나의 스키마를 가지며 스키마의 이름은 사용자의 이름과 같다.

( ** 스키마(Schema) : 테이블, 뷰, 인덱스 등의 스키마 객체(Schema object)의 묶음 )