その10>ペンネーム:クリープ前回で終了しましたマテリアライズドビューの検証でしたが、ご好評にお応えして!?早くも帰ってきました。COMMITについての質問にお応え致します。COMMITに設定した時のパフォーマンスが気になります。COMMITは、元表のデータが変更されCOMMITされた時に自動的にリフレッシュされるようになります。COMMITについては扱っていませんでしたので、ここで少し確認してみましょう。COMMITできるのは、高速リフレッシュが可能な場合のみとなります。この状態で元表に対して変更を行うと、COMMITと同時にリフレッシュも行われます。<==COMMIT後に追加されているコミットした時点でマテビューが更新されています。リフレッシュを行う必要がなく、コミットした時点なのでマテビューを常に最新の状態に保つことができます。COMMITは非常に便利な機能である反面、コミット時にマテビューに更新処理が発生する為、処理時間が気になるところです。実際に確認してみましょう。'c');100万件のデータが入っているテーブルemp_100manを作成しました。最後に完全リフレッシュを行っているのは、truncate文はDDL文なのでONCOMMITしてもリフレッシュされないからです。truncate文には気をつけましょう。commit;INSERTの実行に360秒、COMMITの実行に180秒かかりました。COMMIT時にMV_EMPへの更新処理が実行されていることが原因なのでしょうか。実際にMV_EMPへのMERGE文の処理時間を確認してみましょう。17.051233SQL>※一部抜粋MERGE文の処理時間(ELAPSED_TIME)は17秒なので、INSERT文の実行時間(360秒)が長い原因とは直接関係無いようです。行のみなので、処理時間はほとんどかからないと考えられます。ここで忘れてはいけないのが、MLOGの存在。※一部抜粋2つ目のINSERT以外はコミット時に実行されている処理であり、合計で168秒かかっている為、コミットの処理に180秒近くかかってしまっています。ちなみに、INSERT処理に実行されているMLOGへの挿入処理も255秒と全処理(360秒)の半分以上の処理時間がかかっています。423秒)がMLOGの処理に対して費やされたということになります。以上、マテビューのご質問にお応えしました。次回も引き続きマテビューQアンドAをお送りする予定です。reserved.トップページ企業概要プライバシーポリシ。