コミットクリーンアウトや、遅延ブロッククリーンアウトはどういう扱いになるのだろう。(このシリーズの初回で紹介したいろいろなブログに答えはあるのですがw)システム統計やセッション統計の統計値から、それをどう読み取るか。traceによる実行計画と実行統計を診ていくわけですが。wということで、今回は、前回利用していた表を元にIASで別表を作成し、コミット前後の状況を診ていきたいとおもいます。writeの方から挙動を診ていくことにします。判別しやすくなったよねーというネタをやってましたね。実行計画だけでも違いがわかりやすくなっているので便利になりました。SELECTの実行計画の違い。PDBのscottでログインしてclient_infoをセットv$sessionのclient_info列の'TargetSession'文字列で他のSCOTTユーザーのセッションを特定するため。している様子が確認できますよね。writeでバッファキャッシュを経由せず書き出されたブロックはコミット時にはクリーンアウトの対象にはなっていないようですね。統計をみる限りノイズ程度ですね。いうことは全てのブロックが遅延ブロッククリーンアウト対象になってしまうのか、または、その逆で、最初からクリーンアウト対象にもなっていないかということになります。readで全表走査)REDOログは多少生成されていますが、実際に遅延ブロッククリーンアウトが発生した場合REDOログ量この程度では少なすぎますよね。今回の検証目的からするとノイズの類ですね。