これは、スイッチhttps://blogs.oracle.com/database4cn/log-file-switch-checkpoint-incomplete-%e5%ae%b9%e6%98%93%e8%a2%ab%e8%af%af%e8 ％AF％8A％E7％9A％84event
以下AWRを初めて目、12分のサンプリング、DB時間105分。
DB名DB同上インスタンス研NUM起動時間リリースRAC R11204 R11204 2114874159 1 10月23日- 17 10:10 11.2.0.4.0 NO ホスト名プラットフォームのCPUコアソケットメモリー（GB） nascds18のLinux x86の64ビットの2 2 1 11.64 スナップIDスナップ時間セッションカーソル/セッションは、 スナップを開始：3 10月23日10時55分46秒- 17 37 2.5 終了スナップ：4 10月23日午前11時08分27秒- 17 53 2.3 経過：12.67（分） DB時間：105.90（分）
ビジー待機およびログファイルのスイッチバッファトップイベントの発見は（チェックポイントが不完全）DB時間のほぼすべて取り
合計によってトップ10フォアグラウンドイベント時間待っ イベントウェイツ合計時間（秒）の平均（ミリ秒）％DB時間待ちクラスを待って待って 11 3310.6 300960 52.1同時実行ビジー待機をバッファ 10 3034.8 303479 47.8設定（不完全なチェックポイント）ログファイルのスイッチ DB CPU 5.5。 1つの ログファイルシンク28 2.3 82 0.0コミット ・ログ・バッファ空間24 0.8 32 0.0構成
ASHによって困難なファイルのスイッチをビジー待機は、ログファイルのスイッチ（チェックポイント不完全）閉塞されているバッファ、およびログを見つけるために（チェックポイントが不完全な）ブロックされていLGWRは、制御ファイルのシーケンシャルを読みます。
2017年10月23日11：05：31.563 1 37のPerl @ nascds18（TNS V1-V3）は、バッファビジー待機が待機1 150 2017年10月23日11：05：31.563 1 150 SQLPLUS @ nascds18（TNS V1-V3）はビジーバッファ1 141 WAITING待ち 2017年10月23日11：05：31.563 1 141 OMS 1 130待ちファイルスイッチ（不完全なチェックポイント）ログ 2017年10月23日11：05：nascds18（LGWR）制御ファイルのシーケンシャル@ 31.563 1 130 Oracleが待ち読み取りますNOホルダー
その後、AWRのiostatので振り返る、LGWRはすぐ1.5Gまで12分で読み、読むの多数を発見し、制御ファイルを読んでいます。
関数の要約によるIOSTAT 関数名読み込み：データ LGWR 1.5G その他210M DBWR 0M バッファ・キャッシュは10M読み込み ダイレクト0M書き込み 1.7G：TOTALを iostatのファイルタイプによって要約 ファイルタイプ名は読み込み：データ 制御ファイル1.5G ログファイル185M アーカイブログ0M データファイル10Mの 温度をファイル0M TOTAL：1.7G
LGWRのASHの組み合わせは、究極の所有者であり、従って、それが外れてしまった場合のLGWR待機制御ファイルを読み込み、シーケンシャルという事実は、我々はすぐに、キー容疑者としてLGWRかもしれません。
今回は（不完全なチェックポイント）を停止し、ログファイルのスイッチであるかについて考えることを望むかもしれませんか？
ログファイルのスイッチ（不完全なチェックポイント）のREDOグループハンドオーバのセットは、グループはログがダーティブロックに対応するログ・バッファ・キャッシュのグループ番号ではなく、書き込みを有していること、アクティブであることを見つけたときにダウンやり直す必要性を指しデータファイルには、それは、REDOグループの次のセットを多重化することができる、終了した汚いブロックを待つ必要があります。
次に、どのようなプロセスは、データファイルに書き込まれる汚れたブロックを担当してもう一度考えてみて？答えは、したがって、我々はのDBWnに焦点を当てる必要があります、のDBWnです。OSWatcher状態DBW0はD、psコマンドについての男を見つけることは難しいことではありません分析：Dは、I / OにDBW0ハングを言うことである無停電スリープ（通常はIO）を、参照し、これが問題の根本的な原因です。
では、なぜこれほど多くのLGWRが行う制御ファイルシーケンシャルリードがありますか？答えは、LGWR原因のDBWn問題は常に制御ファイルシーケンシャルリードの多くにREDO状態（ハンドオーバーの成功のために見て）リードの制御ファイルをポーリングしています
この現象を実証するために以下の実験：
12.1.0.2のテスト
セッション1：テーブルを作成し、更新することは、REDOを生成することができ
：に接続
- 64ビットの生産のOracle Database 12cのEnterprise Editionのリリース12.1.0.2.0
パーティショニング、OLAP、高度な分析とReal Application Testingのオプションを使用して
、SQL> ROWNUMの= 1のV $ MYSTATから選択SID
SID
----------
11 <<<<セッション1的SID为11
SQL> DBA_OBJECTSから選択*としてテーブルtを作成します。
表が作成されました。
SQL>更新トンセットobject_nameの= object_nameの。
93841行を更新しました。
セッション2：スイッチング状態のREDOの眺め
SQL>セット行200ページ1000
SQL>グループ＃を選択し、スレッド＃、五$ログからのステータス。
GROUP＃スレッド＃ステータス
---------- ---------- ----------------
1 INACTIVE
2 1 INACTIVE
3 1 CURRENT
SQL> ALTER SYSTEMスイッチのログファイル。
システムが変更されました。
SQL> ALTER SYSTEMスイッチのログファイル。
システムが変更されました。
SQL>を選択し、グループ＃、スレッド＃、五$ログからのステータス。
GROUP＃スレッド＃ステータス
---------- ---------- ----------------
1 1 ACTIVE <<<<<<让下一组是能動的
2 1 ACTIVE
3 1 CURRENT
セッション3：滞在が許可さORADEBUGが仕事をしないのDBWnとLGWRがSPID決定し、DBW0によって中断
SQL>セット行200ページ1000 SQL>を選択SPID、 '％LGの％'のようなプログラム'％のDBWの％'やプログラムなどの五$プロセスからプログラム; SPID PROGRAM ------------------------ ------------------------ ---------------------------------------- 5768 ORACLE.EXE（DBW0） 7248 ORACLE。 EXE（LGWR） 6384 ORACLE.EXE（LG00） 6308 ORACLE.EXE（LG01） SQL> ORADEBUG setospid 5768 オラクルのpid：11、WindowsのスレッドID：5768、画像：ORACLE.EXE（DBW0） SQL> ORADEBUG中断 処理された声明を。
次の更新が許可され、セッション1で再び自動切り替えログを複数回行います。
セッション1：
SQL>更新トンセットobject_nameの= object_nameの。 93841行を更新しました。 SQL> / 93841行を更新しました。 SQL> / 93841行を更新しました。 SQL> / ----在这里住ハング了
セッション4：待機療法イベント
SQL>セット行200ページ1000
A15用SQL>コルプログラム
A40のためのSQL>コルイベント
SQL> sidの、シリアル番号、プログラム、イベント、「％SQLPLUS％」のような五$セッションどこプログラムから状態を選択します。
SID SERIAL＃のプログラムイベントのSTATE
---------- ---------- --------------- --------- ------------------------------- -------------------
10 33682はsqlplus.exe SQLは、*クライアントWAITINGからの純メッセージ
WAITING（不完全なチェックポイント）11 48189はsqlplus.exeログファイルのスイッチ
129 25471はsqlplus.exe SQLは、*クライアントへのネットのメッセージは短い時間待っ
130 64963はsqlplus.exe SQL * NetのメッセージクライアントからWAITING
次は、私たちがLGWRの10046トレースを行い、待機を観察：可視制御ファイルを繰り返しシーケンシャルリード
SQL> ORADEBUG setospid 7248 オラクルは、PID：12、WindowsのスレッドID：7248、画像：ORACLE.EXE（LGWR） SQL> ORADEBUGイベント10046トレース名コンテキスト永遠に、レベル8 に処理声明を。 SQL> ORADEBUG tracefile_name D：\ ORACLE \ DIAG \ RDBMS \ r12102 \ r12102 \トレース\ r12102_lgwr_7248.trc D -f尾：\ ORACLE \ DIAG \ RDBMS \ r12102 \ r12102 \トレース\ r12102_lgwr_7248.trc WAIT＃0：ナム=」 LGWRすべてのワーカーグループのELA = 72 P1 = 0、P2 = 0 P3 = 0 OBJ＃= - 1ティム= 25178622234 WAIT＃0：=ナム'制御ファイルのシーケンシャル' ELA = 407ファイル番号= 0ブロック＃= 1つのブロックを読み込みます= 1 OBJ＃= - 1ティム= 25178622880 ＃0 WAIT：ナム= '制御ファイルのシーケンシャル読み取る' ELA = 262ファイル＃= 1つのブロック＃= 1つのブロック= 1 OBJ＃= - 1ティム= 25178623344 ＃0 WAIT：ナム= '制御ファイルのシーケンシャル読み取る' ELA = 717ファイル番号= 0ブロック＃= 15ブロック= 1 OBJ＃= - 1ティム= 25178624315 WAIT＃0：ナム= ELA = 1774ファイルを'制御ファイルのシーケンシャルリード' ＃= 0ブロック＃= 17ブロック= 1 OBJ＃= - 1ティム= 25178626427 WAIT＃0：ナム= '制御ファイルシーケンシャルリード' ELA = 311ファイル番号= 0ブロック＃= 19ブロック= 1 OBJ＃= - 1ティム= 25178627527 WAIT＃0：ナム= ELA = 269ファイル番号= 0ブロック＃= 284ブロック= 1 OBJ＃= '制御ファイルのシーケンシャルを読み取る' - 1ティム= 25178627983 WAITが＃0：ナム= '制御ファイルシーケンシャルリード' ELA = 238ファイル＃= 0ブロック＃= 22ブロック= 1 OBJ＃= - 1ティム= 25178628363 WAIT＃0：ナム= 'LGWRすべてのワーカーグループのELA = 51 P1 = 0、P2 = 0 P3 = 0 OBJ＃= - 1ティム= 25178628590 WAIT＃0：ナム= '制御ファイルのシーケンシャル読み取り' ELA = 503ファイル番号= 0ブロック＃= 1つのブロック= 1 OBJ＃= - 1ティム= 25178629320 WAIT＃0：ナム= '制御ファイルシーケンシャルリード' ELA = 322ファイル＃= 1ブロック＃= 1つのブロック= 1 OBJ＃= - 1ティム= 25178630389 WAIT＃0：ナム= '制御ファイルのシーケンシャル読み取り' ELA = 276ファイル番号= 0ブロック＃= 15ブロック= 1 OBJ＃= - 1ティム= 25178630864 WAIT＃0：ナム= ELA = 253ファイルを'制御ファイルの順次読み取り' ＃= 0ブロック＃= 17ブロック= 1 OBJ＃= - 1ティム= 25178631286 WAIT＃0：ナム= '制御ファイルシーケンシャルリード' ELA = 250ファイル番号= 0ブロック＃= 19ブロック= 1 OBJ＃= - 1ティム= 25178631696 WAIT＃0：ナム= ELA = 658ファイル番号= 0ブロック＃= 284ブロック= 1 OBJ＃= '制御ファイルのシーケンシャルを読み取る' - 1ティム= 25178632935 WAITが＃0：ナム= '制御ファイルシーケンシャルリード' ELA = 303ファイル＃= 0ブロック＃= 22ブロック= 1 OBJ＃= - 1ティム= 25178633812 ......
最後に、我々はのDBWn回復、この無限の制御ファイルのシーケンシャルの終わりには、待ち時間を読み込みます。
セッション3に戻る、DBW0を再開する。
SQL> ORADEBUG再開 ステートメントは処理します。
あなたは原理を理解すれば、この問題を診断することが困難であっただろうが、ASHおよびAWR DBA情報は問題LGWR待機制御ファイルのシーケンシャルが原因読んで考えるのは間違っているだろう。