출처: https://lilo.tistory.com/48
- SCN(System Change Number)
1) DB의 변경이 발생한 시점 즉, Commit이 발생하면 트랜잭션은 고유한 번호를 받음,
2) 이 때 발생한 번호로 트랜잭션들을 관리할 수 있고 장애 발생시 복구 키가 됨
※ 여기서 트랜잭션 관리는 읽기 일관성을 뜻하며 사용자들에게 가장 최근에 커밋된 데이터를 보여주는 것임
3) Data File, Control File, Redo Log File의 동기화 정보를 맞춤
- SCN에 기록된 파일을 이용한 복구 위치 알기
1) Data File: 실제 데이터가 저장되는 디스크 상의 물리적 파일
※ 이 파일을 OS 상에서 삭제 및 이동하면 안되고 DB에서 삭제해야 됨
2) Control File: DB의 제어 정보를 가지고 있는 파일
※ 이 파일이 손상되면 Mount, Open할 수 없기 때문에 2개 이상으로 백업해서 각자 다른 디스크에 백업하는 것을 권고
3) Redo Log File: DB에서 생긴 모든 변화를 기록한 파일
※ 장애 복구에 가장 핵심이 되는 파일임. 수정된 내용을 Data File에 반영하는데 실패하더라도 변경 사항은 Redo Log File에서 얻을 수 있기 때문에 작업 내용은 유실되지 않음
- SCN이 다르다면 어떻게 될까?
1) SCN이 달라지면 DB가 정상적으로 올라오지 않음
2) Oracle이 Startup된 후 Mount --> Open되는 시점에 Control File과 Data File의 SCN을 비교해서 DB를 올릴지 판단함
출처: https://lilo.tistory.com/48 [LILO:티스토리]
|
2011. 1. 29. 14:13 https://blog.naver.com/xxsaintxx/20121568517 |
SCN은 DB의 동기화를 위해서 사용됩니다.
각 파일들에 저장된 SCN이 같다면 모든 데이터 파일은 동기화 즉 같은 시점까지 되어있다는 것이죠.
DB를 STARTUP을 할때 이 정보가 틀리게 되면 STARTUP이 되지 않습니다.
그때는 복구가 필요하다는 의미가 되겠죠.
참고로 아래글은 SCN에 대한 글입니다. 참고하세요
SCN 이란?
SCN이란? 오라클은 특정한 시점의 데이타베이스 상태를 SCN으로 관리하는데 어떤 트랜잭션이 commit 되면, SCN은 최근의 SCN 보다 크고 유일한 값이 할당되며, 이 값은 그 트랜잭션이 변경시킨 블럭에 반영되고, 또한 데이타화일의 가장 최근의 SCN은 데이타화일의 헤더에 기록 됩니다.
아래에는 SCN이 이용되는 경우에 대해 몇가지 적었습니다.
참고 하세요~
1. Oracle Startup 내부적 과정
$ORACLE_HOME/dbs/init$ORACLE_SID.ora file를 찾는다
.
$ORACLE_SID.ora file내의 지정된 config file를 포함하여 parameter 내용을 참조하여 Oracle backgroud process를 startup 한다.
(nomount )
control_file이라는 parameter에 지정된 control file를 읽는다.
(mount )
control file내에 설정되어 있는 Datafile 및 redolog file를 읽은 후 SCN이 일치하는가를 check한 후에 만약 틀리면 redolog를 이용하여 Recover 한 후 startup한다.
2. Listing Status Information About Data Files
SQL> SELECT name,
2 rfile#,
3 status,
4 checkpoint_change# "CHECKPOINT"
5 FROM v$datafile;
NAME RFILE# STATUS CHECKPOINT
----------------------------------------------------------------
C:\ORACLE\ORADATA\WINK\SYSTEM01.DBF 1 SYSTEM 7041729
C:\ORACLE\ORADATA\WINK\UNDOTBS01.DBF 2 ONLINE 7041729
C:\ORACLE\ORADATA\WINK\CWMLITE01.DBF 3 ONLINE 7041729
C:\ORACLE\ORADATA\WINK\DRSYS01.DBF 4 ONLINE 7041729
C:\ORACLE\ORADATA\WINK\EXAMPLE01.DBF 5 ONLINE 7041729
C:\ORACLE\ORADATA\WINK\INDX01.DBF 6 ONLINE 7041729
C:\ORACLE\ORADATA\WINK\ODM01.DBF 7 ONLINE 7041729
C:\ORACLE\ORADATA\WINK\TOOLS01.DBF 8 ONLINE 7041729
C:\ORACLE\ORADATA\WINK\USERS01.DBF 9 ONLINE 7041729
C:\ORACLE\ORADATA\WINK\XDB01.DBF 10 ONLINE 7041729
10 개의 행이 선택되었습니다.
RFILE#은 각 데이타 화일의 화일 숫자로 리스트 하며 데이타베이스를 갖고 create 되었던,
SYSTEM tablespace에 있는 첫번째 데이타 화일은 항상 화일 1 입니다.
STATUS은 데이타 화일에 대해 다른 정보로 리스트 합니다.
만약 데이타 화일이 SYSTEM tablespace의 부분에 있다면, 상태는 SYSTEM 입니다.
(만약 recovery를 요구 하지 않는다면)
만약 non-SYSTEM tablespace에 데이타 화일이 online으로 된다면, 상태는 ONLINE 이구요,
non-SYSTEM tablespace에 데이타 화일이 offline으로 된다면, 상태는 OFFLINE이나 RECOVER 중 하나로 될 수 있습니다.
CHECKPOINT는 데이타 화일의 가장 최근의 checkpoint에 기록된 마지막의 SCN을 리스트 합니다.
3. Oracle은 "fast commit" mechanism을 사용 하므로 사용자가 COMMIT문장을 사용하면 LGWR은 commit record를 즉시 redo log buffer에 기록하지만 해당 data buffer의 변경들은 redo log buffer들을 datafile들에 write하는 것을 더 효과적으로 할 때까지 지연 되는 것입니다.
User가 transaction을 commit 할 때, transaction은 System Change Number(SCN)를 할당받고 Oracle은 redo log에 transaction의 redo log entry들과 함께 기록 합니다.
Activity가 빈번하다면, LGWR은 group commit을 사용하여 online redo log file에 write할 수도 있습니다.