HANA：xsodata：第一及び第二のリクエストの実行の間に大きな性能差

Question

私はxsodata

service namespace "oData" { 
    entity "mySchema"."myView" as "myView"; 
} 

経由VIEW

CREATE VIEW myView AS 
SELECT ... 
FROM ... 

を公開し、ビューの作成、パフォーマンス後、初めて/ MYVIEWを取得した場合非常に低いです。しかし

：PE後

質問：

• なぜ（それ以降と毎回）同じ要求を再rformingパフォーマンスは、私はそれになりたいものですか！最初の実行時間の長い要求を回避するために、どのように

• ？すでに試した

：HANAスタジオのSQLコンソールで（文の準備なし）SQLプロファイラ出力の

• 実行は常に良いパフォーマンスを提供します

• 表のhotloading（LOAD myTable ALL;は）ありませんでした効果

更新

リクエストにパラメータがない場合でも、xs-engineはクエリを準備文として実行しています。最初の実行（ユーザーのコンテキスト内で）でクエリが処理され、結果はM_SQL_PLAN_CACHE（SELECT * FROM M_SQL_PLAN_CACHE WHERE USER_NAME = 'myUser'）になります。プラン・キャッシュ（ALTER SYSTEM CLEAR SQL PLAN CACHE）をクリアすると、oData要求が再び遅くなり、パフォーマンスのギャップが問合せの再作成にあるという前提が導かれます。どのようにそれを避けるために：

現在第二の問題で立ち往生していますか？私はあなたがに最初の実行に長い時間を削除することができますが、あなたができることを確認していないよ...ただのエントリを無効にし、それを自動的に更新されませんでした（ALTER SYSTEM RECOMPILE SQL PLAN CACHE ENTRY 123）再コンパイルのため

Answer 1

を特定のプランキャッシュエントリをマークする我々のアプローチSQL Engineで実行されている計算ビューにビューを変更してみてください。

HANAは、スーパーその計算ビューを使用するために最適化されており、計画のキャッシュは多分最初の実行時間を大幅に削減、より速く彼らと実行する必要があります。また、Calcのキャッシュを計画する。ビューはユーザー間で共有する必要があります（_SYS_REPOはそれらを生成するユーザーです）。

スクリプトのバージョンを使用している場合、私はあなたがあなたの現在のSQLの多くを再利用することができ信じているが、あなたはまた、同様に、グラフィカルなアプローチを使用して試すことができます。

あなたは運を持っていた場合、私たちは知ってみましょう。ビッグデータによるモデリングは常に驚きです。