Log file switch completion

EXEM Knowledge Base

Jump to: navigation, 찾기

목차

[편집] Basic Info

서버 프로세스가 리두 버퍼에 리두 레코드를 기록하려는 시점에 리두 로그 파일이 꽉차서 더 이상 쓰기를 할 수 없으면 프로세스는 LGWR에게 로그 파일 스위치를 수행할 것을 요청한다. 서버 프로세스는 LGWR에 의해 로그 파일 스위치가 끝날 때까지 log file switch completion 이벤트를 대기하게 된다. 하지만 로그 파일 스위치가 끝나는 시점에, 새로 사용할 리두 로그 파일에 대해 아직 종료되지 않은 작업이 있다면, 아래와 같이 추가적으로 이벤트를 대기해야 한다.

  1. 새로 사용할 리두 로그 파일에 대한 체크포인트 작업이 아직 끝나지 않았다면 프로세스는 DBWR에 의해 체크포인트가 끝나기를 기다려야 한다. 이 경우 프로세스는 log file switch (checkpoint incomplete) 이벤트를 대기하게 된다.
  2. 새로 사용할 리두 로그 파일에 대해 아카이브(Archive) 작업이 아직 끝나지 않았다면 프로세스는 ARCH 프로세스에 의해 아카이브 작업이 끝나기를 기다려야 한다. 이 경우 프로세스는 log file switch (archiving needed) 이벤트를 대기하게 된다. 이 이벤트는 아카이브 모드의 데이터베이스에서만 발생한다.
  3. 새로 사용할 리두 로그 파일에 대해 Private strands에 대한 플러시(flush) 작업이 아직 끝나지 않았다면 이 작업이 끝나기를 기다려야 한다. 이 경우 프로세스는 log file switch (private strand flush incomplete) 이벤트를 대기하게 된다. 이 이벤트는 오라클 10g R2에서 추가된 것이며, 앞에서 언급한 Private redo strands 기능을 사용할 경우에만 발생한다.

위의 세가지 대기현상은 리두 로그 파일이 순환적으로(Circular) 사용되는 상황에서, 아주 많은 리두 데이터가 생성되기 때문에 미처 이전 작업을 다 끝내기도 전에 다시 재사용할 경우에 발생하게 된다. 따라서 이들은 log file switch completion 대기현상과 항상 같이 나타난다. 정확하게 말하면, 서버 프로세스는 먼저 log file switch completion 이벤트를 대기하고 특수한 경우에 다시 log file switch (checkpoint incomplete)log file switch (archving needed), log file switch (private strand flush incomplete) 이벤트를 대기하게 된다.


이름이 비슷해서 관리자들에게 상당한 혼란을 주는 이 네 개의 대기현상의 발생 원인과 해결책은 모두 동일하다. 발생 원인은 트랜잭션이 생성하는 리두 데이터의 양에 비해 리두 로그 파일의 크기가 지나치게 작다는 것이다. 따라서 해결책은 리두 로그 파일의 크기를 충분히 키워주는 것이다. 더불어 Direct load operation이나 Nologging 옵션을 사용하여 리두 데이터의 양을 줄이는 것도 도움이 된다.

[편집] Parameter & Wait Time

[편집] Wait Parameters

log file switch completion 대기이벤트는 대기 파라미터를 사용하지 않는다.

[편집] Wait Time

1초

[편집] Check Point & Solution

[편집] Event Tip

[편집] Analysis Case

[편집] Merge문 수행 시 발생한 많은 REDO양에 의한 성능저하 사례

9:30분 경의 Active Session의 급증 및 대기 현상이 발생하였다. Active Session List를 확인해 보면, 특정 DML문의 수행으로 인하여 많은 양의 Redo가 발생하였다. 이는 해당 세션의 Undo 양을 통해 알 수 있다. 그림:7_4_1.jpg

Active Session의 추이가 Buffer Busy Waits, Redo Blocks Written, Redo Size, Redo Entries와 동일하며, Redo Size가 Redo Entries에 비해 크므로, 하나의 Redo Entry의 크기가 큼을 유추할 수 있다.

문제 세션이 수행중인 SQL문의 상세정보를 확인해 본다. 그림:7_4_2.jpg

총 6번 수행되었고, 1회 수행 시 평균 100초가 소요되었으며, 수행하는 동안 71960개의 Redo Entry를 생성하였다. Redo Entry의 갯수에 비해 Redo Size는 훨씬 크게 나타났을 것으로 예상된다.

문제 SQL문은 예를 들면, 다음과 같은 형태의 Merge문이다.

merge into scott.emp e
    using scott.emp_update u
       on ( e.empno = u.empno )
     when matched then
         update set
                e.ename    = u.ename,
                e.job      = u.job,
                e.mgr      = u.mgr,
                e.hiredate = u.hiredate,
                e.sal      = u.sal,
                e.comm     = u.comm,
                e.deptno   = u.deptno
     when not matched then
         insert ( empno,
                  ename,
                  job,
                  mgr,
                  hiredate,
                  sal,
                  comm,
                  deptno
                ) 
          values( u.empno,
                  u.ename,
                  u.job,
                  u.mgr,
                  u.hiredate,
                  u.sal,
                  u.comm,
                  u.deptno
          );

Merge문 수행 이후로, Log File Switch- Checkpoint incomplete, Buffer Busy Waits – id 220 이벤트가 대량 발생하였다.

그림:7_4_3.jpg

Log File Switch (Checkpoint incomplete)는 로그파일에 대한 체크포인트 프로세스가 완료되지 않아서, 로그파일 스위치를 수행할 수 없을 때 발생한다.

예를 들어 1M 로그파일 4개로 구성된 환경에서 1번 그룹의 1M의 로그파일에 기록을 완료하면 로그스위치가 발생하면서 2번 그룹의 1M 로그파일에 기록을 시작한다. 만일 4번 로그파일에 기록을 완료하고, 다시 1번 로그파일에 기록을 하려는 시점에 1번 로그파일에 대한 체크포인트 프로세스가 완료되지 않았을 경우 Log File Switch (Checkpoint incomplete)가 발생된다.

이 사례는 Merge문 수행으로 Redo Size가 증가하여, Redo Log File 크기가 이를 감당하지 못해서 해당 문제가 발생하였다. 많은 양의 데이터를 변경할 때, 업무시간에 수행해도 좋은지 판단이 필요하며, 위와 같은 성능저하가 발생할 수 있음을 염두에 두고 수행해야 한다.