キャッシュの監視と管理

基礎となるデータベース内の変更を管理し、キャッシュ・エントリを監視するには、キャッシュの管理方針を決める必要があります。

キャッシュ・エントリの作成元である、基礎となる表内のデータが変更されたときにキャッシュ・エントリを無効化するプロセスと、不要なキャッシュ・エントリを監視、識別および削除するプロセスが必要です。

この項では、次の項目について説明します。

キャッシュ管理方針の選択

キャッシュ管理方針の選択は、基礎となるデータベース内のデータの変動性と、この変動を引き起こす変更の予測可能性に依存します。

また、キャッシュに含まれる問合せの数と種類、およびその問合せの使用状況にも依存します。この項では、様々なキャッシュ管理方法の概要を説明します。

システムのキャッシングの無効化

システム全体のキャッシングを無効にすることで、新しいすべてのキャッシュ・エントリを停止し、既存のキャッシュを使用する新しい問合せを停止できます。キャッシングを無効にしても、キャッシュ内に保存されているエントリを失うことなく、後で有効にできます。

キャッシュ・エントリが古い疑いがあるが、そのエントリまたはキャッシュ全体をパージする前に、それが本当に古いかどうかを確認することが望まれる状況では、キャッシングの一時的な無効化の方針が役に立ちます。キャッシュに保存されているデータに依然として関連性があることが判明した場合、または問題のエントリを無事にパージした後で、キャッシュを安全に有効化できます。必要に応じて、キャッシュを再び有効化する前に、キャッシュ全体をパージするか、特定のビジネス・モデルに関連するキャッシュをパージします。

「問合せキャッシングを有効または無効にするためのFusion Middleware Controlの使用」を参照してください。

指定された物理表のキャッシングとキャッシュ永続時間

各物理表のキャッシュ可能属性を設定することで、その表に対する問合せをキャッシュに追加して、今後の問合せに答えを返すかどうかを指定できます。

表のキャッシングを有効にすると、表に関係する問合せがキャッシュに追加されます。デフォルトではすべての表がキャッシュ可能ですが、「キャッシュ永続時間」の設定を使用している場合を除き、表によってはキャッシュに含める必要がない可能性があります。たとえば、毎分更新される株価データを保存している表があるものとします。「キャッシュ永続時間」の設定を使用すると、その表のエントリを59秒ごとにパージできます。

「キャッシュ永続時間」フィールドを使用して、この表のエントリを問合せキャッシュに格納する時間を指定することもできます。これは、頻繁に更新されるデータ・ソースに役立ちます。

管理ツールの物理レイヤーで、物理表をダブルクリックします。
「物理表プロパティ」ダイアログの「一般」タブで、次のいずれかを選択します。
- キャッシングを有効にするには、「キャッシュ可能」を選択します。
- 表をキャッシュしないようにするには、「キャッシュ可能」の選択を解除します。
キャッシュの有効期限を設定するには、「キャッシュ永続時間」を指定し、単位(日、時間、分または秒)を指定します。キャッシュ・エントリが自動的に期限切れにならないようにするには、「キャッシュ失効なし」を選択します。
「OK」をクリックします。

Oracle BIサーバーのイベント・ポーリング表の構成

Oracle BIサーバーのイベント・ポーリング表には、基礎となるデータベース内の更新に関する情報が保存されます。

データベース表が更新されるたびにイベント・ポーリング表に行を追加するように、アプリケーション(データ・マートにデータをロードするアプリケーションなど)を構成できます。Oracle BIサーバーは、設定された間隔でこの表をポーリングし、更新された表に対応するキャッシュ・エントリを無効にします。イベント・ポーリング表は、キャッシュ管理の唯一の方法の場合もあれば、他のキャッシュ管理方式とともに使用することもできます。イベント表は、キャッシュ・エントリの選択とパージのタイミングに関して、あまり柔軟性はありません。「物理データベース上でのイベント・ポーリング表の設定」を参照してください。

ODBCプロシージャを使用するキャッシュのパージと保守

Oracle BIサーバーには、キャッシュ・エントリをパージするためのODBC拡張関数があります。

これらの関数の中には、抽出、変換およびロード(ETL)タスクに埋め込むのに特に役立つものがあります。たとえば、毎晩のETLの実行後に、すべてのOracle BIサーバー・キャッシュ・エントリをパージできます。ファクト表だけが変更された場合は、その表に関連するキャッシュのみをパージできます。場合によっては、特定のデータベースに関連するキャッシュ・エントリをパージする必要があります。

キャッシュをパージする権限を持つのは管理者だけです。したがって、このようなODBC拡張関数をコールするスクリプトは、管理者権限の資格証明の下で実行する必要があります。

次のODBC関数は、ODBC接続で指定されるリポジトリに関連するキャッシュ・エントリに影響します。

SAPurgeCacheByQuery。指定された問合せに完全に一致するキャッシュ・エントリをパージします。たとえば、次の問合せを使用すると、給与が$100,000を超えるすべての従業員の名前を取得する、1つ以上の問合せキャッシュ・エントリが得られます。
```
SELECT lastname, firstname FROM employee WHERE salary > 100000;
```
次のコールによって、この問合せに関連するキャッシュ・エントリがパージされます。
```
Call SAPurgeCacheByQuery('SELECT lastname, firstname FROM employee WHERE salary > 100000' );
```
SAPurgeCacheByTable。クライアントが接続されているリポジトリの、指定された物理表名(完全修飾)に関連するすべてのキャッシュ・エントリをパージします。

この関数は、完全修飾された物理表名の4つのコンポーネント(データベース、カタログ、スキーマおよび表名に固有)を表す、最大で4つのパラメータを使用します。たとえば、完全修飾名がDBName.CatName.SchName.TabNameという表があるものとします。Oracle Business Intelligenceリポジトリの物理レイヤーにあるこの表に関連するキャッシュ・エントリをパージするには、スクリプト内で次のコールを実行します。
```
Call SAPurgeCacheByTable( 'DBName', 'CatName', 'SchName', 'TabName' );
```
注意:
Oracle BIサーバーでは、この関数内でのワイルドカードをサポートしていません。また、DBNameとTabNameをnullにすることはできません。どちらかがnullの場合は、エラー・メッセージが表示されます。
SAPurgeAllCache。すべてのキャッシュ・エントリをパージします。このコールの例を次に示します。
```
Call SAPurgeAllCache();
```
SAPurgeCacheByDatabase。特定の物理データベース名に関連するすべてのキャッシュ・エントリをパージします。キャッシュをパージするODBCプロシージャがコールされると、レコードが返されます。この関数では、物理データベース名を表す1つのパラメータを使用し、パラメータをnullにすることはできません。このコールの構文を次に示します。
```
Call SAPurgeCacheByDatabase( 'DBName' );
```

ODBCプロシージャ構文について

プロシージャの文字列引数の中に一重引用符がある場合は、もう1つの一重引用符を使用してエスケープする必要があります。

例:

Call SAPurgeCacheByQuery('SELECT TOPN("- Currency"."Markdown %", 10) saw_0,
"XX Line"."Order No" saw_1, "- Bill-To Site"."Customer Name" saw_2, "-
Currency"."Net USD" saw_3, "- Currency"."Markdown USD" saw_4, "-
Currency"."Markdown %" saw_5 FROM "Apps 11i - XX Lines" WHERE 
("XX Line"."Open Flag" = ''Y'') AND ("Operating Unit"."Group Name" = ''Group'')
AND ("- Currency"."Net USD" >= 10000) ORDER BY saw_0');

太字の行は、''Y''および''Group''というアイテムのエスケープ文字として使用されている、追加の一重引用符を示しています。

プレゼンテーション・サービス問合せキャッシュの共有について

ユーザーがアンサーにアクセスして問合せを実行すると、プレゼンテーション・サービスは問合せの結果をキャッシュします。

プレゼンテーション・サービスでは、リクエスト・キーと論理SQL文字列を使用して、キャッシュされた結果を後続の問合せが使用できるかどうかを決定します。キャッシュを共有できる場合、後続の問合せは保存されません。

SAGetSharedRequestKey。プレゼンテーション・サービスから論理SQL文を受け取り、リクエスト・キー値を返すODBCプロシージャ。

このプロシージャの構文を次に示します。
```
SAGetSharedRequestKey('sql-string-literal')
```

リクエスト・キーの値は、次の要因の影響を受けます。

リポジトリ物理データベース・オブジェクトで「仮想プライベート・データベース」オプションが選択されているかどうか
セッション変数がリポジトリ内で「セキュリティ・センシティブ」としてマークされているかどうか

プレゼンテーション・サービスは、仮想プライベート・データベースとしてマークされているデータベース・オブジェクトに対して、論理リクエストのリクエスト・キーを計算するときに、セキュリティ・センシティブな変数を考慮します。

「Oracle BIプレゼンテーション・サービス・キャッシュ設定の管理」を参照してください。

結果レコードについて

キャッシュをパージするコマンドを実行すると、結果レコードが返されます。

結果レコードには、2つの列が含まれています。最初の列は結果コードで、2番目の列は、パージ操作の結果を説明する短いメッセージです。次の表は、結果レコードの例を示しています。

結果コード	結果メッセージ
1	SAPurgeCacheByDatabaseが正常終了しました。
59115	キャッシュが有効でないため、操作は実行されませんでした。
59116	指定されたデータベースが存在しません。
59117	指定された表が存在しません。

SAP/BWデータソースのキャッシュの保存とパージ

Microsoft Analysis ServicesとSAP/BWのデータ・ソースでは命名規則が異なるため、メンバーの一意の名前を格納するためのキャッシュ・サブシステムがあります。

Microsoft Analysis Servicesでは、メンバーのキャプション名は、メンバーの一意の名前と同じです。しかし、SAP/BWデータソースでは、メンバーのキャプション名とメンバーの一意の名前は異なります。したがって、Oracle BIサーバーでは、SAP/BWメンバーの一意の名前でキャッシュ・サブシステムを保持します。このサブシステムは、デフォルトでは無効です。構成情報については、「構成ファイル設定」のMDX Member Name Cacheセクションに関する項を参照してください。

メンバーの一意の名前で問合せを受信すると、サブシステムはキャッシュを確認して、この問合せに対するキャッシュの有無を判断します。キャッシュが存在する場合、キャッシュされている一意の名前のレコードが返されます。問合せに一致するキャッシュがない場合は、SAP/BWにプロービング問合せが送信されます。

プロービング問合せは、ログ・レベルが2以上の場合にロギングされます。サーバー・ログには、サブシステムが有効かどうかといったサブシステムの状態と、開始イベントや停止イベントなどのイベントも書き込まれます。

注意:

ログ・レベルが上がるごとに、パフォーマンスに影響が及びます。ユーザーのログ・レベルを上げる際は、注意してください。

キャッシュのパージに関して、次の点に留意してください。

多次元キャッシュ・エントリのサイズは、非常に大きくなる可能性があります。したがって、NQSConfig.INIファイルのMDX_MEMBER_CACHEセクションで、各メンバー・セットのサイズの制限が設定されています。
アップグレードの後、保持されているキャッシュの形式が一貫しているとはかぎりません。このため、ソフトウェアのアップグレードの前に、すべてのキャッシュをパージします。
問合せを初めて実行するときに、キャッシュが移入されます。パフォーマンスへの影響を最小限にするために、オフピーク時にキャッシュを移入するように調整してください。

注意:
管理ツールでは、キューブ表を右クリックし、「メンバー・キャッシュのパージ」を選択することによって、個々のキューブ表のキャッシュをパージできます。これは、管理者権限を持つユーザーがオンライン・モードで実行する必要があります。

次のパージ・プロシージャは、SAP/BWデータソースに固有のものです。

SAPurgeALLMCNCache。すべてのSAP/BWキャッシュ・エントリをパージします。

このプロシージャの構文を次に示します。
```
SAPurgeALLIMCNCache ()
```
SAPurgeMCNCacheByCube。指定された物理キューブに関連するすべてのキャッシュ・エントリをパージします。データベース名とキューブ名は、リポジトリ・オブジェクトの外部名です。このプロシージャの構文を次に示します。
```
SAPurgeMCNCacheByCube( 'DBName', 'CubeName')
```

次の表は、返されるメッセージを示しています。

リターン・コード	戻りメッセージ
1	SAPurgeALLMCNCacheが正常終了しました。
1	SAPurgeMCNCacheByCubeが正常終了しました。
59116	指定されたデータベースが存在しません。データベースと物理キューブの両方が間違っている場合に、この結果コードが返されます。
85025	指定された物理キューブが存在しません。

管理権限を持つユーザーのみが、ODBCパージ・プロシージャを実行できます。

リポジトリの変更が問合せキャッシュに及ぼす影響

Oracle Business Intelligenceリポジトリを変更すると、その変更が、キャッシュに保存されているエントリに影響することがあります。たとえば、物理オブジェクトや動的リポジトリ変数の定義を変更すると、そのオブジェクトや変数を参照しているキャッシュ・エントリが有効でなくなる場合があります。このような変更によって、キャッシュをパージする必要が生じる可能性があります。注意を要する3つのシナリオがあります。オンライン・モードで変更が行われる場合、オフライン・モードで変更が行われる場合およびリポジトリ間を切り替えている場合です。

オンライン・モード

オンライン・モードでOracle Business Intelligenceリポジトリを変更する場合、その変更がキャッシュ・エントリに影響するものであれば、変更されたオブジェクトを参照するすべてのキャッシュ・エントリが自動的にパージされます。パージは、変更をチェックインするときに発生します。たとえば、リポジトリから物理表を削除すると、その表を参照しているすべてのキャッシュ・エントリが、チェックイン時にパージされます。ビジネス・モデルとマッピング・レイヤー内でのビジネス・モデルへの変更によって、そのビジネス・モデルのキャッシュ・エントリがすべてパージされます。

オフライン・モード

オフライン・モードでOracle Business Intelligenceリポジトリを変更する場合、キャッシュに保存されている問合せに影響する変更を行い、キャッシュされた結果が古くなる可能性があります。オフライン・モードの編集時にサーバーはリポジトリをロードしないため、行われた変更がキャッシュ・エントリに影響するかどうかを判断できません。このため、オフラインでの変更の後、サーバーによってキャッシュが自動的にパージされることはありません。キャッシュをパージしないと、リポジトリが次にロードされたときに、無効なエントリが存在する可能性があります。オフラインでの変更の影響を受けるエントリがキャッシュに存在しないことが確実な場合を除いて、変更したビジネス・モデルのキャッシュをパージします。

リポジトリ間の切替え

Oracle BIサーバーの構成からリポジトリを削除する予定の場合は、リポジトリを参照するすべてのキャッシュ・エントリのキャッシュをパージする必要があります。パージしないと、キャッシュが損傷します。「管理ツールでのキャッシュのパージ」を参照してください。

動的リポジトリ変数の変更

動的リポジトリ変数の値は、問合せから返されるデータでリフレッシュされます。動的リポジトリ変数を定義する際には、初期化ブロックを作成するか、SQL問合せが含まれる既存の初期化ブロックを使用します。問合せを実行し、変数の値を定期的にリフレッシュする、Oracle BIサーバーのスケジュールも構成します。

動的リポジトリ変数の値が変更されると、列でこの変数を使用するBIサーバーのキャッシュ・エントリが失効し、そのエントリのデータが再び必要となったときに、新しいキャッシュ・エントリが生成されます。古いキャッシュ・エントリはすぐに削除されず、通常のキャッシュ・メカニズムによって消去されるまでそのまま残ります。