0

私は、約 8 つのマスター テーブルにまたがる単純なマテリアライズド ビューを持っています。

create materialized view MV
REFRESH FAST ON COMMIT as
  SELECT...

また、具体化されたログのサイズを監視するために、このクエリを実行しています。

select segment_name, SUM ( (BYTES) / (1024 * 1024)) "Allocated(MB)" from dba_segments where (segment_name, owner) IN (
  select log_table, log_owner from dba_mview_logs where log_owner = 'XXX')
and segment_type = 'TABLE' GROUP BY segment_name;

コミット時に更新しているので、これらのログが大きくなる機会があるとは思いません。テーブルに書き込むとすぐに、ビューが更新され、ログがクリアされることを期待しています。

ただし、私のログのほとんどは 0.0625mb で、1 つが 27mb、もう 1 つが 2mb です。サイズが大きくなった原因を調べるにはどうすればよいですか？大きなサイズのログを持つ両方のテーブルには、おそらく大きなデータを保持する BLOB 列が含まれています。しかし、なぜこれらのログが 0 より大きいのか、基本的なレベルでは理解できません。

4

1 に答える 1

1

テーブル データ セグメントは、そこからデータが削除されても縮小されません。また、セグメント サイズは、(テーブルスペースの設定に基づいて) 拡大するサイズの増分にも依存します。

そこに表示されるのは、segmenbt が保持しているデータの量ではなく、segmenbt が成長した最大サイズです。クエリを実行すると空になる可能性があります。MV ログ テーブルの行数を数えるだけです。

テーブルに依存するすべての MView を調べて、それらの最終更新時刻を確認し、mview ログ内の SNAPTIME$$ のセットと比較できます。snaptime$$ の後に MView がすべて確実に更新されている場合は、mview.purge_log を見て行を削除してください。

于 2013-07-01T14:11:20.967 に答える