| Oracle® Fusion Middleware SOA SuiteおよびBusiness Process Managementのアップグレード 12c (12.2.1.2) E82837-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware SOA SuiteおよびBusiness Process Managementのアップグレード 12c (12.2.1.2) E82837-02 |
|
|
前 |
次 |
注意:
BAM 12cリリースを含む、以前のOracle SOA Suiteからアップグレードする場合、「Business Activity Monitoringを含むOracle SOA Suiteの以前の12cリリースからのアップグレード」を参照してください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を含むSOA 11gドメインからOracle BAM 12cを含むSOA 12cドメインへのアップグレード・プロセスの概要を示しています。
この項のタスクは、Oracle BAM 11gを含むSOAドメインを12cにアップグレードするときに実行してください。
既存の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 11gドメインを新しい場所にインストールして構成したら、アップグレード前に、11g Oracle BAM ICommandユーティリティを使用して既存の(旧) Oracle BAM 11gドメインからデータをエクスポートし、そのデータを新しいOracle BAM 11gドメインにインポートする必要があります。
11g Oracle BAM ICommandコマンドライン・ユーティリティを使用したデータ・ファイルのエクスポートの詳細は、Oracle BAMによるビジネス・アクティビティの監視のエクスポートに関する項を参照してください。
Oracle BAM 11gアーティファクト(DOとEMSにかぎらず)の完全なエクスポートXMLを作成した後で、そのXMLファイルを新しく作成したOracle BAM 11gドメインにインポートする必要があります。これにより、アップグレードとドメイン再構成の後も、完全に機能するOracle BAMドメインを維持できるようになります。
11g Oracle BAM ICommandコマンドライン・ユーティリティを使用したデータ・ファイルのエクスポートの詳細は、Oracle BAMによるビジネス・アクティビティの監視のインポートに関する項を参照してください。
アップグレードが失敗した場合は、バックアップ・バージョンを使用して、アップグレード前の環境全体をリストアする必要があります。アップグレード・プロセスを続行する前に、Oracle BAM 11g環境全体のバックアップ・バージョンを必ず作成してください。バックアップのドメインは、「アップグレード前の新しいOracle BAM 11gドメインの作成」で作成した新しいOracle BAM 11gドメインとは異なります。
詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのアップグレードのプランニング』のアップグレードのためのバックアップおよびリカバリ計画に関する項を参照してください。
Oracle BAMを含むSOA 11gドメインを、Oracle BAMを含むSOA 12c (12.2.1.2)ドメインにアップグレードするには、この手順を使用します。
これらのタスクは、Oracle BAM 11gドメインの完全なバックアップを作成するまで実行しないでください。
アップグレードを開始する前に、Oracle Universal Installerを使用してOracle Fusion Middleware Infrastrucutreディストリビューション、Oracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.2)ディストリビューション、およびその他のSOA Suite製品をターゲット・システムにインストールします。
注意:
アップグレードにInfrastructureが必要な場合は、その他のFusion Middleware製品をインストールする前に、まずOracle Fusion Middleware Infrastructureディストリビューションをインストールする必要があります。以前の12cリリース(12.1.3.0、12.2.1.0または12.2.1.1)からアップグレードする場合は、12c (12.2.1.2)ディストリビューションを新しいOracleホームにインストールする必要があります。このアップグレードのために既存のOracleホームを再使用しようとしないでください。12c (12.2.1.2)へのアップグレードは、パッチ・リリースではありません。
Oracle SOA Suiteには、Oracle Fusion Middleware Infrastructure (Oracle WebLogic ServerおよびJRF)が必要です。
Fusion Middlewareインフラストラクチャをインストールすると、Oracleホーム・ディレクトリが作成され、その他のFusion Middleware製品をインストールするためのサポート・ソフトウェアが配置されます。
soa_generic.jarの一部です。 11gからアップグレードする場合、アップグレードを開始する前に、リポジトリ作成ユーティリティ(RCU)を使用して必要な12cスキーマを作成する必要があります。
Oracle Fusion Middleware 11gリリースでは、SOAスキーマは必須ではなかったため、データベースなしでBusiness Activity Monitoring (BAM)を実行することもできました。ただし、12cでは、Business Activity Monitoring 12c (12.2.1.2)を実行する前に、サポートされているデータベースを必須のSOAスキーマで構成しておく必要があります。
注意:
Oracle Fusion Middlewareの前の12cリリースからアップグレードする場合、これらのスキーマがすでに存在する場合には再作成する必要はありません。ドメインの既存のスキーマを特定するには、次の手順を参照してください。11gからアップグレードする場合は、「アップグレード前チェックリスト」を参照してドメイン内の既存のスキーマを識別します。12cにアップグレードする前に、次のスキーマが存在している必要があります。
サービス表スキーマ(prefix_STB)。このスキーマは12cで新規のものであり、ドメインベースのアップグレードに必要になります。基本的なスキーマ構成情報(スキーマ接頭辞やパスワードなど)が格納され、他のOracle Fusion Middlewareコンポーネントはドメイン作成中にこれにアクセスして使用できます。このスキーマはリポジトリ作成ユーティリティ(RCU)を実行するときに自動的に作成され、ここで他の11gスキーマに使用した既存のスキーマ所有者接頭辞を指定します。注意: サービス表スキーマが存在しない場合、UPGAST-00328: スキーマ・バージョンのレジストリ表はこのデータベースに存在しません。その場合、アップグレード・アシスタントを実行するためにはサービス表スキーマを作成する必要があります。というエラー・メッセージが表示されることがあります。
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 Business Activity Monitoring (BAM)データがエクスポート済になっていることを確認してください。よくわからない場合は、既存のドメインからのすべてのOracle BAM 11gアーティファクトのエクスポートを参照してください。
テンプレートは、12cのディレクトリ$ORACLE_HOME/soa/common/templates/wlsにあります。
| テンプレート名 | 変更後の名前 |
|---|---|
oracle.bam.reconfig_template_12.2.1.2.0.jar |
oracle.bam.reconfig_template_12.2.1.2.0.jar.old |
oracle.bam.reconfig.template_12.2.1.2.0.jar.rename |
oracle.bam.reconfig_template_12.2.1.2.0.jar |
Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーを停止する必要があります。
Oracle Fusion Middleware環境は、Oracle WebLogic Serverドメイン、管理サーバー、複数の管理対象サーバー、Javaコンポーネント、Identity Managementコンポーネントなどのシステム・コンポーネント、およびメタデータのリポジトリとして使用されるデータベースで構成できます。それらのコンポーネントは相互に依存する場合があるため、正しい順序で停止する必要があります。
注意:
この項内の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用してサーバーおよびプロセスを停止する方法を説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。Oracle Fusion Middlewareの管理の管理サーバー、管理対象サーバーおよびノード・マネージャの起動と停止を参照してください。Fusion Middleware環境を停止するには、次の手順に従います。
手順1: システム・コンポーネントの停止
Oracle HTTP Serverなどのシステム・コンポーネントを停止するには、stopComponentスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name
(Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name
どの順序でもシステム・コンポーネントを停止できます。
手順2: 管理対象サーバーの停止
WebLogic Server管理対象サーバーを停止するには、stopManagedWebLogicスクリプトを使用します。
(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)管理対象サーバー
手順3: Oracle Identity Managementコンポーネントの停止
環境の一部を形成する、Oracle Internet DirectoryなどのOracle Identity Managementコンポーネントを停止します。(UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name
(Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name
手順4: 管理サーバーの停止
管理サーバーを停止するときには、WebLogic Server管理コンソールおよびFusion Middleware Controlなど、管理サーバーで実行されているプロセスも停止します。
管理サーバーを停止するには、stopWebLogicスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/stopWebLogic.sh
(Windows) 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にアップグレードします。
アップグレード・アシスタントを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるアップグレード・アシスタントの画面は異なります。
schema_version_registry内のスキーマ・バージョンが正しく更新されていることを確認することで、アップグレードの成功を確認します。Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。
oracle_common/upgrade/binディレクトリに移動します。ORACLE_HOME/oracle_common/upgrade/binORACLE_HOME\oracle_common\upgrade\binロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。
アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。
表5-5 Upgrade Assistantコマンド・ライン・パラメータ
| パラメータ | 必須/オプション | 説明 |
|---|---|---|
|
準備状況チェックに必要 注意: 準備状況チェックは、スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。 |
実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。 スキーマおよび構成がチェックされます。
|
|
オプション | スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックに必要 |
GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantがサイレント・モード(Upgrade Assistantの画面の表示なし)で実行されます。 |
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
オプション |
次のいずれかの属性を指定して、ロギング・レベルを設定します。
デフォルトのロギング・レベルは より多くの情報がログ記録されるよう、 |
|
オプション |
アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 UNIXの場合:
Windowsの場合:
|
|
オプション |
すべてのコマンド・ライン・オプションを表示します。 |
Upgrade Assistantで複数の画面をナビゲートし、製品スキーマをアップグレードします。
注意:
パージ・スクリプトまたはスケジュールされたデータベース・ジョブの実行中は、アップグレード・アシスタントを起動しないでください。
パージまたはアップグレードが完了するまで待ってから、アップグレード・プロセスを開始してください。アップグレード・アシスタントを使用してスキーマをアップグレードするときに、パージ・スクリプトまたはインスタンスのアップグレード・ジョブを実行していると、アップグレードは失敗します。
アップグレード・アシスタントを起動する必要がある場合は、「バックグラウンド制御ジョブの有効化と無効化(オプション6)」で説明しているように、パージを停止してスケジュールされたジョブを無効にしてください。
たとえば、Oracle SOAを選択した場合、Oracle SOA (_SOAINFRA)、Audit Services (_IAU)、Metadata Service (_MDS)、Oracle Platform Security Services(_OPSS)およびUser Messaging Services (_UMS)スキーマがアップグレードに含まれます。
Managed File Transferを選択した場合、監査サービス(_IAU)、Enterprise Scheduler (_ESS)およびPlatform Security Services (OPSS)がアップグレードに含まれます。
すべてのアップグレード手順が完了したら、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.2.0であることを確認します。ただし、すべてのスキーマ・バージョンが更新されるわけではないことに注意してください。一部のスキーマは、このリリースにアップグレードする必要がなく、アップグレード前のバージョン番号のままになります。
STATUSフィールドは、スキーマのパッチ適用処理中はUPGRADINGまたはUPGRADEDのどちらかになり、その処理が完了するとVALIDになります。
ステータスが「INVALID」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。
IAU_APPENDおよびIAU_VIEWERに所有されているシノニム・オブジェクトは、INVALIDと表示されますが、失敗を示しているわけではありません。
それらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトは、アクセスされるときに有効になります。これらのINVALIDオブジェクトは無視してかまいません。
Oracle BAMの再構成テンプレートの名前を変更した後、再構成ウィザードを起動し、説明されている手順に従います。
再構成ウィザードにより、Oracle BAM 11gアプリケーション、ライブラリ、BAMDataSource、BAMJMSSserverおよびBAMJmsSystemResourceがドメインから削除されます。
注意: アップグレード後に、Oracle BAMサーバーおよびクラスタを手動で削除する必要があります(構成後作業「ドメインからのOracle BAMサーバーおよびクラスタの削除」を参照)。
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)に再構成します。
WebLogic Serverドメインを再構成すると、ドメイン内のアプリケーションに応じて、次の項目が自動的に更新されます。
WebLogic Serverコア・インフラストラクチャ
ドメイン・バージョン
注意:
ドメイン再構成を開始する前に、次の制限事項に注意してください。
再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。
アップグレード・プロセスの間の非動的クラスタ・ドメインから動的クラスタ・ドメインへの変換はサポートされていません。
動的クラスタ機能は再構成ウィザードの実行時に使用可能ですが、Oracleでは、非動的クラスタのアップグレード後の動的クラスタの追加のみがサポートされています。アップグレード・プロセスの間に動的クラスタを追加することはできません。
ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。
すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。
起動スクリプトが更新されます。
変更した起動スクリプトを保持する必要がある場合は、再構成ウィザードを開始する前にそれらをバックアップするようにしてください。
注意:
ドメインの再構成プロセスを開始すると、元に戻すことはできません。再構成ウィザードを実行する前に、アップグレード前チェックリストに示されているようにドメインをバックアップしてあることを確認してください。再構成ウィザードの実行中にエラーまたは他の割込みが発生した場合、バックアップ場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーすることによって、ドメインをリストアする必要があります。これは、ドメインが再構成前の元の状態に戻されたことを確認する唯一の方法です。再構成ウィザードを実行する前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。
ドメイン・ディレクトリのバックアップを作成するには、次の手順を実行します。
Upgrade Assistantを実行する前に、再構成ウィザードを使用して、まず既存のドメインを再構成する必要があります。
注意:
ソースがクラスタ環境である場合は、再構成ウィザードをプライマリ・ノードでのみ実行します。圧縮/解凍ユーティリティを使用して、ドメイン内の他のクラスタ・メンバーに変更を適用します。注意:
「拡張構成」画面に表示されるオプション・カテゴリは、ドメインのために選択したテンプレートで定義されているリソースによって異なります。一般的な一部のカテゴリを次に示します。ドメインの各管理対象サーバーに対し、リスニング・アドレスの実際のホスト名を指定する必要があります。
デフォルトのlocalhostまたは「すべてのローカル・アドレス」オプションは使用しないでください。
実際のホスト名を、hostname.company.comのように指定する必要があります。
「管理対象サーバー」>サーバー・グループのターゲット指定
注意:
以前の12cリリース(たとえば12.1.3)で作成されたドメインをアップグレードする場合、アップグレードのドメイン再構成フェーズで、サーバーを正しいサーバー・グループにターゲット指定する必要があります。これらのサーバーのターゲット指定に失敗すると、アップグレードの失敗や不要なダウンタイムの発生につながることがあります。「管理対象サーバー」画面で「サーバー・グループ」ドロップダウン・メニューから正しいグループ名を選択して、各サーバーを正しいサーバー・グループにターゲット指定します。
GUID-E96F27A4-74D8-4A33-83E3-1829BDBD98B4-default.pngの説明が続きます。
| コンポーネントとサーバー | サーバー・グループ |
|---|---|
| SOA (soa_server1) | SOA-MGD-SVRS-ONLY |
| Oracle Service Bus — OSB (osb_server1) | OSB-MGD-SVRS-ONLY |
| Business Activity Monitoring — BAM (bam_server1) | BAM-MGD-SVRS-ONLY |
| Managed File Transfer — MFT (mft_server1) | MFT-MGD-SVRS-ONLY |
アップグレード・プロセスの一部としてサーバーを作成した場合は、「サーバー」リスト・ボックスでサーバー名を選択して、適切なノード・マネージャ・マシンにターゲット設定します。
そうでない場合は、ドメインのアップグレード時または再構成時にこの画面で操作は必要ありません。
クラスタのアップグレードのみ: クラスタをアップグレードする場合は、この画面を使用して管理対象サーバーをクラスタに割り当てます。
「サーバー」リスト・ボックスには管理対象サーバーのみが表示されます。管理サーバーは、クラスタに割り当てることができないので、リストに表示されません。
注意:
OWSMPMがそれ固有のクラスタ内にあり、SOAまたはOSBクラスタの一部ではない場合:ドメインの再構成が終了したら、アップグレード・アシスタントを再実行して、残りのコンポーネントの構成をアップグレードします。
ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。
oracle_common/upgrade/binディレクトリに移動します。ORACLE_HOME/oracle_common/upgrade/binORACLE_HOME\oracle_common\upgrade\binロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。
アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。
表5-6 Upgrade Assistantコマンド・ライン・パラメータ
| パラメータ | 必須/オプション | 説明 |
|---|---|---|
|
準備状況チェックに必要 注意: 準備状況チェックは、スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では実行できません。 |
実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。 スキーマおよび構成がチェックされます。
|
|
オプション | スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックに必要 |
GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、Upgrade Assistantがサイレント・モード(Upgrade Assistantの画面の表示なし)で実行されます。 |
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
オプション |
次のいずれかの属性を指定して、ロギング・レベルを設定します。
デフォルトのロギング・レベルは より多くの情報がログ記録されるよう、 |
|
オプション |
アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 UNIXの場合:
Windowsの場合:
|
|
オプション |
すべてのコマンド・ライン・オプションを表示します。 |
最終的にOracle BAM 12cを含むことになる、SOA 12cドメインを実行するには、アップグレード後に追加の構成作業を実行する必要があります。
注意:
Oracle BAM 11gを含む12c SOA環境を最初に実行することをお薦めします。環境が予想どおりに機能することを確認した後、Oracle BAM 12cを含むドメインを拡張できます(「Oracle BAM 12cを含むSOAドメインの拡張」を参照)。
Oracle WebLogic管理サーバーを起動するには、次のスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/startWebLogic.sh (Windows) DOMAIN_HOME\bin\startWebLogic.cmd
ここに示す手順は、スタンドアロン環境またはクラスタ化環境のUMS JMSリソースを削除するために使用できます。Oracle BAMクラスタには、追加の手順が必要になります。
UMSJMSServer_auto_1になります。選択したUMS JMSサーバーのターゲットが、Oracle BAMサーバーまたはOracle BAMクラスタであることを必ず確認してください。「JMSサーバーのサマリー」画面に移動します(次の図を参照)。「ドメイン構造」メニューで、「サービス」を開き、「メッセージング」→「JMSサーバー」を選択します。Oracle BAMサーバーに向けてターゲット設定されているUMSJMSServerを見つけます。
次の例では、UMSJMSServer_auto_3はOracle BAMサーバーにターゲット設定されたサーバーです。
UMSJMSServer_auto_3)のローカル・キューを削除します。 「JMSモジュールのサマリー」画面に移動します(次の図を参照)。「ドメイン構造」メニューで、「サービス」を開き、「JMSモジュール」を選択します。UMSJMSSystemResourceを見つけてクリックすることで、「UMSJMSSystemResourceの設定」画面にローカル(および分散)キューを表示します。この結果にフィルタを適用すると、UMS JMSサーバーにターゲット設定したキューのみを表示できます。
UMSJMSServer_auto_3)のみをターゲットに設定した共通分散キューをすべて選択します。(タイプ「共通分散キュー」でフィルタ処理できます)。「削除」をクリックします。注意: Oracle BAM以外のサーバー・ターゲットを含む分散キューは、削除しないでください。その他のターゲット対象サーバーがある場合は、まず、分散キューからOracle BAMサーバーを削除(ターゲット設定解除)しておく必要があります(手順4を参照)。
分散キューからOracle BAMサーバーのターゲット設定を解除するには、「UMSJMSSystemResourceの設定」画面で「ターゲット」タブをクリックします。Oracle BAMサーバーの横のチェックマークを削除して、「保存」をクリックします。これで、手順3の説明に従って、分散キューを安全に削除できます。
「UMSJMSSystemResourceの設定」画面で、Oracle BAMに向けてターゲット設定されているUMS JMSサーバー(UMSJMSServer_auto_3)にターゲット設定されたローカル・キューをすべて選択します(次を参照)。
Oracle BAMにターゲット設定されたUMS JMSサーバーにターゲット設定されたサブデプロイメントのリソースを削除します。
UMSJMSServer_auto_3)。管理サーバーの実行中に、Weblogicコンソールを使用して、次のタスクを完了します。
注意:
Fusion Middleware Controlコンソールを介した操作の詳細は、「Oracle SOA SuiteおよびOracle BPM Suiteの管理のスタート・ガイド」を参照してください。
UMSJMSServer_auto_x を選択します。「現在のターゲット」が、Oracle BAMサーバーであることを確認します。
UMSJMSFileStore_auto_xを選択します。(「ターゲット」が、Oracle BAMサーバーであることを確認します。)
bam_clusterを選択します。 domainupdaterスクリプトを使用して、不要な11gのファイルをアップグレードしたドメインから削除します。
クラスタをアップグレードする場合は、まず、管理サーバーと管理対象サーバーを停止してから、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
管理対象サーバーは、次に示す順序で停止する必要があります。
管理対象サーバーを停止する
ドメインを拡張する前に、現在実行中の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を入力します。
クラスタ内の別のノードに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コマンドを実行して、リモート・マシン上の管理対象サーバー・ドメイン・ディレクトリに使用する、完全なドメインまたはドメインのサブセットを作成します
リモート・マシンの管理対象サーバー・ドメイン・ディレクトリに使用されるフル・ドメインまたはドメインのサブセットを作成できます。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ドメインのアップグレードが完了したら、このSOA 12cドメインを構成して、Oracle BAM 11gドメインを使用するようにします
「アップグレード前の新しいOracle BAM 11gドメインの作成」で作成したOracle BAM 11gドメインを使用します。
この設定の構成方法の詳細は、11gバージョンの『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のOracle BAMアダプタの構成に関する項を参照してください。
構成後の作業を完了するには、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サーバーおよびプロセスを次の順番で起動します。
サービス指向アーキテクチャ(SOA)管理対象サーバー
Oracle Service Bus (OSB)管理対象サーバー
Business Activity Monitoring (BAM)管理対象サーバー
注意:
通常は、管理対象サーバーの起動により、それにデプロイされているアプリケーションが起動します。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。メール・パターンとの非互換性問題があるため、Oracle Enterprise ManagerのUMSドライバを削除する必要があります。
新しいドライバは、SOA 12cドメインをOracle BAM 12cテンプレートで拡張した後に作成します。
usermessagingdriver-mailサービスを選択します。 「ユーザー・メッセージング電子メール・ドライバ」ドロップダウン・メニューで、「電子メール・ドライバ・プロパティ」を選択します(次の図を参照)。
アップグレードされたSOA 12c環境とともにOracle BAM 12cを使用する準備が整っている場合、BAM 12cテンプレートを含むようにドメインを拡張する必要があります。
その場合、次の手順に従います。一部のタスクはオプションです。
管理対象サーバーを停止する
ドメインを拡張する前に、現在実行中の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ドメインを拡張します。
SOA、OSB、BAMなど特定のFusion Middlewareコンポーネントは、12cではUMSに依存しています。単一の12.2.1ドメイン内でこれらのコンポーネントのうち複数を構成する場合は、コンポーネントが動作するサーバーが1つしかない場合でも、これらのコンポーネントは各自のクラスタ内で動作する必要があります 。「クラスタ化されたSOA環境のアップグレード」の図8-1を参照してください。
構成ウィザードの「拡張構成」画面に進んだら、「管理対象サーバー、クラスタおよびCoherence」を選択して、『構成ウィザードによるWebLogicドメインの作成』のクラスタに関する項の説明に従い、BAMクラスタを作成します。
Oracle BAMサーバーがクラスタで実行されているときに、Fusion Middleware Controlコンソールを使用して、次のタスクを完了します。
「ターゲット・ナビゲーション」ペインで「ユーザー・メッセージング・サービス」を選択し、「ユーザー・メッセージング電子メール・ドライバ」ドロップダウン・メニューで「電子メール・ドライバ・プロパティ」を選択します(次の図を参照)。
BAM 12cが含まれるようにドメインを拡張した後で、SOA 12cで使用しているBAM 11g環境から、データ・オブジェクトとEMSデータをエクスポートする必要があります。その後で、BAM 12cを含むSOA環境に、このデータをインポートします。
注意:
importコマンドを-upgradeパラメータとともに使用して、Oracle BAM 11gアーティファクトをOracle BAM 12cに移行すると、一部の情報が変更されます。
BAM 11gドメインで使用したダッシュボード、アラート、ビューなどは、BAM 12cドメインで再作成する必要があります。
BAMユーザー・ガイド、Oracle BAMによるビジネス・アクティビティの監視の、次に関する項を参照してください。
ダッシュボードの作成
アラートの作成
パラメータの作成
ビジネス・ビューの作成と使用
アップグレード済のBPM 12cドメインをBAM 12cで拡張した後には、プロセス・キューブの移行を実行することを強くお薦めします。この移行により、BPMエンティティに必要なすべての12cデータ・オブジェクトが作成されるようになります。さらに、BPMプロセス分析データも11gプロセス・キューブから移行されるようになります(キューブ表に実行時データが移入される場合にのみ該当します)。
各アーカイブをエクスポートおよびインポートするときに、SOAINFRAスキーマのユーザー名とパスワードに加えて、サーバー管理者(admin)のユーザー名とパスワードを指定する必要があります。
注意:
プロセス・キューブの移行は、Monitor Expressの移行(「11g Monitor ExpressデータのBAM 12cプロセス・スター・スキーマへの移行」を参照)を開始する前の必須の前提条件です。
この手順は、BPM 11gでOracle BAM 11g Monitor Expressを使用していなかった場合でも必要になります。
exportTypeは、移行前に決定しておく必要があります。アクティブ・インスタンスの移行が完了して、プロセス分析が有効化されると、後戻りして完了インスタンス・データを移行できなくなってしまいます。
有効なexportTypeの値は、次のとおりです。
INFLIGHT_WITH_DIMENSION_AND_DEFINITION (デフォルト): アクティブ・インスタンスのファクト・データ・アーカイブのみを移行します
ALL: すべてのアクティブ・インスタンスと完了インスタンスのファクト・データ・アーカイブを移行します
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スター・スキーマへの移行」を参照してください。
データ・オブジェクト定義の移行は、2つの手順で実行されます。手順1では11gプロセス・キューブからデータをエクスポートし、手順2ではデータを12cにインポートします。
最初のフェーズでは、次のアーカイブをBPMプロセス・キューブからエクスポートし、2番目のフェーズでは、それらをBAM 12cにエクスポートします。後述するエクスポート・コマンドにより、次のアーカイブ・ファイルが<exportDir>ディレクトリに生成されます。
DefinitionExport.zip
DimensionExport.zip
ActiveFactDataExport.zip
CompletedFactDataExport.zip (-exportType = ALLオプションを使用して実行している場合)
このコマンドは、-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スター・スキーマへの移行」を参照してください。
このコマンドは、-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
このコマンドは、-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スター・スキーマへの移行」を参照してください。
(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh bam_server_name admin_url (Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd bam_server_name admin_url
プロンプトが表示されたらユーザー名とパスワードを入力します。
前提条件: 「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スター・スキーマへの移行」を参照してください。
データ・オブジェクトとデータ・オブジェクト定義は、「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 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へのパブリッシュを有効にするために、DisableProcessMetricsパラメータをfalseに設定します。
注意:
アーカイブ・ファイルのインポート中にエラーが発生した場合は、ロールバックSQLファイルを実行することで、BAM 12cプロセス・スター・スキーマのデータ・オブジェクトにインポートしたすべてのデータをロールバックできます。
BAM 12cデータベースのSQLプロンプトから、SOAINFRAスキーマ・ユーザーとしてログインし、<PATH>ディレクトリに移動して、次のコマンドを実行します。
sql> @rollbackMonitorExpressMigration.sql
その他のエラー処理手順の詳細は、「処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行」を参照してください。
11gのプロセス・スター・スキーマ・ビューを基にして構築されたOracle Fusion Middleware 11gアプリケーションがあるときに、そのアプリケーションを12cでも継続して使用する場合は、そのビューをアップグレード後に再作成する必要があります。12cのスター・スキーマ・データベース・ビューは、11gのビューとは異なっていて、自動的にアップグレードできません。
つまり、12cのスター・スキーマ・データベース・ビューには異なる名前が付けられていて、Oracle BAMデータ・オブジェクトを基にしており(プロセス・キューブ表を基にしていない)、コンポジット・レベルで作成されている(11gのようにプロセス・レベルではない)ということです。Oracle 12c環境で使用するビュー(標準およびプロセス固有の両方)の再作成を支援するために、自動化されたユーティリティが用意されています。
CLASSPATHを更新して、SOAホームにあるoracle.bpm.analytics.interface.jarファイルの場所が含まれるようにする必要があります。
次に例を示します。
DOMAIN_HOME/soa/modules/oracle.bpm.runtime_11.1.1/oracle.bpm.analytics.interface.jar
標準ビュー11g移行ユーティリティを使用して、次に示す11g標準ビューの12c互換バージョンを作成します。
次のコマンドを使用して、ユーティリティを実行します。
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など)。
プロセス固有ビュー11g移行ユーティリティを使用して、次に示す11gプロセス固有ビューの12c互換バージョンを作成します。
次のコマンドを使用して、ユーティリティを実行します。
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(オプション)は、ビューを作成する単一のコンポジットの名前です。
この項は、BAMサーバーがドメイン内に存在する場合にのみ当てはまります。BAMアップグレードの一環として、BAMアーカイブを11gからエクスポートして、それをBAM 12cにインポートできます。このプロセス中にエラーが返された場合は、この項を使用して問題の解決にあたってください。
CFGFWK-60950エラーを受け取った場合は、BAMテンプレートの名前を変更して(「11gスキーマのアップグレード前のOracle BAMテンプレートの名前の変更」を参照)、再構成ウィザードを再度起動します。
このエラーを受け取ったら、アップグレード前の環境全体をリストアし、必要なアップグレード前タスクを実行して、リストされている項の手順を実行する必要があります。その後で、再構成プロセスを再度実行してみてください。
一般的なエラーは、データの変更内容をロール・バックして、オプションを変更したスクリプトを再実行することで解決できることがあります。
すべてのデータ変更内容のロールバック:
使用しているオペレーティング・システムの推奨事項を確認してください。
移行時に予期しないエラーが発生した場合は、問題を修正するために次の手順を実行してみてください。
インポート・フェーズで発生したエラーの場合:
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.*にある移行のログを調べます。
前述したように、すべてのデータ変更内容をロールバックして、次を実行してみてください。
インポート・フェーズで発生したエラーの場合:
次の各項で説明しているとおりに、アーカイブを再インポートします。
タスク5: (Windowsのみ)ディメンション・データ(DimensionExport.zip)をBAMサーバーにインポートします。
タスク6: (Windowsのみ)アクティブ・ファクト・データ(ActiveFactDataExport.zip)をBAMサーバーにインポートします。
タスク7: (Windowsのみ: exportType=ALLの場合)完了ファクト・データ(CompletedFactDataExport.zip)をBAMサーバーにインポートします。
エクスポート・フェーズで発生したエラーの場合:
BPMプロセス・キューブからアーカイブをエクスポートしているときにエラーが発生した場合は、次のタスクを実行します。
