티맥스 티베로 DBMS -7

김재현·2022년 8월 25일
cnu sw academy
0

티맥스 티베로

목록 보기
7/7
  • 금요일(내일) 테스트.
    안 배운 것 중에 나올수도 있음.
  • 교재 참조 backup, recober
  • 티베로 관리자 안내서 백업과 복구
  • 티베로 SQL 참조 안내서 7.2 ALTER DATABASE
    7.69 FLASHBACK TABLE

BackUp & Recobery

백업, 리커버리란?

  • 여러 가지 유형의 장애물로부터 데이터베이스 보호.
    • MTBF (Mean Time Between Failure)를 증가시키고 MTTR (Mean Time Between Recover)를 감소
  • 시스템 장애 발생 시 복원을 하거나 시스템 작동을 유지한다.
  • 관리자는 시스템 장애시 발생할 손실을 최소화하고 복구 가능한 상태로 데이터베이스를 운용해야한다.
    • 최소 한 달에 한번 데이터베이스 전체 백업.
    • 하루에 한 번 Export 백업 권장
  • 데이터 베이스 관리자는 백업에 대한 정책을 수립하고 꼭 필요한 데이터를 최소한의 양으로 백업.
    • 백업은 DBA의 주요 역할 중 가장 주의를 기울어야 함.
  • "RECOVERY에 실패한 DBA는 용서할 수 있지만,
    BACKUP을 실패한 DBA는 용서할 수 없다."
  • 백업이 정상적으로 수행되었는지 주기적으로 검증하는 것을 권장.
  • 백업을 하는 동안 성능저하가 발생할 수도 있기 때문에, 너무 자주하기는 어려울수도 있다.
  • 백업은 자동으로 이루어지게 설계해두는 것이 좋다.
  • 티베로 인스턴스가 백업까지 해주는 것은 어렵기 때문에 백업 프로그램을 따로 구비해두자.
  • 예시 : 베리타스 넷 백업
  • 파일 사용 중에 복사, 백업한다면 추후 복구할 때 사용하지 못할 수도 있다. 백업 소프트웨어-DB소프트웨어의 긴밀한 프로세스가 필요하다.
  • 백업과 관련된 절차와 SQL들을 스크립트로 작성해 백업 소프트웨어를 설정할 때 삽입한다.
    백업 소프트웨어가 세팅되고, 실행될 때 스크립트를 반복실행하여 프로세스를 수행하고 문제 없이 백업이 되게 된다.

여러 유형의 장애

명령문 실패

  • 테이블의 제약 조건에 위배되는 데이터 insert
  • 권한 부족
  • 테이블 생성시나 데이터 변경 시 테이블 스페이스에 공간 부족

사용자 프로세스 실패

  • 비정상적 종료로 인한 사용자 프로세스 실패가 대부분
  • Tibero의 monitor process가 비정상적인 종료를 감지하고 수행중인 트랜잭션 등은 롤백

사용자로 인한 장애

  • 장애 발생 상황
    • DROP TABLE, TRUNCATE TABLE, DELETE FROM&COMMIT, 잘못된 update&COMMIT 등등
  • 해결방안
    • 사용자 교육 실시, 백업에서 복구 Export받은 테이블을 import, Time-based 불완전 복구

Instance fail

  • 정전, CPU나 memory fault, background process의 비정상적 작동 등의 종류가 대부분
  • 복구
    • 특별한 복구 작업이 필요치 않음
    • tbboot을 통해 DBMS를 기동하면 자동으로 복구됨
    • 로그 등을 참고하여 원인 분석

Media fail

  • 데이터파일이 저장된 하드디스크 장애
  • 데이터 파일의 삭제
  • 정해진 복구 전략에 따른 복구 절차가 필요

동작 방식의 이해

Transaction Durability

  • Committed Transaction MUST Survive failures (Recoverable, 복구 가능한)
  • 커밋할 때 Durability(영속성)를 갖게 된다. 커밋 전에는 못 갖음.
  • 커밋 전에는 확정이 되기 전이기 때문.
  • 데이터 파일이 망가진다면 Recoverable하지 않게 된다.

Logging

  • Redo Log Buffer : TSM에 redo 데이터를 저장하기 위한 영역
  • Redo Log File : recovery를 위해 가장 중요한 파일
  • Archive : archive log mode 시 redo logfile을 별도의 위치에 backup.

Redo 저장대상 범위

  • Physical Logging
    • 수정이 일어날 때마다 해당 block을 통째로 남김.
  • Logical Logging
    • update, delete 같은 operation을 log에 남기는 방법.
    • 여러 physical block들에 대한 수정을 하더라도 operation만 기록되어 logging양이 적음.
    • 하지만, change가 반드시 순서대로 apply되야 한다. recovery 때 log apply가 어려움.
  • physiological Logging
    • 위 두 방식의 장점을 융합.

DATABASE(Controlfile, Redolog file, Datafile) 동기화 방식

  • TSN
    • Database의 version 또는 commit version
    • Data Concurrency Control, Redo Ordering, Recovery 등에 사용된다
    • Transaction이 commit될 때 TSN이 generate된다
  • Checkpoint
    • 모든 데이터 접근 작업은 메모리에서 처리.
    • 주기적으로 혹은 사용자의 요청에 따라 메모리에 있는 모든 변경된 (dirty) 블럭을 디스크에 쓰는 작업
    • 업데이트는 SQL과 무관하게 비동기적으로 이루어진다.
      Checkpoint시점에 이 작업이 이루어진다.
    • 나중에 파일에 반영하는 이유 : 매번 동기화돼서 즉시 반영하면 빈번한 디스크 접근이 발생, 서버의 작업량을 높여 성능저하를 야기한다.
      때문에 한 번에 모아서 쓰는 작업을 하는 것.
    • CheckPoint 발생상황
      • 모든 로그 스위치 발생시
      • 인스턴스가 NORMAL, POST_TX, IMMEDIATE 옵션으로 종료
      • 사용자 요청에 따라 수동으로 발생
        SQL> ALTER SYSTEM CHECKPOINT;
    • 갑자기 메모리가 사라진다면 어떻게 해야할까? 컴퓨터의 갑작스러운 종료 등으로.
      Committed Transaction MUST Survive failures. 커밋을 하면 메모리 뿐 아니라 파일에도 저장되기 때문에 안전하다.
    • 모순 아닌가? CheckPoint는 메모리에 모아서 한번에 쓰는 거잖아?
    • Transaction Durability는 RedoLog를 기록한다. 메모리→파일

백업 개요

종류와 전략

종류

  • 논리적인 백업
    • 데이터베이스의 논리적인 단위 백업
    • export - import 명령어
  • 물리적인 백업
    • 운영체제 레벨에서 COPY 명령으로 백업한다.

  • NOARCHIVELOG 모드에서 백업 :
    DB 구성하는 전체 파일에 대해 운영을 멈출 상태에서 백업.
    데이터베이스를 백업 받은 시점으로의 복구만 가능.
  • ARCHIVELOG 모드에서 백업 :
    운영중에도 백업 가능.
    백업된 archive logfile의 시점에 따라 datafile 백업 시점 이전으로의 복구도 가능하다.
  • RedoLog의 상태에 따라 다르다.

  • 오른쪽의 경우
    • closed : DB를 닫는다. tbdown할 때.
      tbdown을 하고 백업을 받아야한다.
    • consistent : 컨트롤 파일이 기준이 돼서, 컨트롤 파일의 기준정보와 실제 파일들이 일치하여야 한다. TSN도 일치해야한다.
      티베로 인스턴스를 정상종료를 할 때 consistent상태가 된다.
      이 상태여야만 추후 복구용으로 사용 가능.
  • 왼쪽의 경우
    • open, inconsistent여도 사용 가능.
      비정상 종료가 되어도 가능하다.
    • 물론 closed 상태, consistent 상태도 가능하다.
    • 당연히 하드가 손상된다든지 하는, 기반이 무너지면 기능 불가...
    • RedoLog 덕분에 가능한 일. RedoLog를 이용해서 정보를 맞춰줄 수 있다.
  • 일반적으로 왼쪽의 경우, ARCHIVELOG 모드(온라인 백업)로 운영하는 경우가 많다.
  • 오른쪽의 NOARCHIVELOG 방식의 경우 제약조건이 너무 많기 때문.
    예: 백업을 받는 동안 tbdown을 해주어야한다. 백업이 5분 걸린다면, 5분동안 DB가 꺼져있는 것이다.
  • open, inconsistent상태에서 백업이 이루어지는 경우가 많다.

아카이브 모드로 변경하자

  • Tibero 종료

  • 파라미터 파일 tibero.tip에서 LOG_ARCHIVE_DEST 확인

  • tbboot mount로 실행

  • SQL문 실행해주기.

  • 껏다 켜주기

  • 로그 모드를 확인해보면, ARCHIVELOG 모드인 것일 알 수 있다,

  • 아카이브 로그 리스트 확인해주기.

  • ALTER SYSTEM SWITCH LOGFILE;
    수동으로 로그파일 스위치

  • sequence가 7→8이 되었다.

  • 파일을 그대로 복사한 것이 아닌, 파일의 내용물만 복사한 것이기 때문에, 용량 등이 다를 수 있다.
  • 자동으로 로그스위치가 됐을때는 로그 파일이 가득 차서 바뀌는 것이기 때문에, 수동으로 로그 스위치를 했을 때의 파일이 더 작을 가능성이 높다.

오프라인 백업하기

  • tbdown을 통해 DB를 끄지 않고 했다면, 백업 파일은 추후 사용하기 어려울 것이다.

  • 무엇을 백업해야하는지 먼저 알아보자.

  • 데이터파일

  • 로그파일

  • 컨트롤파일

  • 반드시 정상종료한 상태에서 작업을 진행하자!

  • 백업용 폴더를 생성하고, 거기에 데이터파일(.dtf) 로그파일(.log) 컨트롤파일(.ctl)을 복사해주자.

  • 아카이브파일(.arc) 파라미터파일(tibero.tip) 패스워드파일(.passwd)도 복사해준다.

  • 확인해보자. 잘 옮겨졌다.

데이터 베이스 원복하기

  • 티베로 인스턴스 종료 → 기존 데이터베이스 삭제 → 백업 데이터 리스토어 : 다시 원래 폴더로 집어넣기 → 티베로 인스턴스 시작
  • 번거로우니 shell 스크립트를 만들어서 자동화시켜보자.
  • 티베로 인스턴스 종료
    tbdown abort
  • 기존 데이터베이스 삭제
rm /tibero/tbdata/tibero/*.dtf
rm /tibero/tbdata/tibero/*.log
rm /tibero/tbdata/tibero/*.ctl
rm /tibero/tbdata/tibero/arch/*.arc
rm /tibero/tibero7/config/tibero.tip
rm /tibero/tbdata/tibero/.passwd
  • 백업 데이터 리스토어 : 다시 원래 폴더로 집어넣기
cp /tibero/s/off_backup/*.dtf /tibero/tbdata/tibero 
cp /tibero/s/off_backup/*.log /tibero/tbdata/tibero 
cp /tibero/s/off_backup/*.ctl /tibero/tbdata/tibero
cp /tibero/s/off_backup/*.arc /tibero/tbdata/tibero/arch
cp /tibero/s/off_backup/tibero.tip /tibero/tibero7/config 
cp /tibero/s/off_backup/.passwd /tibero/tbdata/tibero
  • 티베로 인스턴스 시작
    tbboot

  • off_backup.sh 파일로 만들었다.
    → 파일명 변경 recover_using_offbackup.sh

  • 모드를 바꿔주어야 한다. chmod u+x
    모드를 바꾸면 파일 색깔이 바뀐다.
  • 실행해볼까?

  • 잘 실행됨을 알 수 있다.
    알아서 티베로 인스턴스를 종료하고, 파일의 삭제와 복구를 진행한 후 티베로 인스턴스의 실행까지 한다.
  • 이왕 하는 김에 오프라인 백업해주는 파일도 만들자.

  • 파일을 꾸며준다.

  • 실행 결과를 확인해보자.

리눅스의 권한(퍼미션) 설정

참고

  • 리눅스에서는 파일에 권한을 주어 설정해야 사용이 가능하다.
    chmod가 그 명령어이다.
  • r는 읽기, w는 쓰기, x는 사용이며
    위에서 사용한 chmod u+x는 chmod(change mod) u(user) x(사용)을 합한 명령어라 볼 수 있다.

Online Backup

운영 중 백업(온라인 백업)

  • ALTER TABLESPACE 명령으로 테이블스페이스의 datafile 백업한다
    ARCHIVELOG 모드에서만 사용 가능하다.
  • Tibero 데이터베이스에 온라인 백업 시작을 알림
    SQL> ALTER TABLESPACE SYSTEM BEGIN BACKUP;
  • OS 명령으로 해당 테이블스페이스의 데이터파일 복사
SQL> !cp /data01/tibero/system001.tbf /backup/tibero/system001.tbf_backup`
  • Tibero 데이터베이스에 온라인 백업 종료를 알림
    SQL> ALTER TABLESPACE SYSTEM END BACKUP;
  • 주의!
    온라인 백업 중에는 DB 변경 사항에 대한 log의 양이 늘어나기 때문에 가능하면 신속히 작업을 종료해야한다. > 성능이 느려짐.
  • 일반적인 환경에서는 외부 프로그램을 사용하는 경우가 많다.

동적 뷰

  • V$BACKUP : 현재 begin backup으로 인해 backup mode인 상태를 확인한다.

Bigin backup 이후 발생 내용

  1. begin backup 실행시 redo log 에 쌓이는 로그 차이점
    → begin backup 이 일어난 후 block 변경시 해당 block 전체를redo log로 남기는 image logging 이 발생함에따라 log 양이 평소에 비해 증가하게 됨
  2. end backup 을 실행하지 않는 경우 문제점
    → 1에서 언급한 바와 같이 log 양이 증가함
    → 티베로 정상 종료가 불가하며, 만일 강제 종료할 경우 다음 부팅시 media recovery 를 해줘야 함
  3. end backup 실행시 tibero 내부적으로 처리되는 내용
    → controlfile 과 datafile 에서 해당 tablespace 가 backup mode 라는 플래그를 off 하며, check point 정보를 최신으로 업데이트 합니다
  4. begin backup 실행시 datafile 의 변경사항
    1) datafile 의 header 에 backup mode 라는 플래그가 on 됨
    2) begin backup 과 end backup 사이에 발생하는 변경사항이 data file 과 redo log file 에 기록되지만, header 에 setting 되는 checkpoint 값, TSN 값은 고정된다
  • 오랫동안 backup이 진행되면 로그가 계속 쌓이게 돼서 프로그램이 멈추게 된다.
  • backup을 시작했다면 최대한 빨리 작업을 진행하고, 가급적 빨리 꺼주는 것이 좋다.

  • 일부 데이터파일만 백업을 할 때 장점 : 백업을 켜놓은 파일들에서만 RedoLog가 많이 나오기 때문에, 로그 발생량을 줄일 수 있다.
  • 모든 데이터파일에서 백업을 진행할 때 장점 :작업양이 많을 때 작업시간을 줄일 수 있다.
    단점 : 백업 중간에 정보를 수정하면 모든 파일에서 RedoLog많이 발생하게 된다.
  • 백업 장소 만들기
    /tibero/s/on_backup/

데이터파일 백업

  • SQL 접속한 상태에서 작업.
    SQL에서 명령어를 넣으려면 !를 앞에 붙여주어야한다.
  • 모든 테이블 스페이스의 데이터 파일에 대해 백업플래그 켜기
    → ALTER DATABASE BEGIN BACKUP;

  • 모든 테이블스페이스의 데이터 파일에 대해 백업플레이스 돌리기
    → !cp /tibero/tbdata/tibero/*dtf /tibero/s/on_backup
    → SELECT * FROM V$BACKUP;

  • 백업 플레이스 끄기. 수행 이력이 담긴 리두로그를 아카이브 하기.
    → ALTER DATABASE END BACKUP;

→ ALTER SYSTEM SWITCH LOGFILE;

  • 백업이 종료됐나 확인하기

  • 백업된 데이터파일 조회
    • ALTER SESSION SET NLS_DATE_FORMAT='YYYY/MM/DD HH24:MI:SS';
    • COL TIME FOR A25
    • SELECT * FROM V$BACKUP;
    • !ls -al /tibero/s/on_backup/*dtf

컨트롤 파일 백업

  • 백업 명령 실행
    (ALTER DATABASE ~ TRACE AS '컨트롤파일 생성용 스크립트파일 경로와 이름' )
SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS '/tibero/s/on_backup/crectl.sql'
REUSE NORESETLOGS;
  • 컨트롤 파일을 단순 복사하는 것이 아닌, 새로운 컨트롤 파일을 다시 만든다.
  • 같은 경로에 같은 파일이 있다면 오류가 발생하지만, REUSE가 그냥 덮어씌워 버린다.
    NORESETLOGS는 로그를 생성하지 않는 명령어.
  • 백업된 파일 조회
    • !ls -l /tibero/s/on_backup/crectl.sql
    • !cat /tibero/s/on_backup/crectl.sql

  • NORESETLOGS 와 RESETLOGS 차이점.
    NORESETLOGS : 리두로그 파일이 없다면 작동되지 않는다. 기존 리두로그 파일을 참조하기 때문.
    RESETLOGS : 리두로그 파일에 접근해서 내용을 컨트롤 파일에 적는 작업을 하지 않는다. 새로 만들기 때문에 기존에 있는 내용을 가져올 필요가 없는 것. 따라서 리두로그 파일이 없어도 정상적으로 작동한다.

로그파일 백업

  • 온라인 리두로그를 아카이브 수행하여 아카이브로그 파일을 백업 받는다.
    Log switch 실행
    SQL> ALTER SYSTEM SWITCH LOGFILE;

  • Archivelog 파일 백업
SQL> !cp /tibero/tbdata/tibero/arch/*.arc
/tibero/s/on_backup

  • 백업된 파일 조회
    !ls -l /tibero/s/on_backup/crectl.sql

기타 파일 백업

  • 파라미터 파일
    !cp /tibero/tibero7/config/tibero.tip /tibero/s/on_backup
  • 패스워드 파일
    !cp /tibero/tbdata/tibero/.passwd /tibero/s/on_backup

  • 전체파일 조회
    !ls -al /tibero/s/on_backup
  • 새 로그 파일이 기존 로그 파일을 지우도록 스크립트를 작성하는 경우가 많음.
    이렇게 하지 않으면 로그파일이 언젠가는 디스크를 가득 채우기 때문..

지금까지

  • 로그모드 변경(ARCHIVELOG) → 오프라인 백업(직접하기
    ) → 오프라인 백업(SHELL파일 생성) → 온라인 백업
  • recover_using_offbackup.sh(DB복구)와 off_backup.sh(오프라인 백업)을 만들어보았다.
  • 이 상태를 저장하기 위해서 off_backup.sh를 사용해서 백업을 받자.

  • 먼저 off_backup2 폴더를 비워주기 위해 스크립트를 추가해주었다.

  • 잘 실행된다.

백업 파일을 이용한 datafile 완전 복구

  • 실습을 위해 장애를 강제로 발생시킨다.
    데이터파일을 삭제하고 tbdown abnormal을 통해 비정상 종료.

  • tbboot를 통해 티베로 시작 시 에러메시지가 출력되며 MOUNT모드로 기동된다.
    무엇이 잘못됐는지 당연히 알지만, 모르는 척 하자.

  • 티베로에 접속하고 SELECT * FROM V$RECOVER_FILE;을 사용해서 복구가 필요한 파일을 확인한다.

  • 어떤 파일에 문제가 생겼는지 알 수 있다.

  • !ls 명령을 사용해서 문제가 생긴 파일을 조회한다.
    어라, 파일이 없다는 결과가 출력된다.

  • 백업파일을 원래 파일이 있어야 하는 자리에 복사해준다.
  • 가장 최근에 백업받은 것을 갖다가 넣는다든지 하는 여러 내용이 생략되긴 했지만, 어쩔 수 없다.

  • 잘 수리되었나 조회해본다.

  • ALTER DATABASE RECOVER AUTOMATIC DATABASE;명령어를 사용하자.
  • AUTOMATIC DATABASE : 자동으로 복구 수행

  • 이제 수리해야 할 파일이 없다.

  • 종료할 때도 NORMAL mode로, 다시 시작할 때도 NORMAL mode로 정상적으로 실행하는 것을 알 수 있다.

  • nomount(컨트롤파일x) → mount(컨트롤파일o) → normal(복구 완료)

온라인 백업 이용하여 전체 복구

  • 장애 : 모든 데이터 파일, 컨트롤파일, 리두로그, 아카이브 파일 삭제됨
rm /tibero/tbdata/tibero/*.dtf
rm /tibero/tbdata/tibero/*.log
rm /tibero/tbdata/tibero/*.ctl
rm /tibero/tbdata/tibero/arch/*.arc
rm /tibero/tbdata/tibero/.passwd

tbdown abnormal
  • 복구 : 온라인 백업 파일 이용해 복구.
    • 백업 파일 리스토어
    • 컨트롤 파일 복구
    • 데이터파일 복구
    • 리두로그 파일 복구
    • 데이터 베이스 오픈 이후 tempfile추가.
    • 전체 백업하기

  • 모든 파일이 삭제되고, 티베로 인스턴스가 불완전종료되었다.

  • 텅 빈 tibero폴더의 모습

  • 그래도 온라인 백업 폴더가 남아있다

  • 백업폴더의 파일을 복사해서 올바른 경로에 놓아주자.

  • 데이터파일과 패스워드, 컨트롤파일의 sql 파일.

  • 아카이브 로그

  • 데이터파일 복구가 됐으니, 컨트롤 파일 복구를 진행한다.
    티베로 인스턴스를 nomount모드로 시작해준다.

  • RESETLOGS를 사용하여 실행하여야 한다.
    현재 리두로그가 존재하지 않기 때문.
    NORESETLOGS는 리두로그가 존재해야 사용 가능하다.

  • crectl.sql파일을 수정해준다.
    RESETLOGS케이스를 남기고 위의 NORESETLOGS는 삭제해준다.

  • sql에 접속해서 수정한 crectl_resetlogs.sql파일을 실행해준다.
    컨트롤 파일이 재생성되었다고 출력된다.

  • 티베로를 종료시켰다가 mount 모드로 재실행해준다.
    MOUNT mode로 실행되었다는 문구가 출력된다. 컨트롤 파일이 제대로 생성되었음을 알 수 있다.

  • 컨트롤 파일이 생성되었다.

  • Media Recovery
    ALTER DATABASE RECOVER AUTOMATIC DATABASE;를 실행해준다.
    다음 다시 꺼준다.

  • 로그 재생성을 위해 tbboot restlogs로 재실행해준다.

  • 로그가 생성되었다.

  • 현재 TEMP 파일이 비어있는 것을 확인해주자.

  • TEMP 파일을 채워준다.
  • 노말모드 재기동 때 리두로그 복구.
    5번작업 때 tbboot RESETLOGS 함. > 과거에 백업받은 것으로 복구가 불가능해짐. 리셋이전과 리셋이후가 단절.
    리셋을 한 후에는 백업을 다시 해 줄 필요가 있음.

  • 전체 백업하기
    스크립트 이용 ./off_backup2
  • 시험
    DB링크, TtoT, TtoO
    유틸리티 툴 사용. 티베로에서 익스포트, 임포트 하는 법.
    리모트 티베로에서 익스포트 받아서 로컬 티베로에 임포트 하기
    로더로 텍스트 받아서 테이블에 적재하기
    오라클에서 익스포트 받고, 다른 스키마 내용을 마이그레이션 하기.
    백업 복구 관련 내용. 오프라인 백업, 온라인 백업.
    백업을 이용해서 파일 복구하기. 하나 빠졌을 때, 전부다 빠졌을 때.
profile
김재현
이전 포스트

티맥스 티베로 DBMS -6

0개의 댓글