ch6. Redo log 관리하기.
[Oracle Admin]/oracle관리실무 2014. 10. 20. 17:26 |[녹음7]
ch6. Redo log 관리하기.
|
Redo (다시하기) |
Data가 변경될 경우 변경후의 내용을 적어둠. |
|
Undo (취소하기) (=rollback) |
Data가 변경될 경우 변경전의 내용을 적어둠. |
1. Redo Log의 생성원리.
** 아래 두가지 메커니즘에 의해 Redo log에 기록된다.
|
Write Log Ahead |
|
실제 데이터를 변경(기록)하기 전에, Redo Log에 먼저 기록한 후 데이터를 변경한다. |
|
Log force at commit |
|
사용자로부터 commit요청이 들어오면 관련된 모든 redo record들을 redo log file에 저장한 후 commit을 완료시킴. 즉, redo log file에 기록하지 않고는 commit을 완료하지 않는다. (즉, redo log file에 기록해야만 commit을 완료시킨다.) → 대량의 데이터 변경 후 commit이 한꺼번에 수행되면 악영향을 주는 경우가 발생하기 때문에, Delayed commit(지연된 commit) 이나, Group commit(commit을 아주 짧은 시간동안 모아서 한꺼번에 수행)이란 기술이 등장한다. group commit은 주로 PL/SQL 등에서 짧은 시간 동안 많은 데이터가 변경된 후 한꺼번에 commit 요청이 들어올 경우 많이 발생한다. 그리고 Redo Log를 다 기록한 후 DBWR이 데이터를 기록하는 동기식 커밋에서 성능 문제 때문에 비동기식 커밋 기술도 나온다.(10g R2부터)
|
|
* 데이터 변경시 redo log에 기록되는 원리 ★★★★★ | ||
|
(사진 goalker 참조)
1. 사용자가 data 변경을 요청하는 쿼리 수행. 2. server process가 원하는 block이 buffer cache에 있는지 확인한 후, 없을경우 해당 블록을 데이터 파일에서 찾아 복사한 후 db buffer cache(메모리)로 가져온다. 3. 다른 사용자가 바꿀 수 없도록 해당 block에 Lock 설정 (★page fix★ : file에서 DB cache에 저장한 후, 다른 사용자가 못바꾸게 하는 것) 4. server process가 PGA에서 Redo change vector 생성한 후, Redo Log buffer에서 필요한 용량을 계산한다. ** change vector란 : 변경된 데이터를 나중에 복구할 목적으로 redo log에 기록할 변경된 데이터에 대한 모든 정보의 세트
5. server process가 Redo copy latch를 획득한다.(PGA내의 change vector를 redo buffer로 복사하기위해 획득해야하는 latch.) 6. server process가 Redo allocation Latch를 확보한다.(redo buffer 내의 공간을 확보하고자 획득하는 latch) 7. Change vector들은 redo record format으로 row단위로 redo log buffer에 복사된다. (redo log buffer에 기록된 change vector : redo entry) 8. server process가 아래의 상황이되면 redo writing latch를 확보한 후, LGWR에게 redo log buffer에 있는 내용을 redo log file에 기록하라고 요청.
9. LGWR이 일부를 redo log file에 block단위(os block)로 기록한 후, 기록된 redo entries들은 redo log buffer에서 삭제(flush). - DBWR이 내려쓰는 block의 크기는 DB_BLOCK_SIZE로 결정되지만, LGWR이 내려쓰는 LOG buffer의 block크기는 os block size이며 os종류에 따라 다를 수 있다. - 현재 redo log block size 조회. 10. transaction이 일어났으므로, control file에는 commit SCN이 적힌다. 11. redo log file의 용량이 꽉차면, 다음페이지로 넘어가는 Log switch가 일어난다. 12. log switch가 일어나면 ckpt가 바로 dbwr에게 checkpoint 신호를 준다.(redo log file에서 제일 마지막번호)(control file에 checkpoint SCN이 적힘) 13. dbwr이 받은 checkpoint SCN까지 데이터를 내려쓴다.
** redo log file은 데이터를 바꾸는 것을 기록한다. 그러나 모든 변경사항이 전부 기록되는 것은 아니다. : Direct Load(SQL Loader, Insert /*+ APPEND */)나 table이나 index생성시 nologging옵션을 준다든지 하는 경우에 redo log에 기록되지 않는다. (nologging옵션으로 테이블 생성되었더라도, insert, update, delete같은 작업은 모두 redo log에 기록된다.) - redo buffer에는??? insert, update, delete,create(DDL),, 등 변경사항이 다 적힌다. ->select는 변경하는게 아니니까 적히지 않는다. 단, select할때 다른사람이 못바꾸게하는 "select for update"는 기록에 남는다.
|
|
* Latch란 ? |
|
: 은행의 번호표와 비슷한 의미로 한정된 메모리 자원을 여러 사용자가 사용할 때 서로 먼저 자원을 확보하기 위해 충돌이 일어나는 것을 막기 위해 사용할 수 있는 순서를 정리해주는 역할을 하는 장치. - 오라클에서도 메모리 자원 사용할 때 반드시 Latch를 먼저 확보해야만 한다. - 대부분의 메모리 자원(shared pool, database buffer cache)는 각각 적절한 Latch들을 가지고 있다. * Redo log buffer가 확보해야 하는 두가지 Latch. ① Redo copy latch : PGA내의 change vector를 redo buffer로 복사하려는 프로세스가 획득하기 위한 latch. - change vetor가 모두 redo log buffer에 기록될 때까지 계속 갖고 있어야 하기 때문에 여러개 존재한다. - redo copy latch의 수 : _log_simultaneous_copies 히든 파라미터로 조정 가능. (기본값 : cpu개수*2 ) - redo copy latch 현황 조회시, 보통 cpu가 1개일 경우, 기본적으로 2개의 redo copy latch가 조회된다. ② Redo Allocation Latch : redo buffer 내의 공간을 확보하고자 획득하는 latch. - 8i 까지는 redo allocation latch가 1개 밖에 없어서 데이터 변경이 많이 되는 서버일 경우, redo allocation latch를 확보하기 위해 많은 경합이 발생하기도 했다. - (9i부터) shared redo strand : redo log buffer를 여러 개의 공간으로 나누어서 각 공간별로 redo allocation latch를 할당해주는 기능으로, 여러 프로세스가 동시에 작업하게 하여 성능을 높이고, redo allocation latch를 획득하기 위해 발생했던 경합들을 감소시켰다. - (10g부터) _LOG_PARALLELISM_DYNAMIC 파라미터가 추가됨 : LOG_PARALLELISM파라미터가 _LOG_PARALLELISM(히든파라미터)로 변경되고, 이 값을 동적으로 관리하는 파라미터. (true로 설정 시 오라클이 해당 strand개수를 자동으로 제어할 수 있도록 설정할 수 있음.) (권장값 : CPU개수/8 ) - (10g부터) Private Redo strand : 각 서버프로세스가 shared pool에 자신만의 독립적인 private strand공간을 만들어서, 그곳에 change vector를 생성한 후 필요한 경우 LGWR이 Redo log file에 바로 기록한다. (Latch를 확보해서 Redo log buffer에 기록해야 하는 과정을 줄임 : zero copy redo) (기본값 : 사용안함) (_LOG_PRIVATE_PARALLELISM=TRUE :활성화시킴)
|
|
[ 참고 ] |
|
* strand란? : 여러 개로 분할된 영역을 의미하는 것. LOG_PARALLELISM 파라미터 값으로 설정. 기본값 1
*change vector란 ? : 변경된 데이터를 나중에 복구할 목적으로 Redo log에 기록할 변경된 데이터에 대한 모든 정보의 세트.
* change vector 내에 undo관련내용까지 함께 저장되어 있는 이유 : 사용자가 commit한 후 아직 checkpoint발생전에 db가 강제종료 되었을 때 해당 데이터를 roll forward하는 내용도 저장해야 하지만, 사용자가 rollback한 후 아직 rollback이 완료되지 않은 상태에서 db가 강제 종료 되었을 경우에도 rollback되지 못한 데이터를 전부 rollback해줘야 한다.
|
* Database buffer cache 상태
|
Current (=pinned) |
현재 사용 중 |
|
Active (=Dirty) |
commit 완료 / Data 저장 안됨. (일부라도 저장이 안된 경우) -> 지우고 덮어쓰면 안된다. |
|
Inactive (=Free) |
commit 완료 / Data 저장 완료. -> 지우고 덮어쓰는 것 가능. |
[녹음8]
2. Redo Log File 구성 및 관리하기.
(1) Redo Log buffer와 Redo Log file.
|
- log switch가 너무 자주일어나면 check point active상태가 많아지게된다. - redolog file의 크기가 작으면 log switch가 자주일어나 -> check point 가 자주일어나 -> database buffer cache에서 dirty buffer들을 자주내려써-> 내려쓰는동안 기다려야되니까 DML작업이 느려진다. - check point가 자주일어나지 않는다면 ->db cache에서 자주 내려쓰지 않기때문에 그안에 dirty buffer들이 많아진다. -> 사용자가 select했을때 빈블록을 db cache에 갖다놔야하는데 (LRU list의 보조를 뒤져서 free buffer를 찾아)free buffer가 없어.-> dirty buffer를 free buffer로 바꿀려면 dbw0에게 내려쓰라고 신호를날려서 내려쓰도록해야한다.--> 이것도 select작업이 느려진다. - 변경량이 엄청많으면 redo log크기를 크게 해줘야하고, select만 하는 server같은경우는 redo log크기가 작아도된다. - 한시간에2-3회정도 log switch가 일어나는게 적당하다!!
|
* Redo log 다중화 : redo log file이 고장나면 문제가 생기므로, 똑같은 멤버들을 최소한 두개이상 묶어서 한 그룹으로 만들기를 권장한다.
-> disk 1
-> disk 2
|
|
최소 갯수 |
권장 갯수 |
|
Group |
2 |
3 |
|
member |
1 |
2 |
- 하나의 디스크에 그룹이 통째로 들어가 있으면 안된다.
|
[참고] |
|
* STALE상태 : 해당 로그 파일이 문제가 있다는 것을 의미. - 만약 병렬쓰기 도중에 redo log file이 삭제되었다든지 block에 문제가 생겼다든지하는 경우에 LGWR은 각 오픈로그 멤버의 상태를 조사해 어떤 파일이 에러가 발생되는지 알아내고, 장애난 멤버는 control file안에서 STALE이라는 상태로 기록된다. 그리고 LGWR은 백그라운드 trace file에 ORA-00346에러를 기록한다. - 만약 LGWR이 하나의 로그파일에서 4개 이상의 에러를 만나면 로그 파일을 닫고 더 이상 그 파일에 내용을 기록하지 않는데, 만약 LGWR이 어떤 로그파일에도 내용을 기록할 수 없다면 ORA-00340 에러를 발생시키고 shutdown abort로 강제종료되고 startup되지 않음.
* "checkpoint not completed" 메시지 (alert log file) : redo log file의 크기나 그룹의 개수가 작다는 의미이므로 멤버크기를 크게 만들거나 그룹을 더 만들어 줘야 한다. - 왜냐하면 redo log file의 크기가 작으면 log switch가 너무 빈번하게 일어나게 되고, 이 경우 DBWR이 이전에 발생한 checkpoint내용을 data file에 다 기록을 못한 상태에서 다시 log switch가 발생하여 checkpoint신호가 들어올 경우에 주로 발생한다.
* LSN(Log Sequence Number) : 페이지 번호
|
[녹음8]
(2) Redo Log File 관리하기.(11g기준/이전버전도동일함)
|
1. 신규 Group 생성. |
|
-- 멤버 하나일 때 > alter database add logfile group 4 '/app/oracle/oradata/testdb/redo04_a.log' size 5M;
|
|
-- 멤버 둘 이상일 때 > alter database add logfile group 3 ('/$HOME/oradata/u01/log3a.rdo', '$HOME/oradata/u02/log3n.rdo') size 1M; --멤버 각각에게 1M씩 준다. 같은 그룹 안에 잇는 멤버의 사이즈는 동일해야 한다. |
|
2. Member추가 |
|
> alter database add logfile member '/app/oracle/oradata/testdb/redo04_b.log' to group 4; -- 어차피 기존 멤버들과 같을 테니까, 사이즈 적어줄 필요 없다. |
|
** 삭제시 유의점 ** ★ 1) 삭제는 Inactive상태일 때만 가능하다 2) control file안의 정보만 지워지고, 실제파일은 지워지지 않는다. 3) 실제 파일을 지우고 싶다면, control 파일의 정보 먼저 지우고나서, 이후에 실제파일을 지워야 한다.(순서주의) 4) 그룹안에 마지막 한멤버만 남았다면, 지워지지 않는다. 마지막 멤버를 지우고 싶으면 그룹을 지워야 한다. 5) 만약 두 그룹이 있는 상태에서 한그룹을 지우려고 하면 에러가 난다. (그룹은 최소 2그룹 이상이어야 하므로)
|
|
3. Member 삭제하기. |
|
> alter database drop logfile member '/app/oracle/oradata/testdb/redo04_b.log'; |
|
4. Group 삭제하기. |
|
> alter database drop logfile group 4; |
|
5. 강제로 Log switch 발생시키기 |
|
> alter system switch logfile; -- Unused -> current 로 제일 우선 바뀐다. -- current -> active -> inactive 이 순서로 랜덤하게 계속 바뀐다. -- current상태로 바뀔 때만 sequence 번호가 증가한다.
|
|
6. 강제로 checkpoint 발생시키기 (자동저장 말고, 저장버튼을 즉시 누르는 것과 같은 효과) |
|
> alter system checkpoint; -- Active -> Inactive |
[실습1. Redo log file 관리하기]
1. 준비과정 : vi창으로 log.sql을 생성해서 현재logfile 상태를 확인할 수 있는, <logfile의 그룹번호와 멤버번호, log의 byte용량, log의 sequence번호, log의 상태, log의 아카이브상태>를 바로 조회하도록 저장해놓는다.
2. 신규 그룹, 멤버 추가.
3. 강제로 log switch와, checkpoint를 일어나게 해보고 상태를 확인해보면,
- log switch를 일으켰을 때, current 상태가 -> active상태로 바뀌었고, unused상태가 -> current 상태로 바뀌었다.
- checkpoint를 일으켰을 때, active상태가 -> inactive상태로 바뀌었다.
4. 기존멤버와 그룹을 삭제하기 위해서 logswitch와 checkpoint를 다시 일으켜 삭제하고자 하는 멤버를 Inactive상태로 바꿔준다.
5. 그룹 4의 멤버하나를 삭제하면, 실제파일은 삭제되지 않아있으므로 rm -fr 명령어로 삭제해준다.
6. 그룹4의 남아있는 멤버 하나를 삭제하려고 했는데, 한 그룹에 멤버가 최소 하나는 남아있어야하므로 삭제가 되지 않는다.
즉, 한 그룹에 멤버가 하나만 남은경우 삭제할 때는-> 그룹 자체를 삭제한다.
Alter system switch logfile 에 대해서!!!!!!!
SQL> @log
GROUP# MEMBER MB STATUS SEQ ARC
---------- --------------------------------------------- ---- -------- ---- ---
1 /app/oracle/disk1/redo01_a.log 5 UNUSED 0 YES
1 /app/oracle/disk1/redo02_a.log 5 UNUSED 0 YES
1 /app/oracle/disk1/redo03_a.log 5 UNUSED 0 YES
2 /app/oracle/disk2/redo01_b.log 5 UNUSED 0 YES
2 /app/oracle/disk2/redo02_b.log 5 UNUSED 0 YES
2 /app/oracle/disk2/redo03_b.log 5 UNUSED 0 YES
4 /app/oracle/disk1/redo04.log 5 CURRENT 34 NO
5 /app/oracle/disk2/redo05.log 5 UNUSED 0 YES
8 rows selected.
SQL> alter system switch logfile;
System altered.
SQL> @log
GROUP# MEMBER MB STATUS SEQ ARC
---------- --------------------------------------------- ---- -------- ---- ---
1 /app/oracle/disk1/redo01_a.log 5 CURRENT 35 NO
1 /app/oracle/disk1/redo02_a.log 5 CURRENT 35 NO
1 /app/oracle/disk1/redo03_a.log 5 CURRENT 35 NO
2 /app/oracle/disk2/redo01_b.log 5 UNUSED 0 YES
2 /app/oracle/disk2/redo02_b.log 5 UNUSED 0 YES
2 /app/oracle/disk2/redo03_b.log 5 UNUSED 0 YES
4 /app/oracle/disk1/redo04.log 5 ACTIVE 34 NO
5 /app/oracle/disk2/redo05.log 5 UNUSED 0 YES
8 rows selected.
1그룹의 unused상태 세개가 current로 바뀌고,
current상태는 active상태로 바뀜.
SQL> alter system switch logfile; 한번더함.
System altered.
SQL> @log
GROUP# MEMBER MB STATUS SEQ ARC
---------- --------------------------------------------- ---- -------- ---- ---
1 /app/oracle/disk1/redo01_a.log 5 ACTIVE 35 NO
1 /app/oracle/disk1/redo02_a.log 5 ACTIVE 35 NO
1 /app/oracle/disk1/redo03_a.log 5 ACTIVE 35 NO
2 /app/oracle/disk2/redo01_b.log 5 CURRENT 36 NO
2 /app/oracle/disk2/redo02_b.log 5 CURRENT 36 NO
2 /app/oracle/disk2/redo03_b.log 5 CURRENT 36 NO
4 /app/oracle/disk1/redo04.log 5 ACTIVE 34 NO
5 /app/oracle/disk2/redo05.log 5 UNUSED 0 YES
8 rows selected.
current로 바뀌었던 1그룹의 current상태가 active상태로 바뀌고,
2그룹의 unused상태 3개가 current상태로 바뀜.
SQL> alter system switch logfile; 한번더하면
System altered.
SQL> @log
GROUP# MEMBER MB STATUS SEQ ARC
---------- --------------------------------------------- ---- -------- ---- ---
1 /app/oracle/disk1/redo01_a.log 5 ACTIVE 35 NO
1 /app/oracle/disk1/redo02_a.log 5 ACTIVE 35 NO
1 /app/oracle/disk1/redo03_a.log 5 ACTIVE 35 NO
2 /app/oracle/disk2/redo01_b.log 5 ACTIVE 36 NO
2 /app/oracle/disk2/redo02_b.log 5 ACTIVE 36 NO
2 /app/oracle/disk2/redo03_b.log 5 ACTIVE 36 NO
4 /app/oracle/disk1/redo04.log 5 ACTIVE 34 NO
5 /app/oracle/disk2/redo05.log 5 CURRENT 37 NO
8 rows selected.
current로 바뀌었던 2그룹의 current상태가 active상태로 바뀌고,
unused상태였던 마지막하나가 current로 바뀜.
SQL> alter system switch logfile;
System altered.
SQL> @log
GROUP# MEMBER MB STATUS SEQ ARC
---------- --------------------------------------------- ---- -------- ---- ---
1 /app/oracle/disk1/redo01_a.log 5 INACTIVE 35 NO
1 /app/oracle/disk1/redo02_a.log 5 INACTIVE 35 NO
1 /app/oracle/disk1/redo03_a.log 5 INACTIVE 35 NO
2 /app/oracle/disk2/redo01_b.log 5 ACTIVE 36 NO
2 /app/oracle/disk2/redo02_b.log 5 ACTIVE 36 NO
2 /app/oracle/disk2/redo03_b.log 5 ACTIVE 36 NO
4 /app/oracle/disk1/redo04.log 5 CURRENT 38 NO
5 /app/oracle/disk2/redo05.log 5 ACTIVE 37 NO
8 rows selected.
current로 바뀌었던 마지막 하나가 active로 바뀌고,
active상태였던 1그룹 세개가 Inactive상태로 바뀜.
[redo log 문제] : 10분안에 풀어야 함 ★
|
Q. spfile을 사용하여 아래와 같이 구성하세요. cd /data /data /disk1/control01.ctl, redo01_a.log, redo02_a.log, redo03_a.log |
[ Hint ]
: 각각 group 생성시 disk1에들어가는 redoxx_a.log를 만들어 주고,
이후에 멤버추가로 redoxx_b.log를 각각의 group에 생성해준다.
[ Solution ]
1. 우선 pfile을 사용하는지, spfile을 사용하는지 조회 : show parameter pfile;
-> 현재 control 파일 경로를 조회★ : select name from v$controlfile; -- shutdown하기전에 미리 조회.
-> spfile의 내용 변경 : alter system set control_files='' scope=spfile;
2. /data파일을 찾아보니 디렉토리가 없으므로 data디렉토리를 생성해준다.
--굳이 root계정에서 만들지 않고, oracle계정에서 만들어도 된다. (root계정에서 생성시 oracle에게 /data디렉토리에 대한 권한을 줘야한다.)
3. /data로 가서 disk1~5 디렉토리를 생성한후, 파일을 복사해준다.
(★이 때 카피하려는 원본파일을 꼭 control파일을 조회했을 때 나온 가장 최근의 control파일의 경로를 적어줘야한다.)
-> 정상적으로 startup시킨 후, 현재 control파일을 다시 조회해서 확인한다.
4. 그룹 1,2,3을 제거하기 위해서, 그룹 4,5를 생성한다.
5. 제거하고자 하는 멤버들의 상태를 Inactive상태로 만들어주기 위해서, db를 open한 후 switch log -> checkpoint를 일으켜줍니다.
6. group 1,2,3을 제거한후, 생성하고자하는 group1,2와 멤버를 다시 생성해준다.
7. 해당그룹안에 만들 멤버를 더 추가한다.
8. 다시 제거해야하는 그룹 4,5가 inactive상태이므로 바로 drop시킨다. (완료)
3. 심화학습. SCN과 Checkpoint ★★★
(1) SCN(system commit number) : commit이 발생할 때마다 모든 Transaction(TX)에 SMON이 고유번호 SCN(system commit number)을 준다. (순서대로지정된다.)★
- Instance recovery때나 사용자가 recover 명령을 실행할 때 oracle은 이 SCN정보를 사용하여 데이터베이스에 문제가 있는지 없는지를 판별하고 복구한다.
-DML 문장단위로 할당되는 것이아니라 트랜잭션 단위로 할당된다.
|
ex. insert A update A->B delete B commit : 100번으로 할당됨. :commit을 친 순간 100번으로 SCN이 할당되었다면, 위에 DML문장들도 전부 100번으로 할당된다. (트랜잭션 단위로 할당되므로) |
- SCN base(4bytes) + SCN Wrap(2bytes) : SCN base 값이 전부 다 사용되게 되면 SCN wrap값이 하나씩 증가되어 사용되며, 만약 SCN이 모두 사용되게되면 다시 0으로 reset된 후 새로운 incarnation('시즌'이라고 생각하면 좋다.)으로 할당되어 다시 시작된다.
- Sequence에서 발생시키는 것이 아니라, steve adams가 개발한 'kcmgas'라는 function으로 구현된다.
|
SCN이 기록되는 곳 (system commit number) |
|
1. control file header : checkpoint발생시/ resetlogs발생시 / incomplete recovery수행시 2. data blocks(cache layer) : block cleanout시 마지막 SCN을 각 block에 기록한다. 3. DAta blocks (ITL entries) : data block의 transaction layer안에 있는 ITL(Interested transaction list) entries에 commit된 scn정보를 기록.(delayed block cleanout.) 4. 모든 data file headers : 마지막 checkpoint발생시 / begin backup수행시 / 복구가 되었다면 사용된 마지막 SCN 5. redo records/Log Buffer : commit이 수행되면 commit record에 SCN을 포함하여 저장. 6. 그외 rollback segment(undo segment)와 tablespace headers |
|
commit 관련 파라미터 (11g R2버전) : show parameter commit; | |
|
[10g R2기준] - commit_point_strength : 분산 데이터 베이스 환경에서 2-Phase Commit에서 사용. - max_commit_propagation_delay : 전송시간 제어(10g부터는 이 파라미터의 값은 기본값이 0으로 설정되어 무조건 commit하자마자 전송하도록 설정되어 있다.)(broadcast on commit(BOC)방식) - commit_write : 사용자가 commit을 하게되면 LGWR이 해당 트랜잭션을 redo log file에 기록할때, 아래 4가지 방식 중 어떤 것을 사용할지 결정하는 파라미터.
|
(2) System change number : SCN의 또다른 이름으로, data file, redo log file, control file간의 동기화 정보를 맞추기 위해 사용됨.
- 구성 : SCN_Base(4bytes) + SCN_Wrap(2bytes) + SCN_Sequence(1byte)
- sequence는 동일한 SCN block을 여러개의 server process가 동시에 변경할 경우에 구분하기 위해 사용됨.
|
SCN이 기록되는 곳. (system change number) 주의!! |
|
1.Data block header 2. Redo records 3. Segment Header |
|
[참고] |
|
- Fast commit : commit을 하면 DB buffer cache에서 데이터를 내려쓰지 않고, redo log를 내려쓰는 것이 시간이 단축된다. - block cleanout : commit이 수행될 때 data block에 걸려있던 lock이 해제되는 과정. - delayed block cleanout / commit cleanout : 변경된 블록이 많을 경우, 해당 블록에 걸려있던 lock정보들은 commit후 해당블록을 처음 액세스 하는 시점에 해제를 하는 기법. |
(3) Checkpoint
: commit된 데이터를 어디까지 저장했는지 확인하기 위해 만든개념.(DB buffer cache의 변경된 Dirty buffer들을 data file로 저장하는 것)
|
Checkpoint 종류 | |
|
Database / Global Checkpoint |
DB buffer cache내에 있는 모든 저장안된 dirty buffer들의 내용을 전부 데이터 파일로 저장한다. 저장된 SCN중 가장 번호가 큰 SCN번호(checkpoint SCN)을 control file과 data file header부분에 기록한다. |
|
Thread Checkpoint / Logical Checkpoint |
Log switch가 발생하게되면, 해당 thread 내의 저장되지 않은 모든 dirty buffer들을 data file로 전부 내려쓴다. |
|
Data file Checkpoint |
해당 tablespace를 offline한다거나, begin backup수행시 발생하며, 특정 데이터 파일에만 발생하며, 발생시 해당 정보를 control file과 data file header 부분에 기록한다. |
|
Mini Checkpoint |
drop table과 같이 특정한 DDL발생시 특정 블록에만 발생한다. |
|
Recover Checkpoint |
데이터 파일에 장애가 발생했을 때 백업된 데이터파일 복원 후 redo change vector를 적용시키게 되는데, 그 후 recovery된 블록을 데이터 파일에 저장하고, 이 때 발생하는 checkpoint가 recovery checkpoint이다. |
- oracle은 checkpoint에 우선순위를 두어 우선순위가 높을경우 fast checkpoint로 분류하고, 우선순위가 낮을경우 Low checkpoint로 분류하여 진행한다.
ex)
① fast checkpoint(Full checkpoint) : database shutdown, tablespace begin backup, alter system checkpoint 등의 명령어로 발생되는 checkpoint로, db buffer cache 내부에 있는 모든 저장안된 dirty buffer들을 즉시 데이터파일로 저장. → control file과 data file header에 해당 checkpoint정보를 기록한다.
② Low checkpoint(Incremental Checkpoint, 증분 체크포인트) : checkpoint를 해야할 block의 목록을 즉시 데이터파일로 내려쓰지 않고 어딘가에 기록해 둔 후 background로 내려쓴다.
- oracle 7버전까지 : database bufer cache내에서 내려써야할 dirty buffer들의 목록을 LRUW list(dirty list)로 관리를 했다.
→ 8버전 이후부터는 : checkpoint queue로 대체되는데, queue안에 저장되는 dirty buffer의 목록의 길이를 적절하게 관리하는 것이 가장 중요하다. 즉, 저장을 자주 하지 않으면 성능은 좋아질 수 있지만, checkpoint queue길이가 길어지므로 복구하는 시간이 길어지는 단점이 있고, 저장을 자주하면(checkpoint queue길이가 짧게 되면) 성능이 나빠질 수 있다. → 그래서 DB_BLOCK_MAX_DIRTY_TARET 파라미터를 사용하여 Incremental checkpoint가 발생하는 간격을 조정할 수 있도록 하며, → 8i버전부터는 FAST_START_MTTR_TARGET파라미터를 제공한다. 위 두 파라미터 둘 다 Incremental checkpoint를 하게 되면 checkpoint정보를 control file에만 기록하며 data file에는 기록하지 않는다.
|
[참고] |
|
Queue : 먼저 들어간 항목이 먼저 나오는 것. (FIFO) (뱀처럼 생각!!) Stack : 먼저 들어간 항목이 나중에 나오는 것. (FILO) (쌓는다고 생각!!) |
'[Oracle Admin] > oracle관리실무' 카테고리의 다른 글
| spfile ↔ pfile 변경. (0) | 2014.10.30 |
|---|---|
| ch8. oracle저장구조 (미완) (0) | 2014.10.23 |
| ch7. tablespace와 data file 관리하기. ★★★ (0) | 2014.10.21 |
| ch5. Control File 관리하기. (0) | 2014.10.20 |
| ch4. oracle 시작하기와 종료하기 (0) | 2014.10.20 |
| ch3. Oracle Background Processes (0) | 2014.10.20 |
| ch2. SQL문장의 실행원리 (0) | 2014.10.19 |
| ch1.Oracle Architecture (0) | 2014.10.17 |
Posted by JJ*