개요
터미널환경에서 진행하는 실습
실무 위주?

티맥스 테크넷 - 온라인 매뉴얼 참조
https://technet.tmaxsoft.com/upload/download/online/tibero/pver-20150504-000001/index2.html

Tibero Process

Tibero 전체 구조

Tibero의 구조는 두 가지로 나눌 수 있다.

• 인스턴스 구조(Tibero Process 구조)
• 데이터 베이스 구조

티베로 인스턴스들은 tbBoot 실행파일을 실행할 때 한 번에 시작되고, tbDown 실행파일을 실행하면 종료된다. 이 프로세스들은 DB를 관리하기 위한 목적으로 동작한다. (DB는 데이터가 담긴 파일들을 의미한다. 여러 파일이 하나의 그룹을 이루고 있다.?) 작업 프로세스는 여러 개 존재할 수 있다.

1. Tibero Process 구조

티베로는 대규모 사용자 접속을 수용하는 다중 프로세스 및 다중 스레드 기반의 아키텍쳐를 갖추고 있다. 티베로의 사용자(User)는 3Tier 구조에서 Tier-2에 속하는 영역이다. 즉, Was(Ex: 제우스) 와 같은 클라이언트이다.

프로세스 흐름

1. 클라이언트가 db를 관리하기 위해 리스너 프로세스에게 접속 요청을 보낸다
   • 리스너 프로세스가 구동한다(리스너 프로세스는 하나)
   • 필요한 접속 정보 - 티베로 인스턴스 식별을 위한 네트워크 주소가 필요. (ip주소, 포트 번호 등)
     주소를 확인하기 위해서 필요한 데이터베이스 이름은 파일(파라미터 파일)에 저장되어 있다.
     인증을 위해 유저 패스워드

2. 워커 프로세스
   워커프로세스 쪽으로 연결해준다.

   • 워커 프로세스
   • 워커 스레드
     • CTHT : 하나가 존재
     • WTHR : 여러 개 존재

3. 워커 프로세스에게 워커 스레드를 할당해준다.
   사용자와 연결되어 있지 않은 스레드를 찾아서 할당해준다.

4. 특정 사용자와 워커 스레드의 연결이 이루어진다.

다른 사용자가 접속 요청 시 1234가 진행된다.
이렇게 연결된 접속은 서버 쪽에서 명령하거나 클라이언트에서 끊기 전까지 끊어지지 않는다. sql문을 보내지 않더라도 연결은 유지된다.

스레드가 동시에 여러 개 존재하기 때문에
사용자(클라이언트)들은 db에 동시에 접속해서 쿼리를 실행할 수 있다.

(+) 만약 리스너가 일을 하지 않는다면?

• 신규 접속이 불가능해진다. (1단계)
• 그러나 이미 접속한 뒤 연결 상태가 된 사용자에게는 아무런 영향을 주지 않는다. (4단계)

Listener

파라미터 파일
파라미터 파일의 역할

• 프로세스 동작의 제어
• 리스터 포트도 이 파일에서 제어

리스너 포트가 여러 포트를 리스닝하게 할 수 있다.

정적 파라미터 파일: 파라미터 파일을 편집해서tbBoot(인스턴스 재시작)로 포트 적용
동적 파라미터 파일: tbBoot를 사용하지 않고 sql쿼리를 통해 포트 적용

정적으로 설정해주어야 할 파라미터가 있고 동적으로 설정해주어야할 파라미터가 있다. 예를 들어 워커 스레드의 개수는 동적으로 설정할 수 없고 정적으로 인스턴스 재시작을 통해 설정해주어야 한다.

파라미터는 약 2000여개 정도. 대부분 기본값이 설정되어 있다.
Tibero6 온라인 매뉴얼에 따르면 파라미터는 300여가지인데, 매뉴얼에 실리지 않은
1500여 가지의 파라미터는 히든 파라미터이다.

워커 프로세스

WTHR이 사용자와 일대일로 연결된다.

워커 프로세스는 언제 시작할까? -> 한 번에 최대 개수가 모두 시작된다. 대기상태로 있다가 사용자가 접속하고 sql문을 보내면 sql을 처리해서 동작한다. 리스너, 작업 프로세스 등은 중간에 시작하지 않는다. 최대갯수만큼 시작했다가 대기한다.

Foreground 워커 프로세스: 리스너를 통해 요청 처리
Background 워커 프로세스: 리스너의 요청 처리를 받지 않는다.

Background 워커 프로세스는 왜 존재하는가?

• internal Task나 Job 스케쥴러(데이터 처리를 등록할 수 있는 기능)에 등록된 배치 작업을 수행한다.
• 특정 시점에 어떤 데이터 처리를 하려면 워커 스레드가 필요하다. 모든 워커 스레드가 리스너의 중계 대상이 될 때, 많은 클라이언트가 몰리면 서버 쪽의 모든 워커 스레드가 연결될 것이다. 가용한 스레드가 사라지면 잡 스케쥴러에 등록된 데이터 처리를 해야하는 순간에도 일을 시킬 수 있는 스레드가 없을 것이다. 그런 상황을 방지하기 위한 것이 바로 Background 워커 프로세스이다. 워커 프로세스 기본 설정은 Foreground 워커 프로세스이지만 Background 워커 프로세스 설정 가능하다.

CTHR(Control Thread)

• ㄹ

WTHR(워커 스레드)

• 클라이언트가 보내는 메시지 (String)을 받아 파싱 등의 처리를 하고 결과를 리턴한다.
• 파일에서 데이터를 찾아 메모리에 올리고 메모리 작업을 처리하는 것
• SQL Parsing, 최적화, 수행 등 DBMS가 해야하는 대부분의 일을 처리한다.
• 워커 스레드의 개수가 1000개라면 1000개의 클라이언트가 동시에 작업을 처리가능하다.

동시에 많은 양의 워커 스레드 사용이 발생하는 경우
WAS서버는 sql형태로 처리한다.
동시에 많은 insert쿼리가 발생한다
파라미터 파일에 워커 스레드 관련 설정을 입력해서 조절한다.

만약 워커스레드를 너무 큰 값으로 설정해둔다면 메모리가...
(하나의 워커스레드는 약 2MB)

백그라운드 프로세스

감시 프로세스 ()

• 다른 모든 프로세스 종료시킴

매니저 프로세스

• SYS 계정만 허용한다.
• 의 접속을 통해 sql 처리
• 워커프로세스와 유사하게 동작한다. (매니저 프로세스 내부에 워커 프로세스 존재)
  단, 매니저 프로세스는 리스너 없이 직접 특정 포트를 리스닝 한다.
  (리스너 포트가 리스닝하는 포트+1을 리스닝함)

에이전트 프로세스 (AGNT)

• 잡 수행의 시기를 판단해서 워커 스레드에게 일을 시킨다.

데이터베이스 쓰기 프로세스

• 여기서 말하는 데이터베이스는 파일이다. 즉, 메모리에서 가져온 파일 내부에 데이터를 쓰는 프로세스이다. 메모리는 Tibero 전체 구조에서 볼 수 있는 공유 메모리???(질문 1)
• redo log를 여기서 한다고? (질문 3)

복구 프로세스

• 복구 전용 프로세스
• 티베로 인스턴스를 복구한다.
• 티베로 인스턴스가 망가졌을 때 (crash: 정상적으로 인스턴스를 시작하지 않았을 때 발생)
  복구 프로세스가 recovery를 수행한다. 복구 작업이 필요하기 때문에 티베로의 실행 속도가 조금 늦을 수 있음

Tibero Shared Memory(TSM)

• 사용자가 동시에 데이터를 공유하기 위해 존재
• 인스턴스에 대한 데이터와 제어 정보를 가지는 공유 메모리 영역
• 파라미터를 설정하면 전체 영역의 크기를 제한할 수 있다.
  • TSM에서 반드시 설정해줘야하는 파라미터 : TSM 전체 크기와 공유하기 위한 메모리크기 (질문 4: 이게 내가 들은 게 정확한지...)
• 공유를 잘하면 성능이 높아지고, 못하면 성능이 떨어진다.
• TSM의 영역 3가지
  • 쉐어드 캐시
    • SQL Cache
      ✔ SQL과 관련된 여러가지 정보를 저장한다.
      ✔ sql은 모호하기 때문에 Tibero가 바로 실행할 수 없다. -> 구체적인 실행방법을 별도로 만들어야 한다. SQL Cache에는 이미 실행한 SQL의 실행 내역을 저장해둔다.
    • Data dictionary cache
      ✔ 테이블의 데이터 기본 구조에 대한 정보가 담겨있다.
      ✔ 사용자가 입력한 것이 아니라 tibero가 내부적으로 가지고 있는 정보
      ✔ sql 실행 시 dictionary의 정보들을 빈번하게 참조해서 확인한다.
  • 데이터베이스 버퍼
    • 데이터 블럭 저장에 사용
    • 블럭 단위로 가져온 데이터를 메모리 영역에 올려놓는 용도
    • 블럭안에 있는 데이터를 꺼내서 처리하게 된다.
    • 데이터베이스 버퍼 내부의 데이터는 다른 사용자도 공유해서 사용할 수 있다. -> 디스크에서 데이터를 다시 올릴 필요가 없기 때문에 성능이 향상된다. 즉, 디스크에서 읽지 않고 버퍼에서 읽기 때문에 속도가 빨라진ㄷ.ㅏ
  • redo log buffer
    • redo log를 쓴다
    • redo log: do(데이터 변경 작업(DML?))의 이력 정보를 별도로 남겨둔다. 이력 정보를 활용해서 do 작업을 다시 한 번 활용할 수 있다.
    • redo log 활용방식
      Ex) 책상에 휴대폰이 올려진 상태를 복사한다 → 데이터베이스 백업 (상태 저장)
      중간중간 계속해서 데이터를 복사해둔다. 데이터베이스가 망가질 수 있는 상황을 염두에 두고 백업하는 것. 하지만 가장 최근 상태의 백업을 가져온다고 하더라도 당시 상황과 완전히 같은 것은 아니다?????(질문 2)
      redo log가 온전하다면 데이터 복구를 할 수 있다.
      그런데 만약 백만 건의 변경(do)가 발생한다면 redo log가 계속해서 생길 것이다. redo log buffer는 빈번하게 발생하는 계산을 저장해둠으로써 매 계산마다 디스크를 사용하면서 성능이 저하되는 것을 방지한다.

2. 데이터베이스 저장구조

데이터베이스는 데이터를 담고있는 파일들의 집합이다.
그것은 어떤 구조로 저장되어 있는가?

Tibero Database 저장소 구조

논리 저장구조

• 테이블을 데이터베이스 내의 객체라고 부른다. 데이터를 저장하는 오브젝트들에게는 공간이 필요하다. 물리적인 저장장치를 기반으로
  파일과 같은 물리적인 저장구조의 제약을 뛰어넘어서 저장할 필요성이 있다. 여러 파일들을 묶어서 논리적인 커다란 저장공간인 Tablespace를 만든다. Tablespace-Datafile은 1대N 관계이다. 많은 데이터 파일을 연결하면 Tablespace의 크기는 커진다.

물리 저장구조

• 티베로에 접속하지 않아도 확인할 수 있는 파일들
• 구성요소 [3개]
  • Data file - 사이즈와 개수 1순위
  • Online redo log file - 사이즈와 개수 2순위
    • DB는 계속해서 바뀌기 때문에 redo log는 끊임없이 바뀐다. redo Log file의 크기와 갯수를 고정시켜서 사용한다. 고정된 파일의 내용이 가득차면 파일의 내용을 덮어쓰면서 최근 redo Log를 저장한다. redo log는 아카이브 저장소를 사용할 수 있다. 그곳에
  • Control file - 사이즈와 개수 3순위
  • (+) Password file - 파일이 아니라 테이블에 저장되어 있다. 파일을 오픈해서 사용할 수 없을 때 사용한다. 데이터 파일 안에 여러 테이블이 들어있는데 그 안에 패스워드 파일이 들어있다. 데이터 파일을 열 수 없을 때 SYS유저를 구분하기 위해 사용한다.

백업 저장소

• 백업 대상
  • Data file, Contorl file, redo Log file
  • Online이 아니다.

아카이브 저장소

• Redo Log를 쌓아둔다.
• Online이 아니다.

Tibero 인스턴스는 데이터 베이스의 파일(Data file, redo log file, Control file )들과 연결되어있다. 데이터베이스의 파일들 중 온라인 상태로 연결된 파일은 세 가지 뿐이다. tibero 인스턴스가 이들 파일을 사용하면서 동작하기 때문에 이 세 파일이 망가지면 tibero에 문제가 발생한다.

Tibero 인스턴스가 데이터 베이스의 파일을 이용하기 위해 필요한 것

• 위치 정보를 알아야 한다.

• 상태 정보를 알아야 한다.
  
  

• Control Filed의 정보들을 알 수 있는 방법 -> 파라미터 파일

• Data File + RedoLog File의 정보를 알 수 있는 방법 -> Control file

  데이터 파일 + redo 로그 파일(둘을 함께 봐야한다.)에 대한 정보는 컨트롤 파일에 담겨있기 때문에 오픈 순서가 존재한다. 항상 Control File을 먼저 오픈하게 되는 것이다!!! (질문 5: 파라미터 파일을 제일 먼저 오픈하게 되는 것이 아닌가? 파라미터 파일은 선택사항?)
  정의된 파일은 전부 오픈해야한다. 만약 하나라도 문제가 있다면(Ex: redoLogFile이 없다.) 컨트롤 파일을 오픈한 상태에서 Tibero가 멈추게 된다. -> 마운트 모드 상태
  컨트롤 파일마저 오픈하지 못한 상태 -> 노마운트 모드
  전부 오픈한 상태 -> 노말 모드

  마운트 모드에서는 할 수 있는 일이 별로 없다. 일반적인 작업 불가능

DataFiles

• Table
  • 데이터를 저장하기 위한 객체
  • Table space를 정의해야 한다.
  • Table space : DataFile (1:N관계)
  • 일반 테이블 스페이스의 영속적인 데이터 파일. 서버의 전원을 꺼도 유지된다.
  • Tempfile
• 온라인 데이터 파일 및 오프라인 데이터 파일
• DataFile 구조
  • 데이터 파일 헤더
  • 사용 공간
  • 미사용

Online Redo Log Files

• Log switch
  • 끊임없이 로그 파일을 옮겨가면서 순환하면서 사용
• 담겨있는 정보
• 데이터 베이스 운영 모드를 설정 가능
  • 파라미터 값으로 특정 디렉토리 지정 가능: 지정한 디렉토리가 카피 되어진다.

다중화
Multiplexed Redo Log Files

• Member: redo log File
• 그룹 안의 멤버는 똑같은 파일이다. redo Log buffer의 내용을 읽어서 세 곳에 똑같이 쓴다. redo Log가 발생하면 멤버 셋에 똑같이 기록한다. 왜 이렇게 하느냐? 가용성을 확보하기 위해서 다중화를 하는 것이다. 가용성은 항상 사용할 수 있게 하는 것이다. 1번 Disk가 24시간 동안 실행된다면 디스크가 빠르게 망가질 수 있다. 디스크가 망가진다는 것은 파일이 망가진다는 것이다. 하나라도 정상적인 멤버가 있다면 계속 사용할 수 있을 것이다.
• 파일 다중화의 대상은 redo log 뿐만이 아니라 control file도 포함된다.
• 단, Data file은 다중화 대상이 아니다.(개수와 크기가 가장 큼 -> 많은 비용 발생)

로그 스위치 시 카피를 진행한다. 카피 대상은

아카이브 로그 모드냐
온라인 리두 로그 모드냐에 따라 파생되어지는 동작이 있다.

아카이브 로그 모드

• 온라인 백업 가능
  노 아카이브 로그 모드
• 오프라인 백업 가능
• tbdown-> 백업

Control file

• 데이터 베이스 이름, DBID, 생성 시각, 각 파일 상태에 해당하는 정보들…
• 최소 다른 Disk상에 위치를 다르게 한다...

논리 저장구조

테이블 스페이스를 사용하기 위해서는 Segment를 이용해 테이블 스페이스의 공간 중 일부를 가져다 사용한다. 세그먼트는 특정 객체에게 할당된 저장구조이다. (인덱스 타입의 세그먼트, 테이블 타입의 세그먼트 …) 테이블에 저장한다는 것은 테이블 스페이스에 연결된 세그먼트에 저장한다는 것? 세그먼트는 여러 개가 존재한다.

세그먼트 구성

• ExTent
  • 세그먼트는 여러 개의 ExTent를 가지고 있다.
  • 데이터 파일의 특정 영역을 가져다가 사용
  • 공간 할당의 단위
• Data Block
  • 데이터 베이스 시작 시 설정할 수 있는 데이터 블럭의 크기는 다양.
  • 데이터 베이스 내의 데이터 블럭 크기는 모두 동일하다. (데이터베이스를 만든 뒤 수정 불가)

세그먼트와 익스텐트, 데이터 블록 관계

• 인덱스가 만들어지면서 인덱스에 연결되는 세그먼트 생성, 세그먼트는 테이블이나 인덱스와 다르게 저장공간을 제공하는 역할을 하기 때문에 특정 파일의 특정 영역을 할당받는다. create table 시 #1 데이터 파일의 영역을 세그먼트가 할당받는다. (32KB의 공간을 점유하는 동작을 수행하는 것) 테이블에 데이터가 없더라도 세그먼트는 데이터 테이블의 특정 영역을 할당받는다. 할당받아서 점유하는 이유는 저장공간을 확보하는 측면. 테이블의 데이터가 insert되면 Extent의 block들로 데이터가 저장된다. block이 모두 사용된다면 tibero가 자동으로 extent를 붙여준다. (64KB 공간) 이제 segement는 2개의 extent를 점유한 상태.
• 사전에 공간을 할당받기 때문에 테이블이 얼마나 많은 공간을 점유하고 있는지 확인하기 위해서는 segment의 extent들을 확인한다.
• 만약 delete를 한다면 block안의 데이터를 지우는 것이다. 블럭이나 extent에는 영향을 주지 않는다. 여전히 동일한 공간 점유 중
• Truncate 시 할당 해제 (Drop할 때는?)

테이블 스페이스 공간 관리

• 세그먼트 생성
  • 테이블, 인덱스 객체 생성시 세그먼트가 생성된다.
  • 세그먼트는 스키마 객체에 따라

• UNDO 세그먼트
  • 끊임없이 만들어진다. -> 저장구조가 순환식이다.(기존 공간 재활용)
  • 모든 데이터 변경 시 undo 테이블 스페이스 세그먼트에 저장
  • 1. 새로운 undo데이터가 나올 때 익스텐트1에 나오는 데이터 덮어씀 (우선순위 동작)
  • 2. 기존 4번 익트텐트4에 익스텐트5를 생성해서 저장함 -> 저장공간을 더 사용한다.
  • Active - commit 전
  • Unexpired - 커밋 이후
  • Expired - 커밋 이후 파라미터에 정의된 시간이 지났을 때
  • 역할
    • 커밋 전 상태라면 롤백 가능
    • 트랜잭션이 실패할 경우 전부 롤백 처리
    • 읽어야 할 데이터가 발생할 때 시차가 발생하는데, 나중에 읽은 데이터가 다른 세션에 의해 변경될 수가 있다. 이를 방지하기 위해 처음에 읽는 데이터와 나중에 읽는 데이터를 모두 처음에 읽는 데이터와 동일한 시점으로 맞춰준다. 데이터를 과거로 되돌린다? -> 데이터를 읽는 시점 undo데이터를 이용해서 과거로 되돌려서 (읽기 일관성 작업)
    • 플래시백 쿼리라는 특수한 쿼리를 사용하면 손쉽게 복구를 진행할 수 있다.
  • Undo 데이터는 UNDO_RETENTION 시간 동안 유지

세그먼트 공간관리와 HWM

• 테이블 타입 세그먼트
  세그먼트 블럭들에 access하게 된다. 접근 시에는 기본적으로 세그먼트 타입 데이터는 공간 구조 자체가 순서 없이 빈공간에 채워넣는다.
• 단점 조건에 맞춰 select 해야하는데 세그먼트의 위치를 짐작할 수 없다. 테이블 full scan이 기본 동작이다. 데이터가 적을 때는 문제가 없지만 데이터의 양이 많다면 문제가 된다. 점점 쿼리가 느려질 것. 실제 데이터는 몇 군데에 띄엄띄엄 들어있다 하더라도 full scan을 해야한다.
• 세그먼트 재구성 (deorganize) 을 권장한다. 새로운 세그먼트로 이동하고, 데이터 양만큼의 세그먼트로 할당?
• 인덱스 : 테이블 저장구조 때문에 인덱스 생성이 필수적이다. 모든 정보를 스캔하지 않고 특정 블록의 위치정보를 얻어서 블록만 스캔하는...

데이터블록

• 블록 헤더(메타 데이터)와 데이터 레이어가 존재한다.
• Tibero는 행 단위로 데이터를 저장한다. (열 단위로 저장하는 DBMS도 있다.)
• 행 연쇄 () 행 이주 ()
  • 행 연쇄
    • 블록 내에 데이터를 넣다보면 끊어지는 부분 발생 -> 성능 저하 발생
    • 인서트 시 하나의 블록에 쓰지 못하기 때문에 다른 블록 사용 -> 개념상 io가 두 번 발생
  • 행이주

RowID

• 위치 정보
• 인덱스가 특정 블록의 위치 정보를 가진다. 인덱스는 RowId 정보를 사용한다.
  테이블 스페이스
• 세그먼트를 저장하는 논리저장소. 데이터베이스 생성 시 기본 테이블 스페이스가 만들어지고, 사용자가 추가로 생성해서 사용할 수 있다.

The Parameter File

• 인스턴스가 tbBoot에 의해 실행될 때 파라미터 파일이 중요. 리스터 포트, 티베로 쉐어드 메모리 등을 파라미터 파일이 관리하기 떄무넹.
• 파라미터 파일이 없다면 db는 시작할 수 없다. 그러나 이미 시작된 이후에 파라미터 파일 값을 세팅한다 하더라도 인스턴스 동작에 영향을 주지 않는다. 단, 동적인 속성을 가진 파라미터에 한해 arterset 파라미터를 통해 db 접속 후 쿼리를 통해 바꿀 수 있다.

slog

• 프로세스들이 정해진 중요한 일을 할 때는 tibero slog에 써놓는다. 중요한 일들을 할 때 log에 남기고 에러가 발생할 때도 기록을 남긴다. 시스템 로그를 보면 운영관리에 도움을 받을 수 있는 정보를 알 수 있다.
• 기본 위치. 파라미터를 사용해서 별도의 위치로 바꿀 수 있다.

티베로 기능

티베로 서버는 여러 기능을 가지고 있다.
성능 관점에서 비교해보면 여러 기능이 있따
성능 : 데이터 처리 작업 -> 쿼리가 빨리 실행되느냐?

비용 기반 Optimizer

• 실행계획을 지원하는 녀석
• 옵티마이저의 판단에 따라 몇천, 몇만 배의 성능 차이가 발생할 수 있다.
• 일반적인 DBMS들이 채택하고 있는 방식
• cost
  • Disk io 및 cpu사용에 대한 부분을 정량화 해서 만들어낸 것
• 실행계획을 만든다.(수많은 경로 고려) -> 방법 고려하여 수치 계산한 뒤 비교한다.
• 실행통계 조회 (테이블에 데이터가 얼마나 많은가? 데이터 블럭 몇 개를 점유해서 테이블에 데이터들이 존재하는가?)
• Hint - 사용자가 개입해서 실행계획을 제어할 수 있게 한다.

다양한 인덱스/파티션

• Partition

  • 테이블이 많을 때 성능 향상 가능
  • 오브젝트마다 세그먼트가 생성되어있음. 풀스캔을 하면 연결된 세그먼트의 모든 블럭을 스캔하는 것이기 떄문에 성능 저항 -> 테이블은 하나인데 세그먼트는 하나 존재???. 딕셔너리 정보를 참고하여 테이블 파티션 하나만 풀스캔하도록 한다.

• 고성능 병렬 처리 및 압축

  • 하나의 워커 스레드가 한 개의 쿼리 처리

  • 여러 워커스레드가 할당돼서 일을 동시에 나누어 한다.

  • 그러나 병렬 처리를 한다고 늘 성능이 높아지는 것은 아니다.

  • 병렬 처리에 적합한 형태의 간격이 있다.

  • 서버장비 (물리적인 하드웨어)가 영향을 준다.

  • 압축

    • 블록을 적게 사용한다.
    • 항상 빨라지지는 않고 적합한 경우에 빨라진다.

TAC

• 목적 - 고가용성, 안정성, (+) 확정성
• cluster : 하나가 아니다.
• 티베로 intsance가 여러 개 모여있다.
• active : 여러 티베로 인스턴스들이 active(동작 중)이다. 쿼리를 실행할 수 있다.
• Node 1, 2의 서버 장비가 있고 티베로 db가 설치되있다. 둘은 스토리지 공유에 의해 연결되어있다.
• Ex : 전원 공급장치를 교체해야한다면 ? 그런 상황에서도 서비스가 지속되도록
• (+) 확정성
  서버가 하나만 있다면

TSC

• 목적 - 가용성
• 서버를 하나만 아니라 ,,, redo 로그를 활용해서 복제. 문제가 생기면 다른 node 사용

백업 & 복구

• 특정한 테이블만 export가능

개발관리 도구

• 개발자와 관리자에게 필요한 utility 지원
• T-up
  • 다른 DBMS로의 이식
  • 로딩 시에 사용가능. text형태의 데이터만 가능
• tbExport/tbImport
  • 티베로간 적재와 추출
• tbrmgr
  • 백업 복구 툴