Control file parallel write

EXEM Knowledge Base

Jump to: navigation, 찾기

목차

[편집] Basic Info

control file parallel write 대기이벤트는 세션이 모든 컨트롤 파일(control file)에 대한 쓰기 I/O 요청이 완료되기를 대기할 때 발생한다. 오라클 서버 프로세스는 동시에(parallel) 쓰기 I/O 요청을 한다. 오라클 8.0.5부터, CKPT 프로세스는 3초마다 온라인 리두 로그 파일 안의 체크포인트 위치를 컨트롤 파일에 기록한다. 오라클은 이 정보를 데이터베이스 복구(recovery) 수행 시에 사용한다. 또한 NOLOGGING 또는 UNRECOVERABLE 옵션을 사용하여 DML을 수행할 경우, 오라클은 컨트롤 파일에 unrecoverable SCN을 기록한다. RMAN(Recovery Manager)은 백업과 복구 정보를 컨트롤 파일에 기록한다.

control file parallel write 대기이벤트에 대한 블로킹 세션은 존재하지 않는다. 해당 이벤트를 대기하는 세션은 컨트롤 파일에 쓰기 I/O 요청이 완료될 때까지 O/S 와 I/O 서브시스템의 수행을 기다리는 것이다. 컨트롤 파일에 정보를 기록하려는 세션은 CF enqueue를 획득해야 한다. 만일 control file parallel write 대기이벤트에 대한 대기현상이 광범위하게 발생한다면, 컨트롤 파일에 쓰기I/O 요청이 많거나, 컨트롤 파일에 정보를 기록하는 성능이 좋지 않다는 것이다.

오라클의 컨트롤 파일(control file)은 데이터베이스의 물리적인 구조 및 정보에 핵심적인 정보를 담고 있다. 오라클 Concept 매뉴얼에는 컨트롤 파일이 다음과 같은 정보를 담는다고 밝히고 있다.

The database name
The timestamp of database creation
The names and locations of associated datafiles and redo log files
Tablespace information
Datafile offline ranges
The log history
ARCHived log information
Backup set and backup piece information
Backup datafile and redo log information
Datafile copy information
The current log sequence number
Checkpoint information

V$CONTROLFILE_RECORD_SECTION 뷰를 조회하면 현재 컨트롤 파일내에 어떤 정보가 관리되고 있는지 확인할 수 있다.

SQL> select type, records_used from v$controlfile_record_section;

TYPE                           RECORDS_USED
------------------------------ ------------
DATABASE                                  1
CKPT PROGRESS                         0
REDO THREAD                             1
REDO LOG                                   3
DATAFILE                                   15
FILENAME                                   19
TABLESPACE                               12
TEMPORARY FILENAME                   1
RMAN CONFIGURATION                 0
LOG HISTORY                            292
OFFLINE RANGE                            0
ARCHIVED LOG                            0
BACKUP SET                                0
BACKUP PIECE                             0
BACKUP DATAFILE                        0
BACKUP REDOLOG                        0
DATAFILE COPY                            0
BACKUP CORRUPTION                   0
COPY CORRUPTION                       0
DELETED OBJECT                          0
PROXY COPY                                 0
BACKUP SPFILE                             0
DATABASE INCARNATION              2
FLASHBACK LOG                            0
RECOVERY DESTINATION                1
INSTANCE SPACE RESERVATION     1
REMOVABLE RECOVERY FILES          0
RMAN STATUS                                0
THREAD INSTANCE NAME MAPPING  8
MTTR                                             1
DATAFILE HISTORY                         0
STANDBY DATABASE MATRIX         10
GUARANTEED RESTORE POINT         0
RESTORE POINT                              0

컨트롤 파일의 갱신을 요청한 프로세스들은 갱신이 완료될 때까지 control file parallel write 이벤트를 대기하게 된다. 로그 스위치, 데이터파일 추가, 삭제등과 같은 오퍼레이션은 컨트롤 파일의 변경이 필요하다. 또한 대부분의 LOB 오퍼레이션에 대해서도 컨트롤 파일 변경이 수행된다.

포그라운드 프로세스와 백그라운드 프로세스들은 컨트롤 파일에 기록할 수 있다. 3초마다 CKPT 프로세스는 온라인 리두 로그 안의 체크포인트 위치를 컨트롤파일에 기록한다. 일반적인 환경에서, CKPT 프로세스가 control file parallel write 대기이벤트를 가장 오래 대기한다. ARCH 프로세스는 아카이브 로그와 관련된 정보를 컨트롤 파일에 기록하며, LGWR 프로세스는 로그 스위치가 발생할 때마다 컨트롤 파일을 변경한다. 아래의 쿼리를 이용하여 컨트롤 파일 트랜잭션을 수행하는 세션을 확인할 수 있다.

select /*+ ordered */
       a.sid,
       decode(a.type, 'BACKGROUND', 'BACKGROUND-' || substr
(a.program,instr(a.program,'(',1,1)), 'FOREGROUND') type,
       b.time_waited,
       round(b.time_waited/b.total_waits,4) average_wait,
       round((sysdate - a.logon_time)*24) hours_connected
from   v$session_event b, v$session a
where  a.sid   = b.sid
and    b.event = 'control file parallel write'
order by type, time_waited;

SID TYPE              TIME_WAITED AVERAGE_WAIT HOURS_CONNECTED
--- ----------------- ----------- ------------ ---------------
 10 BACKGROUND-(ARC0)         525        .3431             117
 11 BACKGROUND-(ARC1)         519        .3390             117
  7 BACKGROUND-(CKPT)       64147        .3431             117
  6 BACKGROUND-(LGWR)        1832        .3011             117
517 FOREGROUND                  2        .5120               1

만일 LGWR 프로세스의 대기시간이 길다면, 너무 많은 로그 스위치가 발생된다는 것을 의미하며, V$LOG 뷰를 조회하여 리두 로그 크기를 점검해야 한다. 데이터베이스의 트랜잭션 양에 비해 너무나 작을 수 있기 때문이다. 아래의 쿼리를 이용하여 얼마나 자주 로그 스위치가 발생되는지 확인할 수 있다.

select thread#,
       to_char(first_time,'DD-MON-YYYY') creation_date,
       to_char(first_time,'HH24:MI')     time,
       sequence#,
       first_change# lowest_SCN_in_log,
       next_change#  highest_SCN_in_log,
       recid         controlfile_record_id,
       stamp         controlfile_record_stamp
from   v$log_history
order by first_time;

만일 포그라운드 프로세스가 control file parallel write 대기이벤트의 대기시간이 길다면, 어플리케이션이 NOLOGGING LOB에 대한 변경작업을 수행하는지 점검해야 한다. 데이터파일이 NOLOGGING 오퍼레이션에 의해 변경되면, 컨트롤 파일의 unrecoverable SCN은 변경되어야 한다. 만일 대기시간이 길다면, 10359 이벤트를 설정하여 컨트롤 파일의 변경을 막는 것을 고려할 수 있다. 아래의 예제는 $ORACLE_HOME/rdbms/mesg/oarus.msg 로부터 발췌한 것이다.

10359, 00000, "turn off updates to control file for direct writes"
// *Cause:
// *Action:  Control files won't get updated for direct writes for LOBs
//           when NOCACHE NOLOGGING is set. The only bad impact that it
//           can have is that if you are using the recovery manager,
//           it may affect a warning that says that the user should
//           back everything up. Now the recovery manager won't know
//           to tell you that the files that were updated with
//           unrecoverable events should be backed up.

control file parallel write 대기는 흔히 control file sequential read 대기나 enq: CF - contention 대기와 함께 발생하는 경우가 많다. enq: CF - contention 대기는 여러 세션이 동시에 컨트롤 파일을 갱신하기 위해 CF 락을 획득하는 과정에서 발생한다. control file parallel write, control file sequential read, enq: CF - contention 대기는 모두 과다한 컨트롤 파일 갱신이나 I/O 시스템의 성능문제에 기인한다.

[편집] Parameter & Wait Time

[편집] Wait Parameters

control file parallel write 대기이벤트의 대기 파라미터는 다음과 같다.

  • P1 : 컨트롤 파일의 개수
  • P2 : 컨트롤 파일에 기록하려는 총 블록 수
  • P3 : I/O 요청 횟수

[편집] Wait Time

모든 I/O 요청을 완료하는데 실제로 소요된 시간

[편집] Check Point & Solution

[편집] 로그 파일 스위치가 자주 발생하는 경우

로그 파일의 크기가 너무 작은 경우 로그 파일 스위치가 자주 발생하게 된다. 로그 파일 스위치가 발생할 때마다 컨트롤 파일의 갱신이 필요하기 때문에 LGWR 프로세스가 control file parallel write 이벤트를 대기하는 시간이 늘어나게 된다.

[편집] 체크 포인트가 자주 발생하는 경우

데이터파일에 대해 Nologging 변경 작업을 수행하는 경우 unrecoverable SCN을 변경하기 위해 컨트롤 파일의 갱신이 필요하다. 이 경우 서버 프로세스가 control file parallel write 이벤트를 대기하게 된다. Nologging으로 생성한 LOB 데이터에 대한 변경이 발생하는 경우가 대표적인 경우이다.(unrecoverable SCN은 RMAN에 의해 Backup이 이루어질때 사용된다고 알려져 있다)

[편집] Nologging에 의한 데이터파일 변경이 잦은 경우

컨트롤 파일을 독립적인 디스크 공간에 위치시키고, RAW 디바이스나 Direct I/O를 사용하는 것이 좋다. 만일 컨트롤 파일의 개수가 지나치게 많은 경우에는 복구에 필요한 최소한의 컨트롤 파일만을 보관하는 것이 좋다. 컨트롤 파일을 갱신하는 작업이 과다하지 않은데도 특정 프로세스가 control file parallel write 대기를 많이 겪는다면 I/O 시스템의 성능을 의심해 볼 필요가 있다.

[편집] Event Tip

[편집] Analysis Case