1. Oracle Analytics Serverの管理
  2. 高可用性とパフォーマンスのためのスケーリングおよびデプロイ
  3. パフォーマンス・チューニングと問合せキャッシングの管理
  4. データソース・キャッシュの構成

データソース・キャッシュの構成

データ・ブレンドのパフォーマンスを高めるには、データソース・キャッシュを構成する必要があります。これは、データベースを使用するか、またはファイル・システム上で実行できます。

ファイル・システムでのデータソース・キャッシュの作成

BIサーバーによる直接アクセスのために、データソース・キャッシュのデータをファイル・システムに格納できます。これはデフォルトの構成です。これは、アップロードしたスプレッドシート・ファイルなど、小規模から中規模のデータソースに適しています。大規模なデータソースの場合は、データソース・キャッシュをデータベースに構成すると、より優れたパフォーマンスを得られます。

ファイル・システムベースのデータソース・キャッシュは、次のように機能します。

  1. BIサーバーがデータソースに対する論理SQL文を受け取ります。

  2. BIサーバーはデータソースのメタデータを取得します。メタデータの内容を使用して、BIサーバーは、データソースのデータをリクエストするかわりに、問合せへの応答に使用可能な既存のデータソース・キャッシュ・エントリが存在するかどうかをチェックします。

  3. いずれのデータソースにも既存のデータソース・キャッシュ・エントリがない場合、BIサーバーは、データソースのデータをキャッシュにロードするスレッドを開始します。

  4. 論理SQL文(および同じデータソースのデータを要求する他のすべての同時論理SQL文)は、スレッドの終了を待機します。

  5. スレッドの実行が完了すると、新たにシードされたデータソース・キャッシュ・エントリに依存するすべてのサブリクエストでこのキャッシュが使用されます。

ファイル・システムでデータソース・キャッシュを構成します。

  1. NQSConfig.INIファイルのXSA_CACHEセクションを次のように変更します。
    [XSA_CACHE]
ENABLE = YES;

# The schema and connection pool where the XSA data is cached. 
# Set PHYSICAL_SCHEMA to ""."" to use file-based XSA cache. 
# This indicates that a file-based XSA cache should be used by BI Server and the value of the CONNECTION_POOL parameter should be ignored.
PHYSICAL_SCHEMA = "".""; # "<Database>"."<Schema>"; 
CONNECTION_POOL = "".""; # "<Database>"."<Connection Pool>";

# The path to the location where cache data files is persisted. 
# This is only used if file-based XSA cache is configured. 
# If a relative path is specified, it is relative to: 
# BI_DOMAIN/servers/obisn 
STORAGE_DIRECTORY = "storage"; # location where the cache data files are stored

# The maximum space allocated in the schema for the cache data.
MAX_TOTAL_SPACE = 5 GB;

# The maximum size allowed for a single XSA cache entry. 
MAX_CACHE_ENTRY_SIZE = 200 MB;

# The path to the location where descriptor files of the cache data is persisted. 
# If a relative path is specified, it is relative to: 
# BI_DOMAIN/servers/obisn 
DESCRIPTOR_STORAGE_PATH = "xsacache"; # location where the cache metadata files are stored

# The number of threads available for seeding XSA cache entries. 
CACHE_SEED_THREAD_RANGE = 0-40; 
CACHE_SEED_THREAD_STACK_SIZE = 0; # default is 256 KB (32 BIT mode), 1 MB (64 BIT mode), 0 for default

  2. BIサーバーを再起動します。

  3. データソース・キャッシュが正しく構成されていることを検証するには、obis1-diagnostic.logをチェックします。サーバー起動時に、次のようなエントリを探します。
    [2017-01-13T14:41:30.715-07:00] [OracleBIServerComponent] [NOTIFICATION:1] [] [] [ecid: ] [tid: 81c8] [101043] External Subject Area cache with internal storage is started successfully using configuration from the repository with the logical name Star.
[2011-01-13T14:41:30.716-07:00] [OracleBIServerComponent] [NOTIFICATION:1] [] [] [ecid: ] [tid: 81c8] [101017] External Subject Area cache has been initialized. Total number of entries: 0 Used space: 0 bytes Maximum space: 107374182400 bytes Remaining space: 107374182400 bytes. Cache table name prefix is XC.

データソース・キャッシュを有効にすると、NQSConfig.INIのXSA_CACHEセクションのSTORAGE_DIRECTORYパラメータの定義に従って、ファイル・システムにデータソースのデータが格納されます。メタデータは、NQSConfig.INIのXSA_CACHEセクションにあるDESCRIPTOR_STORAGE_PATHパラメータで指定された、ローカル・ファイル・システムのディレクトリに格納されます。パフォーマンスを向上させるには、データソースのデータおよびデータソース・キャッシュのメタデータ・ファイルをRAMディスクに配置します。

データベースでのデータソース・キャッシュの作成

大規模なデータソースの場合は、データソース・キャッシュをデータベースに構成すると、より優れたパフォーマンスを得られます。

データベース・ベースのデータソース・キャッシュは、次のように機能します。

  1. BIサーバーがデータソースに対する論理SQL文を受け取ります。

  2. BIサーバーはデータソースのメタデータを取得します。メタデータの内容を使用して、BIサーバーは、データソースのデータをリクエストするかわりに、問合せへの応答に使用可能な既存のデータソース・キャッシュ・エントリが存在するかどうかをチェックします。データソース・キャッシュを使用できるサブリクエストはすべて、キャッシュ・データベースのネイティブ物理SQLに再書込みされます。

  3. いずれのデータソースにも既存のデータソース・キャッシュ・エントリがない場合、BIサーバーは、データソースのデータをキャッシュ・データベースにロードするスレッドを開始します。各データソースは、データソースのすべての列を含む単一のデータベース表に変換されます。

  4. 論理SQL文(および同じデータソースのデータを要求する他のすべての同時論理SQL文)は、スレッドの終了を待機します。

  5. スレッドの実行が完了すると、新たにシードされたデータソース・キャッシュ・エントリに依存するすべてのサブリクエストが、キャッシュ・データベースのネイティブ物理SQLに再書込みされます。

サポートされている次の2つのデータソース・キャッシュ・データベース設定から選択できます。

データ・ウェアハウスとは異なるデータベースでのデータソース・キャッシュの構成

  1. キャッシュ・データベースを表す物理オブジェクトをリポジトリに作成します。これには、新規データベース・オブジェクト、新規物理スキーマ・オブジェクトおよび新規接続プールが含まれます。この例では、データベース・オブジェクトの名前はXSACache、接続プールの名前はCP、新規物理スキーマ・オブジェクトの名前はXSA_CACHEです。

    • 接続プールで使用されるユーザー名は、スキーマの名前と同じである必要があります。

    • 接続プールに指定されているユーザーは、スキーマ内の表に対してDDLおよびDMLを実行するために必要な権限を持っている必要があります。たとえば、Oracleでは、ユーザーは少なくともCREATE TABLE権限を持っている必要があります。

  2. NQSConfig.INIのXSA_CACHEセクションにあるパラメータを、適切なスキーマおよび接続プールを指し示すように更新します。 

    [XSA_CACHE]
ENABLE = YES;

# The schema and connection pool where the XSA data is cached. 
# Set PHYSICAL_SCHEMA to ""."" to use file-based XSA cache. 
PHYSICAL_SCHEMA = "XSACache"."XSA_CACHE"; # "<Database>"."<Schema>"; 
CONNECTION_POOL = "XSACache"."CP"; # "<Database>"."<Connection Pool>";

# The path to the location where descriptor files of the cache data is persisted. 
# If a relative path is specified, it is relative to: 
# BI_DOMAIN/servers/obisn 
DESCRIPTOR_STORAGE_PATH = "xsacache"; # location where the cache metadata files are stored

  3. BIサーバーを再起動します。

  4. データソース・キャッシュが正しく構成されていることを検証するには、obis1-diagnostic.logをチェックします。サーバー起動時に、次のようなエントリを探します。
    [2017-01-13T14:41:30.715-07:00] [OracleBIServerComponent] [NOTIFICATION:1] [] [] [ecid: ] [tid: 81c8] [101001] External Subject Area cache is started successfully using configuration from the repository with the logical name Star.
[2011-01-13T14:41:30.716-07:00] [OracleBIServerComponent] [NOTIFICATION:1] [] [] [ecid: ] [tid: 81c8] [101017] External Subject Area cache has been initialized. Total number of entries: 0 Used space: 0 bytes Maximum space: 107374182400 bytes Remaining space: 107374182400 bytes. Cache table name prefix is XC2627531314.

データソース・キャッシュを有効にすると、データソースのデータがデータベースに格納されます。ただし、メタデータは、NQSConfig.INIのXSA_CACHEセクションにあるDESCRIPTOR_STORAGE_PATHパラメータで指定された、ローカル・ファイル・システムのディレクトリに格納されます。パフォーマンスを向上させるには、データソース・キャッシュのメタデータ・ファイルをRAMディスクに配置します。

データ・ウェアハウスと同じデータベースでのデータソース・キャッシュの構成

この構成により、結合がBIサーバーによって内部的に実行されるのではなく、データソースにプッシュ・ダウンされるため、問合せパフォーマンスが向上します。

  1. キャッシュ・データベースを表す物理オブジェクトをデータ・ウェアハウス・データベース・オブジェクトのリポジトリに作成します。これには、新規物理スキーマ・オブジェクトおよび新規接続プールが含まれます。この例では、新規接続プールの名前はXSA Cache Connection Poolで、物理スキーマ・オブジェクトの名前はXSA_CACHEです。

    アプローチとしては、データ・ウェアハウスの接続プールで、別のスキーマに作成されたデータソース・キャッシュ表に問合せを実行できるようにしながら、データソース・キャッシュのシードおよびパージ専用の接続プールを設定します。管理を単純化するには、データソース・キャッシュ・スキーマに専用の表領域を設定することが理想的です。

    • 新規接続プールで使用されるユーザー名は、新規スキーマの名前と同じである必要があります。

    • 新規接続プールに指定されているユーザーは、新規スキーマ内の表に対してDDLおよびDMLを実行するために必要な権限を持っている必要があります。たとえば、Oracleでは、ユーザーは少なくともCREATE TABLE権限を持っている必要があります。

    • 元のデータ・ウェアハウス接続プールに指定されているユーザーは、新規スキーマ内の表のSELECTに必要な権限を持っている必要があります。たとえば、Oracleでは、既存のデータ・ウェアハウス接続プールのユーザーは少なくともSELECT ANY TABLE権限を持っている必要があります。

    • データソース・キャッシュ接続プールをデータベース・オブジェクトのプライマリ接続プールにしないでください。つまり、データソース・キャッシュ接続プールは、データ・ウェアハウスの問合せに使用されるデータ・ウェアハウス接続プールの後に配置されている必要があります。

  2. NQSConfig.INIのXSA_CACHEセクションにあるパラメータを、適切なスキーマおよび接続プールを指し示すように更新します。 

    [XSA_CACHE]
ENABLE = YES;

# The schema and connection pool where the XSA data is cached. 
# Set PHYSICAL_SCHEMA to ""."" to use file-based XSA cache. 
PHYSICAL_SCHEMA = "Oracle Data Warehouse"."Catalog"."XSA_CACHE"; # "<Database>"."<Schema>"; 
CONNECTION_POOL = "Oracle Data Warehouse"."XSA Cache Connection Pool"; # "<Database>"."<Connection Pool>";

# The path to the location where descriptor files of the cache data is persisted. 
# If a relative path is specified, it is relative to: 
# BI_DOMAIN/servers/obisn 
DESCRIPTOR_STORAGE_PATH = "xsacache"; # location where the cache metadata files are stored

  3. BIサーバーを再起動します。

  4. データソース・キャッシュが正しく構成されていることを検証するには、obis1-diagnostic.logをチェックします。サーバー起動時に、次のようなエントリを探します。
    [2017-01-13T14:41:30.715-07:00] [OracleBIServerComponent] [NOTIFICATION:1] [] [] [ecid: ] [tid: 81c8] [101001] External Subject Area cache is started successfully using configuration from the repository with the logical name Star.
[2011-01-13T14:41:30.716-07:00] [OracleBIServerComponent] [NOTIFICATION:1] [] [] [ecid: ] [tid: 81c8] [101017] External Subject Area cache has been initialized. Total number of entries: 0 Used space: 0 bytes Maximum space: 107374182400 bytes Remaining space: 107374182400 bytes. Cache table name prefix is XC2627531314.

データソース・キャッシュを有効にすると、アップロードされたファイルのデータがデータベースに格納されます。ただし、メタデータは、NQSConfig.INIのXSA_CACHEセクションにあるDESCRIPTOR_STORAGE_PATHパラメータで指定された、ローカル・ファイル・システムのディレクトリに格納されます。パフォーマンスを向上させるには、データソース・キャッシュのメタデータ・ファイルをRAMディスクに配置することをお薦めします。

データソース・キャッシュの管理

データソース・キャッシュを有効にした後で、個々のキャッシュ・エントリまたはキャッシュ全体の削除が必要になることがあります。

データソース・キャッシュ・エントリの削除

Oracle BIサーバーには、キャッシュ・エントリをパージするためのODBC拡張関数があります。ストアド・プロシージャの書式は、次のとおりです。
call SAPurgeXSACache('<XSA_PATH>', '<XSA_TABLE>');

<XSA_PATH>は、データソース定義へのパスです。これは、論理SQL内のXSA()句で使用される値です。このパラメータではワイルドカード文字%もサポートされており、これを使用してシステム内のすべてのデータソース・キャッシュ・エントリをパージできます。

<XSA_TABLE>は、データソース内の表の名前です。これは、論理SQL内のXSA()句の後に続く値です。このパラメータではワイルドカード文字%もサポートされており、これを使用してデータソース定義内のすべての表のキャッシュ・エントリをパージできます。

たとえば、データソース・キャッシュ・エントリが、SELECT XSA('weblogic'.'Sample Order Lines')."Columns"."Product Category" FROM XSA('weblogic'.'Sample Order Lines')という問合せを使用して生成されているとします。

  • データソース・キャッシュ・エントリをパージするには、call SAPurgeXSACache('''weblogic''.''Sample Order Lines''', 'Columns');を使用します

  • システム内のすべてのデータソース・キャッシュ・エントリをパージするには、call SAPurgeXSACache('%', '%');を使用します

ファイル・システムでのキャッシュの手動クリーン・アップ

データソース・キャッシュ・エントリを手動で削除するには、次のステップを使用します。

  1. BIサーバーを停止します。

  2. NQSConfig.INIのXSA_CACHEセクションにあるDESCRIPTOR_STORAGE_PATHおよびSTORAGE_DIRECTORYパラメータで指定されているディレクトリ内のファイルを削除します。

データベース内のキャッシュの手動クリーンアップ

次の理由により、データソース・キャッシュ・スキーマにあるすべての表の削除が必要になることがあります。

  • 古いインストールを置き換える新しいBIサーバーのインストールで使用される既存スキーマをクリーンアップするため。

  • メンテナンスによるダウンタイム中に、白紙の状態でのデータソース・キャッシュを開始するため。

キャッシュを消去するには:

  1. このスキーマを使用するBIサーバーが実行されていないことを確認します。表を削除するときにこのようなサーバーが実行されていると、これらのサーバーが不整合な状態で残り、結果として、これらのサーバーが再起動されるまで、表が見つからないというエラーによりデータソースの問合せが失敗します。

  2. SQLクライアントから、データソース・キャッシュ・スキーマのユーザーとしてデータベースにログインします。

  3. 次のPL/SQLを実行します。
    BEGIN  
FOR i IN (SELECT table_name FROM user_tables where table_name like 'XC%')  
LOOP  
EXECUTE IMMEDIATE('DROP TABLE ' || user || '.' || i.table_name || ' CASCADE CONSTRAINTS PURGE');  
END LOOP;  
END;
    データソース・キャッシュの表の名前は、先頭にXCが付くことに注意してください。

  4. NQSConfig.INIのXSA_CACHEセクションにあるDESCRIPTOR_STORAGE_PATHパラメータで指定されているディレクトリ内のファイルを削除します。