Oracle 11g検証 フラッシュバック・データ・アーカイブ その５
＜Oracle 11g検証 フラッシュバック・データ・アーカイブ その５＞
ペンネーム： オレンジみかん
今週も引き続きフラッシュバック・データ・アーカイブ(以下、FDA）の検証
を行います。
■前回までのおさらい
前回はFDAの履歴表の過去レコードの蓄積動作について検証しました。
その結果、FDAはDELETE、UPDATEの履歴レコードを作成し、INSERTでは履歴
レコードが作成されないことが確認出来ました。
これまでのFDAの動作を見てみるとDELETE、UPDATEの実行ごとに履歴レコード
が作成されるため、長期的な履歴レコードの記録には蓄積レコード増加に
対する考慮が必要になります。そこで今回はFDAの運用に着目して検証を行い
たいと思います。
■検証
FDAはUNDO管理の過去レコード参照と違い、長期的な履歴レコードを記録
することが可能です。そのため、履歴レコード量が増加するにつれて
履歴参照時のレスポンスが悪くなることが懸念されます。
そこで、FDAで過去レコード参照する場合、履歴表の検索を速くするには
どのような対処がよいのでしょうか？
SELECT [カラム名] FROM [テーブル名] AS OF [時間]で参照した場合、
FDAではSCNで管理するため内部で検索キーが変わることが予想されます。
実際の実行計画はどのように実行されているのでしょうか？
それでは参照速度向上のための対応方法について確認してみましょう。
はじめにFDAの履歴表に存在する索引情報について確認します。
□履歴表に存在する索引の状態
今回もEMP_MGRを利用して履歴表の中身を確認してみましょう。
現在のEMP_MGRの履歴情報はUSER_FLASHBACK_ARCHIVE_TABLESで確認します。
SQL> SELECT * FROM USER_FLASHBACK_ARCHIVE_TABLES; TABLE_NAME OWNER_NAME FLASHBACK_ARCHI ARCHIVE_TABLE_NAME ------------ ---------- --------------- ------------------------- EMP_MGR SCOTT FLA1 SYS_FBA_HIST_72242
EMP_MGRの履歴表はSYS_FBA_HIST_72242です。FBA_HIST_72242表のINDEX
を確認して見てみると、以下の様に履歴表にはINDEXが存在しないようです。
SQL> SELECT INDEX_NAME,TABLE_NAME,COLUMN_NAME FROM USER_IND_COLUMNS
2 WHERE TABLE_NAME IN ('EMP_MGR','SYS_FBA_HIST_72242');
レコードが選択されませんでした。
FDAの動作を考慮すると、履歴表はFDAからの書き込みの頻度が圧倒的に
多い表となるため、書き込みパフォーマンスを優先してINDEXが作成され
ていないと考えられます。
□履歴表の実行計画（デフォルト：INDEXなし）]
SQL> explain plan for
2 SELECT * FROM EMP_MGR
3 AS OF TIMESTAMP(SYSTIMESTAMP - INTERVAL '5' MINUTE);
解析されました。
SQL> @/app/oracle/product/11.1.0/db_1/RDBMS/ADMIN/utlxplp.sql
---------------------------------------------------------------------
| Id | Operation |Name |
---------------------------------------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | VIEW | |
| 2 | UNION-ALL | |
|* 3 | FILTER | |
| 4 | PARTITION RANGE SINGLE | |
|* 5 | TABLE ACCESS FULL ← |SYS_FBA_HIST_72242 |
|* 6 | FILTER | |
|* 7 | HASH JOIN OUTER | |
|* 8 | TABLE ACCESS FULL |EMP_MGR |
| 9 | VIEW | |
|* 10 | TABLE ACCESS FULL |SYS_FBA_TCRV_72242 |
---------------------------------------------------------------------
PLAN_TABLE_OUTPUT
---------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - filter("TIMESTAMP_TO_SCN"(SYSTIMESTAMP(6)-INTERVAL'+00 00:05:00'
DAY(2) TO SECOND(0))<2700560)
5 - filter("ENDSCN""TIMESTAMP_TO_SCN"
(SYSTIMESTAMP(6)-INTERVAL'+00 00:05:00'
DAY(2) TO SECOND(0)) AND ("STARTSCN" IS NULL OR
"STARTSCN"<="TIMESTAMP_TO_SCN"(SYSTIMESTAMP(6)-INTERVAL'
+00 00:05:00' DAY(2) TO SECOND(0))))
6 - filter("F"."STARTSCN"2700560) AND ("STARTSCN"
IS NULL OR "STARTSCN"<2700560))
実行計画を確認するとINDEXが無いため過去履歴を参照するとフルスキャンに
なります。
FDAの設定によって違いがありますが、1年、2年前の過去情報を
参照するにはレスポンスが悪いことが言えます。
それでは、このレスポンスを向上させるには履歴表にINDEXを作成して、過去情報の
参照が高速になるのでしょうか？
実際に履歴表に対してINDEXを追加した場合の実行計画を確認してみましょう。
□履歴表にINDEXを追加する
EMP_MGRの履歴表は SYS_FBA_HIST_72242であることから実行計画の
ENDSCN” SELECT [カラム名] FROM [テーブル名] AS OF [時間]
以上のように、過去レコードの情報を内部監査の目的で参照する場合は、
一次的に履歴表のベースになる擬似カラムに対してINDEXを追加してから
過去レコードを参照することが有効であることが分かります。
その後は、履歴表への書き込みが定期的に行なわれるため、追加したINDEX
を削除することがFDAの負荷を軽減する上での考慮点だと考えられます。
今回はここまで
ホンダがF１から撤退。応援していたのでとても残念！！ 恵比寿にて