Tibero Architecture_2. 데이터베이스 저장구조

jisu park·2023년 8월 31일

Tibero

목록 보기

2/2

티베로의 데이터베이스 저장구조는 크게 물리저장구조, 논리저장구조로 나누어 볼 수 있다.
논리저장구조에는 database, tablespace, segment,extent 등이 있으며,
물리 저장구조에는 control file, password file, datafile, tempfile, redolog file, archived redolog file, backup set 가 있다.
논리저장구조는 DBMS에 스키마 객체를 저장하는 구조, 물리저장구조는 OS에 저장하는 구조라고 생각하면 구별하기가 쉬울 것이다.

질문 ! >>>>>>>>>>>>>>
1.~~백업저장소는 리눅스 시스템 상에서 어떻게 확인할 수 있는지?~~
[-> 백업저장소가 따로 있는게 아니라 백업파일을 만들어 놓은 곳이 저장소가 됨. 어디에다 만들지는 자신이 결정할 수 있다. 백업을 하기 위해서는 tibero 서버에 접속하여 일련의 과정을 거쳐 세팅을 해준 후, 백업 저장소로 정한 경로로 데이터 파일을 cp하면됨.]
2.데이터블록은 물리저장구조인지, 논리저장구조인지?
[datablock은 논리저장구조이다. os에서 block을 모아서 DB에서 사용하는 block size로 변환시켜 사용. 주로 datablock 사이즈는 default로 8K. OS에 사용하는 block은 filesystem의 format type에 따라 default 값이 달라짐.]

물리 저장구조

<출처 : Tibero 6 온라인 매뉴얼_Tibero 관리자 안내서_3.2. 테이블 스페이스>

control file

데이터베이스 자체의 meta data를 보관하고 있는 바이너리 파일
최초의 컨트롤 파일은 Tibero 설치 시 생성되고, 이에 대한 정보는 $TB_SID.tip 파일에 저장된다.
```
#-----$TB_SID.tip------#

DB_NAME=six
LISTENER_PORT=8629

CONTROL_FILES="/home/tibero1/tibero6/database/sixth/c1.ctl"

MAX_SESSION_COUNT=20

TOTAL_SHM_SIZE=1G
MEMORY_TARGET=2G
```
CONTROL_FILES의 경로로 가면 실제로 해당 컨트롤 파일이 있는 것을 확인할 수 있다.
control file은 Tibero 서버 mount, open시에 필요하다.
Tibero에서는 데이터베이스를 다시 기동할 때마다 먼저 컨트롤 파일을 참조하는데, 컨트롤 파일 내에는 아래와 같은 내용이 담겨져 있다.
database : 데이터베이스 이름, $TB_SID.tip파일 이름, 타임스탬프
table space: 테이블 스페이스를 구성하는 datafile, 타임스탬프
datafile: datafile의 이름, 위치, 타임스탬프
redo log: 로그그룹의 개수, 로그 멤버(로그파일)의 이름, 위치, 타임스탬프
checkpoint: 타임스탬프
Tibero에 의해서만 생성과 갱신을 할 수 있으며 DBA가 컨트롤 파일의 내용을 조회하거나 갱신할 수는 없다.
redolog와 같이 최소 다른 disk상에 2개 이상의 control files를 가지도록 권장한다. _[아래그림 참고]

출처 : Tibero 6 Online Manual
Tibero에서는 컨트롤 파일로부터 정보를 확인할 때 여러 복사본 중에서 하나만 읽는다. 그리고 테이블 스페이스의 변경 등의 이유로 컨트롤 파일을 갱신해야 하는 경우에는 모든 복사본을 동시에 갱신한다. 디스크 에러 등의 원인으로 일부 컨트롤 파일에 장애가 발생했을 경우에도 하나 이상의 컨트롤 파일이 정상이면 Tibero는 문제없이 운영된다.

password file

sys사용자의 password를 암호화한 값을 저장한 파일
mount 모드로 tibero 기동시 .passwd 파일을 참고하여 사용자가 패스워드를 제대로 입력했는지 확인한다. (normal모드에서는 data dictionary 사용...)

datafile

데이터파일의 구조
Tables & Indexes 들과 같은 Logical structure들이 물리적으로 Datafiles에 저장된다.

하나의 datafile이 여러개의 tablespace에 걸쳐 있을 수 없음.
하나의 table이 여러개의 datafile에 걸쳐 있을 수는 있음.
데이터파일의 이름, 경로 변경시에는 해당 테이블 스페이스를 오프라인으로 설정 후 변경가능하다.
$ TB_HOME/database/데이터베이스명의 경로에서 datafile 확인가능하다.

[tibero1@:sixth:/home/tibero1/tibero6/database/six]ls
java  redo001.redo  redo011.redo  redo021.redo  syssub001.dtf  system001.dtf  temp001.dtf  undo001.dtf  usr001.dtf

tempfile

일반 datafile에 저장되는 데이터는 영구적이며, 데이터베이스의 내용이 디스크에 유지될 때 사용되는데 반해, tempfile 에는 저장되는 데이터는 일시적이며, 특정 쿼리 또는 작업이 완료되면 해당 데이터는 삭제된다.
주로 정렬, 조인, 그룹화 등과 같은 연산을 수행할 때 사용되는 임시 작업 공간을 마련하는데 쓰인다.
임시 작업 결과를 저장하고 처리 속도를 높이기 위해 사용됩니다.
DBA_TEMP_FILES, V$TEMPFILE에서 모니터링 할 수 있음.

redolog file

데이터베이스에서 변경이 발생하면 변경내용이 기록된다.
redolog에 있는 내용

데이터 변경 내용, TSN와 타임스탬프, transaction ID, transaction이 커밋될 때의 TSN과 타임스탬프, 변경을 수행한 작업 유형, 변경된 데이터 세그먼트 이름 및 유형
redo는 사람이 알아볼 수 없는 binary형식의 파일
로그 전환(log switch)
리두로그를 순환하며 변경사항들을 write한다. 하나의 그룹이 다 차면 그 다음 그룹으로 옮겨가 쓰기 시작하는데, 이를 log switch라고 한다.
Archivelog Mode일 경우, Log Switch가 일어날 때마다 log_archive_dest에 카피되어 향후 복구에 사용된다.
로그 파일 다중화 (log multiplexing)
로그 파일이 들어있는 disk가 손상될 경우를 대비하여 여러개의 disk에 동일한 redolog 파일을 위치시키는 것.

출처 : Tibero 6 Online Manual
다중화를 하려면 동일한 그룹에 속해 있는 모든 로그 멤버의 크기는 일정해야 하며, 동일한 데이터를 저장하고 동시에 갱신되어야 한다.
동시에 하나의 로그 그룹만을 사용하는 데 현재 사용 중인 로그 그룹을 활성화(active)된 로그 그룹이라고 함
_LOG_WRITE_SYSCALL=1 파라미터와 관련

archive file

archive mode에서 logswitch가 일어날때 온라인 리두로그멤버 파일이 복사되어 archive redo log file로 저장된다.
아카이브 리두 로그의 용도
데이터베이스 백업 복구
TSC( Tibero Standby Cluster) 의 Standby DB 의 데이터 업데이트
Tmax 의 데이터복제 솔루션인 ProSync 에서 사용

Tibero Database 파일 저장 방식

Tibero Active Cluster(TAS)
Tibero Database에서 사용하는 전용 파일시스템
Tibero TAC 환경에서 TAS를 기반으로 데이터베이스를 생성하여 운영할 수 있음
Oracle의 ASM과 비슷
운영체제의 파일 시스템
주로 쓰는 파일 저장 방식
LVM에 의해 생성된 논리볼륨을 기반으로 구축되어 있음.
RAW 장치
Raw Device는 디스크 파티션 혹은 논리볼륨이다.
파일시스템과 달리 cache를 거치지 않고 직접 I/O를 수행할 수 있음.
but, 생성과 관리가 어려워 주로 Tibero TAC 구조에서 쓰임. (비용적인 면에서 장점이 있다)
클러스터 파일 시스템
여러 컴퓨터에서 파일의 저장소를 공유하는 기능을 제공한다.
Tibero TAC 환경에서 쓰일 수 있음.

논리 저장구조

논리 저장 구조는 DATA BLOCK > EXTENT> SEGMENT> TABLESPCACE 의 위계질서로 이루어져 있다.
물리 저장 구조와 헷갈릴 수 있는데, 아래 자료를 보면 이해가 쉽다.

DATA BLOCK

데이터 파일에 할당되는 물리적 파일 블럭으로, Data가 저장되는 최소의 구조 단위이다. (데이터베이스 I/O의 단위)
여러개의 OS block이 모여 Data block을 형성
2k, 4k, 8k, 16k, 32k 로 DB에서 선택가능함.

EXTENT

연속된 databaseblock의 집합
하나의 extent는 여러 데이터파일에 걸쳐서 존재할 수 없음.

SEGMENT

테이블, 인덱스 객체 생성시 segment가 할당됨
세그먼트 타입에는 TABLE, INDEX, LOB 등 이 있음
UNDO 세그먼트
트랜잭션 기록을 보관하는 세그먼트, 트랜잭션 롤백/복구 등에 사용된다.
transaction은 하나의 UNDO 세그먼트를 할당받음.
한개의 UNDO 세그먼트에 여러 transaction이 할당될 수 있음

물리적 구조로 보자면, DML을 수행하면 DB_CACHE와 LOG_BUFFER에 해당 UNDO segment가 적재되고 각각 Datafile과 Redo logfile에 저장된다
질문------> DML 수행시 현재의 block 정보는 undo에 기록하고,
답변)
DML을 수행하면 현재의 block 정보는 undo에 기록하고 수행할 DML은 redolog에서 처리합니다.
이렇게 나뉘어져 있는 이유는 사용자가 잘못된 DML을 날렸을 경우 DML을 수행하기 전 상태로 돌아가기 위해서 입니다.(ROLLBACK)

DB_CACHE -> undo datafile (이전에 얘기했던 오라클쪽 consistant read를 공부해봅시다!)
LOG_BUFFER -> REDO LOGFILE

논리적 구조로 보자면,
UNDO 데이터는 UNDO 테이블스페이스의 블록에 저장되며, 다른 데이터블록처럼 변경 발생 시 REDO log를 생성한다. 위 그림과 같이 extent가 순환하며 재사용 및 추가 할당 된다.
UNDO_RETENTION시간동안 해당 UNDO 데이터를 보존함.

질문 !!
undo extent의 상태는 active, unexpired, expired로 나뉜다고 들었는데요,,!
undo_retention이 지난 extent는 expired 상태가 되는 것인가요?
그리고 active와 unexpired의 차이가 무엇인지 궁금합니다
답변)
active 상태의 extent는 expired 또는 unexpired 상태가 됩니다.
그 조건은

Active -> Unexpired되는 경우는 현재 undo extent의 마지막 block까지 사용하는 경우 , tx의 시작 undo extent와 현재 undo extent가 다를 경우에만 commit이후 undo extent의 상태가 변하게 됩니다.
Active -> Expired로 되는 경우는 현재 tx가 commit이 되었다 하더라도 사용하고 있던 undo extent의 사용가능한 block이 남아있기에 STATUS를 Expired로 변경하게 됩니다.(retention시간 이전에 undo가 덮어써지는 것을 방지함)

이건 다음에 만나면 직접 보여드릴게요.

SEGMENT 공간관리와 HWM(High Water Mark)
자동 세그먼트공간관리방식으로 BITMAP을 사용하여 공간을 관리한다.

데이터 입력시, HWM 하위 여유공간이 있는 블록을 사용함.
Full Scan시에 Segment Header Block의 BITMAP 정보를 이용하여 엑세스함.

TABLESPACE

segment를 저장하는 논리 저장소, 한 개 이상의 datafile이나 tempfile을 사용하여 데이터를 저장한다.

그 외

Parameter File

$TB_SID.tip 파일로, Tibero instance 시작 위해서는 반드시 필요한 파일
TSM의 memory 구성 세팅정보와 control file의 위치와 이름이 적혀있다.

Log File

Redo log와 이름은 비슷하지만 헷갈리지 말 것, instance 실행 중 error 등을 기록해주는 파일
서버 기동시 문제가 생기면 해당 log 파일을 보고 추적해볼 수 있다.
slog
Trace Log File로 $TB_HOME/instance/$TB_SID/log/slog 디렉토리에서 확인 가능.
instance 내부 에러, 데드락 에러 등 서버 성능이 저하되는 원인 찾거나 티베로 자체 버그 해결하는데 사용된다.
dlog
DBMS Log File로 $TB_HOME/instance/$TB_SID/log/slog 디렉토리에서 확인 가능.
서버 기동 및 종류, DDL 문장의 수행 등이 기록된다.
ilog
slog 보다 더 상세한 log. 디스크가 full 날 수 있어 조심해서 사용해야한다.
lsnr log
listener의 상태와 관련된 log

질문 >>>>>>>>>>
위 설명이 맞을까요? .....

jisu park

DB MASTER⭐

이전 포스트