2.7 테스트를 통한 리두동작 방식 분석

트랜잭션에 의해 발생되는 리두가 리두 로그 파링에 저장되는 순서는 크게 2가지로 구분됨

  • 하나의 트랜잭션에서 DML을 수행한 후 COMMIT을 수행하는 동안 다른 트랜잭션에 의해 발생되는 리두가 없는 경우
  • 다른 트랜잭션에 의해 발생되는 리두가 있을 경우

_IN_MEMORY_UNDO 파라미터를 FALSE 와 TURE로 가각 설정하여 각 단계별 리두 로그 파일에 저장되는 내용에 대해 알아보도록함

테스트는 아래에 기술된 단계별로 리두 로그 덤프를 수행함

_IN_MEMORY_UNDO=FALSE 인 경우의 테스트
테스트 초기화

테스트 1단계

테스트 2단계

테스트 3단계

테스트 4단계

테스트 5단계

_IN_MEMORY_UNDO=FALSE 인 경우의 테스트 결과 분석

테스트 1단계 결과 분석

1.1session A1> insert into t2 values (4,'D','d');
관련

테스트 2단계 결과 분석

테스트 3단계 결과 분석

테스트 4단계 결과 분석

테스트 5단계 결과 분석

-- 테스트 초기화
drop table t2;
create table t2 (c1 number, c2 varchar2(10), c3 char(10));
insert into t2 values (1,'A','a');
insert into t2 values (2,'B','b');
commit;

alter system switch logfile;

-- 테스트 1단계
@check_redo_scn.sql

insert into t2 values (3,'C','c');
update t2 set c3='aa' where c1=1;
delete from t2 where c1=2;

alter system dump logfile 'c:\

-- 테스트 2단계
commit;
alter system dump logfile 'c:\

-- 테스트 3단계
select ora_rowscn from t2 where rownum=1;

insert into t2 values (4,'D','d');
update t2 set c3='cc' where c1=3;
insert into t2 values (5,'E','e');
delete from t2 where c1=3;

alter system dump logfile 'C:\

-- 테스트 4단계
commit;
alter system dump logfile 'C:\

-- 테스트 5단꼐
commit;
alter system dump logfile 'C:\

_IN_MEMORY_UNDO=TRUE인 경우의 테스트 결과 분석

IMU & Private redolog strands 개요

IMU & Private redolog strands의 동작방식 유추
IMU

  • 트랜잭션과 관련된 언두의 정보를 언두 세그먼트가 아닌, 메모리의 특정 공간을 사용하는 것임
  • 메모리는 한정된 공간이므로 짧은 트랜잭션에 대한 성능향상을 위해 고안됨
  • 기존방식에서는 1건을 insert하기 위해서도, 언두 세그먼트 헤더 블록을 할당, 언두블록할당이 필요하며, 이러한 작업을 위해 cache buffer chains latch를 획득해야함
    Private redolog strands
    리두레코드를 기존의 로그 버퍼(shared redo strands)에 저장하는 것이 아니라 개별적인(private)메모리 공간에 기록하는 것을 의미함

IMU & Private redolog strands을 위한 메모리 스트럭처와 래치

  • _IN_MEMORY_UNDO=TRUE로 설정할 경우 IMU를 위한 4개의 메모리 스트럭처가 shared pool내에 생성되며, IMU메모리 공간을 보호를 위해 30개의 In Memory undo latch가 생성됨
  • Private redolog strands 메모리 공간을 보호하기 위해 30개의 추가적인(기본적으로2개) redo allocation latch가 생성됨

SQL> select * from v$sgastat where name like '%KTI%';

POOL NAME BYTES



















--
shared pool KTI latch structure 2808
shared pool KTI freelists 44
shared pool KTI-UNDO 1853064
shared pool KTI pool states 28
shared pool KTI latches 432

SQL> select count(*) from v$latch_children where name='In memory undo latch';

COUNT(*)



--
27

SQL> select count(*) from v$latch_children where name='redo allocation';

COUNT(*)



--
29

오라클 8i까지는 shared pool latch를 이용하여 로그 버퍼의 메모리 할당을 관리함
오라클 9i부터는 shared redo strands 라는 개념을 통해 하나의 로그버퍼를 논리적으로 여러 개로 구분하여, 논리적인 단위마다 1개의 shared pool latch를 통해 관리하는 방식을 사용
이는 오라클이 로그버퍼의 할당에 대한 경합을 완화시키기위해 고안된 것이라고 할수 있음
오라클 10g에서는 _LOG_PARALLEISM_MAX 파라미터의 수치(기본설정 값 2) + 30개의 redo allocation 래치를 이용하여 2개의 shared redo strands메모리 공간과 30개의 private redo strands 메모리 공간을 관리하게됨
10gR1의 경우 shared pool내에서 KTI-UNDO 메모리 스트럭처만 추가되었고, 18개의 In memory undo latch와 20개의 redo allocation 래치가 생성됨
10gR2에서 추가적인 12개의 래치가 생성되었음

IMU를 위한 공간은 shred pool내에 생성됨
반면, private redolog strands를 위한 공간응 로그버퍼(LOG_BUFFER) 내에 생성됨 되며 _LOG_PIVATE_MUL에 지정된 비율만큼(5퍼센트)을 private redolog strands공간으로 사용

SQL> @param
1의 값을 입력하십시오: _log_private
구 5: AND ksppinm like '%&1%'
신 5: AND ksppinm like '%_log_private%'
_log_private_mul 5
_log_private_parallelism_mul 10

SQL> show parameter log_buffer
log_buffer integer 6094848

IMU flushes 동작의 이해

일정크기 이상의 언두와 리두를 발생시키는 트랜잭션의 경우, IMU와 private redolog strands의 내용을 각각 언두 세그먼트와 shared redo strands로 flush하게됨
또한 2.7절의 테스트를 통해 블록클린아웃이 발생하는 경우에도 flush가 발생함

case1 일정크기 이상의 언두와 리두가 발생하는 경우

-- 초기데이터 생성
SQL> create table my_objects as select * from dba_objects;
테이블이 생성되었습니다.

SQL> select count(*) from my_objects;
59344

SQL> @check_flush
NAME VALUE














IMU Flushes 6
IMU commits 2
IMU undo allocation size 17352
redo size 3170560
user commits 6