"SCN 과 CHECK POINT"의 두 판 사이의 차이
DB CAFE
(→SCN이 저장 되는 곳) |
(→Checkpoint) |
||
118번째 줄: | 118번째 줄: | ||
(이러한 방식을 Broadcast On Commit, BOC 방식이라고 함) | (이러한 방식을 Broadcast On Commit, BOC 방식이라고 함) | ||
− | === | + | === 체크포인트 (CheckPoint) === |
==== CheckPoint란 ? ==== | ==== CheckPoint란 ? ==== | ||
: - Commit 된 데이터를 어디까지 저장했는지 확인하기 위해서 만들어 놓은 개념 | : - Commit 된 데이터를 어디까지 저장했는지 확인하기 위해서 만들어 놓은 개념 |
2024년 4월 17일 (수) 19:39 판
thumb_up 추천메뉴 바로가기
- DBA { Oracle DBA 명령어 > DBA 초급 과정 > DBA 고급 과정 }
- 튜닝 { 오라클 튜닝 목록 }
- 모델링 { 데이터 모델링 가이드 }
목차
1 SCN 과 체크 포인트[편집]
- 사용자가 Commit을 하게 되면 Oracle 내부적으로 SCN 번호를 생성해서 트랜잭션을 관리
1.1 SCN(System Commit Number)[편집]
1.2 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으로 구현
1.3 SCN이 저장 되는 곳[편집]
- Control File Header
- - 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(모든 데이터 파일 헤더에 기록)
- - 마지막 Checkpoint 발생 때
- - Begin Backup 수행 때
- 복구가 되었다면 사용된 마지막 SCN을 기록
- Redo Records / Log Buffer
- – Commit이 수행되면 Commit Records에 SCN을 포함하여 저장
- 그 외 Rollback Segment(Undo Segment)와 Tablespace Headers에도 기록
notifications_active Commit과 관련된 파라미터(10g 기준)
SQL> show parameter commit;
NAME TYPE VALUE
------------------------------------- ----------- -----------------
commit_point_strength integer 1
commit_write string
max_commit_propagation_delay integer 0
- commit_point_strength : 분산 데이터베이스 환경에서 2-Phase Commit에 사용
- commit_write : 사용자가 commit을 하게 되면 LGWR이 해당 트랜잭션을 Redo Log File에 기록
notifications_active 오라클 커밋(commit) 방법
- WAIT(Default) : LGWR가 로그버퍼를 파일에 기록했다는 완료 메시지를 받을 때까지 대기하며, 그 동안 log_file_sync 대기 이벤트가 발생한다(동기식 커밋).
- NOWAIT : LGWR의 완료 메시지를 기다리지 않고 바로 다음 트랜잭션을 진행하므로,log file sync 대기 이벤트가 발생하지 않음(비동기식 커밋).
- IMMEDIATE(Default) : 커밋 명령을 수행 즉시 LGWR가 로그 버퍼를 파일에 기록 한다 .
- BATCH : 세션 내부에 트랜잭션 데이터를 일정량 버퍼링했다가 일괄 처리한다.
SQL> COMMIT WRITE IMMEDIATE WAIT ; -- 1)
SQL> COMMIT WRITE IMMEDIATE NOWAIT ; -- 2)
SQL> COMMIT WRITE BATCH WAIT ; -- 3)
SQL> COMMIT WRITE BATCH NOWAIT ; -- 4)
- "2)" 방법이 "1)" 방법에 비해 약 7배 정도 성능 향상 됨.
- 주의) 지금까지 사용해 오던 커밋(immediate wait)은 트랜잭션 데이터가 데이터베이스에 안전하게 저장됨을 보장함.
- 하지만 비동기식 커밋 옵션을 사용하면, 트랜잭션 커밋 직후 인스턴스에 문제가 생기거나 Redo 로그가 위치한 파일 시스템에 문제가 생겨 쓰기 작업을 진행할수 없게 되면 커밋이 정상적으로 완료되지 못할수도 있음
- 트랜잭션에 의해 생성되는 데이터 중요도에 따라 활용 여부를 결정해야 함.
- commit_write 파라미터를 이용해 시스템 또는 세션레벨에서 기본 설정 변경 가능.
1.4 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 방식이라고 함)
2 체크포인트 (CheckPoint)[편집]
2.1 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를 참조해서 복구
2.1.1 Database / Global Checkpoint[편집]
- Checkpoint가 발생하면 Buffer Cache에 있는 모든 저장 안 된 Drity Buffer들의 내용을 전부 데이터 파일로 저장,
- 저장된 SCN 중 가장 번호가 큰 SCN 번호(Checkpoint SCN)를 Control File과 Data File Header 부분에 기록
2.1.2 Thread Checkpoint / Logical Checkpoint[편집]
- 해당 Thread 내의 저장되 않은 모든 Dirty Buffer들을 Data File로 전부 내려 씀.
- 이 Checkpoint는 Log Switch가 발생하면 생김, RAC 환경일 경우 각 노드별로 다르게 발생
- Single Instance 일 경우 Database Checkpoint와 같은 역할
2.1.3 Data File Checkpoint[편집]
- 특정 데이터 파일에만 발생하는 Checkpoint
- 해당 Tablespace를 Offline 한다거나, Begin Backup 수행 시 발생
- 이 Checkpoint가 발생하면 해당 정보를 Control File과 Data File Header 부분에 기록
2.1.4 Mini Checkpoint[편집]
- Drop Table과 같이 특정한 DDL 발생 시 특정 블록에만 발생
2.1.5 Recovery Checkpoint[편집]
- 데이터 파일에 장애가 발생했을 때 백업된 데이터 파일 복원 후 Redo Change Vector를 적용시키게 됨,
- 그 후 Recovery된 블록을 데이터 파일에 저장해야 하는데 이때 발생하는 Checkpoint를 말함
- Oracle은 우선순위를 두어서 Checkpoint를 관리 함
- 우선 순위가 높을 경우 Fast Checkpoint,
- 우선 순위가 낮을 경우 Low Checkpoint로 분류
- 두 가지가 동시에 발생 할 경우 Fast Checkpoint부터 진행
notifications_active 패스트 체크포인트 란?
- Database Shutdown, Tablespace Begin Backup, Alter System Checkpoint 등의 명령어로 발생되는 Checkpoint는 Fast Checkpoint로 분류되어 DB Buffer Cache 내부에 잇는 Dirty Buffer들을 즉시 데이터 파일로 저장(=Full Checkpoint), Control File / Data File Header에 기록 함
- 우선 순위가 낮은 경우는 Checkpoint를 해야 할 Block의 목록을 즉시 데이터 파일로 내려 쓰지 않고 어딘가 기록해 둔 후 Background로 내려씀(=Incremental Checkpoint, 증분 체크포인트)