使用するTDVキャッシングオプションを選択するには、各キャッシングオプションと、さまざまなTDVリソースに対してキャッシングがどのように機能するかを事前に理解しておくことをお勧めします。このセクションでは、次のトピックについて説明します。

TDV内で、ビューとテーブルのキャッシュを構成できます。SELECT *をビューまたはテーブルに対して実行すると、返された行がすべてキャッシュに配置されます。このため、次のようになります。

キャッシュするデータまたはオブジェクトに基づいてビューを作成できます。その後、パフォーマンス上の理由から、キャッシュされたビューに含まれるデータを制限できます。

TDVキャッシングは、次のいずれかの条件下で、具体化されたビューに使用するのが最適です。

ビューキャッシュでは、クエリーがキャッシュされたビューを参照し、キャッシュがロードされない場合、キャッシュの更新が開始され、キャッシュがロードされるまでクエリーがブロックされます。

次の例では、Sales_TableはOracleテーブルで、UK_Sales_ViewはそのテーブルのTDVビューです。テーブルレベルでキャッシュした場合は、Sales_Tableから1,000万行と15列すべてが選択され、キャッシュに入れられます。ただし、ビューをキャッシュした場合は、3列のみがビューに射影され、WHERE句によって結果セットが10万行に制限されます。

UK_Sales_ViewのWHERE句とSQLは、処理のためにOracleデータベースにプッシュされます。Oracleから10万行と3列のみが抽出され、ネットワーク経由で送信され、キャッシュに配置されます。これにより、500分の1のデータで同じ結果が得られます。キャッシュが小さくなり、更新が速くなるとともに、更新時におけるOracleデータベースとネットワークの両方への負荷が少なくなります。

次の例では、Composite_viewはファイル、Oracleテーブル、およびSAPテーブルを結合します。Report_procはComposite_viewを使用し、このビューに対して述語をプッシュします。File_1はプッシュをサポートしていないため、述語で毎回File_1とSAP_Table_1のフルスキャンが必要になり、結合とフェッチのパフォーマンスが低下します。Composite_viewがキャッシュされている場合、結合は1回だけ実行されます。

TDVでは、プロシージャベースのリソースからの表形式の結果をキャッシュできます。1つ以上の入力パラメーターを持つプロシージャは、多くのバリアント(入力パラメーターの一意のセット)を持ち、それらの入力バリアントに基づいてさまざまな結果セットを返すことができます。同じプロシージャからの複数の結果セットもキャッシュできます。

バリアントを追跡するため、入力パラメーター値が文字列に変換され、一意性が比較されます。この文字列が255文字を超える場合、プロシージャ呼び出しはキャッシュされません。代わりに、キャッシングが無効になっているかのように実行されます。

たとえば、Proc_1は1つの入力パラメーター(A、整数)を持ち、結果セットを返します。Proc_1は、Aのさまざまな値について呼び出すことができます。キャッシングメカニズムは、このプロシージャを実行し、入力パラメーターの一意のセット(この場合は整数A)ごとに結果セットを格納します。2つのバリアントがキャッシュにあり、1つはA = 1、もう1つはA = 2であるとします。Proc_1がA = 1またはA = 2で呼び出された場合、いずれかのバリアントにヒットし、対応するキャッシュされた結果セットが返されます。

A = 3などの現在キャッシュされていないバリアントでProc_1が呼び出された場合は、「キャッシュミス」が発生し、プロシージャがA = 3で実行されます。結果セットは呼び出し元に直接返され、バリアントと結果セットの両方がキャッシュに書き込まれます。A = 3の結果セットの有効期限が切れる前にproc_1 (3)が再度呼び出された場合、キャッシュされた結果セットが即座に返されます。

バリアントは多数存在する可能性があるため、すべてを保存できない場合があります。デフォルトでは、保存されるバリアントの最大数は32ですが、[Caching(キャッシュ作成)]パネルの[Advanced(詳細)]セクションにある[Maximum number of procedure variants(プロシージャバリアントの最大数)]フィールドでこの値を変更できます。キャッシュがいっぱいの場合は、最新のバリアントを保存できるように使用後の経過時間が最も長いバリアントがスワップアウトされます。

次のプロシージャリソースをキャッシュできます。

プロシージャのキャッシングプロセスでは、出力カーソルごとに1つのストレージテーブルを使用し、スカラー出力用に追加のストレージテーブルを使用します。たとえば、2つのINTEGER出力と2つのCURSOR出力があるプロシージャでは、次の3つのテーブルを使用します。

プロシージャに入力パラメーターがある場合、キャッシュされた結果は、入力値の一意のセットごとに個別に追跡されます。入力パラメーター値の一意の各セットは、バリアントと呼ばれます。

たとえば、INTEGER入力パラメーターを持つプロシージャでは、1、3、5などの値の入力について個別の結果がキャッシュされます。2つのINTEGER入力パラメーターを持つプロシージャでは、入力(1,1)、(1,2)、(x,y)について個別の結果がキャッシュされます。

注意: null以外の入力パラメーターを使用するプロシージャキャッシュには、Studio以外のクライアントアプリケーションから少なくとも1つのバリアントがシードされる必要があります。シードされない場合、[Cache Status(キャッシュステータス)]が[NOT LOADED(未ロード)]から[UP(稼働中)]に変更されません。[Refresh Now(今すぐ更新)]ボタンを使用しても、ロードされていないキャッシュのステータスは変更されません。プロシージャのキャッシング構成が正しい場合でも、クライアントがキャッシュをシードするまで、ステータスはロード済みと表示されません。

プロシージャのキャッシュが更新されると、すでにテーブルに存在するすべてのキャッシュ済みバリアントが更新されます。バリアントがまだキャッシュされていない場合は、何も更新されないか、null入力バリアントのみが更新されます。プロシージャのキャッシュは、Studioから、またはRefreshResourceCacheプロシージャを使用して更新できます(『TDV Application Programming Interfaces Guide(TDVアプリケーションプログラミングインターフェイスガイド)』を参照してください)。

プロシージャでは、トランザクション結果のキャッシングを使用できます。入力パラメーター値の一意のセットごとに、キャッシュデータが1回収集されます。トランザクション結果のキャッシングが有効になっている場合、トランザクション中にプロシージャが初めて実行されたときに、結果がメモリーにキャプチャされます。その後、同じ入力パラメーターを使用してプロシージャを呼び出すと、キャッシュされたデータが返されます。トランザクション結果のキャッシングでは、更新、クリア、ステータス、または追跡は使用できません。

トランザクション結果のキャッシングは、次のようなシナリオで役立ちます。

SQLスクリプトの呼び出しの結果はメモリーに保存されます。後で同じパラメーターを使用して呼び出すと、データがキャッシュに存在する場合はキャッシュからデータが返され、存在しない場合はSQLスクリプトが実行され、そのバリアントがメモリーに保存されます。

トランザクション結果のキャッシングでは、

たとえば、次の2つのTDVリソースについて考えてみましょう。ルックアップを呼び出すたびに、テーブルへのSQLルックアップが必要になります。複合ビューがトランザクション結果のキャッシングなしで100万行を返す場合、ルックアップによってデータベースクエリーが100万回実行されます。トランザクション処理が有効になっていて、field1に一意のデータが含まれていない場合、結果と入力の各組み合わせが一時的にメモリーに保存されます。重複するfield1値が返されると、TDVはメモリー内にあるその入力の前の結果値を返します。トランザクションが終了すると、すべての値が破棄されます。

トランザクション結果のキャッシングを有効にするには、任意のプロシージャの[Info(情報)]タブにある[Transaction Options(トランザクションオプション)]セクションで[Execute only once per transaction for each unique set of input values(入力値の一意のセットごとに、各トランザクションで1回のみ実行する)]チェックボックスをオンにします。

クラスター環境(TDVアクティブクラスターか、その他のクラスター環境かを問わず)でTDVサーバーを実行している場合は、データをキャッシュできます。

TDVサーバーがクラスターで実行されていて、キャッシュがデフォルトキャッシュモードまたは自動モードの場合、各サーバーはキャッシュされたデータの個別のコピーをローカルファイルまたはデータベースシステムに保持し、データの共有は実行されません。

サーバーがクラスターで実行されていて、キャッシュが単一テーブルモード、またはデータターゲットが識別されている複数テーブルモードの場合、クラスター内のすべてのサーバーがキャッシュ情報を取得するために同じデータターゲットにアクセスします。さらに、各サーバーは連携して更新回数を再証言に抑えます。たとえば、2つのサーバーがどちらもキャッシュ内のデータを更新する必要がある場合、一方のサーバーのみが更新を実行し、両方のサーバーが更新されたデータを使用します。

注意: クラスター内でファイルキャッシュデータソースまたはその他のファイルベースのデータソースを使用することは推奨されません。ファイルデータソースではファイルのロックがサポートされないため、ネットワークにマウントされたファイルを使用することも推奨されません。

クラスター環境では、キャッシュを更新しようとすると、他の更新が進行中であるかどうかを判断するためにTDVキャッシュステータステーブルが使用されます。他に進行中の更新がない場合は、更新が開始され、他のすべてのサーバーはTDVキャッシュステータステーブルを再読み取りするよう通知されます(キャッシュステータステーブルの詳細については、「TDVによって作成されるキャッシングオブジェクト」を参照してください)。更新がすでに進行中の場合、サーバーは現在更新中のサーバーに問い合わせを行い、その更新が完了するまで待ちます。

クラスター環境では、キャッシュをクリアしようとすると、TDVキャッシュステータステーブルのキャッシュデータがクリア対象としてマークされます。データを実際に削除するバックグラウンドタスクは、他のクラスターメンバーに問い合わせを行い、使用されなくなったキャッシュキーを判別します。これにより、クラスター内のどのサーバーもアクセスしていない行のみを安全に削除できます。クリアタスクが完了すると、他のすべてのサーバーはTDVキャッシュステータステーブルを再読み取りするよう通知されます。

クラスター内のスケジュールされた更新では、トリガーシステムクラスター機能を使用して、トリガーが適切な回数だけ処理されるようにします。ファイルキャッシュのスケジュールでは、サーバーごとに個別に起動するように構成します。データベースキャッシュのスケジュールでは、クラスターごとに1回だけ起動するように構成します。[Caching(キャッシュ作成)]パネルにあるスケジュールオプションを使用する代わりに、トリガーリソースを作成してこの動作を制御できます(「トリガー」を参照してください)。