オレンジみかん今週も引き続きフラッシュバック・データ・アーカイブ(以下、FDA)の検証を行います。■前回までのおさらい前回はFDAの履歴表の過去レコードの蓄積動作について検証しました。その結果、FDAはDELETE、UPDATEの履歴レコードを作成し、INSERTでは履歴レコードが作成されないことが確認出来ました。これまでのFDAの動作を見てみるとDELETE、UPDATEの実行ごとに履歴レコードが作成されるため、長期的な履歴レコードの記録には蓄積レコード増加に対する考慮が必要になります。そこで今回はFDAの運用に着目して検証を行いたいと思います。■検証FDAはUNDO管理の過去レコード参照と違い、長期的な履歴レコードを記録することが可能です。そのため、履歴レコード量が増加するにつれて履歴参照時のレスポンスが悪くなることが懸念されます。[時間]で参照した場合、FDAではSCNで管理するため内部で検索キーが変わることが予想されます。実際の実行計画はどのように実行されているのでしょうか?それでは参照速度向上のための対応方法について確認してみましょう。はじめにFDAの履歴表に存在する索引情報について確認します。今回もEMP_MGRを利用して履歴表の中身を確認してみましょう。現在のEMP_MGRの履歴情報はUSER_FLASHBACK_ARCHIVE_TABLESで確認します。SYS_FBA_HIST_72242EMP_MGRの履歴表はSYS_FBA_HIST_72242です。FBA_HIST_72242表のINDEXを確認して見てみると、以下の様に履歴表にはINDEXが存在しないようです。レコードが選択されませんでした。FDAの動作を考慮すると、履歴表はFDAからの書き込みの頻度が圧倒的に多い表となるため、書き込みパフォーマンスを優先してINDEXが作成されていないと考えられます。"STARTSCN"&lt;2700560))実行計画を確認するとINDEXが無いため過去履歴を参照するとフルスキャンになります。FDAの設定によって違いがありますが、1年、2年前の過去情報を参照するにはレスポンスが悪いことが言えます。それでは、このレスポンスを向上させるには履歴表にINDEXを作成して、過去情報の参照が高速になるのでしょうか?実際に履歴表に対してINDEXを追加した場合の実行計画を確認してみましょう。一次的に履歴表のベースになる擬似カラムに対してINDEXを追加してから過去レコードを参照することが有効であることが分かります。その後は、履歴表への書き込みが定期的に行なわれるため、追加したINDEXを削除することがFDAの負荷を軽減する上での考慮点だと考えられます。今回はここまでホンダがF1から撤退。reserved.トップページ企業概要プライバシーポリシ。