백업 & 리커버리 (by ljh1148) [2010.01.05]
What is Redo?
리두 로그 파일들은 오라클 데이터베이스에서 매우 중요하다. 이것들은 데이터베이스에 대하여 트랜젝션 로드들이다. 오라클은 2개의 리두 로그 파일들을 관리한다. : online과 archived 그것들은 복구를 위한 목적으로 사용한다. 파일에서 그것들의 목적은 인스턴스나 media의 파손의 경우에 사용한다.
만일 여러분의 데이터베이스의 전원이 꺼졌을 경우 (인스턴스 파손의 원인이 되는), 오라클은 파워가 나가기 전의 정확한 시점의 시스템을 복구하기 위하여 온라인 리두 로그들을 사용할 것이다.
만일 디스크 드라이버(media)가 실패하였을 경우, 오라클은 그 시점의 정확한 시점으로 복구하기 위하여 온라인 리두 로그들 뿐만 아니라 archived 로그들을 사용할 것이다. 게다가, 만일 테이블을 truncate 하거나 어떤 중요한 정보들을 제거라고 commit을 하면 여러분은 영향을 받은 데이터를 복구할 수 있고 online, archived 리두 로그들을 사용하여 사고 전으로 즉시 복구할 수 있다.
Archived 리두 로그 파일들은 전의 full online redo log 파일들을 단순히 복사한다. 시스템은 로그 파일들을 사용함으로써, ARCH 프로세스는 다른 곳에 온라인 로그 파일의 복사본을 만들고, 추가적으로 로컬과 다른 서버들에 다른 복사본을 복사한다. Archived 리두 로그 파일들은 장애가 디스크 장애나 다른 물리적인 이유가 발생하였을 때 media 복구를 수행한다. 오라클은 이러한 archived 로그 파일들을 사용할 수 있고 데이터베이스에 저장함으로써 이것들을 사용하여 데이터 파일들을 백업 등에 사용할 수 있다. 그것들은 데이터베이스의 트랜젝션의 이력이다.
Note
오라클 10g부터 오리는 flashback 기술을 가진다. 이것은 flashback query를 수행을 허용하고, 테이블을 drop 하지 않고, 그것이 어떤 시점 전으로 테이블을 돌린다. 결과적으로, 백업들과 archived redo logs들을 사용함으로써, 복구를 수행할 필요가 있는 경우의 수가 줄어든다. 그러나 복구는 DBA의 중요한 일이다. 데이터베이스 복구는 DBA가 틀리지 않게 복구를 수행하는 것이다.
모든 오라클 데이터베이스는 각각의 그룹 안에 최소한 단일 파일의 2개의 온라인 리두 로그 그룹을 가진다. 이 온라인 리두 로그 그룹들은 주기적으로 순환하여 사용된다. 오라클은 그룹-1 안에 로그 파일들에 기록하고 그것이 그룹-1 안에 파일의 끝에 도달하였을 경우 그것은 그룹-2로 스위치 될 것이고 로그들을 기록할 것이다. 그룹-2에 로그 파일이 가득 채워지면 그 때 그룹-1의 로그 파일로 스위치 될 것이다. (2개의 그룹 있다고 가정한 경우)
리두 로그들이나 트랜젝션 로그들은 데이터베이스를 만드는 중요한 특징이다. 만일 언두 세그먼트 분배된 트랜젝션 복구등이 없다면 그것들은 아마도 중요한 복구 작업을 수행하지 못할 것이다. 그것들은 재래전인 파일 시스템으로부터 데이터베이스를 구성하는 구성요소이다. 온라인 리두 로그들은 전원이 나가는 것들로부터 효율적인 복구를 수행하게 해준다. Archived 로그 파일들은 하드 디스크가 나빠지거나 사람의 실수로 데이터가 손실되었을 때 인스턴스에 대하여 미디어 손실로부터 복구를 해준다. 리두 로그 없이, 데이터베이스는 파일 시스템 보다 다 나은 보호를 제공하지 못한다.
What is undo?
Undo는 개념적으로 redo와 반대이다. Undo 정보는 사용자가 어떤 이유에 대하여 실패하거나 만일 사용자기 ROLLBACK을 요구할 때 트랜잭션이나 문장 안에 수정 전으로 데이터를 변경할 때 생성된다. 리두가 트렌젝션의 복구를 위한 실패의 이벤트 안에 트랜잭션을 돌릴 때 사용하는 반면, 언두는 문장의 구성이나 문장의 영향을 뒤집을 경우 사용한다. 리두와 달리 언두는 undo segments로 알려진 세그먼트들의 구성 안에 데이터베이스 안에 내부적으로 저장된다.
Note
"Rollback segment"와 "undo segment"들은 동기적인 관점에서 취급된다. 수동적으로 언두 세그먼트를 사용함으로써, DBA는 "rollback segments"를 생성할 것이다. 자동적으로 언두를 관리함으로써, 시스템은 자동적으로 필요에 따라서 "undo segments"를 생성하거나 없앨 수 있다.
일반적으로 언두에 관하여 언두는 문장이나 트랜잭션이 실행하기 전에 그것은 물리적으로 데이터베이스를 복구하는데 사용하는 것은 잘못된 개념이다. 데이터베이스는 논리적으로 (어떤 변화가 논리적으로 수행하지 않은 경우) 그것을 복구하는데 사용하지 않지만, 데이터베이스 블락들과 같은 데이터 구조는 롤백 후에 다르게 되어 있을 것이다. 이 사실 안에 이 거짓말에 대한 이유는 다중 시스템 안에 아주 많은 동시 트랜잭션이 있기 때문이다. 데이터베이스의 중요한 기능 중에 하나가 데이터에 대하여 동시 접근을 허용하기 때문이다. 그러므로, 우리는 정확히 트렌젝션이 시작하였을 경우로 블락을 되돌릴 수 없다.
예를 들어, 몇 개의 익스텐트의 할당이 요구되는 insert를 실행한다고 가정한다. Insert는 몇 개의 새로운 블락을 가질 것이다. 그리고 블락에 데이터가 입력될 것이다. 이 관점에서, 몇 개의 트렌젝션이 생길 것이고 블락 안에 데이터가 저장될 것이다. 그러므로, 오라클이 롤백할 경우, 그것은 우리가 첫 번째로 수행한 것과 반대의 논리적 수행이 이루어질 것이다. 모든 insert에 대하여, 오라클은 delete를 수행할 것이다. 모든 delete에 대하여, 오라클은 insert를 수행할 것이다. 모든 update에 대하여 오라클은 "anti-update"를 수행하거나 변경 전으로 데이터를 돌리는 update를 수행할 것이다.
아래의 절차로 수행되는 법을 알아본다.
- 빈 테이블을 생성한다.
- 테이블을 full scan라고 읽는데 수행되는 I/O의 양을 관측한다.
- 많은 데이터를 입력한다(no commit)
- Roll back하고 undo 한다.
- 다시 한 번 테이블을 full scan하고 수행되는 I/O의 양을 관측한다.
빈 테이블을 생성한다.
SQL> create table t
2 as
3 select *
4 from all_objects
5 where 1=0;
Table created.
그리고 쿼리를 수행한다.
그 쿼리는 처음에 테이블을 full scan 하는 세 개의 I/O를 가진다.
SQL> select * from t;
no rows selected
SQL> set autotrace traceonly statistics
SQL> select * from t;
no rows selected
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
3 consistent gets
...
SQL> set autotrace off
다음으로 우리는 테이블에 많은 데이터를 입력한다. 우리는 "grow"로 만들고 다시 롤백한다.
SQL> insert into t select * from all_objects;
48350 rows created.
SQL> rollback;
Rollback complete.
그리고 만일 우리가 다시 쿼리를 수행하면, 우리는 테이블을 읽는데 더 많은 I/O가 발생한 것을 발견할 수 있다.
SQL> select * from t;
no rows selected
SQL> set autotrace traceonly statistics
SQL> select * from t;
no rows selected
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
689 consistent gets
...
SQL> set autotrace off
테이블의 High-water mark 아래 더해지는데 원인이 되는 insert된 블락들은 아직도 거기 있지만 비어있다. Full scan은 만일 어떤 데이터들을 포함되어 있다면 그것을 보기 위하여 읽을 것이다. 이것은 롤백은 논리적 "put the database back the way it was" 작업을 보여준다. 데이터베이스는 정확하게 논리적으로 수행되지 않는다.
How redo and undo work together
우리는 어떻게 언두와 리두가 같이 수행되는지 다양한 시나리오로 살펴 볼 것이다. 예를 들어 우리는 리두와 언두 동작에 관하여 insert 처리 과정 동안에 무엇이 일어나는지 의논하고 어떻게 오라클이 다양한 관점에서 손상되었을 경우 정보를 어떻게 사용하는지 살펴 볼 것이다.
Example INSERT-UPDATE-DELETE Scenario
예제와 같이, 우리는 아래와 같이 문장이 무엇이 발생하는지 조사할 것이다.
insert into t (x,y) values (1,1);
update t set x = x+1 where x = 1;
delete from t where x = 2;
우리는 다른 관점 아래에서 이 트랜잭션을 허용할 것이고 다름의 질문들을 대답할 것이다.
- 만일 시스템이 문장들이 실행할 때 다양한 관점에서 실패할 경우 무엇이 일어나는가?
- 만일 어떤 시점에 ROLLBACK이 발생하면 무엇이 일어나는가?
- 만일 COMMIT이 성공하면 무엇이 발생하는가?
The INSERT
처음에 INSERT INTO 문장이 리두와 언두에 동시에 발생할 것이다. 발생한 언두는 INSERT를 만들기에 충분한 정보일 것이다. INSERT INTO T에 의하여 발생한 이두는 insert을 하기에 충분한 공간일 것이다.
Insert가 발생한 후에, 우리는 다음 그림과 같은 시나리오를 수행하게 된다.
A. State of the system after an INSERT
거기에는 변경된 undo blocks과 인덱스 블락들 그리고 테이블 데이터 블락들이 캐쉬된다. 이 블락들의 각각은 리두 로그 버퍼 안에 등록됨으로써 보호된다.
가상 시나리오 : The system crashes right now
모든 것이 완벽한다. SGA가 망가졌으나, 우리는 SGA 안에 어떤 것도 필요하지 않다. 이것은 만일 우리가 재시작할 때 이 트랜잭션이 다시 발생하지 않는 것과 같다. 변화에 의하여 어떤 블락들도 디스트에 flush되지 않고, 어떤 리두도 디스크에 flush 되지 않는다. 우리는 인스턴스 장애로부터 복구하기 위하여 언두나 리두의 어떤 것도 필요하지 않다.
가상 시나리오 : The buffer cache fills up right now
이 상황은 DBWR 프로세스가 반드시 저장 공간을 만들고 변경된 블락들이 캐쉬로부터 flush 되어야 한다. 이 상황에서, DBWR은 데이터베이스 블락들을 보호하는 리두 entries를 flush 하기 위하여 LGWR에게 물음으로써 시작한다. DBWR은 디스크로부터 변경된 어떤 블락들을 기록하기 전에 LGWR은 반드시 관련된 블락들과 관련된 리두 정보를 flush 한다. 만일 언두 블락들과 관련된 리두 entries에 flush 없이 테이블 T에 대하여 변경된 블락들을 flush 하고 시스템이 장애가 발생하면, 그것과 관련된 어떤 언두 정보들도 테이블 T 블락에 변경된다. 우리는 블락에 기록하기 전에 리두 로그 버퍼들을 flush 해야 한다. 그래서 당장 상태를 SGA에 획득함으로써 필요한 모든 정보를 리두 함으로써 rollback 할 수 있다.
두 번째 시나리오는 발생할 상황의 어떤 부분을 미리 보여준다. "만일 테이블 T의 블락들이 flush 되고 언두 블락들에 대하여 리두가 flush 되지 않았다면 시스템은 장애가 발생한다."는 복잡하게 시작한다. 그것은 단지 우리가 사용자들과 객체들과 동시 프로세스 등을 더함으로써 더 복잡하게 한다.
이와 같은 관점에서, 우리는 그림 A 안에 묘사된 상황을 본다. 우리는 변경된 테이블과 인덱스 블락들이 발생하는 것을 볼 수 있다. 이것들은 언두 세그먼트 블락들과 관련이 있고, 세 가지 타입의 블락들이 그것들을 보호하기 위하여 리두를 생성하는 것을 볼 수 있다. 프로세싱 동안에 어떤 시점에 리두 로그 버퍼가 flush 되는 것은 가능하다. 이와 같은 상황을 그림 B를 통하여 볼 수 있다.
B. State of the system after a redo log buffer flush
The UPDATE
UPDATE는 INSERT가 발생하는 것과 같이 같은 동작이 발생한다. 이 시간에, 언두의 양이 커질 것이다. "before" 이미지들이 update의 결과로써 저장될 것이다. 
C. State of the system after the UPDATE
불락 버퍼 캐쉬 안에 새로운 언두 세그먼트 블락들을 가진다. 언두를 업데이트 하기 위해, 만일 필요하다면, 우리는 캐쉬 안에 데이터베이스 테이블과 인덱스 블락들을 변경한다. 또한 더 많은 리두 로그 버퍼 entries들이 발생한다. insert로부터 발생한 리두 로그의 어떤 것들이 디스크에 있고 어떤 것은 캐쉬에 있다고 가정한다.
가상 시나리오 : The System Crashes Right Now
데이터베이스가 시작할 때, 오라클은 리두 로그들을 읽고 트랜잭션에 대하여 어떤 리두 로그 entries들을 발견한다. 우리가 시스템에서 접속을 끊을 때, 리두 로그 파일들 안에 insert에 대하여 리두 entries과 버퍼 안에 update에 대한 리두들은 오라클은 "roll forward" 한다. 우리는 그림 A와 같이 어떤 언두 블락들과 변경된 테이블 블락들과 변경된 인덱스 블락들이 동작할 것이다. 오라클은 트랜잭션이 절대 commit 되지 않고 시스템이 crash 복구를 하고 있는 것을 발견할 수 있다. 물론 세션은 더 이상 연결되어 있지 않다. 그것은 버퍼 캐쉬 안에 roll forward 된 언두를 가질 것이고 그것은 데이터와 인덱스 블락들을 허용한다. 지금 모든 것은 과거와 같이 된다. 디스크 안에 블락들은 INSERT의 영향을 받거나 받지 않을 것이다. 만일 한다면, 그 때 insert가 되고 블락들이 버퍼 캐쉬로부터 flush 될 때, 데이터 파일은 영향을 받을 것이다. 만일 그것들이 insert를 반영하지 않으면 그것들 후에 어떤 식으로 다시 기록할 것이다.
시나리오에서 crash 복구에의 기본적인 상황을 보여준다. 시스템은 두 개의 과정으로 수행한다. 첫 번째, roll forward에서, 시스템은 장애의 관점에서 수행되고 아직 commit 되지 않은 모든 것을 rollback을 수행할 것이다. 이 행위는 데이터 파일들을 재-동기화 할 것이다. 이것은 아직 완료되지 않은 것을 무효로 하고 과정 안에 일을 반복한다.
가상 시나리오 : The Application Rolls Back the Transaction
이 시점에, 오라클은 만일 그것들이 flush 되었다면 디스크나 캐쉬된 언두 세그먼트 블락들의 트랜잭션에 대하여 언두 정보를 발견할 수 있다. 그것은 버퍼 캐쉬 안에 데이터와 인덱스 블락들의 언두 정보를 발견할 수 있다. 이것은 버퍼 캐쉬 안에 데이터와 인덱스 블락들의 언두 정보를 지원하거나 만일 그것들이 더 이상 캐쉬 안에 요청하지 않으면, 그것들은 그것들을 지원하는 언두를 가지는 캐쉬 안에서 디스크로부터 읽는다 이 블락들은 후에 원래의 데이터 값이 저장되어 있는 데이터 파일로부터 flush 될 것이다.
이 시나리오는 시스템 crash 보다 더 일반적이다. 이것은 rollback 프로세스 동안에 유용하다. 리두 로그들은 절대 관여하지 않는다. 리두 로그들은 읽는 시간은 복구 동안이다. 이것은 키 튜닝 개념이다. 리두 로그들은 기록될 것이다. 오라클은 정상적은 프로세스 동안에 그것들을 읽지 못한다. 여러분이 충분한 장비들을 가지고 있다면 ARCH가 파일로부터 읽을 때, LGWR은 다른 장비에 기록한다. 그 때, 리두 로그에 관한 경합이 없다. 많은 다른 데이터베이스는 리두 로그들을 "트랜잭션 로그들"로 취급한다. 리두와 언두를 구분하지 않는다. 이러한 시스템에 대하여, 롤백 수행이 형편 없이 수행될 것이다. Rollback 프로세스는 log writer가 기록을 시도할 때 반드시 로그들을 읽어야 한다. 오라클의 목적은 로그들이 순차적으로 기록되고 그것들이 기록되는 동안에 아무도 그것들을 읽지 못하게 하는 것이다.
The DELETE
다시 언두는 DELETE의 결과로써 발생한다. 블락들이 변경되고, 리두는 리두 로그 버퍼로 보낸다. 이것은 전과 다르지 않다. 사실 이것은 UPDATE와 유사하다.
The COMMIT
D. State of the system after a COMMIT
변경된 블락들은 버퍼 캐쉬 안에 있다. 아무도 그것들의 어떤 것은 디스크 안에 flush된다. 트랜잭션을 반복하면 필요한 리두는 디스크 안에 안전하게 있고 변경사항은 지금 영구적으로 있다. 만일 우리가 데이터 파일로부터 직접 데이터를 읽으면, 우리는 아마도 트랜잭션이 발생하기 전에 존재하는 블락들을 볼 수 있다. DBWR이 아직 그것들을 기록하지 않았다면 말이다. 리두 로그 파일은 장애가 발생할 때 블락으로부터 데이터를 가지고 와서 사용한다. 오라클은 그것들이 필요한 어떤 세션에 대하여 영향 받는 객체들의 일관적인 읽기를 제공하는데 undo를 사용할 것이다
1. Logminer
1.1 Logminer란?
- Logminer는 Oracle 8i 이상에서 사용가능함
- Online 혹은 Offline Redo Log 파일에 대한 읽기/분석/해석을 위해서 SQL 문장을 사용하여 수행 할 수 있습니다.
- Log파일의 분석 작업 결과는 다음과 같은 용도로 사용 될수 있다.
1) Transaction별, 사용자 별, 시간대 별로 Database에 가해진 변경작업에 대한 추적을 할 수있습니다.
즉, 어떤 사용자가 어떤 자료를 수정 했는지 또한 그 작업을 수행하기 이전의 데이타 값은 무엇이었으며
작업 이후의 데이타 값이 어떤 값으로 변경 되었는지 확인 할 수 있습니다.
데이타 변경과 과거 시점의 자료 추적기능 및 그 작업을 취소(Undo)할 수 있는 기능은 보안과 관리에 매우 중요한
수단으로 사용될 수 있습니다.
2) 논리적 자료의 변조(예를 들어 실수로 자료를 지우고 계속 작업을 진행하는 경우)가 언제 발생했는지를 정확히 알 수 있으며,
변조된 이전 시점까지 일관성이 보장된 상태로 Database를 복원하기 위해서 어떤 방법으로 Recovery를 시작할지를 결정하는데
중요한 역할을 한다.
3) 다양한 형태의 시간적 추이에 따른 어플 사용과 자료의 패턴 분석이 가능하므로 Tuning과 성능 계획을 수립하기 위한 보조자료로 사용될 수 있다.
1.1.1 Logminer 세부 사항
- LogMiner는 Log파일을 추출하여, 그 안에 저장되어 있는 내용을 Database에 가해진 노리적인 작업을 표현하는 SQL 문장으로 변환합니다.
- V$LOGMINR_CONTENTS view는 본래의 작업을 표현하는 SQL(SQL_REDO column)과 그 작업을 취소할수 있는 SQL(SQL_UNDO coumn)을 보여줍니다.
1.1.1 Redo Logs
- 정확한 결과를 얻기 위해서 최소한의 Supplemental Logging이 활성화가 되어야 한다.
- v$LOGMNR_CONTENTS View을 통한 SQL 문장을 실행 시 분석된 Redo log파일정보를 순차적으로 파일로 추출됩니다.
{section}
{column:width=10%}
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (UNIQUE) COLUMNS;
ALTER DATABASE DROP SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
ALTER DATABASE DROP SUPPLEMENTAL LOG DATA (UNIQUE) COLUMNS;
ALTER DATABASE DROP SUPPLEMENTAL LOG DATA;
{column}
{section}
1.1.2 Logminer로 가능한 것들
- Database에 작성된 변경 사항들의 기록
- 유형 (INSERT, UPDATE, DELETE, COMMIT/ROLLBACK, DDL 또는 INDEX 작업)
- 그와 같은 변경이 발생하는 SCN(System Change Number)
- 변경을 포함하는 트랜잭션 식별
- 특정 트랜잭션이 커밋되는 SCN
- 변경된 객체의 테이블 및 스키마 명칭
- DML 또는 DDL 문을 발생시킨 사용자 정보
- Redo 레코드들을 생성하는 "동등한"SQL을 나타낼 수 있는 재생성된 SQL(SQL_REDO)
- 변경 사항의 실행 취소를 위해 필요한 SQL을 제공하는 재생성된 SQL(SQL_UNDO)
1.1.3 Logminer의 제약 사항
1) LONG and LOB data type (10g부터 가능)
2) Object types
3) Nested tables
4) IOT(Index-Organized Table)(10g부터 가능)
5) Chianed row or migrate row
1.2. Logminer의 제약 사항
- UTL_FILE_DIR Parameter 설정 : init parameter file에 설정해주어야 하며, 그 용도는
Log를 읽을 때 생성되는 Dictionary 정보를 저장하는데 사용되는, Flat file의 저장공간으로 사용된다.
UTL_FILE_DIR='/oracle/ora9/dict' scope=spfile; - LogMiner 를 위한 dictionary file 생성(또는 Online Redo log)
=> Object 정보를 저장하기 위한 Flat file 용도이다.
execute dbms_logmnr_d.build(dictionary_filename => 'dictionary.ora', - dictionary_location => 'data/ora9/dict', optioins => dbms_logmnr_d.store_in_flat_file); - 분석할 Redo log 또는 Archive log file
- Database 가 ArchiveLog Mode 이어야 한다.
- 필요에 따라서 Mining 하고자 하는 Table 이 supplemental logging 이 되어야 한다.
- 최소 CPU 1장 정도의 resource 을 사용한다. (대략 Logminer 1개의 DB Session 당 1개의 CPU 사용함)
- 최소 Memory 을 10MB 에서 100MB 정도 사용한다. (Redo Size을 100MB일 겨우)
- Mining 데이터를 Table로 저장 시 Tablespace 확인 후 작업을 해야하며 추후 꼭 Drop 처리를 해야한다.
1.3. Logminer 관련 View 및 Package
1) V$LOGMNR_CONTENTS - 현재 분석되고 있는 log file의 내용
2) V$LOGMNR_DICTIONARY - 사용 중인 dictionary file
3) V$LOGMNR_LOGS - 분석에 사용되고 있는 log file
4) V$LOGMNR_PARAMETERS - LogMiner에 Setting된 현재의 parameter의 값
5) dbms_logmnr Package(start, end, new, addfile, remove)
1.4. Logminer 관련 페키지
1.4.1 DBMS_LOGMNR_D
- Security Model : EXECUTE_CATALOG_ROLE
{section}
{column:width=10%}
SQL> CONN /AS SYSDBA
SQL> /@?/rdbms/admin/dbmslmd.sql
SQL> GRANT EXECUTE_CATALOG_ROLE TO USER_NAME
SQL> CREATE PUBLIC SYNONYM DBMS_LOGMNR FOR SYS.DBMS_LOGMNR;
{column}
{section}
1.4.1.1 DBMS_LOGMNR_D.BUILD
- flat 파일로 Dictionary 추출
- 이전 버전과 상호 호환성을 보장하며, TRANSACTION의 일관성은 보장하지 않습니다.
- Oracle은 flat 파일로 Dictionary 추출을 권장하지 않는다.
- Online Catalog을 이용하거나 Redo Log 파일로 Dictionary 추출을 권장합니다.
{section}
{column:width=10%}
--UTL_FILE_DIR PARAMETER에 명시되어 있어야함.
DBMS_LOGMNR_D.BUILD (
dictionary_filename IN VARCHAR2, --LogMiner dictionary file
dictionary_location IN VARCHAR2, --LogMiner dictionary file directory (UTL_FILE_DIR)
options IN NUMBER); --STORE_IN_FLAT_FILE : flat file, STORE_IN_REDO_LOGS : redo log files files
{column}
{section}
- Example
{column:width=10%}
--flat file
SQL> EXECUTE dbms_logmnr_d.build('dictionary.ora', -
'/oracle/database/', -
options => dbms_logmnr_d.store_in_flat_file);
--redo log files
SQL> EXECUTE dbms_logmnr_d.build( -
options => dbms_logmnr_d.store_in_redo_logs)
{column}
1.4.1.1 DBMS_LOGMNR_D.SET_TABLESPACE
- 모든 LogMiner 테이블들은 Default로 SYSTME Tablespace에 생성이 되며, 다음의 문장을 사용하여
모든 LogMiner 테이블들을 또 다른 Tablespace에 생성할 수 있습니다.
{section}
{column:width=10%}
DBMS_LOGMNR_D.SET_TABLESPACE(
new_tablespace IN VARCHAR2); --해당 Tablespace_name
{column}
{section}
- example
{section}
{column:width=10%}
SQL> CREATE TABLESPACE logmnrts$ datafile '/usr/oracle/dbs/logmnrts.f'
SIZE 25 M REUSE AUTOEXTEND ON MAXSIZE UNLIMITED;
SQL> EXECUTE dbms_logmnr_d.set_tablespace('logmnrts$');
{column}
{section}
사용자 실수로 데이터를 변경(delete, insert, update)후 Logminer로 복구하기
{section}
{column:width=10%}
SQL*Plus: Release 10.2.0.1.0 - Production on 토 1월 9 17:06:26 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> conn /as sysdba
연결되었습니다.
SQL>
SQL> archive log list;
데이터베이스 로그 모드 아카이브 모드
자동 아카이브 사용
아카이브 대상 USE_DB_RECOVERY_FILE_DEST
가장 오래된 온라인 로그 순서 9
아카이브할 다음 로그 11
현재 로그 순서 11
SQL> set linesize 150;
SQL>
SQL> alter system switch logfile;
시스템이 변경되었습니다.
SQL> select * from v$log where status='CURRENT';
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TI
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------
2 1 12 52428800 1 NO CURRENT 716902 10/01/09
SQL>
SQL> conn scott/tiger
연결되었습니다.
SQL>
SQL> select * from emp;
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
---------- ---------- --------- ---------- -------- ---------- ---------- ----------
7369 SMITH CLERK 7902 80/12/17 500 20
7499 ALLEN SALESMAN 7698 81/02/20 500 300 30
7521 WARD SALESMAN 7698 81/02/22 500 500 30
7566 JONES MANAGER 7839 81/04/02 500 20
7654 MARTIN SALESMAN 7698 81/09/28 500 1400 30
7698 BLAKE MANAGER 7839 81/05/01 500 30
7782 CLARK MANAGER 7839 81/06/09 500 10
7788 SCOTT ANALYST 7566 87/04/19 500 20
7839 KING PRESIDENT 81/11/17 20000 10
7844 TURNER SALESMAN 7698 81/09/08 500 0 30
7876 ADAMS CLERK 7788 87/05/23 500 20
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
---------- ---------- --------- ---------- -------- ---------- ---------- ----------
7900 JAMES CLERK 7698 81/12/03 500 30
7902 FORD ANALYST 7566 81/12/03 500 20
7934 MILLER CLERK 7782 82/01/23 500 10
14 개의 행이 선택되었습니다.
SQL> update emp set sal=1000;
14 행이 갱신되었습니다.
SQL> update emp set sal=10000 where ename='KING';
1 행이 갱신되었습니다.
SQL> commit;
커밋이 완료되었습니다.
SQL> CONN / AS SYSDBA
연결되었습니다.
SQL>
SQL> ALTER SYSTEM SWITCH LOGFILE;
시스템이 변경되었습니다.
SQL> SELECT * FROM V$LOG WHERE STATUS = 'CURRENT';
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TI
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------
3 1 13 52428800 1 NO CURRENT 717353 10/01/09
SQL> EXEC DBMS_LOGMNR_D.BUILD(DICTIONARY_FILENAME=>'dict.ora', dictionary_location=>'C:\oracle\produ
ct\10.2.0\oraLog', options=>dbms_logmnr_d.store_in_flat_file);
PL/SQL 처리가 정상적으로 완료되었습니다.
SQL> select member from v$logfile;
MEMBER
----------------------------------------------------------------------------------------------------
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03.LOG
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01.LOG
SQL> exec dbms_logmnr.add_logfile(options => dbms_logmnr.New, logfilename => 'C:\ORACLE\PRODUCT\10.2
.0\ORADATA\ORCL\REDO02.LOG');
PL/SQL 처리가 정상적으로 완료되었습니다.
SQL> exec dbms_logmnr.start_logmnr(dictfilename=>'C:\oracle\product\10.2.0\oraLog\dict.ora', options
=>DBMS_LOGMNR.COMMITTED_DATA_ONLY);
PL/SQL 처리가 정상적으로 완료되었습니다.
SQL> SELECT OPERATION, SQL_UNDO,SQL_REDO
2 FROM V$LOGMNR_CONTENTS
3 WHERE SEG_NAME='EMP';
OPERATION
--------------------------------
SQL_UNDO
----------------------------------------------------------------------------------------------------
SQL_REDO
----------------------------------------------------------------------------------------------------
UPDATE
update "SCOTT"."EMP" set "SAL" = '1000' where "SAL" = '10000' and ROWID = 'AAAMfPAAEAAAAAgAAI';
update "SCOTT"."EMP" set "SAL" = '10000' where "SAL" = '1000' and ROWID = 'AAAMfPAAEAAAAAgAAI';
SQL>
{column}
{section}
출처 : http://www.dbguide.net/know/know102001.jsp?mode=view&pg=1&idx=2688
엔코아 컨설팅 : 한 준 희 님
출처 : http://radiocom.kunsan.ac.kr/lecture/oracle/backup_restore/what_is_backup.html
데이터베이스 백업과 복구전략 (1) - 오라클의 데이터베이스 백업
Note
"복구에 실패한 DBA는 용서받을 수 있어도, 백업에 실패한 DBA는 용서받을 수 없다"
이 길을 들어서서 제일 먼저 사수에게 들었던 전설과 같다는 말이다.
아무리 시스템의 성능이 고도화되고, 성능개선을 위해 숱한 시간을 허비했어도, 다음날 출근했을 때 어제의 작업, 심지어 그동안의 모든 작업이 허사가 되도록 시스템이 주저앉아버린다면 아무런 소용도 없게 된다.
본 문서는 ORACLE사의 RDBMS를 사용하는 사용자 및 운영자들이 적절한 수준에서 백업전략을 수립하고, 이에 맞는 복구전략을 숙지할 수 있도록 가이드를 하는 목적으로 작성하게 되었다.
본 장은 일반적인 데이터베이스 백업전략에 대해 정리해 보았다.
2. DATABASE-데이터베이스 백업
2.1 백업의 개요 및 목적
데이터베이스 백업이라 함은 기간시스템의 장애가 발생할 경우 이를 복구하기 위한 "보험"과 같은 개념이다. 관계형 데이터베이스를 사용하는데 있어서 가장 큰 장점중의 하나는 데이터베이스의 이상 발생시 언제든지 데이터베이스 RECOVERY를 수행하여 현재의 상황으로 복구할 수 있다는 점이다. 이러한 복구가 가능하기 위해서는 데이터베이스 관리자는 복구가 가능한 상태로 데이터베이스를 운용하여야 한다. 예를 들어 사용자가 NO ARCHIVE MODE로 운용할 경우에는 불행히도 데이터베이스를 처음 생성한 시점이나 전체 백업 받은 시점으로만이 복구가 가능하기 때문이다.
일반적인 경우 백업 정책이 없이 무작정 과다한 양의 백업을 받을 경우 일정 기간이 경과하면 백업에 대한 의미가 희미해지게 되고 정상적인 작업을 수행하지 않을 때, 백업파일이 꼭 필요한 경우 작업을 할 수 없는 경우가 발생할 수도 있다.
데이터베이스 관리자는 백업에 대한 정책을 수립하여 꼭 필요한 데이터를 최소의 약으로 백업을 받고 최소의 시간을 소비- 고객의 MTTR(MEAN TIME TO RECOVERY)을 만족할 수 있는 시간-하면서도 항시 복구가 가능한 상태를 유지하여야 한다.
2.2 주요 고려사항
데이터베이스는 기존의 파일시스템과는 달리 전체 사용자 OBJECT를 하나의 TABLESPACE로 관리하거나 필요에 따라 나누어 사용 및 관리하므로 백업뿐 아니라 복구 시에도 상당히 주의를 요한다. 만일 ARCHIVE LOG 상태에서 운용하고 있는 상태에서 이상이 발생할 경우 복구작업에 필요한 LOG FILE중에 하나의 파일이라도 없어지거나 사용할 수 없는 경우에는 정상적인 복구가 불가능하게 된다.
이러한 불행한 경우를 방지하기 위해서 DBA는 항시 복구가 가능한 상태로 작업하기 위한 백업정책을 수립하여 정확하게 작업하여야 한다.
또한 24 X 7(1년 365일) DOWN TIME없이 운용되는 시스템의 경우 백업 정책의 수립에 COLD BACKUP과 같은 FULL IMAGE 백업이 불가능 할 수 있기에 HOT BACKUP 혹은 EXPORT를 통한 LOGICAL 백업만이 가능할 수 있다. 이런 제약사항으로 인해 혹시 발생할 수 있는 장애에 적절한 대응을 하지 못할 수 있다.
이러한 결정상황을 파악하여 백업정책 수립에 심혈을 기울여야 할 것이며 , 시스템 운용의 묘를 살려야 할 것이다.
또한 HOT BACKUP등의 ONLINE상에서 데이터베이스를 백업하기 위해서는 반드시 ARCHIVE MODE로 운영되어야 한다.
2.3 백업 전략
DBA가 어떠한 방법으로 백업을 유지하느냐에 따라 복구 성공률이나 복구 속도 등이 결정된다 물론 매일 작업 종료 후 전체 데이터베이스에 대하여 FULL BACKUP을 한다면 가장 안전한 백업이라고 볼 수 있으나 실질적으로 백업을 받는데 많은 시간을 요구하므로 현실적으로는 불가능한 작업이라 볼 수 있다.
Note
예 : XXX시스템의 특징은 24시간 365일 무중단 운영을 원칙으로 하고 있고, 타 시스템과의 INTERFACE 대상의 DATA LOAD가 야간에 대량으로 발생하며, 정산 및 온라인 통계작업을 통한 대량의 TRANSACTION이 발생한다.이는 다시 말해 COLD BACKUP을 위한 시스템 중단이 사실상 불가능하다는 말과 같다.
이런 시스템의 특성을 반영한 백업시스템 정책은 현실적으로 적용 가능한 HOT BACKUP을 업무가 집중하지 않는 시간에 수행하는 것으로 정하여야 하며, 단위 업무별로 대량의 변화가 발생할 경우에 데이터의 수정 혹은 삭제, 변화가 발생하기 전에 각 단위 팀의 별도 APPLICATION을 통해 데이터 BACKUP을 수행하는 것으로 한다.
Note
가. 업무수행에 지장을 받지 않는 시간대에 HOT BACKUP을 수행한다.
나. 업무변화가 대량으로 발생하기 전에 APPLICATION을 통한 BACKUP수행
다. 자주 read-write되는 tablespace는 자주 online backup을 수행.
라. 데이터베이스에 구조적인 변화가 생기기 前,後로 full backup을 수행.
마. 이전의 backup본을 최소한 2본 이상 가지고 있을 필요가 있다.
바. 특정 테이블들에 대한 data의 입력 오류로 인해 과거 특정 시점으로의 회귀가 필요하거나, 특정 테이블 데이터의 분실로 인해 다시 복귀를 하고자 할 경우를 대비하여 Logical Backup인 Export를 수시로 받아놓도록 한다.
사. Unrecoverable로 Creation된 Object는 redo log file에 logging되지 않기에 이러한 Object들에 대해서는 Export Utility를 사용하여 Backup하도록 하는 것이 좋으며, 초기 생성 후 정상적인 데이터 입력/수정이 이루어질 경우에는 logging으로 변경하도록 한다.
2.4 백업 방법
2.4.1 Physical Backup
물리적인 데이터베이스 파일을 한 위치에서 다른 위치로 COPY하는 물리적인 복제를 Physical Backup이라 한다. 또한 Physical Backup은 Offline, Online Backup(Without Archiving / With Archiving)으로 나눌 수 있다. 즉 데이터베이스 상태가 Down인 상황에서 Backup을 수행하면 Offline Backup이며 이 백업은 Archive Log파일의 Backup은 불필요하나, 데이터베이스가 Online인 상황에서 Backup을 수행하는 Online Backup인 경우에는 Backup도중에도 Transaction이 발생할 수 있고, 이 기간 중에 발생한 데이터의 보존을 위해 Archive Log를 반드시 백업하고 있어야 한다.
2.4.1.1 Cold Backup (Offline Backup)
데이터베이스를 Shutdown 한 이후 아래와 같은 파일들을 백업 Library로 COPY하여야 한다.
Note
가. DataFiles (V$datafile확인자료)
나. Redo Log Files (V$logfile확인자료)
다. Control Files (V$controlfile확인자료)
라. Parameter Files(initSID.ora, spfileSID, configSID.ora, etc)
{section}
{column:width=10%}
SQL*Plus: Release 10.2.0.1.0 - Production on 수 1월 13 12:54:57 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> conn /as sysdba
연결되었습니다.
SQL> select name from v$controlfile;
NAME
--------------------------------------------------------------------------------
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL01.CTL
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL02.CTL
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL03.CTL
SQL> select file_name from dba_data_files;
FILE_NAME
--------------------------------------------------------------------------------
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\EXAMPLE01.DBF
SQL> select group#, member from v$logfile;
GROUP#
----------
MEMBER
--------------------------------------------------------------------------------
3
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03.LOG
2
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG
1
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01.LOG
SQL> shutdown immediate
데이터베이스가 닫혔습니다.
데이터베이스가 마운트 해제되었습니다\
ORACLE 인스턴스가 종료되었습니다.
SQL> !
SP2-0042: 알 수 없는 명령어 "!" - 나머지 줄 무시.
SQL> host
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\oracle\product\10.2.0\db_1\BIN>copy C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CON
TROL0*.ctl c:\back\
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL01.CTL
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL02.CTL
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL03.CTL
3개 파일이 복사되었습니다.
C:\oracle\product\10.2.0\db_1\BIN>copy C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\*.l
og c:\back\
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01.LOG
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03.LOG
3개 파일이 복사되었습니다.
C:\oracle\product\10.2.0\db_1\BIN>copy C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\*.D
BF c:\back\
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\EXAMPLE01.DBF
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\TEMP01.DBF
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF
6개 파일이 복사되었습니다.
C:\oracle\product\10.2.0\db_1\BIN>dir c:\back
C 드라이브의 볼륨에는 이름이 없습니다.
볼륨 일련 번호: 74A7-34A0
c:\back 디렉터리
2010-01-13 오후 01:48 <DIR> .
2010-01-13 오후 01:48 <DIR> ..
2010-01-13 오후 12:59 7,061,504 CONTROL01.CTL
2010-01-13 오후 12:59 7,061,504 CONTROL02.CTL
2010-01-13 오후 12:59 7,061,504 CONTROL03.CTL
2010-01-13 오후 12:59 104,865,792 EXAMPLE01.DBF
2010-01-13 오후 12:58 52,429,312 REDO01.LOG
2010-01-13 오후 12:58 52,429,312 REDO02.LOG
2010-01-13 오후 12:58 52,429,312 REDO03.LOG
2010-01-13 오후 12:59 293,609,472 SYSAUX01.DBF
2010-01-13 오후 12:59 513,810,432 SYSTEM01.DBF
2010-01-12 오후 10:02 20,979,712 TEMP01.DBF
2010-01-13 오후 12:59 36,708,352 UNDOTBS01.DBF
2010-01-13 오후 12:59 5,251,072 USERS01.DBF
12개 파일 1,153,697,280 바이트
2개 디렉터리 90,021,048,320 바이트 남음
SQL> startup
ORA-32004: obsolete and/or deprecated parameter(s) specified
ORACLE 인스턴스가 시작되었습니다.
Total System Global Area 570425344 bytes
Fixed Size 1250188 bytes
Variable Size 201329780 bytes
Database Buffers 360710144 bytes
Redo Buffers 7135232 bytes
데이터베이스가 마운트되었습니다.
데이터베이스가 열렸습니다.
{column}
{section}
2.4.1.1.1 자동으로 오프라인 백업 실행하기
- 오프라인 백업은 데이터 파일의 크기가 작은 경우 쉽고, 간단하게 실행할 수 있지만, 데이터 파일이 큰 경우는 많은 시간이 소요되므로 스크립트를 사용하여 운영체제의 스케듈러에 의해 백업이 자동으로 실행되도록 할 수 있다.
- 1단계 : 오라클 인스턴스 종료
$ORACLE_HOME/bin/sqlplus system/manager as sysdba
SHUTDOWN IMMEDIATE
EXIT
- 2단계 : 데이타베이스와 관련된 모든 물리적 파일 복사
cp /export/home/oracle/app/oracle/oradata/orcl/*.ctl backup/
cp /export/home/oracle/app/oracle/oradata/orcl/*.dbf backup/
cp /export/home/oracle/app/oracle/oradata/orcl/*.log backup/
cp /export/home/oracle/app/oracle/oradata/orcl/*.ora backup/
- 3단계 : 데이터베이스 다시 시작
$ORACLE_HOME/bin/sqlplus /as sysdba
STARTUP
EXIT
EOF
2.4.1.2 HOT Backup(Online Backup)
데이터베이스가 구동중인 상태에서 datafile을 복사하는 방식으로 Archive Log Mode로 운영되어야 한다.
SQL> ALTER TABLESPACE ...... BEGIN BACKUP;
$ *.DBF의 COPY수행
SQL> ALTER TABLESPACE ..... END BACKUP;
이런 명령을 수행하는 기간 동안에는 해당 TABLESPACE가 HOTBACKUP MODE로 운영중이어서 해당 TABLESPACE안에 있는 TABLE에 대한 DML이 발생할 경우 DATAFILE WRITE가 불가능하기 때문에 REDO LOG에만 기록하는 기록하게 되고, 백업이 완료된 시점에서 LOG에 저장된 변경사항을 다시 Data file에 기록하기 위해 적지 않은 부하가 발생할 수 있다. 그러므로 ONLINE HOT BACKUP을 수행하는 시간은 작업량이 적고, 사용자의 접근을 최소화 할 수 있는 시간을 선정하여야 하며, 최소한의 시간에 HOT BACKUP을 수행할 수 있어야 한다.
또한 BACKUP의 시작과 끝에는 HOT BACKUP의 시작 바로 전까지 발생한 TRANSACTION의 REDO LOG를 CHANGE하도록 하여 ARCHIVING하도록 한다.또한 BACKUP이 종료한 후에도 LOG CHANGE를 하도록 하여 BACKUP중에 발생한 DATA에 대한 REDO LOG 내 변경분을 DATAFILE에 기록 및 ARCHIVING을 통한 ARCHIVE FILE BACKUP을 동시에 수행할 수 있도록 하여야 한다.
SQL> ALTER SYSTEM ARCHIVE LOG CURRENTS;
{section}
{column:width=10%}
SQL*Plus: Release 10.2.0.1.0 - Production on 목 1월 14 15:17:16 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> conn /as sysdba
연결되었습니다.
SQL>
SQL> archive log list;
데이터베이스 로그 모드 아카이브 모드
자동 아카이브 사용
아카이브 대상 USE_DB_RECOVERY_FILE_DEST
가장 오래된 온라인 로그 순서 20
아카이브할 다음 로그 22
현재 로그 순서 22
SQL>
SQL> set linesize 200
SQL>
SQL> select tablespace_name, file_name from dba_data_files;
TABLESPACE_NAME
------------------------------
FILE_NAME
----------------------------------------------------------------------------------------------------
USERS
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF
SYSAUX
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF
UNDOTBS1
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF
TABLESPACE_NAME
------------------------------
FILE_NAME
----------------------------------------------------------------------------------------------------
SYSTEM
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF
EXAMPLE
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\EXAMPLE01.DBF
SQL>
SQL> select * from v$backup;
FILE# STATUS CHANGE# TIME
---------- ------------------ ---------- --------
1 NOT ACTIVE 0
2 NOT ACTIVE 0
3 NOT ACTIVE 0
4 NOT ACTIVE 1015323 10/01/14
5 NOT ACTIVE 0
SQL>
SQL> alter tablespace system begin backup;
테이블스페이스가 변경되었습니다.
SQL> host
---------------------------------------------------------------------------------------------------------------------------------
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\oracle\product\10.2.0\db_1\BIN>copy C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYS
TEM01.DBF c:\back_hot\
1개 파일이 복사되었습니다.
C:\oracle\product\10.2.0\db_1\BIN>
----------------------------------------------------------------------------------------------------------------------------------
SQL> select * from v$backup;
FILE# STATUS CHANGE# TIME
---------- ------------------ ---------- --------
1 ACTIVE 1035965 10/01/14
2 NOT ACTIVE 0
3 NOT ACTIVE 0
4 NOT ACTIVE 1015323 10/01/14
5 NOT ACTIVE
SQL> alter tablespace system end backup;
테이블스페이스가 변경되었습니다.
SQL>
SQL> SELECT SID
2 , SERIAL#
3 , (SELECT SPID FROM V$PROCESS WHERE ADDR = PADDR) AS PID
4 FROM V$SESSION
5 WHERE SID = (SELECT SID FROM V$MYSTAT WHERE ROWNUM = 1);
SID SERIAL# PID
---------- ---------- ------------
147 2 3372
SQL>
SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
데이타베이스가 변경되었습니다.
SQL> SELECT s.sid,
2 s.serial#,
3 pa.value || '/' || LOWER(SYS_CONTEXT('userenv','instance_name')) ||
4 '_ora_' || p.spid || '.trc' AS trace_file
5 FROM v$session s,
6 v$process p,
7 v$parameter pa
8 WHERE pa.name = 'user_dump_dest'
9 AND s.paddr = p.addr
10 AND s.audsid = SYS_CONTEXT('USERENV', 'SESSIONID');
SID SERIAL#
---------- ----------
TRACE_FILE
----------------------------------------------------------------------------------------------------
147 2
C:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\UDUMP/orcl_ora_3372.trc
SQL>
SQL>
{column}
{section}
2.4.2 Logical Backup
Export Utility를 이용한 데이터 백업은 보통 DML 발생빈도가 높아 데이터블록의 활용도나 Capacity를 높이지 못할 경우 데이터블록을 최적화하기 위해 사용할 수 있고, 사용자의 실수 혹은 구조상의 문제로 인해 데이터의 손실을 최소화하기 위해 데이터의 보존을 목적으로 사용하는 방법이다.
Export Utility를 이용한 데이터 백업방법은 Full, User, Table단위의 Export Mode가 있다.
2.4.3 Archive Log File의 Backup
2.4.3.1 Archive Log Mode 구조
오라클에서 Online Backup을 받거나 완벽한 복구작업을 수행하기 위해서는 데이터베이스를 "Archive Log Mode"로 운영하여야 한다.
오라클의 log File기록방법은 "순환"기록방법을 채택하고 있다. 첫 번째 log File을 기입하고 나면 두 번째 것을 기입하고, 그것이 끝나면 세 번째 log를 기록한다. 그리고 마지막 Online Redo Log File을 쓰고 나면 Log Writer(LGWR)가 첫번째 Log File을 다시 선택하여 덮어쓰기 시작한다.
Oracle Archive Log Mode에서 작동하고 있을 때에는 Archive Background Process(ARCH)는 각각의 Redo Log File을 덮어쓰기 전에 그에 대한 복사본을 지정된 디렉토리에 만들게 된다.
CheckPoint가 발생할 때 까지는 Redo Log File은 재사용되지 않으며 ARCH에 의해 물리적으로 Redo Log File은 다시 backup된다.
2.4.3.2 Archive Mode와 No-Archive Mode의 비교
위 그림에서 보는 바와 같이 Redo Log가 덮어 쓰이기 시작하고 Archive Mode가 아니면 Media Recovery는 마지막으로 Full Backup받은 시점으로 밖에 복구가 불가능 하다. 반면에 Archive Mode로 운영되는 데이터베이스는 가장 나중의 변화까지도 복구가 가능하다. Archive Log Mode로 운영 시 log_archive_dest Directory밑에 Archive File이 계속 발생하여 할당된 Space가 부족할 경우 log Change가 발생하지 않아 데이터베이스가 Hang-Up이 될 수 있으므로 Space관리를 유의하여야 한다.
2.4.3.3 Archive Log의 백업
데이터베이스 백업주기 결정시 archive log의 backup주기도 결정되어야 한다.
Archive log는 O/S Backup 을 통해 보관하고, Archive Log가 너무 많이 발생하지 않도록 Archive Log의 Size 즉 Redo Log의 사이즈를 적절히 조절하여야 복구를 위한 필요시간을 줄일 수 있다.
Archive Log는 데이터베이스 백업수행과는 별도로 Space의 여유분을 Check하여 일정수치 이상 Free Space가 부족할 경우 자동적으로 Copy한 다음 삭제하도록 스케쥴링하여야 한다.
2.5 백업 주기
2.5.1 백업주기의 결정
백업의 주기 및 백업 시기, 시간은 어떠한 백업방법을 적용할 것인가와 어느 정도의 Down Time을 허용할 것인가에 따라 결정된다.
즉 Hot Backup만을 허용하는 사이트에는 Transaction양이 최소화되는 시간을 선택하여 백업을 수행할 것이고, 시스템을 사용할 수 없는 최대한의 시간을 1~3시간으로 선정었다면 복구를 위해 주어진 시간이 1~3시간으로 판단되어 이에 맞는 백업주기가 결정되게 된다.
전체 시스템을 모두 Backup하는데 걸리는 시간을 산정하여야 한다. 예를 들어 전체 시스템을 Hot Backup하는데 걸리는 시간이 최대 3시간이 걸린다 할 경우 이를 3일 주기로 전체시스템을 백업할 수 있도록 나눈다면 하루에 백업에 소요되는 시간은 대략 1시간이 될 것이다.
그런데 3일 주기로 백업의 한 사이클이 종료되는 관계로 월요일에 백업한 테이블스페이스에 속한 데이터파일에 문제가 생긴 시기가 수요일 오후라면 약 이틀간 발생한 Archive Log를 이용하여 복구를 하여야 하는데 DataFile, Archive Log Restore 및 복구를 마치는데 주어진 Down Time안에 해결할 수 있는지 판단하여야 한다.
일반적으로 백업의 주기는 1년,1분기,1월,1일에 두고 주기 및 방법을 정한다. 또한 백업의 주기 뿐 아니라 백업한 Media의 보관 주기 또한 백업 및 복구에 큰 영향을 미치는 요소이다.
2.5.2 백업 주기 별 대상 결정
백업의 주기(일단위,주단위,월단위,분기단위,년단위,기타)별로 백업 대상을 선정하여 백업 매체를 선정하고, 백업대상을 LIST-UP한 다음 백업하도록 한다.
2.5.2.1 백업 주기
요일 대상 월 화 수 목 금 토 일
백업 대상 A B C D E F ALL
TBS
백업사이즈 354G 296G 338G 354G 296G 338G 998G
http://www.dbguide.net/know/know102001.jsp?mode=view&pg=1&idx=2689
데이터베이스 백업과 복구전략 (2) - 오라클의 데이터베이스 복구
3. DATABASE 복구
3.1 개념
데이터베이스에 이상이 생겨 시스템의 정상작동이 불가능할 경우 백업한 자료를 이용하여 장애발생시점까지의 데이터를 복구하거나, 일정 시간을 기준으로 하여 데이터베이스의 운용시점을 돌려놓으려 하는 작업을 데이터베이스 복구라 한다. 데이터베이스 복구를 위해서는 아래와 같은 환경이 마련되어 있어야 한다.
3.2 복구를 위한 주변 환경
데이터베이스를 복구하기 위해서는 아래와 같은 주변환경이 마련되어 있어야 한다.
Note
가. 장애의 원인은 무엇인지 알 수 있는 환경
- 장애의 원인은 보통 trace file이나 오라클의 alertSID.log파일에 기록되는데 이 파일을 근거로 하여 장애의 원인을 파악할 수 있는 환경이 되어야 한다.
나. 복구를 위해 기존에 백업된 자료가 있는가?
- 장애 유형별로 복구방법이 다르고 복구하고자 하는 시점까지 정확하게 복구가 가능하기 위한 필요한 파일들이 백업이 되어 있어야 한다.
다. 시스템의 가동을 중단할 수 있는가?
- 장애 유형별로 시스템을 가동하지 못하고 사용자의 접속통제가 불가피한 경우 접근통제는 장애진단 후 즉각적으로 처리 될 수 있어야 한다.
라. 복구를 위한 해당 프로덕트 엔지니어에게 기술지원을 받을 준비는 되어 있는가?
- 데이터베이스 전문가와 상의하여야 할 경우는 없는지, 만약 데이터베이스 전문가와의 연락 혹은 방문지원이 필요한 경우 Down Time에 대한 대책은 마련되어 있는가?
3.3 장애 유형별 복구절차
3.3.1 데이터파일 손상 시 복구 절차
- System Tablespace가 아닌 Tablespace의 데이터파일 손상이 발생하여 복구를 수행하여야 할 경우에는 에러메세지가 달리 return될 경우가 있다.
이 경우 에러메세지에 따라 1-1 ~ 1-4까지 해당되는 부분을 참조하여 복구하도록 한다.
1-1. SYSTEM Tablespace Datafile이 아닌 Datafile의 Recovery
- ORA-1116, ORA-1110, ORA-736 8을 Return하는 경우에는 아래의 Recovery 수행 방법을 통해 Recovery한다.
{info:title=Note}
oerr ora 1116
01116, 00000, "error in opening database file %s"
*Cause: Usually the file is not accessible.
*Action: Restore the database file.
oerr ora 1110
01110, 00000, "data file %s: '%s'"
*Cause: Reporting file name for details of another error
*Action: See associated error message
oerr ora 7368
07368, 00000, "sfofi: open error, unable to open database file."
*Cause: Open system call returned an error.
*Action: Check errno. Verify existence, and permissions on database files.
현상 및 Error 내용
{section}
{column:width=10%}
SQL> insert into bonus
values('EEEE','EEEE',99999,999);
insert into bonus
ERROR at line 1:
ORA-01116: error in opening database file 5
ORA-01110: data file 5: '/u02/ORACLE/BACKUP/usrBACKUP.dbf'
ORA-07368: sfofi: open error, unable to open database file.
IBM AIX RISC System/6000 Error: 2: No such file or directory
{column}
{section}
위와 같은 Error가 Return 될 것이다. 그러나 위와 같이 Datafile 이 손상을 입었음에도 Error를 바로 Return하지 않고 정상적으 로 DML이나 DDL을 사용할 수 있을 지도 모른다. 왜냐하면 아직 SGA의 Database buffer안에 Object들이 존재하는 경우는 DBWR가 Datafile에 Database buffer의 내용을 write하기 전까지 는 Error 없이 정상적으로 작업을 수행할 것이며 Datafile에 write하려는 순간에야 비로서 Error를 Return 할 것이다.
1) 닫힌 Recovery 수행 방법
1. V$DATAFILE에서 Datafile을 Check한다.
{section}
{column:width=10%}
SVRMGR> select FILE#,STATUS,ENABLED,BYTES,NAME
2> from v$Datafile;
FILE# STATUS ENABLED BYTES NAME
----- ------- --------- ------- --------------
1 SYSTEM READ WRITE 20971520 /u02/ORACLE/BACKUP/systBACKUP.dbf
2 ONLINE READ WRITE 41943040 /u02/ORACLE/BACKUP/rbsBACKUP.dbf
3 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/tempBACKUP.dbf
4 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/toolBACKUP.dbf
5 ONLINE READ WRITE 0 /u02/ORACLE/BACKUP/usrBACKUP.dbf
5 rows selected.
{column}
{section}
2. Physical한 storage directory를 Check해본다.
$ ls
ctrl1BACKUP.ctl log1BACKUP.dbf log2_m_BACKUP.dbf tempBACKUP.dbf
ctrl2BACKUP.ctl log1_m_BACKUP.dbf rbsBACKUP.dbf toolBACKUP.dbf
ctrl3BACKUP.ctl log2BACKUP.dbf systBACKUP.dbf
3. ABORT Option으로 SHUTDOWN 한다.
{section}
{column:width=10%}
SVRMGR> shutdown ABORT
ORACLE instance shut down.
{column}
{section}
4. Datafile이 손상되었음을 확인했으면 Online으로 Backup받은 해당 Datafile을 host command로 COPY한다.
$ cp /admhome/oracle/product/stage/backup/hot/ usrBACKUP.dbf /u02/ORACLE/BACKUP
$ ls -l rw-r
1 oracle dba 10489856 Oct 17 15:48 usrBACKUP.dbf
5. STARTUP MOUNT한다. Database를 Open까지 하려하면 ORA-1113 Error를 Return할 것이다.
{section}
{column:width=10%}
SVRMGR> startup
ORACLE instance started.
Database mounted.
ORA-01113: file 5 needs media recovery
ORA-01110: data file 5: '/u02/ORACLE/BACKUP/usrBACKUP.dbf'
{column}
{section}
6. V$DATAFILE에서 Datafile이 ONLINE 상태인지 확인한다. 만약 OFFLINE이라면 ALTER DATABASE DATAFILE '/u02/ORACLE/BACKUP/usrBACKUP.dbf' ONLINE ; 을 수행한다.
{section}
{column:width=10%}
SVRMGR> select FILE#,STATUS,ENABLED,BYTES,NAME
2> from v$Datafile;
FILE# STATUS ENABLED BYTES NAME
------- ------- ---------- --------- ---------
1 SYSTEM READ WRITE 20971520 /u02/ORACLE/BACKUP/systBACKUP.dbf
2 ONLINE READ WRITE 41943040 /u02/ORACLE/BACKUP/rbsBACKUP.dbf
3 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/tempBACKUP.dbf
4 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/toolBACKUP.dbf
5 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/usrBACKUP.dbf
5 rows selected.
{column}
{section}
7. 손상된 Datafile을 RECOVER DATAFILE Command로 Recovery한다.
{section}
{column:width=10%}
SVRMGR> recover Datafile '/u02/ORACLE/BACKUP/usrBACKUP.dbf';
ORA-00279: Change 6716 generated at 10/15/96 15:58:38 needed for thread 1
ORA-00289: Suggestion : /admhome/oracle/admin/BACKUP/arch/arch_49.arc
ORA-00280: Change 6716 for thread 1 is in sequence #49
Specify log: {=suggested | filename | AUTO | CANCEL}
auto
Log applied.
{column}
{section}
Physical directory에 Restore된 Datafile을 Archive log를 적용하여 Error가 발생했던 시점까지 Recovery 한다. 이때 Archive log를 적용함에 있어서 AUTO라고 명시적으로 기술해주면 자동으로 Recovery에 필요한 모든 Archive log를 적용한다.
8. Database를 OPEN한다.
{section}
{column:width=10%}
SVRMGR> alter database open;
Statement processed.
{column}
{section}
9. V$DATAFILE에서 Datafile의 상태를 Check한다.
{section}
{column:width=10%}
SVRMGR> select FILE#,STATUS,ENABLED,BYTES,NAME
2> from v$Datafile;
FILE# STATUS ENABLED BYTES NAME
-------- ------- ---------- ---------- -------
1 SYSTEM READ WRITE 20971520 /u02/ORACLE/BACKUP/systBACKUP.dbf
2 ONLINE READ WRITE 41943040 /u02/ORACLE/BACKUP/rbsBACKUP.dbf
3 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/tempBACKUP.dbf
4 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/toolBACKUP.dbf
5 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/usrBACKUP.dbf
5 rows selected.
{column}
{section}
10. 마지막으로 SQLPLUS로 들어가 data가 복구되었는지 확인한다.
1) 오픈 Recovery 수행 방법
{section}
{column:width=10%}
SQL> conn /as sysdba
연결되었습니다.
SQL>
SQL> select table_name, tablespace_name from scott.user_tables;
TABLE_NAME TABLESPACE_NAME
------------------------------ ------------------------------
DEPT USERS
EMP USERS
BONUS USERS
SALGRADE USERS
SQL>
SQL> alter tablespace users begin backup;
테이블스페이스가 변경되었습니다.
SQL>
SQL> host;
SQL> --users 백업
SQL>
SQL> alter tablespace users end backup;
테이블스페이스가 변경되었습니다.
SQL> host;
SQL> --users 삭제
SQL> select * from scott.dept;
select * from scott.dept
*
1행에 오류:
ORA-01116: 4 데이터베이스 파일 열기에 오류입니다
ORA-01110: 4 데이터 파일: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF'
ORA-27041: 파일을 열 수 없습니다
OSD-04002: 파일을 열 수 없음
O/S-Error: (OS 2) 지정된 파일을 찾을 수 없습니다.
SQL> alter system switch logfile;
시스템이 변경되었습니다.
SQL> select * from v$recover_file;
FILE# ONLINE ONLINE_
---------- ------- -------
ERROR CHANGE#
----------------------------------------------------------------- ----------
TIME
--------
4 OFFLINE OFFLINE
FILE NOT FOUND 0
SQL> recover datafile 4;
ORA-00283: 복구 세션이 오류로 인하여 취소되었습니다
ORA-01110: 4 데이터 파일: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF'
ORA-01157: 데이터 4 파일을 식별 또는 잠금 할 수 없습니다- DBWR 추적 파일을
보십시오
ORA-01110: 4 데이터 파일: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF'
SQL> -- 백업 릴리즈
SQL>
SQL> recover datafile 4;
ORA-00279: 변환 1085794가 (01/15/2010 19:35:00에서 생성된) 스레드 1에
필요합니다
ORA-00289: 제안 :
C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2010_01_15\O1_MF_1_
23_%U_.ARC
ORA-00280: 변환 1085794(스레드 1를 위한)가 시퀀스번호 23에 있습니다
로그 지정: {<RET>=suggested | filename | AUTO | CANCEL}
auto
로그가 적용되었습니다.
매체 복구가 완료되었습니다.
SQL> select * from v$recover_file;
선택된 레코드가 없습니다.
SQL> select file#, name, status from v$datafile_header where file# = 4;
FILE#
----------
NAME
----------------------------------------------------------------------------
STATUS
-------
4
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF
OFFLINE
SQL> alter database datafile 4 online;
데이타베이스가 변경되었습니다.
SQL> select count(*) from scott.emp;
COUNT(*)
----------
14
SQL>
{column}
{section}
3) 임시 디렉토리를 이용한 Recovery 방법
{section}
{column:width=10%}
SQL> conn /as sysdba
연결되었습니다.
SQL>
SQL> shotdown abort;
SP2-0734: "shotdown a..."(으)로 시작되는 알 수 없는 명령 - 나머지 줄은 무시되었습니다.
SQL> shutdown abort;
ORACLE 인스턴스가 종료되었습니다.
SQL>
SQL> host
SQL> startup
ORA-32004: obsolete and/or deprecated parameter(s) specified
ORACLE 인스턴스가 시작되었습니다.
Total System Global Area 570425344 bytes
Fixed Size 1250188 bytes
Variable Size 180358260 bytes
Database Buffers 381681664 bytes
Redo Buffers 7135232 bytes
데이터베이스가 마운트되었습니다.
ORA-01157: 데이터 4 파일을 식별 또는 잠금 할 수 없습니다- DBWR 추적 파일을
보십시오
ORA-01110: 4 데이터 파일: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF'
SQL> alter database datafile 4 offline;
데이타베이스가 변경되었습니다.
SQL>
SQL> alter database open;
데이타베이스가 변경되었습니다.
SQL> select file#, name, status from v$datafile_header where file#= 4;
FILE#
----------
NAME
--------------------------------------------------------------------------------
STATUS
-------
4
OFFLINE
SQL> select file_name from dba_data_files;
FILE_NAME
--------------------------------------------------------------------------------
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\EXAMPLE01.DBF
SQL> --백업본을 다른 폴더에 복사.
SQL>
SQL> alter database rename file 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF' to 'C:\ORACLE\PR
ODUCT\10.2.0\ORADATA\ORCL2\USERS01.DBF'
2 ;
데이타베이스가 변경되었습니다.
SQL> select * from v$recover_file;
FILE# ONLINE ONLINE_
---------- ------- -------
ERROR CHANGE#
----------------------------------------------------------------- ----------
TIME
--------
4 OFFLINE OFFLINE
1085794
10/01/15
SQL> recover datafile 4;
ORA-00279: 변환 1085794가 (01/15/2010 19:35:00에서 생성된) 스레드 1에
필요합니다
ORA-00289: 제안 :
C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2010_01_15\O1_MF_1_
23_%U_.ARC
ORA-00280: 변환 1085794(스레드 1를 위한)가 시퀀스번호 23에 있습니다
로그 지정: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: 변환 1085982가 (01/15/2010 19:40:23에서 생성된) 스레드 1에
필요합니다
ORA-00289: 제안 :
C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2010_01_15\O1_MF_1_
24_%U_.ARC
ORA-00280: 변환 1085982(스레드 1를 위한)가 시퀀스번호 24에 있습니다
ORA-00278: 이 복구를 위해 로그
'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2010_01_15\O1_MF_1
_23_5O0KJQTV_.ARC' 파일은 더이상 필요하지 않습니다
로그가 적용되었습니다.
매체 복구가 완료되었습니다.
SQL> alter database datafile 4 online;
데이타베이스가 변경되었습니다.
SQL> select file_name from dba_data_files;
FILE_NAME
--------------------------------------------------------------------------------
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL2\USERS01.DBF
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\EXAMPLE01.DBF
SQL>
{column}
{section}
4) 백업하지 않은 데이터 복구
{section}
{column:width=10%}
SQL> conn /as sysdba
연결되었습니다.
SQL> create tablespace new_tb datafile 'C:\oracle\product\10.2.0\oradata\orcl2/new_tb01.dbf" size 50
m;
create tablespace new_tb datafile 'C:\oracle\product\10.2.0\oradata\orcl2/new_tb01.dbf" size 50m
*
1행에 오류:
ORA-01756: 단일 인용부를 지정해 주십시오
SQL> create tablespace net_tb datafile 'C:\oracle\product\10.2.0\oradata\orcl2/new_tb01.dbf' size 50
m;
테이블스페이스가 생성되었습니다.
SQL>
SQL> create table test tablespace net_tb
2 as
3 select level num
4 from dual
5 connect by level < 1000;
테이블이 생성되었습니다.
SQL> select count(*) from test;
COUNT(*)
----------
999
SQL> commit;
커밋이 완료되었습니다.
SQL> shutdown abort;
ORACLE 인스턴스가 종료되었습니다.
SQL> host -- net_tb삭제
SQL> startup;
ORA-32004: obsolete and/or deprecated parameter(s) specified
ORACLE 인스턴스가 시작되었습니다.
Total System Global Area 570425344 bytes
Fixed Size 1250188 bytes
Variable Size 184552564 bytes
Database Buffers 377487360 bytes
Redo Buffers 7135232 bytes
데이터베이스가 마운트되었습니다.
ORA-01157: 데이터 6 파일을 식별 또는 잠금 할 수 없습니다- DBWR 추적 파일을
보십시오
ORA-01110: 6 데이터 파일: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL2\NEW_TB01.DBF'
SQL> alter tablespace net_tb offline;
alter tablespace net_tb offline
*
1행에 오류:
ORA-01109: 데이터베이스가 개방되지 않습니다
SQL> alter database datafile 6 offline;
데이타베이스가 변경되었습니다.
SQL> alter database open;
데이타베이스가 변경되었습니다.
SQL> alter database create datafile 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL2\NEW_TB01.DBF' as 'C:\ORA
CLE\PRODUCT\10.2.0\ORADATA\ORCL2\NEW_TB01.DBF';
데이타베이스가 변경되었습니다.
SQL> recover datafile 6;
매체 복구가 완료되었습니다.
SQL> alter database datafile 6 online;
데이타베이스가 변경되었습니다.
SQL> select count(*) from test;
COUNT(*)
----------
999
SQL>
{column}
{section}
1-2. SYSTEM Tablespace Datafile이 아닌 Datafile의 Recovery 2
ORA-1578, ORA-1110을 Return하는 경우에는 아래의 Recovery 수행 방법을 통해 Recovery한다.
Note
oerr ora 1578
01578, 00000, "ORACLE data block corrupted (file # %s, block # %s)"
*Cause: The data block indicated was corrupted mostly due to software errors.
*Action: Try to restore the segment containing the block indicated. This may involve dropping the segment and recreating it. If there is a trace file, report the errors in it to your ORACLE representative.
oerr ora 1110
01110, 00000, "data file %s: '%s'"
*Cause: Reporting file name for details of another error
*Action: See associated error message
현상 및 Error 내용
{section}
{column:width=10%}
SQL> select * from bonus;
ERROR:
ORA-01578:ORACLE data block corrupted(file #5, block # 13)
ORA-01110:data file 5: '/u02/ORACLE/BACKUP/usrBACKUP.dbf'
no rows selected
{column}
{section}
위에서 알 수 있듯이 Datafile의 1개 Block이 손상되었다. 이 경우에도 Datafile이 손상을 입었음에도 Error(ORA-1578)를 바로 Return하지 않고 정상적으로 DML이나 DDL을 사용할 수 있을 지도 모른다. 아직 SGA안에 있는 Object들이 있기 때문이다. 그러나 손상된 Block(Blocksize=4096)에 있는 Data에 대해 Access 하려하면 위와 같은 Error를 Return 할 것이다.
Recovery 수행 방법
1. 일단 V$DATAFILE을 확인해본다.
{section}
{column:width=10%}
SVRMGR> select FILE#,STATUS,ENABLED,BYTES,NAME
2> from v$Datafile;
FILE# STATUS ENABLED BYTES NAME
------- ------- -------- -------- --------
1 SYSTEM READ WRITE 20971520 /u02/ORACLE/BACKUP/systBACKUP.dbf
2 ONLINE READ WRITE 41943040 /u02/ORACLE/BACKUP/rbsBACKUP.dbf
3 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/tempBACKUP.dbf
4 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/toolBACKUP.dbf
5 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/usrBACKUP.dbf
5 rows selected.
{column}
{section}
2. Physical한 storage directory를 Check해본다.
Note
$ ls -l
rw-r
- 1 oracle dba 52432896 Oct 17 17:53 usrBACKUP.dbf
확인해 보면 Datafile은 그대로 존재한다.
3. ABORT Option으로 Shutdown 한다.
{section}
{column:width=10%}
SVRMGR> shutdown ABORT
ORACLE instance shut down.
이 경우에 NORMAL이나 IMMEDIATE로 Shutdown하려하면 다음과 같은 Error가 발생할 것이다.
ORA-01122: database file 5 failed verification check
ORA-01110: data file 5: '/u02/ORACLE/BACKUP/usrBACKUP.dbf'
ORA-01208: data file is an old version - not accessing current version
SVRMGR> !oerr ora 1122
01122, 00000, "database file %s failed verification check"
*Cause: The information in this file is inconsistent with information from the control file. See accompanying message for reason.
*Action: Make certain that the db files and control files are the correct files for this database.
{column}
{section}
4. Datafile이 손상되었음을 확인했으면 Online으로 Backup받은 해당 Datafile을 host command로 COPY한다.
$ cp /admhome/oracle/product/stage/backup/hot/ usrBACKUP.dbf /u02/ORACLE/BACKUP
$ ls -l rw-r
1 oracle dba 10489856 Oct 17 15:48 usrBACKUP.dbf
5. STARTUP MOUNT한다. Database를 Open까지 하려하면 ORA-1113 Error를 Return할 것이다.
{section}
{column:width=10%}
SVRMGR> startup
ORACLE instance started.
Database mounted.
ORA-01113: file 5 needs media recovery
ORA-01110: data file 5: '/u02/ORACLE/BACKUP/usrBACKUP.dbf'
{column}
{section}
6. V$DATAFILE에서 Datafile이 ONLINE 상태인지 확인한다. 만약 OFFLINE이라면 ALTER DATABASE DATAFILE '/u02/ORACLE/BACKUP/usrBACKUP.dbf' ONLINE ; 을 수행한다.
{section}
{column:width=10%}
SVRMGR> select FILE#,STATUS,ENABLED,BYTES,NAME
2> from v$Datafile;
FILE# STATUS ENABLED BYTES NAME
------ ------- -------- ----------- ---------
1 SYSTEM READ WRITE 20971520 /u02/ORACLE/BACKUP/systBACKUP.dbf
2 ONLINE READ WRITE 41943040 /u02/ORACLE/BACKUP/rbsBACKUP.dbf
3 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/tempBACKUP.dbf
4 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/toolBACKUP.dbf
5 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/usrBACKUP.dbf
5 rows selected.
{column}
{section}
7. 손상된 Datafile을 RECOVER DATAFILE command로 Recovery한다.
{section}
{column:width=10%}
SVRMGR> recover Datafile '/u02/ORACLE/BACKUP/usrBACKUP.dbf';
ORA-00279: Change 6890 generated at 10/17/96 16:25:37 needed for thread 1
ORA-00289: Suggestion : /admhome/oracle/admin/BACKUP/arch/arch_76.arc
ORA-00280: Change 6890 for thread 1 is in sequence #76
ORA-00278: Logfile '/admhome/oracle/admin/BACKUP/arch/arch_75.arc' no longer needed fy
Log applied.
Media recovery complete.
{column}
{section}
8. Database를 OPEN한다.
SVRMGR> alter database open;
Statement processed.
9. V$DATAFILE에서 Datafile의 상태를 Check한다.
{section}
{column:width=10%}
SVRMGR> select FILE#,STATUS,ENABLED,BYTES,NAME
2> from v$Datafile;
FILE# STATUS ENABLED BYTES NAME
---------- ------------- --------------------
1 SYSTEM READ WRITE 20971520 /u02/ORACLE/BACKUP/systBACKUP.dbf
2 ONLINE READ WRITE 41943040 /u02/ORACLE/BACKUP/rbsBACKUP.dbf
3 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/tempBACKUP.dbf
4 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/toolBACKUP.dbf
5 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/usrBACKUP.dbf
5 rows selected.
{column}
{section}
10. 마지막으로 SQL*PLUS로 들어가 data가 복구되었는지 확인한다.
1-3. SYSTEM Tablespace Datafile이 아닌 Datafile의 Recovery 3
ORA-376, ORA-1110을 Return 하는 경우에는 아래의 Recovery 절차를 통해 수행한다.
Note
oerr ora 376
00376, 00000, "file %s cannot be read at this time"
*Cause: attempting to read from a file that is not readable. Most likely the file is offline.
*Action: Check the state of the file. Bring it online
oerr ora 1110
01110, 00000, "data file %s: '%s'"
*Cause: Reporting file name for details of another error
*Action: See associated error message
현상 및 Error 내용
{section}
{column:width=10%}
SQL> insert into bonus
2 values ('MMMMMM','JJJJJJ',999999,888888);
1 row created.
SQL> /
insert into bonus
*
ERROR at line 1:
ORA-00376: file 5 cannot be read at this time
ORA-01110: data file 5: '/u02/ORACLE/BACKUP/usrBACKUP.dbf'
{column}
{section}
위 Error를 보면 Datafile이 손상되었음을 알 수 있다. 현재 이 Datafile은 알 수 없는 손상으로 인해 ORACLE에 의해 내부적으로 Offline되었고 V$DATAFILE에서 Datafile의 Status를 보면 RECOVER로 나타남을 보게 될 것이다. 이처럼 ORA-376같은 Error가 발생하면 다음과 같이 복구한다.
Recovery 수행 방법
1. V$DATAFILE을 확인해 본다.
{section}
{column:width=10%}
SVRMGR> select FILE#,STATUS,ENABLED,BYTES,NAME
2> from v$Datafile;
FILE# STATUS ENABLED BYTES NAME
------ ------- ----------- -------- --------
1 SYSTEM READ WRITE 20971520 /u02/ORACLE/BACKUP/systBACKUP.dbf
2 ONLINE READ WRITE 41943040 /u02/ORACLE/BACKUP/rbsBACKUP.dbf
3 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/tempBACKUP.dbf
4 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/toolBACKUP.dbf
5 RECOVER READ WRITE 10485760 /u02/ORACLE/BACKUP/usrBACKUP.dbf
5 rows selected.
{column}
{section}
2. 정상적인 Datafile을 Restore한다.
$ cp /admhome/oracle/product/stage/backup/hot/ usr* /u02/ORACLE/BACKUP
$ ls -l rw-r
1 oracle dba 10489856 Oct 17 19:21 usrBACKUP.dbf
Recovery 하기 전에 다른 Datafile의 복구 과정처럼 Shutdown을 하지 않고 OPEN 상태에서 Recovery가 가능하다.
SVRMGR>Recover Tablespace users;
또는 Recover Datafile '/u02/ORACLE/BACKUP;
ORA-00279: Change 6716 generated at 10/15/96 15:58:38 needed for thread 1
ORA-00289: Suggestion : /admhome/oracle/admin/BACKUP/arch/arch_49.arc
ORA-00280: Change 6716 for thread 1 is in sequence #49
Specify log: =suggested
auto
Log applied.
3. Media recovery complete.
Datafile의 상태를 확인한다.
{section}
{column:width=10%}
SVRMGR> select FILE#,STATUS,ENABLED,BYTES,NAME
2> from v$Datafile;
FILE# STATUS ENABLED BYTES NAME
------ ------- -------- --------- ---------
1 SYSTEM READ WRITE 20971520 /u02/ORACLE/BACKUP/systBACKUP.dbf
2 ONLINE READ WRITE 41943040 /u02/ORACLE/BACKUP/rbsBACKUP.dbf
3 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/tempBACKUP.dbf
4 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/toolBACKUP.dbf
5 OFFLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/usrBACKUP.dbf
5 rows selected.
위에서와 같이 Recovery가 성공적으로 끝난 Datafile은 Status가 OFFLINE으로 나타난다. 고로 이 상태에서 Table에 대해 access 하려하면 맨 처음 Datafile이 손상되었을 때에 나타난 Error와 똑같은 Error가 Return될 것이다. 그렇다고 Recovery가 실패한 것은 절대 아니다. 이러한 Error가 나타나는 것은 V$DATAFILE 에서 보듯이 Recovery된 Datafile이 OFFLINE 되어 있기 때문이 다. 그러므로 ALTER DATABASE DATAFILE filename ONLINE command를 사용하여 Tablespace를 ONLINE으로 변경시켜야 Table에 대한 access가 가능할 것이다.
SQL> select * from bonus;
ERROR:
ORA-00376: file 5 cannot be read at this time
ORA-01110: data file 5: '/u02/ORACLE/BACKUP/usrBACKUP.dbf'
{column}
{section}
5. Tablespace를 ONLINE으로 변경한다.
SVRMGR> alter database Datafile '/u02/ORACLE/BACKUP/usrBACKUP.dbf' online;
Statement processed.
1-4. SYSTEM Tablespace Datafile의 Recovery
SYSTEM Tablespace의 Datafile이 손상을 입었을 경우에는 Error 가 2가지 Type으로 나타난다. ORA-604, ORA-1116, ORA-7368을 Return하는 경우와 ORA-1092가 나타나는 경우이다. 아래의 Recovery 수행 방법을 통해 Recovery한다.
Note
oerr ora 604
00604, 00000, "error occurred at recursive SQL level %s"
*Cause: An error occurred while processing a recursive SQL statement(a statement applying to internal dictionary tables).
*Action: If the situation described in the next error on the stack can be corrected, do so; otherwise contact Oracle Support.
oerr ora 1116
01116, 00000, "error in opening database file %s"
*Cause: Usually the file is not accessible.
*Action: Restore the database file.
oerr ora 1092
01092, 00000, "ORACLE instance terminated. Disconnection forced"
*Cause: The instance this process was connected to was terminated abnormally, probably via a shutdown abort. This process
was forced to disconnect from the instance.
*Action: When instance has been restarted, retry action.
현상 및 Error 내용
{section}
{column:width=10%}
SQL> insert into bonus
2 values('EEEE','EEEE',99999,999);
1 row created.
SQL> /
insert into bonus
*
ERROR:
ORA-00604: error occurred at recursive SQL level 1
ORA-01116: error in opening database file 1
ORA-01110: data file 1: '/u02/ORACLE/BACKUP/systBACKUP.dbf'
ORA-07368: sfofi: open error, unable to open database file.
IBM AIX RISC System/6000 Error: 2: No such file or directory
위와 같은 Error가 Return 될 것이다. 그러나 위와 같이 SYSTEM Tablespace의 Datafile이 손상을 입었음에도 Error를 바로 Return하지 않고 정상적으로 DML을 사용할 수 있을 지도 모른다. 기본적으로 ORACLE은 Data를 Block단위로 access하 여 SGA의 Database Buffer에 올려 놓고 Data에 대한 변화를 작 업 한다. 현재 Recovery test를 위한 Instance인 BACKUP은 'BLOCK_SIZE = 4096'으로 설정되어 Creation 되어 있으므로 하 나의 Table을 Select했을지라도 그 Table이 있는 Block과 그 Table이 참조하는 Data Dictionary를 같이 Database Buffer와 Data Dictionary Cache에 올린다. 그러므로 현재 SGA안에 올려 진 Data Dictionary를 Access하려하면 System Tablespace Datafile이 없음에도 Dictionary를 볼 수 있지만 만약 아직 SGA 의 Dictionary Cache에 올라와 있지 않은 Dictionary를 Access 하려하거나 특정 시점(Dictionary Cache의 것을 SYSTEM Tablespace Datafile에 Write하려 할 때)에 도달하면 위와 같은 Error를 Return 할 것이다. Error Message가 다음과 같이 Return 되더라도 다음의 Action에 따라 Recovery를 수행한다.
SQL> insert into bonus
2 values('EEEEEEE','EEEEEE',888888,8888888);
insert into bonus
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-01578: ORACLE data block corrupted (file # 1, block # 259)
ORA-01110: data file 1: '/u02/ORACLE/BACKUP/systBACKUP.dbf'
또는
SQL> /
insert into bonus
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
{column}
{section}
Recovery 수행 방법
1. V$DATAFILE에서 Datafile을 Check한다.
{section}
{column:width=10%}
SVRMGR> select FILE#,STATUS,ENABLED,BYTES,NAME
2> from v$Datafile;
FILE# STATUS ENABLED BYTES NAME
----- ------- --------- ------------ ---------
1 SYSTEM READ WRITE 20971520 /u02/ORACLE/BACKUP/systBACKUP.dbf
2 ONLINE READ WRITE 41943040 /u02/ORACLE/BACKUP/rbsBACKUP.dbf
3 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/tempBACKUP.dbf
4 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/toolBACKUP.dbf
5 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/usrBACKUP.dbf
5 rows selected.
{column}
{section}
2. Physical한 Storage directory를 Check해본다.
$ ls /u02/ORACLE/BACKUP
ctrl1BACKUP.ctl log1BACKUP.dbf log2_m_BACKUP.dbf tempBACKUP.dbf
ctrl2BACKUP.ctl log1_m_BACKUP.dbf rbsBACKUP.dbf toolBACKUP.dbf
ctrl3BACKUP.ctl log2BACKUP.dbf
3. ABORT Option으로 Shutdown 한다.
{section}
{column:width=10%}
SVRMGR> shutdown
ORACLE instance shut down.
이 경우에 NORMAL이나 IMMEDIATE로 SHUTDOWN하려하면 다음과 같은 Error가 발생할 것이다.
ORA-01122: database file 5 failed verification check
ORA-01110: data file 5: '/u02/ORACLE/BACKUP/usrBACKUP.dbf'
ORA-01208: data file is an old version - not accessing current version
SVRMGR> !oerr ora 1122
01122, 00000, "database file %s failed verification check"
*Cause: The information in this file is inconsistent with informationfrom the control file. See accompanying message for reason.
*Action: Make certain that the db files and control files are the correct files for this database.
{column}
{section}
4. Datafile이 손상되었음을 확인했으면 Online으로 Backup받은 해당 Datafile을 host command로 COPY한다.
$ cp /admhome/oracle/product/stage/backup/hot/ systBACKUP.dbf /u02/ORACLE/BACKUP
$ ls -l rw-r
1 oracle dba 20971520 Oct 17 15:48 systBACKUP.dbf
5. STARTUP MOUNT한다. Database를 Open까지 하려하면 ORA-1113 Error를 Return할 것이다.
{section}
{column:width=10%}
SVRMGR> startup
ORACLE instance started.
Database mounted.
ORA-01113: file 5 needs media recovery
ORA-01110: data file 5: '/u02/ORACLE/BACKUP/usrBACKUP.dbf'
{column}
{section}
6. 손상된 Datafile을 RECOVER DATAFILE command로 Recovery한다.
{section}
{column:width=10%}
SVRMGR> recover Datafile '/u02/ORACLE/BACKUP/systBACKUP.dbf';
ORA-00279: Change 6716 generated at 10/15/96 15:58:38 needed for thread 1
ORA-00289: Suggestion : /admhome/oracle/admin/BACKUP/arch/arch_49.arc
ORA-00280: Change 6716 for thread 1 is in sequence #49
Specify log: {=suggested | filename | AUTO | CANCEL}
auto
Log applied.
{column}
{section}
7. Database를 OPEN한다.
SVRMGR> alter database open;
Statement processed.
8. V$DATAFILE에서 Datafile의 상태를 Check한다.
{section}
{column:width=10%}
SVRMGR> select FILE#,STATUS,ENABLED,BYTES,NAME
2> from v$Datafile;
FILE# STATUS ENABLED BYTES NAME
------ ------- ---------- --------- ---------
1 SYSTEM READ WRITE 20971520 /u02/ORACLE/BACKUP/systBACKUP.dbf
2 ONLINE READ WRITE 41943040 /u02/ORACLE/BACKUP/rbsBACKUP.dbf
3 ONLINE READ WRITE 52428800 /u02/ORACLE/BACKUP/tempBACKUP.dbf
4 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/toolBACKUP.dbf
5 ONLINE READ WRITE 10485760 /u02/ORACLE/BACKUP/usrBACKUP.dbf
5 rows selected.
{column}
{section}
9. 마지막으로 SQLPLUS로 들어가 data가 복구되었는지 확인한다.
{section}
{column:width=10%}
SQL*Plus: Release 10.2.0.1.0 - Production on 금 1월 15 16:18:55 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> conn scott/tiger
연결되었습니다.
SQL>
SQL> set linesize 200
SQL>
SQL> select * from tab;
TNAME TABTYPE CLUSTERID
------------------------------ ------- ----------
DEPT TABLE
EMP TABLE
BONUS TABLE
SALGRADE TABLE
SQL> select table_name, tablespace_name from user_tables;
TABLE_NAME TABLESPACE_NAME
------------------------------ ------------------------------
DEPT USERS
EMP USERS
BONUS USERS
SALGRADE USERS
SQL> select count(*) from bonus;
COUNT(*)
----------
0
SQL> conn /as sysdba
연결되었습니다.
SQL>
SQL> archive log list
데이터베이스 로그 모드 아카이브 모드
자동 아카이브 사용
아카이브 대상 USE_DB_RECOVERY_FILE_DEST
가장 오래된 온라인 로그 순서 20
아카이브할 다음 로그 22
현재 로그 순서 22
SQL>
SQL> select tablespace_name, file_name from dba_data_files;
TABLESPACE_NAME
------------------------------
FILE_NAME
----------------------------------------------------------------------------------------------------
USERS
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF
SYSAUX
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF
UNDOTBS1
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF
TABLESPACE_NAME
------------------------------
FILE_NAME
----------------------------------------------------------------------------------------------------
SYSTEM
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF
EXAMPLE
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\EXAMPLE01.DBF
SQL> alter tablespace users begin backup;
테이블스페이스가 변경되었습니다.
SQL>
SQL> host
SQL> alter tablespace users end backup;
테이블스페이스가 변경되었습니다.
SQL> shutdown immediate;
데이터베이스가 닫혔습니다.
데이터베이스가 마운트 해제되었습니다.
ORACLE 인스턴스가 종료되었습니다.
SQL> host --원도우는 해당파일 락을 잡고있어서.. tablespace 삭제
SQL> startup
ORA-32004: obsolete and/or deprecated parameter(s) specified
ORACLE 인스턴스가 시작되었습니다.
Total System Global Area 570425344 bytes
Fixed Size 1250188 bytes
Variable Size 171969652 bytes
Database Buffers 390070272 bytes
Redo Buffers 7135232 bytes
데이터베이스가 마운트되었습니다.
ORA-01157: 데이터 2 파일을 식별 또는 잠금 할 수 없습니다- DBWR 추적 파일을 보십시오
ORA-01110: 2 데이터 파일: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF'
SQL> select file#, status, enabled, bytes, name from v$datafile;
FILE# STATUS ENABLED BYTES
---------- ------- ---------- ----------
NAME
----------------------------------------------------------------------------------------------------
1 SYSTEM READ WRITE 513802240
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF
2 ONLINE READ WRITE 0 <- 잘못지움
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF
3 ONLINE READ WRITE 314572800
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF
FILE# STATUS ENABLED BYTES
---------- ------- ---------- ----------
NAME
----------------------------------------------------------------------------------------------------
4 ONLINE READ WRITE 5242880
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF
5 ONLINE READ WRITE 104857600
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\EXAMPLE01.DBF
SQL> set linesize 200
SQL> host --잘못 지운 백업파일을 배포함 copy
SQL> alter database open;
alter database open
*
1행에 오류:
ORA-01113: 2 파일이 매체 복구되어야 합니다
ORA-01110: 2 데이터 파일: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF'
SQL> recover Datafile 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF'
ORA-00279: 변환 932417가 (01/13/2010 12:58:51에서 생성된) 스레드 1에 필요합니다
ORA-00289: 제안 : C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2010_01_15\O1_MF_1_18
ORA-00280: 변환 932417(스레드 1를 위한)가 시퀀스번호 18에 있습니다
로그 지정: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: 변환 940634가 (01/13/2010 16:12:39에서 생성된) 스레드 1에 필요합니다
ORA-00289: 제안 : C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2010_01_15\O1_MF_1_19
ORA-00280: 변환 940634(스레드 1를 위한)가 시퀀스번호 19에 있습니다
ORA-00278: 이 복구를 위해 로그 'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORCL\ARCHIVELOG\2010_01
로그가 적용되었습니다.
매체 복구가 완료되었습니다.
SQL> alter database open;
데이타베이스가 변경되었습니다.
SQL> select file#, status, enabled, bytes, name from v$datafile;
FILE# STATUS ENABLED BYTES
---------- ------- ---------- ----------
NAME
----------------------------------------------------------------------------------------------------
1 SYSTEM READ WRITE 513802240
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSTEM01.DBF
2 ONLINE READ WRITE 36700160
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\UNDOTBS01.DBF
3 ONLINE READ WRITE 314572800
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\SYSAUX01.DBF
FILE# STATUS ENABLED BYTES
---------- ------- ---------- ----------
NAME
----------------------------------------------------------------------------------------------------
4 ONLINE READ WRITE 5242880
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\USERS01.DBF
5 ONLINE READ WRITE 104857600
C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\EXAMPLE01.DBF
SQL>
{column}
{section}
3.3.2 제어파일 손상 시 복구절차
Note
1. Mirrored 되는Control file 전부가 손상된 경우의 Recovery
oerr ora 210
00210, 00000, "cannot open control file '%s'"
*Cause: Cannot open the control file
*Action: Check to make sure the control file is there and not locked by some other program
현상 및 Error 내용
{section}
{column:width=10%}
SQL> alter tablespace users add Datafile '/u02/ORACLE/BACKUP/usr2BACKUP.dbf';
alter tablespace users add Datafile '/u02/ORACLE/BACKUP/usr2BACKUP.dbf'
*
ERROR at line 1:
ORA-00210: cannot open control file '/u02/ORACLE/BACKUP/ctrl1BACKUP.ctl'
ORA-07368: sfofi: open error, unable to open database file.
IBM AIX RISC System/6000 Error: 2: No such file or directory
{column}
{section}
"Mirroring이 되고 있든 아니든 간에 Control file이 손상을 입었다면 Database는 Background process가 Control file에 처음으로 access 하는 시점까지는 정상적으로 운영된다. 그러나 이 시점( Database의 물리적인 구조를 변경시키는 작업, 즉 Database file을 추가하거나 삭제하는 작업을 하려하는 시점)에 도달하면 ORACLE은 Database와 Instance를 강제로 terminate 시킨다.
일단 Oracle에 의해 강제로 terminated 된 후에는 Control file이 Recovery되기 전까지는 Database를 OPEN 할 수 없으며 MOUNT할 수도 없다. "라고 ORACLE 7.3 Manual Admin Guide 24-53에는 기술되어 있지만 실제 Test한 바로는 Oracle은 terminate 되지 않았고 단지 아래와 같은 Error만을 Return할 뿐이었다. 참고로 아래의 Recovery 과정은 Test한 결과를 바탕으로 기술한 것이다.
Control file은 Database의 물리적인 구조에 관한 정보를 가지고 있다. 만약 Database의 물리적인 구성요소인 Database Datafile , 즉 Datafile이나 redo log file이 추가될 경우 Database의 변화를 반영하기 위해 ORACLE은 Control file에 Database의 변경된 사항을 기록한다.
그러므로 이 Control file이 손상을 입었을 경우에 특정 Tablespace에 Datafile을 추가하려 하면 ORACLE은 Control file 을 변경하려고 시도하지만 Control file이 사라졌기 때문에 Database 의 변경 사항을 기록할 수 없고 Error(ORA-210)를 Return 할 것 이다.
Recovery 수행 방법
1. 위의 Error(ORA-210)에서와 같이 Control file에 손상이 가해졌음을 알 수 있듯이 실제 Physical한 Storage directory에서 Control file의 변화를 확인해본다.
$ls /u02/ORACLE/BACKUP
log1_m_BACKUP.dbf rbsBACKUP.dbf toolBACKUP.dbf
log2BACKUP.dbf systBACKUP.dbf usrBACKUP.dbf
log1BACKUP.dbf log2_m_BACKUP.dbf tempBACKUP.dbf
2. Control file이 전부 분실된 경우에는 새로 Control file을 Creation 해야 한다. 이 경우에는 vi editor를 열어 아래와 같이 Control file을 Creation하는 script를 작성한 후에 Control file을 새로 Creation하고 Recovery해야 한다.
{section}
{column:width=10%}
STARTUP NOMOUNT
CREATE CONTROL FILE REUSE DATABASE "BACKUP" NORESETLOGS ARCHIVELOG
MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXDATAFILES 30
MAXINSTANCES 8
MAXLOGHISTORY 800
LOGFILE
GROUP 1 (
'/u02/ORACLE/BACKUP/log1BACKUP.dbf',
'/u02/ORACLE/BACKUP/log1_m_BACKUP.dbf'
) SIZE 10K,
GROUP 2 (
'/u02/ORACLE/BACKUP/log2BACKUP.dbf',
'/u02/ORACLE/BACKUP/log2_m_BACKUP.dbf'
) SIZE 10K
DATAFILE
'/u02/ORACLE/BACKUP/systBACKUP.dbf',
'/u02/ORACLE/BACKUP/rbsBACKUP.dbf',
'/u02/ORACLE/BACKUP/tempBACKUP.dbf',
'/u02/ORACLE/BACKUP/toolBACKUP.dbf',
'/u02/ORACLE/BACKUP/usrBACKUP.dbf' ;
RECOVER DATABASE
ALTER SYSTEM ARCHIVE LOG ALL;
ALTER DATABASE OPEN;
{column}
{section}
3. 위의 script를 작성한 후 실행시키기 위해서는 현재 OPEN 되어있는 Database를 NOMOUNT 상태로 만들어야 한다. 현재 Open 되어 있는 Database를 NORMAL이나 IMMEDIATE Option으로 SHUTDOWN하려하면 Error(ORA-1122)가 Return 될 것이다. 왜냐하면 Oracle은 Control file이 가지고 있는 Database Structure에 관한 정보와 실제 Database Structure의 구조를 비교 하여 일치할 경우에만 Database를 SHUTDOWN, STARTUP 할 수 있다. 그러나 현재 Control file이 (Mirroring 되고 있는 Control file까지) 전부 손상되어 있으므로 손상된 Control file이 가지고 있는 손상된 정보와 실제 Database Structure는 일치하지 않으므로 SHUTDOWN을 ABORT 해야 Database는 Shutdown될 것이다. 그러나 이 상태에서 Control file을 다시 Creation할 때 Control file은 생성되지만 Recovery는 수행되지 않고 Database는 OPEN된다. 그러므로 ABORT Option으로 SHUTDOWN 해야 Recovery까지 수행할 수 있다.
만약 Control file이 손상되기 이전에 Backup받아 놓은 Control file이 있고 Backup을 받은 후에도 Database의 물리적인 구조가 변경되지 않았다면 ALTER DATABASE BACKUP CONTROL FILE TO TRACE ; command를 사용하면 Control file을 Creation하는 script를 보다 쉽게 작성할 수 있게 해준다. ALTER DATABASE BACKUP CONTROL FILE TO TRACE ; command를 사용하기 위해선 Backup받은 Control file 모두를 Physical directory로 Copy해야 한다.
왜냐하면 이 Command는 Physical한 Control file을 user_dump_dest(config.ora file에서 정의)인/admhome/ oracle/admin/BACKUP/udump로 ORA_xxxxx.trc라는 trace file을 생성하며 이 trace file에는 Physical한 Control file이 가지고 있는 Database의 Structure에 관한 정보를 토대로 Control file을 Creation하는 Script가 만들어진다.
설령 Control file을 Backup받은 후에 Database의 물리적인 구조가 변경되었다면 Backup받은 Control file을 Copy하고 ALTER DATABASE BACKUP CONTROL FILE TO TRACE ; 를 실 행한 후 /admhome/oracle/admin/BACKUP/udump밑에 생성된 Trace file에 Database의 변경된 부분을 추가 혹은 삭제하여 SHUTDOWN ABORT한 후에 실행시키면 Recovery가 수행될 것이다.
SVRMGR> shutdown abort
ORACLE instance shut down.
4. 위에서 작성한 script를 실행시켜 Control file을 Creation하고 Recovery를 수행해야 한다.
SVRMGR> @create_contolfile.sql
Statement processed.
Media recovery complete.
Statement processed.
Statement processed.
5. Control file이 Creation되었는지 physical directory에서 확인해본다.
$ ls -l /u02/ORACLE/BACKUP rw-r
1 oracle dba 111104 Oct 18 11:34 ctrl1BACKUP.ctl
1 oracle dba 111104 Oct 18 11:34 ctrl2BACKUP.ctl
1 oracle dba 111104 Oct 18 11:34 ctrl3BACKUP.ctl
6. Datafile을 추가하여 Database가 정상적으로 Recovery 되었는지 확인해 볼 수 있다.
3. Control file 중 일부가 손상된 경우의 Recovery
Note
oerr ora 210
00210, 00000, "cannot open control file '%s'"
*Cause: Cannot open the control file
*Action: Check to make sure the control file is there and not locked by some other program
현상 및 Error 내용
위 CASE 2-1과 같은 Error를 Return 할 것이다.
Note
SQL> alter tablespace users add Datafile '/u02/ORACLE/BACKUP/usr2BACKUP.dbf';
alter tablespace users add Datafile '/u02/ORACLE/BACKUP/usr2BACKUP.dbf'
*
ERROR at line 1:
ORA-00210: cannot open control file '/u02/ORACLE/BACKUP/ctrl1BACKUP.ctl'
ORA-07368: sfofi: open error, unable to open database file.
IBM AIX RISC System/6000 Error: 2: No such file or directory
Recovery 수행 방법
1. Physical directory에서 mirroring 되고 있는 Control file을 Copy한다.
$ cp /u02/ORACLE/BACKUP/ctrl2BACKUP.ctl ctrl1BACKUP.ctl
2. IMMEDIATE로 Shutdown한다.
{section}
{column:width=10%}
SVRMGR> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
{column}
{section}
3. STRATUP 한다.
{section}
{column:width=10%}
SVRMGR> startup
ORACLE instance started.
Database mounted.
Database opened.
{column}
{section}
위와 같이 Test결과 Recovery된다. Mirroring되고있는Control file 중 일부가 손상을 입어 Database의 물리적 구조를 변화시키지 못하여 Error를 Return 할 때 Mirroring되고 있는 Control file을 Physical directory에 Copy하고 NORMAL로 SHUTDOWN한 후 다시 STARTUP하면 손상된Control file을 Recovery할 수 있다. 그러나 ORACLE Mannual에는 ABORT로 SHUTDOWN하라고 명시하고 있다. 그리고 Mannual에는 1과 2를 바꿔 수행하라고 기술되어 있지만 두 가지 경우 모두 Recovery는 정상적으로 된다.
다른 Recovery 방법(ORACLE Mannual)
1. ABORT로 SHUTDOWN한다.
SVRMGR> shutdown ABORT
Database closed.
Database dismounted.
ORACLE instance shut down.
2. Physical directory에서 mirroring 되고 있는 Control file을 Copy한다.
$ cp /u02/ORACLE/BACKUP/ctrl2BACKUP.ctl ctrl1BACKUP.ctl
3. STRATUP 한다.
SVRMGR> startup
ORACLE instance started.
Database mounted.
Database opened.
3.4.3 온라인 Log(Redo Log)의 손상 시 복구 절차
1. Mirrored 되는 Redolog file Group중 특정 member의 Recovery
(Current redo log Group이 아닌 Group의 member가 손상된 경우, Current redo log Group의 member가 손상된 경우 공통)
{section}
{column:width=10%}
cf) 현재 log file의 상태
SVRMGR> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
------ ------- --------- ------- -------- ---
1 1 136 10240 2 YES INACTIVE
2 1 137 10240 2 NO CURRENT
2 rows selected.
h3. 현상 및 Error 내용
SQL> insert into bonus
2 select * from bonus;
736 rows created.
SQL>select count(*) from bonus
COUNT(*)
----------
1472
SVRMGR> select GROUP#,THREAD#,SEQUENCE#,BYTES, MEMBERS, ARCHIVED,STATUS
2> from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
------ -------- ----------- ----- -------- ---
1 1 146 10240 2 NO CURRENT
2 1 145 10240 2 YES INACTIVE
2 rows selected.
{column}
{section}
Log Group에서 각 Group에 최소한 1개의 Mirroring되고 있는log file이 있다면 Log 상태가 CURRENT이든 INACTIVE이든 상관없이 log file member가 손상을 입었을지라도 ORACLE의 background process인 LGWR은 손상된 log file이외 의 다른 log file member를 찾아 Write하므로 별도의 Error를 Return하지 않고 정상적으로 Database가 작동하도록 한다. 다만 LGWR Trace file이나 ALERT file에 Error message를 남긴다.
Recovery 수행 방법
1. V$LOG에서 손상된 log file member의 상태가 Current가 아닌지를 확인한다. 만약 Current상태라면 인위적으로 Log Switch를 다른 Group으로 넘겨 INACTIVE 상태로 만들어야 손상된 log file을 DROP할 수 있고 다시 ADD할 수 있다.
{section}
{column:width=10%}
SVRMGR> alter system switch logfile;
Statement processed.
SVRMGR> select GROUP#,THREAD#,SEQUENCE#,BYTES, MEMBERS,ARCHIVED,STATUS
2> from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
------ -------- --------- ------ -------- ----
1 1 145 10240 2 YES INACTIVE
2 1 146 10240 2 NO CURRENT
{column}
{section}
2. 손상된 log file을 DROP한다.
{section}
{column:width=10%}
SVRMGR> alter database drop logfile member '/u02/ORACLE/BACKUP/log1BACKUP.dbf';
Statement processed.
SVRMGR> select * from v$logfile;
GROUP# MEMBER
--------- -------------------------
2 /u02/ORACLE/BACKUP/log2BACKUP.dbf
2 /u02/ORACLE/BACKUP/log2_m_BACKUP.dbf
1 /u02/ORACLE/BACKUP/log1_m_BACKUP.dbf
3rows selected.
{column}
{section}
3. 다시 log member를 추가한다.
{section}
{column:width=10%}
SVRMGR> alter database add logfile member '/u02/ORACLE/BACKUP/log1BACKUP.dbf'
2> to group 1;
Statement processed.
SVRMGR> select * from v$logfile;
GROUP# STATUS MEMBER
--------- -----------------------------------
2 /u02/ORACLE/BACKUP/log2BACKUP.dbf
2 /u02/ORACLE/BACKUP/log2_m_BACKUP.dbf
1 INVALID /u02/ORACLE/BACKUP/log1BACKUP.dbf
1 /u02/ORACLE/BACKUP/log1_m_BACKUP.dbf
4 rows selected.
{column}
{section}
위와 같이 Log file Group에서 Member일부가 손상을 입었을 경우에는 위와 같이 간단히 Recovery 할 수 있다.
2 Mirrored 되는 Redolog file Group중 특정 Group의 Recovery
Note
(Current Online Redolog Group이 아닌 경우)
ORA-1096을 Return하는 경우에는 아래의 Recovery 수행 방법을 통해 Recovery한다.
oerr ora 1092
01092, 00000, "ORACLE instance terminated. Disconnection forced"
*Cause:The instance this process was connected to was terminated abnormally, probably via a shutdown abort. This process was forced to disconnect from the instance.
*Action: When instance has been restarted, retry action.
현상 및 Error 내용
{section}
{column:width=10%}
SQL> insert into bonus values('wwew','qeq',1122,22222);
1 row created.
SQL> /
1 row created.
SQL> /
insert into bonus
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
Current Log Group이 아닌 다음 Log Switch가 일어날 Group이 손상된 경우 User는 계속해서 DML작업을 계속할 것이다. 일반적으로 SGA안의 Log Buffer가 다 차면 Current Log Group 에 Write하고 Log Switch를 다음 Log Group으로 넘기고 꽉 찬 Current Log file의 내용을 Archive log file에 써야 한다. 그러나 다음 Log Switch가 넘어갈 Group이 손상되어 있으므로 Log Switch가 넘어가지를 못한다. 그리고 Current Log Group은 LGWR이 Log Buffer의 내용을 Write했으므로 꽉찼지만 Archive 는 아직 수행하지 못하고 있는 상태이다.
이처럼 다음 Log Switch가 일어날 Group이 손상된 경우 ORACLE은 Background process인 LGWR를 강제로 terminate 시키고 Trace file에 기록을 남긴다.
$ls -la /admhome/oracle/admin/BACKUP/bdump
-rw-r--r-- 1 oracle dba 27107 Oct 19 15:53 alert_BACKUP.log
-rw-r----- 1 oracle dba 1131 Oct 19 15:58 lgwr_44568.trc
-rw-r----- 1 oracle dba 682 Oct 19 15:58 pmon_28172.trc
$ vi /admhome/oracle/admin/BACKUP/bdump/ pmon_28172.trc
Sat Oct 19 15:58:21 1996
*** SESSION ID:(1.1) 1996.10.19.15.58.21.959
error 470 detected in background process
OPIRIP: Uncaught error 447. Error stack:
ORA-00447: fatal error in background process
ORA-00470: LGWR process terminated with error
$ vi /admhome/oracle/admin/BACKUP/bdump/ lgwr_44568.trc
*** SESSION ID:(4.1) 1996.10.19.15.50.06.574
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/u02/ORACLE/BACKUP/log1BACKUP.dbf'
ORA-07360: sfifi: stat error, unable to obtain information about file.
IBM AIX RISC System/6000 Error: 2: No such file or directory
ORA-00312: online log 1 thread 1: '/u02/ORACLE/BACKUP/log1_m_BACKUP.dbf'
ORA-07360: sfifi: stat error, unable to obtain information about file.
IBM AIX RISC System/6000 Error: 2: No such file or directory
Sat Oct 19 15:53:12 1996
ORA-00313: open failed for members of log group 1 of thread 1
Sat Oct 19 15:58:21 1996
error 313 detected in background process
{column}
{section}
Recovery 수행 방법
1. PMON은 Background process인 LGWR를 강제로 kill 시키고 Terminate 시키므로 ABORT Option으로 SHUTDOWN 시킨다.
SVRMGR> shutdown abort
ORACLE instance shut down.
2. 일단 NORMAL로 STARTUP하여 ERROR를 Check한다.
{section}
{column:width=10%}
SVRMGR> startup
ORACLE instance started.
Database mounted.
ORA-00313: open failed for members of log group 2 of thread 1
ORA-00312: online log 2 thread 1: '/u02/ORACLE/BACKUP/log2_m_BACKUP.dbf'
ORA-00312: online log 2 thread 1: '/u02/ORACLE/BACKUP/log2BACKUP.dbf'
SVRMGR> !oerr ora 313
00313, 00000, "open failed for members of log group %s of thread %s"
*Cause: The online log cannot be opened. May not be able to find file.
*Action: See accompanying errors and make log available.
SVRMGR> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
------- ------ ---------- ----- ---------
1 1 156 10240 2 NO CURRENT
2 1 0 10240 2 YES UNUSED
2 rows selected.
SVRMGR> select * from v$logfile;
GROUP# STATUS MEMBER
---------- ------- ---------------------------
2 STALE /u02/ORACLE/BACKUP/log2BACKUP.dbf
2 STALE /u02/ORACLE/BACKUP/log2_m_BACKUP.dbf
1 /u02/ORACLE/BACKUP/log1BACKUP.dbf
1 /u02/ORACLE/BACKUP/log1_m_BACKUP.dbf
{column}
{section}
3. 임의의 Log Group을 Add한다.
SVRMGR> alter database add logfile '/u02/ORACLE/BACKUP/log3.dbf' size 10k;
Statement processed.
4. 손상된 Log Group을 DROP한다.
SVRMGR> alter database drop logfile group 2;
Statement processed.
5. 다시 손상된 Log Group과 같은 Size, Name으로 ADD한다.
{section}
{column:width=10%}
SVRMGR> alter database add logfile '/u02/ORACLE/BACKUP/log2BACKUP.dbf' size 10k;
Statement processed.
SVRMGR> alter database add logfile member '/u02/ORACLE/BACKUP/log2_m_BACKUP.dbf'
2> to group 2;
Statement processed.
SVRMGR> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
------- ------ ----------- ----- -------------
1 1 156 10240 2 NO CURRENT
2 1 0 10240 2 YES UNUSED
3 1 0 10240 1 YES UNUSED
3 rows selected.
{column}
{section}
6. 임의로 생성했던 Log Group을 DROP한다.
SVRMGR> alter database drop logfile group 3;
Statement processed.
7. Database를 OPEN한다.
{section}
{column:width=10%}
SVRMGR> alter database open;
Statement processed.
SVRMGR> alter system switch logfile;
Statement processed.
SVRMGR> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
------- ------ ----------- ---- --------------
1 1 156 10240 2 NO CURRENT
2 1 157 10240 2 YES INACTIVE
2 rows selected.
SVRMGR> select * from v$logfile;
GROUP# STATUS MEMBER
-------- ------- -----------------------------
2 /u02/ORACLE/BACKUP/log2BACKUP.dbf
2 /u02/ORACLE/BACKUP/log2_m_BACKUP.dbf
1 /u02/ORACLE/BACKUP/log1BACKUP.dbf
1 /u02/ORACLE/BACKUP/log1_m_BACKUP.dbf
4 rows selected.
{column}
{section}
8. 마지막으로 임의로 생성했던 Physical한 Log file을 Remove한다.
$ rm /u02/ORACLE/BACKUP/log3.dbf
3 Mirrored 되는 Redolog file Group중 특정 Group의 Recovery
Note
(Current Online Redo log Group인 경우)
DML(Data Manipulation Language) 즉, Insert, Delete, Update등 을 실행 시켰는데 아무런 결과를 Return하지 않고 계속 묵묵부 답일 때에는 다른 Session을 열어 Alert_ORACLE_SID.ora을 확인 하여 Database에 어떤 문제가 발생한 것은 아닌 지 확인 해보는 자세가 중요하다.
현상 및 Error 내용
{section}
{column:width=10%}
SQL> insert into bonus
2 select * from bonus;
10 rows created.
SQL> /
===> 무반응
현재 Current log Group이 전부 손상된 시점에 ORACLE은 특별한 Error Message를 Return하지 않고 다만 /admhome/oracle/admin/BACKUP/bdump에 ALERT file이나 arch_xx.trc file에 Error Message를 남긴다. 여기서 arch_xx.trc file을 보면 ,
ORA-00255: error archiving log 1 of thread 1, sequence # 169
ORA-00312: online log 1 thread 1: '/u02/ORACLE/BACKUP/log1BACKUP.dbf'
ORA-00312: online log 1 thread 1: '/u02/ORACLE/BACKUP/log1_m_BACKUP.dbf'
ORA-00286: No members available, or no member contains valid data
ORA-00334: archived log: '/adhome/oracle/admin/BACKUP/arch/arch_169.arc
위의 Error를 Return 함을 알 수 있다. 특히 ORA-286을 보면 알 수 있듯이 Current log Group이 없음을 알 수 있고 Log file이 없으므로 Archive할 Data가 없다고 Message를 남긴다.
00286, 00000, "No members available, or no member contains valid data"
*Cause: None of the members of a logfile group are available, or the available members do not contain complete data.
*Action: If a member is temporarily offline, attempt to make it available.Make sure that the correct file names are being used, especially if the log is being accessed from a remote location.
SGA안의 Log buffer가 꽉차서 LGWR가 Redo log Buffer안의 내용을 Current Log file에 write하려고 하지만 Log file이 손상되어 있으므로 write하지 못한다. 이때 ORACLE은 내부적 알고리즘에 의해 LGWR가 손상된 Current Log file에 Redo log buffer의 내용을 write하지 못했더라도 다른 정상적인 Log Group으로 Log Switch를 넘긴다. 그러나 현재 손상된 Current log file에 write한 것이 없으므로 Current log file의 것을 Archive file로도 남길 수 없다. 다음의 V$LOG에서 나타나듯이 손상된 Current Group이었던 Group # 1의 STATUS는 INACTIVE이고 Archive는 안되었음을 알 수 있다.
§주의 할 점은 위처럼 Current Log Group이 손상을 입었을 때는 ORACLE은 아무런 Message를 내보내지 않는다는 것이 다. 그러므로 위에서처럼 DML에 아무런 반응이 없을 때는 Current Log Group이 손상되지 않았나 Check해 보는 것이 바람직하다.
{column}
{section}
Recovery 수행 방법
1. 일단 DML에 대한 아무런 반응이 없었으므로 Alert file이나 현재시간에 생성된 Trace file을 살펴본다. Trace file의 내용이 Log file과 연관이 있는 것이라면 V$LOG를 확인해 본다.
{section}
{column:width=10%}
SVRMGR> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
------- ------ ----------- ------ -------- ---
1 1 158 10240 2 NO INACTIVE
2 1 159 10240 2 NO CURRENT
2 rows selected.
{column}
{section}
위에서 확인한 것처럼 Group # 1의 ARCHIVE가 안 일어나고 Group 2로 Log Switch가 넘어갔음을 알 수 있다.
2. 임의의 Log Group을 생성한다. 왜냐하면 손상된 Log Group 을 없애고 새로 만드는 과정에서 ORACLE에서는 반드시 Log Group이 2개 이상(Circular fashion)이어야 한다. 그러므로 GROUP 1을 DROP하는 시점에 Log Group은 2개 이상이 존재 해야 하므로 임의의 Log Group 3를 생성해야 한다.
{section}
{column:width=10%}
SVRMGR> alter database add logfile '/u02/ORACLE/BACKUP/log3.dbf' size 10k;
Statement processed.
SVRMGR> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
-------- ------ ---------- ---- --------- ---
1 1 158 10240 2 NO INACTIVE
2 1 159 10240 2 NO CURRENT
3 1 0 10240 1 YES UNUSED
3 rows selected.
{column}
{section}
3. 손상될 Log Group을 DROP해야 한다. 그러나 현재 Database는 ARCHIVELOG Mode로 운영되고 있다. ARCHIVELOG Mode에서는 Archive가 되지않은 Current Log file을 DROP할 수 없다. 그러므로 손상된 Log Group을 DROP하 기에 앞서 Database를 NOARCHIVELOG Mode로 변경시켜주어 야 한다.
{section}
{column:width=10%}
SVRMGR> alter database drop logfile group 1;
alter database drop logfile group 1
ORA-00350: log 1 of thread 1 needs to be archived
ORA-00312: online log 1 thread 1: '/u02/ORACLE/BACKUP/log1BACKUP.dbf'
ORA-00312: online log 1 thread 1: '/u02/ORACLE/BACKUP/log1_m_BACKUP.dbf'
SVRMGR> shutdown immediate
ORACLE instance shut down.
SHUTDOWN 했으면 STARTUP MOUNT한다.
SVRMGR> startup mount
ORACLE instance started.
Database mounted.
SVRMGR> alter database noarchivelog;
Statement processed.
SVRMGR> archive log list
Database log mode No Archive Mode
Automatic archival Enabled
Archive destination /admhome/oracle/admin/BACKUP/arch
Oldest online log sequence 158
Current log sequence 159
{column}
{section}
4. 손상된 Log Group을 DROP한다.
{section}
{column:width=10%}
SVRMGR> alter database drop logfile group 1;
Statement processed.
SVRMGR> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
------- ------ ---------- ------- -------- ---
2 1 159 10240 2 NO CURRENT
3 1 0 10240 1 YES UNUSED
{column}
{section}
2 rows selected.
5. 새로 Log Group을 생성한다.
{section}
{column:width=10%}
SVRMGR> alter database add logfile '/u02/ORACLE/BACKUP/log1BACKUP.dbf' size 10k;
Statement processed.
SVRMGR> alter database add logfile member '/u02/ORACLE/BACKUP/log1_m_BACKUP.dbf'
2> to group 1;
Statement processed.
SVRMGR> select * from v$logfile;
GROUP# STATUS MEMBER
---------- ------- ---------------------------
2 STALE /u02/ORACLE/BACKUP/log2BACKUP.dbf
2 STALE /u02/ORACLE/BACKUP/log2_m_BACKUP.dbf
1
/u02/ORACLE/BACKUP/log1BACKUP.dbf
1 INVALID /u02/ORACLE/BACKUP/log1_m_BACKUP.dbf
3
/u02/ORACLE/BACKUP/log3.dbf
5 rows selected.
{column}
{section}
6. 임의로 생성했던 Log Group 을 DROP 한다.
{section}
{column:width=10%}
SVRMGR> alter database drop logfile group 3;
Statement processed.
SVRMGR> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
------- --------- ------------ ---------- ---
1 1 0 10240 2 YES UNUSED
2 1 159 10240 2 NO CURRENT
2 rows selected.
SVRMGR> select * from v$logfile;
GROUP# STATUS MEMBER
---------- ------- ---------------------------
2 STALE /u02/ORACLE/BACKUP/log2BACKUP.dbf
2 STALE /u02/ORACLE/BACKUP/log2_m_BACKUP.dbf
1
/u02/ORACLE/BACKUP/log1BACKUP.dbf
1 INVALID /u02/ORACLE/BACKUP/log1_m_BACKUP.dbf
4 rows selected.
{column}
{section}
7. NOARCHIVE Mode를 다시 ARCHIVELOG Mode로 바꾼다.
SVRMGR> alter database archivelog;
Statement processed.
8. Database를 OPEN한다.
SVRMGR> alter database open;
Statement processed.
9. Physical Storage directory에서 임의로 생성했던 log file을 Remove한다.
$ rm /u02/ORACLE/BACKUP/log3.dbf
4. Redo log file이 모두 손상된 경우
Recovery 수행 방법
System이 Shutdown되기 전에 복구해야 함.
{section}
{column:width=10%}
SQL> insert into bonus
2 select * from bonus;
1280 rows created. (총 2560row 존재)
SVRMGR> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIR
---------- ---------- ---------- ---------- ---------- --- ---------------- ----
1 1 1 4194304 2 NO CURRENT
2 1 0 4194304 2 YES UNUSED
SVRMGR> alter database add logfile group 3
'/u01/ORACLE/BACKUP/log3BACKUP.dbf' size 1m;
Statement processed.
SVRMGR> alter database drop logfile group 2;
Statement processed.
SVRMGR> alter database add logfile group 2
'/u01/ORACLE/BACKUP/log2BACKUP.dbf' size 4m;
Statement processed.
SVRMGR> alter database add logfile member
'/u01/ORACLE/BACKUP/log2_m_BACKUP.dbf' to group 2;
Statement processed.
SVRMGR> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIR
---------- ---------- ---------- ---------- --
1 1 1 4194304 2 NO CURRENT
2 1 0 4194304 2 YES UNUSED
3 1 0 1048576 1 YES UNUSED
3 rows selected.
SVRMGR> alter database drop logfile group 1;
alter database drop logfile group 1
ORA-01623: log 1 is current log for thread 1 - cannot drop
ORA-00312: online log 1 thread 1: '/u01/ORACLE/BACKUP/log1BACKUP.dbf'
ORA-00312: online log 1 thread 1: '/u01/ORACLE/BACKUP/log1_m_BACKUP.dbf'
SVRMGR> alter system switch logfile;
Statement processed.
SVRMGR> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIR
---------- ---------- ---------- ---------- --
1 1 1 4194304 2 NO INACTIVE
2 1 2 4194304 2 NO CURRENT
3 1 0 1048576 1 YES UNUSED
3 rows selected.
SVRMGR> alter database drop logfile group 1;
alter database drop logfile group 1
*
ORA-00350: log 1 of thread 1 needs to be archived
ORA-00312: online log 1 thread 1: '/u01/ORACLE/BACKUP/log1BACKUP.dbf'
ORA-00312: online log 1 thread 1: '/u01/ORACLE/BACKUP/log1_m_BACKUP.dbf'
SVRMGR> shutdown abort
SVRMGR> startup mount
SVRMGR> alter database noarchivelog;
Statement processed.
SVRMGR> alter database drop logfile group 1;
Statement processed.
SVRMGR> alter database add logfile group 1
2> '/u01/ORACLE/BACKUP/log1BACKUP.dbf' size 4m;
Statement processed.
SVRMGR> alter database add logfile member
2> '/u01/ORACLE/BACKUP/log1_m_BACKUP.dbf' to group 1;
Statement processed.
SVRMGR> alter database drop logfile group 3;
Statement processed.
SVRMGR> alter database open;
SVRMGR> shutdown
SVRMGR> startup mount
SVRMGR> alter database archivelog;
Statement processed.
SVRMGR> alter database open;
Statement processed.
SVRMGR> connect scott/tiger
Connected.
SVRMGR> select count(*) from bonus;
COUNT(*)
----------
2560
1 row selected.
{column}
{section}
3.3.4 기타 장애 유형별 복구 절차.
Case 1. Online Tablespace backup 직후 failure가 발생한 경우 (End Backup command를 아직 수행하지 못한 경우)
Recovery 수행 방법
{section}
{column:width=10%}
SVRMGR> select * from v$backup;
FILE# STATUS CHANGE# TIME
------ ------ -------- ----------------------
1 ACTIVE 6559 10/12/96 13:53:16
2 ACTIVE 6560 10/12/96 13:53:16
3 ACTIVE 6562 10/12/96 13:53:16
4 ACTIVE 6561 10/12/96 13:53:16
5 ACTIVE 6563 10/12/96 13:53:16
ACTIVE는 backup mode중 임을 뜻한다.
SVRMGR> shutdown abort
ORACLE instance shut down.
SVRMGR> startup
ORACLE instance started.
Total System Global Area 4953044 bytes
Fixed Size 38940 bytes
Variable Size 4078520 bytes
Database Buffers 819200 bytes
Redo Buffers 16384 bytes
Database mounted.
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/u01/ORACLE/BACKUP/systBACKUP.dbf'
SVRMGR> recover Datafile '/u01/ORACLE/BACKUP/systBACKUP.dbf';
Media recovery complete.
ORA-01113: file 2 needs media recovery
ORA-01110: data file 2: '/u01/ORACLE/BACKUP/rbsBACKUP.dbf'
SVRMGR> recover Datafile '/u01/ORACLE/BACKUP/rbsBACKUP.dbf';
Media recovery complete.
SVRMGR> alter database open;
alter database open
*
ORA-01113: file 3 needs media recovery
ORA-01110: data file 3: '/u01/ORACLE/BACKUP/tempBACKUP.dbf'
SVRMGR> recover Datafile '/u01/ORACLE/BACKUP/tempBACKUP.dbf'
Media recovery complete.
SVRMGR> alter database open;
ORA-01113: file 4 needs media recovery
ORA-01110: data file 4: '/u01/ORACLE/BACKUP/toolBACKUP.dbf'
SVRMGR> recover Datafile '/u01/ORACLE/BACKUP/toolBACKUP.dbf'
Media recovery complete.
SVRMGR> alter database open;
alter database open
*
ORA-01113: file 5 needs media recovery
ORA-01110: data file 5: '/u01/ORACLE/BACKUP/usrBACKUP.dbf'
SVRMGR> recover Datafile '/u01/ORACLE/BACKUP/usrBACKUP.dbf';
Media recovery complete.
SVRMGR> alter database open;
Statement processed.
SVRMGR> select * from v$backup;
FILE# STATUS CHANGE# TIME
---------- ------------------ ---------- --------------------
1 NOT ACTIVE 6559 10/12/96 13:53:16
2 NOT ACTIVE 6560 10/12/96 13:53:16
3 NOT ACTIVE 6562 10/12/96 13:53:16
4 NOT ACTIVE 6561 10/12/96 13:53:16
5 NOT ACTIVE 6563 10/12/96 13:53:1
{column}
{section}
Recovery 수행 방법
{section}
{column:width=10%}
SVRMGR> startup mount
ORACLE instance started.
Total System Global Area 4953044 bytes
Fixed Size 38940 bytes
Variable Size 4078520 bytes
Database Buffers 819200 bytes
Redo Buffers 16384 bytes
Database mounted.
SVRMGR> alter database Datafile '/u01/ORACLE/BACKUP/systBACKUP.dbf' end backup;
Statement processed.
SVRMGR> alter database Datafile '/u01/ORACLE/BACKUP/rbsBACKUP.dbf' end backup;
Statement processed.
SVRMGR> alter database Datafile '/u01/ORACLE/BACKUP/tempBACKUP.dbf' end backup;
Statement processed.
SVRMGR> alter database Datafile '/u01/ORACLE/BACKUP/toolBACKUP.dbf' end backup;
Statement processed.
SVRMGR> alter database Datafile '/u01/ORACLE/BACKUP/usrBACKUP.dbf' end backup;
Statement processed.
SVRMGR> alter database open;
Statement processed.
{column}
{section}
Case 2. Backup본이 없는 Datafile이 손상 된 경우
Recovery 수행 방법
{section}
{column:width=10%}
임의의 tablespace test3를 만듦.
그 tablespace에 table을 만든다.
Datafile을 삭제한다.
SQL> create tablespace TEST Datafile
'/u01/ORACLE/BACKUP/test3.dbf' size 5m reuse
default storage (
initial 20k
next 20k
pctincrease 50);
SQL> create table chw
2 (a number(2),
3 b varchar2(8),
4 c varchar2(8))
5 tablespace test;
Table created.
SQL> insert into chw
2 values(1,'chw','seoul');
1 row created.
SQL> /
1 row created.
SQL>commit;
$ rm /u01/ORACLE/BACKUP/test3.dbf
h3. Recovery 수행 방법
SQL> select NAME,STATUS from v$Datafile;
NAME STATUS
----------------------------------- ---------
/u01/ORACLE/BACKUP/systBACKUP.dbf SYSTEM
/u01/ORACLE/BACKUP/rbsBACKUP.dbf ONLINE
/u01/ORACLE/BACKUP/tempBACKUP.dbf ONLINE
/u01/ORACLE/BACKUP/toolBACKUP.dbf ONLINE
/u01/ORACLE/BACKUP/usrBACKUP.dbf ONLINE
/u01/ORACLE/BACKUP/test.dbf ONLINE
SVRMGR> shutdown abort
ORACLE instance shut down.
SVRMGR> startup
ORACLE instance started.
Database mounted.
ORA-01157: cannot identify data file 6 - file not found
ORA-01110: data file 6: '/u01/ORACLE/BACKUP/test.dbf'
SVRMGR> alter database create Datafile '/u01/ORACLE/BACKUP/test.dbf' as
2> '/u01/ORACLE/BACKUP/test2.dbf';
SVRMGR> recover tablespace test;
ORA-01109: database not open
SVRMGR> alter database open;
alter database open
*
ORA-01113: file 6 needs media recovery
ORA-01110: data file 6: '/u01/ORACLE/BACKUP/test2.dbf'
SVRMGR> recover Datafile '/u01/ORACLE/BACKUP/test2.dbf';
ORA-00279: Change 6583 generated at 10/12/96 14:22:20 needed for thread 1
ORA-00289: Suggestion : /admhome/oracle/admin/BACKUP/arch/arch_8.arc
ORA-00280: Change 6583 for thread 1 is in sequence #8
Specify log: {=suggested | filename | AUTO | CANCEL}
Log applied.
ORA-00279: Change 6643 generated at 10/14/96 10:47:40 needed for thread 1
ORA-00289: Suggestion : /admhome/oracle/admin/BACKUP/arch/arch_9.arc
ORA-00280: Change 6643 for thread 1 is in sequence #9
ORA-00278: Logfile '/admhome/oracle/admin/BACKUP/arch/arch_8.arc' no longer neey
Specify log: {=suggested | filename | AUTO | CANCEL}
Log applied.
ORA-00279: Change 6659 generated at 10/14/96 10:50:58 needed for thread 1
ORA-00289: Suggestion : /admhome/oracle/admin/BACKUP/arch/arch_10.arc
ORA-00280: Change 6659 for thread 1 is in sequence #10
ORA-00278: Logfile '/admhome/oracle/admin/BACKUP/arch/arch_9.arc' no longer neey
Specify log: {=suggested | filename | AUTO | CANCEL}
Log applied.
Media recovery complete.
** set auto recovery on으로 설정한 후 log를 적용하면 적용 시점까지 저절로 apply된다.
SVRMGR> alter database open ;
Statement processed.
{column}
{section}
Case 3. 특정 시점으로의 Recovery ( Time-Based Recovery)
현상 및 Error 내용
{section}
{column:width=10%}
SVRMGR> shutdown
$cp /u01/ORACLE/BACKUP/* /u01/ORACLE/COLD_BACK
SVRMGR> startup
SVRMGR>connect scott/tiger
SVRMGR> insert into bonus
2> select * from bonus;
640 rows processed.
SVRMGR> /
SVRMGR> /
SVRMGR> commit;
Statement processed.
SVRMGR> select count(*) from bonus;
COUNT(*)
----------
1280
1 row selected.
SVRMGR> select to_char(sysdate,'yyyy-mm-dd:hh24:mi:ss') from dual;
TO_CHAR(SYSDATE,'YYYY-MM-DD:HH24:MI:SS')
---------------------------------------------------------------------------
1996-10-16:18:37:20
1 row selected.
SVRMGR> truncate table bonus;
Statement processed.
SVRMGR> commit;
Statement processed.
{column}
{section}
Recovery 수행 방법
{section}
{column:width=10%}
SVRMGR>shutdown abort
$ls /u01/ORACLE/COLD_BACK
ctrl1BACKUP.ctl log1_m_BACKUP.dbf systBACKUP.dbf usrBACKUP.dbf
ctrl2BACKUP.ctl log2BACKUP.dbf tempBACKUP.dbf
ctrl3BACKUP.ctl log2_m_BACKUP.dbf test.dbf
log1BACKUP.dbf rbsBACKUP.dbf toolBACKUP.dbf
Control file과 Redo log file을 제외한 Datafile을 copy한다.
만일 current한 control file이 복구하고자 하는 시점의 database의 물리적 구조와 일치하지 않는다면 incomplete recovery를 끝내고자 하는 시점의 database의 물리적 file 구조를 반영하는 control file의 backup을 restore한다.
Hardware적인 문제로 인해 control file backup을 대체시킬 수 없다면 control_files를 edit할 수 있다.
존재하는 Datafile을 대체하기 위해서 사용되는 모든 backup file은 복구하고자 하는 시점 전의 것이어야 한다.
$cd /u01/ORACLE/COLD_BACK
$cp rbsBACKUP.dbf systBACKUP.dbf tempBACKUP.dbf test.dbf toolBACKUP.dbf usrBACKUP.dbf /u01/ORACLE/BACKUP
SVRMGR> startup mount
database의 모든 Datafile은 time-based or change-based recovery 하는 동안 online이어야 함
SVRMGR> select * from v$Datafile;
FILE# STATUS ENABLED CHECKPOINT BYTES CREATE_BYT NAME
---------- ------- ---------- ---------- -----
1 SYSTEM READ WRITE 6798 52428800 52428800 /u01/ORACLE/BACK
2 ONLINE READ WRITE 6798 41943040 41943040 /u01/ORACLE/BACK
3 ONLINE READ WRITE 6798 52428800 52428800 /u01/ORACLE/BACK
4 ONLINE READ WRITE 6798 10485760 10485760 /u01/ORACLE/BACK
5 ONLINE READ WRITE 6798 10485760 10485760 /u01/ORACLE/BACK
truncate 하기 전의 시간으로 복구한다.
Control file backup을 사용했거나 재 creation된 control file이 restore되었다면 "using backup Control file" parameter를 명시한다.
SVRMGR> recover database until time '1996-10-16:18:37:00';
Media recovery complete.
log를 reset시킨다.
SVRMGR> alter database open resetlogs;
Statement processed.
SVRMGR> connect scott/tiger
Connected.
SVRMGR> select count(*) from bonus;
COUNT(*)
----------
1280
1 row selected
{column}
{section}
제공 : DB포탈사이트 DBguide.net