| Oracle Business Intelligence Applications Informatica PowerCenterユーザーのためのアップグレード・ガイド リリース7.9.6.2 B61367-01 |
|
 戻る |
 次へ |
| Oracle Business Intelligence Applications Informatica PowerCenterユーザーのためのアップグレード・ガイド リリース7.9.6.2 B61367-01 |
|
戻る |
次へ |
|
注意: データベース・プラットフォームとソース・システムに関する情報の一部には、今回のリリースのOracle Business Intelligence Applicationsに適用されないものがあります。今回のリリースのOracle Business Intelligence Applicationsでサポートされているデータベースとソース・システムの最新情報は、『Oracle Business Intelligence Applicationsシステム要件およびサポートされるプラットフォーム』を参照してください。必ず、『Oracle Business Intelligence Applicationsリリース・ノート』も参照してください。これらのドキュメントの最新版は、Oracle Technology Network（http://www.oracle.com/technetwork/middleware/bi-foundation/documentation/index.html）にあります。Oracle Technology Networkの無料アカウントを登録するには、http://www.oracle.com/technology/about/index.htmlにアクセスしてください。 |
この章では、JD Edwards Enterprise Applicationsをソース・システムとして実行している場合にOracle BI Applicationsをアップグレードする手順について説明します。
この章の内容は次のとおりです。
第8.5項「Oracle BI ApplicationsおよびDACと連携するためのInformatica PowerCenterバージョン8.6.1の構成」
第8.8項「Teradataデータベースにおけるリリース7.9.6.2へのデータ・ウェアハウスのスキーマのアップグレードとデータの移行」
Oracle BI Infrastructureを、現行リリースのOracle BI Applicationsでサポートされているリリースにアップグレードします。『Oracle Business Intelligence Applicationsシステム要件およびサポートされるプラットフォーム』を参照し、サポートされている現行リリースを確認してください。サポートされているリリースのOracle BI Infrastructureをインストールする方法の詳細は、『Oracle Business Intelligence Infrastructureアップグレード・ガイド』を参照してください。
Oracle BI Applicationsのインストーラを実行して、Oracle BI Applications環境を現行リリースにアップグレードします。インストーラを実行する方法の詳細は、Oracle Business Intelligence Applications Informatica PowerCenterユーザーのためのインストレーション・ガイドを参照してください。
次の事項に注意してください。
Oracle Business Intelligence Applications Informatica PowerCenterユーザーのためのインストレーション・ガイドの第3章「Oracle BI Applicationsのインストール前およびデプロイメント前の要件」を参照してください。現行リリースのOracle BI Applicationsにアップグレードするには、これらの要件を満たす必要があります。
インストーラを実行する手順のみ実行してください。インストーラを実行した後における構成作業の指示は実行しないでください。
以前のリリースのOracle BI Applicationsがインストールされている場合、現行リリース用インストーラを実行する前に、アンインストールする必要があります。以前のリリースをアンインストールしないと、現行リリースのインストールでは一部のフォルダが適切にインストールされないことがあります（以前のリリースをアンインストールする前に、DACフォルダをバックアップしてください。これによって、DACのクライアントとサーバーおよびDACメタデータ・ファイルがバックアップされます）。
現行リリースのOracle BI Applicationsを実行するには、Informatica PowerCenter 8.6.1とHotfix 11をインストールする必要があります。現行バージョンのInformaticaをサポートするために必要な場合がある追加Hotfixや緊急Bug Fixの詳細は、『Oracle Business Intelligence Applicationsシステム要件およびサポートされるプラットフォーム』を参照してください。
Informatica PowerCenter 8.6.1のコンポーネントとアーキテクチャは、PowerCenter 7.xバージョンとは大幅に異なります。Oracle BI Applicationsに同梱されているInformatica DVDに収録されている、Informatica PowerCenter 8.6.1のドキュメントを熟読することをお薦めします。
Oracle BI ApplicationsのデプロイメントでInformatica PowerCenter 8.6.1を単一のマシンにインストールする際のインストール手順の概要は、Oracle Business Intelligence Applications Informatica PowerCenterユーザーのためのインストレーション・ガイドを参照してください。
Informatica PowerCenter 8.6.1をデプロイする方法の詳細は、『Informatica PowerCenter Installation Guide』、『Informatica PowerCenter Configuration Guide』、『Informatica PowerCenter Administrator Guide』および関連ドキュメントを参照してください。
Hotfix 11を適用する方法の詳細は、『PowerCenter Version 8.6.1 Hotfix 11 Release Notes』を参照してください。このPDFはInformatica PowerCenter DVDのInformaticaドキュメントに収録されており、Hotfix 11インストールにも含まれています。
Informatica PowerCenter 8.6.1にアップグレードするには:
『Informatica PowerCenter Installation Guide』に記載されているアップグレード前手順を実行します。
『Informatica PowerCenter Installation Guide』と『PowerCenter Version 8.6.1 HotFix 11 Release Notes』に記載されている指示に従って、Informatica PowerCenterバージョン8.6.1とHotfix 11をインストールします。
『Informatica PowerCenter Installation Guide』に記載されているアップグレード後手順を実行します。
次の事項に注意してください。
Informatica PowerCenter 8.6.1のインストール・プロセスには、現在使用しているInformaticaリポジトリをバージョン8.6.1形式にアップグレードする作業が含まれます。バージョン8.6.1のクライアント・ツールを使用して現在のリポジトリにアクセスし、第8.4項「Informaticaリポジトリのアップグレード」に記載されている手順を実行できるようにするためには、この手順が必要です。
第8.4項「Informaticaリポジトリのアップグレード」で、現在のリポジトリをバックアップして名前を変更してから、Oracle BI Applicationsのインストール中にインストールしたInformaticaリポジトリ（Oracle_BI_DW_Base.repなど）を復元します。カスタム・フォルダをバックアップ・リポジトリから新たに復元したOracle_BI_DW_Baseリポジトリにコピーします。
インストーラで「Install」オプションではなく「Upgrade」オプションを使用してInformatica PowerCenter 8.6.1をインストールする場合、$PMRootDirプロパティはアップグレードしたサービス・バージョン・インストール・ディレクトリに合わせて更新されません。DACでInformaticaソース・ファイルを検索できるようにするには、アップグレードしたサービス・インストール・ディレクトリを指定するようにこのプロパティを構成する必要があります。
$PMRootDirプロパティを構成するには、Informatica管理コンソールを起動してから「Integration Service」をNavigatorで選択し、「Processes」タブ→「Edit」をクリックして、$PMRootDirの適切な値を入力します。
次の手順に従って、Informaticaリポジトリをアップグレードします。
Informaticaリポジトリをバックアップして復元する方法の詳細は、『Informatica PowerCenter Administrator Guide』の第8章「Managing the Repository」で「Backing Up and Restoring the Repository」を参照してください。このドキュメントは、Oracle BI Applicationsに同梱されているInformatica DVDに収録されています。
Informaticaリポジトリをアップグレードするには:
現在使用しているInformaticaリポジトリをバックアップしてから名前を変更してあることを確認します。
|
注意: 第8.3項「Informatica PowerCenterバージョン8.6.1とHotfix 11へのアップグレード」に記載された手順を実行する際に、このリポジトリをバージョン8.6.1形式にアップグレードする必要があります。カスタム・フォルダを、このリポジトリから次の手順で復元する新規Oracle_BI_DW_Baseリポジトリに移動するには、このリポジトリをバージョン8.6.1形式にアップグレードする必要があります。 |
Oracle_BI_DW_Base.repファイルをOracleBI\dwrep\Informatica\Repositoryフォルダから<PowerCenter_installation_Directory>\server\infa_shared\Backupフォルダにコピーします。
|
注意: 第8.2項「Oracle BI Applicationsのアップグレード」で説明されているように、Oracle BI Applicationsインストーラを実行すると、Oracle_BI_DW_Base.repファイルはOracleBIのルート・ディレクトリにインストールされます。 |
Oracle_BI_DW_Base.repリポジトリを空のスキーマに復元します。
カスタム・フォルダを、以前使用していたInformaticaリポジトリから新規に作成したInformaticaリポジトリにコピーします。
Informatica PowerCenter Repository Managerを起動して、以前使用していたInformaticaリポジトリと新規作成のInformaticaリポジトリの両方に接続します。
以前使用していたリポジトリのカスタム・フォルダを、新規作成のInformaticaリポジトリにコピーします。
カスタム・フォルダの各マッピングに対して個別にワークフローが存在していることを確認します。
Informatica PowerCenterバージョン8.6.1をOracle BI ApplicationsおよびDACと連携させるには、さらに構成する必要があります。それらの手順を実行する方法の詳細は、Oracle Business Intelligence Applications Informatica PowerCenterユーザーのためのインストレーション・ガイドで次に関する項を参照してください。
ソース・ファイルと検索ファイルのコピー
PowerCenter統合サービスの弛緩コード・ページ検証の設定
PowerCenter統合サービス・カスタム・プロパティの設定
ネイティブ・セキュリティ・ドメインにおけるリポジトリ管理者ユーザーの作成
この項では、DACのアップグレードと構成で従う必要のある情報について説明します。この項の内容は次のとおりです。
第8.6.1項「DACプラットフォームとOracle BI Applicationsメタデータ・リポジトリファイルのインストール」
第8.6.2項「Oracle BI ApplicationsおよびInformaticaと連携するためのDACのクライアントとサーバーの構成」
現行リリースのDACはそのインストーラによりインストールされますが、Oracle BI Applicationsのインストーラではインストールされません。現行リリースのOracle BI ApplicationsでサポートされているDACプラットフォームのリリースの詳細は、『Oracle Business Intelligence Applicationsシステム要件およびサポートされるプラットフォーム』を参照してください。
DACをインストールしたら、メタデータ・ファイルを、Oracle BI ApplicationsをホスティングするマシンからDACのクライアントとサーバーをホスティングするマシンにコピーする必要があります。その上で、新しいメタデータをDACリポジトリにインポートする必要があります。それらのタスクを実行する方法の詳細は、Oracle Business Intelligence Applications Informatica PowerCenterユーザーのためのインストレーション・ガイドで次に関する項を参照してください。
DACプラットフォームのインストール
|
注意: JDBCドライバのインストール、ODBCデータベース接続の作成、pmrepとpmcmdのコマンドライン・プログラムのインストールなど、この項に記載された手順のすべてを実行する必要があります。 |
DACメタデータ・ファイルのインストール
DACへの初回ログインとDACリポジトリへのメタデータのインポート
この手順の実行が完了すると、Oracle BI Applicationsリリース7.9.6.2用にデフォルトのDACリポジトリが作成されます。
DACのクライアントとサーバーがOracle BI ApplicationsやInformatica PowerCenterと連携できるように構成タスクを実行する必要があります。それらのタスクを実行する方法の詳細は、Oracle Business Intelligence Applications Informatica PowerCenterユーザーのためのインストレーション・ガイドで次に関する項を参照してください。
DACサーバーの構成
DAC統合設定の構成
SiebelUnicodeDBカスタム・プロパティの構成
|
注意: ソースからターゲットにデータを移行する構成がUnicodeからUnicodeに移行する構成である場合にのみ、この手順が必要です。 |
電子メール通知を受信するためのDACの設定
追加構成タスク
この項では、ご使用の環境に適用されるタスクのみを実行してください。
DACのUpgrade/Merge WizardのRefresh Baseオプションを使用して、既存のDACリポジトリをアップグレードします。Upgrade/Merge WizardのRefresh Baseオプションを使用する方法の詳細は、Oracle Business Intelligenceデータ・ウェアハウス管理コンソール・ユーザーズ・ガイドの第10章「DACリポジトリのアップグレード、比較およびマージ」でRefresh Baseオプションの概要に関する項を参照してください。
Oracle Business Intelligenceデータ・ウェアハウス管理コンソール・ユーザーズ・ガイドは、Oracle Technology NetworkのOracle Business Intelligenceデータ・ウェアハウス管理コンソール用ドキュメント・ライブラリで入手できます。
DACリポジトリをアップグレードする前に、次を実行してください。
デフォルトのソース・システム・コンテナをコピーします。事前構成済のコンテナにあるメタデータは変更できません。格納されているオブジェクトを変更できるようにするには、コピーする必要があります。詳細は、Oracle Business Intelligenceデータ・ウェアハウス管理コンソール・ユーザーズ・ガイドを参照してください。
Oracle BI Applicationsのリリース7.9.6またはリリース7.9.6.1からリリース7.9.6.2にアップグレードする場合、この項に記載された手順を実行します。
第8.7.1項「リリース7.9.6からリリース7.9.6.1へのデータ・ウェアハウスのスキーマのアップグレードとデータの移行」（Oracleデータベースをデータ・ウェアハウス・データベースとして使用している場合にのみ適用）
第8.7.2項「非Teradataデータベースにおけるリリース7.9.6.1からリリース7.9.6.2へのデータ・ウェアハウスのスキーマのアップグレードとデータの移行」
現在Oracle BI Applicationsリリース7.9.6を実行している場合、第8.7.1項と第8.7.2項の手順を実行する必要があります。
現在Oracle BI Applicationsリリース7.9.6.1を実行している場合、第8.7.2項の手順を実行する必要があります。
この項に記載された手順に従って、データ・ウェアハウスのスキーマをリリース7.9.6.1にアップグレードし、データを移行します。
|
注意: Oracleデータベースをデータ・ウェアハウス・データベース用に使用している場合にのみ、この項に記載された手順が適用されます。 |
この項の内容は次のとおりです。
次の手順に従って、データ・ウェアハウスのスキーマをリリース7.9.6.1にアップグレードします。
データ・ウェアハウスのスキーマをリリース7.9.6.1用のスキーマにアップグレードするには:
7961_UPGRADE_DROP_INDEXES.sqlスクリプトを実行します。
データベースタイプに対応するSQLクライアントを起動します。
OracleBI\dwrep\Upgrade\DbScripts\Oracleフォルダにナビゲートします。
7961_UPGRADE_DROP_INDEXES. sqlファイルを開いてから、ファイルの内容をSQLクライアントにコピーします。
スクリプトを実行します。
UPGRADE_7961.ctlスクリプトを実行します。詳細は、付録F「DDLimpユーティリティを使用したCTLファイルの実行」を参照してください。
796ORA_TO_7961ORA_UPGRADE_PRE_CTL_SCRIPT.sqlを実行します。このファイルは、OracleBI\dwrep\Upgrade\DbScripts\Oracleフォルダにあります。
ddl_7961.ctlスクリプトを実行します。詳細は、付録F「DDLimpユーティリティを使用したCTLファイルの実行」を参照してください。
次の手順に従って、アップグレードしたデータ・ウェアハウスにデータを移行します。
アップグレードしたデータ・ウェアハウスにデータを移行するには:
7961_UPGRADE_PRE_DIMENSION_SCRIPT.sqlスクリプトを実行します。このファイルは、OracleBI\dwrep\Upgrade\DbScripts\Oracleにあります。
reset_infa_seq_gen.batスクリプトを使用して、アップグレード・リポジトリ上で増分実行するために、Informatica Sequence Generatorを初期化します。詳細は、付録E「アップグレードInformaticaリポジトリ上でのreset_infa_seq_gen.batファイルの実行」を参照してください。
Informaticaパラメータ・ファイルの7961_UPG_PARAMS.txtを構成します。詳細は、付録A「7961_UPG_PARAMS.txtにおけるパラメータの設定」を参照してください。
Oracle Financial Analyticsをアップグレードしている場合、固有のパラメータを構成しマッピングを更新する必要があります。詳細は、第B.1項「Oracle Financial Analytics用の796_UPG_PARAMS.txtにおけるパラメータおよびマッピングの構成」を参照してください。
JD Edwardsリリース8.11または8.12を使用している場合、Informatica Workflow Managerで、UPGRADE_796_to_7961_JDE_811SP1_812フォルダにナビゲートします。まず、UPGRADE_DIMENSIONSワークフローを実行してから、UPGRADE_FACTSワークフローを実行します。
JD Edwardsリリース9を使用している場合、Informatica Workflow Managerで、UPGRADE_796_to_7961_JDE_90フォルダにナビゲートします。そして、UPGRADE_DIMENSIONSワークフローを実行してから、UPGRADE_FACTSワークフローを実行します。
reset_infa_seq_gen.batスクリプトを使用して、ベースのInformaticaリポジトリ（たとえば、Oracle_BI_DW_Base.rep）上で増分実行するために、Informatica Sequence Generatorを初期化します。詳細は、付録E「ベースのInformaticaリポジトリ上でのreset_infa_seq_gen.batファイルの実行」を参照してください。
7961_UPGRADE_POST_SCRIPT.sqlを実行します。このファイルは、OracleBI\dwrep\Upgrade\DbScripts\Oracleにあります。
次の手順に従って、アップグレードしたデータ・ウェアハウスにデータが正常に移行されたことを確認します。
データが正常に移行されたことを確認するには:
<PowerCenter_Installation_Directory>\server\infa_shared\Sesslogsディレクトリに格納されたInformaticaマッピング・ログファイルを調べて、エラーや失敗を示すログがないことを調べます。
データベースのSQLクライアントにおいて実行した次のスクリプトで実行中に障害やエラーが発生したかどうかを確認します。
7961_UPGRADE_DROP_INDEXES.sql
796ORA_TO_7961ORA_UPGRADE_PRE_CTL_SCRIPT.sql
7961_UPGRADE_PRE_DIMENSION.sql
7961_UPGRADE_POST_SCRIPT.sql
DDLimpコマンドを使用して実行したddl_7961.ctlスクリプトとUpgrade_7961.ctlスクリプトのログファイルを調べて、実行が失敗したかどうかを確認します。
前述の手順でエラーや実行失敗が検出されなかった場合、データの移行は正常に実行されたことを示します。
|
注意: テーブルやインデックスがデータベースから削除できないことを示すエラー・メッセージは無視してください。指定されたオブジェクトがデータベースに存在しない場合、これらのエラー・メッセージが表示されます。各ソース・システム・コンテナにすべてのデータ・ウェアハウス・テーブルのサブセットが格納されているため、この現象が発生する場合があります。 |
データの移行が正常に実行された場合、アップグレード・プロセス中に作成したテーブル（W_xxxx_x_79x、LKP_xxxx_x、79x_XXXX_TMPなど）を削除します。
この手順によって、前述のバックアップ・テーブルで使用していたディスク領域が解放されます。
この項で説明する手順は次のとおりです。
次の手順に従って、データ・ウェアハウスのスキーマをリリース7.9.6.2にアップグレードします。
データ・ウェアハウスのスキーマをリリース7.9.6.2用のスキーマにアップグレードするには:
インデックスの削除と作成を行うスクリプトを生成します。詳細は、第C.1項「インデックスの削除および作成のためのスクリプトの生成」を参照してください。
すべてのインデックスを削除するためのスクリプトを実行します。詳細は、第C.2項「すべてのインデックスの削除のためのスクリプトの実行」を参照してください。
SQL Serverデータベースを使用している場合、7962_UPGRADE_PRE_UPG_CTL_SCRIPT.sqlスクリプトを実行します。このファイルは、OracleBI\dwrep\Upgrade\DbScripts\SQLServerにあります。
UPGRADE_7962.ctlスクリプトを実行します。付録F「DDLimpユーティリティを使用したCTLファイルの実行」
7962_UPGRADE_PRE_CTL_SCRIPT.sqlを実行します。このファイルは、OracleBI\dwrep\Upgrade\DbScripts\<database type>フォルダにあります。
DDL_7962.ctlスクリプトを実行します。詳細は、付録F「DDLimpユーティリティを使用したCTLファイルの実行」を参照してください。
次の手順に従って、アップグレードしたデータ・ウェアハウスにデータを移行します。
アップグレードしたデータ・ウェアハウスにデータを移行するには:
7962_UPGRADE_PRE_DIMENSION_SCRIPT.sqlスクリプトを実行します。このファイルは、OracleBI\dwrep\Upgrade\DbScripts\<database type>にあります。
reset_infa_seq_gen.batスクリプトを使用して、アップグレード・リポジトリ上で増分実行するために、Informatica Sequence Generatorを初期化します。詳細は、付録E「アップグレードInformaticaリポジトリ上でのreset_infa_seq_gen.batファイルの実行」を参照してください。
Informaticaパラメータ・ファイルの7962_UPG_PARAMS.txtを構成します。詳細は、付録A「7962_UPG_PARAMS.txtにおけるパラメータの設定」を参照してください。
ETLインデックスを作成するためのスクリプトを実行します。詳細は、第C.3項「ETLおよびクエリー・インデックスの作成のためのスクリプトの実行」を参照してください。
Informatica Workflow Managerで、UPGRADE_7961_to_7962_JDEフォルダにナビゲートします。そして、UPGRADE_DIMENSIONSワークフローを実行してから、UPGRADE_FACTSワークフローを実行します。
reset_infa_seq_gen.batスクリプトを使用して、ベースのInformaticaリポジトリ（たとえば、Oracle_BI_DW_Base.rep）上で増分実行するために、Informatica Sequence Generatorを初期化します。詳細は、付録E「ベースのInformaticaリポジトリ上でのreset_infa_seq_gen.batファイルの実行」を参照してください。
クエリー・インデックスを作成するためのスクリプトを実行します。詳細は、第C.3項「ETLおよびクエリー・インデックスの作成のためのスクリプトの実行」を参照してください。
次の手順に従って、アップグレードしたデータ・ウェアハウスにデータが正常に移行されたことを確認します。
データが正常に移行されたことを確認するには:
<PowerCenter_Installation_Directory>\server\infa_shared\Sesslogsディレクトリに格納されたInformaticaマッピング・ログファイルを調べて、エラーや失敗を示すログがないことを調べます。
データベースのSQLクライアントにおいて実行した次のスクリプトで実行中に障害やエラーが発生したかどうかを確認します。
dropallindexes.sql
7962_UPGRADE_PRE_CTL_SCRIPT.sql
7962_UPGRADE_PRE_DIMENSION.sql
createETLIndexes.sql
createQueryIndexes.sql
DDLimpコマンドを使用して実行したddl_7962.ctlスクリプトとUpgrade_7962.ctlスクリプトのログファイルを調べて、実行が失敗したかどうかを確認します。
前述の手順でエラーや実行失敗が検出されなかった場合、データの移行は正常に実行されたことを示します。
|
注意: テーブルやインデックスがデータベースから削除できないことを示すエラー・メッセージは無視してください。指定されたオブジェクトがデータベースに存在しない場合、これらのエラー・メッセージが表示されます。各ソース・システム・コンテナにすべてのデータ・ウェアハウス・テーブルのサブセットが格納されているため、この現象が発生する場合があります。 |
データの移行が正常に実行された場合、アップグレード・プロセス中に作成したテーブル（W_xxxx_x_79x、LKP_xxxx_x、79x_XXXX_TMPなど）を削除します。
この手順によって、前述のバックアップ・テーブルで使用していたディスク領域が解放されます。
アップグレードしたデータ・ウェアハウスにデータが正常に移行したことを確認したら、次の手順に従ってリフレッシュの日付をリセットします。
JD Edwardsリリース8.11または8.12を使用している場合、Informatica Workflow Managerで、UPGRADE_7961_to_7962_JDE_811SP1_812フォルダにナビゲートして、RESET_DAC_REFRESH_DATESワークフローを実行します。
JD Edwardsリリース9を使用している場合、Informatica Workflow Managerで、UPGRADE_7961_to_7962_JDE90フォルダにナビゲートして、RESET_DAC_REFRESH_DATESワークフローを実行します。
7962_RESET_REFRESH_DATES.txtファイルをOracleBI\dwrep\Upgrade\Informatica\SrcFilesフォルダで探します。
次の手順で、7962_RESET_REFRESH_DATES.txtに記載されているテーブルに対してリフレッシュの日付をNULLにリセットします。
DACで、次を実行します。
Setupビューにナビゲートし、Physical Data Sourcesタブをクリックします。
上部のペイン・リストで、「DataWarehouse」を選択します。データ・ウェアハウスの接続名をカスタマイズした場合、データ・ウェアハウスのデータベースに対する適切な接続を選択します。
Refresh Datesサブタブ（下部のペイン）をクリックします。
7962_RESET_REFRESH_DATES.txtファイルに一覧されているテーブルに対してクエリーを実行し、テーブルごとにRefresh Dateカラムの値をNULLに設定します。
前述のデータ移行手順が完了した場合、誤って使用したり混同しないように、アップグレード・リポジトリを削除できます。
Informatica PowerCenter管理コンソールで、「Upgrade」リポジトリ・サービスを選択します。
「Properties」タブの「General Properties」領域で、「Edit」をクリックします。
リポジトリ・サービスのオペレーティング・モードが「Exclusive」に設定されていることを確認します。
「OK」をクリックします。
「Actions」を選択し、「Delete Contents」をクリックします。
「Delete contents for <repository name>」ダイアログで、リポジトリのユーザー名とパスワードを入力（たとえば、「Administrator」と「Administrator」）してから、「OK」をクリックします。
データ・ウェアハウスのデータベース・プラットフォームがTeradataの場合、この項の手順に従って、Oracle Business Applicationsのリリース7.9.6.1からリリース7.9.6.2にアップグレードします。
Teradataデータベースのデータ・ウェアハウスのスキーマをアップグレードし、データを移行するには:
7962_UPGRADE_TMP_TABLES.sqlスクリプトを実行します。
データベースタイプに対応するSQLクライアントを起動します。
OracleBI\dwrep\Upgrade\DbScripts\Teradataフォルダにナビゲートします。
<version>_UPGRADE_TMP_TABLES.sqlファイルを開いて、ファイルの内容をSQLクライアントにコピーします。
スクリプトを実行します。
データ・ウェアハウス・テーブルのカラムでデフォルト値がDACで指定されていないカラムに対して、グローバル・デフォルト値がNOT NULLでteradata.missing.defaults.propertiesファイルに格納されます。ご使用の環境に適合するようにteradata.missing.defaults.propertiesファイルでデフォルト値を変更できます。ファイルは、\bifoundation\dac\conf\sqlgen\sql\teradataにあります。
アップグレード・スクリプトをDACで生成します。
DACにログインします。
メニュー・バーで、Tools→ETL Management→Configureを選択します。
Sourcesダイアログ・ボックスで、ターゲット・データ・ウェアハウスのデータベース・プラットフォームとして「Teradata」を選択し、ソース・データ・ウェアハウスのデータベース・プラットフォームを選択します。
Data Warehouse Configuration WizardのConfigurationタブがアクティブになります。
Generate upgrade statements for Data Warehouse Tablesを選択し、Nextをクリックします。
Data Warehouse SQLタブがアクティブになります。
次を実行します。
- Teradataデータベースに対して適切な物理データソース名を選択します。
- Containerフィールドで、アップグレード・スクリプトを生成する対象となるカスタム・コンテナの名前を入力します。または、フィールドを空欄にして、すべてのコンテナに対してアップグレード・スクリプトを生成します。
Data Warehouse Configuration Wizardでは次のファイルが生成され、\bifoundation\DAC\conf\sqlgen\sql\teradataに格納されます。
upgrade-regular.sql: このファイルには、DACで確認した、データ・ウェアハウスのスキーマをアップグレードするために必要なスクリプトが格納されます。スクリプトにより新規または変更済のテーブルとカラムが処理されます。たとえば、シンプルなデータ型のサイズが大きくなったり、NULLのカラムがNULLでないように変更される場合があります。
upgrade-questionable.sql: このファイルには、DACで提示した、データ・ウェアハウスのスキーマをアップグレードするために必要になるスクリプトが格納されます。これらのスクリプトはアップグレード要件の確認に使用するものであり、Teradata DBAがその内容を見直して必要に応じて修正する必要があります。
upgradedwtables_sql.log: このファイルはupgrade-regular.sqlファイルに対応するログファイルです。情報提供のためにのみ存在します。
upgrade-issues.log: このファイルはupgrade-questionable.sqlファイルに対応するログファイルです。情報提供のためにのみ存在します。
upgrade-regular.sqlファイルとupgrade-questionable.sqlファイルを開いて次の文を検索し、追加されたり変更されたカラムを探します。
ALTER TABLE <Table Name> ADD <Column Name><attributes>;
ADDコマンドのあるカラムのすべてに対して、カラムが存在しているかどうかを調べます。存在する場合、STATISTICSが定義されているどうかを調べます。
STATISTICSが定義されているカラムのすべてに対して、カラム定義をバックアップしてから、STATISTICSを削除します。
upgrade-regular.sqlファイルにあるスクリプトを実行します。
upgrade-questionable.sqlファイルにあるスクリプトの内容を確認します。必要に応じてスクリプトを編集して、実行します。
STATISTICSを削除したカラムでSTATISTICSを再作成します。
7962_UPDATE_DEFAULTS.sqlスクリプトを実行します。
7962_Backup_Tables.sqlスクリプトを実行します。
reset_infa_seq_gen.batスクリプトを使用して、アップグレード・リポジトリ上で増分実行するために、Informatica Sequence Generatorを初期化します。
Informaticaパラメータ・ファイルの7962_UPG_PARAMStxtを構成します。詳細は、付録A「7962_UPG_PARAMS.txtにおけるパラメータの設定」を参照してください。
JD Edwardsリリース8.11または8.12を使用している場合、Informatica Workflow Managerで、UPGRADE_7961_to_7962_JDE_811SP1_812フォルダにナビゲートし、指定された順序で次のワークフローを実行します。
UPGRADE_DIMENSIONS
UPGRADE_FACTS
RESET_DAC_REFRESH_DATES
JD Edwardsリリース9を使用している場合、Informatica Workflow Managerで、UPGRADE_7961_to_7962_JDE90フォルダにナビゲートし、指定された順序で次のワークフローを実行します。
UPGRADE_DIMENSIONS
UPGRADE_FACTS
RESET_DAC_REFRESH_DATES
reset_infa_seq_gen.batスクリプトを使用して、ベースのInformaticaリポジトリ（たとえば、Oracle_BI_DW_Base.rep）上で増分実行するために、Informatica Sequence Generatorを初期化します。詳細は、付録E「ベースのInformaticaリポジトリ上でのreset_infa_seq_gen.batファイルの実行」を参照してください。
7962_RESET_REFRESH_DATES.txtファイルをOracleBI\dwrep\Upgrade\Informatica\SrcFilesフォルダで探します。
次の手順で、7962_RESET_REFRESH_DATES.txtに記載されているテーブルに対してリフレッシュの日付をNULLにリセットします。
DACで、次を実行します。
Setupビューにナビゲートし、Physical Data Sourcesタブをクリックします。
上部のペイン・リストで、「DataWarehouse」を選択します。データ・ウェアハウスの接続名をカスタマイズした場合、データ・ウェアハウスのデータベースに対する適切な接続を選択します。
Refresh Datesサブタブ（下部のペイン）をクリックします。
7962_RESET_REFRESH_DATES.txtファイルに一覧されているテーブルに対してクエリーを実行し、テーブルごとにRefresh Dateカラムの値をNULLに設定します。
前述のデータ移行手順が完了した場合、誤って使用したり混同しないように、アップグレード・リポジトリを削除できます。
Informatica PowerCenter管理コンソールで、「Upgrade」リポジトリ・サービスを選択します。
「Properties」タブの「General Properties」領域で、「Edit」をクリックします。
リポジトリ・サービスのオペレーティング・モードが「Exclusive」に設定されていることを確認します。
「OK」をクリックします。
「Actions」を選択し、「Delete Contents」をクリックします。
「Delete contents for <repository name>」ダイアログで、リポジトリのユーザー名とパスワードを入力（たとえば、「Administrator」と「Administrator」）してから、「OK」をクリックします。
この項のプロセスにより、以前のリリースのOracle BIリポジトリにおけるカスタマイズ内容を、新しいリリースのOracle BIリポジトリとマージします。このプロセスを開始する前に、既存のリポジトリをバックアップしてから名前を変更してあることを確認してください。
リポジトリをアップグレードするために行う作業は次のとおりです。
この項に記載している作業では、複数のバージョンのOracle BIリポジトリについて言及しています。表8-1には、この項の例で使用しているリポジトリの名前と説明が記載されています。
表8-1 例で使用されているAnalyticsリポジトリの名前
| リポジトリの名前 | 説明 |
|---|---|
|
OracleBIAnalyticsApps_793.rpd |
アップグレード元リリース用の標準Oracle BIリポジトリです。 注意: 以前のリリースの標準リポジトリは、\OracleBI\Upgradeフォルダで利用できます。 |
|
OracleBIAnalyticsApps.rpd |
アップグレード先リリース用の標準Oracle BIリポジトリです。 |
|
Customer_OracleBIAnalyticsApps.rpd |
アップグレード元リリース用のカスタマイズ内容のあるOracle BIリポジトリです。 |
|
Merged_Repository_OracleBI.rpd |
アップグレード先リリース用のカスタマイズ内容のあるOracle BIリポジトリです。 |
次の手順に従って、リポジトリのアップグレードを準備します。
Analyticsリポジトリのアップグレードを準備するには:
マージ・プロセス用のディレクトリ（\OracleBIUpgradeなど）を設定し、次のサブフォルダを作成します。
Original
AfterEqualize
AfterMerge
AfterManualWork
AfterRegressions
元のリポジトリ（たとえば、OracleBIAnalyticsApps_793.rpd）、本番リポジトリ（たとえば、Customer_OracleBIAnalyticsApps.rpd）および最新インストールのリポジトリ（たとえば、OracleBIAnalyticsApps.rpd）を、\OracleBIUpgrade\Originalフォルダにコピーします。
現在使用している環境において、Oracle BIリポジトリを使用しているモジュールが1つ以上あるOracle BI Applicationsが実行しており、そのOracle BIリポジトリは、標準のOracle BIリポジトリファイル（以前のリリースに付属していたもの）からモジュールのために対応プロジェクトを抽出したものである場合、OracleBIAnalyticsApps_793.rpdファイルから同じプロジェクトを抽出してから元のリポジトリとして使用する必要があります。前回アップグレードしたときに抽出に使用した元のリポジトリがある場合、元のリポジトリファイルとして使用できます。これによって、今回アップグレードする際に追加する新規メタデータの喪失が防止されます。
また、大量のオブジェクトを削除することでカスタマイズしたOracle BIリポジトリがある場合に、これらのオブジェクトを今回のアップグレードで元に戻すためには、OracleBIAnalyticsApps_793.rpdファイルで同様に削除処理し、削除処理したファイルを元のリポジトリファイルとして使用する必要があります。これによって、今回アップグレードする際に追加する新規メタデータの喪失が防止されます。
Administration Toolのマージ機能は変更検出アルゴリズムに基づいています。このアルゴリズムによって、リポジトリを適切にアップグレードするために適用が必要な変更を調べます。このアルゴリズムが適切に動作するためには、3つのリポジトリ（たとえば、OracleBIAnalyticsApps_793.rpd、OracleBIAnalyticsApps.rpd、Customer_OracleBIAnalyticsApps.rpd）にあるオブジェクトで同等なオブジェクトを調べる必要があります。
この手順のポイントは、OracleBIAnalyticsApps.rpdとCustomer_OracleBIAnalyticsApps.rpdにあるすべてのオブジェクトが、OracleBIAnalyticsApps_793.rpdから派生したものであるかどうかを調べることです。
Administration Toolの同等化機能を使用して、これらのオブジェクトにおいて同等化の処理を行います。出力オプション（-O）で指定したファイルは、同等化プロセス中に変更される唯一のファイルになります。
同等化機能には、次に示すようなメカニズムがあります。これらのメカニズムによって、別々のリポジトリにあるオブジェクトがセマンティクス的に同等であるかどうかを調べます。
完全修飾名: あるリポジトリにあるオブジェクトの完全修飾名が、別のリポジトリにある同じクラスに属する別のオブジェクトの完全修飾名と同じ場合、これらのオブジェクトは同等であると宣言されます。
単純文字列置換: 別々のリポジトリにある同じクラスに属する別々のオブジェクトで、オブジェクトの名前が異なっていてもキーとなる文字のみが異なる場合、それらのオブジェクトは同等であると宣言できます。equalizerpds実行可能ファイルでは、完全修飾名のチェックの際にこれらの文字は無視されます。たとえば、「_」と「 」の文字が同等であると宣言されている場合、"Core"."W_DAY_D"は"Core"."W DAY D"と同等であるとみなすことができます。
名前変更ファイル: 前述に示したルールが適用されない場合、equalizerpds実行可能ファイルへの入力としてスクリプトを使用すると、手動で同等と宣言できます。主要なリリースに対応する名前変更ファイル（MAP）が付属しています。これらのファイルは、OracleBI\Upgradeフォルダにあります。また、製品に付属している名前変更ファイルで対応しないカスタマイズがある場合、独自の名前変更ファイルも作成できます。名前変更ファイルはMicrosoft Excelで開いて編集できます。
表8-2には、使用できるMAPファイルとファイルに関連するSiebel AnalyticsリリースやOracle BI Applicationsリリースの一覧が記載されています。
表8-2 様々なリリースに使用されるMAP名前変更ファイル
| Siebel AnalyticsリリースまたはOracle Business Intelligence Applicationsリリース（DWリリースからのアップグレード） | 使用されるMAP名前変更ファイル |
|---|---|
|
Siebel Business Analytics Applications 7.0.x |
利用できない |
|
Siebel Business Analytics Applications 7.5.x |
利用できない |
|
Siebel Business Analytics Applications 7.7.x（リリース7.7.0より前のリリースのSiebel CRM OLTP） |
Rename77-7962.map |
|
Siebel Business Analytics Applications 7.7.x（Siebel CRM OLTPリリース7.7.0） |
Rename771-7962.map |
|
Siebel Business Analytics Applications 7.8.2、およびこのリリースより前のすべての7.8.xリリース |
Rename782-7962.map |
|
Siebel Business Analytics Applications 7.8.3、およびこのリリースより後のすべての7.8.xリリース |
Rename783-7962.map |
|
Oracle BI Applications 7.9.0 |
Rename79x-7962.map |
|
Oracle BI Applications 7.9.1 |
Rename79x-7962.map |
|
Oracle BI Applications 7.9.2 |
Rename79x-7962.map |
|
Oracle BI Applications 7.9.3 |
Rename793to7962.map |
|
Oracle BI Applications 7.9.4 |
Rename794to7962.map |
|
Oracle BI Applications 7.9.5 |
Rename79x-7962.map |
|
Oracle BI Applications 7.9.5.1 |
Rename7951to7962.map |
|
Oracle BI Applications 7.9.5.2 |
Rename7951to7962.map |
|
Oracle BI Applications 7.9.6 |
Rename79x-7962.map |
|
Oracle BI Applications 7.9.6.2 |
利用できない |
equalizerpdsコマンドの構文を次に示します。
equalizerpds.exe -A userid1 [-B [password1]] -C base_repository_name -D userid2 [-E [password2]] -F repository2_name [-J udml_utf8_file_name_equalization] [-O ouput_repository_name] [-X] [-Y equalStringSet] -X Treat 'Factxxxx' as 'Fact' in Business Model. -Y Treat the characters as equals. /? Display this usage information and exit.
リポジトリの同等化を行うには:
適切なMAPファイルをOracleBI\Upgradeフォルダからequalizerpds.exe実行用フォルダ（たとえば、\OracleBIUpgrade\Original）にコピーします。
equalizerpds.exeを実行して、最新インストールのリポジトリ（たとえば、OracleBIAnalyticsApps.rpd）と元のリポジトリ（たとえば、OracleBIAnalyticsAppss_793.rpd）の同等化を行います。equalizerpdsコマンドの例を次に示します。
equalizerpds -A Administrator -B SADMIN -C \\OracleBIUpgrade\Original\OracleBIAnalyticsApps_793.rpd -D Administrator -E SADMIN -F \\OracleBIUpgrade\Original\OracleBIAnalyticsApps.rpd -O \\OracleBIAnalyticsUpgrade\AfterEqualize\OracleBIAnalyticsApps.rpd -X -J rename7x-79.map
MAPファイルは、OracleBI\Upgradeフォルダにあります。
equalizerpds.exe実行可能ファイルが正常に実行されると、返されるエラーはありません。
equalizerpds.exeを実行して、カスタマイズ・リポジトリ（たとえば、Customer_OracleBIAnalyticsApps.rpd）と元のリポジトリ（たとえば、OracleBIAnalyticsApps_79x.rpd）の同等化を行います。equalizerpdsコマンドの例を次に示します。
equalizerpds -A Administrator -B SADMIN -C \\OracleBIUpgrade\Original\OracleBIAnalyticsApps_7x.rpd -D Administrator -E SADMIN -F \\OracleBIUpgrade\Original\Customer_OracleBIAnalyticsApps.rpd -O \\OracleBIUpgrade\AfterEqualize\Customer_OracleBIAnalyticsApps.rpd
カスタマイズ・リポジトリと元のリポジトリとの同等化を行うequalizerpdsを実行しても、名前変更ファイルは使用されません。
元のリポジトリは新しい場所において変更されずにコピーされていることを確認してください。これによって、スクリプト実行後、3つのリポジトリすべてが、\OracleBIUpgrade\AfterEqualizeディレクトリ内に格納されるようになります。
プロセスが正常に完了したことを確認するには、リポジトリのサイズを比較します。出力リポジトリ（-O）のサイズは、同等化（-F）を行ったリポジトリのサイズに近似した値になります。
次の手順に従って、新しいリリースのアップグレード先リポジトリと既存のリポジトリを比較します。
Analyticsリポジトリを比較するには:
Administration Toolのリポジトリ比較機能を使用して、新しいリリースのアップグレード先リポジトリと既存のリポジトリとの違いを分析します。新しいリリースのリポジトリにおいて要素が作成、削除または変更されている場所に注意してください。新しいメタデータを使用でき、既存のリポジトリにおけるカスタマイズ内容を廃棄できるかどうかを検討してください。
Administration Toolのリポジトリ比較機能を使用する方法の詳細は、『Oracle Business Intelligence Server管理ガイド』を参照してください。
この項の手順では、メインのアルゴリズムを実行してリポジトリをアップグレードします。リポジトリをマージする方法の詳細は、『Oracle Business Intelligence Server管理ガイド』を参照してください。
複数のバージョンのOracle BIリポジトリをマージするには:
3つのリポジトリ（たとえば、OracleBIAnalyticsApps_793.rpd、OracleBIAnalyticsApps.rpdおよびCustomer_OracleBIAnalyticsApps.rpd）をAfterMergeフォルダにコピーします。
\OracleBIUpgrade\AfterMergeフォルダにある最新インストール版リポジトリ（たとえば、OracleBIAnalyticsApps.rpd）を開きます。
リポジトリを別の名前（たとえば、Merged_Repository_OracleBIAnalyticsApps.rpd）で保存します。
新しく保存したリポジトリには、アップグレードの最終結果の内容が格納されます。
Administration Toolのメニュー・バーで、File→Mergeを選択します。
Select Original Repositoryダイアログ・ボックスで、元のリポジトリ（たとえば、OracleBIAnalyticsApps_793.rpd）を選択します。
パスワードを入力してからOKをクリックします。
Select for the Modified Repository fieldをクリックします。
Select Modified Repositoryダイアログ・ボックスで、以前のリリースのAnalyticsリポジトリに対するカスタマイズが含まれるリポジトリを選択します。
Openをクリックしてパスワードを入力し、OKをクリックします。
Decisionドロップダウン・リストで、リポジトリ変更に対応する操作を選択するか、デフォルト操作を受け入れます。
Decisionフィールドが空の後続の行を検出するには、Decisionヘッダー・セルをクリックします。
すべての行のDecisionフィールドに値が入力されると、Mergeボタンが有効になります。
Mergeをクリックします。
作業しているリポジトリのサイズによっては、このプロセスの所要時間が最大40分になる場合があります。マージが完了すると、メッセージにより通知が行われます。
一貫性チェックを実行する場合は、「はい」をクリックします。
一貫性チェックで返されたエラーの数により、マージ・プロセスの実行結果を判定します。発生したエラーの数が多い場合（たとえば、300個以上）、エラーの原因を分析する必要があります。マージ・プロセスにおいて別々のオブジェクトが同等であるとの認識に失敗したとき、名前変更ファイルの編集が必要になる場合があります。それは、現在使用しているリポジトリにオブジェクトがある場合です。また、多くのオブジェクトの名前を変更したが、アップグレード・エンジンでそれらを元のオブジェクトに関連付ける処理が失敗した場合、独自に名前変更ファイルを追加する必要が発生する場合があります。
また、マージを再実行する前に、Decisionドロップダウン・リストで選択した操作の変更が必要になる場合もあります。これによって、手作業での対処が必要なエラーの数が減少して、時間を節約できる場合があります。
マージの結果が満足できる水準に達しても、残りのエラーを手作業で対処する必要があります。次の手順に進む前に、すべてのエラーに対処することが重要です。このリポジトリは、次のステージの入力として使用します。
また、カスタマイズしたオブジェクトのすべてが存在していることと、重複した物理テーブルが存在しないことも確認する必要があります。重複した物理テーブルの有無を確認するには、次のようなクエリーを使用して物理テーブルを検索します。
where name like '*#1'
リポジトリを\OracleBIUpgrade\AfterManualWorkフォルダにコピーします。
リポジトリのマージで回帰テストを実行する目的は、レポートで使用される論理SQL文のセットを収集して、新しいメタデータで作業が続行されることを確認することです。このために、次の手順を実行することをお薦めします。
回帰テストを実行するには:
回帰テストにおいて含める必要があるレポートを実行します。これらのレポートは、Presentation Catalogにおけるレポートのサブセットの場合があります。
前述の手順で生成された論理SQL文を収集します。このために使用状況トラッキングを使用したり、クエリー・ログファイルを解析することができます。
使用状況トラッキングの詳細は、『Oracle Business Intelligence Server管理ガイド』を参照してください。
\OracleBI\server\binにあるnQCmd.exeコマンドライン・ユーティリティを使用して、論理SQL文を古いリポジトリに対して実行し、その結果をファイルに保存します。
nQCmd.exeユーティリティの詳細は、『Oracle Business Intelligence Server管理ガイド』を参照してください。
論理SQLテスト・スクリプトを編集して、アップグレードした結果による変更内容や名前の変更を無効にするように変更します。
編集した論理SQLテスト・スクリプトをマージ・リポジトリに対して実行し、その結果を保存します。
前述の手順で実行した結果を比較して、差異を解釈します。これらの差異の原因がアップグレード・プロセスによるものと判断した場合、手作業で対処する必要があります。
これによって、新しいOracleBIAnalyticsApps.rpdと本番リポジトリからマージされた内容が、このリポジトリに格納されます。
組織で次が実行されていた場合、現在使用しているOracle BI Presentation Catalogをアップグレードする必要があります。
ビルトイン・アプリケーションがすでにインストールされている場合
現在使用しているOracle BI Presentation Catalogをカスタマイズしてある場合
以前のバージョンのビルトイン・アプリケーションで配布されたPresentation Catalogに変更を加えていない場合は、カタログのアップグレードは必要ありません。新しいバージョンのカタログを使い始めることができます。
この項の内容は次のとおりです。
|
注意: Oracle BI Applicationsリリース7.9よりも前のリリースでは、Presentation Catalog（旧称はSiebel Analytics Web Catalog）は、個々のファイルのディレクトリ構造ではなく、単一のファイルに格納されていました。以前のリリースのPresentation Catalogがある場合は、新しいフォーマットに変換する必要があります。Presentation Catalogを新しいフォーマットに変換する方法の詳細は、『Oracle Business Intelligence Infrastructureアップグレード・ガイド』を参照してください。 |
現在使用しているPresentation Catalogをアップグレードしてから、新しいPresentation Catalogとマージする前に、保持対象となる既存の内容と組込み対象となる新しい内容を調べてください。既存のPresentation Catalogを調べて、レポートとダッシュボードの使用パターンを調査します。既存のカタログに事前構成済の内容のいくつかが、再設計されたフォーマットで新しいバージョンに表示される場合があることに注意してください。さらに、新しいバージョンには新しい内容がすべて格納されます。全社Presentation Catalogを構成する内容にすると判断したら、Catalog Managerを使用して入力カタログを調整します。カタログを調整する方法の詳細は、『Oracle Business Intelligence Presentation Services管理ガイド』を参照してください。
Presentation Catalogのアップグレード・プロセスでは、次に示す3つのカタログが使用されます。
オリジナルのPresentation Catalog: これは、変更されていないPresentation Catalogで、アップグレード元のOracle BI Applicationsリリースに付属していたカタログです。
新しいPresentation Catalog: これは、OracleBIData\web\catalogフォルダにインストールされているPresentation Catalogで、Oracle BI Applicationsのインストールに付属しているカタログです。
現在使用しているPresentation Catalog: これは、所属する組織で現在使用しているPresentation Catalogです。
このアップグレード・プロセスではCatalog Managerを使用します。Catalog Managerでは、現在使用しているPresentation Catalogと変更されているPresentation Catalogの両方の内容を、オリジナルのPresentation Catalogの内容と比較します。そして、現在使用しているPresentation Catalogに変更内容をマージしてから、アップグレードの差異に関する一覧を作成します。差異を処理する方法を示すことでこれらを解決する必要があります。カタログの内容が競合する場合、内容を優先的に取得する対象カタログを選択できます。最終結果は、マージされたPresentation Catalogになります。このカタログにはサイト固有の変更が反映され、新しいメタデータも同様に反映されます。
現在使用しているPresentation Catalogを新しいバージョンにアップグレードするには:
現在使用しているPresentation Catalogのバックアップ・コピーを作成します。そして、フォルダ名を<catalogname>_oldに変更してから一時的な場所に移動します。
オリジナルのPresentation Catalogを、現在使用しているPresentation Catalog格納用フォルダにコピーしてから、名前を<catalogname>_Originalに変更します。
Catalog Managerを起動してから、新しいPresentation Catalogをオフライン・モードで開きます。
Tools→Upgrade Catalogを選択します。
original Presentation Catalogフィールドで、オリジナルのPresentation Catalogの場所を探して参照します。
Current Presentation Catalogフィールドで、現在使用しているWeb Catalog（<catalogname>_old）の場所を探して参照します。
OKをクリックします。
アップグレードの差異を次のようにして解決します。
Unresolved差異リストでそれぞれの未解決差異を確認します。
それぞれの未解決差異で、保持するバージョンを選択します。
OKをクリックします。
SiebelAnalyticsMigrationLog.txtログファイルには、マージ・プロセスに関する情報が記録されます。このログファイルは、\OracleBI\web\catalogmanagerに書き込まれます。エラーがログファイルに記録されている場合、マージ・メカニズムでマージを解決できなかった問題が、該当のパスに存在することを意味します。何も対処は行われていません。特定の項目をマージするには、オリジナルのPresentation Catalogに移動してから手動でマージします。
アップグレードしたPresentation Catalogを調べ、必要に応じてオブジェクトの権限を設定します。
新しいPresentation Catalogを保存します。
|
注意: この項の手順を実行する前に、アップグレードしたデータ・ウェアハウスに最初にデータを移行する必要があります。 |
Presentation Catalogのアップグレード機能では、自動的にオブジェクトの権限が継承されません。したがって、この項の手順を実行する前に、Presentation Catalogオブジェクトの権限を確認する必要があります。
この手順によって、アップグレードされたレポートと事前構成済の新規レポートが適切に機能して、マージされた新規Presentation Catalog内で適切な結果にレンダリングされるようになります。この手順は一般的に、最初から最後までのすべてのアップグレード・プロセスを行った最終結果を目視で確認することで行います。
アップグレードされたレポートの場合、比較目的に行う適切な手法としては、複数の共存環境を用意して、ユーザーに対して特定のダッシュボード内容を別々の環境で確認するように依頼することがあります。アプリケーションのルック・アンド・フィールだけでなく、レポートに格納されるデータも調べて、内容が同一であることを確認します。日常業務を通常遂行する際に使用するユーザー・インタフェースの様々な要素を使用して結果を検証することを、ユーザーにリクエストすることをお薦めします。様々な要素の例としては、グローバルプロンプト、カラム・セレクタ、レポートフィルタ、ドリル、ナビゲーションなどがあります。
また、新しいPresentation Catalogにおいて全体的な表示設定と管理設定を調べて適切であることを確認してください。アップグレード中に移行した内容に対して確立した表示ルールに注意してください。これらの設定に関して手動での調整が必要になる場合があります。
