1. SOA SuiteおよびBusiness Process Managementのアップグレード
  2. Oracle Business Activity Monitoringを含むOracle SOA Suiteの11gからのアップグレード

5 Oracle Business Activity Monitoringを含むOracle SOA Suiteの11gからのアップグレード

Business Activity Monitoring (BAM)を含むサポートされているOracle SOA Suite 11g環境から、新しく再設計されたOracle BAM 12cを含むSOA 12c (12.2.1.3.0)環境にアップグレードできます。

ノート:

BAM 12cリリースを含む、以前のOracle SOA Suiteからアップグレードする場合、「Business Activity Monitoringを含むOracle SOA Suiteの以前の12cリリースからのアップグレード」を参照してください

Business Activity Monitoring 12c (12.2.1.3.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 Business Activity Monitoringを含むOracle SOA Suiteの11gからのアップグレード

Oracle BAM 11gを含むSOAのアップグレード・プロセス・フローの理解

次のフローチャートは、Oracle BAMを含むSOA 11gドメインからOracle BAM 12cを含むSOA 12cドメインへのアップグレード・プロセスの概要を示しています。

fupss_upgrade_flowchart_bam.pngの説明が続きます
図fupss_upgrade_flowchart_bam.pngの説明

親トピック: Oracle Business Activity Monitoringを含むOracle SOA Suiteの11gからのアップグレード

Oracle BAMのアップグレード前タスクの実行

この項のタスクは、Oracle BAM 11gを含むSOAドメインを12cにアップグレードするときに実行してください。

  1. アップグレード前の新しいOracle BAM 11gドメインの作成
  2. 既存のドメインからのすべてのOracle BAM 11gアーティファクトのエクスポート
  3. 新しいOracle BAM 11gドメインへのOracle BAM 11gアーティファクトのインポート
  4. Oracle BAM 11gドメインの完全なバックアップの作成

親トピック: Oracle Business Activity Monitoringを含むOracle SOA Suiteの11gからのアップグレード

アップグレード前の新しい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 11gアーティファクトの新しいOracle BAM 11gドメインへのインポート

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 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.3.0)ドメインにアップグレードするには、この手順を使用します。

これらのタスクは、Oracle BAM 11gドメインの完全なバックアップを作成するまで実行しないでください。

  1. Oracle SOA SuiteおよびBusiness Process Managementの12c (12.2.1.3.0)製品ディストリビューションのインストール
    アップグレードを開始する前に、Oracle Universal Installerを使用してOracle Fusion Middleware Infrastrucutreディストリビューション、Oracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.3.0)ディストリビューション、およびその他のSOA Suite製品をターゲット・システムにインストールします。
  2. RCUを使用した必要な12cスキーマの作成
    11gからアップグレードする場合、必要な12cスキーマを作成する必要があります。リポジトリ作成ユーティリティ(RCU)を使用してカスタマイズされたスキーマを作成するか、オプションでUpgrade Assistantを使用してデフォルトのスキーマ設定を使用したスキーマを作成できます。この手順では、RCUを使用してスキーマを作成する方法について説明します。Upgrade Assistantを使用してスキーマを作成する詳細は、アップグレード手順で説明します。
  3. 11gスキーマのアップグレード前のOracle BAMテンプレートの名前の変更
  4. サーバーとプロセスの停止
    Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、すべてのアップグレード前のプロセス、および管理サーバーや管理対象サーバーを含めたすべてのサーバーを停止する必要があります。
  5. アップグレード・アシスタントの実行によるスキーマのアップグレード
  6. 再構成ウィザードを使用した11gドメインの再構成
  7. Upgrade Assistantの実行によるコンポーネント構成のアップグレード

親トピック: Oracle Business Activity Monitoringを含むOracle SOA Suiteの11gからのアップグレード

Oracle SOA SuiteおよびBusiness Process Managementの12c (12.2.1.3.0)製品ディストリビューションのインストール

アップグレードを開始する前に、Oracle Universal Installerを使用してOracle Fusion Middleware Infrastrucutreディストリビューション、Oracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.3.0)ディストリビューション、およびその他のSOA Suite製品をターゲット・システムにインストールします。

ノート:

Infrastructureがアップグレードに必要な場合、他のFusion Middleware製品をインストールする前にOracle Fusion Middlewareディストリビューションを最初にインストールする必要があります。
開始する前に、次の点に注意してください。

  • 以前の12cリリースからアップグレードする場合は、12c (12.2.1.3.0)ディストリビューションを新しいOracleホームにインストールする必要があります。このアップグレードのために既存のOracleホームを再使用しようとしないでください。12c (12.2.1.3.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ディストリビューションsoa_generic.jarの一部です。
Oracle SOA Suiteコンポーネント・ディストリビューションをインストールするには:
  1. ターゲットのシステムにサインインします。
  2. Oracle Technology NetworkまたはOracle Software Delivery Cloudからターゲット・システムに次のディストリビューションをダウンロードします。
    • Fusion Middleware Infrastructureディストリビューション(fmw_12.2.1.3.0_infrastructure_generic.jar)
    • Fusion Middleware SOA SuiteおよびBusiness Process Managementディストリビューション(fmw_12.2.1.3.0_soa_generic.jar)
    • Managed File Transfer、Oracle Service BusまたはOracle B2Bを実行している場合は、Managed File Transferディストリビューション(fmw_12.2.1.3.0_mft_generic.jar)、Oracle Service Bus (fmw_12.2.1.3.0_osb_generic.jar)およびOracle B2B (fmw_12.2.1.3.0_b2b_generic.jar)をダウンロードします。
  3. 12c (12.2.1.3.0)製品ディストリビューションをダウンロードしたディレクトリに移動します。
  4. Oracle Fusion Middleware Infrastructureのインストール・プログラムを起動します。
    • (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.3.0_infrastructure_generic.jar
    • (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.3.0_infrastructure_generic.jar
  5. UNIXオペレーティング・システムでは、このホストにOracle製品を初めてインストールする場合に、「インストール・インベントリの設定」画面が表示されます。
    中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名に対して中央インベントリの場所への書込み権限が付与されていることを確認し、「次へ」をクリックします。

    ノート:

    「インストール・インベントリの設定」画面は、Windowsオペレーティング・システムでは表示されません。
  6. 「ようこそ」画面で、情報をレビューしてすべての前提条件を満たしていることを確認します。「次へ」をクリックします。
  7. 「自動更新」画面で、オプションを選択します。

    • この時点でソフトウェアの更新をシステムで確認しないようにする場合は、「自動更新をスキップ」を選択します。

    • パッチ・ファイルをダウンロードした場合は、「ディレクトリからパッチを選択」を選択して、ローカル・ディレクトリに移動します。

    • My Oracle Supportアカウントを持っている場合にソフトウェアの更新を自動でダウンロードするには、「My Oracle Supportで更新を検索」を選択します。Oracle Supportの資格証明を入力して、「検索」をクリックします。インストーラがMy Oracle Supportにアクセスするようにプロキシ・サーバーを構成するには、「プロキシ設定」をクリックします。「接続のテスト」をクリックして接続をテストします。

    「次へ」をクリックします。
  8. 「インストールの場所」画面でOracleホーム・ディレクトリの場所を指定し、「次へ」をクリックします。
    Oracle Fusion Middlewareディレクトリ構造の詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成のためのディレクトリの理解に関する項を参照してください。
  9. 「インストール・タイプ」画面で、インストールする製品(1つまたは複数)を選択します。製品の依存関係が自動的に選択されます。「次へ」をクリックします。
  10. 「前提条件チェック」画面では、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
    確認されたタスクのリストを表示するには、「正常なタスクの表示」を選択します。ログの詳細を表示するには、「ログの表示」を選択します。前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。エラー・メッセージや警告メッセージを無視してインストールを続けるには、「スキップ」をクリックします(非推奨)。
  11. 「インストール・サマリー」画面で、選択したインストール・オプションを確認します。
    これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルには、入力したすべての情報が収集して格納され、後で(コマンドラインから)サイレント・インストールを実行するために使用できます。

    「インストール」をクリックしてインストールを開始します。

  12. 「インストールの進行状況」画面で、進行状況バーに100%と表示されたら、「終了」をクリックしてインストーラを終了するか、「次へ」をクリックしてサマリーを表示します。
  13. 「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。情報を確認し、「終了」をクリックしてインストーラを閉じます。
  14. Infrastructureをインストールしたら、ステップ3から13までを繰り返してその他の製品ディストリビューションをインストールします。

親トピック: Oracle BAMドメインを含むSOAの12cへのアップグレード

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.3.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がドメインの一部になっている場合にのみ必要です。

RCUを使用して12cスキーマを作成するには:
  1. (オプション) 11gからアップグレードする場合に、既存のドメインに存在するスキーマを確認するには、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 ;
  2. コマンドラインからjava -versionを実行して、動作保証されたJDKがすでにシステムにあることを確認します。12c (12.2.1.3.0)では、動作保証されたJDKは1.8.0_131以降です。
    JAVA_HOME環境変数が、動作保証済JDKの場所に設定されていることを確認します。たとえば:
    • (UNIX) setenv JAVA_HOME=/home/Oracle/Java/jdk1.8.0_131
    • (Windows) set JAVA_HOME=C:\home\Oracle\Java\jdk1.8.0_131
    Add $JAVA_HOME/bin to $PATH.
  3. oracle_common/binディレクトリに移動します。
    • (UNIX) NEW_ORACLE_HOME/oracle_common/bin
    • (Windows) NEW_ORACLE_HOME\oracle_common\bin
  4. RCUを起動します。
    • (UNIX) ./rcu
    • (Windows) rcu.bat
  5. 「ようこそ」画面で「次へ」をクリックします。
  6. 「リポジトリの作成」画面で「リポジトリの作成」を選択し、「システム・ロードおよび製品ロード」を選択します。
    DBA権限を持っていない場合は、「システム・ロードに対するスクリプトの準備」を選択します。これによって、選択したコンポーネントに対してRCUでアクションが実行された場合にコールされるのと同じSQL文およびブロックをすべて含むSQLスクリプトが生成されます。このスクリプトが生成された後は、必要なSYSまたはSYSDBA権限を持つユーザーが、このスクリプトを実行してシステム・ロード・フェーズを完了できます。

    「次へ」をクリックします。

  7. 「データベース接続の詳細」画面で、「データベース・タイプ」を選択し、11gスキーマをホストするデータベースの接続情報を入力します。次の該当する表を参照してください。

    表5-1 Oracle Databaseと、エディションベースで再定義されるOracle Databaseに対する接続資格証明

    オプション 説明と例
    ホスト名

    データベースが実行されるサーバーの名前を、次の書式で指定します。

    examplehost.exampledomain.com

    Oracle RACデータベースの場合は、このフィールドにVIP名またはいずれかのノード名を指定します。
    ポート

    データベースのポート番号を指定します。Oracleデータベースのデフォルトのポート番号は、1521です。

    サービス名

    データベースのサービス名を指定します。通常、サービス名はグローバル・データベース名と同じです。

    Oracle RACデータベースの場合、このフィールドにいずれかのノードのサービス名を指定します。たとえば:

    examplehost.exampledomain.com
    ユーザー名 データベースのユーザー名を入力します。デフォルトのユーザー名はSYSです。
    パスワード データベース・ユーザーのパスワードを入力します。
    ロール

    ドロップダウン・リストからデータベース・ユーザーのロールを選択します。

    「標準」または「SYSDBA」

    表5-2 MySQLデータベースに対する接続資格証明

    オプション 説明と例
    ホスト名

    データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。

    ポート

    データベースのポート番号を指定します。
    データベース名

    データベースの名前を指定します。
    ユーザー名 管理者権限を持つユーザーの名前を指定します。
    パスワード データベース・ユーザーのパスワードを入力します。

    表5-3 Microsoft SQL Serverデータベースに対する接続資格証明

    オプション 説明と例
    Unicodeのサポート

    ドロップダウン・リストから「はい」または「いいえ」を選択します。

    サーバー名 データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。

    MSSQL名前付きインスタンス: 名前付きインスタンスは、コンピュータのネットワーク名およびインストール時に指定したインスタンス名によって識別されます。クライアントは、接続時に、サーバー名とインスタンス名を両方とも指定する必要があります。
    ポート

    データベースのポート番号を指定します。
    データベース名

    データベースの名前を指定します。
    ユーザー名 管理者権限を持つユーザーの名前を指定します。
    パスワード データベース・ユーザーのパスワードを入力します。

    表5-4 IBM DB2データベースに対する接続資格証明

    オプション 説明と例
    サーバー名 データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。
    ポート

    データベースのポート番号を指定します。
    データベース名

    データベースの名前を指定します。
    ユーザー名 DB所有者の権限が付与されているユーザーの名前を指定します。IBM DB2データベースのデフォルトのユーザー名はdb2adminです。
    パスワード データベース・ユーザーのパスワードを入力します。
    前提条件のチェックが成功した場合は、「OK」をクリックして次の画面に進みます。チェックが失敗した場合は、入力した詳細を確認して再試行します。
  8. 「コンポーネントの選択」画面で、「既存の接頭辞の選択」を選択し、ドロップダウン・メニューから既存の11gスキーマの作成に使用した接頭辞(たとえば、DEV11G)を選択します。この接頭辞は、スキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。

    Oracle BAMに必要なスキーマを選択します。

    ノート:

    デフォルトで、Common Infrastructure Services (prefix_STB)およびOracle Platform Security Services (prefix_OPSS)スキーマが選択されます(まだそれらが作成されていない場合)。

    インストールするコンポーネントの接頭辞とスキーマ名をノートにとります。インストールの構成時にこの情報が必要になります。「次へ」をクリックします。
  9. 「前提条件チェック」ダイアログで、前提条件チェックが正常であることを確認し、「OK」をクリックします。
  10. 「スキーマ・パスワード」画面で、スキーマの所有者のパスワードを入力します。
    この画面で入力したパスワードをノートにとってください。製品インストールの構成中に必要となります。
  11. 「表領域のマップ」画面で、作成するスキーマに必要な表領域マッピングを構成します。
    「次へ」をクリックし、確認ダイアログで「OK」をクリックします。進行状況ダイアログに表領域の作成が完了したことが示されたら、「OK」をクリックします。
    RCUの起動時に、Transparent Data Encryption (TDE)がデータベース(OracleまたはOracle EBR)内で有効化されている場合にのみ、「表領域の暗号化」チェック・ボックスが表示されます。RCUにより作成されるすべての新しい表領域を暗号化するには、「表領域のマップ」画面で「表領域の暗号化」チェック・ボックスを選択します。
  12. 「サマリー」画面で情報を確認し、「作成」をクリックしてスキーマの作成を開始します。
    この画面には、このRCU操作で作成されたログ・ファイルに関する情報が表示されます。特定のログ・ファイルの名前をクリックして、そのファイルの内容を表示します。
  13. 「完了サマリー」画面の情報を確認し、操作が正常に完了したことを確かめます。「閉じる」をクリックして、スキーマの作成を完了します。

親トピック: Oracle BAMドメインを含むSOAの12cへのアップグレード

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

親トピック: Oracle BAMドメインを含むSOAの12cへのアップグレード

サーバーとプロセスの停止

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

プロンプトが表示されたらユーザー名とパスワードを入力します。

ステップ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ドメインを含むSOAの12cへのアップグレード

アップグレード・アシスタントの実行によるスキーマのアップグレード

アップグレード・アシスタントを使用したスキーマのアップグレードの、標準の手順に従います。

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の現在のリリースにアップグレードします。

親トピック: Oracle BAMドメインを含むSOAの12cへのアップグレード

製品スキーマのアップグレード

サーバーおよびプロセスの停止後、Upgrade Assistantを使用して、サポートされている製品スキーマを現在のリリースのOracle Fusion Middlewareにアップグレードします。

アップグレード・アシスタントを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるアップグレード・アシスタントの画面は異なります。

  • Upgrade Assistantの起動
    Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。
  • Upgrade Assistantの使用によるSOAスキーマのアップグレード
    Upgrade Assistantの各画面を通じて、製品スキーマをアップグレードします。
  • スキーマのアップグレードの確認
    すべてのアップグレード・ステップを完了したら、schema_version_registryのスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードの成功を検証します。

親トピック: アップグレード・アシスタントの実行によるスキーマのアップグレード

アップグレード・アシスタントの起動

Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

ノート:

Upgrade Assistantを起動する前に、Upgrade Assistantを実行しているプラットフォームにJVM文字エンコーディングがUTF-8に設定されていることを確認してください。文字エンコーディングがUTF-8に設定されていない場合、名前にUnicode文字を含むファイルをダウンロードできません。アップグレードが失敗することがあります。

  1. oracle_common/upgrade/binディレクトリに移動します。
    • (UNIX) NEW_ORACLE_HOME/oracle_common/upgrade/bin
    • (Windows) NEW_ORACLE_HOME\oracle_common\upgrade\bin
  2. Upgrade Assistantを起動します。
    • (UNIX) ./ua
    • (Windows) ua.bat

ロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。

アップグレード・アシスタントのパラメータ

アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。

表5-5 Upgrade Assistantコマンドライン・パラメータ

パラメータ 必須またはオプション 説明

-readiness

 準備状況チェックに必要

ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必要

GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel attribute

オプション

次のいずれかの属性を指定して、ロギング・レベルを設定します。

  • TRACE

  • NOTIFICATION

  • WARNING

  • ERROR

  • INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

より多くの情報がログ記録されるよう、-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir location

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

(UNIX)

NEW_ORACLE_HOME/oracle_common/upgrade/logs
NEW_ORACLE_HOME/oracle_common/upgrade/temp

(Windows)

NEW_ORACLE_HOME/oracle_common/upgrade/logs
NEW_ORACLE_HOME/oracle_common/upgrade/temp

-help

オプション

すべてのコマンドライン・オプションを表示します。

親トピック: Upgrade Assistantの起動

アップグレード・アシスタントを使用したSOAスキーマのアップグレード

Upgrade Assistantの各画面を通じて、製品スキーマをアップグレードします。

注意:

パージ・スクリプトまたはスケジュールされたデータベース・ジョブの実行中は、アップグレード・アシスタントを起動しないでください。

パージまたはアップグレードが完了するまで待ってから、アップグレード・プロセスを開始してください。アップグレード・アシスタントを使用してスキーマをアップグレードするときに、パージ・スクリプトまたはインスタンスのアップグレード・ジョブを実行していると、アップグレードは失敗します。

アップグレード・アシスタントを起動する必要がある場合は、「バックグラウンド制御ジョブの有効化と無効化(オプション6)」で説明しているように、パージを停止してスケジュールされたジョブを無効にしてください。

Upgrade Assistantを使用して、製品スキーマをアップグレードするには:
  1. 「ようこそ」画面で、Upgrade Assistantの概要、および重要なアップグレード前作業に関する情報を確認します。「次へ」をクリックします。

    ノート:

    Upgrade Assistantの画面の詳細は、その画面上のヘルプをクリックしてください。
  2. 「選択したスキーマ」画面で、実行するスキーマ・アップグレード操作を選択します。
    • 「ドメインで使用されるすべてのスキーマ」を使用すると、Upgrade Assistantは、ドメイン内でアップグレードに対応可能な「ドメイン・ディレクトリ」フィールドで指定されたスキーマを持つコンポーネントをすべて検出して選択します。これは、ドメイン支援のスキーマ・アップグレードとも呼ばれています。さらに、Upgrade Assistantはスキーマの入力画面に接続情報を事前に移入します。

      ノート:

      すべての必要なスキーマがアップグレードに含まれていることを確認するためにほとんどのアップグレードに「ドメインで使用されるすべてのスキーマ」を選択することをお薦めします。
    • 「個別に選択されたスキーマ」: ドメインで使用されるスキーマをすべてアップグレードするのではなく、アップグレードするスキーマを個別に選択する場合のオプションです。

      注意:

      12c (12.2.1.3.0)コンポーネントをサポートするために使用されるスキーマのみをアップグレードしてください。Oracle Fusion Middleware 12c (12.2.1.3.0)に含まれないコンポーネントをサポートするために現在使用されているスキーマは、アップグレードしないでください。

    「次へ」をクリックします。

  3. 「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、スキーマをアップグレードするコンポーネントを選択します。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。
  4. 「使用可能なコンポーネント」画面でOracle Platform Security ServicesまたはOracle Audit Servicesが選択されている場合は、「ドメイン・ディレクトリ」画面が表示されます。既存のWebLogicドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックして、アップグレードするドメイン・ディレクトリに移動して選択します
  5. 「前提条件」画面で、すべてのチェック・ボックスを選択することで、前提条件を満たしていることを認めます。「次へ」をクリックします。

    ノート:

    アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。
  6. スキーマ資格証明の画面で、アップグレードするスキーマごとにデータベース接続の詳細を指定します(この画面名は、選択したスキーマに応じて変化します)。
    要素 説明

    データベース・タイプ

    アップグレード用に選択されたデータベース・タイプは、RCUが最初にスキーマを作成したときに選択されたデータベース・タイプと同一である必要があります。

    データベース・タイプとしてOracle Edition-Based Redefinition (EBR)を選択した場合は、アップグレードしているスキーマも、EBRデータベース・タイプとしてRCUによって作成されている必要があります。特に、アップグレード・アシスタントでは、スキーマのデータベース・タイプが別のタイプに変換されることはありません。

    オプションは、次のとおりです。

    • Oracle Database

    • Microsoft SQL Server

    • IDM DB2

    • MySQL

    • Java DB

    • エディション・ベースの再定義に対応したOracle Database

    エディション名

    データベース・タイプ「エディション・ベースの再定義に対応したOracle Database」(EBRデータベース)の場合、「エディション名」要素フィールドに既存のエディションの名前を入力する必要があります。データベース・スキーマのアップグレードは、選択したエディションで行われます。

    データベース接続文字列

    データベースの場所を入力します。

    たとえば、Oracle Databaseを選択する場合は、次のURL形式を使用できます。

    host:port/db_service_name

    Microsoft SQL ServerまたはIBM DB2データベースを使用している場合は、ドロップダウン・メニューからデータベース・タイプを選択し、各データベース・タイプに対して使用できる構文の例を確認してください。

    DBAユーザー名

    データベースへの接続に使用するデータベース・ユーザー名を入力します。

    Oracle Databaseユーザーのみ: SSL認証が使用されている場合、「DBAユーザー名」フィールドはオプションになることがあります。DBAユーザー名を指定すると、その情報がデータベース認証中に使用されます。

    Oracle Databaseユーザーで、SYSまたはSYSDBAとして操作を実行していない場合、アップグレード・アシスタントのユーザーはFMWユーザー・アカウントで付与されるすべての権限を持っている必要があります。

    sysdba以外のユーザーを作成してアップグレード・アシスタントを実行する方法の詳細は、コンポーネント固有のアップグレード・ドキュメントを参照してください。

    DBAパスワード

    指定したDBAデータベース・ユーザーに対応するパスワードを入力します。

    Oracle Databaseユーザーのみ: SSL認証が使用されている場合、「DBAパスワード」フィールドはオプションになることがあります。DBAユーザー名およびパスワードを指定すると、その情報がデータベース認証中に使用されます。

    スキーマ・ユーザー名

    「スキーマ・ユーザー名」ドロップダウン・メニューからアップグレードするスキーマを選択し、スキーマのパスワードを入力します。アップグレードするスキーマに対して正しいスキーマ接頭辞を使用してください。

    前の12cリリースからのアップグレード:

    リリース12.1.2.0.0以降、UCSUMSスキーマのスキーマ名は変更されました。新しい名前は、アップグレードの開始点に応じて、prefix_ORASDPMまたはprefix_UMSのどちらかとなります。Upgrade Assistantが自動的に使用可能なスキーマを認識せず、ドロップダウン・リストに表示できない場合、テキスト・フィールドに名前を手動で入力する必要があります。

    11gから12cへのアップグレードのみ: UCSUMSスキーマは、自動移入されません。ユーザーとしてprefix_ORASDPMを入力します。アップグレード環境ではスキーマ名としてprefix_ORASDPMが使用されますが、12c環境ではこれは_UMSと見なされます。

    スキーマ・パスワード

    特定のスキーマ・ユーザー名に関連付けられているパスワードを入力します。
  7. 「スキーマの作成」画面で、Upgrade Assistantが欠落スキーマを作成するかどうかを指定します。デフォルトでは、指定されたドメインの欠落スキーマの作成オプションが有効です。アップグレード・アシスタントは、指定されたデータベース接続詳細とスキーマ所有者名を使用して、ドメインの欠落スキーマの作成を試行します。Upgrade Assistantは、デフォルトの表領域設定を使用してスキーマを作成します。
    同じパスワードをすべてのスキーマに使用する場合、「すべてのスキーマに同じパスワードを使用」を選択します。表のパスワードを入力して確認します。パスワードを指定する必要があるのは1回のみです。

    ノート:

    スキーマにカスタマイズされたオプションが必要な場合、Upgrade Assistantによるスキーマの作成を許可しないでください。デフォルトのリポジトリ作成ユーティリティ(RCU)設定を使用して、スキーマが作成されます。たとえば、スキーマに追加の表領域が必要な場合、RCUを使用してスキーマを作成する必要があります。

    Upgrade Assistantでこれらのスキーマを作成しない場合、指定されたドメインの欠落スキーマの作成オプションを選択解除し、「次」をクリックします。リポジトリ作成ユーティリティを使用してスキーマを作成する必要があります。

  8. 指定されたドメインの欠落スキーマの作成オプションを選択した場合、スキーマのデフォルト値の作成画面が表示されます。各コンポーネント・スキーマと補助スキーマのデフォルトのデータファイル・サイズがリストされます。表領域データファイルのサイズを変更するか、デフォルトのスキーマ設定にその他の変更を加える必要がある場合は、リポジトリ作成ユーティリティを使用してスキーマを作成します。アップグレード・アシスタントから表領域設定を変更することはできません。
  9. 「調査」画面で、各スキーマを調査したUpgrade Assistantのステータスを確認して、スキーマのアップグレードの準備が整っていることを検証します。ステータスが「調査が終了しました。」の場合は、「次」をクリックします。
    調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、共通するアップグレード・エラーの解決に関する情報を『Oracle Fusion Middleware Upgrade Assistantによるアップグレード』のアップグレードのトラブルシューティングに関する項で参照します。

    ノート:

    • 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、Upgrade Assistantを再度開始する前に、バックアップからアップグレード前の環境をリストアする必要があります。

    • 調査プロセスを取り消してもスキーマまたは構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。

  10. 「アップグレード・サマリー」画面で、アップグレードまたは作成、あるいはその両方が行われるスキーマのサマリーを確認します。
    アップグレード対象の各スキーマについて、正しいソース・バージョンとターゲット・バージョンがリストされていることを確認します。
    これらのオプションをレスポンス・ファイルに保存して、後で再度レスポンス(またはサイレント)モードでUpgrade Assistantを実行する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を提供します。サイレント・アップグレードでは、Upgrade Assistantとまったく同じ機能が実行されますが、データを手動で再入力する必要はありません。
    「次」をクリックします
  11. 「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

    注意:

    アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。
    正しくアップグレードされていないスキーマがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

    ノート:

    この画面上の進行状況バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

    「次へ」をクリックします。

  12. アップグレードが正常に終了した場合: 「アップグレード成功」画面で、「閉じる」をクリックしてアップグレードを完了しウィザードを閉じます。

    アップグレードが失敗した場合: 「アップグレード失敗」画面で、「ログの表示」をクリックしてエラーを表示し、トラブルシューティングします。ログはNEW_ORACLE_HOME/oracle_common/upgrade/logsにあります。

    ノート:

    アップグレードが失敗した場合は、バックアップからアップグレード前の環境をリストアし、問題を修正してから、Upgrade Assistantを再起動する必要があります。
スキーマのアップグレードの確認

すべてのアップグレード・ステップが完了したら、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.3.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サーバーおよびクラスタの削除」を参照)。

親トピック: Oracle BAMドメインを含むSOAの12cへのアップグレード

ドメインの再構成について

再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.3.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バージョンと互換性を持つために必要な再構成タスクを定義します。

  • 起動スクリプトが更新されます。

    変更した起動スクリプトを保持する必要がある場合は、再構成ウィザードを開始する前にそれらをバックアップするようにしてください。

ノート:

ドメインの再構成プロセスを開始すると、行う変更を元に戻すことはできません。再構成ウィザードを実行する前に、アップグレード前チェックリストに示されているようにドメインをバックアップしてあることを確認してください。再構成ウィザードの実行中にエラーまたは他の割込みが発生した場合、バックアップ場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーすることによって、ドメインをリストアする必要があります。これは、ドメインが再構成前の元の状態に戻されたことを確認する唯一の方法です。

再構成ウィザードを使用して既存のドメインを変更するには、次の説明に従ってください。Oracle WebLogic ServerのアップグレードのWebLogicドメインの再構成を参照してください。

親トピック: 再構成ウィザードを使用した11gドメインの再構成

ドメインのバックアップ

再構成ウィザードを実行する前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。

ドメイン・ディレクトリのバックアップを作成するには:

  1. コンテンツを保持するには、ソース・ドメインを別の場所にコピーします。
    (Windows) copy C:\domains\mydomain to C:\domains\mydomain_backup。
    (UNIX) cp mydomain /domains/mydomain_backup
  2. 各リモート管理対象サーバー上でドメインを更新する前に、各リモート・マシン上のドメイン・ディレクトリのバックアップ・コピーを作成します。
  3. ドメインのバックアップしたバージョンが完全であることを確認します。
ドメインの再構成がなんらかの理由で失敗した場合は、すべてのファイルおよびディレクトリをバックアップ・ディレクトリから元のドメイン・ディレクトリにコピーして、ドメインを再構成前の元の状態に完全に戻す必要があります。
再構成ウィザードの起動

ノート:

再構成プロセスを開始する前に管理サーバーおよびすべてのコロケートされた管理対象サーバーを停止します。「サーバーとプロセスの停止」を参照

再構成ウィザードをグラフィカル・モードで起動するには:

  1. ドメインが存在するシステムにサインインします。
  2. コマンド・シェル(UNIXオペレーティング・システムの場合)またはコマンド・プロンプト・ウィンドウ(Windowsオペレーティング・システムの場合)を開きます。
  3. エディション・ベースのデータベース・ユーザーのみ: スキーマがEBRデータベースを使用して構成されている場合、再構成ウィザードを実行する前に、手動でデフォルトのエディション名を設定する必要があります。
    次のSQLコマンドを実行して、デフォルト・エディションを設定します。

    ALTER DATABASE DEFAULT EDITION = edition_name;

    ここでのedition_nameは子エディション名です。

  4. oracle_common/common/binディレクトリに移動します。
    • (UNIX) NEW_ORACLE_HOME/oracle_common/common/bin
    • (Windows) NEW_ORACLE_HOME\oracle_common\commom\bin
  5. 再構成ウィザードを次のロギング・オプションを指定して起動します。
    • (UNIX) ./reconfig.sh -log=log_file -log_priority=ALL
    • (Windows) reconfig.cmd -log=log_file -log_priority=ALL

    log_fileは、ドメイン再構成セッション用に作成するログ・ファイルの絶対パスです。これは、再構成処理をトラブルシューティングする必要がある場合に役立つことがあります。

    パラメータ-log_priority=ALLを指定すると、ログが詳細モードで記録されます。

    ノート:

    このコマンドを実行すると、デフォルトのキャッシュ・ディレクトリが無効であることを示す次のエラー・メッセージが表示される場合があります。

    *sys-package-mgr*: can't create package cache dir

    環境変数CONFIG_JVM_ARGSを設定することでキャッシュ・ディレクトリを変更できます。たとえば:

    CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

再構成ウィザードを使用したSOAドメインの再構成

Upgrade Assistantを実行する前に、再構成ウィザードを使用して、まず既存のドメインを再構成する必要があります。

ノート:

ソースがクラスタ環境である場合は、再構成ウィザードをプライマリ・ノードでのみ実行します。圧縮/解凍ユーティリティを使用して、ドメイン内の他のクラスタ・メンバーに変更を適用します。
ドメインを再構成するには:
  1. 「ドメインの選択」画面で、アップグレードするドメインの場所を指定するか、「参照」をクリックしてナビゲートし、ドメインのディレクトリを選択します。「次へ」をクリックします。
  2. 「再構成セットアップの進行状況」画面で、設定プロセスの進行状況を確認します。完了したら、「次へ」をクリックします。
    このプロセスでは次の処理が行われます。

    • Fusion Middleware製品を含む、インストール済製品の再構成テンプレートが自動的に適用されます。これにより、config.xml、config-groups.xml、security.xmlなどの様々なドメイン構成ファイルが更新されます。

    • Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

    • ドメイン・アップグレードが検証されます。

  3. 「ドメイン・モードおよびJDK」画面で、ドメインで使用するJDKを選択するか、「参照」をクリックして、使用するJDKにナビゲートします。12c (12.2.1.3.0)でサポートされているJDKバージョンは、1.8.0_131以降です。「次へ」をクリックします。

    ノート:

    このステージでは、「ドメイン・モード」を変更することはできません。
    特定のプラットフォームでサポートされているJDKのリストは、Oracle Fusion Middlewareでサポートされているシステム構成の説明を参照してください。
  4. 「データベース構成タイプ」画面で、「RCUデータ」を選択してServer Table (_STB)スキーマに接続します。
    RCUサービス表(_STB)スキーマ資格証明を使用してデータベース接続の詳細を入力し、「RCU構成の取得」をクリックします。
    再構成ウィザードは、この接続を使用して、ドメインのコンポーネントに必要なデータソースを自動的に構成します。

    ノート:

    デフォルトでは、Oracleのサービス接続用ドライバ(Thin)、バージョン: 任意が選択されたドライバです。サービス名のかわりに接続詳細のインスタンス名を指定した場合、Oracleのサービス接続用ドライバ(Thin)、バージョン: 任意を選択する必要があります。ドライバ・タイプを変更しないと、接続は失敗します。

    ノート:

    既存の11gデータ・ソースの場合、再構成では既存の値が保持されます。スキーマがRCUで12c用に作成されている新しいデータ・ソースの場合、デフォルトの接続データは_STBスキーマから取得されます。特定のスキーマの接続データが_STBスキーマにない場合は、デフォルトの接続データが使用されます。
    チェックが成功した場合は、「次へ」をクリックします。チェックが失敗した場合は、接続の正しい詳細を再入力し、再試行します。

    ノート:

    11gからアップグレードし、データベースに_OPSSまたは_IAU 11gデータベース・スキーマが含まれる場合、それらのスキーマに手動でデータベース接続詳細を入力する必要があります。これらのスキーマは11gで不要であり、手動で作成する必要がありました。ユーザーは任意の名前をこれらのスキーマに割り当てることができるため、再構成ウィザードでは認識されません。_IAUの接続情報を指定する場合、IAU_APPENDユーザー情報を使用します。
  5. 「JDBCコンポーネント・スキーマ」画面で、各コンポーネント・スキーマのDBMS/サービスおよびホスト名が正しいことを確認し、「次へ」をクリックします。
  6. 「JDBCコンポーネント・スキーマ・テスト」画面で、すべてのコンポーネント・スキーマを選択して「選択された接続のテスト」をクリックし、各スキーマの接続をテストします。テストの結果は、「ステータス」列に表示されます。
    チェックが完了したら、「次へ」をクリックします。
  7. 「拡張構成」画面で、拡張構成を実行するすべてのカテゴリを選択できます。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。

    ノート:

    「拡張構成」画面に表示されるオプション・カテゴリは、ドメインのために選択したテンプレートで定義されているリソースによって異なります。一般的な一部のカテゴリを次に示します。
    「拡張構成」>「管理対象サーバー」:

    ドメインの各管理対象サーバーに対し、リスニング・アドレスの実際のホスト名を指定する必要があります。

    デフォルトのlocalhostまたは All Local Addressesオプションは使用しないでください。

    実際のホスト名を、hostname.yourcompany.comのように指定する必要があります

    「管理対象サーバー」>サーバー・グループのターゲット指定

    ノート:

    • 11gから12cリリースにアップグレードする場合は、OSB管理対象サーバーをターゲット指定するために次のサーバー・グループを選択してください。
      • OSB-MGD-SVRS-ONLY – Oracle Service BusサービスとOracle Web Services Manager (OWSM)サービスを別々の管理対象サーバーにターゲット指定する場合は、このサーバー・グループを選択します。
      • OSB-MGD-SVRS - OSBサービスとOWSMサービスを同じ管理対象サーバーにターゲット指定する場合は、このサーバー・グループを選択します。このオプションは、CloudSDKをOSB管理対象サーバーにターゲット指定しません。必要に応じて、CloudSDKを手動でターゲット指定したり、さらにOSB-MGD-SVRS-COMBINEDサーバー・グループを選択したり、OSB管理対象サーバーをターゲット指定することもできます。
    • 以前の12cリリース(たとえば12.1.3)で作成されたドメインをアップグレードする場合、アップグレードのドメイン再構成フェーズで、サーバーを正しいサーバー・グループにターゲット指定する必要があります。これらのサーバーのターゲット指定に失敗すると、アップグレードの失敗や不要なダウンタイムの発生につながることがあります。

    1. 「管理対象サーバー」画面で「サーバー・グループ」ドロップダウン・メニューから正しいグループ名を選択して、各サーバーを正しいサーバー・グループにターゲット指定します。
      recon_managed.pngの説明が続きます
      図recon_managed.pngの説明

    2. 各サーバーが正しいサーバー・グループにターゲット指定され、「未指定」と表示されていないことを確認します。
      コンポーネントとサーバー サーバー・グループ
      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クラスタの一部ではない場合:

    • SOA-MGD-SVRS-ONLYユーザー拡張可能サーバー・グループのみをSOAクラスタのターゲットに指定します
    • OSB-MGD-SVRS-ONLYのみをOSBクラスタのターゲットに指定します
    • WSMPM-MAN-SVERサーバー・グループをOWSMのターゲットに指定します
    • 12.1.3.0を12.2.1.3.0,にアップグレードする場合、BAM-MGD-SVRS-ONLYをBAMクラスタのターゲットに指定する必要もあります。
  8. 「構成のサマリー」画面で、ドメインの詳細な構成設定を確認してから続行します。
    「表示」ドロップダウン・リストからフィルタ・オプションを選択すると、右側のパネルに表示される項目を制限できます。
    構成を変更するには、「戻る」をクリックして適切な画面に戻ります。ドメインを再構成するには、「再構成」をクリックします。

    ノート:

    ドメインを再構成しても、その場所は変更されません。
  9. 「再構成の進行状況」画面には、再構成プロセスの進行状況が表示されます。
    このプロセスでは次の処理が行われます。

    • ドメイン情報が抽出、保存および更新されます。

    • Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

    進捗バーが100%になったら、「次へ」をクリックします。
  10. 「構成の終了」画面には、再構成プロセスが正常に完了したか失敗したかが示されます。管理サーバーURL(リスニング・ポートを含む)とともに再構成されたドメインの場所も表示します。再構成が成功した場合は、Oracle Weblogic Serverの再構成に成功しましたと表示されます。
    再構成プロセスが正常に完了しなかった場合は、その理由を示すエラー・メッセージが表示されます。問題を解決するための適切な措置を講じます。問題を解決できない場合は、My Oracle Supportに連絡してください。
    以後の操作のためにドメインの場所と管理サーバーURLをノートにとります。

Upgrade Assistantの実行によるコンポーネント構成のアップグレード

ドメインの再構成が終了したら、アップグレード・アシスタントを再実行して、残りのコンポーネントの構成をアップグレードします。

親トピック: Oracle BAMドメインを含むSOAの12cへのアップグレード

ドメイン・コンポーネント構成のアップグレード

ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。

  • Upgrade Assistantの起動
    Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。
  • Upgrade Assistantを使用したドメイン・コンポーネントのアップグレード
    Upgrade Assistantの各画面を通じて、WebLogicドメインのコンポーネント構成をアップグレードします。

親トピック: Upgrade Assistantの実行によるコンポーネント構成のアップグレード

アップグレード・アシスタントの起動

Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成またはスタンドアロン・システム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。Upgrade AssistantをSYSDBA以外のユーザーとして実行し、一度に1つのドメインのアップグレードを完了することをお薦めします。

Upgrade Assistantを起動するには、次の手順に従います。

ノート:

Upgrade Assistantを起動する前に、Upgrade Assistantを実行しているプラットフォームにJVM文字エンコーディングがUTF-8に設定されていることを確認してください。文字エンコーディングがUTF-8に設定されていない場合、名前にUnicode文字を含むファイルをダウンロードできません。アップグレードが失敗することがあります。

  1. oracle_common/upgrade/binディレクトリに移動します。
    • (UNIX) NEW_ORACLE_HOME/oracle_common/upgrade/bin
    • (Windows) NEW_ORACLE_HOME\oracle_common\upgrade\bin
  2. Upgrade Assistantを起動します。
    • (UNIX) ./ua
    • (Windows) ua.bat

ロギング・パラメータなど、コマンド・ラインで指定できるその他のパラメータの詳細は、次を参照してください。

アップグレード・アシスタントのパラメータ

アップグレード・アシスタントをコマンド・ラインから起動する際に、追加パラメータを指定できます。

表5-6 アップグレード・アシスタントのコマンドライン・パラメータ

パラメータ 必須またはオプション 説明

-readiness

 準備状況チェックに必要

ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。

実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。

スキーマおよび構成がチェックされます。

-examineパラメータを指定した場合は、このパラメータを使用しないでください。

-threads

オプション

スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。

値は、1 - 8の正の整数である必要があります。デフォルトは4です。

-response

サイレント・アップグレードまたはサイレント準備状況チェックに必要

GUIモードでのUpgrade Assistantの実行時に入力されたデータから生成されたレスポンス・ファイルに保存されている入力を使用して、Upgrade Assistantを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。

-examine

オプション

調査フェーズを実行しますが、実際のアップグレードは実行しません。

-readinessパラメータを指定した場合、このパラメータを指定しないでください。

-logLevel attribute

オプション

次のいずれかの属性を指定して、ロギング・レベルを設定します。

  • TRACE

  • NOTIFICATION

  • WARNING

  • ERROR

  • INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

より多くの情報がログ記録されるよう、-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。

-logDir location

オプション

アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。

デフォルトの場所は次のとおりです。

(UNIX)

NEW_ORACLE_HOME/oracle_common/upgrade/logs
NEW_ORACLE_HOME/oracle_common/upgrade/temp

(Windows)

NEW_ORACLE_HOME/oracle_common/upgrade/logs
NEW_ORACLE_HOME/oracle_common/upgrade/temp

-help

オプション

すべてのコマンドライン・オプションを表示します。

親トピック: Upgrade Assistantの起動

Upgrade Assistantの使用によるドメイン・コンポーネントのアップグレード

Upgrade Assistantで複数の画面をナビゲートし、WebLogicドメイン内のコンポーネント構成をアップグレードします。

再構成ウィザードを実行してWebLogicドメインを12c (12.2.1.3.0)に再構成した後、Upgrade Assistantを実行して、更新したドメイン構成と一致するようドメイン・コンポーネント構成をアップグレードします。

Upgrade Assistantでドメイン・コンポーネント構成をアップグレードするには:
  1. 「ようこそ」画面で、Upgrade Assistantの概要、および重要なアップグレード前作業に関する情報を確認します。「次へ」をクリックします。

    ノート:

    Upgrade Assistantの画面の詳細は、その画面上のヘルプをクリックしてください。
  2. 次の画面で、次のことを実行します。

    • 「ドメインによって使用されるすべての構成」を選択します。画面名が「WebLogicコンポーネント」に変わります。

    • 「ドメイン・ディレクトリ」フィールドで、WebLogicドメイン・ディレクトリのパスを入力します。

    「次へ」をクリックします。

  3. アップグレード前の環境に複数のWebLogicドメインがあるが、Oracle Web Services Manager (OWSM)ポリシー・マネージャが1つのドメインのみにあり、OWSMエージェントが他のドメインにある場合: OWSMポリシー・マネージャ画面で、Oracle Web Services Manager (OWSM)ポリシー・マネージャがデプロイされているWebLogic管理サーバー・ドメインの資格証明を提供します。
  4. 「コンポーネント・リスト」画面で、構成をアップグレードするすべてのコンポーネントを含んだリストを確認し、「次」をクリックします。
    アップグレード対象のコンポーネントが表示されていない場合は、「戻る」をクリックして前の画面に戻り、別のドメインを指定します。
  5. 「前提条件」画面で、すべてのチェック・ボックスを選択することで、前提条件を満たしていることを認めます。「次へ」をクリックします。

    ノート:

    アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。
  6. ユーザー・メッセージング・サービス(UMS)構成ファイルをホストするリモート管理対象サーバーがある場合: UMS構成画面で、Upgrade Assistantが構成ファイルにアクセスできるよう、これらのサーバーへの資格証明を提供します。

    ノート:

    Upgrade AssistantでUMS構成ファイルが見つからない場合は、それらのファイルを手動でコピーする必要があります。ユーザー・メッセージング・サービス(UMS)構成ファイルのコピー中のエラーを参照してください。
  7. Upgrade Assistantで各コンポーネントを調査したら、「調査」画面で、Upgrade Assistantのステータスを確認し、コンポーネント構成のアップグレード準備が整っていることを確かめます。ステータスが「調査が終了しました。」の場合は、「次」をクリックします。
    調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、共通するアップグレード・エラーの解決に関する情報を『Oracle Fusion Middleware Upgrade Assistantによるアップグレード』のアップグレードのトラブルシューティングに関する項で参照します。

    ノート:

    • 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、Upgrade Assistantを再度開始する前に、バックアップからアップグレード前の環境をリストアする必要があります。

    • 調査プロセスを取り消しても構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。

  8. 「アップグレード・サマリー」画面で、コンポーネント構成のアップグレードのために選択したオプションについて、概要を確認します。
    レスポンス・ファイルにより、入力したすべての情報を収集および保存し、後でサイレント・アップグレードを実行できます。サイレント・アップグレードでは、Upgrade Assistantとまったく同じ機能が実行されますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。
    「アップグレード」をクリックして、アップグレード・プロセスを開始します。
  9. 「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

    注意:

    アップグレード・アシスタントにはアップグレードを実行するための十分な時間を与えてください。やむを得ない場合を除き、アップグレード操作は取り消さないでください。これを行うと、環境が不安定になる可能性があります。
    正しくアップグレードされていないコンポーネントがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

    ノート:

    この画面上の進行状況バーには、現在のアップグレード手順の進行状況が表示されます。アップグレードの残り時間を示すものではありません。

    「次へ」をクリックします。

  10. アップグレードが正常に終了した場合: 「アップグレード成功」画面で、「閉じる」をクリックしてアップグレードを完了しウィザードを閉じます。新規インストールでコンポーネントを機能させるために手動で実行する必要のある作業が、アップグレード後のアクションウィンドウに表示されます。このウィンドウは、コンポーネントにアップグレード後のステップがある場合のみ表示されます。
    アップグレードが失敗した場合: 「アップグレード失敗」画面で、「ログの表示」をクリックしてエラーを表示し、トラブルシューティングします。ログはNEW_ORACLE_HOME/oracle_common/upgrade/logsにあります。

    ノート:

    アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、Upgrade Assistantを再度起動する必要があります。

Oracle BAM 12cを含むOracle SOAのアップグレード後構成タスクの実行

最終的にOracle BAM 12cを含むことになる、SOA 12cドメインを実行するには、アップグレード後に追加の構成作業を実行する必要があります。

ノート:

Oracle BAM 11gを含む12c SOA環境を最初に実行することをお薦めします。環境が予想どおりに機能することを確認した後、Oracle BAM 12cを含むドメインを拡張できます(「Oracle BAM 12cを含むSOAドメインの拡張」を参照)。

  1. 管理(Admin)サーバーの起動
  2. WebLogic Server管理12cコンソールの起動
  3. Oracle BAMサーバーまたはOracle BAMクラスタで実行中のUMS JMSリソースの削除
    ここに示すステップは、スタンドアロン環境またはクラスタ化環境のUMS JMSリソースを削除するために使用できます。Oracle BAMクラスタには、追加のステップが必要になります。
  4. Oracle BAMにターゲット設定されたUMS JMSサーバーにターゲット設定されたサブデプロイメントのリソースの削除
    Oracle BAMにターゲット設定されたUMS JMSサーバーにターゲット設定されたサブデプロイメントのリソースを削除します。
  5. ドメインからのOracle BAMサーバーおよびクラスタの削除
    管理サーバーの実行中に、Weblogicコンソールを使用して、次のタスクを完了します。
  6. アップグレードされたドメインからファイルの不要なOracle BAM 11gファイルの削除
    domainupdaterスクリプトを使用して、不要な11gのファイルをアップグレードしたドメインから削除します。
  7. クラスタのアップグレードのみ: 管理サーバーと管理対象サーバーの停止
    クラスタをアップグレードする場合は、まず、管理サーバーと管理対象サーバーを停止してから、packコマンドとunpackコマンドを実行する必要があります。
  8. クラスタのアップグレードのみ: 管理サーバーと管理対象サーバーがインストールされた場所でのpackコマンドの実行
    クラスタ内の別のノードにNodeManagerを含む再構成済ドメインを取り込むには、管理サーバー・マシンから管理対象packを実行して、リモート・ノードで解凍します。
  9. クラスタのアップグレードのみ: unpackコマンドの実行によるSOAHOST1のドメイン構成のSOAHOST2へのレプリケート
    管理サーバーと管理対象サーバーがまだ停止していることを確認してから、次のunpackコマンドを実行して、リモート・マシン上の管理対象サーバー・ドメイン・ディレクトリに使用する、完全なドメインまたはドメインのサブセットを作成します
  10. 管理サーバーの再起動
    残りの構成タスクを実行する前に、12c管理サーバーを再起動する必要があります。
  11. SOA 12cドメインで動作するような11g Oracle BAMアダプタの構成
    SOA 12cドメインのアップグレードが完了したら、このSOA 12cドメインを構成して、Oracle BAM 11gドメインを使用します。
  12. SOA管理対象サーバーの再起動
    構成後の作業を完了するには、SOA管理対象サーバーを再起動する必要があります。
  13. SOAドメインからドライバの既存のUMS電子メール・ドライバの削除
    メール・パターンとの非互換性問題があるため、Oracle Enterprise ManagerのUMSドライバを削除する必要があります。

親トピック: Oracle Business Activity Monitoringを含むOracle SOA Suiteの11gからのアップグレード

管理(Admin)サーバーの起動

Oracle WebLogic管理サーバーを起動するには、次のスクリプトを使用します。 

(UNIX) DOMAIN_HOME/bin/startWebLogic.sh

(Windows) DOMAIN_HOME\bin\startWebLogic.cmd

親トピック: Oracle BAM 12cを含むOracle SOAのアップグレード後構成タスクの実行

WebLogic Server管理12cコンソールの起動

管理コンソールを表示するには:

  1. ブラウザに次のURLを入力します。
    http://hostname:port_number/console

    ポート番号は管理サーバーのポート番号です。デフォルトのポート番号は7001です。

    ログイン・ページが表示されます。

  2. インストール時に指定したユーザー名とパスワード、作成した別の管理ユーザーのユーザー名とパスワードを使用してログインします。

    あるいは、管理サーバーや管理対象サーバーなどのターゲットのホームページから、Fusion Middleware Controlの管理コンソールにアクセスすることもできます。

親トピック: Oracle BAM 12cを含むOracle SOAのアップグレード後構成タスクの実行

Oracle BAMサーバーまたはOracle BAMクラスタで実行中のUMS JMSリソースの削除

ここに示すステップは、スタンドアロン環境またはクラスタ化環境のUMS JMSリソースを削除するために使用できます。Oracle BAMクラスタには、追加のステップが必要になります。

  1. Oracle BAMサーバーまたはOracle BAMクラスタに向けてターゲット設定されているJMSサーバー名を特定します。複数のJMSサーバーがある場合は、Oracle BAMサーバーまたはクラスタに向けてターゲット設定されているサーバーをノートにとってから、作業を進めることが重要になります。所有するUMS JMSサーバーが1つのみの場合、デフォルト名はUMSJMSServer_auto_1になります。選択したUMS JMSサーバーのターゲットが、Oracle BAMサーバーまたはOracle BAMクラスタであることを必ず確認してください。

    「JMSサーバーのサマリー」画面に移動します(次の図を参照)。「ドメイン構造」メニューで、「サービス」を開き、「メッセージング」→「JMSサーバー」を選択します。Oracle BAMサーバーに向けてターゲット設定されているUMSJMSServerを見つけます。

    次の例では、UMSJMSServer_auto_3はOracle BAMサーバーにターゲット設定されたサーバーです。

    umsjms_servers_list.pngの説明が続きます
    図umsjms_servers_list.pngの説明
  2. Oracle BAMに向けてターゲット設定されたUMS JMSサーバー(この例では、UMSJMSServer_auto_3)のローカル・キューを削除します。

    「JMSモジュールのサマリー」画面に移動します(次の図を参照)。「ドメイン構造」メニューで、「サービス」を開き、「JMSモジュール」を選択します。UMSJMSSystemResourceを見つけてクリックすることで、「UMSJMSSystemResourceの設定」画面にローカル(および分散)キューを表示します。この結果にフィルタを適用すると、UMS JMSサーバーにターゲット設定したキューのみを表示できます。

    jms_modules.pngの説明が続きます
    図jms_modules.pngの説明
  3. Oracle BAMクラスタのみ: Oracle BAMサーバーまたはクラスタ(この例では、UMSJMSServer_auto_3)のみをターゲットに設定した共通分散キューをすべて選択します。(タイプ「共通分散キュー」でフィルタ処理できます)。「削除」をクリックします。

    注意: Oracle BAM以外のサーバー・ターゲットを含む分散キューは、削除しないでください。その他のターゲット対象サーバーがある場合は、まず、分散キューからOracle BAMサーバーを削除(ターゲット設定解除)しておく必要があります(ステップ4を参照)。

    dist_queue.pngの説明が続きます
    図dist_queue.pngの説明
  4. 分散キューからOracle BAMサーバーのターゲット設定を解除します(必要な場合)。

    分散キューからOracle BAMサーバーのターゲット設定を解除するには、「UMSJMSSystemResourceの設定」画面で「ターゲット」タブをクリックします。Oracle BAMサーバーの横のチェックマークを削除して、「保存」をクリックします。これで、ステップ3の説明に従って、分散キューを安全に削除できます。

    untarget_queue.pngの説明が続きます
    図untarget_queue.pngの説明
  5. UMS JMSサーバーに向けてターゲット設定されているローカル・キューを削除します。

    「UMSJMSSystemResourceの設定」画面で、Oracle BAMに向けてターゲット設定されているUMS JMSサーバー(UMSJMSServer_auto_3)にターゲット設定されたローカル・キューをすべて選択します(次を参照)。

    jms_queues.pngの説明が続きます
    図jms_queues.pngの説明
  6. 「削除」をクリックします。

親トピック: Oracle BAM 12cを含むOracle SOAのアップグレード後構成タスクの実行

Oracle BAMにターゲット設定されたUMS JMSサーバーにターゲット設定されたサブデプロイメントのリソースの削除

Oracle BAMにターゲット設定されたUMS JMSサーバーにターゲット設定されたサブデプロイメントのリソースを削除します。

  1. UMS JMSサーバーから、サブデプロイメントのリソースを削除します。

    「UMSJMSSystemResourceの設定」画面で、「サブデプロイメント」タブをクリックします。

  2. Oracle BAMに向けてターゲット設定されたUMS JMSサーバーを選択します(次の例では、UMSJMSServer_auto_3)。
  3. 「削除」をクリックします。

親トピック: Oracle BAM 12cを含むOracle SOAのアップグレード後構成タスクの実行

ドメインからのOracle BAMサーバーおよびクラスタの削除

管理サーバーの実行中に、Weblogicコンソールを使用して、次のタスクを完了します。

ノート:

Fusion Middleware Controlコンソールを介した操作の詳細は、「Oracle SOA SuiteおよびOracle BPM Suiteの管理のスタート・ガイド」を参照してください。

  1. 「JMSサーバーのサマリー」画面に移動します(次の図を参照)。「ドメイン構造」メニューで、「サービス」を開き、「メッセージング」→「JMSサーバー」を選択します。
  2. リストから、UMSJMSServer_auto_x を選択します。「現在のターゲット」が、Oracle BAMサーバーであることを確認します。
  3. 「削除」をクリックします。
  4. 永続ストアのサマリー画面に移動します(次の図を参照)。
  5. リストから、UMSJMSFileStore_auto_xを選択します。(「ターゲット」が、Oracle BAMサーバーであることを確認します。)
  6. 「削除」をクリックします。

  7. 「クラスタのサマリー」画面に移動します(次の図を参照)。「ドメイン構造」メニューで、「環境」を開き、「クラスタ」を選択します。
  8. クラスタのリストで、bam_clusterを選択します。
  9. 「削除」をクリックします。

  10. 「サーバーのサマリー」画面に移動します(次の図を参照)。「ドメイン構造」メニューで、「環境」を開き、「サーバー」を選択します。
  11. リストから、Oracle BAMサーバーを選択します。
  12. 「削除」をクリックします。

親トピック: Oracle BAM 12cを含むOracle SOAのアップグレード後構成タスクの実行

アップグレードされたドメインからの不要なOracle BAM 11gファイルの削除

domainupdaterスクリプトを使用して、不要な11gのファイルをアップグレードしたドメインから削除します。

  1. 12c管理サーバーを停止します。 
    DOMAIN_HOME/bin/stopWebLogic.sh 
       username password [admin_url]
  2. SOA 12cホームからdomainupdaterスクリプトを実行して、アップグレードしたドメインから不要なレガシー11gファイルを削除します。 
    (UNIX) cd ORACLE_HOME/soa/bam/bin
./domainupdater.sh
Enter the 11g domain path: (ex:)/soa11g/user_projects/domains/soa_domain 

(Windows) cd ORACLE_HOME\soa\bam\bin
domainupdater.cmd
Enter the 11g domain path: (ex:)\soa11g\user_projects\domains\soa_domain
  3. 12c管理サーバーを再起動します。 
    (UNIX) DOMAIN_HOME/bin/startWebLogic.sh

(Windows) DOMAIN_HOME\bin\startWebLogic.cmd

親トピック: Oracle BAM 12cを含むOracle SOAのアップグレード後構成タスクの実行

クラスタのアップグレードのみ: 管理サーバーと管理対象サーバーの停止

クラスタをアップグレードする場合は、まず、管理サーバーと管理対象サーバーを停止してから、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

管理対象サーバーは、次に示す順序で停止する必要があります。

親トピック: Oracle BAM 12cを含むOracle SOAのアップグレード後構成タスクの実行

管理サーバーおよび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サーバーおよびプロセスを停止します。

  1. Business Activity Monitoring (BAM)管理対象サーバー

  2. Oracle Service Bus (OSB)管理対象サーバー

  3. サービス指向アーキテクチャ(SOA)管理対象サーバー

  4. 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コマンドの概要に関する項を参照してください。

親トピック: Oracle BAM 12cを含むOracle SOAのアップグレード後構成タスクの実行

クラスタのアップグレードのみ: 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は、ドメイン・テンプレート・ファイルに割り当てられる名前です。

親トピック: Oracle BAM 12cを含むOracle SOAのアップグレード後構成タスクの実行

管理サーバーの再起動

残りの構成タスクを実行する前に、12c管理サーバーを再起動する必要があります。

管理サーバーを起動するときには、WebLogic Server管理コンソールおよびFusion Middleware Controlなど、管理サーバーで実行されているプロセスも起動します。

管理サーバーを起動するには、次のスクリプトを使用します。

(UNIX) DOMAIN_HOME/bin/startWebLogic.sh
(Windows)DOMAIN_HOME\bin\startWebLogic.cmd

プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよびURLを入力します。

親トピック: Oracle BAM 12cを含むOracle SOAのアップグレード後構成タスクの実行

SOA 12cドメインで動作する11g Oracle BAMアダプタの構成

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アダプタの構成に関する項を参照してください。

親トピック: Oracle BAM 12cを含むOracle SOAのアップグレード後構成タスクの実行

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サーバーおよびプロセスを次の順番で起動します。

  1. Oracle Web Services Manager (OWSM)管理対象サーバー

  2. サービス指向アーキテクチャ(SOA)管理対象サーバー

  3. Oracle Service Bus (OSB)管理対象サーバー

  4. Business Activity Monitoring (BAM)管理対象サーバー

ノート:

通常は、管理対象サーバーの起動により、それにデプロイされているアプリケーションが起動します。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。

親トピック: Oracle BAM 12cを含むOracle SOAのアップグレード後構成タスクの実行

SOAドメインからの既存のUMS電子メール・ドライバの削除

メール・パターンとの非互換性問題があるため、Oracle Enterprise ManagerのUMSドライバを削除する必要があります。

新しいドライバは、SOA 12cドメインをOracle BAM 12cテンプレートで拡張した後に作成します。

  1. 管理サーバーと、すべての管理対象サーバーがSOAドメインで実行しているときに、「ユーザー・メッセージング・サービス」に移動し、soa_serverに向けてターゲット設定されたusermessagingdriver-mailサービスを選択します。

    「ユーザー・メッセージング電子メール・ドライバ」ドロップダウン・メニューで、「電子メール・ドライバ・プロパティ」を選択します(次の図を参照)。

    email_driver_prop_menu.pngの説明が続きます
    図email_driver_prop_menu.pngの説明
  2. 「ターゲット・ナビゲーション」ペインで、「ユーザー・メッセージング・サービス」の電子メール・ドライバ名を選択します。
  3. 「削除」をクリックします。
  4. ドメイン内にある別のクラスタにも、このプロセスを繰り返します。

親トピック: Oracle BAM 12cを含むOracle SOAのアップグレード後構成タスクの実行

Oracle BAM 12cを含むSOAドメインの拡張

アップグレードされたSOA 12c環境とともにOracle BAM 12cを使用する準備が整っている場合、BAM 12cテンプレートを含むようにドメインを拡張する必要があります。

その場合、次の手順に従います。一部のタスクはオプションです。

  1. 管理サーバーおよびSOA管理対象サーバーを停止する
  2. Oracle BAM 12cドメイン・テンプレートによるSOA 12cドメインの拡張
  3. Oracle BAMサーバーの新しいUMS電子メール・ドライバの作成
  4. Oracle BAM 11gデータ・オブジェクトとEMSデータのBAM 12cサーバーへのインポート
  5. BAM 12cドメインで使用する11g BAMダッシュボード、アラートおよびその他のアーティファクトの手動での再作成
  6. 11gプロセス・キューブのBAM 12cプロセス・スター・スキーマへの移行(BPMユーザーのみ)
  7. 11g Monitor ExpressデータのBAM 12cプロセス・スター・スキーマへの移行(オプション)
  8. 12cでの11g互換プロセス・スター・スキーマ・データ・ビューの生成(オプション)

親トピック: Oracle Business Activity Monitoringを含むOracle SOA Suiteの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サーバーおよびプロセスを停止します。

  1. Business Activity Monitoring (BAM)管理対象サーバー

  2. Oracle Service Bus (OSB)管理対象サーバー

  3. サービス指向アーキテクチャ(SOA)管理対象サーバー

  4. 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ドメインを拡張します。

  1. 構成ウィザードを起動します。
    (UNIX) ORACLE_HOME/oracle_common/common/bin
./config.sh

(Windows) ORACLE_HOME\oracle_common\common\bin
config.cmd
  2. 要求されたら、「既存のドメインの拡張」を選択します。
  3. 「テンプレート」画面で、次のテンプレートを選択します。

    • Oracle WSMポリシー・マネージャ - 12.2.1.0

    • Oracle User Messaging Service - 12.2.1.0

    • Oracle BAM Client - 12.2.1.0

    • Oracle Enterprise Manager Plugin for BAM - 12.2.1.0

  4. 『Oracle SOA SuiteおよびBusiness Process Managementのインストールと構成』のOracle Business Activity Monitoringドメインの構成に関する項の説明に従って、構成ウィザードの残りの画面を完了します。

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コンソールを使用して、次のタスクを完了します。

  1. 「電子メール・ドライバ・プロパティ」 画面に移動します。

    「ターゲット・ナビゲーション」ペインで「ユーザー・メッセージング・サービス」を選択し、「ユーザー・メッセージング電子メール・ドライバ」ドロップダウン・メニューで「電子メール・ドライバ・プロパティ」を選択します(次の図を参照)。

    ums_config_12c_pic1.pngの説明が続きます
    図ums_config_12c_pic1.pngの説明
  2. 「作成」をクリックして、新しいUMS電子メール・ドライバを追加します。
  3. 次に示すように、「名前」フィールドで新しい電子メール・ドライバの一意の名前を指定します。UMSは、12cドメイン内の各クラスタに対して構成する必要があります。そのため、イメージに示すように「クラスタ」として「構成レベル」のデフォルト選択を維持します。
  4. デフォルトの送信者アドレスの使用を選択して、EMAIL:emailid@yourcompany.comと入力します。このフィールドには、EMAIL:という接頭辞が必須になります。
  5. 「OK」をクリックして、指定したプロパティで新しいドライバを作成します。

親トピック: Oracle BAM 12cを含むSOAドメインの拡張

Oracle BAM 11gデータ・オブジェクトとEMSデータのBAM 12cサーバーへのインポート

BAM 12cが含まれるようにドメインを拡張した後で、SOA 12cで使用しているBAM 11g環境から、データ・オブジェクトとEMSデータをエクスポートする必要があります。その後で、BAM 12cを含むSOA環境に、このデータをインポートします。

  1. 11g ICommandコマンドライン・ユーティリティを使用して、データ・オブジェクトとEMSデータを11g BAMドメインからエクスポートします。(EMS定義は標準アップグレード・プロセスの一部としてアップグレードされているため、インポートする必要はありません。)

    次の例では、Oracle BAMサーバーの1つ以上のオブジェクトに関する情報をXMLファイルにエクスポートする、ICommand 11gの使用方法を示しています。 

    $11g_ORACLE_HOME/soa/bam/bin/icommand -cmd export -name "/Samples/Call Center" -type dataobject -file C:\CallCenter.xml

    ノート: スクリプトを実行する前に、ICommand構成ファイルに変更を加えることが必要になる場合があります。具体的には、正しいユーザー名とパスワードが入力されていることを確認してください。BAMICommandConfig.xmlファイルは、WLS_HOME/user_projects/domains/base_domain/config/fmwconfig/servers/bam_server1/applications/oracle-bam_11.1.1/config/にあります。

    構成ファイルの例を、次に示します。 

    <host>www.example.com</host>
<port>7001</port>
<username>weblogic</username>
<password>your_password</password>
<dbusername>SOAINFRA</dbusername>
<dbpassword>your_dbpassword</dbpassword>
<dburl>jdbc:oracle:thin:@localhost:1521:example</dburl>

  2. 12cのBAMCommandコマンドライン・ユーティリティを使用して、前述のステップで作成したXMLファイルをインポートします。

    次の例は、12cのBAMCommandを使用して情報をインポートする方法を示しています。 

    $12c_ORACLE_HOME/soa/bam/bin/bamcommand -cmd import -file BPELOrderBookingDataObject.xml -upgrade 1 -username weblogic -port 7001 -host server.yourcompany.com

ノート:

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. タスク1: プロセス・メトリックを無効にします。
  2. タスク2: 移行に使用するexportTypeを決定します。
  3. タスク3: (UNIXのみ) 12c SOAホームから、migrateBPMProcessCubesスクリプトを実行します。
  4. タスク4: (Windowsのみ) 11g BPMプロセス・キューブから、データ・オブジェクトの定義とデータをエクスポートして、それらを12cにインポートします。
  5. タスク5: (Windowsのみ)ディメンション・データ(DimensionExport.zip)をBAMサーバーにインポートします。
  6. タスク6: (Windowsのみ)アクティブ・ファクト・データ(ActiveFactDataExport.zip)をBAMサーバーにインポートします。
  7. タスク7: (Windowsのみ: exportType=ALLの場合)完了ファクト・データ(CompletedFactDataExport.zip)をBAMサーバーにインポートします。
  8. タスク8: 移行が正常に完了したら、Oracle BAMサーバーを再起動します。
  9. タスク9: Oracle BAMサーバー実行中のプロセス・メトリックを有効化します。

親トピック: Oracle BAM 12cを含むSOAドメインの拡張

タスク1: プロセス・メトリックを無効にします。
  1. Fusion Middleware Controlコンソールにログインします。
  2. ターゲット・ナビゲーション・ペインで、WebLogicドメイン・ノードを開きます。
  3. Oracle SOA 12cサーバーがインストールされているドメインを選択します。

    たとえば、ドメインはsoainfraまたはbase_domainです。

  4. ドメインを右クリックし、「システムMBeanブラウザ」を選択します。

    システムMBeanブラウザ・ページが表示されます。

  5. 「システムMBeanブラウザ」で、「アプリケーション定義のMBean」ノードを開きます。
  6. 「アプリケーション定義のMBean」の下の「oracle.as.soainfra.config」ノードを展開します。
  7. oracle.as.soainfra.configの下のServer: server_nameノードを開きます。
  8. Server: server_nameの下のAnalyticsConfigノードを開きます。
  9. AnalyticsConfigの下で、analyticsをクリックします。

    analytics属性がリストされます。

  10. trueに設定されていない場合は、DisableProcessMetrics属性の値をtrueに変更します。
  11. 「適用」をクリックします。
タスク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オプションを使用して実行している場合)

migrateBPMProcessCubesスクリプトを実行する前に、次の環境変数を設定する必要があります。
環境変数 説明 場所の例
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オプションを使用して実行している場合)

  1. データ・オブジェクトと定義を、次のコード例を使用してエクスポートします(必ず実際のディレクトリ名を指定してください)。
    java -cp

%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.interface.jar;
%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.model.jar;
%ORACLE_HOME%\oracle_common\modules\oracle.jdbc_12.1.0\ojdbc6.jar;
%ORACLE_HOME%\bam\modules\oracle.bam.client\bam-client.jar;%ORACLEHOME%\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.bpm.metrics.dataobject.migration.application.Migrate11gProcessCubesto12cDO -url <soa db jdbc url> -userName <soa schema user name> -exportDir <export directory path> [-exportType ALL]
  2. データ・オブジェクト定義(DefinitionExport.zip)をBAMサーバーにインポートします。
    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  DefinitionExport.zip> -mode update

    ノート: BAM 12cのアーカイブをインポートした後で、ORACLE_HOME/bam/binディレクトリのbamcommand.log.*ファイルを調べて、エラーが発生していないことを確認します。エラー条件がある場合は、「エラー処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行」を参照してください。

タスク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

プロンプトが表示されたらユーザー名とパスワードを入力します。

タスク9: Oracle BAMサーバー実行中のプロセス・メトリックを有効化します。
  1. Fusion Middleware Controlコンソールにログインします。
  2. ターゲット・ナビゲーション・ペインで、WebLogicドメイン・ノードを開きます。
  3. Oracle BAMサーバーがインストールされているドメインを選択します。

    たとえば、ドメインはsoainfraまたはbase_domainです。

  4. ドメインを右クリックし、「システムMBeanブラウザ」を選択します。

    システムMBeanブラウザ・ページが表示されます。

  5. 「システムMBeanブラウザ」で、「アプリケーション定義のMBean」ノードを開きます。
  6. 「アプリケーション定義のMBean」の下の「oracle.as.soainfra.config」ノードを展開します。
  7. oracle.as.soainfra.configの下のServer: server_nameノードを開きます。
  8. Server: server_nameの下のAnalyticsConfigノードを開きます。
  9. AnalyticsConfigの下で、analyticsをクリックします。

    analytics属性がリストされます。

  10. DisableProcessMetrics属性の値をfalseに変更します。
  11. 「適用」をクリックします。

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スター・スキーマへの移行」を参照してください。

  1. プロセス・メトリックを無効にします。
  2. Oracle BAM移行ユーティリティを実行してMonitor Expressデータを移行します。
  3. BPMデータをOracle BAM 12cにインポートします。
  4. BAM 12cへのパブリッシュを有効化します。

親トピック: Oracle BAM 12cを含むSOAドメインの拡張

プロセス・メトリックを無効にします。
  1. Fusion Middleware Controlコンソールにログインします。
  2. ターゲット・ナビゲーション・ペインで、WebLogicドメイン・ノードを開きます。
  3. Oracle BAMサーバーがインストールされているドメインを選択します。

    たとえば、ドメインはsoainfraまたはbase_domainです。

  4. ドメインを右クリックし、「システムMBeanブラウザ」を選択します。

    システムMBeanブラウザ・ページが表示されます。

  5. 「システムMBeanブラウザ」で、「アプリケーション定義のMBean」ノードを開きます。
  6. 「アプリケーション定義のMBean」の下の「oracle.as.soainfra.config」ノードを展開します。
  7. oracle.as.soainfra.configの下のServer: server_nameノードを開きます。
  8. Server: server_nameの下のAnalyticsConfigノードを開きます。
  9. AnalyticsConfigの下で、analyticsをクリックします。

    analytics属性がリストされます。

  10. DisableProcessMetrics属性の値をtrueに変更します。
  11. 「適用」をクリックします。
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に設定します。

  1. Fusion Middleware Controlコンソールにログインします。
  2. ターゲット・ナビゲーション・ペインで、WebLogicドメイン・ノードを開きます。
  3. Oracle BAMサーバーがインストールされているドメインを選択します。

    たとえば、ドメインはsoainfraまたはbase_domainです。

  4. ドメインを右クリックし、「システムMBeanブラウザ」を選択します。

    システムMBeanブラウザ・ページが表示されます。

  5. 「システムMBeanブラウザ」で、「アプリケーション定義のMBean」ノードを開きます。
  6. 「アプリケーション定義のMBean」の下の「oracle.as.soainfra.config」ノードを展開します。
  7. oracle.as.soainfra.configの下のServer: server_nameノードを開きます。
  8. Server: server_nameの下のAnalyticsConfigノードを開きます。
  9. AnalyticsConfigの下で、analyticsをクリックします。

    analytics属性がリストされます。

  10. DisableProcessMetrics属性の値をfalseに変更します。
  11. 「適用」をクリックします。

ノート:

アーカイブ・ファイルのインポート中にエラーが発生した場合は、ロールバック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環境で使用するビュー(標準およびプロセス固有の両方)の再作成を支援するために、自動化されたユーティリティが用意されています。

  1. タスク1: クラスパスを更新してインタフェースJARファイルを含める
  2. タスク2: 標準のビューを再作成する
  3. タスク3: プロセス固有のビューを再作成する

親トピック: 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にインポートできます。このプロセス中にエラーが返された場合は、この項を使用して問題の解決にあたってください。

親トピック: Oracle Business Activity Monitoringを含むOracle SOA Suiteの11gからのアップグレード

CFGFWK-60950エラーの解決

CFGFWK-60950エラーを受け取った場合は、BAMテンプレートの名前を変更して(「11gスキーマのアップグレード前のOracle BAMテンプレートの名前の変更」を参照)、再構成ウィザードを再度起動します。

このエラーを受け取ったら、アップグレード前の環境全体をリストアし、必要なアップグレード前タスクを実行して、リストされている項のステップを実行する必要があります。その後で、再構成プロセスを再度実行してみてください。

親トピック: 失敗したOracle BAMアップグレードからのリカバリ

エラー処理: 11gプロセス・キューブからBAM 12cスター・スキーマへの移行

一般的なエラーは、データの変更内容をロール・バックして、オプションを変更したスクリプトを再実行することで解決できることがあります。

すべてのデータ変更内容のロールバック:

  1. SOAデータベースでSQLセッションを開きます。
  2. SOAINFRAスキーマ・ユーザーとしてログインし、次のスクリプトを実行して、すべてのデータ変更内容をロールバックします。 
    "<exportDir>/rollBackBPMProcessCubesMigration.sql"

使用しているオペレーティング・システムの推奨事項を確認してください。

親トピック: 失敗した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プロセス・キューブからアーカイブをエクスポートしているときにエラーが発生した場合は、次のタスクを実行します。

  1. (<exportDir>)として定義されているエクスポート・ディレクトリのバックアップ・コピーを作成します。
  2. <exportDir>の内容を削除します。
  3. シェル・スクリプトmigrateBPMProcessCubes.shを「11gプロセス・キューブのBAM 12cプロセス・スター・スキーマへの移行(BPMユーザーのみ)」で説明しているとおりに再実行します。ただし、-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]

追加情報:

問題の解決を支援するために、次の作業も実行してみてください。

  • BAM 12cに各アーカイブをインポートした後で、$ORACLE_HOME/bam/binディレクトリにあるbamcommond.log.*ファイルを調べて、エラーが発生していないことを確認します。

  • <exportDir>/MigrationLogs.*にある移行のログを調べます。

親トピック: 失敗したOracle BAMアップグレードからのリカバリ

Windowsオペレーティング・システムのエラー処理

前述したように、すべてのデータ変更内容をロールバックして、次を実行してみてください。

インポート・フェーズで発生したエラーの場合:

次の各項で説明しているとおりに、アーカイブを再インポートします。

エクスポート・フェーズで発生したエラーの場合:

BPMプロセス・キューブからアーカイブをエクスポートしているときにエラーが発生した場合は、次のタスクを実行します。

  1. (<exportDir>)として定義されているエクスポート・ディレクトリのバックアップ・コピーを作成します。
  2. <exportDir>の内容を削除します。
  3. シェル・スクリプトmigrateBPMProcessCubes.shを「11gプロセス・キューブのBAM 12cプロセス・スター・スキーマへの移行(BPMユーザーのみ)」で説明しているとおりに再実行します。ただし、-importOnlyオプションは削除してください。

    たとえば:

    java -cp

%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.interface.jar;
%ORACLE_HOME%\soa\modules\oracle.bpm.runtime_11.1.1\oracle.bpm.analytics.metrics.model.jar;
%ORACLE_HOME%\oracle_common\modules\oracle.jdbc_12.1.0\ojdbc6.jar;
%ORACLE_HOME%\bam\modules\oracle.bam.client\bam-client.jar;%ORACLEHOME%\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.bpm.metrics.dataobject.migration.application.Migrate11gProcessCubesto12cDO -url <soa db jdbc url> -userName <soa schema user name> -exportDir <export directory path> [-exportType ALL]
  4. 「11g Monitor ExpressデータのBAM 12cプロセス・スター・スキーマへの移行(オプション)」の残りの移行ステップを繰り返します。

親トピック: 失敗したOracle BAMアップグレードからのリカバリ