테스트 방법
cubrid.conf 파라미터 추가
- vacuum_log_block_pages=4, er_log_vacuum=64 해당 파라미터를 먼저 추가하고, 아래 명령어를 통해 테스트
log header
- 아래 명령어를 실행했을 때 나오는 Current_append (현재 추가된 LOG PAGE의 위치) 확인
csql> show log header;
server.err
- $CUBRID/log/server/server.err → Update keep_from_log_pageid를 통해 현재 VACUUM이 수행 되어야 할 LOG PAGE 위치 확인
statdump 명령어
- statdump 명령어(-c 옵션 추가해서 누적값으로 확인)로 VACCUM을 진행해야 할 log data page의 수와 진행한 log data page의 수 확인
- Num_vacuum_log_pages_vacuumed: VACUUM이 수행된 LOG PAGE의 수
- Num_vacuum_log_pages_to_vacuum: VACUUM이 수행될 LOG PAGE의 수
DELETE를 수행할 때 VACUUM
1. delete 구문 수행 전
- VACUUM이 수행된 log page의 수와 VACUUM이 수행될 log page의 수는 0
- 현재 추가된 LOG PAGE의 위치는 1421024
- VACUUM이 수행 되어야 할 LOG PAGE 위치는 1420978
- VACUUM을 수행해야 하는 LOG PAGE가 없기 때문에, 현재 이 두 값의 차이는 크지 않음
2. delete 구문 수행 (commit 전)
- autocommit off 상태에서 진행
- 백만건의 레코드를 delete하는 sql 구문 수행
csql> ;au off
csql> delete t1;
- VACUUM이 수행될 LOG PAGE의 수가 증가하는 것을 확인
- vacuum worker에 의해 VACUUM이 수행될 LOG PAGE 페이지를 지속적으로 수집하는 것을 확인
- 트랜잭션 commit 전 이므로, 수집된 LOG PAGE는 활성 로그에 해당하여 아직 VACUUM이 수행되지 않은 상태
- 현재의 추가된 LOG PAGE의 위치는 1441577
- VACUUM이 수행 되어야 할 LOG PAGE 위치는 1421009
- 현재 VACUUM이 수행되지 않았기 때문에, 이 두 값의 차이는 큼
3. commit 후
- 트랜잭션 commit
csql> commit;
- VACUUM이 수행된 log page의 수가 증가하면서 VACUUM이 수행되고 있는 것을 확인
- VACUUM이 수행된 log page의 수와 VACUUM이 수행될 log page의 수가 같아지면, VACUUM 작업이 모두 완료된 것
- server.err를 확인해보면 VACUUM이 수행되면서 VACUUM이 수행 되어야 할 LOG PAGE 위치가 지속적으로 갱신된 것을 확인할 수 있음
- 현재의 추가된 LOG PAGE의 위치는 1450632
- VACUUM이 수행 되어야 할 LOG PAGE 위치는 1450583
- VACUUM이 모두 수행되었기 때문에, 현재 이 두 값의 차이는 크지 않음
'DBMS > CUBRID' 카테고리의 다른 글
[CUBRID] 다른 서버로 DB 복구 (0) | 2024.08.26 |
---|---|
[CUBRID] 백업과 복구의 이해 (0) | 2024.08.26 |
[CUBRID] 2PL, MVCC, VACUUM (0) | 2024.08.25 |
[CUBRID] Lock 관련 파라미터 (0) | 2024.08.25 |
[CUBRID] Lock 발생시킨 후 잠금 상태 확인 (0) | 2024.08.25 |