ヘッダーをスキップ
Oracle® Business Intelligence Applications Informatica PowerCenterユーザーのためのインストレーション・ガイド
リリース7.9.6.3
B66690-01
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

3 Oracle BI Applicationsのインストール前要件と配置要件


注意:

データベース・プラットフォームとソース・システムに関する情報の一部には、今回のリリースのOracle Business Intelligence Applicationsに適用されないものがあります。今回のリリースのOracle Business Intelligence Applicationsでサポートされているデータベースとソース・システムの最新情報は、『Oracle Business Intelligence Applicationsシステム要件およびサポートされるプラットフォーム』を参照してください。必ず、『Oracle Business Intelligence Applicationsリリース・ノート』も参照してください。また、これらのドキュメントの最新版はOracle Technology Network(http://www.oracle.com/technology/documentation/bi_apps.html)にあります。Oracle Technology Networkの無料アカウントを登録するには、http://www.oracle.com/technetwork/index.htmlにアクセスしてください。

この項では、Oracle BI Applicationsをインストールして配置するための準備について説明します。インストールと配置のプロセスを開始する前に、この章の説明を確認しておいてください。Oracle Business Analytics Warehouseの設定に関する一般的なガイドライン、および使用するソースOLTPデータベースに対応するデータベース固有ガイドラインも参照してください。

また、第4.3項「必須要件」で指定されているデータベース要件とInformatica PowerCenter要件を満たしていることを確認する必要があります。

備考

この項は、次の項目を含んでいます。

3.1 Oracle Business Analytics Warehouseの設定に関する一般的なガイドライン

Oracle Business Analytics Warehouseは、次元スキーマを持つデータベースです。Oracle Business Analytics Warehouseをトランザクション・データベースと同じデータベースに配置することは技術的には可能ですが、パフォーマンス上の理由からお薦めできません。トランザクション・データベースはオンライン・トランザクション処理(OLTP)データベースとして構造化されますが、Oracle Business Analytics Warehouseはオンライン分析処理(OLAP)データベースとして構造化され、それぞれが独自の目的に合せて最適化されます。この2つのデータベースが結合されない理由は、次のとおりです。

Informaticaリポジトリには、Oracle Business Analytics Warehouseを移入するETLマッピングのオブジェクト定義のすべてが格納されます。データベースに格納されるのは一連のリポジトリ・テーブルで、トランザクション・データベース、分析データベースまたは別のデータベースにできます。

Oracle Business Analytics Warehouseは、リレーショナル・データベース管理システムと連携します。使用するDBMSによっては、一般的な要件に加えて、データベース管理システム(DBMS)固有の要件が発生します。

次に示す一般的なガイドラインは、パフォーマンスと拡張に対応するようにデータ・ウェアハウスの物理データベースを設定する際に役立ちます。

Oracle Business Analytics Warehouseの構成プロセスで、第4.9.1項「データ・ウェアハウス・テーブルの作成」の手順に従ってデータ・ウェアハウス・テーブルを作成する際に、テーブルとインデックスを別々の表領域に作成できます。ただし、パフォーマンス上の理由から、表領域は表3-1で説明されているように作成することをお薦めします。

表3-1 推奨される表領域の構成

表領域名 表一覧

DIM_STG

W_*DS

FACT_STG

W_*FS

DIM

W_*DおよびW_*MD

FACT

W_*F

AGG

W_*A

OTHER

残りのW*テーブル

DIM_INDX

W_*Dテーブルのインデックス

(たとえば、他のテーブルにはW*GテーブルやW*GSテーブルが含まれます)

FACT_INDX

W_*Fテーブルのインデックス

OTHER_INDX

W*テーブルの残りのインデックス


注意:

ETL実行時に致命的なデッドロックが発生しないように、必ずInformaticaで「Session Level Retry on Deadlock」オプションを選択してください。

3.2 Oracle Business Analytics WarehouseのIBM DB2 UDB固有のデータベースのガイドライン

表3-2に、DB2リレーショナル・データベース管理システム(RDBMS)を使用する際のパラメータ設定に関するガイドラインを示します。このガイドラインはベースとして使用してください。具体的なデータベース・サイズ、データ・シェイプ、サーバー・サイズ(CPUとメモリ)およびストレージ・タイプを基に、変更を加える必要があります。データベース管理者は、パフォーマンスの監視とチューニングに関する考慮事項に基づいて、設定に変更を加える必要があります。

表3-2 推奨されるDB2パラメータの設定

パラメータ DB2 UDB V7 DB2 UDB V8 and V9 備考

SHEAPTHRES

400000

400000

ASLHEAPSZ

15

15

RQRIOBLK

65535

65535

QUERY_HEAP_SZ

16384

16384

JAVA_HEAP_SZ

2048

2048

MAXAGENTS

400

400

NUM_INITAGENTS

10

10

NUM_POOLAGENTS

200

200

INTRA_PARALLEL

YES

YES

FCM_NUM_BUFFERS

12288

12288

SHEAPTHRES_SHR

なし

=SHEAPTHRES

DBHEAP

16384

16384

CATALOGCACHE_SZ

5558

5558

LOGBUFSZ

2048

2048

UTIL_HEAP_SZ

10000

10000

NUM_ESTORE_SEGS

16

NIL

V7ではアドレス可能なメモリが1.75GBに制限されていますが、この制限が撤廃されたDB2 V8 64ビットではリストアが不要です。

ESTORE_SEG_SZ

65536

NIL

LOCKLIST

25000

25000

APP_CTL_HEAP_SZ

5000

5000

SORTHEAP

4000

4000

STMTHEAP

40960

40960

APPLHEAPSZ

2560

2560

PCKCACHESZ

2560

2560

STAT_HEAP_SZ

20000

20000

DLCHKTIME

10000

10000

MAXLOCKS

50

50

LOCKTIMEOUT

1200

1200

MAXAPPLS

500

500

AVG_APPLS

10

10

MAXFILOP

500

500

GROUPHEAP_RATIO

なし

70

V8で導入

APPGROUP_MEM_SZ

なし

30000

V8で導入

DATABASE_MEMORY

なし

AUTOMATIC

V8で導入


注意:

ETL実行時に致命的なデッドロックが発生しないように、必ずInformaticaで「Session Level Retry on Deadlock」オプションを選択してください。

3.3 IBM DB2 UDB zOSおよびOS/390、またOracle Business Analytics WarehouseのzOS固有のデータベースのガイドライン

zOSおよびOS/390にIBM DB2 RDBMSを使用する場合は、次の要件が適用されます。

表3-3 IBM DB2 UDB zOSおよびOS/390データベース向けの変数設定

パラメータ 推奨される設定 備考

IDTHTOIN

1800

CDSSRDEF

任意

STARJOIN

1

この設定は、スター型結合が有効になっていることを示します。カーディナリティが最大である1つのテーブルが、要素テーブルです。ただし、このカーディナリティのテーブルが複数あると、スター型結合は有効となりません。

3.4 Oracle Business Analytics WarehouseのSQL Server固有のデータベースのガイドライン

この項では、SQL Serverデータベースの使用方法に関するガイドラインを示します。


注意:

SQL Serverデータベースは、バイナリ・ソート順序または大文字と小文字を区別するディクショナリ・ソート順序をサポートする照合順序を使用して作成する必要があります。大文字と小文字を区別しないディクショナリ・ソート順序はサポートされていません。たとえば、米国英語キャラクタ・セットでのバイナリ・ソート順序には、Latin1_General_BINという照合を使用します。デフォルトの照合設定であるSQL_Latin1_General_CP1_CI_ASを使用すると、データベースが大文字と小文字を区別しないように設定され、これがサポートされていないためにインデックスの作成が失敗します。

この項は、次の項を含んでいます。

3.4.1 ANSI NULLオプションの設定

Oracle BI Applicationsでは、SQL Serverデータベースを作成する際にANSI NULLオプションを選択する必要があります。

ANSI NULLオプションを設定するには:

  1. SQL Server Enterprise Managerで、適切なデータベースを右クリックし、「Properties」を選択します。

  2. 「Options」タブをクリックし、「ANSI NULL default」のボックスを選択します。

3.4.2 DBライブラリ・オプションの設定の変更

SQL Server 2000の環境では、Oracle BI Applicationsテーブルに各国対応データをロードする際、または複数の言語をロードする際、DBライブラリ・オプションの設定を変更する必要があります。

DBライブラリ・オプションの設定を変更するには:

  1. Microsoft SQL Serverのプログラム・メニューで、「Client Network Utility」を選択します。

  2. 「DB Library Options」タブを選択します。

  3. 「Automatic ANSI to OEM」オプションの選択を解除します。


    注意:

    SQL Server 2000では、サーバー構成オプションの多くが自動的に調整されるので、管理者が調整を行う必要はほとんどありません。構成オプションは変更可能ですが、一般には、それらのオプションをデフォルト値のままにして、SQL Serverが実行時の状況に応じて自動的に調整されるようにすることをお薦めします。

3.4.3 推奨されるSQL Serverデータベース・パラメータ

必要に応じて、SQL Serverコンポーネントを表3-4のように構成してパフォーマンスを最適化できます。

表3-4 SQL Serverデータベースの推奨される変数設定

パラメータ 推奨される設定 備考

affinity mask

0

allow updates

0

AWE enabled

0

C2 audit mode

0

cost threshold for parallelism

5

cursor threshold

–1

default full-text language

1033

default language

0

fill factor

95%

挿入集約型トランザクションの場合は、fill factorを90から95%に設定します。クエリーのパフォーマンスを高めるには、fill factorを95%または100%に設定します。

index create memory

1024KB

デフォルトは0です。

lightweight pooling

0

locks

0

max degree of parallelism

0

デフォルトは0です。これによって、並列性がオフになります。max degree of parallelismは0のままにする必要があります。これは、パラレル・プラン生成が使用されることを意味します。マルチ・スレッド・コンポーネント(EIMスレッドが複数ある場合など)を実行する場合、1(1つのプロセスのみ使用)に設定する必要があります。

max server memory

2000MB

デフォルトは2147483647です。

max text replication size

65536バイト

max worker threads

100

デフォルトは255です。

media retention

0

min memory per query

1024KB

min server memory

500MB

デフォルトは0です。

nested triggers

1

network packet size

8192バイト

デフォルトは4096です。

open objects

0

priority boost

0

query governor cost limit

0

CPU使用率が高い場合のみ、60に変更します。

query wait

–1秒

recovery interval

0分

remote access

1

remote login timeout

20秒

remote proc trans

0

remote query timeout

600秒

scan for startup procs

0

set working set size

0

two digit year cutoff

2049

user connections

0

user options

0

  • SQL Serverのメモリ: 使用できるメモリ容量が十分であることを確認します。

  • トランザクション・ログとTempDB: データベース・データのディスクとは別のディスクに配置します。

  • 完全ロード: データベースの完全復旧モデルです。

  • 増分(リフレッシュ)ロード: 完全復旧モデルを一括ログ復旧モデルに変更します。

3.5 Oracle Business Analytics WarehouseのTeradata固有のデータベースのガイドライン

この項では、Teradataの配置におけるパフォーマンスを最大化するために推奨ベスト・プラクティスとガイドラインを示します。内容は次のとおりです。

3.5.1 Teradataデータベースの必須JDBCドライバのインストール

データ・ウェアハウス管理コンソール(DAC)には、データベース接続のためのJDBCドライバが必要です。サポートされているデータベースと互換性のあるJDBCドライバのみ使用する必要があります。サポート対象データベースの詳細は、『Oracle Business Intelligence Applicationsシステム要件およびサポートされるプラットフォーム』を参照してください。JDBCドライバにはデータベースのバージョンごとに差異があるため、該当するデータベースに付属していたドライバを使用するか、該当するデータベース・バージョン用として動作保証されていることがわかっているドライバをデータベース・ベンダー・サイトからダウンロードして使用する必要があります。現在、データベース用のサード・パーティ製JDBCドライバはサポートされていません。

Unicode環境がTeradataデータベースにある場合、Teradata 12.0またはTeradata 13.0のTeradata JDBCドライバをインストールする必要があります。バージョン12以前のバージョンを含めて、すべてのサポート対象バージョンのTeradataデータベースでこのドライバが必要です。Teradata 12.0とTeradata 13.0のTeradata JDBCドライバは、「Teradata JDBC Driver」(http://www.teradata.com/DownloadCenter)で入手できます。

3.5.2 Teradataの配置に関する一般的なガイドライン

Teradataデータベースを使用する場合は、次の要件が適用されます。

  • デッドロック問題が発生した場合は、DAC内の特定グループで「Execute Serially」オプションを使用することをお薦めします。Teradataの場合、これは必須です。このオプションがタスク・グループで選択されている場合は、タスクを含む実行プランを再ビルドしてから実行する必要があります。

  • Informatica Serverがインストールされているマシンに、Teradata Parallel Data Pump (TPump) Teradataロード・ユーティリティをインストールします。

  • Informatica PowerCenterをインストールする場合は、Informatica Serverのディレクトリ名またはディレクトリ・パスにスペースが含まれていないことを確認します。デフォルト・ディレクトリに含まれているスペースは、手動で削除する必要があります。

  • Teradata環境にOracle BI Applicationsをインストールする場合は、事前に構築されたInformaticaリポジトリ・ファイルのOracle_BI_DW_Teradata.repをロードする必要があります。これはORACLE_HOME\biapps\dwrep\Informatica\Repositoryにあります。

  • スキーマを作成する前に、TeradataのODBC構成で、セッション・モードをANSIに、DateFormatをAAAにそれぞれ設定します。テーブルは、ケース固有として作成する必要があります。スキーマを作成した後にこのODBC構成を行うと、テーブルがケース固有として作成されない場合があります。

  • 算術計算に18,3(精度、スケール)を超える小数データ型が関係する場合は、オーバーフローが発生しないように、次の静的なソース・システム・パラメータを追加します。

    • $$Hint_Tera_Post_Cast = "as Decimal(18,3))"

    • $$Hint_Tera_Pre_Cast = "Cast("

    DACでのソース・システム・パラメータの設定の詳細は、第4.18.2項「DACソース・システム・パラメータの設定」を参照してください。

  • Informaticaのserver/binディレクトリにreswords.txtファイルをインストールします。reswords.txtファイルを構成する場合、次の点に注意してください。

    テーブル名や列名にデータベース予約語(MONTHやYEARなど)があると、Informatica統合サービスでデータベースに対してSQLを実行すたときに、データベース・エラーが発生してセッションは失敗します。予約語ファイルのreswords.txtを作成してserver/binディレクトリに保持できます。統合サービスでセッションを初期化するときには、reswords.txtが検索されます。ファイルが存在している場合には、データベースに対してSQLを実行する際に、統合サービスによって、一致した予約語が引用符で囲まれます。

    予約語で作業する際、次のルールとガイドラインを使用します。

    • 統合サービスは、SQLを生成して、ソース、ターゲットおよび検索のデータベースに接続すると、予約語ファイルを検索します。

    • ソース、ターゲットおよび検索のSQLよりも優先する場合、予約語を引用符で囲む必要があります。

    • 引用符で囲まれた識別子に関するSQL-92規格を使用するために、SQL Serverなどのデータベースを有効にすることが必要になる場合があります。接続環境SQLを使用して、コマンドを発行します。

      たとえば、SET QUOTED_IDENTIFIER ONコマンドを、サンプルreswords.txtファイルに対してSQL Serverで使用します。

    予約語ファイルを使用するには、reswords.txtという名前のファイルを作成して、server/binディレクトリに格納します。データベースごとに、予約語の格納に必要なセクションを作成します。テーブルや列の名前で使用される予約語を追加します。データベースにおけるすべての予約語をこのファイルに格納する必要はありません。reswords.txtの予約語とデータベース名では大文字と小文字は区別されません。

    サンプルのreswords.txtファイルは次のとおりです。

    [Teradata]
MONTH
DATE
INTERVAL

注意:

ETLプロセス実行時に致命的なデッドロックが発生しないように、必ずInformaticaで「Session Level Retry on Deadlock」オプションを選択してください。

3.5.3 Teradataの配置に関するベスト・プラクティス

この項では、Teradataの配置におけるパフォーマンスを最大化するために推奨されているベスト・プラクティスを示します。この項の内容は次のとおりです。

3.5.3.1 前提条件としての統計収集

ステージング・データベースおよびターゲット・データベースにテーブルが作成されたら、指定された統計収集を実行する必要があります。これに失敗すると、ETLのパフォーマンスに影響し、スプール領域エラー(エラー番号2646)が発生する可能性があります。

DACでは、ETLプロセスの一環として統計が再収集されます。ただし、DACではテーブル・レベルで統計収集ステートメントが発行され(たとえばw_org_dで統計を収集)、その対象は既存の統計に限られます。

3.5.3.2 左側外部結合の問題

Teradataコードのパフォーマンスは、各インストールの具体的な環境に大きく依存します。結合を伴う列で単一値(NULLかどうか)や少ない値の出現数が多いと、Teradata AMPにおいてデータに偏りが発生する場合があります。この影響としては、AMPごとのスプール制限を超過する可能性が高くなり、あるAMPでCPU使用率が上昇しながら、別のAMPでは偏りが発生する問合せで使用率が低くなることがあります。これによってこの問合せの処理時間が長くなり、偏りが発生するAMPでCPUリソースが競合するシステムにおいて他の問合せに悪影響が及びます。

環境によっては、現在のコードにより外部テーブルに結合キーで再分散できます。ただし、内部テーブルが小さい場合は除きます。Teradata Optimizerにより、内部テーブルをすべてのAMPにコピーして、外部テーブルに再分散しない場合があります。外部キーにNULLなどの値が多すぎると、結合操作中にTeradataでデータに偏りが発生します。これが発生した場合、関係するテーブルで統計が定義され収集されたことを確認してください。すべての必要な統計が定義され最近収集されていると、SQLの再記述が必要になる場合があります。

要素SILマッピングの多くは、ROW_ID/INTEGRATION_IDから次元ROW_WIDを取得する必要があります。たとえば、W_PER_RANK_FS.ACCNT_IDは、W_PER_RANK_Fテーブルにロードする前にACCNT_WIDに変換する必要があります。ACCT_IDはNULL値可能であるため、W_PER_RANK_FSとW_ORG_Dの結合は左側外部結合として定義されます。

ただし、データセットによっては、ACCT_IDカラムでのNULLの割合が50%以上になることがあります。ACCT_IDに従ってW_PER_RANK_FSを再分散すると、ACCT_ID = NULLであるすべての行が1つのAMPに格納されます。

通常、Teradataデータベースには数百ギガバイトのスプール領域が確保されていますが、このスプール領域は何百ものAMPに割り当てられます。各AMPのスプール領域は制限されています(たとえば上限が2ギガバイトなど)。

W_PER_RANK_FSの大部分が1つのAMPに割り当てられると、十分なスプール領域を確保できなくなることがあります。この状況は、スプール領域が小さすぎるために発生するのではなく、1つのAMPにスプールされるデータが多すぎる場合に発生します。

Teradataでのパラレル処理および左側外部結合解決のメカニズムを使用するには、SQLを記述しなおす必要があります。

たとえば、元のSQLが次のように記述されていたとします。

SELECT ...  FROM 
 W_PER_RANK_FS FS LEFT OUTER JOIN  W_ORG_D ORG ON
   FS.ACCNT_ID = ORG.INTEGRATION_ID  AND
   FS.DATASOURCE_NUM_ID = ORG.DATASOURCE_NUM_ID

前述のSQLは、次のSQL例で示すように、均等に分散されているのに一致していない複数の値へNULLを変換するように再コードします。

SELECT ... FROM
 W_PER_RANK_FS FS LEFT OUTER JOIN  
   (SELECT
   FS.INTEGRATION_ID, FS.DATASOURCE_NUM_ID, ORG.ROW_WID, ORG.GEO_WID
    FROM
   W_PER_RANK_FS FS, W_ORG_D ORG
   WHERE
   FS.ACCNT_ID = ORG.INTEGRATION_ID AND FS.DATASOURCE_NUM_ID = 
   ORG.DATASOURCE_NUM_ID AND FS.ACCNT_ID IS NOT NULL)
ORG  ON
   FS.DATASOURCE_NUM_ID = ORG.DATASOURCE_NUM_I AND
   FS.INTEGRATION_ID = ORG.INTEGRATION_ID

スプール領域の問題が発生している他のソース修飾子にも、同じようにSQLを再コーディングする方法を使用できます。

3.5.3.3 Group ByとDistinctの違い

固有値の数が少ない場合は、GROUP BY句を使用した方が効率的です。固有値の数が多い場合を除いて、DISTINCT句は使用しないでください。

3.5.3.4 マッピングとテーブルの削除

提供された事前構成済フィールドの一部を使用しない場合は、無関係のフィールドをマッピングとテーブルから除外することで、パフォーマンスが向上します。

3.5.3.5 ローダーの構成

この項では、Teradataで使用できるローダーと、Oracle Business Intelligence Applicationsでのその用途について説明します。

Teradataには、次の3種類のTeradataローダー・プロセスがあります。

各ローダー・プロセスは、次の2種類のモードで使用できます。

  • ステージ・モード: Informaticaプロセスによって、次の処理が上から順に実行されます。

    • ソース・データから読み取ります。

    • データ・ファイルを作成します。

    • ローダー・プロセスを起動して、作成したデータ・ファイルを使用してテーブルをロードします。

    長所: 障害が発生した場合に、Teradataリカバリ・プロセスを使用してリカバリできます。

    短所: ステージ・モードはパイプ・モードよりも時間がかかります。また、大きなデータ・ファイルを作成できるため、より大きなディスク領域が必要となります。

  • パイプ・モード: Informaticaプロセスによってソースからの読取りが行われ、同時にそのデータがローダーにパイプ処理されてターゲット・テーブルのロードが開始されます。

    長所: ステージ・モードよりも処理時間が短く、データ・ファイルが作成されないので大量のディスク領域を必要としません。

    短所: 障害が発生した場合に、Teradataリカバリ・プロセスを使用してリカバリできません(TPumpでは、FastLoadやMultiLoadとは異なり、行コミットが行われるため)。

3.5.3.5.1 Tpump

TPumpはデータ・ロード・ユーティリティで、Teradataデータベースにおいてデータの保守(更新、削除、挿入および原子アップサート)に役立ちます。TPumpによって、データ・ウェアハウスにおいてほぼリアルタイムでデータが処理できます。TPumpで標準のTeradata SQLを使用して、Teradataデータベースにおいて適度なデータ・ロード率から高いデータ・ロード率で処理されます。通常は、複数のセッションと複数文リクエストを使用して、スループットを向上させます。大半のロード・ユーティリティとは異なり、TPumpではテーブル・レベル・ロックではなく行ハッシュ・ロックを使用します。これによって、TPump実行中に問合せを実行できます。このことは、TPumpは即座に停止できることも意味します。

TPumpは次のモードで使用できます。

  • Tpump_Insert: 挿入を行う場合に使用します。

  • Tpump_Update: 更新を行う場合に使用します(このモードを使用するには、Informaticaのターゲット・テーブル定義でプライマリ・キーを定義する必要があります)。

  • Tpump_Upsert: 更新または更新の対象がなくて挿入を行う場合に使用します(このモードを使用するには、Informaticaのターゲット・テーブルの定義でプライマリ・キーを定義する必要があります)。

  • Tpump_Delete: 削除を行う場合に使用します(このモードを使用するには、Informaticaのターゲット・テーブル定義でプライマリ・キーを定義する必要があります)。

Informaticaでは、実際のターゲット・テーブル名を使用して、その制御ファイルの生成で使用するエラー・テーブルとログ・テーブルが生成されます。TPumpの2つのインスタンスが、同時に同じターゲット・テーブルへのロードを行う場合は、別々のエラー・テーブル名とログ・テーブル名を使用するようにセッションを変更する必要があります。

パイプ・モードのTPumpロード・プロセスは、増分ロードの際に、またテーブルにデータがある場合に役立ちます。エラーが発生した場合は、プロセスを再起動することで、最後にコミットされたデータからリロードが開始されます。

Teradataのローダーを使用するためのセッションの構成については、Informaticaのドキュメントを参照してください。

3.5.3.5.2 Fastload

Fastload External Loaderプロセスは、空のテーブルに対して使用します。たとえば、ステージング・テーブルをロードする場合や、テーブルが空である初期ロードの場合などです。Fastloadプロセスでロードを開始すると、ターゲット・テーブルをロックします。これは、プロセス(検索など)でそのテーブルにアクセスできないことを意味します。この問題の解決策としては、検索オーバーライド用に、ダミーのSQLをセッション・レベルで指定します。


ヒント:

Fastloadプロセスの実行中にセッションが失敗した場合は、SQL Assistantで単純なSQLコマンド(count(*)など)を実行して、テーブルがFastloadプロセスによってロックされていないかを確認します。

テーブル(W_ORG_DSなど)がロックされている場合は、次のスクリプトを使用してロックを解放します。

LOGON DATABASEALIAS/USER,PASSWORD
BEGIN LOADING USER.W_ORG_DS
ERRORFILES USER.ET_W_ORG_DS,USER.UV_W_ORG_DS;
END LOADING;

前述のテキストをtest.ctlというファイルに保存した場合、コマンド・プロンプトで次のコマンドを入力するとこのプロセスを実行できます。

C:\fastload\test.ctl

ヒント:

テーブルのロード・スクリプトを作成するには、前述のtest.ctlスクリプトを編集してログイン情報を変更し、W_ORG_DSの部分を必要なターゲット・テーブル名ですべて置き換えます。

ロード・プロセス・スクリプトが正常に実行されると、ターゲット・テーブルに対してselect count(*)コマンドを実行できるようになります。ロックを解放できない場合は、ロックを削除するためにテーブルの削除と再作成が必要になることがあります。これを行った場合は、統計を再作成する必要があります。


ヒント:

一般にFastLoadは、ステージング・テーブルのロードおよび初期ロードをパイプ・モードで行う場合に使用されます。エラーが発生した場合は、データ全体をリロードします。

3.6 Oracle Business Analytics WarehouseのOracle固有のデータベースのガイドライン

Business Analyticsデータ・ウェアハウスをOracleデータベースでより簡単に構成するには、パラメータ・テンプレート・ファイルのinit10gR2.oraとinit11g.oraを参照してください。これらのファイルは、<DRIVE>:\<Oracle BI Applications install directory>\dwrep\Documentation\にあります。

パラメータ・テンプレート・ファイルにより、Oracle 10gと11gのコストベース・オプティマイザに基づくパラメータ・ガイドラインが示されます。このガイドラインはベースとして使用してください。具体的なデータベース・サイズ、データ・シェイプ、サーバー・サイズ(CPUとメモリ)およびストレージ・タイプを基に、変更を加える必要があります。データベース管理者は、パフォーマンスの監視とチューニングに基づいて、この設定に変更を加える必要があります。

適切なテンプレート・ファイルを$ORACLE_HOME/dbsディレクトリにコピーします。そして、テンプレート・ファイルの推奨内容を確認して、特定のデータベース構成に基づいて変更を行います。データベース管理者は、パフォーマンスの監視とチューニングに関する考慮事項に基づいて、設定に変更を加える必要があります。


注意:

NLS_LENGTH_SEMANTICSパラメータにより、バイト長セマンティクスや文字長セマンティクスを定義できます。Oracle BI Applicationsでは、このパラメータにおいてBYTE値とCHAR値がサポートされています。MLS文字を使用する場合、このパラメータをinit10gR2.oraとinit11g.oraのファイルに追加できます。

3.7 Oracle Business Analytics WarehouseでのOracleデータベースのパフォーマンスを最適化するためのその他の提案

この項では、Oracleデータベースのパフォーマンスを最適化するためのその他の提案を示します。

3.8 大きな要素テーブルのパーティション化に関するガイドライン

この項では、パーティション化を使用してOracle BI Applicationsの配置でパフォーマンスを最大にする方法について説明します。内容は次のとおりです。

3.8.1 大きな要素テーブルのパーティション化の概要

範囲とコンポジット範囲-範囲パーティション化を要素テーブルで利用すると、ETLプロセス中のインデックスおよび統計のメンテナンス時間が短縮され、Web問合せパフォーマンスが向上します。大半の挿入と更新は最新のパーティションに影響を与えるので、影響のあるパーティションでのみローカル・インデックスを無効にしてから、無効にしたインデックスをロード後に再作成し、更新されたパーティションのみで統計を算出する必要があります。オンライン・レポートとダッシュボートでは、結果がより迅速にレンダリングされます。オプティマイザがパーティション化排除ロジックを使用して、より効率的な実行プランを構築するためです。

2000万行を超える大きな要素テーブルは、パーティション化に適している場合があります。最適なパーティション化テーブルを妥当なデータ分散で構築するには、月別、四半期別、年別などでパーティション化することを検討できます。初期ロード前にターゲット要素テーブルを特定してパーティション化するか、移入済テーブルをパーティション化オブジェクトに完全ロード後に変換できます。

パーティション化テーブルをOracle Business Analytics Data Warehouseでサポートするように実装するには、DACメタデータを更新して、ターゲット・データベース内のパーティション化テーブルに候補を手動で変換する必要があります。

パーティション化された要素テーブルを配置するには

  1. 大きな要素テーブルをパーティション化します。詳細は、第3.8.2項「大きな要素テーブルのパーティション化」を参照してください。

  2. パーティション化されたテーブルのETLをサポートするようにDACを構成します。詳細は、第3.8.3項「パーティション化されたテーブルをサポートするようにDACを構成する方法」を参照してください。

3.8.2 大きな要素テーブルのパーティション化

大きな要素テーブルでパフォーマンスに影響を及ぼす場合、この項で説明するように、要素テーブルをパーティション化することによりパフォーマンスを最大化できます。

この項に記載されている手順では、W_WRKFC_EVT_MONTH_F要素テーブルをパーティション化テーブルに変換し年別に範囲パーティション化を使用する例を使用しています。

大きな要素テーブルをパーティション化するには

  1. パーティション化キーを特定して、パーティション化間隔を決定します。

    適切なパーティション化キーを選択することは、効果的なパーティション化において最も重要な要因です。Web問合せやETL更新で関係するパーティションの数が定義されるからです。パーティション化キーの列を選択する際、次のガイドラインを確認してください。

    • 範囲パーティション化を実装するために、DATE型の適切な列を特定します。

    • Oracle BI Serverリポジトリに接続して、論理レイヤーとプレゼンテーション・レイヤーで列ごとに使用方法や依存性をチェックします。

    • それぞれの潜在的なパーティション化キー候補および時間の範囲別(月、四半期または年)のデータ・ボリュームによって、要約されたデータ分布をターゲット・テーブルで分析します。

    • コンパイル済データに基づいて、今後のパーティション化テーブルで適切なパーティション化キーとパーティション化範囲を決定します。

    • 大半の実装における推奨パーティション化範囲は月ですが、四半期または年のパーティション化範囲に関する実装を検討することが必要になる場合があります。

    • これらのガイドラインでは、ほとんどの増分ETLボリューム・データは、新規レコードで構成されていると想定しています。つまり、それらは2つの最新パーティションの1つに格納されます。次に示すように、選択した範囲の粒度に応じて、最も影響が及ぶ最新パーティションでローカル・インデックスを再作成することをお薦めします。

      • 月次範囲。最新のパーティションを2つ(つまり現在のパーティションと前のパーティション)保持することをお薦めします。

      • 四半期別範囲。現在のパーティションのみを保持する必要があります。

      • 年次範囲。現在のパーティションを保持することをお薦めします。

  2. パーティション化テーブルを作成します。

    初期ロード前にパーティション化テーブルを事前に作成したり、データを通常のテーブルにロードしてからパーティション化テーブルのコピーを作成し、要約されたデータを移行できます。通常のテーブルへの初期ロードが完了している状況で、パーティション化すると決定した場合、初期ロードの再実行は不要です。

    テーブルをパーティション化テーブルに変換するオプションを2つ検討できます。

    • 「as select」SQL文を使用してテーブルを作成します。

      この方法は、より簡略で高速です。

    • 交換パーティション構文を使用してテーブルを作成してから、パーティションを分割します。

      エンド・ユーザーがデータにアクセスする状況でパーティション化を行う必要がある場合、この方法は高可用性データ・ウェアハウスに適しています。

      次のSQLコマンドの構文で、1つの表領域(名前はUSERS)の例を使用します。

      1. 元のテーブルの名前を変更します。

        SQL> rename W_WRKFC_EVT_MONTH_F to W_WRKFC_EVT_MONTH_F_ORIG;

      2. 年別でパーティション化されている範囲を使用してパーティション化テーブルを作成します。

        SQL> create table W_WRKFC_EVT_MONTH_F partition by range (EVENT_YEAR)(
partition PART_MIN values less than (2006),
partition PART_2006 values less than (2007),
partition PART_2007 values less than (2008),
partition PART_2008 values less than (2009),
partition PART_2009 values less than (2010),
partition PART_2010 values less than (2011),
partition PART_MAX  values less than (maxvalue)
)
tablespace BIAPPS_DATA
nologging parallel enable row movement
as select * from W_WRKFC_EVT_MONTH_F_ORIG;

        注意:

        年別パーティション化ではYYYY形式を、四半期別パーティション化ではYYYYQQ形式を、月別パーティション化ではYYYYMM形式を、それぞれ使用する必要があります。テーブルをパーティション化する前に、パーティション化列データ型を必ずチェックしてください。

        前述の例におけるEVENT_YEAR列では、数値(4)精度が使用されます。これによって、YYYY形式を使用してテーブル・パーティション値が定義されます。パーティション化キーでWID列を選択した場合、YYYYMMDD形式を使用してパーティション化範囲を定義する必要があります。

        次のような構文を使用して、コンポジット範囲-範囲パーティション化を実装できます。この例では、パーティション化では四半期範囲を、サブパーティション化では年範囲を、それぞれ使用しています。EXPENDITURE_DT_WID列は数値(8)精度なので、YYYY形式の年別パーティション、YYYYMM形式の月別パーティションおよびYYYYMMDD形式のWID別パーティションを使用して、テーブル・パーティション値が定義されます。年の範囲ではYYYYのデータ形式を、四半期の範囲ではYYYYQQのデータ形式を、月別の範囲ではYYYYMMDDのデータ形式を、それぞれ使用する必要があります。テーブルをパーティション化する前に、パーティション化列データ型を必ずチェックしてください。

        SQL> create table W_PROJ_EXP_LINE_F
partition by range    (CHANGED_ON_DT)
subpartition by range (EXPENDITURE_DT_WID)
(partition PART_MIN values less then (TO_DATE('01-JAN-2008','DD-MON-YYYY'))
( subpartition PART_MIN_MIN  values less than (19980000)
, subpartition PART_MIN_1998 values less than (19990000)
, subpartition PART_MIN_1999 values less than (20010000)
, subpartition PART_MIN_2001 values less than (20020000)
, subpartition PART_MIN_2002 values less than (20030000)
, subpartition PART_MIN_2003 values less than (20040000)
, subpartition PART_MIN_2004 values less than (20050000)
, subpartition PART_MIN_2005 values less than (20060000)
, subpartition PART_MIN_2006 values less than (20070000)
, subpartition PART_MIN_2007 values less than (20080000)
, subpartition PART_MIN_2008 values less than (20090000)
, subpartition PART_MIN_2009 values less than (20100000)
, subpartition PART_MIN_MAX values less than (MAXVALUE)
)
(partition PART_200801 values less then (TO_DATE('01-APR-2008','DD-MON-YYYY'))
( subpartition PART_200801_MIN  values less than (19980000)
( subpartition PART_200801_1998  values less than (19990000)
( subpartition PART_200801_1999  values less than (20010000)
( subpartition PART_200801_2001  values less than (20020000)
( subpartition PART_200801_2002  values less than (20030000)
( subpartition PART_200801_2003  values less than (20040000)
( subpartition PART_200801_2004  values less than (20050000)
( subpartition PART_200801_2005  values less than (20060000)
( subpartition PART_200801_2006  values less than (20070000)
( subpartition PART_200801_2007  values less than (20080000)
( subpartition PART_200801_2008  values less than (20090000)
( subpartition PART_200801_2009  values less than (20100000)
( subpartition PART_200801_MAX  values less than (MAXVALUE)
)
...
...
, partition PART_MAX values less than (maxvalue)
( subpartition PART_MAX_MIN values less than (19980000)
, subpartition PART_MAX_1998 values less than (19990000)
, subpartition PART_MAX_1999 values less than (20010000)
, subpartition PART_MAX_2001 values less than (20020000)
, subpartition PART_MAX_2002 values less than (20030000)
, subpartition PART_MAX_2003 values less than (20040000)
, subpartition PART_MAX_2004 values less than (20050000)
, subpartition PART_MAX_2005 values less than (20060000)
, subpartition PART_MAX_2006 values less than (20070000)
, subpartition PART_MAX_2007 values less than (20080000)
, subpartition PART_MAX_2008 values less than (20090000)
, subpartition PART_MAX_2009 values less than (20100000)
, subpartition PART_MAX_MAX values less than (maxvalue)
)
) nologging parallel
enable row movement
as (select * from W_PROJ_EXP_LINE_F_ORIG);

  3. 名前を変更したテーブルでインデックスを削除してから名前を変更します。

    SQL> spool drop_ind.sql
SQL> SELECT 'DROP INDEX '|| INDEX_NAME||';' FROM USER_INDEXES
     WHERE TABLE_NAME = 'W_WRKFC_EVT_MONTH_F_ORIG';
SQL> spool off
SQL> @drop_ind.sql

    パーティション化変換が正常に完了するまで、元の名前変更済テーブルでインデックスを保持する場合、次のコマンドを使用します。

    SQL> spool rename_ind.xql
SQL> SELECT 'ALTER INDEX '|| INDEX _NAME ||' rename to '|| INDEX_NAME || '_ORIG; ' FROM USER_INDEXES 
WHERE TABLE_NAME = 'W_WRKFC_EVT_MONTH_F_ORIG';
SQL> spool off
SQL> @rename_ind.sql

  4. グローバル・インデックスとローカル・インデックスを作成します。

    1. 次の問合せをDACリポジトリ所有者として実行します。

      SQL> spool indexes.sql
SQL> SELECT 'CREATE'
     ||DECODE(ISUNIQUE,'Y','UNIQUE')
     ||DECODE(ISBITMAP,'Y','BITMAP')
     ||'INDEX'
     ||I.NAME
     ||'ON'
     ||T.NAME
     ||'('
     ||MAX(DECODE(POSTN,1,C.NAME||'ASC'))
     ||MAX(DECODE(POSTN,2,' ,'||C.NAME||'ASC'))
     ||MAX(DECODE(POSTN,3,' ,'||C.NAME||'ASC'))
     ||MAX(DECODE(POSTN,4,' ,'||C.NAME||'ASC'))
     ||MAX(DECODE(POSTN,5,' ,'||C.NAME||'ASC'))
     ||MAX(DECODE(POSTN,6,' ,'||C.NAME||'ASC'))
     ||MAX(DECODE(POSTN,7,' ,'||C.NAME||'ASC'))
     ||') tablespace USERS_IDX '
     ||DECODE(ISUNIQUE, 'Y','GLOBAL','LOCAL')
     ||' NOLOGGING;'
FROM  W_ETL_TABLE T, W_ETL_INDEX I, W_ETL_INDEX_COL C
WHERE T.ROW_WID = I.TABLE_WID
      AND T.NAME = 'W_WRKFC_EVT_MONTH_F'
      AND I.ROW_WID = C.INDEX_WID
      AND I.INACTIVE_FLG = 'N'
GROUP BY T.NAME,I.NAME,ISBITMAP,ISUNIQUE;
S       QL> spool off;

      このスクリプトでは、最大で7つの位置でインデックスが作成されます。7列の位置よりも多くのインデックスがある場合は、MAX(DECODE(POSTN...))文を変更します。

    2. スプール・ファイルのindexes.sqlをデータ・ウェアハウス・スキーマで実行します。次に例を示します。

      SQL> @indexes.sql

  5. 統計をパーティション化テーブルで算出します。次に例を示します。

    SQL> BEGIN
     dbms_stats.Gather_table_stats(
          NULL
          tabname => 'W_WRKFC_EVT_MONTH_F',
          CASCADE => true,
          estimate_percent => dbms_stats.auto_sample_size,
          method_opt => 'FOR ALL INDEXED COLUMNS SIZE AUTO');
     END;

  6. 行移動を有効にすることでパーティション化テーブルをサポートするようにInformaticaを構成します。

    1. Informatica Workflow Managerで、メニュー・バーから「Connections」→「Relational」を選択します。

    2. 「Relational Connection Browser」ダイアログ・ボックスで「DataWarehouse」接続を選択します。

    3. 接続環境SQLを次のように更新します。

      ALTER SESSION SET SKIP_UNUSABLE_INDEX=TRUE;

パーティション化されたテーブルをサポートするようにDACを構成する必要があります。詳細は、第3.8.3項「パーティション化されたテーブルをサポートするようにDACを構成する方法」を参照してください。

3.8.3 パーティション化されたテーブルをサポートするようにDACを構成する方法

第3.8.2項「大きな要素テーブルのパーティション化」の説明に従って、要素テーブルをパーティション化すると、パーティション化された要素テーブルをサポートするようにDACを構成する必要があります。この処理では、最初に新しいソース・システム・パラメータを作成します。そして、DACアクション機能を使用して、インデックスの削除と作成におけるデフォルトの動作よりも優先するインデックス・アクションを作成します。また、テーブルを分析するデフォルトのアクションよりも優先するテーブル・アクションも作成します。インデックスとテーブル・アクションを作成したら、これらのアクションを適切なインデックスとテーブルにDACリポジトリで関連付けます。

DACアクション機能の詳細は、Oracle Business Intelligenceデータ・ウェアハウス管理コンソール・ユーザーズ・ガイドを参照してください。


注意:

このプロセスの例では、インデックスの再作成を設定して、年別の範囲パーティション化において2つの最新パーティション(つまり、前のパーティションと現在のパーティション)で統計をメンテナンスする方法が示されています。月次かそれより粒度の細かい範囲には、前のパーティションと現在のパーティションのみを実装することを検討してください。四半期別か年別の範囲でパーティションを実装する場合は、現在のパーティションのみを保持する必要があります。四半期別か年別で前のパーティションを保持すると、不必要なオーバーヘッドが発生して、増分ETL実行時間が長くなる場合があります。

パーティション化テーブルをサポートするようにDACを構成するには、次の手順を実行する必要があります。

DACアクション機能の詳細は、Oracle Business Intelligenceデータ・ウェアハウス管理コンソール・ユーザーズ・ガイドを参照してください。これは、Oracle Technology Network(http://www.oracle.com/technology/documentation/bi_dac.html)で入手できます。

3.8.3.1 パーティション化されたテーブルをサポートするようにDACでソース・システム・パラメータを作成する方法

この手順に従って、パーティション化されたテーブルをサポートするようにDACでソース・システム・パラメータを作成します。

パーティション化されたテーブルをサポートするようにDACでソース・システム・パラメータを作成するには

  1. DACにログインします。

    DACにログインする方法の詳細は、第A.1項「DACにログインする方法」を参照してください。

  2. 「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。

  3. 「Source System Parameters」タブをクリックします。

  4. ツールバーで「New」をクリックし、新規レコードを開きます。

  5. 年別パーティションの場合:

    1. 次の値でパラメータを作成します。

      -Name: $$CURRENT_YEAR_WID

      -Data Type: SQL

      -Value: SELECT TO_CHAR(ROW_WID) FROM W_YEAR_D WHERE W_CURRENT_CAL_YEAR_CODE = 'Current'

      -Logical Data Source: DBConnection_OLAP

    2. 次の値で2番目のパラメータを作成します。

      -Name: $$PREVIOUS_YEAR_WID

      -Data Type: SQL

      -Value: SELECT TO_CHAR(ROW_WID) FROM W_YEAR_D WHERE W_CURRENT_CAL_YEAR_CODE = 'Previous'

      -Logical Data Source: DBConnection_OLAP

  6. 月別パーティションの場合:

    1. 次の値でパラメータを作成します。

      -Name: $$CURRENT_MONTH_WID

      -Data Type: SQL

      -Value: SELECT TO_CHAR(ROW_WID) FROM W_MONTH_D WHERE W_CURRENT_CAL_MONTH_CODE = 'Current'

      -Logical Data Source: DBConnection_OLAP

    2. 次の値で2番目のパラメータを作成します。

      -Name: $$PREVIOUS_MONTH_WID

      -Data Type: SQL

      -Value: SELECT TO_CHAR(ROW_WID) FROM W_MONTH_D WHERE W_CURRENT_CAL_MONTH_CODE = 'Previous'

      -Logical Data Source: DBConnection_OLAP

  7. 四半期別パーティションの場合:

    1. 次の値でパラメータを作成します。

      -Name: $$CURRENT_QTR_WID

      -Data Type: SQL

      -Value: SELECT TO_CHAR(ROW_WID) FROM W_QTR_D WHERE W_CURRENT_CAL_QTR_CODE = 'Current'

      -Logical Data Source: DBConnection_OLAP

    2. 次の値で2番目のパラメータを作成します。

      -Name: $$PREVIOUS_QTR_WID

      -Data Type: SQL

      -Value: SELECT TO_CHAR(ROW_WID) FROM W_QTR_D WHERE W_CURRENT_CAL_QTR_CODE = 'Previous'

      -Logical Data Source: DBConnection_OLAP

3.8.3.2 DACにおけるインデックス・アクションの作成

この項では、インデックス・アクションを作成し、インデックスをパーティション化テーブルで無効にして作成する手順について説明します。内容は次のとおりです。

3.8.3.2.1 インデックス・アクションを作成してローカル・インデックス・パラメータを無効にする方法

このインデックス・アクションによりローカル・インデックスが無効になります。この例では年別パーティション範囲を使用しています。四半期別や月別のパーティション範囲を使用する場合、アクションとSQLでは適切な名前(PREVIOUS_MONTH_WID/CURRENT_MONTH_WIDやPREVIOUS_QTR_WID/CURRENT_QTR_WIDなど)で置換します。使用する範囲ごとに別々のアクションを定義する必要があります。

  1. DACにログインします。

    DACにログインする方法の詳細は、第A.1項「DACにログインする方法」を参照してください。

  2. 「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。

  3. 「Menu」バーから、「Tools」→「Seed Data」→「Actions」→「Index Actions」を選択します。

  4. 「Index Actions」ダイアログ・ボックスで「New」をクリックします。

    新規レコード・フィールドがアクションのリストの上部に表示されます。

  5. 名前フィールドに、「Year Partitioning: Disable Local Index」と入力します。

  6. 「Save」をクリックします。

  7. 「Value」フィールドをダブルクリックして、「Value」ダイアログ・ボックスを開きます。

    「Value」ダイアログ・ボックスが表示されます。

  8. SQLスクリプトを定義します。

    1. 「Add」をクリックします。

      新規レコード・フィールドがSQLブロックのリストの上部に表示されます。

      このイメージは新規レコード・フィールドを示しています

    2. 新規レコード・フィールドに次の情報を入力します。

      フィールド 説明
      名前 「Disable PREVIOUS_YEAR_WID Local Indexes」と入力します。
      タイプ 「SQL」を選択します。
      Database Connection 「Target」を選択します。
      Valid Database Platforms フィールドをダブルクリックして「Supported Database Types」ダイアログ・ボックスを開き、適切なデータベースを選択します。

    3. ウィンドウの右下部にあるテキスト・ボックスで、次のSQLを入力します。

      alter index getIndexName() modify partition PART_@DAC_$$PREVIOUS_YEAR_WID unusable

      注意: テキスト・エリアにおいてセミコロン(;)をSQLの末尾で使用しないでください。

    4. 「Save」をクリックします。

  9. SQLを定義します。

    1. 「Add」をクリックします。

      新規レコード・フィールドがSQLブロックのリストの上部に表示されます。

    2. 新規レコード・フィールドに次の情報を入力します。

      フィールド 説明
      名前 「Disable CURRENT_YEAR_WID Local Indexes」と入力します。
      タイプ 「SQL」を選択します。
      Database Connection 「Target」を選択します。
      Valid Database Platforms フィールドをダブルクリックして「Supported Database Types」ダイアログ・ボックスを開き、適切なデータベースを選択します。

    3. ウィンドウの右下部にあるテキスト・ボックスで、次のSQLを入力します。

      alter index getIndexName() modify partition PART_@DAC_$$CURRECT_YEAR_WID unusable

    4. 「Save」をクリックします。

3.8.3.2.2 インデックス・アクションを作成してローカル・インデックス・パラメータを有効にする方法

このインデックス・アクションによりローカル・インデックスが有効になります。この例では年別パーティション範囲を使用しています。四半期別や月別のパーティション範囲を使用する場合、アクションとSQLでは適切な名前(PREVIOUS_MONTH_WID/CURRENT_MONTH_WIDやPREVIOUS_QTR_WID/CURRENT_QTR_WIDなど)で置換します。使用する範囲ごとに別々のアクションを定義する必要があります。

  1. DACにログインします。

    DACにログインする方法の詳細は、第A.1項「DACにログインする方法」を参照してください。

  2. 「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。

  3. 「Menu」バーから、「Tools」→「Seed Data」→「Actions」→「Index Actions」を選択します。

  4. 「Index Actions」ダイアログ・ボックスで「New」をクリックします。

    新規レコード・フィールドがアクションのリストの上部に表示されます。

  5. 名前フィールドに、「Year Partitioning: Enable Local Index」と入力します。

  6. 「Save」をクリックします。

  7. 「Value」フィールドをダブルクリックして、「Value」ダイアログ・ボックスを開きます。

    「Value」ダイアログ・ボックスが表示されます。

  8. SQLスクリプトを定義します。

    1. 「Add」をクリックします。

      新規レコード・フィールドがSQLブロックのリストの上部に表示されます。

    2. 新規レコード・フィールドに次の情報を入力します。

      フィールド 説明
      名前 「Enable PREVIOUS_YEAR_WID Local Indexes」と入力します。
      タイプ 「SQL」を選択します。
      Database Connection 「Target」を選択します。
      Valid Database Platforms フィールドをダブルクリックして「Supported Database Types」ダイアログ・ボックスを開き、適切なデータベースを選択します。

    3. ウィンドウの右下部にあるテキスト・ボックスで、次のSQLを入力します。

      alter index getIndexName() rebuild partition PART_@DAC_$$PREVIOUS_YEAR_WID nologging

      注意: テキスト・エリアにおいてセミコロン(;)をSQLの末尾で使用しないでください。

    4. 「Save」をクリックします。

  9. SQLスクリプトを定義します。

    1. 「Add」をクリックします。

      新規レコード・フィールドがSQLブロックのリストの上部に表示されます。

    2. 新規レコード・フィールドに次の情報を入力します。

      フィールド 説明
      名前 「Enable CURRENT_YEAR_WID Local Indexes」と入力します。
      タイプ 「SQL」を選択します。
      Database Connection 「Target」を選択します。
      Valid Database Platforms フィールドをダブルクリックして「Supported Database Types」ダイアログ・ボックスを開き、適切なデータベースを選択します。

    3. ウィンドウの右下部にあるテキスト・ボックスで、次のSQLを入力します。

      alter index getIndexName() rebuild partition PART_@DAC_$$CURRECT_YEAR_WID nologging

      注意: テキスト・エリアにおいてセミコロン(;)をSQLの末尾で使用しないでください。

    4. 「Save」をクリックします。

3.8.3.2.3 インデックス・アクションを作成してローカル・サブパーティション化インデックス・パラメータを有効にする方法

このインデックス・アクションはコンポジット・パーティション化専用です。この例では年別パーティション範囲を使用しています。四半期別や月別のパーティション範囲を使用する場合は、アクションとSQLでは適切な名前で置換します。

  1. DACにログインします。

    DACにログインする方法の詳細は、第A.1項「DACにログインする方法」を参照してください。

  2. 「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。

  3. 「Menu」バーから、「Tools」→「Seed Data」→「Actions」→「Index Actions」を選択します。

  4. 「Index Actions」ダイアログ・ボックスで「New」をクリックします。

    新規レコード・フィールドがアクションのリストの上部に表示されます。

  5. 名前フィールドに、「Year Partitioning: Enable Local Index」と入力します。

  6. 「Save」をクリックします。

  7. 「Value」フィールドをダブルクリックして、「Value」ダイアログ・ボックスを開きます。

    「Value」ダイアログ・ボックスが表示されます。

  8. SQLスクリプトを定義します。

    1. 「Add」をクリックします。

      新規レコード・フィールドがSQLブロックのリストの上部に表示されます。

    2. 新規レコード・フィールドに次の情報を入力します。

      フィールド 説明
      名前 「Enable Local Sub-partitioned Index」と入力します。
      タイプ 「Stored Procedure」を選択します。
      Database Connection 「Target」を選択します。
      Valid Database Platforms フィールドをダブルクリックして「Supported Database Types」ダイアログ・ボックスを開き、適切なデータベースを選択します。

    3. ウィンドウの右下部にあるテキスト・ボックスで、次のSQLを入力します。

      DECLARE
     CURSOR C1 IS
     SELECT DISTINCT SUBPARTITION_NAME
     FROM USER_IND_SUBPARTITIONS
     WHERE INDEX_NAME='getIndexName()' AND STATUS = 'UNUSABLE';
BEGIN
   FOR REC IN C1 LOOP
     EXECUTE IMMEDIATE 'alter index getIndexName() rebuild subpartition
'||REC.SUBPARTITION_NAME||'';
   END LOOP;
END

      注意: テキスト・エリアにおいてセミコロン(;)をSQLの末尾で使用しないでください。

    4. 「Save」をクリックします。

3.8.3.2.4 インデックス・アクションを作成してローカル・ビットマップ・インデックス・パラメータを作成する方法

この例では年別パーティション範囲を使用しています。四半期別や月別のパーティション範囲を使用する場合は、アクションとSQLでは適切な名前で置換します。

  1. DACにログインします。

    DACにログインする方法の詳細は、第A.1項「DACにログインする方法」を参照してください。

  2. 「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。

  3. 「Menu」バーから、「Tools」→「Seed Data」→「Actions」→「Index Actions」を選択します。

  4. 「Index Actions」ダイアログ・ボックスで「New」をクリックします。

    新規レコード・フィールドがアクションのリストの上部に表示されます。

  5. 名前フィールドに、「Year Partitioning: Create Local Bitmap Index」と入力します。

  6. 「Save」をクリックします。

  7. 「Value」フィールドをダブルクリックして、「Value」ダイアログ・ボックスを開きます。

    「Value」ダイアログ・ボックスが表示されます。

  8. SQLスクリプトを定義します。

    1. 「Add」をクリックします。

      新規レコード・フィールドがSQLブロックのリストの上部に表示されます。

    2. 新規レコード・フィールドに次の情報を入力します。

      フィールド 説明
      名前 「Create Local Bitmap Indexes」と入力します。
      タイプ 「SQL」を選択します。
      Database Connection 「Target」を選択します。
      Valid Database Platforms フィールドをダブルクリックして「Supported Database Types」ダイアログ・ボックスを開き、適切なデータベースを選択します。

    3. ウィンドウの右下部にあるテキスト・ボックスで、次のSQLを入力します。

      Create bitmap index getIndexName() on getTableName() (getUniqueColumns()) tablespace getTableSpace() local parallel nologging

      注意: テキスト・エリアにおいてセミコロン(;)をSQLの末尾で使用しないでください。

    4. 「Save」をクリックします。

3.8.3.2.5 インデックス・アクションを作成してローカルBツリー・インデックス・パラメータを作成する方法

この例では年別パーティション範囲を使用しています。四半期別や月別のパーティション範囲を使用する場合は、アクションとSQLでは適切な名前で置換します。

  1. DACにログインします。

    DACにログインする方法の詳細は、第A.1項「DACにログインする方法」を参照してください。

  2. 「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。

  3. 「Menu」バーから、「Tools」→「Seed Data」→「Actions」→「Index Actions」を選択します。

  4. 「Index Actions」ダイアログ・ボックスで「New」をクリックします。

    新規レコード・フィールドがアクションのリストの上部に表示されます。

  5. 名前フィールドに、「Year Partitioning: Create Local B-Tree Index」と入力します。

  6. 「Save」をクリックします。

  7. 「Value」フィールドをダブルクリックして、「Value」ダイアログ・ボックスを開きます。

    「Value」ダイアログ・ボックスが表示されます。

  8. SQLスクリプトを定義します。

    1. 「Add」をクリックします。

      新規レコード・フィールドがSQLブロックのリストの上部に表示されます。

    2. 新規レコード・フィールドに次の情報を入力します。

      フィールド 説明
      名前 「Create Local B-Tree Index」と入力します。
      タイプ 「SQL」を選択します。
      Database Connection 「Target」を選択します。
      Valid Database Platforms フィールドをダブルクリックして「Supported Database Types」ダイアログ・ボックスを開き、適切なデータベースを選択します。

    3. ウィンドウの右下部にあるテキスト・ボックスで、次のSQLを入力します。

      Create index getIndexName() on getTableName() (getUniqueColumns()) tablespace getTableSpace() local parallel nologging

      注意: テキスト・エリアにおいてセミコロン(;)をSQLの末尾で使用しないでください。

    4. 「Save」をクリックします。

3.8.3.2.6 インデックス・アクションを作成してグローバル一意インデックス・パラメータを作成する方法

この例では年別パーティション範囲を使用しています。四半期別や月別のパーティション範囲を使用する場合は、アクションとSQLでは適切な名前で置換します。

  1. DACにログインします。

    DACにログインする方法の詳細は、第A.1項「DACにログインする方法」を参照してください。

  2. 「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。

  3. 「Menu」バーから、「Tools」→「Seed Data」→「Actions」→「Index Actions」を選択します。

  4. 「Index Actions」ダイアログ・ボックスで「New」をクリックします。

    新規レコード・フィールドがアクションのリストの上部に表示されます。

  5. 名前フィールドに、「Year Partitioning: Create Global Unique Index」と入力します。

  6. 「Save」をクリックします。

  7. 「Value」フィールドをダブルクリックして、「Value」ダイアログ・ボックスを開きます。

    「Value」ダイアログ・ボックスが表示されます。

  8. SQLスクリプトを定義します。

    1. 「Add」をクリックします。

      新規レコード・フィールドがSQLブロックのリストの上部に表示されます。

    2. 新規レコード・フィールドに次の情報を入力します。

      フィールド 説明
      名前 「Create Global Unique Index」と入力します。
      タイプ 「SQL」を選択します。
      Database Connection 「Target」を選択します。
      Valid Database Platforms フィールドをダブルクリックして「Supported Database Types」ダイアログ・ボックスを開き、適切なデータベースを選択します。

    3. ウィンドウの右下部にあるテキスト・ボックスで、次のSQLを入力します。

      Create index getIndexName() on getTableName() (getUniqueColumns()) tablespace getTableSpace() global parallel nologging

      注意: テキスト・エリアにおいてセミコロン(;)をSQLの末尾で使用しないでください。

    4. 「Save」をクリックします。

3.8.3.3 DACにおけるテーブル・アクションの作成

この項では、テーブル・アクションを作成し、統計をパーティション化テーブルで収集する手順について説明します。内容は次のとおりです。

3.8.3.3.1 テーブル・アクションを作成して統計をパーティション化テーブルで収集する方法

この例では年別パーティション範囲を使用しています。四半期別や月別のパーティション範囲を使用する場合は、アクションとSQLでは適切な名前で置換します。

  1. DACにログインします。

    DACにログインする方法の詳細は、第A.1項「DACにログインする方法」を参照してください。

  2. 「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。

  3. 「Menu」バーから、「Tools」→「Seed Data」→「Actions」→「Table Actions」を選択します。

  4. 「Table Actions」ダイアログ・ボックスで「New」をクリックします。

    新規レコード・フィールドがアクションのリストの上部に表示されます。

  5. 名前フィールドに、「Year Partitioning: Gather Partition Stats」と入力します。

  6. 「Save」をクリックします。

  7. 「Value」フィールドをダブルクリックして、「Value」ダイアログ・ボックスを開きます。

    「Value」ダイアログ・ボックスが表示されます。

  8. SQLスクリプトを定義します。

    1. 「Add」をクリックします。

      新規レコード・フィールドがSQLブロックのリストの上部に表示されます。

    2. 新規レコード・フィールドに次の情報を入力します。

      フィールド 説明
      名前 「Gather Partition Stats」と入力します。
      タイプ 「Stored Procedure」を選択します。
      Database Connection 「Target」を選択します。
      Valid Database Platforms フィールドをダブルクリックして「Supported Database Types」ダイアログ・ボックスを開き、適切なデータベースを選択します。

    3. ウィンドウの右下部にあるテキスト・ボックスで、次のSQLを入力します。

      DECLARE
     CURSOSR C1 IS
     SELECT DISTINCT UIP.PARTITION_NAME
     FROM USER_IND_PARTITIONS UIP, USER_PART_INDEXES UPI
     WHERE UPI.TABLE_NAME = 'getTableName()'
          AND UIP.INDEX_NAME=UPI.INDEX_NAME
          AND UIP.STATUS = 'USABLE'
          AND UIP.PARTITION_NAME IN
('PART_@DAC_$$CURRENT_YEAR_WID','PART_@DAC_$$PREVIOUS_YEAR_WID');
BEGIN
   FOR REC IN C1 LOOP
DBMS_STATS.GATHER_TABLE_STATS(
               NULL,
               TABNAME => 'getTableName()',
               CASCADE => TRUE
               PARTNAME => REC.PARTITION_NAME
            ESTIMATE_PERCENT => DBMS_STATS.AUTO_SAMPLE_SIZE,
            GRANULARITY => 'PARTITION',
            METHOD_OPT => 'FOR ALL INDEXED COLUMNS SIZE AUTO',
            DEGREE => DBMS_STATS.DEFAULT_DEGREE);
   END LOOP;
END

      注意: テキスト・エリアにおいてセミコロン(;)をSQLの末尾で使用しないでください。

    4. 「Save」をクリックします。

3.8.3.3.2 テーブル・アクションを作成してコンポジット・パーティション化のパーティション化テーブルで統計を収集する方法

四半期別や月別のパーティション範囲を使用する場合は、アクションとSQLでは適切な名前で置換します。

注意: 変更したインデックスでは「Drop and Create Always」と「Drop and Create Always Bitmap」のプロパティを変更しないでください。これらのチェック・ボックスの選択を解除すると、DACでは定義されているインデックス・アクションがスキップされます。

  1. DACにログインします。

    DACにログインする方法の詳細は、第A.1項「DACにログインする方法」を参照してください。

  2. 「Design」ビューに移動して、適切なカスタム・コンテナをドロップダウン・リストから選択します。

  3. 「Menu」バーから、「Tools」→「Seed Data」→「Actions」→「Table Actions」を選択します。

  4. 「Table Actions」ダイアログ・ボックスで「New」をクリックします。

    新規レコード・フィールドがアクションのリストの上部に表示されます。

  5. 名前フィールドに、「Quarter Composite Partitioning: Gather Partition Stats」と入力します。

  6. 「Save」をクリックします。

  7. 「Value」フィールドをダブルクリックして、「Value」ダイアログ・ボックスを開きます。

    「Value」ダイアログ・ボックスが表示されます。

  8. SQLスクリプトを定義します。

    1. 「Add」をクリックします。

      新規レコード・フィールドがSQLブロックのリストの上部に表示されます。

    2. 新規レコード・フィールドに次の情報を入力します。

      フィールド 説明
      名前 「Gather Partition Stats」と入力します。
      タイプ 「Stored Procedure」を選択します。
      Database Connection 「Target」を選択します。
      Valid Database Platforms フィールドをダブルクリックして「Supported Database Types」ダイアログ・ボックスを開き、適切なデータベースを選択します。

    3. ウィンドウの右下部にあるテキスト・ボックスで、次のSQLを入力します。

      DECLARE
     CURSOSR C1 IS
     SELECT DISTINCT UIP.PARTITION_NAME
     FROM USER_IND_PARTITIONS UIP, USER_PART_INDEXES UPI
     WHERE UPI.TABLE_NAME = 'getTableName()'
          AND UIP.INDEX_NAME=UPI.INDEX_NAME
          AND UIP.STATUS = 'USABLE'
          AND UIP.PARTITION_NAME IN
('PART_@DAC_$$CURRENT_QTR_WID','PART_@DAC_$$PREVIOUS_QTR_WID');
BEGIN
   FOR REC IN C1 LOOP
DBMS_STATS.GATHER_TABLE_STATS(
               NULL,
               TABNAME => 'getTableName()',
               CASCADE => TRUE
               PARTNAME => REC.PARTITION_NAME
            ESTIMATE_PERCENT => DBMS_STATS.AUTO_SAMPLE_SIZE,
            GRANULARITY => 'PARTITION',
            METHOD_OPT => 'FOR ALL INDEXED COLUMNS SIZE AUTO',
            DEGREE => DBMS_STATS.DEFAULT_DEGREE);
   END LOOP;
END

      注意: テキスト・エリアにおいてセミコロン(;)をSQLの末尾で使用しないでください。

    4. 「Save」をクリックします。

3.8.3.4 DACにおけるインデックスへのインデックス・アクションの割当て

インデックス・アクションをDACで作成したら、前の手順で作成した次のインデックス・アクションごとに、インデックス・アクションを特定のインデックスに割り当てる必要があります。

  • ローカル・インデックスの無効化

  • ローカル・インデックスの有効化

  • ローカル・ビットマップ・インデックスの作成

  • ローカルBツリー・インデックスの作成

  • グローバル一意インデックスの作成

インデックス・アクションをインデックスに割り当てるには

  1. 「DAC Design」ビューで、「Index」タブをクリックします。

  2. 割当て対象のインデックス・アクションに基づいて、適切なインデックスをパーティション化テーブルで問い合せます。

    注意: グローバル・インデックスは問合せに含めないでください。割り当てられているインデックス・アクション・タスクがグローバル・インデックスに存在してはいけません。

  3. クエリー結果の一覧で右クリックし、「Add Actions」を選択します。

    「Add Actions」ダイアログ・ボックスが開きます。

  4. 「Action Type」フィールドで、適切なアクション・タイプを選択します。

  5. 「Load Type」フィールドで次の操作を行います。

    「Incremental for Disable」と「Enable Local Indexes」のアクションを選択します。

    「Initial for Create Local Bitmap Index」、「Create Local B-Tree Index」および「Create Global Unique Index」を選択します。

  6. 「Action」フィールドで、ダブルクリックして「Choose Action」ダイアログを開きます。

  7. 適切なアクション名を選択します。

  8. 「OK」をクリックして、「Add Actions」ダイアログ・ボックスを閉じます。

3.8.3.5 DACにおけるテーブルへのテーブル・アクションの割当て

テーブル・アクションをDACで作成したら、前の手順で作成したテーブル・アクションごとに、テーブル・アクションを特定のテーブルに割り当てる必要があります。

インデックス・アクションをインデックスに割り当てるには

  1. 「DAC Design」ビューで、「Index」タブをクリックします。

  2. 割当て対象のテーブル・アクションに基づいて適切なテーブルを問い合せます。

  3. クエリー結果の一覧で右クリックし、「Add Actions」を選択します。

    「Add Actions」ダイアログ・ボックスが開きます。

  4. 「Action Type」フィールドで、「Analyze Table」を選択します。

  5. 「Load Type」フィールドで、「Incremental」を選択します。

  6. 「Action」フィールドで、ダブルクリックして「Choose Action」ダイアログを開きます。

  7. 適切なアクション名(<Range> Partitioning: Gather Partition Statsなど)を選択します。

  8. 「OK」をクリックして、「Add Actions」ダイアログ・ボックスを閉じます。

  9. 「OK」をクリックして、「Add Actions」ダイアログ・ボックスを閉じます。

注意: コンポジット範囲-範囲テーブルでは、コンポジット・パーティション化テーブル・アクションを必ず使用してください。

3.9 Oracle BI Applicationsの配置に関するその他の情報

この項には次のトピックが含まれます:

3.9.1 SAシステム・サブジェクトエリアの事前に構成済のマッピング

OracleのSiebel Applicationsユーザー向けに、SAシステム・サブジェクトエリアの事前に構成済のマッピングを表3-5に示します。OracleのSiebelトランザクション・データベースにないフィールドは、デフォルトでこの表の値に設定されます。

  • デフォルトの上書き。S_USERテーブルに対する拡張テーブルを作成することで、これらのフィールドにユーザー固有の値を追加して、ユーザー固有のデフォルトを格納できます。また、デフォルト値はいずれも変更可能です。次の論理テーブルのメタデータを変更して、物理的な拡張テーブルを組み込むことができます。

    SA User.(User)

    手順については、OracleのSiebel Business Applicationsのテーブルとカラムの構成に関するドキュメントを参照してください。

  • プロバイダ情報の設定。一般に、Oracle Business Analytics Warehouseでは携帯電話番号とFAX番号にプロバイダ名が含まれません。このため、ポケベルは一般に555-483-3843などの数値に設定されます。このアドレスにプロバイダを追加するには、次のガイドラインに従ってください。

    • 会社全体が同じプロバイダを使用している場合は、カラムのマッピングでプロバイダを追加できます。

    • 複数のユーザーが異なるプロバイダを使用できる場合は、拡張テーブルを作成する必要があります。手順については、OracleのSiebel Business Applicationsのテーブルとカラムの構成に関するドキュメントを参照してください。

表3-5 SAシステム・サブジェクトエリアのユーザー・テーブルに対する事前に構成済のマッピング

論理カラム 物理テーブル 式 備考

携帯電話

''

このフィールドにSMTPアドレスが含まれている場合は、S_CONTACT.CELL_PH_NUMにマップされます。

携帯電話の優先順位

''

デフォルトはN

表示名

S_CONTACT

"Real Time OLTP"."".SIEBEL.S_CONTACT_User.FST_NAME || ' ' || "Real Time OLTP"."".SIEBEL.S_CONTACT_User.LAST_NAME

名と姓の連結

電子メール

S_CONTACT

EMAIL_ADDR

電子メールの優先順位

'HNL'

デフォルトはN

電子メールのタイプ

'html'

デフォルトはHTML

グループ名

S_RESP

NAME

ハンドヘルド

''

デフォルトは空の文字列

ハンドヘルドの優先順位

''

デフォルトは空の文字列

言語

'en'

デフォルトは'en'

ロケール

'en'

デフォルトは'en'

ログオン

S_USER

LOGIN

ポケベル

''

このフィールドにSMTPアドレスが含まれている場合は、S_CONTACT.PAGER_PH_NUMにマップされる可能性があります。

ポケベルの優先順位

''

デフォルトはN

タイムゾーン

S_TIMEZONE

NAME

3.9.2 初期化ブロックの使用

表3-6に、すべてのOracle BI Applicationsに共通の初期化ブロックの一部と、その目的を示します。各Oracle BI Applications領域固有の初期化ブロックは、ここに示されていません。

Oracle BI Applicationsで用意されている初期化ブロックを表示するには、変数マネージャをOracle Business Intelligence Enterprise Edition Administration Toolで開きます。詳細は、『Oracle Business Intelligence Server管理ガイド』を参照してください。

表3-6 初期化ブロックとその目的

初期化ブロック 目的

Authorization

データベースからユーザーの職責を計算します。

Authentication

基幹業務アプリケーション・ユーザーとして存在するユーザーを、データベースに対して認証し、検証します。

External Metadata Strings

ユーザーのロケール用に翻訳されたメタデータ文字列の値を取得します。この初期化ブロックは、各国対応の配置におけるIntelligenceダッシュボードに必要不可欠です。

LOCALE

Oracle BI Serverでのユーザーのロケール仕様を設定します。

Login Properties

ユーザーのログイン・プロパティ(フルネームなど)をデータベースから取得します。この初期化ブロックでは、ユーザーのログレベルも設定されます。デフォルトでは、全ユーザーのログ・レベルが0になります。すべてのユーザーにOracle BIクエリー・ログを生成する場合は、デフォルト値および初期化SQLの値を変更することで、この初期化ブロックを更新する必要があります。

Default System Language ID

基幹業務アプリケーション・データベースにクエリーを実行することで、変数OLTP_LANG_IDを設定します。

Organizations for Org-based Security

基幹業務アプリケーション・データベースに問い合せて、各ユーザーについて組織メンバーシップを取得します。ORGANIZATION変数が設定されます。

Primary Owner ID

ユーザーのログインIDに基づいて、プライマリ所有者IDを設定します。

Primary Position ID

基幹業務アプリケーション・データベースにクエリーを実行して、変数PRIMARY_POSTN_IDを設定します。

Warehouse Refresh Date

CURRENT_YEARなどの、複数の時間ベースの変数を設定します。

ETL Run Date

ETL実行日を取得します。

ETL Default Currency

デフォルト通貨を取得します。

3.9.3 増分ロード・パフォーマンス用のSiebelソース・データベースにおけるカスタム・インデックスの作成

パフォーマンスをSiebel CRMで最大にするために、ORACLE_HOME\biapps\dwrepディレクトリで利用可能なSQLファイルを使用してインデックスを実装できます。表3-7に、特定のアプリケーションに該当するSQLファイルを示します。

表3-7 Siebelトランザクション・データベース用のSQLファイル

アプリケーション名 SQLファイル名

Horizontal Application

PerfIndex_Horizontal.sql

Industry Application

PerfIndex_Industry.sql

SQLファイルによって、事前構成済アプリケーションで使用されているすべてのS_.*テーブルにインデックスが生成されます。


注意:

テスト環境から本番環境に移行する場合は、本番環境でインデックスを削除して再作成する必要があります。

3.9.3.1 チェンジ・キャプチャSQLの例と必要なインデックス

チェンジ・キャプチャSQLによって、次のSQLが生成されます。

Insert into S_ETL_I_IMG_XX (ROW_ID, LAST_UPD)
AS
SELECT ROW_ID, LAST_UPD, MODIFICATION_NUM
From
S_XXX
WHERE LAST_UPD > 'LAST REFRESH_DATE – PRUNE DAYS'
AND NOT EXISTS
(
SELECT 'X' FROM S_ETL_R_IMAGE
WHERE S_ETL_R_IMAGE.ROW_ID = S_XXX.ROW_ID AND
S_ETL_R_IMG_XX.MODIFICATION_NUM = S_XXX.MODIFICATION_NUM AND
S_ETL_R_IMG_XX.LAST_UPD = S_XXX.LAST_UPD
)

SQL生成スクリプトが前述のSQLに基づいてS_CONTACTテーブルに作成するインデックスを、表3-8に示します。

表3-8 Siebelトランザクション・データベースのS_CONTACTテーブルに作成されたインデックス

インデックス インデックス・カラム

S_CONTACT_W1

LAST_UPD、ROW_ID_MODIFICATION_NUM

S_CONTACT_W11

LAST_UPD

3.9.4 増分ロード・パフォーマンス用のOracle EBSソース・データベースにおけるカスタム・インデックスの作成

Oracle EBSソース・データベース・テーブルに必須のLAST_UPDATE_DATE列があります。これをOracle BI Applicationsで使用して、増分データ変更を取得します。Oracle BI Applicationsで使用されるOracle EBSソース・テーブルには、インデックスがLAST_UPDATE_DATE列にないテーブルがあります。インデックスがあると、ソース・アプリケーションのパフォーマンスに影響が及ぶ場合があるからです。

Oracle EBSテーブルには、LAST_UPDATE_DATE列のインデックスに関連するカテゴリが3つあります。

  • カテゴリ1: LAST_UPDATE_DATE列にインデックスはないがパフォーマンスが低下せずにインデックスを作成できるテーブル。

  • カテゴリ2: LAST_UPDATE_DATE列にインデックスがあるテーブル。これらのインデックスはOracle EBSリリース12で導入されました。

  • カテゴリ3: パフォーマンスがOracle EBS環境で低下するため、LAST_UPDATE_DATE列にインデックスを作成できないテーブル。

3.9.4.1 カテゴリ1テーブル用インデックスの作成

次のDDLスクリプトにより、カスタム・インデックスをLAST_UPDATE_DATE列でカテゴリ1テーブル(つまり、このインデックスが作成されていないすべてのOracle EBSリリースのテーブル、およびそのようなインデックスの作成においてパフォーマンスに関する既知の影響がないテーブル)用に作成します。

ソース・システムがOracle EBSリリース11iまたはリリース12の環境において、特定のサブジェクトエリアを実装する際に増分抽出マッピングのパフォーマンスが低い場合、このDDLスクリプトを実行する必要があります。

注意: ソース・システムが、Oracle EBSリリース12、Oracle EBSリリース11.5.10、Oracle EBSリリース11.5.9またはそれより以前のリリースの環境において、Oracle Applications Tablespace Model(OATM)に移行されている場合、<IDX_TABLESPACE>をAPPS_TS_TX_IDXで置換します。

DDLスクリプトは次のとおりです。

CREATE index AP.OBIEE_AP_INVOICE_PAYMENTS_ALL ON AP.AP_INVOICE_PAYMENTS_ALL(LAST_UPDATE_DATE) tablespace <IDX_TABLESPACE>;

CREATE index AP.OBIEE_AP_PAYMENT_SCHEDULES_ALL ON AP.AP_PAYMENT_SCHEDULES_ALL(LAST_UPDATE_DATE) tablespace <IDX_TABLESPACE>;

CREATE index AP.OBIEE_AP_INVOICES_ALL ON AP.AP_INVOICES_ALL(LAST_UPDATE_DATE) tablespace <IDX_TABLESPACE>;

CREATE index GL.OBIEE_GL_JE_HEADERS ON GL.GL_JE_HEADERS (LAST_UPDATE_DATE) tablespace <IDX_TABLESPACE>;

CREATE index ONT.OBIEE_OE_ORDER_HEADERS_ALL ON ONT.OE_ORDER_HEADERS_ALL(LAST_UPDATE_DATE) tablespace <IDX_TABLESPACE>;

CREATE index PER.OBIEE_PAY_INPUT_VALUES_F ON PER.PAY_INPUT_VALUES_F (LAST_UPDATE_DATE) tablespace <IDX_TABLESPACE>;

CREATE index PER.OBIEE_PAY_ELEMENT_TYPES_F ON PER.PAY_ELEMENT_TYPES_F (LAST_UPDATE_DATE) tablespace <IDX_TABLESPACE>;

CREATE index PO.OBIEE_RCV_SHIPMENT_LINES ON PO.RCV_SHIPMENT_LINES (LAST_UPDATE_DATE) tablespace <IDX_TABLESPACE>;

CREATE index PO.OBIEE_RCV_SHIPMENT_HEADERS ON PO.RCV_SHIPMENT_HEADERS (LAST_UPDATE_DATE) tablespace <IDX_TABLESPACE>;

CREATE index AR.OBIEE_AR_CASH_RECEIPTS_ALL ON AR.AR_CASH_RECEIPTS_ALL (LAST_UPDATE_DATE) tablespace <IDX_TABLESPACE>;

CREATE index WSH.OBIEE_WSH_DELIVERY_DETAILS ON WSH.WSH_DELIVERY_DETAILS (LAST_UPDATE_DATE) tablespace <IDX_TABLESPACE>;

CREATE index WSH.OBIEE_WSH_NEW_DELIVERIES ON WSH.WSH_NEW_DELIVERIES (LAST_UPDATE_DATE) tablespace <IDX_TABLESPACE>;

注意:

  • 必ず、FND_STATSを使用して新規作成インデックスで統計を算出し、Oracle EBSデータベースの新規インデックス作成テーブル列で統計を更新してください。

  • この項においてDDLで作成されたインデックスすべてには接頭辞OBIEE_があります。この接頭辞は、標準のOracle EBSインデックス・ネーミング規則に従っていません。このため、Autopatchが今後のアップグレード中に失敗する場合があります。そのような場合は、OBIEE_接頭辞のインデックスを削除して、Autopatchを再起動する必要があります。

3.9.4.2 カテゴリ2テーブル用インデックスの作成

次のDDLにより、カスタム・インデックスをLAST_UPDATE_DATE列でカテゴリ2テーブル(つまり、Oracleリリース12のLAST_UPDATE_DATE列でインデックスが導入されたテーブル)用に作成します。

ソース・システムがOracle EBSリリース11iの場合は、このDDLスクリプトを実行する必要があります。

注意: ソース・システムが、Oracle EBSリリース11.5.10、Oracle EBSリリース11.5.9またはそれより以前のリリースの環境において、Oracle Applications Tablespace Model (OATM)に移行されている場合、<IDX_TABLESPACE>をAPPS_TS_TX_IDXで置換します。

DDLスクリプトは次のとおりです。

CREATE index PO.RCV_TRANSACTIONS_N23 ON PO.RCV_TRANSACTIONS (LAST_UPDATE_DATE) INITIAL 4K NEXT 2M MINEXTENTS 1 MAXEXTENTS 50 PCTINCREASE 0 INITRANS 2 MAXTRANS 255 PCTFREE 10 tablespace <IDX_TABLESPACE>;

CREATE index PO.PO_DISTRIBUTIONS_N13 ON PO.PO_DISTRIBUTIONS_ALL (LAST_UPDATE_DATE) INITIAL 4K NEXT 2M MINEXTENTS 1 MAXEXTENTS 50 PCTINCREASE 0 INITRANS 2 MAXTRANS 255 PCTFREE 10 tablespace <IDX_TABLESPACE>;

CREATE index PO.PO_LINE_LOCATIONS_N11 ON PO.PO_LINE_LOCATIONS_ALL (LAST_UPDATE_DATE) INITIAL 4K NEXT 2M MINEXTENTS 1 MAXEXTENTS 50 PCTINCREASE 0 INITRANS 2 MAXTRANS 255 PCTFREE 10 tablespace <IDX_TABLESPACE>;

CREATE index PO.PO_LINES_N10 ON PO.PO_LINES_ALL (LAST_UPDATE_DATE) INITIAL 4K NEXT 4K MINEXTENTS 1 MAXEXTENTS 50 PCTINCREASE 0 INITRANS 2 MAXTRANS 255 PCTFREE 10 tablespace <IDX_TABLESPACE>;

CREATE index PO.PO_REQ_DISTRIBUTIONS_N6 ON PO.PO_REQ_DISTRIBUTIONS_ALL (LAST_UPDATE_DATE) INITIAL 4K NEXT 250K MINEXTENTS 1 MAXEXTENTS 50 PCTINCREASE 0 INITRANS 4 MAXTRANS 255 PCTFREE 10 tablespace <IDX_TABLESPACE>;

CREATE index PO.PO_REQUISITION_LINES_N17 ON PO.PO_REQUISITION_LINES_ALL (LAST_UPDATE_DATE) INITIAL 4K NEXT 250K MINEXTENTS 1 MAXEXTENTS 50 PCTINCREASE 0 INITRANS 4 MAXTRANS 255 PCTFREE 10 tablespace <IDX_TABLESPACE>;

CREATE index PO.PO_HEADERS_N9 ON PO.PO_HEADERS_ALL (LAST_UPDATE_DATE) INITIAL 4K NEXT 1M MINEXTENTS 1 MAXEXTENTS 50 PCTINCREASE 0 INITRANS 2 MAXTRANS 255 PCTFREE 10 tablespace <IDX_TABLESPACE>;

CREATE index PO.PO_REQUISITION_HEADERS_N6 ON PO.PO_REQUISITION_HEADERS_ALL (LAST_UPDATE_DATE) INITIAL 4K NEXT 250K MINEXTENTS 1 MAXEXTENTS 50 PCTINCREASE 0 INITRANS 4 MAXTRANS 255 PCTFREE 10 tablespace <IDX_TABLESPACE>;

CREATE index AR.RA_CUSTOMER_TRX_N14 ON AR.RA_CUSTOMER_TRX_ALL (LAST_UPDATE_DATE) INITIAL 4K NEXT 4M MINEXTENTS 1 MAXEXTENTS 50 PCTINCREASE 0 INITRANS 4 MAXTRANS 255 PCTFREE 10 tablespace <IDX_TABLESPACE>;

注意: 必ず、FND_STATSを使用して新規作成インデックスで統計を算出し、Oracle EBSデータベースの新規インデックス作成テーブル列で統計を更新してください。

3.9.5 英語以外のOLTPデータ・ソースを使用したETLの実行

英語以外のOLTPデータ・ソースでETLを実行するには、適切なソース・システム・コンテナのコピーを作成し、言語、国、大陸の各パラメータを構成する必要があります。

英語以外のOLTPデータ・ソースでETLを実行するには

  1. DACで、「File」→「New Source System」を選択して「New Source System Container」ダイアログ・ボックスを表示します。

  2. 「Create as a Copy of Existing Container」ラジオ・ボタンを選択します。

  3. 「Existing Containers」ドロップダウン・リストで、コピーするコンテナを選択し、「OK」をクリックします。

  4. 「Design」ビューに移動します。

  5. 適切なコンテナが「Containers」ドロップダウン・リストで選択されていることを確認してください。

  6. 「Source System Parameters」タブを選択します。

  7. 「Source System Parameters」リストの下の「Edit」タブで、リスト内の次のパラメータの値を変更します。

    • $$DFLT_LANG(デフォルトの言語)–たとえば、日本語のデータ・ソースの場合は、この値をJPNに変更します。

    • (オプション)$$DFLT_COUNTRY(デフォルトの国)

    • (オプション)$$DFLT_CONTINENT(デフォルトの大陸)

    ヒント: $$DFLT_LANGパラメータに指定する値を特定するには、OLTPデータベースに対してクエリー「select VAL from S_SYS_PREF where SYS_PREF_CD=<ETL value>」を発行します。たとえば、デフォルトのETL言語を特定するには、次のコマンドを発行します。

    select VAL from S_SYS_PREF where SYS_PREF_CD='ETL Default Language';

  8. 新しいソース・システム・コンテナに新しいETLプランを作成し、そのパラメータを次のように編集します。

    1. 「Execute」タブをクリックします。

    2. 「Execution Plans」サブタブをクリックします。

    3. 「New」をクリックして空白の実行タブを新規に作成し、その下のサブタブ(「Subject Areas」、「Parameters」、「Ordered Tasks」など)を使用して、実行プランの詳細を指定します。

    4. 「Save」をクリックします。

  9. 「Run Now」をクリックして、新しいETLプランを実行します(または、「Schedule」タブを使用して、新しい実行プランを実行するタイミングを指定します)。

  前
前 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次		 索引へ移動
索引