
control file parallel write - 日本エクセム株式会社 Oracle待機イベント情報
目次[非表示]
- 1.基本情報
- 2.待機パラメータと待機時間
- 3.チェックポイントとソリューション
基本情報
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マニュアルには、制御ファイルは、次のような情報を入れると明示しています。
V$ CONTROLFILE_RECORD_SECTIONビューを照会すると、現在の制御ファイル内にどのような情報が管理されているかどうかを確認することができます。
コントロールファイルの更新を要求されたプロセスは、更新が完了するまでcontrol file parallel writeイベントを待機することになります。ログスイッチ、データファイルの追加、削除などのようなオペレーションは、制御ファイルの変更が必要です。また、ほとんどのLOBオペレーションにもコントロールファイルの変更が行われます。
フォアグラウンドプロセスとバックグラウンドプロセスは、制御ファイルに記録することができます。 3秒ごとにCKPTプロセスは、オンラインREDOログ・中のチェックポイントの位置を制御ファイルに記録します。一般的な環境では、CKPTプロセスがcontrol file parallel write待機イベントを最も長く待機します。 ARCHプロセスは、アーカイブ・ログに関する情報をコントロールファイルに記録して、LGWRプロセスは、ログ・スイッチが発生するたびに、コントロールファイルを変更します。以下のクエリを使用して、制御ファイルのトランザクションを実行するセッションを確認することができます。
もしLGWRプロセスの待機時間が長い場合は、あまりにも多くのログ・スイッチが発生していることを意味し、V$ LOGビューを照会して、REDOログのサイズを確認しなければなりません。データベースのトランザクション量に比べてあまりにも小さいことがあるからです。以下のクエリを利用して、どのくらいの頻度、ログ・スイッチが発生していることを確認することができます。
もしフォアグラウンドプロセスがcontrol file parallel write待機イベントの待機時間が長い場合は、アプリケーションがNOLOGGING LOBへの変更操作を行うかどうかを確認しなければなりません。データファイルがNOLOGGING操作によって変更されると、制御ファイルのunrecoverable SCNを変更する必要があります。もし待機時間が長い場合は、10359イベントを設定して、制御ファイルの変更を防ぐことを考慮することができます。以下の例は、$ ORACLE_HOME/ rdbms/ mesg/ oarus.msgから抜粋したものです。
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待機イベントの待機パラメータは以下の通りです。
待機時間
すべての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システムの性能を疑って見る必要があります。