백업과 복구
Tibero는 시스템의 예상치 못한 오류 등으로 인해 데이터베이스가 비정상적으로 종료하거나 시스템에 물리적인 손상을 입은 상황을 대처하려고 다양한 백업과 복구 방법을 제공합니다. 본 장에서는 이러한 백업과 복구 방법을 설명합니다.
Tibero 구성 파일
Tibero의 파일은 컨트롤 파일(Control file), 데이터 파일(Data file), 임시 파일(Temp file), 로그 파일(Log file)로 구성됩니다.
플래시백 데이터베이스(Flashback Database) 기능 사용 시에는 플래시백 로그 파일(Flashback Log File)
이 추가됩니다. 플래시백 데이터베이스 기능에 대해서는 “플래시백 데이터베이스”를 참고합니다. 각 파일의 특징과 역할은 다음과 같습니다.
컨트롤 파일(Control file) 컨트롤 파일은 Tibero를 구성하는 모든 파일의 위치와 데이터베이스의 이름 등 데이터베이스의 구조를 저장하는 파일입니다. 특히, Tibero가 사용하는 데이터 파일, 로그 파일 등의 상태 정보가 기록됩니다. 컨트 롤 파일은 Tibero를 기동할 때 복구가 필요한지를 판단하는 데 사용됩니다. 컨트롤 파일은 데이터베이스의 복구에 매우 중요한 파일이므로 다른 물리적 파티션에 여러 개 지정하 기를 권장합니다. 여러 개를 유지하면 한 파티션에 장애가 발생하여 컨트롤 파일을 사용하지 못하더라도 다른 컨트롤 파일을 이용하여 복구할 수 있습니다. 컨트롤 파일은 현재의 데이터베이스를 구성하는 파일에 관한 정보를 담고 있으므로 반드시 최신 것으 로 유지해야 합니다. 컨트롤 파일의 백업은 현재의 컨트롤 파일 자체를 백업하는 방식으로 이루어지지 않 고, 컨트롤 파일을 생성하는 CREATE CONTROLFILE 문을 백업해 두었다가 복구가 필요한 경우 백업 해 놓은 컨트롤 파일 생성문을 사용하여 컨트롤 파일을 다시 생성하는 방식으로 이루어진다. 최신의 컨트롤 파일을 유지하기 위해서는 데이터베이스에 파일을 추가하거나 변경하는 등 구조상 변화 가 있을 때마다 컨트롤 파일의 생성문을 백업해야 합니다. 컨트롤 파일 자체를 백업해 두었다가 사용하는 것은 NOARCHIVELOG 모드에서처럼 데이터베이스 전체를 백업하는 경우에만 사용할 수 있습니다.
데이터 파일(Data file) 데이터 파일은 사용자의 데이터를 저장하는 파일로써 로그 파일과 함께 데이터베이스를 구성하는 가장 중요한 파일입니다. Permanent 테이블 스페이스와 Undo 테이블 스페이스에서 정의한 파일로 테이블, 인덱스 등의 데이터 베이스 객체를 저장합니다. 테이블 스페이스는 한 개 이상의 데이터 파일로 이루어지며, 한 데이터 파일은 하나의 테이블 스페이스에 속합니다. 데이터 파일은 사용자의 데이터가 물리적으로 저장되는 공간이므로 반드시 백업해야 합니다.
임시 파일(Temp file) 임시 파일은 데이터베이스가 메모리에서 처리할 수 없는 방대한 양의 데이터를 다루는 경우 임시로 사 용하기 위한 공간입니다. Tibero는 사용자의 질의를 처리하기 위해 정렬 등의 연산을 수행할 때와 임시 테이블(Temporary Table) 의 데이터를 저장할 때 데이터 파일을 사용합니다. 데이터 파일은 임시 테이블 스페이스(Temporary Ta blespace)에서만 정의할 수 있고, 임시 테이블 스페이스는 하나 이상의 데이터 파일을 가질 수 있습니다. 임시 파일은 데이터베이스를 구성하는 데이터가 물리적으로 저장되지는 않고 운영 중에 임시로 사용되는 영역이므로 백업할 필요가 없습니다.
로그 파일(Log file) 로그 파일은 로그를 저장하는 파일입니다. 데이터 파일에 기록되는 내용을 시간 순으로 기록하는 파일로 써 데이터베이스를 복구할 때 사용합니다. 로그 파일은 운영 중에 순환적으로 재사용되는 온라인 로그 파 일과 재사용된 온라인 로그 파일을 보관하는 아카이브 로그 파일로 나뉩니다. ARCHIVELOG 모드로 운영 중일 때만 아카이브 로그 파일이 만들어진다. NOARCHIVELOG 모드에서 는 온라인 로그 파일만 사용합니다. NOARCHIVELOG 모드에서는 재사용되어 없어진 로그 파일이 있을 수 있으므로 복구할 때 많은 제약이 따른다. 로그 파일은 데이터베이스 복구할 때 복원된 데이터 파일을 최신 상태로 복구하기 위해, 데이터베이스가 어떻게 변경되어 왔는지에 대한 모든 정보를 기록합니다. 따 라서 데이터 파일과 함께 반드시 백업을 해야 합니다.
플래시백 로그 파일(Flashback Log File) 플래시백 로그 파일은 플래시백 로그를 저장하는 파일입니다. 데이터 파일이 변경되기 직전 내용들을 블 록 단위로 기록하는 파일로써 플래시백 데이터베이스 기능으로 데이터베이스를 가까운 과거로 되돌릴 때 사용합니다. 일반적인 사용 방법과 특징은 로그 파일과 같습니다. ARCHIVELOG 모드로 운영 중이어야만 플래시백 로그를 기록할 수 있습니다. 플래시백 아카이브 로그 파일 을 오래 보관할수록 플래시백 데이터베이스 기능으로 돌아갈 수 있는 과거가 더 오래됩니다. 하지만, 백업 파일 사용하여 복구 시 플래시백 로그 파일은 모두 무용지물이 되기 때문에 일반 아카이브 로그 파일과 다르게 백업 대상이 아닙니다. 일반 로그 파일과 다르게 Tibero Standby Cluster의 동기화 대상이 아닙니다.
백업
백업(Backup)은 여러 가지 유형의 장애로부터 데이터베이스를 보호하는 것을 뜻합니다. 즉, 시스템 장애가 발생했을 때 복구를 하거나 시스템 작동을 유지하기 위한 절차 또는 기법입니다.
Tibero는 데이터베이스를 백업하는 방법을 크게 두 가지로 나누어 수행할 수 있습니다.
논리적 백업 논리적 백업이란 테이블, 인덱스, 시퀀스와 같은 데이터베이스의 논리적 단위를 백업하는 것을 뜻합니다. Tibero에서는 이를 위해 tbExport와 tbImport 유틸리티를 제공하고 있습니다. tbExport와 tbImport에 대한 자 세한 내용은 "Tibero 유틸리티 안내서"를 참고합니다.
물리적 백업 물리적 백업이란 데이터베이스를 구성하는 물리적인 파일을 백업하는 것이며 운영체제에서 파일 복사 명령(COPY)으로 백업하는 것을 뜻합니다. 물리적 백업이 필요한 파일에는 데이터 파일과 아카이브 로그 파일이 있습니다. 온라인 로그 파일은 NOARCHIVELOG 모드에서 데이터베이스 전체를 백업하여 복구할 경우에만 의미가 있습니다.
주의
데이터베이스가 운영 중일 때 운영체제의 파일 복사 명령을 사용하는 것은 안전하지 않으므로 주의 합니다.
백업 종류
다음은 Tibero가 제공하는 백업의 종류입니다.
모드별 백업
데이터베이스를 ARCHIVELOG 모드로 운영할 때와 그렇지 않았을 때 사용할 수 있는 백업 방법이 다릅니다.
ARCHIVELOG 모드
온라인 백업(Online Backup) 또는 Hot Backup이라 합니다.데이터베이스가 운영 중일 때 백업할 수 있음
백업이 가능한 파일은 컨트롤 파일의 생성문과 데이터 파일, 아카이브 로그 파일 등이 있음
복구는 백업된 아카이브 로그 파일의 시점에 따라 데이터 파일의 백업 시점 전으로 복구할 수 있음
NOARCHIVELOG 모드
오프라인 백업(Offline Backup) 또는 Cold Backup이라 함
기본적으로 데이터베이스는 NOARCHIVELOG 모드
데이터베이스를 구성하는 전체 파일은 반드시 Tibero가 정상적으로 종료된 상태에서 백업
백업 때문에 서비스가 중지되면 안 됨
복구는 데이터베이스를 백업받은 시점으로부터 복구할 수 있음
Consistent 백업 Tibero를 정상적으로 종료한 상태에서 백업하는 방법입니다. 실행 예는 “백업 실행”의 "Consistent백업"을 참고합니다.
Inconsistent 백업 Tibero의 데이터베이스가 운영 중일 때 백업하거나 정상적으로 종료되지 않은 상태에서 백업하는 방법 입니다. 실행 예는 “백업 실행”의 "Inconsistent 백업"을 참고합니다. 단, NOARCHIVELOG 모드에서 는 정합성 문제가 발생할 수 있으므로 이 방법은 허용되지 않습니다.
백업 실행
본 절에서는 Tibero가 제공하는 물리적 및 논리적인 백업 방법에 따라 백업을 실행하는 예를 설명합니다.
데이터 파일이나 로그 파일의 경우에는 데이터베이스 상태에 따라서 백업 받는 방법이 다르므로 이를 각 각 데이터베이스가 운영 중인 경우(Inconsistent 백업)와 그렇지 않은 경우(Consistent 백업)로 나누어서 설명합니다.
컨트롤 파일 백업
컨트롤 파일은 물리적인 백업과 논리적인 백업을 모두 지원하지만, Tibero에서는 컨트롤 파일의 논리적인 백업을 추천합니다. 물리적 백업은 제약사항과 사용법이 복잡하기 때문에 실수를 방지하기 위해 보통 사용 하지 않는 것이 좋습니다. 물리적 백업시 데이터의 정합성을 맞춰주기 위해 모든 데이터 파일을 백업한 후 마 지막에 컨트롤 파일을 백업해 주어야 합니다. 데이터베이스의 구조에 변화가 일어난 경우에는 컨트롤 파일 의 생성문을 백업하는 논리적 백업을 사용하는 것을 권장합니다.
다음은 컨트롤 파일을 물리적 백업으로 tibero7/backup 디렉터리에 있는 ctrlfile1.ctl 파일에, 논리적 백업 으로 컨트롤 파일의 생성문을 ctrlfile1.sql 파일에 백업하는 예입니다.
컨트롤 파일의 물리적 백업
[예 1] 컨트롤 파일의 물리적 백업
컨트롤 파일의 논리적 백업
[예 2] 컨트롤 파일의 논리적 백업
생성된 ctrlfile1.sql 파일은 다음과 같은 내용을 포함합니다.
[예 3] 백업된 컨트롤 파일 생성문
RESETLOGS는 컨트롤 파일의 생성문에 지정한 대로 만들어진다. 이 생성문은 트레이스 파일을 생성한 후 RESETLOGS를 필요로 할 경우에 사용하며, RESETLOGS가 필요하지 않은 경우는 NORESETLOGS 로 수정하여 컨트롤 파일을 생성할 때 적용할 수 있습니다.
참고
컨트롤 파일의 생성문에는 임시 파일을 생성하는 내용이 없습니다. 컨트롤 파일을 생성한 후 Tibero를 기 동하면 임시 파일은 존재하지 않습니다. 컨트롤 파일을 새로 생성한 경우 반드시 임시 파일을 추가해야 임시 파일을 이용한 기능을 사용할 수 있습니다.
생성된 컨트롤 파일은 $TB_SID.tip 파일에 경로를 설정합니다. 여러 경로를 명시하여 다중화가 가능합니다.
[예 4] 컨트롤 파일 경로 설정
다음과 같이 MOUNT나 OPEN 상태에서 컨트롤 파일의 목록을 조회하려면 동적 뷰 V$CONTROLFILE를 조회합니다.
[예 5] 컨트롤 파일 조회
참고
컨트롤 파일을 다시 생성하기 위해서는 $TB_SID.tip 파일에 설정된 컨트롤 파일의 위치를 [예 5]의 질의 결과와 동일하게 설정한 후 CREATE CONTROLFILE 문을 실행해야 합니다.
Consistent 백업
본 절에서는 Tibero가 정상적으로 종료한 후에 백업하는 방법을 설명합니다.
Consistent 백업을 실행 하기에 앞서 백업할 컨트롤 파일, 데이터 파일, 로그 파일을 조회합니다.
다음은 MOUNT나 OPEN 상태에서 동적 뷰 V$DATAFILE를 통해 데이터 파일을 조회하는 방법입니다. 여 기서 MOUNT는 Tibero의 인스턴스가 시작된 상태이며, OPEN은 컨트롤 파일에 정의한 모든 파일이 오픈 된 상태를 의미합니다.
[예 6] 데이터 파일의 조회
다음은 온라인 로그 파일을 MOUNT나 OPEN 상태에서 조회하는 방법입니다.
[예 7] 온라인 로그 파일의 조회
온라인 로그 파일은 ARCHIVELOG 모드가 아닌 경우에는 백업하지 않는 것이 좋습니다. ARCHIVELOG 모드 에서는 온라인 로그 파일이 아카이브되기 때문에 아카이브된 파일을 백업하면 안 됩니다. 참고로 아카이브 된 파일은 LOG_ARCHIVE_DEST 초기화 파라미터에 설정된 위치에 저장됩니다.
데이터베이스는 다음과 같이 NORMAL 모드로 종료해야 합니다.
데이터베이스가 정상적으로 종료되면 운영체제별로 제공하는 파일 복사 명령을 사용하여 백업합니다.
Inconsistent 백업
본 절에서는 Tibero가 운영 중일 때 백업하는 방법을 설명합니다.
데이터베이스가 운영 중이면 운영체제의 명령어를 사용해 데이터 파일을 복사하는 것은 안전하지 않습니다. 따라서 다음과 같은 문장을 실행하여 Tibero에 백업의 시작과 종료를 통보해야 합니다.
begin backup과 end backup 문장 사이에는 해당 테이블 스페이스의 변경 사항에 대한 로그가 늘어나기 때문에 데이터베이스에 부담이 가중되게 됩니다. begin backup을 시작한 이후에는 신속하게 백업을 완료하 고 end backup 상태로 복귀시켜야 합니다.
Inconsistent 백업의 전체 과정은 다음과 같습니다.
먼저 백업할 테이블 스페이스를 선정합니다.
[예 8] Inconsistent 백업 - 테이블 스페이스의 선정
백업할 테이블 스페이스에 속한 데이터 파일을 조회한 후 begin backup, end backup 명령어를 사용하 여 백업을 수행합니다. 예를 들어 USER 테이블 스페이스를 백업할 경우를 가정하고 수행합니다.
[예 9] Inconsistent 백업 - begin backup, end backup 명령어의 사용
복구
Tibero를 운영합니다 보면, 예상치 못한 장애로 인해 정상적인 데이터베이스 운영이 어려운 상황이 발생할 수 있습니다. 복구는 장애가 발생하는 경우 복원하는 일련의 과정입니다.
복구를 하려면 백업된 데이터베이스가 있어야 합니다. Tibero는 데이터베이스에서 일어나는 모든 변화를 로 그 파일에 기록합니다. 따라서 백업 이후에 데이터베이스에 일어난 모든 변화에 대해서는 로그를 적용하면 복구할 수 있습니다. 로그 파일에는 커밋되지 않은 트랜잭션이 수정한 데이터도 포함되어 있습니다. 복구할 때 아 카이브 로그 파일과 로그 파일 모두 사용할 수 있습니다.
복구 과정은 다음과 같이 두 가지 경우로 수행할 수 있습니다.
데이터 파일에 기록되지 않는 변화를 로그를 사용하여 적용하는 과정 데이터 파일에 모든 로그의 변화를 기록하는 과정을 통해서 데이터베이스는 안정된 상태가 됩니다. 즉, 데 이터베이스 운영상의 특정 시점까지 모든 작업이 반영되고 그 이후의 변화는 발생하지 않아야 합니다. 데 이터베이스에 정상적인 복구가 이루어져 안정된 상태가 되어야만 기동할 수 있습니다.
커밋되지 않는 데이터로 복구하는 과정 데이터베이스를 종료할 때 커밋하지 않은 트랜잭션이 수정한 내용으로 복구하는 과정입니다.
부트 모드별 복구
Tibero는 부트 모드별로 발생되는 작업을 복구 측면에서 보면 다음과 같습니다.
NOMOUNT 모드 NOMOUNT 모드로는 언제나 복구할 수 있습니다. 이 모드에서는 데이터베이스와 컨트롤 파일을 생성할 수 있습니다. MOUNT 모드로 동작하기 위해서는 컨트롤 파일이 있어야 합니다. 컨트롤 파일이 없거나 컨트롤 파 일에 장애가 발생한 경우에는 NOMOUNT 모드로 동작하며 컨트롤 파일을 생성하면 MOUNT 모드로 동작할 수 있습니다.
MOUNT 모드 MOUNT 모드에서는 데이터 파일, 온라인 로그 파일, 컨트롤 파일 사이의 상태를 검사하여 Tibero를 기 동할 준비를 합니다. 세 파일이 모두 최신 상태이면 OPEN 모드로 동작할 수 있습니다. 파일에 물리적인 장애 가 발생하였거나, 복원된 파일이라면 미디어 복구가 필요하며 MOUNT 모드로 동작합니다. MOUNT 모드 에서는 제한된 뷰의 조회가 가능하고, 미디어 복구를 수행할 수 있습니다.
OPEN 모드 Tibero의 데이터 파일, 온라인 로그 파일, 컨트롤 파일이 일관성을 유지할 때에만 OPEN 모드로 동작할 수 있습니다. OPEN 모드에서 Tibero는 세 파일을 열고 정상으로 동작합니다. 일반 사용자는 데이터베이스를 이용할 수 있습니다. 오프라인 상태인 테이블 스페이스에 사용자가 접근하려면 우선 해당 테이블 스페이스 를 온라인 상태로 전환해야 합니다. 이때 다른 파일들과 일관성을 유지하기 위해 해당 테이블 스페이스에 온라인 미디어 복구를 수행해야 합니다.
파손 복구
파손 복구(Crash Recovery)는 Tibero를 운영하는 중에 정전, 시스템 이상, 강제 종료 등으로 데이터베이 스가 비정상적으로 종료되었을 때 사용자의 명령 없이 자동으로 복구되는 것을 의미합니다. 복구가 완료되 면 Tibero가 정상적으로 동작합니다.
파손 복구는 온라인 로그 파일의 내용 중 아직 데이터 파일에 반영되지 않은 부분을 기록하여 Tibero가 비 정상적으로 종료되기 직전에 운영 시점의 상태로 복구하는 과정과 이러한 상태로 복구된 시점에서 커밋 되지 않은 트랜잭션이 발생시킨 변화를 되돌리는 과정으로 나눌 수 있습니다.
파손 복구의 모든 과정은 파일의 손상이 없으면 DBA의 도움 없이 자동으로 이루어집니다.
평균 파손 복구 시간 설정 Tibero는 평균 파손 복구 시간을 설정 할수 있는 기능(Mean Crash Recovery Time)을 제공하고 있습니다. Mean Crash Recovery Time(이하 MCRT)은 파손 복구시 필요한 I/O 횟수를 통제함으로써 평균 파손 복 구 시간을 조절합니다.
MCRT는 다음 파라미터를 설정해서 조절할 수 있습니다.
_MCRT_TARGET
평균 파손 복구 시간을 설정(기본값: 1800, 단위: 초)
미디어 복구
Tibero를 구성하는 파일이 물리적인 손상이나 정상적으로 동작할 수 없는 경우가 발생할 수 있습니다. 이러한 경우 데이터베이스가 정상적으로 동작할 수 있도록 복구하는 과정이 미디어 복구(Media Recovery)입니다.
미디어 복구 과정은 자동으로 이루어지지 않습니다. DBA가 상황을 파악해서 필요한 과정을 지시하는 일련 의 작업이 필요합니다. 복구 완료시점을 오류가 발생하기 이전의 가장 최근 시점까지로 할지, 과거의 특정시점까지로 할지 여부에 따라서 완전 복구(Complete Recovery)와 불완전 복구(Incomplete Recovery)로 구분됩니다.
완전 복구
온라인 로그 파일의 가장 최근 로그까지 모두 반영하는 미디어 복구입니다.
불완전 복구
온라인 로그 파일의 최근까지가 아닌 그 이전의 특정 시점까지 복구하는 것을 말합니다. 불완전 복구 후에는 반드시 RESETLOGS 모드로 Tibero를 기동해야 합니다. RESETLOGS는 온라인 로그 파일을 초기화하는 것이며, 현재 온라인 로그 파일로 데이터베이스를 시작하지 않을 때 사용합니다.
RESETLOGS가 필요한 경우는 다음과 같습니다.
불완전 미디어 복구를 한 경우
RESETLOGS로 컨트롤 파일을 생성한 경우
RESETLOGS로 시작하면 새로운 데이터베이스가 만들어진 것과 같습니다. RESETLOGS 이전의 데이터 파 일, 로그 파일과 RESETLOGS 이후의 파일은 서로 호환되지 않습니다. RESETLOGS 이전의 백업 파일이나 로그 파일을 이용하여 RESETLOGS 이후로 복구할 수 없습니다. 또한 RESETLOGS 이후의 파일을 RESETLOGS 이전 상태로 불완전 복구를 하는 것도 불가능합니다. 따라서 RESETLOGS 모드로 기동한 경우에는 반드시 새로 백업을 하기를 권장합니다.
RESETLOGS로 데이터베이스를 기동하는 방법은 다음과 같습니다.
[예 10] RESETLOGS를 이용한 데이터베이스의 기동
미디어 복구 과정은 MOUNT 모드에서만 이루어진다. 백업된 파일을 사용하여 오류가 발생한 파일을 복 원하는 과정과 복원된 파일을 백업한 시점으로부터 최근 또는 특정 시점까지 반영되지 않은 변화를 로그 파일을 사용하여 복구하는 과정으로 나눌 수 있습니다. 단순한 복원 과정만으로는 Tibero의 정상적인 운영이 불가능합니다.
미디어 복구를 위해 장애가 발생한 파일을 찾아 복구해야 합니다. 이를 위해 다음과 같은 뷰를 제공합니다.
V$LOGFILE
V$CONTROLFILE
V$LOG
V$RECOVER_FILE
V$RECOVERY_FILE_STATUS
미디어 복구는 로그 파일을 하나씩 데이터베이스에 순서대로 반영하여 진행합니다. 데이터베이스는 현재 복구에 필요한 로그 파일만을 반영할 수 있습니다. 현재 필요한 로그 파일을 찾기 위해 시퀀스 번호가 사용된 다. 시퀀스 번호는 데이터베이스가 생성된 이후로 만들어진 로그 파일의 일련 번호이며, 모든 로그 파일은 하나의 유일한 시퀀스 번호를 갖습니다다. 시퀀스 번호가 큰 로그 파일이 최근 로그 파일입니다. 시퀀스 번호는 아카이브 로그 파일의 경우 파일 이름을 통해 알 수 있고, 온라인 로그 파일의 경우 V$LOG 뷰를 통해 알 수 있습니다.
온라인 미디어 복구
Tibero를 운영하는 도중에 일부 데이터 파일이 물리적으로 손상되거나 정상적으로 동작할 수 없는 경우가 발생할 수 있습니다. 이러한 경우에 OPEN 모드에서 해당 데이터 파일이 포함된 테이블 스페이스만 미디어 복 구를 수행할 수 있습니다. 이것이 온라인 미디어 복구(Online Media Recovery)입니다. 온라인 미디어 복구는 완 전 복구만 가능합니다.
스냅샷 데이터베이스 복구
Tibero에서 공식적으로 제공하는 백업 방법이 아닌 스토리지 스냅샷 솔루션을 이용하여 데이터베이스를 백업한 경우 이를 복구하기 위해서는 아래와 같이 스냅샷 데이터베이스 전용 복구 DDL을 이용하여 복구 를 수행해야 합니다.
스냅샷 데이터베이스 복구의 경우 복구 관리자를 통한 복구는 현재 지원하지 않습니다.
Clone DB 생성 및 복구
테스트 및 여러 목적을 위해 Tibero 백업을 이용하여 Clone DB를 구축할 수 있습니다. Full Backup을 통해서 운영 DB와 동일하게 구축할 수 있으며, 일부 Tablespace에 대한 Backup을 통해 부분적으로도 구축할 수 있습니다.
Clone DB 구축 시, 다음과 같이 진행합니다.
운영 DB에서 Backup 진행
Clone DB 구축하기 위한 Backup에는 아래 항목이 포함되어야 합니다.
Tablespace에 대한 Backup
Archive Logfile
Control File Trace Backup
Clone DB를 생성할 위치에 Backup을 restore
Control File 생성문 수정 Clone DB 생성에 필요 없는 Tablespace을 Control File 생성문의 DATAFILE 항목에서 제외합니다. 일반 적으로 Backup에 온라인 로그파일이 포함되지 않으므로 RESETLOGS 옵션으로 수정합니다.
NOMOUNT mode로 기동 후, Control File 재생성
미디어 복구 진행 V$ARCHIVE_DEST_FILES를 통해 restore 된 Archive Logfile 들을 조회하여 복구 목표 시점 확인 후, 불완전 복구 진행합니다.
Control File과 Data Dictionary 간 정합성 확인 DDL 수행
Clone DB 생성에 필요 없는 Tablespace에 대해 offline immediate DDL 수행
DB down 및 RESETLOGS 기동
Clone DB 생성에 필요없는 Tablespace에 대해 drop DDL 수행
복구 관리자
Tibero는 다양한 백업 및 복구 시나리오를 제공합니다. 숙련된 데이터베이스 관리자라면 상황에 맞는 적절 한 방법을 선택하고 활용할 수 있을 것입니다. 허나 너무 다양한 기능을 제공함으로써 오히려 사용자에게 혼 란을 줄 수도 있습니다. 이러한 면을 보완하기 위하여 Tibero는 복구 관리자(이하 RMGR)를 제공합니다.
기본 기능
RMGR은 다양한 백업/복구 시나리오를 지원하도록 구성되어 있습니다. Tibero에서 제공되는 RMGR의 기능 은 다음과 같습니다.
Online Full Backup Tibero 데이터베이스에 속한 전체 데이터 파일을 온라인 백업합니다. 온라인 백업을 위해서는 데이터베이 스가 ARCHIVELOG 모드이여야 합니다. RMGR은 자동으로 데이터베이스의 Begin Backup 기능을 사용 하여 모든 테이블 스페이스를 Hot Backup 상태로 만들고 백업을 진행합니다. 백업을 완료하면 데이터베이스의 End Backup 기능을 사용하여 모든 테이블 스페이스를 Hot Backup 상태로부터 해제합니다. 명령과 옵션들을 통해 백업이 진행/완료되어 하나의 Backup Set(백업 셋)이 생성 되면, V$BACKUP_SET을 통해 진행 상황 및 해당 Backup Set에 사용한 옵션들을 확인할 수 있습니다.
Incremental Backup RMGR를 통해 온라인 백업을 받았으면 이를 이용하여 Incremental Backup을 할 수 있습니다. Incremental Backup이란 백업을 받을 때 전체 파일을 받는 것이 아니라 이전 백업과의 차이만을 기록하는 방식으로 백업에 소모되는 디스크 공간을 획기적으로 줄일 수 있습니다. Incremental Backup을 하려면 이전에 RMGR를 통해 Online Full Backup을 받았어야 합니다. 현재 데이터 베이스와 백업본과의 차이를 구하여 백업 파일을 만든다. 이러한 기능은 RMGR를 통해서만 사용할 수 있습니다.
Block Change Tracking Incremental Backup은 이전 백업과 현재 운영 중인 데이터 파일 간의 변경된 사항만을 기록하여야 하기 때문에 전체 데이터 파일을 스캔하여 백업본과의 차이점을 구하는 동작을 수행합니다. 이러한 동작은 데 이터 파일이 큰 경우에는 데이터 파일을 모두 스캔하는 오버헤드가 크기 때문에 백업되는 파일의 용량 은 적지만 시간이 오래 걸리는 단점이 있습니다. 이런 단점을 보완하기 위해 Tibero 서버가 마지막 백업시점 이후의 데이터 파일의 변화 내역을 기록하고 백업할 때 활용합니다. 이 기능은 어떤 블록만 백업하면 될지 추적하기가 쉽기 때문에 Incremental Backup의 수행속도가 비약적으로 빨라질 수 있습니다. 이를 위해 RMGR 및 Tibero 서버는 Block Change Tracking(BCT)기능을 제공합니다.
BCT 기능을 사용하기 위해서는 Tibero 서버 tip 파일에 BCT 관련 파라미터를 설정하고 BCT 기능을 컨 트롤하는 DDL을 수행해야 하며, LGWR AIO 기능과는 호환되지 않습니다.
[예 11] Tibero 서버 tip 파일에 BCT 설정
[예 12] BCT 기능 사용
RMGR은 Incremental Backup을 수행할 때 이 BCT 파일을 사용하여 백업할 블록들의 리스트를 빠른 시 간내에 탐색하여 백업을 효과적으로 수행할 수 있습니다. 해당 파일이 운영 중에 삭제되거나 장애가 생길 때 에 Tibero 서버는 자동적으로 BCT 기능을 중지하며 사용자는 다시 BCT 기능을 DDL로 수행해야 합니다.
수동으로 BCT 기능을 중지하기 위해서는 다음의 DDL을 수행합니다.
[예 13] BCT 기능 해제
RMGR은 Tibero 서버에 현재 BCT 기능이 켜져있는지를 질의하여 이전 백업부터의 블록 변화가 BCT 파일에 온전히 기록이 되었는지 확인한 후 유효한 BCT 파일이 존재할 때만 BCT를 이용한 Incremental Backup을 수행합니다. Tibero 서버는 Incremental Backup이 끝나면 백업이 끝난 시점부터 변경된 사항들 을 BCT 파일에 기록하게 됩니다.
Automatic Recovery RMGR을 이용하여 만들어진 백업본을 이용하여 자동 복구를 진행합니다. 백업 정보는 컨트롤 파일에 저 장이 되어있습니다. 컨트롤 파일에 저장된 정보를 기반으로 Online Full Backup/Incremental Backup 정보를 분석하여 자동으로 Merge 후 복구를 진행합니다. 컨트롤 파일이 접근 불가능할때에는 백업된 컨트롤 파 일을 이용하여 복구를 진행합니다. 단, 이때에는 특정 옵션을 사용하여 백업이 존재하는 백업 경로를 명시 해주어야 합니다.
주의
TAC 환경에서 RMGR을 이용한 복구를 진행하기 위해서는 구성 노드 중 한 개의 노드만 떠있는 상황 에서 복구를 진행해야 합니다.
Datafile/Tablespace 단위 백업 및 복구 전체 데이터베이스를 백업/복구하는 대신에 필요한 데이터 파일 또는 테이블 스페이스만 대상으로 백 업/복구 작업을 수행할 수 있습니다. 복구할 때에는 데이터 파일 또는 테이블 스페이스는 각 백업 파일들을 가져온 후 복구 자체는 전체 복구로 MOUNT 모드에서 진행됩니다.
Delete Backup Set RMGR을 이용하여 컨트롤 파일에 등록된 Backup Set(백업 셋)을 삭제할 수 있습니다. 삭제 대상이 되는 Target Backup Set은 Backup Set ID를 직접 지정할 수 있으며(--bakcup-set 옵션), 특정 시간을 명시하 여 특정 시간 이전에 생성된 Backup Set들을 모두 지정할 수 있습니다(--beforetime 옵션). 삭제하고자 하는 Backup Set이 존재하는 백업 경로는 컨트롤 파일을 참조하여 결정하므로, 백업이 이 루어진 이후에 백업 경로가 변경된 경우에는 삭제하고자 하는 Backup Set이 존재하는 백업 경로(-o 옵 션)를 명시해주어야 합니다. 만약 컨트롤 파일에 등록된 Backup Set을 사용자가 수동으로 삭제하였거나, 잘못된 백업 경로를 명시하여 백업 경로에서 삭제 대상으로 지정된 Backup Set을 찾을 수 없는 경우에 는 컨트롤 파일에 등록된 Backup Set Entry만을 삭제하고 종료할 수 있습니다(--cf-only 옵션).
Standby Backup RMGR을 이용하여 Tibero Standby Cluster 환경의 standby에서 백업을 진행할 수 있습니다. Standby의 백업 파일을 이용하여 standby, primary 모두 복구가 가능합니다. Standby 환경에서 백업을 진행할 때는 다음과 같은 제약사항이 추가됩니다.
– --for-standby 옵션은 사용할 수 없습니다.
– -w, --with-archivelog 옵션을 사용하려면 primary 접속에 필요한 정보를 tbdsn.tbr에 설정한 후에 primary의 SID를 $TB_SID.tip 파일에 초기화 파라미터 RMGR_PRIMARY_SID로 설정해야 합니다.
[예 14] Primary SID 설정
복구 관리자 옵션
RMGR은 셸 명령으로 실행되며 다양한 옵션을 지정하여 원하는 기능을 사용할 수 있습니다.
backup
RMGR를 통해 백업을 진행하여 Backup Set을 생성
recover
RMGR로 백업한 Backup Set을 원하는 경로에 복원하여 복구를 진행
delete
RMGR로 받아놓은 백업본 중 사용자 입력으로 주어진 조건에 맞는 Backup Set을 삭제
--userid
데이터베이스에 접속할 사용자명과 패스워드 및 SID를 아래와 같은 형식으로 지정
--userid USERID[[/PASSWD][@SID]]화면상에 비밀번호 노출을 원치 않을 때에는 비밀번호를 공백으로 입력한 후 비밀번호를 입력하라는 문구가 나오면 비공개로 번호를 입력할 수 있음
--userid USERID/[@SID]OS 인증을 받은 계정으로 로그인하는 경우 Userid와 Passwd를 입력하지 않아도 로그인 가능(단, 현재는 backup과 delete 기능만 가능)
--userid /
--help
RMGR의 옵션 사용법을 출력
--interval
RMGR 백업/복구 진행률을 확인하여 출력해주는 실시간 시간 간격을 초 단위로 조절
기본값은 1 초이며, 최소 0.01 초까지 설정 가능
0으로 설정하는 경우 실 시간 진행률을 확인하지 않음
-v, --verbose
RMGR 백업/복구를 진행하는 경우 각 데이터 파일마다의 절대 경로를 출력
-s, --silent
RMGR 백업/복구를 진행하는 경우 각 데이터 파일마다의 진행률을 출력하지 않음
-l, --log-level
클라이언트 로그 RMGR 로그(tbrmgr_trace.log)의 기록 레벨을 설정
레벨은 1부터 5까지 있으며 숫자가 커질 수록 더 자세히 기록됨
기본 레벨은 0
-L
tbrmgr_trace.log의 기록될 위치를 지정
기본 경로는 $TB_HOME/client/tbrmgr_log/
-o
백업, 복구 및 삭제에 사용될 디렉터리 경로를 지정
백업할 때 옵션을 사용하지 않을 경우 RMGR_BACKUP_DEST가 기본 경로로 설정
복구의 경우 옵션을 사용하지 않으면 각 Backup Set마다 백업된 경로를 자동으로 찾아감
옵션을 사용할 경우 모든 Full/Incremental Backup Set 및 아카이브 로그 백업셋이 해당 경로에 있어야
콤마(,)로 구분된 다중경로를 16개까지 지원
백업을 제외한 복구 및 삭제에서 다중경로 옵션을 사용할 경우, 명시된 디렉터리 경로 모두 유효해야 함
tbrmgr backup -o /backup/ tbrmgr backup -o /backup1/,/backup2/아카이브 로그의 경우 다중경로 삭제 기능을 지원하지 않음
-n
NetBackup을 사용하는 경우 백업/복구에 사용할 NetBackup 경로를 지정
백업할 때 옵션을 사용하지 않을 경우 RMGR_NBU_BACKUP_DEST가 기본 경로로 설정됨
이와 동시에 -o 옵션과 동일하며, 복구/삭제까지도 동일한 옵션으로 동시에 사용할 수 있음
USE_NBU_FOR_BACKUPSET 파라미터를 Y로 사용할 경우 기본 백업/경로는 로컬이 아닌 NetBackup 경로가 우선
-i, --incremental
가장 최신 백업에 대한 Incremental backup을 수행
-c, --cumulative
바로 이전 Incremental backup에 대한 Incremental backup을 수행
-w, --with-archivelog
백업/복구를 수행할 때 backup을 복구하기 위한 아카이브 로그 파일도 함께 백업/복원
기본적으로 클러스터 환경에서는 모든 Instance들이 Shared disk로 모두 같은 LOG_ARCHIVE_DEST를 공유해야 정상적으로 동작
이는 Active stroage 를 사용하는 경우도 마찬가지
NetBackup을 사용하는 경우 USE_NBU_FOR_ARCHIVELOG=Y인 경우엔 옵션 사용 불가함
백업된 아카이브 로그 파일은 다음의 형식으로 관리됨
bkl_<BACKUPSET#>_t<THREAD#>-r<RESETLOGS_TSN>-s<SEQUENCE#>.arc예를 들어 BACKUPSET#는 1, THREAD#는 0, RESETLOGS TSN는 0, SEQE UNCE#는 1인 경우 파일명은 'bkl_1_t0-r0-s1.arc'이 됨
-a, --archive-only
가장 최근에 백업한 아카이브 로그 백업 셋 이후에 생성된 아카이브 로그 파일들을 모두 백업
복구할 때 필요한 경우 자동으로 함께 사용됨
tbrmgr backup --archive-only특정 Redo 스레드의 아카이브 로그의 특정 시퀀스를 지정하여 해당 시퀀스의 시작부터 최선까지의 아카이브 로그 파일들을 백업할 수도 있음(--thread, --from-seq 옵션)
tbrmgr backup --archive-only --thread <THREAD#> --from-seq <SEQUENCE#>NetBackup을 사용하는 경우 USE_NBU_FOR_ARCHIVELOG=Y인 경우에 옵션 사용 불가
-p, --parallel
복구 전용 Process의 스레드를 각자 하나의 데이터 파일을 담당하는 데, 스레드 개수를 명시하여 여러 스레드를 할당하여 병렬적으로 백업/복구를 수행
기본값은 10이며 최대값은 16
이는 (RECO_PROC_WTHR_CNT - _CACHE_RECO_DOP )/3 값으로 조정할 수 있음
tbrmgr backup --parallel <THREAD_COUNT>
-u, --skip-unused
아직 사용되지 않은 깨끗한 블록은 백업하지 않음
보통 백업에 소요되는 시간은 늘어나나 생성되는 파일 크기를 줄일 수 있음
-c, --compress
백업을 수행할 때 데이터를 압축하여 저장
LOW, MEDIUM, BASIC, HIGH로 옵션을 추가하여 압축 정도를 지정할 수 있음
옵션을 지정하지 않으면 BASIC 옵션이 자동으로 지정됨
LOW>MEDIUM>BASIC>HIGH 순으로 압축속도가 빠르며, HIGH>BASIC>MEDIUM>LOW 순으로 압축률이 높음
tbrmgr backup --compress [LOW|MEDIUM|BASIC|HIGH]
-d, --datafile
백업/복구할 대상 데이터 파일을 지정
지정할 때에는 데이터 파일 번호를 명시해야 하며, 콤마(,)를 사용하여 여러 개를 명시할 수 있음
tbrmgr backup --datafile <DATAFILE#1,DATAFILE#2,...>
-t, --tablespace
백업/복구할 대상 테이블 스페이스를 지정
지정할 때에는 테이블 스페이스 이름을 명시해야 하며, 콤마(,)를 사용하여 여러개를 명시할 수 있음
tbrmgr backup --tablespace <TABLESPACE_NAME1,TABLESPCE_NAME2,...>
-T, --skip-tablespace
백업/복구 대상에서 제외할 테이블 스페이스를 지정
지정할 때에는 테이블 스페이스 이름을 명시해야 하며, 콤마(,)를 사용하여 여러 개를 명시할 수 있음
tbrmgr backup --skip-tablespace <TABLESPACE_NAME1,TABLESPACE_NAME2,...>
--skip-readonly
백업/복구 대상에서 Read only 테이블 스페이스들은 제외
--skip-offline
백업/복구 대상에서 Offline 테이블 스페이스들은 제외
--untiltime
시간기반 불완전 복구를 수행
옵션에서 지정한 시간까지 변경된 내용만 복구
시간은 YYYYMMDDHH24MISS의 형식
tbrmgr recover --untiltime <YYYYMMDDHH24MISS>
--untilchange
변경 기반 불완전 복구를 수행
옵션에서 지정한 TSN까지 변경된 내용만 복구됨
tbrmgr recover --untilchange <TSN>
--from-seq
해당 옵션 사용하여 아카이브 로그의 특정 시퀀스를 지정할 수 있고, 해당 시퀀스부터 마지막 시퀀스, 또는 특정 시퀀스까지 백업/복구(--to-seq 옵션)
필수로 Redo 스레드를 지정해야 함(--thread 옵션)
tbrmgr backup --thread <THREAD> --from-seq <SEQUENCE#>
--to-seq
해당 옵션 사용하여 아카이브 로그의 특정 시퀀스를 지정할 수 있고, 해당 시퀀스까지 모두 복구
무조건 Redo 스레드를 지정해주고(--thread 옵션), 구간을 정해주어야 함 (--from-seq 옵션).
tbrmgr recover --thread <THREAD> --from-seq <SEQUENCE#> --to-seq <SEQUENCE#>
--thread
아카이브 로그 백업/복구할 때 Redo 스레드를 지정
--arc-dest-force
아카이브 로그 백업/복구할 때 대상 구간에 임의의 아카이브 로그 파일을 찾을 수 없어도 실패하지 않고 진행되게 함
--delete-original
아카이브 로그 백업/복구 후 백업 본이 아닌 원본 파일들을 삭제
--with-password-file
MOUNT 모드에서 SYS 계정 로그인에 필요한 password file을 함께 백업/복구
--no-rollback
백업 도중 취소/실패하는 경우 기존에 백업한 파일들을 롤백하지 않고 보존
--continue
백업 파일을 가져오지 않고 복구만 진행
주로 아카이브 로그 파일들을 소량씩 가져오면서 완전 복구를 단계적으로 하려고 할 때 사용할 수 있음
MOUNT 모드에서만 사용 가능
--for-standby
Standby 구축을 위한 백업/복구를 진행
모든 데이터 파일들과 복구에 필요한 아카이브 로그 파일, 그리고 온라인 Redo 로그 파일들까지 백업/복구
클러스터 환경에 대한 제약 사항이 --with-archivelog와 동일
NetBackup 연동을 지원하지 않음
--at-standby
Standby에서의 복구를 진행
--for-standby와 다르게 standby에서 별개의 Media recovery를 진행해야 할 때 사용됨
--recover-to
Backup Set로 지정한 특정 경로에 가져온 후 복구를 수행
데이터베이스와 컨트롤 파일이 알고 있는 파일들의 경로도 함께 변경
Active storage 경로들도 가능
tbrmgr recover --recover-to <NEW_DIRECTORY>
--restore-only
대상 백업 데이터 파일들을 가져온 후 복구는 수행하지 않음
MOUNT 또는 NORMAL 모드에서 사용 가능하며, NORMAL 모드에서는 무조건 Offline 테이블 스페이스들을 지정해야 함
tbrmgr recover --restore-only
--restore-archive-only
대상 백업 아카이브 로그 파일들을 가져온 후 복구는 수행하지 않음
무조건 --from-seq, --to-seq, --thread 옵션을 함께 사용해야 함
MOUNT 또는 NORMAL 모드에서 사용 가능
NetBackup을 사용하는 경우 USE_NBU_FOR_ARCHIVELOG=Y인 경우에 옵션 사용이 불가능
--restore-incremental-only
대상 incremental backup 파일들을 가져와서 대응되는 데이터파일과 병합
단, incremental backup이 백업될 당시 기준으로 한 full backup 데이터파일 상태여야 함
이 기능은 주로 테스트 장비에서 full backup set으로 resetlogs 부팅하여 테스트 후, flashback database로 full backup set 상태로 다시 돌아오고 나서 사용됨
즉, 해당 상태에서 운영기의 incremental backup을 병합하여 테스트 환경이 운영기를 간편히 동기화 할 수 있게 함
MOUNT 또는 NORMAL 모드에서 사용 가능
--incrementally-updated
존재하는 full backup set을 해당 backup set을 base로 하는 incremental/cumulative backup set로 incremental update
즉, 존재하는 full backup set과 incremental/cumulative backup set을 병합하여 하나의 full backup set으로 만드는 기능
이를 통해 저장 공간 최적 및 추후 복구 시간 축소의 장점을 가짐
--wallet
암호화된 테이블 스페이스에 접근하기 위한 인증작업을 수행
사용자가 명시한 PASSWORD를 통해 WALLET을 열고 복구를 시작
tbrmgr recover --wallet <WALLET_PASSWORD>
-b, --backup-set
지정한 Backup Set을 삭제하거나 복구 시에는 지정한 Backup Set부터 탐색하여 가져옴
--archivelog
컨트롤 파일에 기록된 아카이브 로그들을 삭제하고, 사용자가 경로를 지정한 경우에도 그 경로에 있는 아카이브 로그들을 삭제
--beforetime, --beforechange 혹은 --sent-to-standby 옵션과 같이 사용되어야 함
--beforetime
명시한 시점 이전의 Backup Set 혹은 아카이브 로그들을 삭제
시간은 YYYYMMDDHH24MISS의 형식
tbrmgr delete --beforetime <YYYYMMDDHH24MISS>
--beforechange
명시한 TSN 이전의 아카이브 로그들을 삭제
--redundancy
명시한 숫자만큼의 최신 full backup set 혹은 전체 backup set들을 삭제
--recovery-window
명시한 숫자만큼의 일수보다 오래된 backup set들을 삭제
--cf-only
실제 Backup Set 혹은 아카이브 로그의 파일을 가져오면서 데이터 파일 및 컨트롤 파일이 알고 있는 경로를 변경하지만, 삭제는 하지 않음
즉 사용자 수준으로 이용하여 백업/복구를 이용한 잘못된 경로 변경을 되돌릴 시점에서 사용 가능
--sent-to-standby
Standby로 전송이 완료된 아카이브 로그들을 삭제
--archivelog 옵션과 같이 사용되어야 하며, --beforetime 또는 --beforechange와 같이 사용될 수 있음
--switch
데이터베이스의 파일이름을 Backup Set의 백업 파일의 이름으로 바꿔줌
테이블 스페이스를 지정할 수 있음
NetBackup을 사용한 Backup Set에 대해서는 지원하지 않음
tbrmgr recover --switch
--no-image-logging
백업을 수행할 때 기존의 image logging 방식이 아닌 block consistency check 방식을 이용
standby에서 백업을 수행할 경우 옵션 사용 여부 상관없이 block consistency check 방식으로 진행
백업에 소요되는 시간은 늘어나지만 백업하는 동안 발생하는 온라인 redo 로그의 크기는 줄어듬
복구 관리자를 이용한 백업 및 복구 예제
본 절에서는 다음의 백업/복구 시나리오를 통해서 RMGR을 이용한 백업/복구를 설명합니다.
Online Full Backup 시나리오
Compress 옵션과 Skip Unused 옵션을 적용한 Online Full Backup 시나리오
With Archive Log 옵션을 적용한 Online Full Backup 시나리오
With Archive Log 옵션을 적용한 Incremental Backup 시나리오
Online Full Backup을 이용한 복구 시나리오
Online Full Backup과 Archive Log Backup을 이용한 복구 시나리오
Online Full Backup과 Incremental Backup을 이용한 복구 시나리오
Tablespace 기반 복구 시나리오
주의
RMGR의 Online(Full / Incremental) Backup을 통해 생성된 Backup Set을 이용하여 복구를 수행하 기 위해서는 Archive Log File이 반드시 필요합니다. 따라서 Archive Log File이 유실될 경우에 대비하 여 Online(Full / Incremental) Backup의 경우 Archive Log File도 함께 Backup (--with-archivelog / -- archive-only 옵션) 해두는 것이 바람직합니다.
또한, TAC 환경에서는 RMGR을 이용한 Archive Log Backup을 위해서는 모든 노드들의 Archive Log File에 접근할 수 있도록, 모든 노드들은 공유 디스크 의 동일한 LOG_ARCHIVE_DEST에 Archive Log File을 저장해야합니다.
RMGR은 대부분의 과정을 자동으로 진행하기 때문에 사용자가 실행 명령을 통해 작업을 명시해준 이후 에는 특별히 관리해야 할 사항이 없습니다. RMGR이 작업을 진행하는 동안에는 작업의 진행 과정을 살펴볼 수 있습니다.
RMGR을 통해 Backup을 진행한 이후에는 V$BACKUP_SET을 통해 Backup Set 정보를 조회할 수 있으 며, V$BACKUP_ARCHIVED_LOG를 통해 Archive Log Backup 정보를 조회할 수 있습니다. V$BACK UP_SET_TABLESPACE를 조회하면 각 Backup Set에 대한 테이블 스페이스 정보를 확인할 수 있습니다.
참고
데이터 파일이 Raw Device 파일 및 Tibero Active Storage인 경우에도 RMGR을 이용한 백업 및 복구가 가능합니다. 단, Active Storage를 사용할 때 미리 Active Storage Instance를 설정 및 부팅을 해야 합니다.
Online Full Backup 시나리오
RMGR을 이용하여 임의의 백업 경로에서 Online Full Backup을 수행할 수 있으며(-o 옵션), 백업 경로를 명시하지 않은 경우에는 RMGR_BACKUP_DEST가 기본 dest로 설정됩니다.
[예 15] Online Full Backup 시나리오
Compress 옵션과 Skip Unused 옵션을 적용한 Online Full Backup 시나리오
데이터를 압축하여 Backup Set을 생성하는 Compress(-c) 옵션과 실제로 사용되지 않은 블록을 백업 대상 에서 제외하는 Skip Unused(-u) 옵션을 함께 적용하여 Online Full Backup을 수행할 수 있습니다.
[예 16] Compress 옵션과 Skip Unused 옵션을 적용한 Online Full Backup 시나리오
With Archive Log 옵션을 적용한 Online Full Backup 시나리오
RMGR을 이용한 Backup을 수행하는 경우 with Archive Log(--with-archivelog) 옵션을 적용함으로써, 백업 경로에 데이터 파일에 대한 백업과 함께 Archive Log Backup을 생성할 수 있습니다. Online Backup을 이용하 여 복구를 수행하기 위해서는 Archive Log가 반드시 필요하므로, Archive Log Backup을 생성함으로써 원 본 Archive Log File이 유실되는 경우에도 정상적으로 복구를 진행할 수 있습니다.
백업된 아카이브 로그 파일은 다음의 형식으로 관리됩니다.
예를 들어 BACKUPSET#는 1, THREAD#는 0, RESETLOGS TSN는 0, SEQUENCE#는 1인 경우 파일명은 'bkl_1_t0-r0-s1.arc'이 됩니다.
V$BACKUP_SET을 조회함으로써 각 Backup Set에 Archive Log Backup이 존재하는지 확인할 수 있으며, V$BACKUP_ARCHIVED_LOG를 조회함으로써 Archive Log Backup의 정보를 확인할 수 있습니다.
[예 17] With Archive Log 옵션을 적용한 Online Full Backup 시나리오
With Archive Log 옵션을 적용한 Incremental Backup 시나리오
앞서 Online Full Backup을 통해 생성된 Full Backup Set이 최소 1개 이상 존재하는 경우에는 가장 최신의 Backup Set과 현재 상태를 비교하여 변경사항만을 백업하는 Incremental Backup을 수행할 수 있습니다. 변경 사항만을 백업하므로 Full Backup Set에 비해 Backup Set의 Size를 획기적으로 줄일 수 있지만, 앞선 Backup Set이 유실되어 비교 대상이 사라지게 되면 Backup Set을 데이터베이스 복구에 사용할 수 없는 위험성이 존재합니다.
V$BACKUP_SET을 조회함으로써 각 Backup Set이 Incremental Backup Set인지 확인할 수 있으며, Incre mental Backup의 경우 비교 대상이 되는 Backup Set(Base Set)의 ID를 확인할 수 있습니다. Full Backup Set 의 경우 Base Set이 존재하지 않으므로 Base Set ID가 0으로 표기됩니다.
[예 18] With Archive Log 옵션을 적용한 Incremental Backup 시나리오
Online Full Backup을 이용한 복구 시나리오
RMGR은 Online Full Backup을 통해 생성된 Backup Set을 이용하여 복구를 수행할 수 있습니다. 아래 예제는 Backup Set에 Archive Log Backup이 존재하지 않는 경우로, 이 경우에는 원본 Archive Log File을 가지고 있어야 복구를 진행할 수 있습니다.
[예 19] Online Full Backup을 이용한 복구 시나리오
Online Full Backup과 Archive Log Backup을 이용한 복구 시나리오
RMGR은 Online Full Backup을 통해 생성된 Backup Set을 이용하여 데이터베이스 복구를 수행할 수 있 다. 아래 예제는 원본 Archive Log File이 유실된 경우로, with Archive Log(--with-archivelog) 옵션을 통해 Archive Log Backup을 Restore하는 경우에는 정상적으로 복구가 진행되지만, with Archive Log(--with- archivelog) 옵션을 적용하지 않고 복구를 수행하는 경우에는 복구에 실패하는 것을 확인할 수 있습니다.
[예 20] Online Full Backup과 Archive Log Backup을 이용한 복구 시나리오
Online Full Backup과 Incremental Backup을 이용한 복구 시나리오
RMGR은 Online Full Backup을 통해 생성된 Backup Set과 Incremental Backup을 통해 생성된 Backup Set을 자동으로 Merge하여 복구를 진행합니다.
[예 21] Online Full Backup과 Incremental Backup을 이용한 복구 시나리오
Tablespace 기반 복구 시나리오
RMGR은 사용자가 Tablespace Name으로 지정한(--tablespace 옵션) 특정 테이블 스페이스에 대해서만 복구를 수행할 수 있습니다. V$BACKUP_SET_TABLESPACE을 조회함으로써 각 Backup Set에 포함된 테이 블 스페이스를 확인할 수 있습니다.
[예 22] Tablespace 기반 복구 시나리오
복구 관리자를 이용한 백업 삭제 예제
본 절에서는 다음의 백업 삭제 시나리오를 통해서 RMGR을 이용한 백업 삭제를 설명합니다.
Backup Set ID에 기반한 백업 삭제 시나리오
Backup Date에 기반한 백업 삭제 시나리오
RMGR을 이용하여 Backup Set을 삭제하는 경우, 삭제 대상이 되는 Target Backup Set은 두 가지 방식으 로 지정할 수 있습니다. 첫 번째로 Backup Set ID(--backup_set 옵션)를 명시하여 해당 Backup Set만을 삭제 할 수 있으며, 두 번째로 Backup Date(--beforetime 옵션)를 명시하여 명시한 Backup Date 이전에 백업이 이루어진 모든 Backup Set들을 삭제할 수 있습니다.
RMGR은 컨트롤 파일을 참조하여 삭제 대상으로 지정된 Backup Set의 존재 유무와 백업 경로를 확인한 후 삭제를 진행합니다. 따라서 컨트롤 파일에서 참조할 수 없는 Backup Set은 RMGR을 이용하여 삭제할 수 없으며, Backup Set이 존재하는 백업 경로가 백업할 때 컨트롤 파일에 등록된 백업 경로와 다른 경우에는 Backup Dest(-o 옵션)를 직접 명시해주어야 변경된 백업 경로에서 실제 백업된 파일에 대한 삭제를 진행 할 수 있습니다.
컨트롤 파일에 등록되어 있는 Backup Set 정보는 V$BACKUP_SET을 통해 조회할 수 있으며, 각 Backup Set에 속하는 Archive Log 정보는 V$BACKUP_ARCHIVED_LOG를 통해 조회할 수 있습니다.
참고
컨트롤 파일에 등록된 Backup Set을 사용자가 수동으로 삭제하였거나, 잘못된 백업 경로를 명시하 여 백업 경로에서 삭제 대상으로 지정된 Backup Set을 찾을 수 없는 경우에는 컨트롤 파일에 등록된 Backup Set Entry만을 삭제하고 종료합니다. 또한 테이프 장비에 저장된 경우 역시 컨트롤 파일에 등 록된 Backup Set Entry만을 삭제하고 종료합니다.
Backup Set ID에 기반한 백업 삭제 시나리오
RMGR은 사용자가 Backup Set ID로 지정한(--backup_set 옵션) 특정 Backup Set만을 선택적으로 삭제할 수 있습니다.
다음 예제에서는 RMGR을 이용하여 Backup Set ID = 1에 해당하는 Backup Set을 삭제합니다.
[예 23] Backup Set ID에 기반한 백업 삭제 시나리오
Backup Date에 기반한 백업 삭제 시나리오
RMGR은 사용자가 Backup Date로 지정한(--beforetime 옵션) 시간 이전에 생성된 모든 Backup Set을 삭 제할 수 있습니다.
다음 예제에서는 RMGR을 이용하여 "2016년 06월 17일 12시" 이전에 생성된 모든 Backup Set을 삭제한 다. Backup Date는 YYYYMMDDHH24MISS 형태로 명시합니다.
[예 24] Backup Date에 기반한 백업 삭제 시나리오
Tibero와 NetBackup 연동
NetBackup은 엔터프라이즈 백업 및 복구 소프트웨어로서, 다양한 환경에 대한 완벽하고 유연한 데이터 보호 솔루션을 제공합니다.
Tibero에서 복구 관리자를 사용해서 Veritas NetBackup으로 백업 파일 저장 및 복원할 수 있습니다. 아래에서 소개할 Tibero와 NetBackup 연동을 위해서는 NetBackup과 Tibero가 정상적으로 설치되어 있어야 합니다.
참고
NetBackup 연동을 위해서는 TmaxTibero 기술지원에 요청하여 NetBackup 연동이 가능한 Tibero를 별도로 제공 받아야 합니다.
NetBackup 설치 및 관리에 대한 자세한 내용은 "NetBackup Documentation"을 참고합니다.
NetBackup 환경설정
복구 관리자를 사용해서 NetBackup의 백업 파일 저장 및 복원하기 위해서 라이브러리를 연결하고, Net Backup 서버 및 클라이언트의 기본 정보를 설정해야 합니다.
NetBackup에 필요한 Tibero 라이브러리 연결 설정
초기 상태에는 $TB_HOME/client/lib에 있는 dummy 라이브러리들과 연결되어 있습니다. dummy 라이브러리 들은 사용하지 않으면 삭제하거나 직접 NetBackup 관련 라이브러리를 연결해주어야 합니다.
32bit 환경
libnbclientcST32.so
libnbbasecST32.so
libxbsa.so
libvxcPBXST.so
64bit 환경
libnbclientcST.so
libnbbasecST.so
libxbsa64.so
libvxcPBXST.so
NetBackup 서버 및 클라이언트 기본 설정
NetBackup 서버가 설치된 머신의 /etc/hosts 파일에 해당 머신의 호스트와 IP 주소 및 NetBackup 클라 이언트가 설치된 머신들의 호스트와 IP 주소를 추가합니다.
NetBackup 서버가 설치된 머신에서 NetBackup이 설치된 경로에 db/altnames 디렉터리를 생성한 후 NetBackup 클라이언트가 설치된 머신들의 호스트를 이름으로 가지는 빈 파일을 생성합니다.
NetBackup 클라이언트가 설치된 머신의 /etc/hosts 파일에 NetBackup 서버가 설치된 머신의 호스트와 IP 주소를 추가하고, 해당 머신의 호스트와 IP 주소를 추가합니다.
NetBackup 클라이언트가 설치된 머신에서 NetBackup이 설치된 경로에 있는 bp.conf 파일에 다음의 내용을 추가합니다.
복구 관리자를 위한 NetBackup 관리자 환경설정
다음은 복구 관리자를 사용하기 위해서 NetBackup 관리자 환경을 설정하는 방법에 대한 설명입니다.
NetBackup 관리자 콘솔이 설치된 머신의 /etc/hosts에 NetBackup 마스터가 설치된 머신의 호스트와 IP주소를 추가합니다.
NetBackup 관리자 콘솔 실행한 후 NetBackup 마스터가 설치된 머신의 root와 해당하는 비밀번호로 접 속합니다.
NetBackup 관리자 콘솔의 [Master Server] 탭에서 'Configure Disk Storage Servers'를 선택하여 NetBackup 마스터에서 사용할 디스크를 'AdvancedDisk'로 선택합니다. ReadyStream 이후 실제 백업에 사용할 디렉터리를 선택합니다.
NetBackup 관리자 콘솔 [PoliciesPolicies] 탭에서 New Policy를 생성합니다. Policy의 이름은 NBU_BACKUP_POL ICY_NAME, NBU_ARCHIVE_POLICY_NAME iparam에서 설정한 값으로 생성합니다. [AttributesAttributes] 탭의 'Policy type'을 'DataStore'로 생성하고 그외는 임의로 설정합니다. [ClientsClients] 탭에서 [New] 버튼을 클릭하고 NetBackup 클라이언트를 설치한 머신을 등록합니다.
NetBackup 관리자 콘솔의 [Host Properties] 탭에 있는 [Clients] 탭에 앞서 등록한 NetBackup 클라이 언트 머신이 표시되고 실제 정보와 일치하는지 확인합니다.
복구 관리자의 옵션 중 -p, --parallel 옵션을 사용할 수 있도록 아래와 같이 설정합니다.
Storage unit 설정에서 해당 스토리지에 Maximum concurrent jobs를 parallel로 실행될 thread 개수의 최대값으로 설정합니다(Tibero는 최대 16개를 parallel로 사용하고 있습니다).
Master server 설정에서 [Global Attribute] 탭에 있는 Maximum jobs per client 값을 하나의 클라이 언트에서 parallel로 실행될 thread 개수의 최대값으로 설정합니다.
Master server 설정에서 [ClientAttributeClient Attribute] 탭에 있는 Maximum data streams 값을 하나의 클라이언 트에서 parallel로 실행될 thread 개수의 최대값으로 설정합니다.
Policy 설정에 있는 [Schedules Tab]의 스케줄마다 설정에서 Media multiplexing 값을 하나의 클라이 언트에서 parallel로 실행될 thread 개수의 최대값으로 설정합니다.
복구 관리자 환경설정
NetBackup에서는 백업 파일에 대한 권한 관리가 이루어지 때문에 복구 관리자를 위한 파라미터들이 정상 적으로 설정되지 않은 상태에서 백업이 수행되면 복구가 불가능해질 수 있습니다.
다음은 복구 관리자의 환경설정에 사용되는 파라미터에 대한 설명입니다. 각 파라미터는 동적 설정이 가능 합니다.
USE_NBU_FOR_BACKUPSET
다음은 설정값에 대한 설명
Y : 복구 관리자에 의한 BackupSet 생성은 모두 NetBackup 서버에 전송되어 생성
N : NetBackup 서버에 저장된 BackupSet을 가져올 수 있음. (기본값)TAC 환경에서는 모든 노드가 동일한 값으로 설정되어 있어야 함.
USE_NBU_FOR_ARCHIVELOG
설정 값이 Y일 경우 데이터베이스에서 생성되는 아카이브 로그가 NetBackup 서버에 전송되어 생성되며, 복구할 때에도 NetBackup 머신에 존재하는 아카이브 로그를 읽어 복구를 진행 (기본값: N)
[참고] USE_NBU_FOR_ARCHIVELOG=Y일 경우 with-archivelog, archive-only, restore-archive-only 기능은 지원하지 않음
NBU_ARCHIVELOG_SEARCH
설정 값이 Y일 경우 NetBackup에 생성된 아카이브 로그들을 v$archive_dest_files로 조회 가능하고 이를 읽어 복구할 수 있음(기본값: N)
NBU_OBJ_OWNER_NAME
NetBackup을 통해 생성되는 백업 파일의 권한을 해당 파라미터에 설정한 값으로 설정해주며, 복구할 때에는 해당 파라미터의 값이 아닌 클라이언트 머신에서 로그인한 username을 참고 (기본값: "")
NBU_OBJ_OWNER_GROUP_NAME
NetBackup을 통해 생성되는 백업 파일의 권한을 해당 파라미터에 설정한 값으로 설정해주며, 복구할 때에는 해당 파라미터의 값이 아닌 클라이언트 머신에서 로그인한 group name을 참고
해당 값을 설정해주지 않으면 NBU_OBJ_OWNER_NAME으로 설정해준 user name에만 권한이 있게됨 (기본값: "")
NBU_CLIENT_COUNT
Tibero 인스턴스가 위치하는 독립적인 머신을 숫자로 설정
0에서 10 사이로 설정해주어야 하며, NBU_ARCHIVELOG_SEARCH를 Y로 설정한 경우 NBU_CLIENT_COUNT의 값과 NBU_CLIENT_HOSTNAME_#의 수가 같아야 함 (기본값: 0)
NBU_CLIENT_HOSTNAME_#
SID#N을 인스턴스 ID로 갖는 Tibero 인스턴스가 위치하는 머신의 호스트로 #을 0부터 시작해 설정 (기본값: "")
NBU_SKIP_HOST_CHECK
설정값이 Y일 경우 Tibero 인스턴스가 위치하는 머신의 호스트와 NBU_CLIENT_HOSTNAME_0에 설정되어 있는 값이 같은지 비교하지 않음 (기본값: N)
NBU_BACKUP_INST_SID
NBU_CLIENT_HOSTNAME_0에 설정된 머신의 호스트에 해당하는 Tibero 인스턴스의 SID로 설정 (기본값: "")
참고
for-standby 기능은 지원하지 않습니다.
복구 관리자를 이용한 NetBackup 사용 예제
연동 절차가 모두 완료된 후 복구 관리자로 백업을 수행했을 때 아래와 같이 NetBackup에 백업한다는 메시지가 찍히고 백업이 정상적으로 진행됩니다면 연동에 성공한 것입니다.
[예 25] NetBackup 시나리오
플래시백 데이터베이스
Tibero는 다양한 백업 및 복구 시나리오를 제공하지만, 백업 파일 용량이 매우 클 때는 백업 파일 복원과 이후 복구까지 굉장히 오랜 시간이 걸릴 수 있습니다. 특히, 유저의 실수를 만회하고자 데이터베이스를 아주 가까운 과거로 되돌리기 위해서도 백업 파일을 복원해야 합니다는 점 때문에 시간 소요가 너무 크다.
이러한 면을 보완하기 위하여 Tibero는 백업 파일 없이도 DB 전체를 과거로 되돌릴 수 있는 플래시백 데 이터베이스(Flashback Database) 기능을 제공합니다.
기본 기능 및 특징
플래시백 데이터베이스는 단어 의미 그대로 데이터베이스를 가까운 과거로 빠르게 되돌릴 수 있는 기능 입니다. SQL 명령어 ALTER DATABASE 구문으로 플래시백 로그 파일 관리 및 플래시백 수행 가능합니다.
Tibero 플래시백 데이터베이스 기능의 특징은 다음과 같습니다.
데이터베이스를 과거로 되돌리기 위한 플래시백 로그 파일을 따로 생성하고 관리합니다. 추가적인 로그 파일을 생성하기 때문에 데이터베이스 성능 저하는 불가피합니다. 플래시백 로그 파일은 “Tibero 구성 파일”을 참고합니다.
Flashback Marker 시점까지 데이터베이스를 과거로 되돌린 후 사용자가 입력한 시점까지 불완전 복구 합니다. Flashback Marker는 블록의 변경되는 이미지를 플래시백 로그 파일에 로깅하는 기준입니다. 사용자가 SQL 구문을 통해 직접 추가할 수 있으며, 초기화 파라미터 FLASHBACK_MARKER_INTER VAL(단위: 초)를 설정하여 백그라운드 작업으로 주기적으로 남기게 할 수 있습니다. Flashback Marker는 자 주 남길 수록 플래시백 데이터베이스 기능 수행이 빠르지만, 그만큼 플래시백 로그가 많이 생성되기에 데이터베이스 운영 성능이 더 저하됩니다.
백업 파일들 복원하지 않고 특정 과거 시점으로 데이터베이스를 회귀시킬 수 있습니다.
백업 파일 복원 후 불완전 복구와 효과는 같지만, 총 작업 시간이 백업 파일 복원 시간만큼 절감됩니다.
현재의 Resetlogs TSN 이전으로도 회귀시킬 수 있습니다. 이 특징을 사용하면 사이트의 운영 장비가 아닌 별도의 개발 장비에서 Resetlogs 부팅으로 특정 시나리오 테스트 후 데이터베이스를 재생성하지 않고 빠르게 기존 상태로 원복할 수 있습니다.
Tibero Standby Cluster 사용 중 switchover/failover를 발생할 때 기존 Primary Database를 재구축하지 않고 빠르게 standby로 전환시킬 수 있습니다.
전제 조건 및 제약 사항
플래시백 데이터베이스는 현재 존재하는 파일을 블록 단위로 과거로 돌리는 작업이기 때문에 다음과 같 은 사항들이 고려되어야 합니다.
지워지지 않고 실제 존재하는 정상적인 데이터 파일에 대해서만 플래시백 가능합니다. 손상된 데이터 파 일을 복구하는 것은 불가합니다.
플래시백하는 시점 이후로 추가된 파일은 자동으로 데이터베이스에서 삭제됩니다. 물리적 파일은 삭제하 지 않기 때문에 직접 관리해줘야합니다.
Drop된 데이터 파일을 Drop되기 전으로 플래시백하려면, 해당 데이터 파일의 백업 파일이 존재해야만 합니다. 플래시백 수행 후 백업 파일을 복원하라는 가이드가 화면에 안내됩니다.
플래시백하는 시점 기준으로 테이블 스페이스는 rename되지만, 데이터 파일은 보존됩니다.
Offline된 테이블 스페이스 및 데이터 파일은 플래시백 대상에서 제외됩니다. 추후 drop해야 합니다.
크기가 Extend된 데이터 파일은 다시 줄어들지 않습니다.
Shrink된 데이터 파일은 플래시백 불가합니다. 단, 해당 데이터 파일을 offline시키면 이를 제외한 나머지 데이터베이스에 대해서는 플래시백 가능합니다. 이후 해당 파일에 대해서는 직접 백업 파일을 복원하여 불완전 복구해야합니다.
컨트롤 파일을 재생성했다면 이전까지 축적한 플래시백 로그 정보는 사라진다. 플래시백 로깅을 다시 활성화해야 하며, Flashback Marker도 처음부터 다시 생성됩니다. 즉, 컨트롤 파일 재생성 이전으로는 플 래시백 데이터베이스 불가합니다. 컨트롤 파일 재생성 이전에 생성된 플래시백 로그 파일들은 백업 데이 터 파일과 컨트롤 파일이 있지 않는 이상 사용할 수 없습니다.
백업 데이터 파일과 컨트롤 파일로 Media Recovery 후에도 기존 플래시백 로그 파일을 사용하고자 한 다면, 완전 복구를 통해 Resetlogs 부팅은 하지 않아야 하며, Flashback Marker 이후의 플래시백 로그 파일들의 존재가 보장되어야 합니다. 일반적으로 백업 데이터 파일과 컨트롤 파일을 사용하여 데이터베이스를 복구할 때 Flashback Marker 를 초기화여 플래시백 로깅을 새롭게 시작하는 것이 안전합니다. 추가적으로 플래시백 로깅을 활성화한 채로 Media Recovery를 수행할 때 Redo 로그를 기반으로 플래시백 로그도 복구하기 때문에 복구 성능 이 매우 저하될 수 있습니다. 따라서 플래시백 로깅을 비활성화하는 것을 추천하는데, 비활성화 할 경우 플 래시백 로그 파일 정보들은 모두 초기화됩니다.
NOLOGGING 모드는 권장하지 않습니다. NOLOGGING 모드로 데이터베이스를 사용하면 플래시백은 가 능하지만 NOLOGGING 모드를 사용한 기간 동안의 플래시백 로그가 없기 때문에 해당 내용들은 플래 시백이 불가하여 정합성이 깨진 미래의 데이터베이스로 남아있을 뿐입니다.
데이터베이스를 정상 종료해야만 MOUNT 모드에서 플래시백 데이터베이스 기능이 실행 가능합니다. 정 합성이 보장된 상태에서 플래시백해야 하기 때문입니다.
플래시백 데이터베이스 실행 예제
본 절에서는 다음의 시나리오들을 통해서 플래시백 데이터베이스를 위한 플래시백 로그 파일 생성, 로깅 활성화, 그리고 실제 플래시백 데이터베이스 수행을 설명합니다. 이들은 모두 MOUNT 상태에서만 수행 가 능합니다.
플래시백 로그 파일 생성과 로깅 활성화 시나리오
플래시백 데이터베이스 실행 시나리오
플래시백 데이터베이스 실행 중 MISSING 파일 생성 시나리오
플래시백 로그 파일 생성과 로깅 활성화
일반 로그 파일 구조, 구성과 동일하기에 이를 관리하는 원리도 같습니다. 단, 현재 플래시백 로그 파일 다중화 기능은 지원하지 않기 때문에 플래시백 로그 멤버는 그룹당 하나만 가능합니다. 플래시백 로그 파일에 대해 서는 일반 로그 파일인 “로그 파일”을 참고합니다.
플래시백 로그 파일을 추가한 후에는 해당 스레드와 플래시백 로깅을 활성화해야 운영 중 플래시백 로깅 이 동작합니다. 플래시백 로깅을 활성화시키기 위해서는 초기화 파라미터인 FLASHBACK_LOG_BUFFER 가 세팅되어 있어야합니다.
FLASHBACK_LOG_BUFFER 값은 일반적으로 LOG_BUFFER 값의 2배가 권장됩니다. 자세한 값은 실제 사이트의 운영 방식에 맞게 튜닝이 필요합니다.
[예 26] 플래시백 로그 파일 생성과 로깅 활성화 시나리오
플래시백 데이터베이스 실행 시나리오
현재 TSN 값이 155670인 데이터베이스를 가까운 과거인 150000으로 플래시백하려면 데이터베이스를 정상 종료 후 MOUNT 모드에서 다음을 구문을 수행한 후 완료 여부를 확인합니다.
[예 27] 플래시백 데이터베이스 실행 시나리오
플래시백 데이터베이스 실행 중 MISSING 파일 생성 시나리오
현재 TSN 값이 155670인 데이터베이스를 가까운 과거인 150000으로 플래시백 수행 도중 다음과 같은 에러가 발생할 때 Drop된 파일을 되살려야 합니다. 에러와 함께 안내되는 절차대로 수행하면 데이터베이스가 원하던 시점으로 온전히 플래시백됩니다.
[예 28] 플래시백 데이터베이스 실행 중 MISSING 파일 생성 시나리오
Last updated