RAC운영중 컨트롤파일 재생성해서 CLONE에 복구시
다른 노드에 있던 아카이브파일을 찾지못해서 복구를
못하는 경우에 대한 포스팅입니다.
그래서 그냥 대충 찍어서 파일을 하나 적어줘봤습니다.(아카이브파일은 thread1에서 thread2로 모두 복사해준 상태입니다.)
첫번째 파일은 운좋게 맞았지만, 두번째 파일은 아니군요.
컨트롤파일 재생성으로 인해 thread가 교차해서 archive가 저장되는 경우는 추천되는 archivelog를 찾을 수가 없나봅니다.
이후 원하는 불완전복구를 해보았습니다.
첫번째 추천되는 아카이브 파일때는 그냥 엔터를 쳤고,
두번째도 그냥 엔터를 쳤습니다.
운좋게 두번째까지만 필요해서 복구는 완료가 되었습니다.
관건은 change 숫자 에 해당하는 아카이브로그 파일을 어떻게 찾느냐 입니다.
방법 1: v$archived_log 이용
포스팅 종료
-----------------------------------------------------------------
-----------------------------------------------------------------
logmnr을 사용하는 법은 사용하지 마세요 ^^;
v$archived_log이용하는 방법이 훨씬 좋습니다.
이래서 모르는 만큼 몸이 피곤하게 되네요 ㅠ
방법 2: logmnr 로 change '숫자'에 맞는 아카이브 파일을 한번 찾아보겠습니다.
일단 logmnr에 모든 아카이브 파일이 등록되어있다고 가정하고 (http://gyh214.tistory.com/102 logmnr 참조)
v$logmnr_logs를 이용해서 찾아보겠습니다.
위에서 요구한 284207에 대한 아카이브로그파일을 찾아보면
change 284207 generated at 03/10/2012 10:13:21 needed for thread 2에 대한 아카이브는
THREAD_ID : 2 이고 위 결과 중 2_13_777438049.dbf 임을 알 수 있습니다.
(2_12_777438049.dbf는 NEXT_SCN이 284207이기때문에 아닙니다.)
change 284207 generated at 03/10/2012 09:38:38 needed for thread 1에 대한 아카이브는
THREAD_ID : 1 이고 1_4_777548049.dbf 임을 알 수 있습니다.
추가 :
처음
다른 노드에 있던 아카이브파일을 찾지못해서 복구를
못하는 경우에 대한 포스팅입니다.
결론 : 제대로 된 아카이브 파일을 지정하면 됩니다.
문제점 : 어떻게 제대로 된 아카이브 파일을 찾느냐?
해결 :
1) v$archived_log 를 사용해서 해당 archivelog파일 찾기
상황 : RAC로 노드 2개 운영중 복구하기 위해 cloneDB로 restore 한 후 controlfile 재생성 후 복구시도(thread 2에서 작업함)
그 후 thread 2 에 해당하는 아카이브파일들은 추천파일에 다 적히지만(ORA-00289: suggestion),
thread 1에 해당하는 아카이브 파일들은 추천리스트에 적히지 않음
SQL> recover database using BACKUP CONTROLFILE; ORA-00279: change 284130 generated at 03/10/2012 10:12:25 needed for thread 2 ORA-00289: suggestion : /home/oracle/archive/2_12_777548049.dbf ORA-00280: change 284130 for thread 2 is in sequence #12 Specify log: {=suggested | filename | AUTO | CANCEL} <엔터> ORA-00279: change 284130 generated at needed for thread 1
원래 ORA-00279아래에 추천되는 파일명이 적히는 자리인데
컨트롤파일 재생성으로 인해 다른노드에 있던 아카이브파일은뭐가뭔지 모르므로(추측) 적히지 않고,
단순히 [change 284130 이 생성된, thread 1의] 아카이브 파일이 필요하다고만오라클이 말해줍니다.
그래서 그냥 대충 찍어서 파일을 하나 적어줘봤습니다.(아카이브파일은 thread1에서 thread2로 모두 복사해준 상태입니다.)
Specify log: {=suggested | filename | AUTO | CANCEL} /home/oracle/archive/1_4_777548049.dbf ORA-00279: change 284207 generated at 03/10/2012 10:13:21 needed for thread 2 ORA-00289: suggestion : /home/oracle/archive/2_13_777548049.dbf ORA-00280: change 284207 for thread 2 is in sequence #13 ORA-00278: log file '/home/oracle/archive/2_12_777548049.dbf' no longer needed for this recovery Specify log: { =suggested | filename | AUTO | CANCEL} /home/oracle/archive/1_5_777548049.dbf ORA-00325: archived log for thread 2, wrong thread # 1 in header ORA-00334: archived log: '/home/oracle/archive/1_5_777548049.dbf'
첫번째 파일은 운좋게 맞았지만, 두번째 파일은 아니군요.
컨트롤파일 재생성으로 인해 thread가 교차해서 archive가 저장되는 경우는 추천되는 archivelog를 찾을 수가 없나봅니다.
SQL> recover database until time '2012-03-10:10:13:10' using backup controlfile; ORA-00279: change 284207 generated at 03/10/2012 10:13:21 needed for thread 2 ORA-00289: suggestion : /home/oracle/archive/2_13_777548049.dbf ORA-00280: change 284207 for thread 2 is in sequence #13 Specify log: {=suggested | filename | AUTO | CANCEL} ORA-00279: change 284207 generated at 03/10/2012 09:38:38 needed for thread 1 ORA-00289: suggestion : /home/oracle/archive/1_4_777548049.dbf ORA-00280: change 284207 for thread 1 is in sequence #4 Specify log: { =suggested | filename | AUTO | CANCEL} Log applied. Media recovery complete.
이후 원하는 불완전복구를 해보았습니다.
첫번째 추천되는 아카이브 파일때는 그냥 엔터를 쳤고,
두번째도 그냥 엔터를 쳤습니다.
운좋게 두번째까지만 필요해서 복구는 완료가 되었습니다.
관건은 change 숫자 에 해당하는 아카이브로그 파일을 어떻게 찾느냐 입니다.
방법 1: v$archived_log 이용
select thread#, FIRST_CHANGE#, NEXT_CHANGE#, name from v$archived_log where 288267 between FIRST_CHANGE# and NEXT_CHANGE# SQL> / THREAD# FIRST_CHANGE# NEXT_CHANGE# NAME ---------- ------------- ------------ ------------------------------ 2 284253 288444 /home/oracle/archive/2_23_7775 48049.dbf
이와같이 무정지복구 시 clone쪽에서 컨트롤파일이 재생성되어
제대로 된 아카이브파일을 찾아주지 못할 때는
원래 DB에서 v$archived_log 를 이용해서 적절한 아카이브파일을 찾아주면 됩니다.
포스팅 종료
-----------------------------------------------------------------
-----------------------------------------------------------------
logmnr을 사용하는 법은 사용하지 마세요 ^^;
v$archived_log이용하는 방법이 훨씬 좋습니다.
이래서 모르는 만큼 몸이 피곤하게 되네요 ㅠ
방법 2: logmnr 로 change '숫자'에 맞는 아카이브 파일을 한번 찾아보겠습니다.
일단 logmnr에 모든 아카이브 파일이 등록되어있다고 가정하고 (http://gyh214.tistory.com/102 logmnr 참조)
v$logmnr_logs를 이용해서 찾아보겠습니다.
위에서 요구한 284207에 대한 아카이브로그파일을 찾아보면
SQL> l 1 select FILENAME, LOW_SCN, NEXT_SCN, THREAD_ID 2 from v$logmnr_logs 3* where 284207 between LOW_SCN and NEXT_SCN SQL> / FILENAME LOW_SCN NEXT_SCN THREAD_ID --------------------------------------------- ---------- ---------- ---------- /home/oracle/archive/1_4_777548049.dbf 280085 284239 1 /home/oracle/archive/2_12_777548049.dbf 280082 284207 2 /home/oracle/archive/2_13_777548049.dbf 284207 284209 2
change 284207 generated at 03/10/2012 10:13:21 needed for thread 2에 대한 아카이브는
THREAD_ID : 2 이고 위 결과 중 2_13_777438049.dbf 임을 알 수 있습니다.
(2_12_777438049.dbf는 NEXT_SCN이 284207이기때문에 아닙니다.)
change 284207 generated at 03/10/2012 09:38:38 needed for thread 1에 대한 아카이브는
THREAD_ID : 1 이고 1_4_777548049.dbf 임을 알 수 있습니다.
추가 :
처음
change 284130 generated at 03/10/2012 10:12:25 needed for thread 2
change 284130 generated at needed for thread 1
에 해당하는 파일들도 찾아보면
위와 같이 나옴을 알 수 있습니다.
에 해당하는 파일들도 찾아보면
SQL> l 1 select FILENAME, LOW_SCN, NEXT_SCN, THREAD_ID 2 from v$logmnr_logs 3* where 284130 between LOW_SCN and NEXT_SCN SQL> / FILENAME LOW_SCN NEXT_SCN THREAD_ID --------------------------------------------- ---------- ---------- ---------- /home/oracle/archive/1_4_777548049.dbf 280085 284239 1 /home/oracle/archive/2_12_777548049.dbf 280082 284207 2
위와 같이 나옴을 알 수 있습니다.
'Oracle > 백업&복구' 카테고리의 다른 글
Managing Oracle for High-Availability (가용성) ; 링크 (0) | 2012.04.04 |
---|---|
Datapump 사용시 주의사항 ; newer version --> older version 자료이관시 (0) | 2012.03.24 |
백업&복구 15번째(Flashback) ; Database level, Flashback Data Archive(11g) (0) | 2012.02.25 |
백업&복구 14번째(Flashback) ; Table level (0) | 2012.02.25 |
Flashback Constraint Issue ;Reference Key가 걸린 table 삭제(부모테이블 삭제)후 flashback으로 복구 시 관련 constraint 살펴보기 (0) | 2012.02.21 |