11

私はこのように定義された具体化されたビューを持っています:

CREATE MATERIALIZED VIEW M_FOO
REFRESH COMPLETE ON COMMIT
AS
    SELECT FOO_ID, BAR
    FROM FOO
    WHERE BAR IS NOT NULL
    GROUP BY FOO_ID, BAR
/

COMMENT ON MATERIALIZED VIEW M_FOO IS 'Foo-Bar pairs';

一種のキャッシュとして書きました。ソース テーブルは巨大ですが、異なるペアの数はかなり少ないです。他のテーブルと結合するには、これらのペアが必要です。これまでのところ非常に優れています。クエリが完全に高速化されています。

しかし、ビューに古いデータが含まれていないことを確認したいと考えています。基になるテーブルは月に 4 ～ 5 回変更されますが、いつ変更されるかは必ずしもわかりません。ソーステーブルが変更されたときにマテリアライズドビューが更新されるように、マテリアライズドビューを定義できることを理解しています。ただし、ドキュメントはかなり複雑になります。

  1. 使用する必要がある正確な構文は何ですか?

  2. マテリアライズド ビュー ログを作成する必要はありますか?

  3. 高速リフレッシュと完全リフレッシュの違いは何ですか?

4

2 に答える 2

21

質問を逆の順序で行うには

FAST 更新は、増分更新とも呼ばれます。それはあなたに違いについての手がかりを与えるはずです。COMPLETE リフレッシュは MVIEW 全体を最初から再構築しますが、FAST リフレッシュはフィーダー テーブルに対して実行された DML からの変更のみを適用します。

FAST リフレッシュを実行するには、適切な MVIEW LOG が必要です。これにより、基礎となるテーブルのデータへの変更が追跡されるため、Oracle は、テーブル全体をクエリするのではなく、マテリアライズド ビューにデルタを効率的に適用できます。

構文に関しては、基本は次のとおりです。

SQL> create materialized view log on emp
  2  with rowid, primary key, sequence (deptno, job)
  3  including new values
  4  /

Materialized view log created.

SQL> create materialized view emp_mv
  2  refresh fast on commit
  3  as
  4  select deptno, job from emp
  5  group by deptno, job
  6  /

Materialized view created.

SQL>

このON COMMIT句は、MVIEW がトランザクションごとに更新されることを意味します (ON DEMAND通常の一括更新ではなく)。このREFRESH句は、増分リフレッシュまたは完全リフレッシュのどちらを適用するかを指定します。更新の使用を強制するクエリのカテゴリがいくつかありますがCOMPLETE、これらは Oracle の新しいバージョンごとに減少するようです。

それが機能することを確認するための簡単なテスト...

SQL> select * from emp_mv
  2  order by deptno, job
  3  /

    DEPTNO JOB
---------- ---------
        10 MANAGER
        10 PRESIDENT
        10 SALES
        20 ANALYST
        20 CLERK
        20 MANAGER
        30 CLERK
        30 MANAGER
        30 SALESMAN
        40 CLERK
        40 DOGSBODY

11 rows selected.

SQL>

新記録どう？

SQL> insert into emp (empno, ename, deptno, job)
  2  values (6666, 'GADGET', 40, 'INSPECTOR')
  3  /

1 row created.

SQL> commit
  2  /

Commit complete.

SQL> select * from emp_mv
  2  order by deptno, job
  3  /

    DEPTNO JOB
---------- ---------
        10 MANAGER
        10 PRESIDENT
        10 SALES
        20 ANALYST
        20 CLERK
        20 MANAGER
        30 CLERK
        30 MANAGER
        30 SALESMAN
        40 CLERK
        40 DOGSBODY
        40 INSPECTOR

12 rows selected.

SQL>

構文の詳細については、SQL リファレンスを参照してください。Data Warehousing Guideの Materialized View の章も読む価値があります。

以下のコメント投稿者の懸念にもかかわらず、これは宣伝どおりに機能します. 残念ながら、デモを公開するための通常の場所 (SQL Fiddle、db<>fiddle) では、具体化されたビューは許可されていません。私は Oracle SQL Live で何かを公開しました (無料の Oracle アカウントが必要です): 私はそれに対する Oracle の承認を待っており、到着したらこの質問を更新します。

于 2010-01-08T14:17:30.390 に答える
8

高速リフレッシュでは、変更されたデータのみがマテリアライズドビューに挿入/更新/削除されます。完全に更新すると、マテリアライズドビューが空になり、すべての行にコピーされます。

「コミット時」とは、マスター表で変更がコミットされるたびにマテリアライズド・ビューが更新されることを意味します。したがって、現在の構文は非常に非効率になります。誰かがfooの行を変更するたびに、m_fooが切り捨てられ、fooテーブルのすべての行が挿入されます。

foo内の変更された行のみがm_fooに送信される、高速リフレッシュを使用すると、より適切に実行できます。これにより、多くのオーバーヘッドなしで一貫性が得られます。

主キーを使用してfooにマテリアライズドビューログを作成します。--主キーがあると仮定すると、コミット時にマテリアライズドビューm_foorefreshを\;として高速に作成する必要があります。

dbリンクを使用している場合、またはfooを所有するスキーマがm_fooを所有するスキーマではない場合は、許可と同義語にいくつかの追加の微妙な点があります。

于 2010-01-08T13:56:49.957 に答える