5 Oracle Business Activity Monitoringを含むOracle SOA Suiteの11gからのアップグレード
ノート:
BAM 12cリリースを含む、以前のOracle SOA Suiteからアップグレードする場合、 「Business Activity Monitoringを含むOracle SOA Suiteの以前の12cリリースからのアップグレード」を参照してください- Business Activity Monitoring 12c (12.2.1.4.0)へのアップグレードの理解
Oracle BAM 11gからBAM 12cへのアップグレードは、標準のアップグレード手順を使用することでは処理できません。いくつかの構成タスクを手動で実行して、アップグレードを完了する必要があります。 - Oracle BAM 11gを含むSOAのアップグレード・プロセス・フローの理解
- Oracle BAMのアップグレード前タスクの実行
- Oracle BAMドメインを含むSOAの12cへのアップグレード
Oracle BAMを含むSOA 11gドメインをOracle BAMを含むSOA 12c (12.2.1.4.0)ドメインにアップグレードするには、この手順を使用します。 - Oracle BAM 12cを含むOracle SOAでのアップグレード後構成タスクの実行
最終的にOracle BAM 12cを含むSOA 12cドメインを実行するには、アップグレード後に追加の構成タスクを実行する必要があります。 - Oracle BAM 12cを含むSOAドメインの拡張
アップグレードされたSOA 12c環境とともにOracle BAM 12cを使用する準備が整っている場合、BAM 12cテンプレートを含むようにドメインを拡張する必要があります。 - 失敗したOracle BAMアップグレードからのリカバリ
Business Activity Monitoring 12c (12.2.1.4.0)へのアップグレードの理解
Oracle BAM 11gからBAM 12cへのアップグレードは、標準のアップグレード手順を使用することでは処理できません。いくつかの構成タスクを手動で実行して、アップグレードを完了する必要があります。
ノート:
次の各項で説明している手順は、11gからのアップグレードにのみ適用されます。すでにアップグレード済の12cドメインをこの12cリリースにアップグレードする場合、「Oracle SOA SuiteおよびBusiness Process Managementの以前の12cリリースからのアップグレード」で説明されている標準アップグレード手順に従います。
Oracle Business Activity Monitoring (BAM) 12cは、Oracle SOA Suite 12cと併用するように完全に再設計されているため、ダイレクト・アップグレード・パスはありません。Oracle BAM 12cで使用するスキーマ、バイナリおよびディレクトリ構造は、Oracle BAM 11gで使用するものとは異なります。そのため、Oracle BAM 11gからBAM 12cへのアップグレードは、標準のアップグレード手順を使用することでは処理できません。いくつかの構成タスクを手動で実行して、アップグレードを完了する必要があります。
BAM 12cドメインで使用できるOracle BAM 11gオブジェクトのみが、データ・オブジェクト(DO)であり、エンタープライズ・メッセージ・ソース(EMS)であることを理解することも重要です。これらのオブジェクトは、手動でXMLファイルにエクスポートしてから、BAM 12cドメインにインポートする必要があります。その他のOracle BAM 11gアーティファクト(ダッシュボードなど)は、Oracle BAM 12cドメインに手動で再作成する必要があります。
Oracle BAM 11gドメインは、アップグレード後も続けて使用することをお薦めします。これにより、必要になるすべてのアーティファクトを作成およびテストする機会が得られます。そのため、Oracle BAMを含むSOAのアップグレード・プロセスを開始する前に、Oracle BAM 11gドメインを別個の場所にインストールしておくことで、ドメインの再構成中にソース・ファイルが改変されないようにすることを強くお薦めします。アップグレード後に、この新しい11gドメインを指すようにSOA 12cを構成します。これは、既存の11g Oracle BAMドメインは変更され、SOA 12cでは機能しなくなるためです。
ノート:
Oracle BAMのみのドメイン(SOAのないドメイン)のアップグレードはサポートされていません。BAM専用ドメインがあり、Oracle BAM 12cへのアップグレードが必要になる場合は、新しいOracle BAM 12cドメインを作成し、データ・オブジェクトをインポートしてから、すべてのダッシュボードとアラートを再作成する必要があります。
Oracle BAM 11gを含むSOAのアップグレード・プロセス・フローの理解
次のフローチャートは、Oracle BAMを含むSOA 11gドメインからOracle BAM 12cを含むSOA 12cドメインへのアップグレード・プロセスの概要を示しています。
Oracle BAMのアップグレード前タスクの実行
この項のタスクは、Oracle BAM 11gを含むSOAドメインを12cにアップグレードするときに実行してください。
アップグレード前の新しいOracle BAM 11gドメインの作成
既存のOracle Business Activity Monitoring (BAM) 11gドメインはアップグレード後も継続使用することになるため、アップグレード前にBAM 11gを新しいドメイン・ホームにインストールする必要があります。新しい(別個の) BAM 11gドメインを作成しないと、アップグレード後に機能するBAMドメインがなくなり、アーティファクトや構成の多くが失われてしまいます。
ノート:
Oracle BAM 11gに別個のドメインを作成しないと、BAMアーティファクトとBAM関連の構成のみが失われます(SOAアーティファクトには影響しません)。
さらに、BAMアーティファクトを参照するコンポジット(アダプタなど)や新しいインスタンスは、実行時に失敗するようになります。
『Oracle Fusion Middleware Oracle SOA Suite and Oracle Business Process Management Suiteインストレーション・ガイド』のバージョン11gのインストール手順を使用してください。
既存の11g BAM環境を保持するには、11g ICommandを使用してOracle BAM 11gアーティファクトのすべて(DOとEMSにかぎらず)をエクスポートし、それを新しいOracle BAM 11gドメインにインポートします。これにより、アップグレード後にも完全に機能するOracle BAM 11gドメインを用意できます。
Oracle BAM 11gドメインは、アップグレードの後も継続使用できます。別の方法として、Oracle BAM 12cを含む12c SOAドメインを拡張し、11gドメインからDOおよびEMSアーティファクトをエクスポートして、拡張したOracle BAM 12cドメインにそれらをインポートすることもできます。詳細は、「Oracle BAM 12cを含むSOAドメインの拡張」を参照してください。
親トピック: Oracle BAMのアップグレード前タスクの実行
既存のドメインからのすべてのOracle BAM 11gアーティファクトのエクスポート
新しいOracle BAM 11gドメインを新しい場所にインストールして構成したら、アップグレード前に、11g Oracle BAM ICommandユーティリティを使用して既存の(旧) Oracle BAM 11gドメインからデータをエクスポートし、そのデータを新しいOracle BAM 11gドメインにインポートする必要があります。
11g Oracle BAM ICommandコマンドライン・ユーティリティを使用したデータ・ファイルのエクスポートの詳細は、Oracle BAMによるビジネス・アクティビティの監視のエクスポートに関する項を参照してください。
親トピック: Oracle BAMのアップグレード前タスクの実行
Oracle BAM 11gアーティファクトの新しいOracle BAM 11gドメインへのインポート
Oracle BAM 11gアーティファクト(DOとEMSにかぎらず)の完全なエクスポートXMLを作成した後で、そのXMLファイルを新しく作成したOracle BAM 11gドメインにインポートする必要があります。これにより、アップグレードとドメイン再構成の後も、完全に機能するOracle BAMドメインを維持できるようになります。
11g Oracle BAM ICommandコマンドライン・ユーティリティを使用したデータ・ファイルのエクスポートの詳細は、Oracle BAMによるビジネス・アクティビティの監視のインポートに関する項を参照してください。
親トピック: Oracle BAMのアップグレード前タスクの実行
Oracle BAM 11gドメインの完全なバックアップの作成
アップグレードが失敗した場合は、バックアップ・バージョンを使用して、アップグレード前の環境全体をリストアする必要があります。アップグレード・プロセスを続行する前に、Oracle BAM 11g環境全体のバックアップ・バージョンを必ず作成してください。バックアップのドメインは、「アップグレード前の新しいOracle BAM 11gドメインの作成」で作成した新しいOracle BAM 11gドメインとは異なります。
詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのアップグレードのプランニング』のアップグレードのためのバックアップおよびリカバリ計画に関する項を参照してください。
親トピック: Oracle BAMのアップグレード前タスクの実行
Oracle BAMドメインを含むSOAの12cへのアップグレード
Oracle BAMを含むSOA 11gドメインを、Oracle BAMを含むSOA 12c (12.2.1.4.0)ドメインにアップグレードするには、この手順を使用します。
これらのタスクは、Oracle BAM 11gドメインの完全なバックアップを作成するまで実行しないでください。
- Oracle SOA SuiteおよびBusiness Process Managementの12c (12.2.1.4.0)製品ディストリビューションのインストール
アップグレードを開始する前に、Oracle Universal Installerを使用してOracle Fusion Middleware Infrastructureディストリビューション、Oracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.4.0)ディストリビューション、およびその他のSOA Suite製品をターゲット・システムにインストールします。 - RCUを使用した必要な12cスキーマの作成
11gからアップグレードする場合、必要な12cスキーマを作成する必要があります。リポジトリ作成ユーティリティ(RCU)を使用してカスタマイズされたスキーマを作成するか、オプションでUpgrade Assistantを使用してデフォルトのスキーマ設定を使用したスキーマを作成できます。この手順では、RCUを使用してスキーマを作成する方法について説明します。Upgrade Assistantを使用してスキーマを作成する詳細は、アップグレード手順で説明します。 - 11gスキーマのアップグレード前のOracle BAMテンプレートの名前の変更
- サーバーとプロセスの停止
Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、すべてのアップグレード前のプロセス、および管理サーバーや管理対象サーバーを含めたすべてのサーバーを停止する必要があります。 - アップグレード・アシスタントの実行によるスキーマのアップグレード
- 再構成ウィザードを使用した11gドメインの再構成
- Upgrade Assistantの実行によるコンポーネント構成のアップグレード
Oracle SOA SuiteおよびBusiness Process Managementの12c (12.2.1.4.0)製品ディストリビューションのインストール
アップグレードを開始する前に、Oracle Universal Installerを使用してOracle Fusion Middleware Infrastructureディストリビューション、Oracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.4.0)ディストリビューション、およびその他のSOA Suite製品をターゲット・システムにインストールします。
ノート:
Infrastructureがアップグレードに必要な場合、他のFusion Middleware製品をインストールする前にOracle Fusion Middlewareディストリビューションを最初にインストールする必要があります。-
以前の12cリリースからアップグレードする場合は、12c (12.2.1.4.0)ディストリビューションを新しいOracleホームにインストールする必要があります。このアップグレードのために既存のOracleホームを再使用しようとしないでください。12c (12.2.1.4.0)へのアップグレードは、パッチ・リリースではありません。
-
Oracle SOA Suiteには、Oracle Fusion Middleware Infrastructure (Oracle WebLogic ServerおよびJRF)が必要です。
Fusion Middlewareインフラストラクチャをインストールすると、Oracleホーム・ディレクトリが作成され、その他のFusion Middleware製品をインストールするためのサポート・ソフトウェアが配置されます。
- SOAドメインにOracle Service Bus、Managed File TransferまたはOracle B2Bなどのその他のSOA統合コンポーネントがある場合は、それらのディストリビューションを同じ新しいOracleホームにインストールする必要があります。Oracle Business Activity MonitoringおよびBusiness Process Managementは、汎用のSOAディストリビューションの一部です。
RCUを使用した必要な12cスキーマの作成
11gからアップグレードする場合、必要な12cスキーマを作成する必要があります。リポジトリ作成ユーティリティ(RCU)を使用してカスタマイズされたスキーマを作成するか、オプションでUpgrade Assistantを使用してデフォルトのスキーマ設定を使用したスキーマを作成できます。この手順では、RCUを使用してスキーマを作成する方法について説明します。Upgrade Assistantを使用してスキーマを作成する詳細は、アップグレード手順で説明します。
Oracle Fusion Middleware 11gリリースでは、SOAスキーマは必須ではなかったため、データベースなしでBusiness Activity Monitoring (BAM)を実行することもできました。ただし、12cでは、Business Activity Monitoring 12c (12.2.1.4.0)を実行する前に、サポートされているデータベースを必須のSOAスキーマで構成しておく必要があります。
ノート:
Oracle Fusion Middlewareの前の12cリリースからアップグレードする場合、これらのスキーマがすでに存在する場合には再作成する必要はありません。ドメインの既存のスキーマを特定するには、次のステップを参照してください。12cにアップグレードする前に、次のスキーマが存在している必要があります。11gからアップグレードし、現在使用しているスキーマがわからない場合、次のステップを参照して、ドメインの既存のスキーマを識別します。すでに存在する場合、これらのスキーマを再作成する必要はありません
-
サービス表スキーマ(
prefix_STB
)。このスキーマは12cで新規のものであり、ドメインベースのアップグレードに必要になります。基本的なスキーマ構成情報(スキーマ接頭辞やパスワードなど)が格納され、他のOracle Fusion Middlewareコンポーネントはドメイン作成中にこれにアクセスして使用できます。このスキーマはリポジトリ作成ユーティリティ(RCU)を実行するときに自動的に作成され、ここで他の11gスキーマに使用した既存のスキーマ所有者接頭辞を指定します。ノート:
サービス表スキーマが存在しない場合、
UPGAST-00328: スキーマ・バージョンのレジストリ表はこのデータベースに存在しません。その場合、Upgrade Assistantを実行するためにはサービス表スキーマを作成する必要があります。
というエラー・メッセージが表示されることがあります。 -
Oracle Platform Security Services (OPSS)スキーマ(
prefix_OPSS
)。このスキーマは、11gでOIDベースのセキュリティ・ストアを使用している場合に必要です。このスキーマは、リポジトリ作成ユーティリティ(RCU)を実行するときに自動的に作成されます。LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directory (OID)のみです。LDAPベースのポリシー・ストアは、通常、本番環境で使用します。アップグレード前に、OIDベースのセキュリティ・ストアを再関連付けする必要はありません。アップグレード・アシスタントの実行中に、OPSSスキーマを選択できます。アップグレード・アシスタントは、OIDベースのセキュリティ・ストアを自動的にアップグレードします。ノート:
12c OPSSデータベース・スキーマが必要なのは、ドメインの再構成時に12cスキーマを参照するためです。ドメインでは、アップグレード完了後にOIDベースのセキュリティ・ストアが引き続き使用されます。
-
Audit Services(
prefix_IAU
) -
WebLogic Services (
prefix_WLS
)。このスキーマは、12cのBAMに必要となります。11gでは、BAMには固有の別個のスキーマはありません。 -
Managed File Transfer (
prefix_MFT
)。このスキーマはリリース12c (12.1.3)で導入されたものであり、MFTがドメインの一部になっている場合にのみ必要です。
11gスキーマのアップグレード前のOracle BAMテンプレートの名前の変更
アップグレード・アシスタントで11gスキーマをアップグレードする前に、次のOracle BAM再構成テンプレートの名前を変更する必要があります。そうしないと、アップグレードは失敗します。
このステップを完了する前に、11g Oracle Business Activity Monitoring (BAM)データがエクスポート済になっていることを確認してください。よくわからない場合は、既存のドメインからのすべてのOracle BAM 11gアーティファクトのエクスポートを参照してください。
テンプレートは、12cのディレクトリ$ORACLE_HOME/soa/common/templates/wls
にあります。
テンプレート名 | 変更後の名前 |
---|---|
oracle.bam.reconfig_template_11g_12.2.1.jar |
oracle.bam.reconfig_template_11g_12.2.1.jar-old |
oracle.bam.reconfig.template_11g_12.2.1.jar.rename |
oracle.bam.reconfig_template_11g_12.2.1.jar |
サーバーとプロセスの停止
Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、すべてのプアップグレード前のプロセスと管理サーバーや管理対象サーバーを含めたすべてのサーバーを停止する必要があります。
Oracle Fusion Middleware環境は、Oracle WebLogic Serverドメイン、管理サーバー、複数の管理対象サーバー、Javaコンポーネント、Identity Managementコンポーネントなどのシステム・コンポーネント、およびメタデータのリポジトリとして使用されるデータベースで構成できます。コンポーネントは相互に依存していることがあるため、適切な順序で停止する必要があります。
ノート:
この項内の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用して既存のアップグレード前のサーバーおよびプロセスを停止する方法を説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。管理サーバー、管理対象サーバーおよびノード・マネージャの起動と停止を参照してください。アップグレード前のFusion Middleware環境を停止するには、アップグレード前のドメインに移動し、次のステップに従います。
ステップ1: システム・コンポーネントの停止
Oracle HTTP Serverなどのシステム・コンポーネントを停止するには、stopComponent
スクリプトを使用します。
-
(UNIX)
EXISTING_DOMAIN_HOME/bin/stopComponent.sh component_name
-
(Windows)
EXISTING_DOMAIN_HOME\bin\stopComponent.cmd component_name
どの順序でもシステム・コンポーネントを停止できます。
ステップ2: 管理対象サーバーの停止
WebLogic Server管理対象サーバーを停止するには、stopManagedWebLogic
スクリプトを使用します。
-
(UNIX)
EXISTING_DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url
-
(Windows)
EXISTING_DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url
プロンプトが表示されたらユーザー名とパスワードを入力します。
SOAサーバーおよびプロセスは、次の順番で停止してください。
-
Business Activity Monitoring (BAM)管理対象サーバー
-
Oracle Service Bus (OSB)管理対象サーバー
-
サービス指向アーキテクチャ(SOA)管理対象サーバー
-
Oracle Web Services Manager (OWSM)管理対象サーバー
ステップ3: Oracle Identity Managementコンポーネントの停止
Oracle Identity Managementのコンポーネント(Oracle Internet Directoryなど)を停止します。-
(UNIX)
EXISTING_DOMAIN_HOME/bin/stopComponent.sh component_name
-
(Windows)
EXISTING_DOMAIN_HOME\bin\stopComponent.cmd component_name
ステップ4: 管理サーバーの停止
管理サーバーを停止するときには、WebLogic Server管理コンソールおよびFusion Middleware Controlなど、管理サーバーで実行されているプロセスも停止します。
管理サーバーを停止するには、stopWebLogic
スクリプトを使用します。
-
(UNIX)
EXISTING_DOMAIN_HOME/bin/stopWebLogic.sh
-
(Windows)
EXISTING_DOMAIN_HOME\bin\stopWebLogic.cmd
プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよびURLを入力します。
ステップ5: ノード・マネージャの停止
ノード・マネージャを停止するには、それが実行されているコマンド・シェルを閉じます。
またはnodemanager.properties
の属性QuitEnabled
をtrue
に設定した後(デフォルトはfalse
です)、WLSTを使用して、ノード・マネージャに接続して停止できます。WebLogic Server WLSTコマンド・リファレンスのstopNodeManagerを参照してください。
アップグレード・アシスタントの実行によるスキーマのアップグレード
アップグレード・アシスタントを使用したスキーマのアップグレードの、標準の手順に従います。
Oracle BAM 11gスキーマを使用するSOA SuiteおよびBPMをアップグレードする場合は、「使用可能なコンポーネント」画面(それぞれのスキーマ名がリストされる)で次のオプションを選択します。
-
Oracle Platform Security Services (
_OPSS
) -
Oracle SOA (
_SOAINFRA
) -
Oracle Managed File Transfer (_MFT)
Oracle Platform Security ServicesとOracle SOAを選択した場合は、次の依存関係も選択します。
-
Oracle Audit Services(
_IAU
) -
Oracle Metadata Services (
_MDS
) -
ユーザー・メッセージング・サービス(
_ORASDPM
)ノート: 11g
_ORASDPM
スキーマは、12cでは名前が_UMS
に変更されています。ただし、アップグレード・アシスタントで要求された場合は、11gのスキーマ名、接頭辞_ORASDPM
を入力する必要があります。スキーマ名はアップグレード・アシスタントでは変更できないため、アップグレードしたドメインのスキーマは、<接頭辞>_ORASDPM
のままになります。
- 製品スキーマのアップグレード
サーバーとプロセスの停止後に、Upgrade Assistantを使用して、サポートされている製品スキーマをOracle Fusion Middlewareの現在のリリースにアップグレードします。
製品スキーマのアップグレード
サーバーおよびプロセスの停止後、Upgrade Assistantを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。
アップグレード・アシスタントを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるアップグレード・アシスタントの画面は異なります。
- Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.4.0)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。 - Upgrade Assistantの使用によるSOAスキーマのアップグレード
Upgrade Assistantの各画面を通じて、製品スキーマをアップグレードします。 - スキーマのアップグレードの確認
すべてのアップグレード・ステップを完了したら、schema_version_registry
のスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードの成功を検証します。
アップグレード・アシスタントの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.4.0)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。
ノート:
Upgrade Assistantを起動する前に、Upgrade Assistantを実行しているプラットフォームにJVM文字エンコーディングがUTF-8に設定されていることを確認してください。文字エンコーディングがUTF-8に設定されていない場合、名前にUnicode文字を含むファイルをダウンロードできません。アップグレードが失敗することがあります。
oracle_common/upgrade/bin
ディレクトリに移動します。- (UNIX)
ORACLE_HOME/oracle_common/upgrade/bin
- (Windows)
ORACLE_HOME\oracle_common\upgrade\bin
- (UNIX)
- Upgrade Assistantを起動します。
- (UNIX) ./ua
- (Windows) ua.bat
ロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。
アップグレード・アシスタントのパラメータ
アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。
表5-5 Upgrade Assistantコマンドライン・パラメータ
パラメータ | 必須またはオプション | 説明 |
---|---|---|
|
準備状況チェックに必要
ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。 |
実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。 スキーマおよび構成がチェックされます。
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックに必要 |
GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。 |
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
オプション |
次のいずれかの属性を指定して、ロギング・レベルを設定します。
デフォルトのロギング・レベルは より多くの情報がログ記録されるよう、 |
|
オプション |
アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 (UNIX)
(Windows)
|
|
オプション |
すべてのコマンドライン・オプションを表示します。 |
親トピック: Upgrade Assistantの起動
アップグレード・アシスタントを使用したSOAスキーマのアップグレード
Upgrade Assistantの各画面を通じて、製品スキーマをアップグレードします。
注意:
パージ・スクリプトまたはスケジュールされたデータベース・ジョブの実行中は、アップグレード・アシスタントを起動しないでください。
パージまたはアップグレードが完了するまで待ってから、アップグレード・プロセスを開始してください。アップグレード・アシスタントを使用してスキーマをアップグレードするときに、パージ・スクリプトまたはインスタンスのアップグレード・ジョブを実行していると、アップグレードは失敗します。
アップグレード・アシスタントを起動する必要がある場合は、「バックグラウンド制御ジョブの有効化と無効化(オプション6)」で説明しているように、パージを停止してスケジュールされたジョブを無効にしてください。
親トピック: 製品スキーマのアップグレード
スキーマのアップグレードの確認
すべてのアップグレード・ステップが完了したら、schema_version_registry
内のスキーマ・バージョンが正しく更新されていることを確認することで、アップグレードの成功を確認します。
Oracle Databaseを使用する場合、Oracle DBAを持つユーザーとしてデータベースに接続し、SQL*Plusから次を実行して現行のバージョン番号を取得します。
SET LINE 120 COLUMN MRC_NAME FORMAT A14 COLUMN COMP_ID FORMAT A20 COLUMN VERSION FORMAT A12 COLUMN STATUS FORMAT A9 COLUMN UPGRADED FORMAT A8 SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;
問合せ結果について:
-
VERSION
列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。たとえば、スキーマ・バージョン番号が12.2.1.4.0になっていることを確認します。ノート:
すべてのスキーマ・バージョンが更新されるわけではありません。一部のスキーマは、このリリースにアップグレードする必要がなく、アップグレード前のバージョン番号のままになります。
-
STATUS
フィールドは、スキーマのパッチ適用処理中はUPGRADING
またはUPGRADED
のどちらかになり、その処理が完了するとVALID
になります。 -
ステータスが
「INVALID」
と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。 -
IAU_APPEND
およびIAU_VIEWER
に所有されているシノニム・オブジェクトは、INVALID
と表示されますが、失敗を示しているわけではありません。それらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトは、アクセスされるときに有効になります。これらの
INVALID
オブジェクトは無視してかまいません。
親トピック: 製品スキーマのアップグレード
再構成ウィザードを使用した11gドメインの再構成
Oracle BAMの再構成テンプレートの名前を変更した後、再構成ウィザードを起動し、説明されているステップに従います。
再構成ウィザードにより、Oracle BAM 11gアプリケーション、ライブラリ、BAMDataSource、BAMJMSSserverおよびBAMJmsSystemResourceがドメインから削除されます。
ノート: アップグレード後に、Oracle BAMサーバーおよびクラスタを手動で削除する必要があります(構成後作業「ドメインからのOracle BAMサーバーおよびクラスタの削除」を参照)。
- ドメインの再構成について
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.4.0)にあわせて再構成します。
ドメインの再構成について
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.4.0)に再構成します。
WebLogic Serverドメインを再構成すると、ドメイン内のアプリケーションに応じて、次の項目が自動的に更新されます。
-
WebLogic Serverコア・インフラストラクチャ
-
ドメイン・バージョン
ノート:
ドメイン再構成を開始する前に、次の制限事項に注意してください。
-
再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。
-
アップグレード・プロセスの間の非動的クラスタ・ドメインから動的クラスタ・ドメインへの変換はサポートされていません。
動的クラスタ機能は再構成ウィザードの実行時に使用可能ですが、Oracleでは、非動的クラスタのアップグレード後の動的クラスタの追加のみがサポートされています。アップグレード・プロセスの間に動的クラスタを追加することはできません。
-
アップグレードするインストールでOracle Access Management (OAM)が使用されない場合は、2つのファイルを編集して、再構成ウィザードが、存在しないOAMインフラストラクチャ・スキーマの更新(アップグレードが失敗する)を試みないようにする必要があります。
$DOMAIN/init-info/domain-info.xml
に次の例のような行をコメント・アウトします。<!--extention-template-ref name="Oracle Identity Navigator" version="11.1.1.3.0" location="/u01/app/oracle/product/fmw/iam111130/common/templates/applications/yourcomany.oinav_11.1.1.3.0_template.jar" symbol=""/--> <!--install-comp-ref name="oracle.idm.oinav" version="11.1.1.3.0" symbol="yourcompany.idm.oinav_11.1.1.3.0_iam111130_ORACLE_HOME" product_home="/u01/app/oracle/product/fmw/iam111130"/-->
また、同様に、
$DOMAIN/config/config.xml
に次の例のような行をコメント・アウトします。<!--app-deployment> <name>oinav#11.1.1.3.0</name> <target>AdminServer</target> <module-type>ear</module-type> <source-path>/u01/app/oracle/product/fmw/iam111130/oinav/modules/oinav.ear_11.1.1.3.0/oinav.ear</source-path> <deployment-order>500</deployment-order> <security-dd-model>DDOnly</security-dd-model> <staging-mode>nostage</staging-mode> </app-deployment-->
-
ドメインの
config.xml
ファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。 -
すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。
-
起動スクリプトが更新されます。
変更した起動スクリプトを保持する必要がある場合は、再構成ウィザードを開始する前にそれらをバックアップするようにしてください。
ノート:
ドメインの再構成プロセスを開始すると、行う変更を元に戻すことはできません。再構成ウィザードを実行する前に、アップグレード前チェックリストに示されているようにドメインをバックアップしてあることを確認してください。再構成ウィザードの実行中にエラーまたは他の割込みが発生した場合、バックアップ場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーすることによって、ドメインをリストアする必要があります。これは、ドメインが再構成前の元の状態に戻されたことを確認する唯一の方法です。- ドメインのバックアップ
- 再構成ウィザードの起動
- 再構成ウィザードを使用したSOAドメインの再構成
Upgrade Assistantを実行する前に、再構成ウィザードを使用して、まず既存のドメインを再構成する必要があります。
親トピック: 再構成ウィザードを使用した11gドメインの再構成
ドメインのバックアップ
再構成ウィザードを実行する前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。
ドメイン・ディレクトリのバックアップを作成するには:
親トピック: ドメインの再構成について
再構成ウィザードの起動
ノート:
再構成プロセスを開始する前に管理サーバーおよびすべてのコロケートされた管理対象サーバーを停止します。「サーバーとプロセスの停止」を参照再構成ウィザードをグラフィカル・モードで起動するには:
親トピック: ドメインの再構成について
再構成ウィザードを使用したSOAドメインの再構成
Upgrade Assistantを実行する前に、再構成ウィザードを使用して、まず既存のドメインを再構成する必要があります。
ノート:
ソースがクラスタ環境である場合は、再構成ウィザードをプライマリ・ノードでのみ実行します。圧縮/解凍ユーティリティを使用して、ドメイン内の他のクラスタ・メンバーに変更を適用します。親トピック: ドメインの再構成について
Upgrade Assistantの実行によるコンポーネント構成のアップグレード
ドメインの再構成が終了したら、アップグレード・アシスタントを再実行して、残りのコンポーネントの構成をアップグレードします。
- ドメイン・コンポーネント構成のアップグレード
ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。
ドメイン・コンポーネント構成のアップグレード
ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。
- Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.4.0)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。 - Upgrade Assistantを使用したドメイン・コンポーネントのアップグレード
Upgrade Assistantの各画面を通じて、WebLogicドメインのコンポーネント構成をアップグレードします。
アップグレード・アシスタントの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.4.0)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。
ノート:
Upgrade Assistantを起動する前に、Upgrade Assistantを実行しているプラットフォームにJVM文字エンコーディングがUTF-8に設定されていることを確認してください。文字エンコーディングがUTF-8に設定されていない場合、名前にUnicode文字を含むファイルをダウンロードできません。アップグレードが失敗することがあります。
oracle_common/upgrade/bin
ディレクトリに移動します。- (UNIX)
ORACLE_HOME/oracle_common/upgrade/bin
- (Windows)
ORACLE_HOME\oracle_common\upgrade\bin
- (UNIX)
- Upgrade Assistantを起動します。
- (UNIX) ./ua
- (Windows) ua.bat
ロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。
アップグレード・アシスタントのパラメータ
アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。
表5-6 アップグレード・アシスタントのコマンドライン・パラメータ
パラメータ | 必須またはオプション | 説明 |
---|---|---|
|
準備状況チェックに必要
ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。 |
実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。 スキーマおよび構成がチェックされます。
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックに必要 |
GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。 |
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
オプション |
次のいずれかの属性を指定して、ロギング・レベルを設定します。
デフォルトのロギング・レベルは より多くの情報がログ記録されるよう、 |
|
オプション |
アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 (UNIX)
(Windows)
|
|
オプション |
すべてのコマンドライン・オプションを表示します。 |
親トピック: Upgrade Assistantの起動
Upgrade Assistantの使用によるドメイン・コンポーネントのアップグレード
Upgrade Assistantで複数の画面をナビゲートし、WebLogicドメイン内のコンポーネント構成をアップグレードします。
再構成ウィザードを実行してWebLogicドメインを12c (12.2.1.4.0)に再構成した後、Upgrade Assistantを実行して、更新したドメイン構成と一致するようドメイン・コンポーネント構成をアップグレードします。
親トピック: ドメイン・コンポーネント構成のアップグレード
Oracle BAM 12cを含むOracle SOAのアップグレード後構成タスクの実行
最終的にOracle BAM 12cを含むことになる、SOA 12cドメインを実行するには、アップグレード後に追加の構成作業を実行する必要があります。
ノート:
Oracle BAM 11gを含む12c SOA環境を最初に実行することをお薦めします。環境が予想どおりに機能することを確認した後、Oracle BAM 12cを含むドメインを拡張できます(「Oracle BAM 12cを含むSOAドメインの拡張」を参照)。
- 管理(Admin)サーバーの起動
- WebLogic Server管理12cコンソールの起動
- Oracle BAMサーバーまたはOracle BAMクラスタで実行中のUMS JMSリソースの削除
ここに示すステップは、スタンドアロン環境またはクラスタ化環境のUMS JMSリソースを削除するために使用できます。Oracle BAMクラスタには、追加のステップが必要になります。 - Oracle BAMにターゲット設定されたUMS JMSサーバーにターゲット設定されたサブデプロイメントのリソースの削除
Oracle BAMにターゲット設定されたUMS JMSサーバーにターゲット設定されたサブデプロイメントのリソースを削除します。 - ドメインからのOracle BAMサーバーおよびクラスタの削除
管理サーバーの実行中に、Weblogicコンソールを使用して、次のタスクを完了します。 - アップグレードされたドメインからファイルの不要なOracle BAM 11gファイルの削除
domainupdaterスクリプトを使用して、不要な11gのファイルをアップグレードしたドメインから削除します。 - クラスタのアップグレードのみ: 管理サーバーと管理対象サーバーの停止
クラスタをアップグレードする場合は、まず、管理サーバーと管理対象サーバーを停止してから、packコマンドとunpackコマンドを実行する必要があります。 - クラスタのアップグレードのみ: 管理サーバーと管理対象サーバーがインストールされた場所でのpackコマンドの実行
クラスタ内の別のノードにNodeManagerを含む再構成済ドメインを取り込むには、管理サーバー・マシンから管理対象packを実行して、リモート・ノードで解凍します。 - クラスタのアップグレードのみ: unpackコマンドの実行によるSOAHOST1のドメイン構成のSOAHOST2へのレプリケート
管理サーバーと管理対象サーバーがまだ停止していることを確認してから、次のunpackコマンドを実行して、リモート・マシン上の管理対象サーバー・ドメイン・ディレクトリに使用する、完全なドメインまたはドメインのサブセットを作成します - 管理サーバーの再起動
残りの構成タスクを実行する前に、12c管理サーバーを再起動する必要があります。 - SOA 12cドメインで動作するような11g Oracle BAMアダプタの構成
SOA 12cドメインをアップグレードした後、Oracle BAM 11gドメインを使用するようにSOA 12cドメインを構成する必要があります。 - SOA管理対象サーバーの再起動
構成後の作業を完了するには、SOA管理対象サーバーを再起動する必要があります。 - SOAドメインからドライバの既存のUMS電子メール・ドライバの削除
メール・パターンとの非互換性問題があるため、Oracle Enterprise ManagerのUMSドライバを削除する必要があります。
管理(Admin)サーバーの起動
Oracle WebLogic管理サーバーを起動するには、次のスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/startWebLogic.sh (Windows) DOMAIN_HOME\bin\startWebLogic.cmd
Oracle BAMサーバーまたはOracle BAMクラスタで実行中のUMS JMSリソースの削除
ここに示すステップは、スタンドアロン環境またはクラスタ化環境のUMS JMSリソースを削除するために使用できます。Oracle BAMクラスタには、追加のステップが必要になります。
Oracle BAMにターゲット設定されたUMS JMSサーバーにターゲット設定されたサブデプロイメントのリソースの削除
Oracle BAMにターゲット設定されたUMS JMSサーバーにターゲット設定されたサブデプロイメントのリソースを削除します。
ドメインからのOracle BAMサーバーおよびクラスタの削除
管理サーバーの実行中に、Weblogicコンソールを使用して、次のタスクを完了します。
ノート:
Fusion Middleware Controlコンソールを介した操作の詳細は、「Oracle SOA SuiteおよびOracle BPM Suiteの管理のスタート・ガイド」を参照してください。
クラスタのアップグレードのみ: 管理サーバーと管理対象サーバーの停止
クラスタをアップグレードする場合は、まず、管理サーバーと管理対象サーバーを停止してから、packコマンドとunpackコマンドを実行する必要があります。
WebLogic Serverを停止するには:
DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]
SOAサーバーを停止するには:
(UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh soa_server_name admin_url (Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd soa_server_name admin_url
管理対象サーバーは、次に示す順序で停止する必要があります。
管理サーバーおよびSOA管理対象サーバーを停止する
管理対象サーバーを停止する
ドメインを拡張する前に、現在実行中の12cサーバーとプロセスをすべて停止します。次のスクリプトを使用して、SOA管理対象サーバーを停止します。
-
(UNIX)
DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url
-
(Windows)
DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url
プロンプトが表示されたらユーザー名とパスワードを入力します。
ノート:
次の順序でSOAサーバーおよびプロセスを停止します。-
Business Activity Monitoring (BAM)管理対象サーバー
-
Oracle Service Bus (OSB)管理対象サーバー
-
サービス指向アーキテクチャ(SOA)管理対象サーバー
-
Oracle Web Services Manager (OWSM)管理対象サーバー
管理サーバーを停止します。
管理サーバーを停止するときには、WebLogic Server管理コンソールおよびFusion Middleware Controlなど、管理サーバーで実行されているプロセスも停止します。
管理サーバーを停止するには、次のスクリプトを使用します。
DOMAIN_HOME/bin/stopWebLogic.sh
プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよびURLを入力します。
管理サーバーと管理対象サーバーがインストールされた場所でのpackコマンドの実行
クラスタ内の別のノードにNodeManagerを含む再構成済ドメインを取り込むには、管理サーバー・マシンから管理対象packを実行して、リモート・ノードで解凍します。
packコマンドは、ドメイン全体またはドメインのサブセットのスナップショットを格納したテンプレート・アーカイブ(.jar)ファイルを作成します。ドメインのサブセットを格納したテンプレートを使用すると、リモート・マシン上に管理対象サーバーのドメインのディレクトリ階層を作成できます。
ノート: packおよびunpackコマンド・ユーティリティは、アップグレード済の11gドメインを指す12cインストール・ディレクトリから実行する必要があります。
pack
コマンドは、管理サーバーといずれかの管理対象サーバーがインストールされているサーバーで実行します。
この例では、SOAHOST1
で次を実行します。
cd
/12c_ORACLE_HOME/oracle_common/common/bin
./pack.sh -domain=/
11g_DOMAIN_HOME -template=domainupgradetemplate.jar -template_name=domainupgradetemplate -managed=true
この例では、次のようになります。
-
12c_ORACLE_HOMEは、12c Oracleホーム・ディレクトリ(12.2.1ビットのインストール・ディレクトリ)への実際のパスを表します。
-
11g_DOMAIN_HOMEは、アップグレードされたドメイン・ディレクトリへの実際のパスに置き換えます。
-
domainupgradetemplate.jar
は、作成するJARファイルのサンプル名です。このファイルにドメイン構成ファイルを格納します。 -
domainupgradetemplate
は、ドメイン・テンプレート・ファイルに割り当てられる名前です。 -
デフォルトでは、
domainupgradetemplate
は、現行ディレクトリ(packコマンドを実行したディレクトリ)に作成されます。この例では次のディレクトリに作成されますが、packコマンドの-template
引数の一部としてテンプレートJARファイルのフルパスを指定できます。ORACLE_COMMON_HOME/common/bin/
pack
コマンドは、ドメイン全体またはドメインのサブセットのスナップショットを格納したテンプレート・アーカイブ(.jar)ファイルを作成します。ドメインのサブセットを格納したテンプレートを使用すると、リモート・マシン上に管理対象サーバーのドメインのディレクトリ階層を作成できます。
packコマンドの使用の詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』のPackおよびUnpackコマンドの概要に関する項を参照してください。
クラスタのアップグレードのみ: unpackコマンドの実行によるSOAHOST1のドメイン構成のSOAHOST2へのレプリケート
管理サーバーと管理対象サーバーがまだ停止していることを確認してから、次のunpackコマンドを実行して、リモート・マシン上の管理対象サーバー・ドメイン・ディレクトリに使用する、完全なドメインまたはドメインのサブセットを作成します
リモート・マシンの管理対象サーバー・ドメイン・ディレクトリに使用されるフル・ドメインまたはドメインのサブセットを作成できます。unpackは、現在のインストールと互換性のあるテンプレートでのみ使用できます。
サンプルのunpackコマンドのコード・スニペットを次に示します。これは例としてのみ使用します。 unpackには、"-overwrite_domain=true
"フラグを指定する必要がある点に注意してください。
packコマンドの使用の詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』のPackおよびUnpackコマンドの概要に関する項を参照してください。
cd
/12c_ORACLE_HOME/oracle_common/common/bin
./unpack.sh -template=domainupgradetemplate.jar - domain=
11g_DOMAIN_HOME -overwrite_domain=true
この例では、次のようになります。
-
12c_ORACLE_HOMEは、12c Oracleホーム・ディレクトリ(12.2.1ビットのインストール・ディレクトリ)への実際のパスを表します。
-
11g_DOMAIN_HOMEは、アップグレードされたドメイン・ディレクトリへの実際のパスに置き換えます。
-
domainupgradetemplate.jar
は、作成するJARファイルのサンプル名です。このファイルにドメイン構成ファイルを格納します。 -
domainupgradetemplate
は、ドメイン・テンプレート・ファイルに割り当てられる名前です。
管理サーバーの再起動
残りの構成タスクを実行する前に、12c管理サーバーを再起動する必要があります。
管理サーバーを起動するときには、WebLogic Server管理コンソールおよびFusion Middleware Controlなど、管理サーバーで実行されているプロセスも起動します。
管理サーバーを起動するには、次のスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/startWebLogic.sh
(Windows)DOMAIN_HOME\bin\startWebLogic.cmd
プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよびURLを入力します。
SOA 12cドメインで動作する11g Oracle BAMアダプタの構成
SOA 12cドメインをアップグレードした後、Oracle BAM 11gドメインを使用するようにSOA 12cドメインを構成する必要があります。
「アップグレード前の新しいOracle BAM 11gドメインの作成」で作成したOracle BAM 11gドメインを使用します。
この設定の構成方法の詳細は、11gバージョンの『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のOracle BAMアダプタの構成に関する項を参照してください。
SOA管理対象サーバーの再起動
構成後の作業を完了するには、SOA管理対象サーバーを再起動する必要があります。
次のスクリプトでWebLogic Server管理対象サーバーを起動します。
-
(UNIX)
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
-
(Windows)
DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url
プロンプトが表示されたらユーザー名とパスワードを入力します。
SOAサーバーおよびプロセスを次の順番で起動します。
- Oracle Web Services Manager (OWSM)管理対象サーバー
-
サービス指向アーキテクチャ(SOA)管理対象サーバー
-
Oracle Service Bus (OSB)管理対象サーバー
-
Business Activity Monitoring (BAM)管理対象サーバー
ノート:
通常は、管理対象サーバーの起動により、それにデプロイされているアプリケーションが起動します。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。Oracle BAM 12cを含むSOAドメインの拡張
アップグレードされたSOA 12c環境とともにOracle BAM 12cを使用する準備が整っている場合、BAM 12cテンプレートを含むようにドメインを拡張する必要があります。
その場合、次の手順に従います。一部のタスクはオプションです。
- 管理サーバーおよびSOA管理対象サーバーを停止する
- Oracle BAM 12cドメイン・テンプレートによるSOA 12cドメインの拡張
- Oracle BAMサーバーの新しいUMS電子メール・ドライバの作成
- Oracle BAM 11gデータ・オブジェクトとEMSデータのBAM 12cサーバーへのインポート
- BAM 12cドメインで使用する11g BAMダッシュボード、アラートおよびその他のアーティファクトの手動での再作成
- 11gプロセス・キューブのBAM 12cプロセス・スター・スキーマへの移行(BPMユーザーのみ)
- 11g Monitor ExpressデータのBAM 12cプロセス・スター・スキーマへの移行(オプション)
- 12cでの11g互換プロセス・スター・スキーマ・データ・ビューの生成(オプション)
管理サーバーおよびSOA管理対象サーバーを停止する
管理対象サーバーを停止する
ドメインを拡張する前に、現在実行中の12cサーバーとプロセスをすべて停止します。次のスクリプトを使用して、SOA管理対象サーバーを停止します。
-
(UNIX)
DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url
-
(Windows)
DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url
プロンプトが表示されたらユーザー名とパスワードを入力します。
ノート:
次の順序でSOAサーバーおよびプロセスを停止します。-
Business Activity Monitoring (BAM)管理対象サーバー
-
Oracle Service Bus (OSB)管理対象サーバー
-
サービス指向アーキテクチャ(SOA)管理対象サーバー
-
Oracle Web Services Manager (OWSM)管理対象サーバー
管理サーバーを停止します。
管理サーバーを停止するときには、WebLogic Server管理コンソールおよびFusion Middleware Controlなど、管理サーバーで実行されているプロセスも停止します。
管理サーバーを停止するには、次のスクリプトを使用します。
DOMAIN_HOME/bin/stopWebLogic.sh
プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよびURLを入力します。
親トピック: Oracle BAM 12cを含むSOAドメインの拡張
Oracle BAM 12cドメイン・テンプレートによるSOA 12cドメインの拡張
構成ウィザードを使用して、Oracle BAM 12cで既存のSOAドメインを拡張します。
SOA、OSB、BAMなど特定のFusion Middlewareコンポーネントは、12cではUMSに依存しています。単一の12.2.1ドメイン内でこれらのコンポーネントのうち複数を構成する場合は、コンポーネントが動作するサーバーが1つしかない場合でも、これらのコンポーネントは各自のクラスタ内で動作する必要があります 。「クラスタ化されたSOA環境のアップグレード」の図8-1を参照してください。
構成ウィザードの「拡張構成」画面に進んだら、「管理対象サーバー、クラスタおよびCoherence」を選択して、『構成ウィザードによるWebLogicドメインの作成』のクラスタに関する項の説明に従い、BAMクラスタを作成します。
親トピック: Oracle BAM 12cを含むSOAドメインの拡張
Oracle BAMサーバーの新しいUMS電子メール・ドライバの作成
Oracle BAMサーバーがクラスタで実行されているときに、Fusion Middleware Controlコンソールを使用して、次のタスクを完了します。
親トピック: Oracle BAM 12cを含むSOAドメインの拡張
Oracle BAM 11gデータ・オブジェクトとEMSデータのBAM 12cサーバーへのインポート
BAM 12cが含まれるようにドメインを拡張した後で、SOA 12cで使用しているBAM 11g環境から、データ・オブジェクトとEMSデータをエクスポートする必要があります。その後で、BAM 12cを含むSOA環境に、このデータをインポートします。
ノート:
import
コマンドを-upgrade
パラメータとともに使用して、Oracle BAM 11gアーティファクトをOracle BAM 12cに移行すると、一部の情報が変更されます。
親トピック: Oracle BAM 12cを含むSOAドメインの拡張
BAM 12cドメインで使用する11g BAMダッシュボード、アラートおよびその他のアーティファクトの手動での再作成
BAM 11gドメインで使用したダッシュボード、アラート、ビューなどは、BAM 12cドメインで再作成する必要があります。
BAMユーザー・ガイド、Oracle BAMによるビジネス・アクティビティの監視の、次に関する項を参照してください。
親トピック: Oracle BAM 12cを含むSOAドメインの拡張
11gプロセス・キューブのBAM 12cプロセス・スター・スキーマへの移行(BPMユーザーのみ)
アップグレード済のBPM 12cドメインをBAM 12cで拡張した後には、プロセス・キューブの移行を実行することを強くお薦めします。この移行により、BPMエンティティに必要なすべての12cデータ・オブジェクトが作成されるようになります。さらに、BPMプロセス分析データも11gプロセス・キューブから移行されるようになります(キューブ表に実行時データが移入される場合にのみ該当します)。
各アーカイブをエクスポートおよびインポートするときに、SOAINFRAスキーマのユーザー名とパスワードに加えて、サーバー管理者(admin)のユーザー名とパスワードを指定する必要があります。
ノート:
プロセス・キューブの移行は、Monitor Expressの移行(「11g Monitor ExpressデータのBAM 12cプロセス・スター・スキーマへの移行」を参照)を開始する前の必須の前提条件です。
このステップは、BPM 11gでOracle BAM 11g Monitor Expressを使用していなかった場合でも必要になります。
- タスク1: プロセス・メトリックを無効にします。
- タスク2: 移行に使用するexportTypeを決定します。
- タスク3: (UNIXのみ) 12c SOAホームから、migrateBPMProcessCubesスクリプトを実行します。
- タスク4: (Windowsのみ) 11g BPMプロセス・キューブから、データ・オブジェクトの定義とデータをエクスポートして、それらを12cにインポートします。
- タスク5: (Windowsのみ)ディメンション・データ(DimensionExport.zip)をBAMサーバーにインポートします。
- タスク6: (Windowsのみ)アクティブ・ファクト・データ(ActiveFactDataExport.zip)をBAMサーバーにインポートします。
- タスク7: (Windowsのみ: exportType=ALLの場合)完了ファクト・データ(CompletedFactDataExport.zip)をBAMサーバーにインポートします。
- タスク8: 移行が正常に完了したら、Oracle BAMサーバーを再起動します。
- タスク9: Oracle BAMサーバー実行中のプロセス・メトリックを有効化します。
親トピック: Oracle BAM 12cを含むSOAドメインの拡張
タスク2: 移行に使用するexportTypeを決定します。
exportTypeは、移行前に決定しておく必要があります。アクティブ・インスタンスの移行が完了して、プロセス分析が有効化されると、後戻りして完了インスタンス・データを移行できなくなってしまいます。
有効なexportTypeの値は、次のとおりです。
-
INFLIGHT_WITH_DIMENSION_AND_DEFINITION
(デフォルト): アクティブ・インスタンスのファクト・データ・アーカイブのみを移行します -
ALL
: すべてのアクティブ・インスタンスと完了インスタンスのファクト・データ・アーカイブを移行します
タスク3: (UNIXのみ) 12c SOAホームから、migrateBPMProcessCubesスクリプトを実行します。
migrateBPMProcessCubesシェル・スクリプトは、エクスポートとインポートの2フェーズで移行を実行します。最初のフェーズでは、次のアーカイブをBPMプロセス・キューブからエクスポートします。2番目のフェーズでは、エクスポートしたアーカイブをBAM 12cにインポートします。
-
DefinitionExport.zip
-
DimensionExport.zip
-
ActiveFactDataExport.zip
-
CompletedFactDataExport.zip (-exportType = ALLオプションを使用して実行している場合)
環境変数 | 説明 | 場所の例 |
---|---|---|
JAVA_HOME | サポートされているJava Development Kit (JDK)のインストール先。 | /u01/oracle/products/jdk_version |
ORACLE_HOME | Oracle Fusion Middleware全製品用にホスト・コンピュータに作成されるOracleホーム。この読取り専用ディレクトリには、バイナリ・ファイルとライブラリ・ファイル、Oracle共通ホーム・ディレクトリ、およびインストールするOracle Fusion Middlewareの各製品ごとの個別の製品ディレクトリが含まれています。
ノート: これは、11gではミドルウェア・ホームと呼ばれていました。 |
/install_location/Oracle_Home。 |
PROD_DIR | 論理製品またはフィーチャー・セットに関連付けられているバイナリ・ファイルが含まれている、Oracleホーム内のディレクトリ。Oracleホーム内の各製品ディレクトリの名前はインストーラによって事前定義され、変更できません。 | install_location/Oracle_Home/SOA |
UNIXオペレーティング・システムの場合:
cd $ORACLE_HOME/bam/bin ./migrateBPMProcessCubes.sh -serverUrl <BAM 12c server url> -serverPort <BAM 12c server port> -serverUserName <BAM 12c server user> -dbUrl <soa db jdbc url> -dbUserName <soainfra schema username> -exportDir <export dir> [-exportType ALL] [-importOnly]
説明:
serverUrl (mandatory) : BAM 12c Server URL serverPort (mandatory) : BAM 12c Server Port serverUserName (mandatory) : BAM 12c Server admin user dbUrl (mandatory) : SOA DB jdbc URL dbUserName (mandatory) : SOAINFRA schema username exportDir (mandatory) : A writable Directory where exported archives will be written exportType (optional ) : Export Type. Valid values are a)INFLIGHT_WITH_DIMENSION_AND_DEFINITION (default): Migrates only Active instance fact data archives b)ALL : Migrates all Active and Completed instance fact data archives importOnly (optional ) : If specified, data object definition and data archive export phase is skipped and only import is performed. It is assumed that archives are already present under "exportDir"
ノート:
移行中にエラーが発生した場合は、手動で問題を修正して、スクリプトを再度開始する必要があります。詳細は、「エラー処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行」を参照してください。
タスク4: (Windowsのみ) 11g BPMプロセス・キューブから、データ・オブジェクトの定義とデータをエクスポートして、それらを12cにインポートします。
データ・オブジェクト定義の移行は、2つのステップで実行されます。ステップ1では11gプロセス・キューブからデータをエクスポートし、ステップ2ではデータを12cにインポートします。
最初のフェーズでは、次のアーカイブをBPMプロセス・キューブからエクスポートし、2番目のフェーズでは、それらをBAM 12cにエクスポートします。後述するエクスポート・コマンドにより、次のアーカイブ・ファイルが<exportDir>ディレクトリに生成されます。
-
DefinitionExport.zip
-
DimensionExport.zip
-
ActiveFactDataExport.zip
-
CompletedFactDataExport.zip (
-exportType = ALL
オプションを使用して実行している場合)
タスク5: (Windowsのみ)ディメンション・データ(DimensionExport.zip)をBAMサーバーにインポートします。
このコマンドは、-datamode
および-migrate
パラメータを使用します。
次のコード例を使用して、ディメンション・データをインポートします。
cd %ORACLE_HOME%\bam\bin\ bamcommand.cmd -host <bam server host> -protocol t3 -port <bam server port> -username <bam server admin user> -dburl <bam database jdbc url> -dbusername <bam database db user> -cmd import -file <Path to DimensionExport.zip> -datamode update -migrate 1
ノート: BAM 12cのアーカイブをインポートした後で、ORACLE_HOME/bam/binディレクトリのbamcommand.log.*ファイルを調べて、エラーが発生していないことを確認します。エラー条件がある場合は、「エラー処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行」を参照してください。
タスク6: (Windowsのみ)アクティブ・ファクト・データ(ActiveFactDataExport.zip)をBAMサーバーにインポートします。
このコマンドは、-datamode
および-migrate
パラメータを使用します。
cd %ORACLE_HOME%\bam\bin\ bamcommand.cmd -host <bam server host> -protocol t3 -port <bam server port> -username <bam server admin user> -dburl <bam database jdbc url> -dbusername <bam database db user> -cmd import -file <Path to ActiveFactDataExport.zip> -datamode update -migrate 1
タスク7: (Windowsのみ: exportType=ALLの場合)完了ファクト・データ(CompletedFactDataExport.zip)をBAMサーバーにインポートします。
このコマンドは、-datamode
および-migrate
パラメータを使用します。
このコマンドは、BAM 11gプロセス・キューブのデータ・オブジェクト定義を移行したときに、exportTypeにALLを使用した場合にのみ使用します。
cd %ORACLE_HOME%\bam\bin\ run the following command bamcommand.cmd -host <bam server host> -protocol t3 -port <bam server port> -username <bam server admin user> -dburl <bam database jdbc url> -dbusername <bam database db user> -cmd import -file <Path to ActiveFactDataExport.zip> -datamode update -migrate 1
ノート: BAM 12cのアーカイブをインポートした後で、ORACLE_HOME/bam/binディレクトリのbamcommand.log.*ファイルを調べて、エラーが発生していないことを確認します。エラー条件がある場合は、「エラー処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行」を参照してください。
タスク8: 移行が正常に完了したら、Oracle BAMサーバーを再起動します。
(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh bam_server_name admin_url (Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd bam_server_name admin_url
プロンプトが表示されたらユーザー名とパスワードを入力します。
11g Monitor ExpressデータのBAM 12cプロセス・スター・スキーマへの移行(オプション)
前提条件: 「11gプロセス・キューブをBAM 12cプロセス・スター・スキーマに移行する(BPMユーザーのみ)」のステップを実行します。
このオプションのタスクは、BAM 11gの履歴データをBAM 12cのプロセス分析ダッシュボードから分析できるようにする場合にのみ実行します。これを行うには、BAM 11gのMonitor Expressデータ・オブジェクトの11gプロセス分析データを、BAM 12cのプロセス・スター・スキーマのデータ・オブジェクトに移行する必要があります。
11g Monitor ExpressのデータをBAM 12cのプロセス・スター・スキーマにアップグレードする前に、11gプロセス・キューブをBAM 12cスター・スキーマに移行して、BPMのエンティティに必要なすべての12cデータ・オブジェクトが作成されるようにする必要があります。さらに、BPMプロセス分析データも11gプロセス・キューブから移行されるようになります(キューブ表に実行時データが移入される場合にのみ該当します)。
ノート:
アーカイブ・ファイルのインポート中にエラーが発生した場合は、ロールバックSQLファイルを実行することで、BAM 12cプロセス・スター・スキーマのデータ・オブジェクトにインポートしたすべてのデータをロールバックできます。
BAM 12cデータベースのSQLプロンプトから、SOAINFRAスキーマ・ユーザーとしてログインし、<PATH>ディレクトリに移動して、次のコマンドを実行します。
sql> @rollbackMonitorExpressMigration.sql
その他のエラー処理手順の詳細は、「処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行」を参照してください。
- プロセス・メトリックを無効にします。
- Oracle BAM移行ユーティリティを実行してMonitor Expressデータを移行します。
- BPMデータをOracle BAM 12cにインポートします。
- BAM 12cへのパブリッシュを有効化します。
親トピック: Oracle BAM 12cを含むSOAドメインの拡張
Oracle BAM移行ユーティリティを実行してMonitor Expressデータを移行します。
データ・オブジェクトとデータ・オブジェクト定義は、「11gプロセス・キューブのBAM 12cプロセス・スター・スキーマへの移行(BPMユーザーのみ)」で移行済です。
次のコマンドにより、BPMデータのデータ・エクスポートがzip圧縮されたCSVファイルで作成されます。
java -cp $DOMAIN_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.metrics.interface.jar: $ORACLE_HOME/oracle_common/modules/oracle.jdbc_12.1.0/ojdbc6.jar: $ORACLE_HOME/bam/modules/oracle.bam.client/bam-client.jar: $ORACLE_HOME/bam/lib/bam-schema.jar: $ORACLE_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.metrics.dataobject.jar: $ORACLE_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.hwfanalytics.dataobject.jar: $ORACLE_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.metrics.model.jar oracle.bpm.metrics.dataobject.migration.application.Migrate11gBAMBPMTo12cDO PropertyFiles
このコマンドにより、<
PATH>
ディレクトリに、FactDataExport.zipファイルが作成されます。
ノート: プロパティ・ファイルで、コンポジット名を指定できます。コンポジット名を指定すると、該当するコンポジットのみのデータが移行されるようになります。プロパティ・ファイルでコンポジット名を定義していないと、すべてのコンポジット・データが移行されます。
#************************************* #Mandatory Fields #************************************* #11g User Name BAM_11g_USER_NAME= <<11gUserName>> #12c User Name BAM_12c_SOURCE_NAME = <<12cUserName>> #11g URL BAM_11g_URL=jdbc:oracle:thin:@<<11gBAMSchemaDatabaseIP>>:<<Port>>:<<SID>> #12c URL BAM_12c_URL=jdbc:oracle:thin:@<<12cDatabaseIP>>:<<Port>>:<<SID>> #Path where data to be exported PATH = <<Path where data need to be exported>> #************************************* #Optional Fields #************************************ COMPOSITE_LIST = <<List of Composite for which data needs to be exported. This is ':' separated>> #If above mention configurable is missing then all the composite data will be migrated. DATAOBJECT_FOLDER_PATH = <<DataObject Path If this field is absent then default path will taken as Samples/Monitor Express/BI_>> #************************************
BPMデータをOracle BAM 12cにインポートします。
このステップにより、事前にエクスポートしたBPM Monitor Expressデータが、確実にBAM 12cにインポートされます。
cd $DOMAIN_HOME/bam/bin ./bamcommand -host <<host>> -protocol t3 -dbusername <<DbUserName>> -dburl jdbc:oracle:thin:@<<DBIP>>:<<Port>><<SID>> -username <<weblogicUserName>> -cmd import -file <<Path of BPM FactDataExport zip file >> -mode update -migrate 1
BAM 12cへのパブリッシュを有効化します。
移行が完了したら、BAM 12cへのパブリッシュを有効にするために、DisableProcessMetrics
パラメータをfalseに設定します。
ノート:
アーカイブ・ファイルのインポート中にエラーが発生した場合は、ロールバックSQLファイルを実行することで、BAM 12cプロセス・スター・スキーマのデータ・オブジェクトにインポートしたすべてのデータをロールバックできます。
BAM 12cデータベースのSQLプロンプトから、SOAINFRAスキーマ・ユーザーとしてログインし、<PATH>ディレクトリに移動して、次のコマンドを実行します。
sql> @rollbackMonitorExpressMigration.sql
その他のエラー処理手順の詳細は、「処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行」を参照してください。
12cでの11g互換プロセス・スター・スキーマ・データ・ビューの生成(オプション)
11gのプロセス・スター・スキーマ・ビューを基にして構築されたOracle Fusion Middleware 11gアプリケーションがあるときに、そのアプリケーションを12cでも継続して使用する場合は、そのビューをアップグレード後に再作成する必要があります。12cのスター・スキーマ・データベース・ビューは、11gのビューとは異なっていて、自動的にアップグレードできません。
つまり、12cのスター・スキーマ・データベース・ビューには異なる名前が付けられていて、Oracle BAMデータ・オブジェクトを基にしており(プロセス・キューブ表を基にしていない)、コンポジット・レベルで作成されている(11gのようにプロセス・レベルではない)ということです。Oracle 12c環境で使用するビュー(標準およびプロセス固有の両方)の再作成を支援するために、自動化されたユーティリティが用意されています。
親トピック: Oracle BAM 12cを含むSOAドメインの拡張
タスク1: クラスパスを更新してインタフェースJARファイルを含める
CLASSPATHを更新して、SOAホームにあるoracle.bpm.analytics.interface.jarファイルの場所が含まれるようにする必要があります。
たとえば:
DOMAIN_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.interface.jar
タスク2: 標準のビューを再作成する
標準ビュー11g移行ユーティリティを使用して、次に示す11g標準ビューの12c互換バージョンを作成します。
- BPM_ACTIVITY_DEFINITION_V
- BPM_ACTIVITY_INSTANCE_V
- BPM_ACTIVITY_PERFORMANCE_V
- BPM_PROCESS_DEFINITION_V
- BPM_PROCESS_INSTANCE_V
- BPM_PROCESS_PERFORMANCE_V
- BPM_ROLE_DEFINITION_V
次のコマンドを使用して、ユーティリティを実行します。
java -cp $DOMAIN_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.interface.jar oracle.bpm.analytics.cube.persistence.util.StandardView11gMigrationUtil
<initialContextFactory> <protocol> <hostname> <soa-port> <username>[]
説明:
-
initialContextFactoryはJNDI初期コンテキスト・ファクトリです(
weblogic.jndi.WLInitialContextFactory
など)。 -
protocolは、ターゲット・サーバー用に構成されたRMI/JNDIプロトコルです。t3、IIOP、HTTP、T3s、IIOPSまたはHTTPSを指定します。
-
hostnameは、ホストのフル・ネームです(
soa.mycompany.com
など)。 -
soa-portは、SOAのリスニング・ポートです(
7001
など)。 -
usernameは、サーバーのログイン名です(
weblogic
など)。
タスク3: プロセス固有のビューを再作成する
プロセス固有ビュー11g移行ユーティリティを使用して、次に示す11gプロセス固有ビューの12c互換バージョンを作成します。
- BPM_ACTV_INST_<viewIdentifier>_V
- BPM_ACTV_PERF_<viewIdentifier>_V
- BPM_PRCS_INST_<viewIdentifier>_V
- BPM_PRCS_PERF_viewIdentifier>_V
次のコマンドを使用して、ユーティリティを実行します。
java -cp $DOMAIN_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.interface.jar oracle.bpm.analytics.cube.persistence.utill.ProcessSpecificView11gMigrationUtil
<initialContextFactory> <protocol> <hostname> <soa-port> <username > [<composite-name>]
説明:
-
initialContextFactoryはJNDI初期コンテキスト・ファクトリです(
weblogic.jndi.WLInitialContextFactory
など)。 -
protocolは、ターゲット・サーバー用に構成されたRMI/JNDIプロトコルです。t3、IIOP、HTTP、T3s、IIOPSまたはHTTPSを指定します。
-
hostnameは、ホストのフル・ネームです(
soa.mycompany.com
など)。 -
soa-portは、SOAのリスニング・ポートです(
7001
など)。 -
usernameは、サーバーのログイン名です(
weblogic
など)。 -
composite-name(オプション)は、ビューを作成する単一のコンポジットの名前です。
失敗したOracle BAMアップグレードからのリカバリ
この項は、BAMサーバーがドメイン内に存在する場合にのみ当てはまります。BAMアップグレードの一環として、BAMアーカイブを11gからエクスポートして、それをBAM 12cにインポートできます。このプロセス中にエラーが返された場合は、この項を使用して問題の解決にあたってください。
CFGFWK-60950エラーの解決
CFGFWK-60950エラーを受け取った場合は、BAMテンプレートの名前を変更して(「11gスキーマのアップグレード前のOracle BAMテンプレートの名前の変更」を参照)、再構成ウィザードを再度起動します。
このエラーを受け取ったら、アップグレード前の環境全体をリストアし、必要なアップグレード前タスクを実行して、リストされている項のステップを実行する必要があります。その後で、再構成プロセスを再度実行してみてください。
親トピック: 失敗したOracle BAMアップグレードからのリカバリ
エラー処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行
一般的なエラーは、データの変更内容をロール・バックして、オプションを変更したスクリプトを再実行することで解決できることがあります。
すべてのデータ変更内容のロールバック:
使用しているオペレーティング・システムの推奨事項を確認してください。
親トピック: 失敗したOracle BAMアップグレードからのリカバリ
UNIXオペレーティング・システムのエラー処理
移行時に予期しないエラーが発生した場合は、問題を修正するために次のステップを実行してみてください。
インポート・フェーズで発生したエラーの場合:
BAM 12cにアーカイブをインポートしているときにエラーが発生した場合は、「11gプロセス・キューブのBAM 12cプロセス・スター・スキーマへの移行(BPMユーザーのみ)」で説明するように、スクリプトmigrateBPMProcessCubes.shを再実行します。ただし、-importOnlyオプションを追加してください。エクスポートのステップを省略することで、時間を節約できます。
たとえば:
cd $ORACLE_HOME/bam/bin ./migrateBPMProcessCubes.sh -serverUrl <BAM 12c server url> -serverPort <BAM 12c server port> -serverUserName <BAM 12c server user> -dbUrl <soa db jdbc url> -dbUserName <soainfra schema username> -exportDir <export dir> [-exportType ALL] [-importOnly]
エクスポート・フェーズで発生したエラーの場合:
BPMプロセス・キューブからアーカイブをエクスポートしているときにエラーが発生した場合は、次のタスクを実行します。
追加情報:
問題の解決を支援するために、次の作業も実行してみてください。
-
BAM 12cに各アーカイブをインポートした後で、$ORACLE_HOME/bam/binディレクトリにあるbamcommond.log.*ファイルを調べて、エラーが発生していないことを確認します。
-
<exportDir>/MigrationLogs.*にある移行のログを調べます。
親トピック: 失敗したOracle BAMアップグレードからのリカバリ
Windowsオペレーティング・システムのエラー処理
前述したように、すべてのデータ変更内容をロールバックして、次を実行してみてください。
インポート・フェーズで発生したエラーの場合:
次の各項で説明しているとおりに、アーカイブを再インポートします。
-
タスク5: (Windowsのみ)ディメンション・データ(DimensionExport.zip)をBAMサーバーにインポートします。
-
タスク6: (Windowsのみ)アクティブ・ファクト・データ(ActiveFactDataExport.zip)をBAMサーバーにインポートします。
-
タスク7: (Windowsのみ: exportType=ALLの場合)完了ファクト・データ(CompletedFactDataExport.zip)をBAMサーバーにインポートします。
エクスポート・フェーズで発生したエラーの場合:
BPMプロセス・キューブからアーカイブをエクスポートしているときにエラーが発生した場合は、次のタスクを実行します。
親トピック: 失敗したOracle BAMアップグレードからのリカバリ