2017.11.01
Control file parallel write
目次
基本情報
control file parallel write待機イベントは、セッションがすべてのコントロールファイル（control file）への書き込みI/O要求が完了するまで待機するときに発生します。Olacleのサーバー・プロセスは、同時に（parallel）書き込みI/O要求します。Olace8.0.5から、CKPTプロセスは、3秒ごとにオンラインREDOログ・ファイルの中のチェックポイントの位置を制御ファイルに記録します。Olacleは、この情報をデータベース回復（recovery）を実行する際に使用するのです。また、NOLOGGINGまたはUNRECOVERABLEオプションを使用してDMLを実行する場合、Oracleは制御ファイルにunrecoverable SCNを記録します。 RMAN（Recovery Manager）は、バックアップと復元の情報を制御ファイルに記録します。
control file parallel write待機イベントのブロックセッションは存在しません。そのイベントを待機するセッションは、コントロールファイルへの書き込みI/O要求が完了するまで、O/SとI/Oサブシステムの実行を待っています。コントロールファイルに情報を記録するセッションは、CF enqueueを獲得しなければなりません。もしcontrol file parallel write待機イベントの待機現象が広範囲に発生した場合、制御ファイルへの書き込みI/O要求が多かったり、制御ファイルに情報を記録する性能が低下します。
Oracleの制御ファイル（control file）は、データベースの物理的な構造と情報の重要な情報を含んでいます。OracleConceptマニュアルには、制御ファイルは、次のような情報を入れると明示しています。
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プロセスは、オンラインREDOログ・中のチェックポイントの位置を制御ファイルに記録します。一般的な環境では、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ビューを照会して、REDOログのサイズを確認しなければなりません。データベースのトランザクション量に比べてあまりにも小さいことがあるからです。以下のクエリを利用して、どのくらいの頻度、ログ・スイッチが発生していることを確認することができます。
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システムのパフォーマンスの問題に起因します。
パラメータと待機時間
待機パラメータ
control file parallel write待機イベントの待機パラメータは以下の通りです。
・P1：コントロールファイルの数 ・P2：制御ファイルに記録する総ブロック数 ・P3：I / O要求の数
待機時間
すべてのI/ O要求を完了するのに実際に要した時間
チェック・ポイントとソリューション
ログファイルのスイッチが頻繁に発生する場合
ログファイルのサイズが小さすぎる場合は、ログファイルのスイッチが頻繁に発生するようになります。ログファイルのスイッチが発生するたびに、コントロールファイルの更新が必要なため、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システムの性能を疑って見る必要があります。
