RMAN 복구 (Datafile 삭제 후 DB Open 상태에서 복구하기)

 

- Testdb 의 Datafile 이 다음과 같습니다.

 

 

- 다음과 같이 clone_test01.dbf 파일을 OS 명령어로 삭제 하였습니다.

 

- 우선 rman 에서 삭제된 Data file 을 offline 시킵니다.

- rman 으로 Backup 파일을 불러 옵니다. (restore)

 

- 이제 복구를 수행하고 offline 되었던 tablespace 를 online 으로 변경합니다.

 

- 다음의 작업을 한번에 작업형 명령어로 복구를 수행할 수도 있습니다.

RMAN-06004: ORACLE error from recovery catalog database:

RMAN-20035: invalid high recid

 

- 전에 Recovery 할 때 Close backup 파일들로 DB 를 그냥 올린적이 있었는데 아무리 expired 된 backupset 을 삭제하려 해도 되지 않고 방금처럼 RMAN 으로 전체 backup 을 받으려 해도 다음과 같은 오류를 발생 시켰다.

 

- list incarnation 을 확인하니 현재 inc number 가 현재 DB 의 incarnation number 와 맞지 않는 것을 확인 할 수 있었다. 그래서 rman 에서

RMAN>list incarnation of database testdb;

RMAN>reset database to incarnation <inc no>;

 

- 그리고 운영 디비를 내렸다가 다시 올리니 backup 이 수행된다.

- 정확한 내용을 확인 해야 할 것 같다.

Differences between a Connection and a Session

Connection

- 클라이언트와 오라클 인스턴스를 연결해주는 물리적 통로

- Connection 은 여러 종류 중 하나가 선택 되어질 수 있다.

Options are
1. client --connected to-- dispatcher
2. client --connected to-- dedicated server
3. client --connected to-- Oracle Connection Manager(CMAN)

 

Session

- 인스턴스의 논리적 요소로서 커넥션이 이루어짐으로서 세션이 성립된다. 또한 프로세스는 세션에 의해 수행되는 명령어에 의해 사용된다. 혹 세션과 프로세스 그리고 커넥션에는 CONNECTION->SESSION->PROCESS 의 관계가 있다고 볼 수도 있다. 커넥션이 이루어짐으로서 세션이 성립되고 세션을 통해 프로세스가 사용되어짐으로서 이러한 관계가 있다고 말할 수 있다.

'Oracle > Admin' 카테고리의 다른 글

Undo tablespace  (1) 2011.10.05
ORACLE Overview of Primary Components  (1) 2011.09.30

Recovery Catalog DB 관리하기

1. crosscheck

- 이 명령어는 target 서버와 recovery catalog 간의 정보를 동기화 시켜주는 역할을 합니다.

- 전체 backupset 과 target 서버 비교하기

RMAN>crosscheck backupset;

 

- backupset 을 OS 명령어로 삭제 후 다시 crosscheck 수행

 

- EXPIRED 된 것을 보면 이것은 BACKUPSET 목록에 존재하지만 실제 파일은 존재하지 않는다는 의미입니다. 백업 파일을 삭제 할 때도 RMAN 명령어로 삭제해 주어야 하며 그렇지 않을 시 위처럼 문제가 발생하게 됩니다.

2. delete

- 특정 backupset 을 삭제하고자 할 때 사용하는 명령어

- 목록 확인

RMAN>list backupset;

- 현재 backupset 목록 확인 후 특정 backupset 삭제하기

RMAN>delete backupset <number>;

 

3. catalog(관리자가 수동 백업 받은 파일을 RMAN catalog 에 추가하여 관리)

- example tablespace 를 RMAN 이 아닌 begin backup 수행

- RMAN Recovery Catalog 에 example 파일이 있는지 확인 합니다.

- 아직 정보가 없음을 확인 할 수 있습니다.

- Catalog 명령어로 Recovery Catalog 에 추가합니다.

 

- change 와 uncatalog 명령 (삭제 시)

- 리스트에 없는 것을 확인 할 수 있습니다.

 

[ERROR] ORA-01123 : cannot start online backup; media recovery not enabled

원인 :  Begin backup 은 noarchive log mod 에서는 수행할 수 없음
          archive log mode 인지 확인

해결방안 : mount 단계에서 archive log mode 로 변경
alter database archivelog
- 창피하다……

Catalog Server 구성 테스트

- 시나리오

à 현재 복구 서버에 접속한 상태에서 rclient 에서 전체 백업을 수행

à 그 후 testdb에서 모든 control file 을 삭제한 후 DB를 종료

à 이 장애는 catalog server 를 사용하지 않으면 복구가 안 되는 장애이므로 catalog server 를 이용하여 복구

- 오류 발생 testdb 서버가 Noarchive log mode 였다.

- 다시 archive log mode 로 변경한 후 다시 실행해 봅니다.

- 다시 정상적으로 백업 되는 것을 확인 할 수 있습니다.

- 이제 testdb 의 컨트롤 파일을 모두 삭제하고 DB 를 재시작 해 보겠습니다.

 

- 이제 RMAN 으로 catalog server 에 접속해서 복구를 시작합니다.

- testdb 서버에서 restore controlfile 명령어를 실행하면 복구가 되는 것을 확인 할 수 있습니다.

- 다음을 통해 컨트롤 파일이 복구 된 것을 확인할 수 있습니다.

- 어라 abort 로 껐는데 복구 없이 올라온다. 이렇게 되면 안되는데 이상하다.

다시 한번 시도!! 컨트롤 지우고 다시 해봐야겠다

- 그래 이렇게 나와야 한다. 자세한 내용은 admin 에서… abort 로 종료를 하게되면 dirty database 가 되기 때문에 다음과 같이 나오게 된다

- 아차 싶다…. Redo log 파일은 rman 백업 대상에 제외된다. 또한 방금 resetlogs 옵션으로 DB를 올렸기 때문에 incanation number 가 증가 되었을 것이다. 그렇기 때문에 기존의 컨트롤 파일로 rman 으로 복구한 후 recover 를 하려 했으나 되질 않는다. 또한 Datafile 과 컨트롤 파일의 scn 또한 틀릴 것이다.

-Resetlogs 옵션으로 올린 후 꼭 백업을 다시 받아야 한다는 교훈을 새삼 느끼는 순간이다.

 

- 다른 방법으로 살렸다… 조심하자..

Recovery Catalog 구성

 

- Recovery catalog 란 RMAN 사용시에 RMAN 으로 백업 복구 작업을 하고 관련 정보를 저장해 두는 장소

- Recovery catalog Server 가 있을 경우 Recovery catalog 에 정보를 저장

1. Data file 및 Archive redo log file 의 백업 셋과 copy 된 이미지에 대한 정보

2. 백업 대상 서버의 물리적인 구조

3. 자주 사용하는 백업 스크립트(Recovery catalog Server 를 사용할 경우만 해당)

 

- Catalog Server 사용시 접속 방법 : rman target / catalog rcuser/rcuser@rcserver

- Catalog Server 미 사용시 접속 : rman target /

 

- rman 실행시 오류 발생

- 확인해보면 rman 의 경로가 다른 것으로 되어 있기에 변경 해 주면 됩니다.

 

1. Recovery Catalog DB 생성

- 운영 DB 와 Catalog DB 가 필요하므로 Clone DB를 같은 서버에 생성해서 만들도록 하겠습니다.

- Clone DB 를 만드는 것은 저의 다른 글을 참고 하시길

-ORACLE_SID=rcserver 로 하고 생성

- Clone DB 에서 작업

 

- 복구 카탈로그를 저장할 테이블 스페이스(rc_tbs01)을 생성

- 복구 카탈로그를 관리할 사용자 계정(rcuser)를 생성하고 권한을 설정

 

- tnsnames.ora 파일을 수정해 줍니다.

- testdb 에서 rcserver 로 접속이 되는지 테스트 합니다.

- 이 테스트를 위해서는 당연히 리스너가 실행되고 있어야 합니다.

 

 

$lsnrctl

LSNRCTL>start listener3

- testdb à rcserver 로의 접속 테스트

 

- testdb 서버에 rman 으로 접속하되 recovery catalog 서버에 접속합니다.

 

- 복구 카탈로그를 생성 합니다.

 

-이제 복구 서버에 testdb 서버가 등록되어 있는지 확인 합니다.

- rcserver 서버에서 확인 합니다.

- 아직 testdb 서버의 SID 가 등록되지 않았습니다.

- 위 작업은 testdb 서버에서 하는 작업 입니다.

- 다시 rcserver 에서 testdb 가 등록되었는지 확인 합니다.

- rcserver 에서의 테이블 스페이스와 testdb 의 테이블 스페이스를 각각 비교

- rcserver 에서의 확인은 당연히 rcuser 로 접속하거나 rcuser.rc_datafile 로 테이블을 select 해야 하는 것은 당연지사.

 

- testdb 에서의 테이블 스페이스 구조와 rcserver 의 rc_datafile 의 카탈로그 테이블의 구조가 같은 것을 확인할 수 있습니다.

Undo tablespace

- 사용자가 DML 을 수행할 경우 원본 데이터(undo data)들을 저장해 두는 특별한 Tablespace

- 사용자가 생성 가능하며 관리 할 수 있음

- Undo 라는 용어는 8i 버전까지 rollback 이라는 용어로 사용됨

 

1. Undo tablespace 의 특징

- Oracle Server Process 는 이 Tablespace 에 Undo segment 를 생성하고 기본적으로 각 사용자 별로 undo segment(ex: _SYSMU1$) 를 할당하여 관리하며 사용자는 관여할 수 없음

- Undo tablespace 는 Instance 당 여러 개가 동시에 존재 할 수 있지만 사용되는 것은 한번에 1개이다.

-> create undo tablespace undo01 datafile '/~~~~/undo01.dbf' size 10M 으로 만들어 줘도 파라미터에 적용 시키지 않으면 바뀌지 않음

- 관리 방법은 AUM(Automatic Undo Management) 과 MUM(Manual Undo Management) 이 있음 -> 9i 버전 부터는 AUM 방식을 권장

 

2. Undo Tablespace 의 사용 목적

- Transaction Rollback – 사용자가 rollback 이라는 명령어를 수행할 경우에 이곳에 저장된 undo data를 사용해서 rollback 을 수행함

- Read Consistency (읽기 일관성) –CR 작업을 통해 트랙잭션이 끝나지 않은 데이터는 변경 전 데이터를 보여줌.

- 다음 그림과 같이 update 가 발생하면 Datafile 에서 DB Buffer Cache 로 데이터 블록을 불러오게 되며 블록에는 lock 이 설정되어 아무도 내용을 볼 수 없는 상태

- 또한 원본 Data(Undo Data) 는 undo segment 에 저장되게 된다.

 

- Update 가 수행되던 중 사용자 2에 의해서 select 가 수행되었을 때 undo segment 에서 DB Buffer Cache 로 원본 Data 를 복사하여 사용자 2에게 결과값을 보여주게 됩니다. 대신 1(홍길동) Data 는 lock 이 설정되어 commit 이나 rollback 이 수행되기 전까지는 1 block 에 다른 사용자가 접근할 수 없습니다.

- Transaction Recovery (Instance recovery) : 운영 중이던 DB 서버가 비정상적으로 종료 되었을 때 Roll Forward 와 Roll backward 작업을 수행해서 Dirty Database 를 Clean DB 로 만들어 주는 과정에 사용됨

 

- Undo Parameter 확인

- 신규 Undo Tablespace 생성

SQL>create undo tablespace undo01

2 datafile '/data/temp2/undo01.dbf' size 10M

3 autoextend on;

Tablespace created.

- Undo tablespace 를 생성 하여도 파라미터 파일을 변경 하여야 함.

SQL>alter system set undo_tablespace=undo01;

 

-PFILE 의 경우 파라미터 값을 직접 변경해야 나중에 다시 DB Open 시 문제가 발생하지 않는다.

 

- 각 세션 별로 사용중인 undo segment 확인

SQL>select s.sid,s.serial#,s.username,r.name "ROLLBACK SEG"

1 from v$session s,v$transaction t,v$rollname r

2 where s.taddr=t.addr

3 and t.xidusn = r.usn;

 

 

3. Undo segment 할당되는 원리

- Undo tablespace 는 Data file 의 크기가 증가만 되고 절대 줄어들지 않는다.

<하늘색 : 트랜잭션 완료, 갈색 : 트랜잭션 미완료>

 

다음과 같이 사용자가 DML(E) 을 수행하게 되면 가장 먼저 Server Process 는 Undo Segment 를 확보하게 되는데 이 때 기존에 만들어져 있던 Segment 중 트랜잭션이 완료된 것이 없는지를 확인한 후 그 곳에 덮어쓰게 됩니다.

 

- 다음과 같이 완료된 트랜잭션이 존재하지 않을 경우 새로운 undo segment 를 새로 생성하게 됩니다.

- 이런 식으로 더 이상 빈 공간이 존재하지 않을 경우 Data file 의 저장 공간이 허요하는 범위까지 늘어나다가 만약 더 이상 공간이 없게 되면 하나의 Segment 에 2개 세션 이상의 undo data를 함께 기록하게 됩니다. 이것조차 불가능하게 된다면 해당 트랜잭션은 에러를 발생 합니다.

- Undo tablespace 의 용량을 줄이기 위해서는 새로운 Undo Tablespace 를 생성후 파라미터 값을 변경시킨 다음 기존 Undo Tablespace 를 삭제 하셔야 합니다.

 

4. 주요 Parameter

- undo_retention àcommit 수행 후에도 해당 undo segment 내의 데이터를 다른 서버 프로세스가 덮어 쓰지 못하고 일정 시간동안 대기 시켜주는 파라미터이며 이 파라미터는 undo segment 의 여분이 존재할 경우에만 적용되며 항상 보장하지 않습니다.

 

- undo_retention_guarantee à undo_retention 파라미터는 여분이 존재하지 않을 경우 undo segment 가 재사용 되어지는데 반해 undo_retention_guarantee 파라미터는 설정된 시간동안 무조건 보장해줍니다.

 

- Oracle 10g 버전 부터는 ORA-01555:Snapshot too old 라는 에러를 줄이기 위해 undo retention 을 자동으로 관리하는 기능을 제공합니다.

- 다음은 undo tablespace 를 확인하고 guarantee 로 바꿔주는 명령어

 

SQL>alter tablespace undotbs retention noguarantee;

- no guarantee 로 변경하는 명령어

 

- NOT APPLY 는 Undo tablespace 가 아니므로 적용할 수 없습니다.

실전! 오라클 백업과 복구
국내도서>컴퓨터/인터넷
저자 : 서진수
출판 : 생능출판사 2010.09.06
상세보기

'Oracle > Admin' 카테고리의 다른 글

Differences between a Connection and a Session  (0) 2011.10.06
ORACLE Overview of Primary Components  (1) 2011.09.30

+ Recent posts