테이블 복구 사례
2010.05.12 08:32
원문 : http://www.ischo.net -- 조인상 // 시스템 엔지니어
Writer : http://www.ischo.net -- ischo // System Engineer in Replubic Of Korea
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
본문 : http://www.ischo.net -- 조인상 //시스템 엔지니어
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
지금 실제로 서비스중인 DB가 있습니다.
DB의 케렉터셋은 UTF8이고 이 DB에는 일본어와, 한국어, 영어 데이터가 들어가 있습니다.
이 DB의 전체 백업은 2001년 5월 21일날 받아 두었습니다.
그리고 그 이후에 아카이브모드로 해서 아카이브파일들을 백업받고 있었죠..
그러던 어느날(2002년 5월 29일) 신입사원이 테스트DB에서 작업을 하다가
서비스중인 DB에 접속할 일이 있어서..잠시 접속을 해서 작업을 하던중..
실수로 테이블을 삭제 시켰습니다.
SQL>DROP TABLE kpc_ctnt;
이론..큰 실수를 해 버렸습니다. 긴급사항이 발생했습니다.
kpc_ctnt테이블에는 실제 서비스중인 데이터가 2000rows가 넘게 있었거든요..
근데 이 DB의 특징은 export받은 파일을 import하면 웹어서 일본어가 깨진다는 거죠..
DB를 설치할때 뭘 잘못해났는지 모르겠지만..
이거 exp파일을 import할 수가 없는 상황이었습니다.
그래서 생각한 것이 불완전 복구(Incomplete Recovery) 였습니다.
전 OCP만 있지..실제로 recovery를 한번도 안 해 봤습니다.
스터디하면서 이론상으로 공부한것이 전부 였죠..
다른 회사의 DBA들도 Recovery하는 경우는 거의 발생하지가 않죠..
그래서 우리 대리님께서 앞장을 서서 복구를 시작 하셨습니다.
우선 운영중인 웹 사이트 서비스를 죽이고..
DB를 죽이고.. 전체 백업을 받았습니다.
cp -R ctldbf /datas/
cp -R defdbf /datas/
cp -R logdbf /datas/
cp -R kpcdbf /datas/
cp -R tmpdbf /datas/
cp -R oradata /datas/
cp -R sysdbf /datas/
cp -R kpctst /datas/
모든 데이터파일과 control파일, 리두로그 파일, 등등..다른 하드디스크로 복사를 했죠..
그리고 데이터베이스를 마운트 시켰습니다.
SVRMGR>startup mount
어쩌구 저쩌구 하더니 마운트가 됐습니다.
이상태에서 2001년 5월 21일자 데이터파일들를 Restore시켰습니다.
cp -R defdbf /datas/
cp -R kpcdbf /datas/
cp -R tmpdbf /datas/
cp -R oradata /datas/
cp -R sysdbf /datas/
그리고 나서 타임베이스로 Incomplete Recovery를 수행 시켰습니다.
SVRMGR>recover database until time '2002-05-29:00:00:00';
명령이 잘 수행이 되더라구요..
오라클에서 알아서 아카이브 파일들을 찾아서 복구를 시킵니다.
AUTO로 할건지.. 그냥 엔터키를 치면서 하나하나씩 아카이브 파일을 복구 시킬껀지.
그냥 CANCEL을 쳐서 중간에 복구를 끝마칠수도 있더라구요..
그래서 복구가 다 끝난지 알았는데..
맨 마지막 아카이브 파일을 읽는 순간 에러가 발생하더라구요..
그거때문에 우리 대리님께서 밤을 지새우셨읍니다.
그 이유를 알고 봤더니..
2001년 5월 21일 풀 백업을 받아놓은 상태에서 테이블 스페이스가 4개가 더 생겼더라구요..
물리적으로 DBF 파일도 4개가 더 생겼구요..
그 에러를 해결하기 위해서.. 데이터파일을 복사해서 만들어 주었죠..
사실 이게 정확한 방법인줄은 잘 모르겠고
하두 답답해서 우리대리님께서 시도 하시더라구요..
SVRMGR>ALTER DATABASE CREATE DATAFILE
'/datas/kpcdbf/kpc_context01.dbf'
AS
'/datas/kpcdbf/kpc_context01.dbf';
이렇게 해서 새로생긴 데이터파일들을 모두 복사했습니다.
명령어를 수행하고..
불완적 복구를 다시 시도했습니다.
SVRMGR>recover database until time '2002-05-29:00:00:00';
아카이브 파일들을 하나씩 복구시키더니..
무사히 완료되었다고 메세지가 떴습니다.
그리고 모든파일들을 동기화 시키기 위해서 RESETLOGS옵션으로 데이터베이스를 오픈했습니다.
SVRMGR>alter database open resetlogs;
그리고 나서 DB를 가동하니 예전의 데이터가 모두 복구가 되었습니다.
다시 데이터베이스를 shutdown하고..
데이터베이스 FULL Backup를 받았습니다.
무엇보다 중요한것은 archive mode로 운영하고..
FULL백업을 자주 받아 두는거 같습니다.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
지금 실제로 서비스중인 DB가 있습니다.
DB의 케렉터셋은 UTF8이고 이 DB에는 일본어와, 한국어, 영어 데이터가 들어가 있습니다.
이 DB의 전체 백업은 2001년 5월 21일날 받아 두었습니다.
그리고 그 이후에 아카이브모드로 해서 아카이브파일들을 백업받고 있었죠..
그러던 어느날(2002년 5월 29일) 신입사원이 테스트DB에서 작업을 하다가
서비스중인 DB에 접속할 일이 있어서..잠시 접속을 해서 작업을 하던중..
실수로 테이블을 삭제 시켰습니다.
SQL>DROP TABLE kpc_ctnt;
이론..큰 실수를 해 버렸습니다. 긴급사항이 발생했습니다.
kpc_ctnt테이블에는 실제 서비스중인 데이터가 2000rows가 넘게 있었거든요..
근데 이 DB의 특징은 export받은 파일을 import하면 웹어서 일본어가 깨진다는 거죠..
DB를 설치할때 뭘 잘못해났는지 모르겠지만..
이거 exp파일을 import할 수가 없는 상황이었습니다.
그래서 생각한 것이 불완전 복구(Incomplete Recovery) 였습니다.
전 OCP만 있지..실제로 recovery를 한번도 안 해 봤습니다.
스터디하면서 이론상으로 공부한것이 전부 였죠..
다른 회사의 DBA들도 Recovery하는 경우는 거의 발생하지가 않죠..
그래서 우리 대리님께서 앞장을 서서 복구를 시작 하셨습니다.
우선 운영중인 웹 사이트 서비스를 죽이고..
DB를 죽이고.. 전체 백업을 받았습니다.
cp -R ctldbf /datas/
cp -R defdbf /datas/
cp -R logdbf /datas/
cp -R kpcdbf /datas/
cp -R tmpdbf /datas/
cp -R oradata /datas/
cp -R sysdbf /datas/
cp -R kpctst /datas/
모든 데이터파일과 control파일, 리두로그 파일, 등등..다른 하드디스크로 복사를 했죠..
그리고 데이터베이스를 마운트 시켰습니다.
SVRMGR>startup mount
어쩌구 저쩌구 하더니 마운트가 됐습니다.
이상태에서 2001년 5월 21일자 데이터파일들를 Restore시켰습니다.
cp -R defdbf /datas/
cp -R kpcdbf /datas/
cp -R tmpdbf /datas/
cp -R oradata /datas/
cp -R sysdbf /datas/
그리고 나서 타임베이스로 Incomplete Recovery를 수행 시켰습니다.
SVRMGR>recover database until time '2002-05-29:00:00:00';
명령이 잘 수행이 되더라구요..
오라클에서 알아서 아카이브 파일들을 찾아서 복구를 시킵니다.
AUTO로 할건지.. 그냥 엔터키를 치면서 하나하나씩 아카이브 파일을 복구 시킬껀지.
그냥 CANCEL을 쳐서 중간에 복구를 끝마칠수도 있더라구요..
그래서 복구가 다 끝난지 알았는데..
맨 마지막 아카이브 파일을 읽는 순간 에러가 발생하더라구요..
그거때문에 우리 대리님께서 밤을 지새우셨읍니다.
그 이유를 알고 봤더니..
2001년 5월 21일 풀 백업을 받아놓은 상태에서 테이블 스페이스가 4개가 더 생겼더라구요..
물리적으로 DBF 파일도 4개가 더 생겼구요..
그 에러를 해결하기 위해서.. 데이터파일을 복사해서 만들어 주었죠..
사실 이게 정확한 방법인줄은 잘 모르겠고
하두 답답해서 우리대리님께서 시도 하시더라구요..
SVRMGR>ALTER DATABASE CREATE DATAFILE
'/datas/kpcdbf/kpc_context01.dbf'
AS
'/datas/kpcdbf/kpc_context01.dbf';
이렇게 해서 새로생긴 데이터파일들을 모두 복사했습니다.
명령어를 수행하고..
불완적 복구를 다시 시도했습니다.
SVRMGR>recover database until time '2002-05-29:00:00:00';
아카이브 파일들을 하나씩 복구시키더니..
무사히 완료되었다고 메세지가 떴습니다.
그리고 모든파일들을 동기화 시키기 위해서 RESETLOGS옵션으로 데이터베이스를 오픈했습니다.
SVRMGR>alter database open resetlogs;
그리고 나서 DB를 가동하니 예전의 데이터가 모두 복구가 되었습니다.
다시 데이터베이스를 shutdown하고..
데이터베이스 FULL Backup를 받았습니다.
무엇보다 중요한것은 archive mode로 운영하고..
FULL백업을 자주 받아 두는거 같습니다.