Oracle10g Cost Base Optimizerにまつわる検証 その2

投稿日: 2004年10月27日

<Oracle10g Cost Base Optimizerにまつわる検証 その2>
~Monitoring属性の変~
ペンネーム:グリーンペペ

先回は10gからstatistics_level=typical もしくは allの場合、Monitoring属
性がデフォルトで”YES”になっていることを確認しました。

ではMonitoring属性になっていると何がどうなるのか今一度確認してみましょ
う。Monitoring属性の表はinsert/delete/updateなどの回数がdba_tab_modifications
ディクショナリビューに監視情報として記録されます。

■環境
Miracle Linux Standard Edition V2.1
Oracle Database 10g Enterprise Edition Release 10.1.0.2.0

■Monitoring属性である表の監視情報の検証

SQL> select TABLE_NAME,MONITORING from tabs
    where table_name='EMP2';

TABLE_NAME  MONITO
----------- ------
EMP2        YES

SQL> insert into emp2 select * from emp;

14 rows created.

SQL> select * from dba_tab_modifications where table_owner='EMP2';

no rows selected

あれ!?監視情報が何も記録されていません。
実は監視情報はSGAに記録されており、SMONが15分おきにディクショナリに書
き込みを行うのです。
以下のコマンドにてSGAの監視情報よりディクショナリへの書き込みが即時に
行われます。

SQL> exec dbms_stats.flush_database_monitoring_info;

PL/SQL procedure successfully completed.

SQL> select * from dba_tab_modifications where table_owner='EMP2';

TABLE_NAME PARTITION_NAME
---------- -----------------
EMP2

SUBPARTITION_NAME         INSERTS
---------------------- ----------
                               14

   UPDATES    DELETES TIMESTAMP   TRUNCA DROP_SEGMENTS
---------- ---------- ----------- ------ -------------
         0          0 09/22 19:20 NO                 0

監視情報が記録されました。INSERTS行が14となっていることから、14回insert
が行われたことが分かります。
では先ほどのinsertトランザクションは未だcommitしてませんので、試しに
rollbackしてみたら、どうなるでしょうか?
監視情報も元に戻るのでしょうか?

■Monitoring属性である表に対するトランザクションをrollbackしてみる

SQL> rollback;

Rollback complete.

SQL> exec dbms_stats.flush_database_monitoring_info;

PL/SQL procedure successfully completed.

SQL> select * from dba_tab_modifications where table_owner='EMP2';

TABLE_NAME PARTITION_NAME
---------- -----------------
EMP2

SUBPARTITION_NAME         INSERTS
---------------------- ----------
                               14

   UPDATES    DELETES TIMESTAMP   TRUNCA DROP_SEGMENTS
---------- ---------- ----------- ------ -------------
         0          0 09/22 19:20 NO                 0

実データはrollbackされているため、何もinsertされていない状態にも関わら
ず監視情報はinsertされたことになっています。
では、この監視情報はどのタイミングにて消えるのでしょうか?

■Monitoring属性である表の監視情報の消えるタイミングを検証

▽shutdownの実行

SQL> shutdown
データベースがクローズされました。
データベースがディスマウントされました。
ORACLEインスタンスがシャットダウンされました。
SQL> startup
ORACLEインスタンスが起動しました。

Total System Global Area  285212672 bytes
Fixed Size                  1297048 bytes
Variable Size             262419816 bytes
Database Buffers           20971520 bytes
Redo Buffers                 524288 bytes
データベースがマウントされました。
データベースがオープンされました。
SQL> select * from dba_tab_modifications where table_owner='EMP2';

TABLE_NAME PARTITION_NAME
---------- -----------------
EMP2

SUBPARTITION_NAME         INSERTS
---------------------- ----------
                               14

   UPDATES    DELETES TIMESTAMP   TRUNCA DROP_SEGMENTS
---------- ---------- ----------- ------ -------------
         0          0 09/22 19:20 NO                 0

shutdownでは監視情報は消えないようです。

▽統計情報の取得

SQL> exec dbms_stats.gather_table_stats('SCOTT','EMP2');

PL/SQL procedure successfully completed.

SQL> select * from dba_tab_modifications where table_owner='EMP2';

no rows selected

監視情報がなくなりました。

■まとめ

1. Monitoring属性の表の監視情報はSGAに記録され、SMONが15分毎にディクシ
   ョナリに書き込みを行う。
2. 即時にディクショナリに書き込みを行うには
   dbms_stats.flush_database_monitoring_infoプロシジャを実行する。
3. Monitoring属性の表の監視情報は統計情報を取得すると消える。

来週こそは10gからデフォルトになったMonitoring属性とCBO(Cost Base Optimizer)
の関係の謎が明らかに。。。

コタツが恋しくなってきた茅ヶ崎より