다른 명령
SCN 과 체크 포인트
- 사용자가 Commit을 하게 되면 Oracle 내부적으로 SCN 번호를 생성해서 트랜잭션을 관리
SCN(System Change Number, System Commit Number)
SCN 이란?
- Commit 할 때 생성되는 번호, 트랜잭션을 관리하며 장애 발생 시 복구도 함
- Commit이 발생 할 때마다 모든 트랜잭션에 고유한 SCN 번호가 부여됨 (트랜잭션 단위로 할당)
- SCN = SCN base(4bytes) + SCN Wrap(2bytes)
- SCN base 값이 전부 다 사용되면 SCN Wrap 값이 하나씩 증가되어 사용하게 됨
- 만약 이 SCN이 모두 다 사용되면 다시 0으로 reset 된 후 새로운 Incarnation으로 할당되어 다시 시작
- SCN은 Sequence에서 발생시키는 것이 아니라 Steve adams가 개발한 ‘Kcmgas’라는 Function으로 구현
오라클 기동시 SCN 동기화
- SCN은 datafile, redolog file, control file간의 동기화 정보를 맞추는 용도로써 사용 됨
- SCN이 다르면 DB가 기동 되지 않음.
- 오라클은 Startup 후 mount 에서 open 시점에 컨트롤 파일의 SCN과 데이터파일의 SCN을 비교한다.
- 만약 다르다면 Redolog file이나 archive log file에서 찾아, 낮은 번호의 SCN부터 차례대로 복구를 수행함.
- 예시) 컨트롤 파일 재생성 후 SCN비교
SQL> select checkpoint_change# from v$database; CHECKPOINT_CHANGE# ------------------ 0 SQL> select name,checkpoint_change# from v$datafile; NAME CHECKPOINT_CHANGE# --------------------------------------------------- ------------------- /app/oracle/cfgtoollogs/orcl/system01.dbf 5647538 /app/oradata/dbms_data001.dbf 5647538 /app/oracle/cfgtoollogs/orcl/sysaux01.dbf 5647538 /app/oracle/cfgtoollogs/orcl/undotbs01.dbf 5647538 /app/oracle/cfgtoollogs/orcl/example01.dbf 5647538 /app/oracle/cfgtoollogs/orcl/users01.dbf 5647538
SCN 종류
- 여러 종류의 SCN이 존재함
SCN 종류 | 설 명 |
---|---|
current SCN | 시스템의 현재 SCN |
system checkpoint SCN | 마지막 checkpoint 시점의 SCN |
controlfile checkpoint SCN | 컨트롤파일에 있는 데이터파일의 SCN |
datafile checkpoint SCN | 데이터파파일에 있는 SCN |
start SCN | checkpoint가 종료될 때 데이터파일의 헤더 부분에 기록되는 SCN |
stop SCN | DB가 운영 중이면 stop SCN 값은 null임. DB를 정상 종료할 경우 .stop SCN은 start SCN과 같은 값을 가짐. 만약 abort 옵션으로 DB를 내리게 된다면 stop SCN 값은 무한대를 가짐. |
SCN이 저장 되는 곳
- Control File Header
select checkpoint_change# from v$database; -- #컨트롤파일에 저장된 SCN 조회
- - Checkpoint 발생 할 때
- - Resetlogs 발생 할 때
- - Incomplete Recovery 수행 할 때
- Data Blocks(Cache Layer)
- - Block Cleanout 시 마지막 SCN을 각 Block에 기록
- Data Blocks(ITL Entries)
- - Data Block의 Transaction Layer 안에 있는 ITL(Interested Transaction List) Entries 안에 Commit 된 SCN 정보를 기록(Delayed Block Cleanout).
- Data File Headers(모든 데이터 파일 헤더에 기록)
select name,checkpoint_change# from v$datafile;
- - 마지막 Checkpoint 발생 때
- - Begin Backup 수행 때
- 복구가 되었다면 사용된 마지막 SCN을 기록
- Redo Records / Log Buffer
- – Commit이 수행되면 Commit Records에 SCN을 포함하여 저장
- 그 외 Rollback Segment(Undo Segment)와 Tablespace Headers에도 기록
Commit 관련된 파라미터 (11g)
SQL> show parameter commit; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ commit_logging string commit_point_strength integer 1 commit_wait string commit_write string
SQL> alter system set commit_logging = immediate ; System altered.
SQL> alter system set commit_wait = nowait ; System altered.
SQL> alter system set commit_write = immediate, nowait; System altered.
SQL> show parameter commit ; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ commit_logging string IMMEDIATE commit_point_strength integer 1 commit_wait string NOWAIT commit_write string IMMEDIATE, NOWAIT
- - max_commit_propagation_delay : (RAC 환경으로 가정하고 설명)
- 만약 홍길동이라는 데이터를 양쪽 노드에서 다 호출한 후 node 1에서 일지매로 업데이트 한 후에 commit 하고
- commit과 거의 동시에 node2에서 누군가 홍길동 정보를 조회했다고 가정하면 분명히 node 1에서 홍길동 정보를
- 일지매로 변경 후에 Commit 했기 때문에 node 2에서는 홍길동이 아닌 일지매로 보여야 할 것이다.
- 그러나 아직 node 1에서 commit 된 정보가 node 2에 도달하지 않으면 node 2에서는 잘못된 정보를 볼 수 있는
- 문제가 발생
- ⇒ Oracle 에서는 node 1에서 발생한 정보를 node 2에 전송할 때 Piggyback이란 방식으로 전송
- - Piggyback : Commit이 발생하면 즉시 보내는 것이 아니라 다른 메시지가 갈 때 함께 업혀서 가는 방식
- ⇒ 메시지 발생양은 작고 트래픽 양은 작은 장점이 있으나 틀린 내용을 조회할 수 있다는 단점
- → max_commit_propagation_delay 파라미터를 사용해서 전송시간을 제어 함
※ 10g부터는 이 파라미터의 기본 값이 0으로 설정되어 무조건 commit을 하자마자 전송을 하도록 설정
(이러한 방식을 Broadcast On Commit, BOC 방식이라고 함)
체크포인트 (CheckPoint)
CheckPoint란 ?
- - Commit 된 데이터를 어디까지 저장했는지 확인하기 위해서 만들어 놓은 개념
- ex) SCN이 100번까지 Commit 되었고 CheckPoint 정보가 90번 이라면 SCN 90번 트랜잭션 까지는 데이터 파일에 저장 되었다고 확인 됨.
- DB Buffer Cache의 변경된 Dirty Buffer들을 Data File로 저장하는 것을 Checkpoint라고 함
- Control File 과 Data File의 Checkpoint 정보를 비교하여 서로 정보가 다르면 다른 부분을 Online Redo Log 나 Archived Redo Log를 참조해서 복구
Database / Global Checkpoint
- Checkpoint가 발생하면 Buffer Cache에 있는 모든 저장 안 된 Drity Buffer들의 내용을 전부 데이터 파일로 저장,
- 저장된 SCN 중 가장 번호가 큰 SCN 번호(Checkpoint SCN)를 Control File과 Data File Header 부분에 기록
Thread Checkpoint / Logical Checkpoint
- 해당 Thread 내의 저장되 않은 모든 Dirty Buffer들을 Data File로 전부 내려 씀.
- 이 Checkpoint는 Log Switch가 발생하면 생김, RAC 환경일 경우 각 노드별로 다르게 발생
- Single Instance 일 경우 Database Checkpoint와 같은 역할
Data File Checkpoint
- 특정 데이터 파일에만 발생하는 Checkpoint
- 해당 Tablespace를 Offline 한다거나, Begin Backup 수행 시 발생
- 이 Checkpoint가 발생하면 해당 정보를 Control File과 Data File Header 부분에 기록
Mini Checkpoint
- Drop Table과 같이 특정한 DDL 발생 시 특정 블록에만 발생
Recovery Checkpoint
- 데이터 파일에 장애가 발생했을 때 백업된 데이터 파일 복원 후 Redo Change Vector를 적용시키게 됨,
- 그 후 Recovery된 블록을 데이터 파일에 저장해야 하는데 이때 발생하는 Checkpoint를 말함
- Oracle은 우선순위를 두어서 Checkpoint를 관리 함
- 우선 순위가 높을 경우 Fast Checkpoint,
- 우선 순위가 낮을 경우 Low Checkpoint로 분류
- 두 가지가 동시에 발생 할 경우 Fast Checkpoint부터 진행