DB 운영시 oracle은 2가지의 checkpoint Number로 자료들의 일관성(Integrity)들을 판단합니다.
checkpoint Number의 종류
1) checkpoint SCN : 모든 데이터파일, 컨트롤파일, 리두로그파일의 checkpoint SCN은 동일합니다.
2) checkpoint CNT : 데이터파일마다 각각 존재하는 번호로, checkpoint 가 발생될때마다 CKPT 프로세서가 동작하는데, 그 때 변하게됩니다. 모든 데이터파일의 checkpoint CNT 번호는 control file에 적혀져 있고, 해당 번호들을 보고 오류가 있는지 없는지 판단합니다.
** 추가로 자료들의 일관성을 판단하는 번호가 하나 더 있는데 stop SCN입니다.
stop SCN : control을 dump떠서 보면 Data file 부분에 나오는데, stop SCN이 0xffff.ffffffff 이면 Instance Crash가 발생했거나, 아니면 OPEN상태에서 덤프를 생성했다는 말입니다. ( 정상종료 후 mount단계에서 덤프떠서 보면, checkpoint SCN = stop SCN입니다.)
컨트롤 파일에는 여러가지 정보들이 있는데
Logfile에서 Low SCN, Next SCN을 보고, log switch가 나서 어떤 그룹에서 어떤 그룹으로 Current가 이동했는지 알 수 있습니다.
복구의 원리
1. Recover나 startup명령어가 실행되면, control file내에서 control file의 checkpoint SCN과 control file안에 기재된 각 datafile들의 checkpoint SCN을 비교합니다. 비교 후 다음 단계로 진행
2. 각 데이터파일의 header에 있는 checkpoint SCN과 control file안의 stop SCN을 비교합니다.(일치 시 clean, 불일치시 복구시도)
(위에서도 설명했다시피, 정상종료일 경우에는 stop SCN과 checkpoint SCN과 동일합니다.)
3. 복구가 필요하다면, datafile에 부족한 SCN중에서 가장 낮은 SCN이 몇번인지 확인 후 control file안에 있는 Log File Record 부분을 참고하여, Low SCN부분을 확인해서 필요한 내용이 들어있는 파일을 찾습니다. 이후 그 경로로 가서 복구해야 하는 내용을 읽어서 필요한 로그파일을 순차적으로 적용시킵니다.
4. 적당한 redo log file을 찾게되면, 우선 가장 낮은 SCN번호부터 Roll Foward하게 됩니다.
5. 4번단계가 끝나면 commit이 수행되지 않은 transaction을 찾기 위해 undo$ 딕셔너리를 찾아보고, 그 안에서 ACTIVE한 undo segment를 찾게 되고, commit안된 데이터를 roll foward합니다.
복구의 2가지 종류
Instance Recovery : Redo log만 사용해서 복구(SMON담당)
Media Recovery : Redo log file에 복구시 원하는 자료가 없어서 Archive log mode운영시, Archive log까지 사용해서 하는 복구
파라미터 장애복구
파라미터파일이 없으면 mount단계까지 올라가지 못하므로, 백업된 파라미터파일을 restore하거나, sample파일을 복사해서 복구해야합니다.
Sample 파일이 있는 경로 : $ORACLE_BASE/admin/DBNAME/pfile/initDBNAME.ora.1927371927 (숫자는 임의의숫자)
다른 파라미터 장애들은 이미 앞에서 다 다루었던 내용이므로 건너뜁니다.
Control File 장애복구
들어가기 전에 : DB이름같으면 mount까지는 무조건 가능합니다.
그래서 컨트롤 파일이 아예 삭제되어버리면, 다른 컴퓨터에 똑같은 DB이름으로 oracle을 설치 한 후 해당 control파일을 복사 후 장애복구를 하셔도 됩니다.
이유? mount단계까지는 컨트롤 파일안에서만 검사하는 단계이므로, datafile과 내용이 완전히 달라도 mount까지는 올라갑니다.
장애유형 1)DB open시에 old control file error가 나고, mount단계까지 올라갑니다.
(datafile정상, redo log정상, controlfile만 old)
원인 : http://gyh214.tistory.com/74
해결 : Control File 재생성 후 noresetlogs으로 DB open
결과 : 애초에 자료에 장애가 발생한 것이 아니므로, 자료들은 아무 이상없음
1. control file재생성 스크립트 만들기
SQL> alter database backup controlfile to trace as '/path/filename.sql';
하시면 해당 경로에 filename.sql이 생성됩니다.
여기에서 NORESETLOG부분만 남기고 나머지는 모두 지웁니다. 또한 스크립트 중앙에 빈칸, 주석줄도 모두 지워줍니다.
2. Idle 상태에서 생성된 실행하기
shutdown 한 후 @/home/oracle/c 와 같이 실행을 시키시면 controlfile이 재생성되면서 MOUNT단계까지 올라가게 됩니다.
3. DB open하기
SQL> alter database open;
** 백업한 파일을 restore한 후 DB를 오픈시킬때 간혹,
--> 이 경우에는 shutdown 한 후, parameter file에
_allow_resetlogs_corruption=TRUE 을 추가한 후 다시 open 시도해보시면 됩니다.
* 주의 : 위 파라미터는 oracle Hidden parameter이므로, 사용시 발생한 문제에 대해 oracle이 책임을 지지 않습니다.
* 위 파라미터를 쓰면 datafile들간의 어긋난 SCN정보를 강제로 동기화 시켜주게 됩니다.
* control file재생성시에 RESETLOGS와 NORESETLOGS 차이
RESETLOGS : database를 open할 때, 모든 logfile들을 다시 생성(이전의 log file들은 포기)하고, checkpoint SCN, log sequence#를 초기화합니다. (alter database open resetlogs;)
--> 이 후, DB open시점 이전의 Archive log file, log file들은 사용이 불가능해집니다.
NORESETLOGS : DB를 정상적으로 open할때 사용되는 옵션입니다.(alter database open;)
* control file 재생성하는 대표적인 유형(이유)
1. control file이 전부 삭제되었을 때
2. old control file관련 에러
3. DB name변경하고 싶을 때
4. 최대 Datafile개수와 redo log file개수를 변경하고 싶을때
등등
checkpoint Number의 종류
1) checkpoint SCN : 모든 데이터파일, 컨트롤파일, 리두로그파일의 checkpoint SCN은 동일합니다.
2) checkpoint CNT : 데이터파일마다 각각 존재하는 번호로, checkpoint 가 발생될때마다 CKPT 프로세서가 동작하는데, 그 때 변하게됩니다. 모든 데이터파일의 checkpoint CNT 번호는 control file에 적혀져 있고, 해당 번호들을 보고 오류가 있는지 없는지 판단합니다.
** 추가로 자료들의 일관성을 판단하는 번호가 하나 더 있는데 stop SCN입니다.
stop SCN : control을 dump떠서 보면 Data file 부분에 나오는데, stop SCN이 0xffff.ffffffff 이면 Instance Crash가 발생했거나, 아니면 OPEN상태에서 덤프를 생성했다는 말입니다. ( 정상종료 후 mount단계에서 덤프떠서 보면, checkpoint SCN = stop SCN입니다.)
컨트롤 파일에는 여러가지 정보들이 있는데
Logfile에서 Low SCN, Next SCN을 보고, log switch가 나서 어떤 그룹에서 어떤 그룹으로 Current가 이동했는지 알 수 있습니다.
복구의 원리
1. Recover나 startup명령어가 실행되면, control file내에서 control file의 checkpoint SCN과 control file안에 기재된 각 datafile들의 checkpoint SCN을 비교합니다. 비교 후 다음 단계로 진행
2. 각 데이터파일의 header에 있는 checkpoint SCN과 control file안의 stop SCN을 비교합니다.(일치 시 clean, 불일치시 복구시도)
(위에서도 설명했다시피, 정상종료일 경우에는 stop SCN과 checkpoint SCN과 동일합니다.)
3. 복구가 필요하다면, datafile에 부족한 SCN중에서 가장 낮은 SCN이 몇번인지 확인 후 control file안에 있는 Log File Record 부분을 참고하여, Low SCN부분을 확인해서 필요한 내용이 들어있는 파일을 찾습니다. 이후 그 경로로 가서 복구해야 하는 내용을 읽어서 필요한 로그파일을 순차적으로 적용시킵니다.
4. 적당한 redo log file을 찾게되면, 우선 가장 낮은 SCN번호부터 Roll Foward하게 됩니다.
5. 4번단계가 끝나면 commit이 수행되지 않은 transaction을 찾기 위해 undo$ 딕셔너리를 찾아보고, 그 안에서 ACTIVE한 undo segment를 찾게 되고, commit안된 데이터를 roll foward합니다.
복구의 2가지 종류
Instance Recovery : Redo log만 사용해서 복구(SMON담당)
Media Recovery : Redo log file에 복구시 원하는 자료가 없어서 Archive log mode운영시, Archive log까지 사용해서 하는 복구
파라미터 장애복구
파라미터파일이 없으면 mount단계까지 올라가지 못하므로, 백업된 파라미터파일을 restore하거나, sample파일을 복사해서 복구해야합니다.
Sample 파일이 있는 경로 : $ORACLE_BASE/admin/DBNAME/pfile/initDBNAME.ora.1927371927 (숫자는 임의의숫자)
다른 파라미터 장애들은 이미 앞에서 다 다루었던 내용이므로 건너뜁니다.
Control File 장애복구
들어가기 전에 : DB이름같으면 mount까지는 무조건 가능합니다.
그래서 컨트롤 파일이 아예 삭제되어버리면, 다른 컴퓨터에 똑같은 DB이름으로 oracle을 설치 한 후 해당 control파일을 복사 후 장애복구를 하셔도 됩니다.
이유? mount단계까지는 컨트롤 파일안에서만 검사하는 단계이므로, datafile과 내용이 완전히 달라도 mount까지는 올라갑니다.
장애유형 1)DB open시에 old control file error가 나고, mount단계까지 올라갑니다.
(datafile정상, redo log정상, controlfile만 old)
원인 : http://gyh214.tistory.com/74
해결 : Control File 재생성 후 noresetlogs으로 DB open
결과 : 애초에 자료에 장애가 발생한 것이 아니므로, 자료들은 아무 이상없음
1. control file재생성 스크립트 만들기
SQL> alter database backup controlfile to trace as '/path/filename.sql';
하시면 해당 경로에 filename.sql이 생성됩니다.
여기에서 NORESETLOG부분만 남기고 나머지는 모두 지웁니다. 또한 스크립트 중앙에 빈칸, 주석줄도 모두 지워줍니다.
남겨야 할 내용들
STARTUP NOMOUNT
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "TESTDB" NORESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
LOGFILE
GROUP 1 '/home/oracle/oradata/testdb/redo01.log' SIZE 50M,
GROUP 2 '/home/oracle/oradata/testdb/redo02.log' SIZE 50M,
GROUP 3 '/home/oracle/oradata/testdb/redo03.log' SIZE 50M
DATAFILE
'/home/oracle/oradata/testdb/system01.dbf',
'/home/oracle/oradata/testdb/undotbs01.dbf',
'/home/oracle/oradata/testdb/sysaux01.dbf',
'/home/oracle/oradata/testdb/users01.dbf',
'/home/oracle/oradata/testdb/example01.dbf'
CHARACTER SET KO16MSWIN949
;
shutdown 한 후 @/home/oracle/c 와 같이 실행을 시키시면 controlfile이 재생성되면서 MOUNT단계까지 올라가게 됩니다.
3. DB open하기
SQL> alter database open;
** 백업한 파일을 restore한 후 DB를 오픈시킬때 간혹,
SQL> alter database open resetlogs; alter database open resetlogs * ERROR at line 1: ORA-01196: file 1 is inconsistent due to a failed media recovery session ORA-01110: data file 1: '/home/oracle/oradata/testdb/system01.dbf'위와 유사한 오류가 뜨고 DB가 open되지 않을 때에는, 백업받을 떄 OPEN BACKUP으로 받아서, 각 data file들 마다 resetlogs들이 corruption이 생겼을 경우입니다.(OPEN BACKUP시에는 각 datafile마다 checkpoint SCN이 다른 경우가 대부분입니다.)
--> 이 경우에는 shutdown 한 후, parameter file에
_allow_resetlogs_corruption=TRUE 을 추가한 후 다시 open 시도해보시면 됩니다.
* 주의 : 위 파라미터는 oracle Hidden parameter이므로, 사용시 발생한 문제에 대해 oracle이 책임을 지지 않습니다.
* 위 파라미터를 쓰면 datafile들간의 어긋난 SCN정보를 강제로 동기화 시켜주게 됩니다.
* control file재생성시에 RESETLOGS와 NORESETLOGS 차이
RESETLOGS : database를 open할 때, 모든 logfile들을 다시 생성(이전의 log file들은 포기)하고, checkpoint SCN, log sequence#를 초기화합니다. (alter database open resetlogs;)
--> 이 후, DB open시점 이전의 Archive log file, log file들은 사용이 불가능해집니다.
NORESETLOGS : DB를 정상적으로 open할때 사용되는 옵션입니다.(alter database open;)
* control file 재생성하는 대표적인 유형(이유)
1. control file이 전부 삭제되었을 때
2. old control file관련 에러
3. DB name변경하고 싶을 때
4. 최대 Datafile개수와 redo log file개수를 변경하고 싶을때
등등