Table Recovery using Clone DB

게시 날짜: 2011/11/15, 카테고리: ADMIN, ORACLE
태그:, ,

Table 을 purge 를 이용하여 드롭하였을 경우 플래시백 테이블 명령을 통해 복구할 수 없다. 우연찮게도 필요 없을 줄 알고 깨끗하게 지우기 위해 drop table tablename purge 를 사용하였는데, 갑자기 현업에서 그 테이블의 데이터가 필요하다고 요청이 오면 적지 않이 당황할 수 있다.

쫄지마 시바. 우린 DBA 이다. 까짓거 멋지게 복구해 준다음 현업에게 전화해서 이렇게 한마디 해주자.

“(매우 공손하게)복구 다 되었습니다.”

차마 갈굴 순 없다. 왜나하면 난 마음이 약하니까. 뭐, 어쩌겠냐만 이러한 것도 우리가 해야할 일 중 하나이니 해달라면 해 줄 수 밖에. 물론 DBA라고 테이블을 마음대로 지울 순 없을 것 이다. 테이블을 지우는 것은 현업 사용자들의 요구 및 확인을 거쳐 삭제하게 될 터인데 그들도 사람이라 실수 할 수 있으니까 말이다.

잡설은 이제 여기까지 하고 이제 Test 장비등을 이용하여 클론 DB를 생성 후, 복구를 수행하도록 하자.

Condition & Scenario

  1. 일정한 주기로 데이터베이스는 콜드 백업을 수행한다.
  2. 데이터베이스는 아카이브 모드이다.
  3. 어느날 현업에서 테이블 A 를 삭제해 달라는 요청을 받는다.
  4. 요청에 따라 테이블 삭제. (편의상 14:00:00 분)
  5. 하지만 이내 그 테이블의 데이터가 필요하게 되어서 복구 요청 받음.
  6. CloneDB 를 생성하여 14:00:00 이전까지 데이터를 복구
  7. exp/imp 유틸리티를 사용하여 데이터를 복구

Recovery Step 1. Creation Clone Database

운영하고 있는 데이터베이스의 콘트롤 파일을 트레이스로 백업을 받는다.

SQL> alter database backup controlfile to trace

Clone db  는 데이터베이스를 복구하면서 resetlogs 를 사용할 것이다. 생성된 트레이스 파일을 열고 resetlogs 부분을 찾아서 편집한다.

CREATE CONTROLFILE SET DATABASE "FSDBP_BK" RESETLOGS  ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 '/datafiles/fsdbp_bk/redo01.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 2 '/datafiles/fsdbp_bk/redo02.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 3 '/datafiles/fsdbp_bk/redo03.log'  SIZE 50M BLOCKSIZE 512
-- STANDBY LOGFILE
DATAFILE
  '/datafiles/fsdbp_bk/system01.dbf',
  '/datafiles/fsdbp_bk/sysaux01.dbf',
  '/datafiles/fsdbp_bk/undotbs01.dbf',
  '/datafiles/fsdbp_bk/fsts001_d.dbf'
CHARACTER SET KO16MSWIN949;

데이터 베이스 이름을 변경하기 위해 및줄친 부분을 자신이 복구하고자 하는 클론 데이터베이스의 명으로 맞게 고친다. 로그파일의 위치 및 데이터 파일의 위치도 각자 자신의 상황에 맞게 수정하도록 한다. 절대로 현재 사용하고 있는 운영쪽과 경로 및 파일명이 겹치지 않게 수정하도록 한다. 그런 실수 하지 않을거라 믿는다. 여기서는 해당 테이블이 있었던 테이블스페이스의 데이터 파일명이 fsts001_d.dbf 이다. 복구에 필요한 이 네개의 데이터파일만 남겨놓고 나머지는 다 삭제한다.

이제 운영 데이터베이스에서 클론 데이터베이스의 인스턴스를 띄우기 위해 초기화 파라메터 파일을 생성한다.

SQL> create pile from spfile;

생성된 pfile 을 수정한다. 콘트롤 파일의 위치등을 클론 디비가 만들어질 위치로 지정하고 저장한다. 이 내용을 읽고 있을 수준이라면 다들 알거라 믿지만, 혹시 모르는 사람을 위해 적자면, 위 명령을 통해 생성된 초기화 파일은 $ORACLE_HOME/dbs/init<SID>.ora 형식으로 생성된다. 파일명을 자신의 클론디비명으로 맞게 수정하고 vi 편집기 등을 통하여 경로 역시 클론디비를 생성할 곳에 맞춰 수정해 주어야 한다. 본 포스팅에서 클론 디비는 fsdbp_bk 이므로 초기화 파일명은 initFSDBP_BK.ora 가 된다.

이제 필요한 파일들을 풀 백업본에서 클론디비의 데이터파일 경로 (위 콘트롤 파일에서 수정한 바로 그 위치)로 복사해 온다. 운영 데이터베이스에서 해당 테이블이 있었던 테이블스페이스의 데이터파일과 system, undo, sysaux 정도만 클론디비의 데이터파일 위치로 가져온다. (이는 위콘트롤파일 재생성 스크립트에서 적어 놓은 파일들이다.)

이제 OS 상에서 SID 를 변경한 후, 클론 DB를 nomount 상태로 기동한다.

$ export ORACLE_SID=FSDBP_BK
$ sqlplus / as sysbda
SQL> startup nomount;

정상적으로 인스턴스가 기동되었다면 이제 콘트롤 파일 재생성 스크립트를 수행한다. 콘트롤 파일 역시 정상적으로 수행되었다면 이제 데이터베이스를 테이블을 드롭하기 이전까지 복구를 수행하도록 한다.

Recovery Step 2. Open Clone Database and recovery table using exp/imp

데이터베이스를 복구한다. 편의상 위에서 테이블을 날린 시간이 14:00:00 분이었다. 콘트롤 파일을 재생성 했으니 해당 콘트롤 파일을 이용하여 복구를 한다. 14:00:00 분 이전으로 복구를 해야하니 until time 명령어도 함께 사용한다.

SQL> recover database using backup controlfile until time ‘2011-11-15:13:59:59’;

미디어 리커버리가 끝났으면 이제 resetlogs 를 이용하여 데이터베이스를 오픈한다.

SQL> alter database open resetlogs

테이블이 정상적으로 복구되었는지 확인하기 위해 해당 테이블을 조회해 본다. 정상적으로 조회가 되었으면, exp(dp) 를 통해 데이터를 추출하고, 추출된 데이터를 이용하여 imp(dp)를 통하여 운영 데이터베이스에 넣어준다.

$ exp userid/password tables=tablename file=dumpfile_name feedback=1000

생성된 덤프파일을 운영 데이터베이스에서 imp 를 수행한다.

$ imp userid/password full=y file=dumpfile_name feedback=1000 direct=y

만약 복구해야 할 데이터가 많다면 export/import 유틸리티보다 데이터 펌프 사용을 권장한다. 디렉토리 설정등 초기 설정이 조금 번잡하지만 빠르게 데이터를 추출하고 넣을 수 있다. 만약 이러한 유틸리티를 사용하기 싫다면 리스너 설정 및 TNS 설정을 통하여 dblink 를 이용하여 데이터를 넣을 수 있다.

(잘못된 부분이 있을 경우 코맨트 남겨 주시면 반영토록 하겠습니다.)

 

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중