問題タブ [materialized-views]

次のようなマテリアライズドビューがありますが、このマテリアライズドビューを「高速」で更新できるようにする方法があるかどうか疑問に思っています。基本的に、私は次のことを求めています。

1. マテリアライズド・ビューにCOALESCE、NVL、NVL2などのOracle関数を含めても、高速で更新できますか？

2. マテリアライズド・ビューには、私が作成した関数を含めることができますが、それでも高速で更新できます。

3. マテリアライズドビューに派生テーブルへの結合を含めても、高速に更新できますか？

これについてOracleのドキュメントを確認しましたが、これらの制限はリストされていませんでしたが、以下のケースを自分のシステムでテストした後、それが可能であるとは思いません。

Oracleバージョン：10g

アプリケーションの1つに、1日に3回更新され、更新に7時間かかる大規模なマテリアライズドビューがあります。（理想的ではありません、私は知っています）。更新中はユーザーとセッションがこのマテリアライズドビューにアクセスできないと確信していたので、これは私を困惑させましたが、どうやらアクセスできるようです！。（更新の種類は完全更新です）

完全な更新中に、私の理解では、既存のデータセットが削除され、クエリが再実行されます。これが当てはまる場合、マテリアライズド・ビューがリフレッシュされている間、ユーザー/他のセッションはどのようにしてマテリアライズド・ビューにアクセスできますか？

次の SQL を使用して、特定のマテリアライズド ビューの DDL を取得できます。

テーブルスペース情報がないと DDL を取得できません。SET_TRANSFORM_PARAMディレクティブは、実際にはテーブルとインデックス (具体化されたビューではない) に固有のものとして文書化されています。STORAGEone は実際に機能しますが、andTABLESPACEはSEGMENT_ATTRIBUTES効果がありません。生成された DDL からテーブルスペース情報を省略する方法はありますか?

本番環境で実行されたビューを具体化しましたが、更新に問題があります。エラーメッセージは

ORA-32411: マテリアライズド・ビュー定義問合せが最大長を超えています

問題があるのは、76kb、70kb、75kb、および 67kb です。クエリを分割する以外にできることはありますか? スクリプトはそれぞれ 1 つの長いクエリであるため、分割するのは困難です。

たとえば、さまざまなイベントに関する情報を保持するテーブルがあります

すべてのクエリの90％が今日のイベントにのみアクセスすることに気づきました。古い行は履歴として保存され、最終的にアーカイブテーブルに移動されます。
ただし、イベントテーブルはまだ大きいので、次のようなマテリアライズドビューを作成してパフォーマンスを向上させることができるWHERE event_date = trunc(sysdate)でしょevent_dateうか。まったく許されますか？

ありがとう

RubyonRailsとPostgreSQLを使ってプログラムを書いています。システムは、頻繁に更新され、ユーザーが頻繁にアクセスする多くのレポートを生成します。Postgresトリガーを使用してレポートテーブル（Oracleマテリアライズドビューなど）を作成する必要があるのか​​、ActiveRecordコールバックに組み込まれているRailsを使用する必要があるのか​​がわかりません。誰かがこれについて何か考えや経験を持っていますか？

SQL Server Compact Edition の現在のバージョンまたは計画されている将来のバージョンは、マテリアライズド ビューをサポートしていますか? ストレート SQL とテーブル インデックス以外の方法で同様の機能を実装する方法はありますか?

私はそのようなビューを作成しようとしています：

そして、私が得るのはエラーだけです::テーブルスペースMySmallTSORA-01658のセグメントのINITIALエクステントを作成できません

さて、今、私がビューを作成しようとしているユーザーMySmallTSのデフォルトのtsです-そしてそれはいっぱいです。表スペースがいっぱいであるということは別の問題であり、対処されていますが、どこに欲しいかを明示的に指示しているのに、なぜOracleはこのビューにそれを使用しようとしているのでしょうか。

さらに、クエリaを変更してgroup by'sを削除すると、それが機能し、正しい表スペースにビューが作成されます。

TEMPグループ化や合計などの操作全体で、そのユーザーに割り当てられたテーブルスペースを使用するべきではないでしょうか。それは理にかなっているように思えますが、ちなみに、私の臨時雇用者には十分なスペースがあります...

どうしてこんなことに？

ありがとう

実際のアプリデータのコピーに対して正常に実行されるマテリアライズドビューをいくつか作成しました。アプリは独自のデータを監視しません。それ以来、一部のユーザーは、データ入力に不注意または創造的であった可能性があります。Mviewはチョークして死にます。エラーメッセージは、1つ以上の関数から複数の行が返されることを示しています。

EXCEPTIONSを使用しようとしていますが、DBMS_Outputで最初の行object_idが成功し、関数（の1つ）が失敗します。MViewの実行を完了し、各関数から問題を引き起こすobject_idsをログに記録できる方がよいでしょう。例外データをテーブルに挿入することに成功していません。

プラットフォームはOracle10g2です。DMLエラーログインを頭に詰め込もうとしています。これはBULKデータで機能するはずであると理解しており、マテリアライズドビューを作成することは適切であると想定しています。これはMViewsで機能しますか？これが最善の方法ですか？

当社のアプリケーションでは、サーバーから統計データ（負荷、ディスク使用量など）を収集します。膨大な量のデータがあり、常にすべてのデータを必要とするわけではないため、生データを取得して最小値を計算する「圧縮」ルーチンがあります。多数のデータポイントの最大値と平均値。これらの新しい値を同じテーブルに保存し、数週間後に古い値を削除します。

今、私はこの圧縮ルーチンを書き直す任務を負っています。新しいルーチンは、1年間のすべての非圧縮データを1つのテーブルに保持し、「圧縮」データを別のテーブルに保持する必要があります。私の主な関心事は、データベースに継続的に書き込まれるデータを処理する方法と、「トランザクションテーブル」を使用するかどうかです（より良いものを思い付くことができないので、私自身の用語です。コミットについては話していません。 / rollbackトランザクション機能）。

現在のところ、データコレクターはすべての情報をという名前のテーブルに挿入しovak_result、圧縮されたデータはで終わりovak_resultcompressedます。しかし、「一時ストレージ」と呼ばれるテーブルを作成して「一時ストレージ」としてovak_resultuncompressed使用することには、特定の利点または欠点がありますか？圧縮ルーチンに適した最小限に抑えられますが、すべてのデータをあるテーブルから別のテーブルに継続的にシャッフルする必要があり、で常に読み取り、書き込み、削除が行われます。ovak_resultovak_resultovak_result

この種のものを処理するためのMySQLのメカニズムはありますか？

（注意：ここでは非常に大きなデータセットについて説明しています（非圧縮テーブルで約1億行、圧縮テーブルで約1〜10 M行）。また、ソフトウェアとハ​​ードウェアの両方の構成で、ほぼやりたいことができます。したがって、MySQLの構成やハードウェアのセットアップに関するヒントやアイデアがある場合は、それらを実行してください。）