테이블 복구 사례
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백업을 자주 받아 두는거 같습니다.
댓글 0
번호 | 제목 | 글쓴이 | 날짜 | 조회 수 |
---|---|---|---|---|
15 | Oracle Database 2 Day DBA - 부록 A. ASM | 조인상 | 2012.04.05 | 18678 |
14 | ORA-01555 : snapshot too old: rollback segment number %s with name \"%s\" too small | ischo | 2012.04.10 | 19266 |
13 | ASM 정리자료 | 조인상 | 2012.04.26 | 14511 |
12 | Introduce Oracle ExaData | 조인상 | 2012.05.24 | 13694 |
11 | datafile, redolog, controlfile 위치 변경하기 | 조인상 | 2012.08.02 | 24625 |
10 | SQL study - 특정열 앞에 순차적인 값 붙여 나열하기 | 조인상 | 2012.11.23 | 14835 |
9 | Orace Lisence 정책 | 조인상 | 2013.01.22 | 13812 |
8 | SQL developer 실행시 jvm.dll 오류 발생 조치 방법 | 조인상 | 2013.01.23 | 19766 |
7 | Oracle Database 10g: New Features for Oracle8i OCPs | 조인상 | 2013.05.13 | 13469 |
6 | checkpoint not complete에 대해서 | ischo | 2013.05.22 | 252 |
5 | REDO 로그 그룹의 용량을 늘리기 [1] | 조인상 | 2013.05.22 | 15180 |
4 | ORA-28002 : the password will expired within N days | 조인상 | 2014.01.09 | 11276 |
3 | ORA-28040 : No matching authentication protocol | 조인상 | 2014.11.13 | 67285 |
2 | Oracle expdp 로 백업하기 | 조인상 | 2015.02.23 | 9094 |
1 | 일반유저에게 kill session 권한 주기 | ischo | 2019.08.12 | 22324 |