キャッシュロードプロセス¶

各ロードプロセスの構成 (Example of the extraction section of a VDPCache job) は、VDP タイプのジョブの抽出セクションとよく似ています (このジョブは同じデータソースを使用した VDP タイプのジョブの集合体のようなものと考えることができます)。以下から構成されています。

• プリロードする VDP の ビュー 。選択されたビューのすべてのフィールドが投影されます。ユーザーはビュー名を入力できます。このコンボボックスには、ユーザーの入力によってフィルタされるビューの候補が表示されます。このコンボボックスのビューは、ジョブ用に構成された VDP データソースから取得されます (データソースで指定されたデータベースのビューだけでなく、ユーザーが権限を持つすべてのデータベースのビューがリストに表示されます)。対応する VDP サーバーが実行されている必要があります。また、レンズアイコンをクリックしてビューを選択することもできます。VDP から取得した、データベースとフォルダを含むツリー構造のポップアップが表示されます。目的のデータベースとフォルダをクリックしてビューを表示し、目的のビューにチェックを入れ、[OK] ボタンをクリックして選択します。

VDPCache ジョブのビューツリーセレクターの例¶

• フィールド名: ビューからフィールドを選択する場合は、条件 fieldName > '@LAST_REFRESH_DATE' がクエリに追加されます。このフィールドを選択すると、増分キャッシュロードが使用されます。

• クエリ条件: VDP タイプのジョブの、既存のパラメータ化クエリの where 部分です。クエリ条件はオプションであり、ユーザーは次の 2 つのコンボボックスを使用して条件を作成できます。

  • 1 つは、選択したビューの フィールドを条件に追加 するためのものです (必須フィールドが示されます)。このコンボは、新しいビューが選択されるたびに更新されます (VDP データソースがアクセス可能な場合)。

  • もう 1 つは、条件に 演算子を追加 するためのものです。このコンボには条件で使用できるすべての指定可能な演算子が含まれます。

  クエリ条件にはパラメータを指定できます。ソースと同時実行性のレベルの定義方法は VDP ジョブの場合と同じです。

  増分キャッシュロードを行う場合、 '\@LAST_REFRESH_DATE' 変数を使用して、最終実行日時を参照できます。

  ジョブ構成を保存すると、各ロードプロセスのクエリ条件が VDP に対して検証されます。エラーがある場合は、エラーのあるロードプロセスの名前が赤色で表示され、各エラーに関する詳細情報が該当のロードプロセスの詳細に表示されます。

• クエリ コンテキスト: VDP に送信されるクエリの CONTEXT 句にプロパティを指定できます。たとえば、クエリの実行時に単純化を適用しないように、 'simplify' = 'off' を指定できます。他のパラメータを使用して構成された CONTEXT 句に適用可能なオプション 1 はここでは指定できなません。

• ロード前に キャッシュを無効にする オプション: このオプションには、次の 4 つの値のいずれかを指定できます。

  1. None: キャッシュを無効にしません。

  2. All rows: このオプションが選択されている場合は、VDP に送信されるクエリの CONTEXT 句に、オプション 'cache_invalidate' = 'all_rows' が追加されます。その場合、クエリに関係なく、キャッシュからのすべてのタプルが無効になります。

  3. Matching rows: このオプションが選択されている場合は、VDP に送信されるクエリの CONTEXT 句に、オプション 'cache_invalidate' = 'matching_rows' が追加されます。その場合、クエリによって返される行に一致するタプルのみがキャッシュから無効にされます。これは、新しいジョブのデフォルトオプションです。

  4. Matching PK: このオプションが選択されている場合は、Scheduler によって VDP に送信されるクエリの CONTEXT 句に、オプション 'cache_invalidate' = 'matching_pk' が追加されます。その場合、キャッシュから無効化される行はありません。VDP では、クエリによって返される行のプライマリキーに一致するタプルを更新し、一致しないタプルを挿入します。このオプションは、選択したビューにプライマリキーが含まれる場合にのみ使用できます。

• ロードのプロセスとキャッシュデータの無効化 (構成されている場合、前述の事項を参照) が同じトランザクションで実行されているかどうかを示すオプション (Load / Invalidate data in a single transaction): このオプションがチェックされている場合、VDP に送信されるクエリの CONTEXT 句に、オプション 'cache_atomic_operation = 'true' が追加されます。チェックされていない場合は、CONTEXT 句にオプション 'cache_atomic_operation' = 'false' が追加されます。デフォルトでは、このオプションはチェックされています。

• クエリがエラーで終了した場合もキャッシュにデータを読み込む必要があるかどうかを示すオプション (Populate the cache even when a query finishes with errors): このオプションがチェックされている場合は、VDP に送信されるクエリの CONTEXT 句に、オプション 'cache_load_on_error' = 'true' が追加されます。チェックされていない場合は、CONTEXT 句にオプション 'cache_load_on_error' = 'false' が追加されます。デフォルトでは、このオプションはチェックされていません。

これらの 5 つのフィールドの値を考慮すると、VDP データソースに送信されるクエリは以下のようになります。

SELECT *
FROM view
[ WHERE <conditions> ]
CONTEXT(
'cache_preload' = 'true',
'cache_wait_for_load' = 'true',
'cache_return_query_results' = 'false',
[ 'cache_invalidate' = { 'all_rows' | 'matching_rows' | 'matching_pk' },
'cache_atomic_operation' = { 'true' | 'false' }, ]
'cache_load_on_error' = { 'true' | 'false' } )

この場合

<conditions> ::= <fieldName> > '@LAST_REFRESH_DATE'
                            | <query_conditions>
                            | <fieldName> > '@LAST_REFRESH_DATE' AND <query_conditions>

上の例が示すとおり:

• クエリは常に明示的なキャッシュロードを示します ('cache_preload' = 'true')。

• クエリの結果は Scheduler に返されません ('cache_return_query_results' = 'false')。これは、このジョブタイプにはエクスポーターセクションがないからです。

• クエリのすべての結果がキャッシュされるまで、制御権が Scheduler に戻るのを待機します ('cache_wait_for_load' = 'true')。

• オプションで、キャッシュをロードされる前に無効にすることができます ( 'cache_invalidate' = '{all_rows | matching_rows | matching_pk}' )。キャッシュのロードと無効化のプロセスを単一のトランザクションで実行するかどうかを指定できます ( 'cache_atomic_operation' = {'true' | 'false'} )。

• クエリがエラーで終了した場合もキャッシュにデータを読み込む必要があるかどうかを指定できます ('cache_load_on_error' = {'true' | 'false'})。

また、フィールド [Load Process Name] では、ユーザーが各ロードプロセスにわかりやすい名前を指定できます。この名前はロードプロセスを特定しやすいよう、それらプロセスのリストに表示されます。デフォルトでは、プリロードされたビューの名前が表示されます (同じ名前を複数のロードプロセスに割り当てることはできません)。

VDPCache ジョブの抽出セクションの例¶

増分ロードプロセス (非推奨)¶

前述のとおり、増分ロードプロセスの作成はストアドプロシージャ INCREMENTAL_CACHE_LOAD が Virtual DataPort に正しくインストールされている場合のみ実行可能です。このプロシージャには (関連するドキュメントに記載されているとおり) いくつかの制限があります。

• キャッシュされるビューは、プライマリキーを保持している必要があります。

• キャッシュされるビューは、フルキャッシュが有効になっている必要があります。

• 基本ビューとは問題なく連携しますが、派生ビューの場合はいくつかの制限があります。

各ロードプロセスの構成は、 通常のキャッシュロードプロセス を構成する場合とよく似ていますが、オプションの数が少ない点が異なります。構成は以下のとおりです。

• プリロードする VDP ビュー: この場合、プライマリキー (PK) を持つビューのみが表示されます。このオプションにより、ストアドプロシージャのパラメータ DATABASE_NAME と VIEW_NAME の値が入力されます。

• Load Process Name: 各ロードプロセスのわかりやすい名前。

• Block Size: キャッシュを更新するクエリの IN 演算子のチャンクサイズ (NUM_ELEMENTS_IN_CLAUSE)。

キャッシュにまだ存在しないソースからデータを取得する条件 (LAST_UPDATE_CONDITION) とストアドプロシージャによってキャッシュにロードされる条件は、以下のパラメータで構成できます (そのうちの少なくとも 1 つは必須)。

• Field Name: ビューからフィールドを選択する場合は、条件 fieldName > @LAST_REFRESH_DATE がクエリに追加されます。

• Custom conditions: このフィールドを使用して、クエリに追加されるカスタム条件を指定できます (変数 \@LAST_REFRESH_DATE を使用して、最後の実行時間を参照できます)。

これらのフィールドの値を考慮すると、VDP データソースに送信されるクエリは以下のようになります。

SELECT *
FROM <database_with_the_sp>.INCREMENTAL_CACHE_LOAD
('<DATABASE_NAME>',
 '<VIEW_NAME>',
 '<LAST_UPDATE_CONDITION>',
 <NUM_ELEMENTS_IN_CLAUSE>);

この場合

<LAST_UPDATE_CONDITION> ::= <fieldName> > @LAST_REFRESH_DATE
                            | <custom conditions>
                            | <fieldName> > @LAST_REFRESH_DATE AND <custom conditions>

一般的な考慮事項¶

このタイプのジョブは他の抽出ジョブとは少し異なるため (クエリされたビューによって返されるタプルが Scheduler に送信されないため、エクスポーターセクションがないことを思い出してください)、ジョブのテーブルの「Extracted」列と「Processed」列の値の意味を以下で説明します。

• クエリされた VDP ビューから抽出されたタプルは Scheduler には送信されませんが、「Extracted」列はそれらタプルの数が示されます。

• 「Processed」列は、「CacheLoader」と呼ばれる 仮想 エクスポーターの名前と、クエリされた VDP ビューのキャッシュに挿入されたタプルの数を示します。

どちらの列も個別のロードプロセスの値の集計を示しています。何らかの警告またはエラーがある場合は、最終的にそのロードプロセスのレポートを個別に確認することができます。さらに、ロードプロセスが、数回実行されるパラメータ化クエリで構成されている場合は、各パラメータに関するレポートを確認できます。「Extracted」と「Processed」のどちらの列も、各プロセスで生成されたエラーの数、つまり、それぞれ抽出エラーの数とキャッシュ挿入エラーの数を示します (他のジョブタイプと同様に、エラーがない場合、エラーの数は示されません)。

1

これらのプロパティは、 cache_preload 、 cache_wait_for_load 、 cache_return_query_results 、 cache_invalidate 、 cache_atomic_operation 、 cache_load_on_error です。