プライマリ・コンテンツに移動
Oracle® Fusion Middleware SOA SuiteおよびBusiness Process Managementのアップグレード
12c (12.2.1.1)
E77369-01
目次へ移動
目次

前
次

4 以前の12cリリースからのOracle SOA SuiteおよびBusiness Process Managementのアップグレード

アップグレード手順は、開始ポイントや既存のドメイン内のコンポーネントにより異なります。以前の12cリリースからアップグレードする場合、次の手順を使用してこのリリースにアップグレードします。

次のいずれかのアップグレード・パスを選択します。

4.1 以前の12cリリースからSOA SuiteおよびBusiness Process Management 12c (12.2.1.1)へのアップグレード

Oracle SOA SuiteおよびBusiness Process Managementの12cデプロイメントをこの12cリリースにアップグレードするには、この手順に従います。

  1. すべての必要なアップグレード前タスクが完了していることを確認します。
    このプロセスを開始する前に、アップグレード前タスクを完了します。「Oracle Fusion Middlewareアップグレード前のチェックリスト」と、デプロイされたアプリケーションに必要となる可能性があるSOA固有のタスクを参照してください。リストアの必要が生じた場合のために、使用可能な完全なバックアップ・バージョンが存在することを確認します。
  2. 新しいOracleホームに12c (12.2.1.1)製品ディストリビューションをインストールします。Oracle SOA SuiteおよびBusiness Process Management 12cのインストール (12.2.1.1)
  3. Upgrade Assistantを-readinessモードで使用して、アップグレード前の準備状況チェックを実行します。
    12c (12.2.1.1) OracleホームからreadinessモードでUpgrade Assistantを起動して、12.1.3または12.2.1ドメインに、アップグレードの失敗の原因となる可能性のある問題がないか確認します。

    UNIXオペレーティング・システムのユーザーは、12c (12.2.1.1) Oracleホームのoracle_common/upgrade/binに移動します

    次のコマンドを実行します。 ./ua — readiness

    Windowsオペレーティング・システムのユーザーは、12c (12.2.1.1) Oracleホームのoracle_common\upgrade\binに移動します

    次のコマンドを実行します。ua.bat — readiness

  4. すべての管理サーバーおよび管理対象サーバーを停止しますSOAサーバーとプロセスの停止
  5. Upgrade Assistant 12c (12.2.1.1)を使用して、12.1.3または12.2.1.0スキーマを12c (12.2.1.1)にアップグレードします。
    12c (12.2.1.1) OracleホームからUpgrade Assistantを起動して、12.1.3または12.2.1.0スキーマをアップグレードします。

    UNIXオペレーティング・システムでは、ディレクトリをORACLE_HOME/oracle_common/upgrade/binに変更します

    次のコマンドを実行します。 ./ua

    Windowsオペレーティング・システムでは、ディレクトリをORACLE_HOME\oracle_common\upgrade\binに変更します

    次のコマンドを実行します。ua.bat

    注意:

    デフォルトのロギング・レベルはNOTIFICATIONです。(必要な場合)トラブルシューティングの際に役立つように、ロギング・レベルをWARNINGまたはERRORに設定することを検討します。例: ./ua -logLevel ERROR
  6. 標準アップグレード・プロセス「Upgrade Assistantを使用したSOAスキーマのアップグレード」の説明に従って、Upgrade Assistantの各画面を完了します
  7. 再構成ウィザードを使用したドメイン構成のアップグレード

    再構成ウィザードを起動してドメインを再構成します。

    UNIXオペレーティング・システムの場合:

    ORACLE_HOME/oracle_common/common/bin

    Windowsオペレーティング・システムの場合:

    ORACLE_HOME\oracle_common\common\bin

    ORACLE_HOMEは、12c (12.2.1.1) Oracleホーム・ディレクトリです。

    UNIXオペレーティング・システムの場合:

    ./reconfig.sh -log=<log_file> -log_priority=ALL

    Windowsオペレーティング・システムの場合:

    reconfig.cmd -log=<log_file> -log_priority=ALL

    12c (12.2.1.1) Oracleホームから再構成ウィザードを起動して、12.1.3または12.2.1ドメインをアップグレードします。
  8. 標準再構成プロセス「ドメインの再構成」の説明に従って、再構成ウィザードの各画面を完了します
    再構成プロセスの間、サーバーを正しいサーバー・グループにターゲット指定する必要があります(詳細は「再構成ウィザードを使用したサーバー・グループのターゲット指定」を参照)

4.1.1 Oracle SOA SuiteおよびBusiness Process Management 12cのインストール (12.2.1.1)

既存のSOAおよびBusiness Process Management (BPM)のコンポーネントをアップグレードする前に、まず、Oracle Fusion Middleware InfrastructureとOracle SOA SuiteおよびBusiness Process Management 12c (12.2.1.1)製品ディストリビューションをインストールする必要があります。

12c (12.2.1.1)製品ディストリビューションを新しいOracleホーム・ディレクトリにインストールします。インストールに既存のOracleホーム・ディレクトリを使用しないでください。

前提条件となるソフトウェアがすべてインストールされていることを確認します。Oracle SOA Suiteには、Oracle Fusion Middleware Infrastructure (Oracle WebLogic ServerおよびJRF)が必要です。詳細は、「Infrastructureソフトウェアのインストール」を参照してください

使用するSOAドメインに別のSOA統合コンポーネントがある場合は、それらのディストリビューションもインストールする必要があります。各製品ディストリビューションのインストール・ガイドの完全なリストについては、Oracle Fusion Middlewareドキュメント・ライブラリを参照してください。このドキュメントの、コンポーネント固有の章を確認して、追加のインストールに対する追加のアップグレード前の手順があるかどうかを判断してください。

  1. ターゲットのシステムにログインします。
  2. インストール・プログラムがダウンロードされたディレクトリに移動します。
  3. ご使用のシステムのJDKディレクトリからjava実行可能ファイルを実行して、インストール・プログラムを起動します。
    • UNIXオペレーティング・システムの場合: /home/Oracle/Java/jdk1.8.0_77/bin/java —jar fmw_12.2.1.0.0_PRODUCT.jar

    • Windowsオペレーティング・システムの場合: C:\home\Oracle\Java\jdk1.8.0_77\bin\java -jar <component_name>.jarfmw_12.2.1.0.0_PRODUCT.jar

    例: cd /home/Oracle/Java/jdk1.8.0_77/bin/java —jar fmw_12.2.1.0.0_PRODUCT.jar

    これらの例にあるJDKの場所は、ご使用のシステムの実際のJDKの場所に読み替えてください。

  4. 「インストール画面のナビゲート」の手順に従います。このリンクを使用すると、サポートされているすべてのトポロジに対応するインストール手順が記載されたOracle SOA SuiteおよびBusiness Process Managementのインストレーション・ガイドにアクセスできます。
  5. インストールの終わりに、構成ウィザードを起動して12c (12.2.1.1)に新しいドメインを構成するように要求されます

4.1.2 アップグレード前の準備状況チェックの実行

Upgrade Assistantを-readinessモードで実行することにより、実際にアップグレードを実行する前にアップグレードの潜在的な問題を特定できます。

準備状況チェックは、既存のドメインまたはデータベース・スキーマをスキャンし、スキャンの結果が記載されたテキスト・ファイルを生成する読取り専用操作です。アップグレード前の環境に問題がある場合、アップグレードする前にこれらの問題を修正してから、準備状況チェックを再実行できます。

デフォルトで、準備状況チェック・レポート・ファイルはOracle 12cディレクトリ(ORACLE_HOME/oracle_common/upgrade/logs)に配置されます。

注意:

準備状況チェックは、システムがオンライン中に実行できます。チェックの複雑さによっては、準備状況チェックが終わるまでにしばらく時間がかかります。パフォーマンスの低下を回避するために、準備状況チェックは使用率の低い期間に実行することをお薦めします。
アップグレード前の環境に対して準備状況チェックを実行するには、-readinessモードでアップグレード・アシスタントを起動します。
  1. binディレクトリに移動します。

    UNIXオペレーティング・システムの場合:

    ORACLE_HOME/oracle_common/upgrade/bin

    Windowsオペレーティング・システムの場合:

    ORACLE_HOME\oracle_common\upgrade\bin

  2. 次のコマンドを入力してアップグレード・アシスタントを起動します。

    UNIXオペレーティング・システムの場合:

    ./ua -readiness

    Windowsオペレーティング・システムの場合:

    ua.bat -readiness

    次のUNIXの例に示すように、ロギング・パラメータを使用してアップグレード・アシスタントを起動することもできます。

    ./ua [-logLevel <log_level] [-logDir <log_directory>]

    ロギング・レベル。次のいずれかを選択します。
    • TRACE

    • NOTIFICATION

    • WARNING

    • ERROR

    • INCIDENT_ERROR

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

    トラブルシューティングする場合、-logLevelTRACEに設定すると、より多くの情報がロギングされます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があるため、別の情報が必要ない場合は、logLevelを変更してください。

    注意:

    サービス表スキーマを作成していない場合、UPGAST-00328: スキーマ・バージョンのレジストリ表はこのデータベースに存在しません。その場合、Upgrade Assistantを実行するためにはサービス表スキーマを作成する必要があります。というエラー・メッセージが表示されることがあります。

    この場合、リポジトリ作成ユーティリティ(RCU)を使用して必要な12cスキーマを作成する必要があります。

    表4-1 Upgrade Assistant画面: 準備状況チェック

    画面 画面が表示されるタイミング 説明
    ようこそ

    常時。

    この画面には、準備状況チェックの概要が示されます。

    準備状況チェックのタイプ:

    • 個別に選択されたスキーマ

    • ドメイン・ベース

    常時。

    準備状況チェックは、サポートされるアップグレードの開始点にあるスキーマまたはコンポーネント構成に対してのみ実行されます。次の2つのオプションがあります。次にこれらのオプションについて説明します。

    • 「個別に選択されたスキーマ」オプションを使用すると、アップグレードする前に確認するスキーマを選択できます。

    • 「ドメイン・ベース」オプションを使用して、ドメインごとに準備状況チェックが実行されるようにします。

    使用可能なコンポーネント

    「個別に選択されたスキーマ」が選択されている場合。

    この画面には、スキーマが選択される使用可能なコンポーネントがリストされます。ここで何かを選択すると、そのコンポーネントのスキーマに対して準備状況チェックが実行されます。

    すべてのスキーマのコンポーネント・リスト

    スキーマの準備状況チェックが実行されるたび。

    この画面は、スキーマの準備状況チェックが実行されるたびに表示されます。これは、「すべてのスキーマのチェックを含める」オプションを使用して「個別に選択されたスキーマ」または「ドメイン・ベース」を選択する場合です。
    スキーマ資格証明

    常時。

    この画面を使用して、選択したスキーマとそのスキーマをホストするデータベースへの接続に必要な情報を入力します。アップグレードするスキーマが以前のFusion MiddlewareのリリースでRCUによって作成された場合は、使用可能なスキーマ名がリストされたドロップダウン・メニューが表示されます。

    DBAユーザー名: SYSDBAではなくFMWとしてUpgrade Assistantを実行することをお薦めします。まだFMWユーザーを作成していない場合は、「Upgrade Assistantを実行するための非SYSDBAユーザーの作成」を参照してください

    準備状況サマリー

    常時。

    この画面には、選択に基づいて実行される準備状況チェックの概要が示されます。

    Upgrade Assistantを-response (またはサイレント)モードで再実行する場合は、「レスポンス・ファイルの保存」をクリックします。

    準備状況チェック

    常時。

    この画面には、準備状況チェックの現在のステータスが表示されます。チェック対象として選択した内容によっては、このプロセスには数分かかる場合があります。

    詳細レポートを表示するには、準備状況レポートのレビューをクリックします。このボタンは、準備状況チェックがすべて完了した後のみ表示されます。

    注意:

    パフォーマンスの低下を回避するには、準備状況チェックをオフピーク時に実行することを検討してください。
    準備状況成功

    準備状況チェックが正常に完了した場合。

    これで、完全なレポートをレビューできるようになります。

    準備状況チェックで問題またはエラーが発生した場合、ログ・ファイルをレビューして問題を特定し、問題を修正してから、準備状況チェックを再開してください。

    デフォルトで、準備状況チェック・レポート・ファイルは次のOracle 12cディレクトリに配置されます。

    ORACLE_HOME/oracle_common/upgrade/logs

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

アップグレード・アシスタントを実行する前に、すべてのOracle Fusion Middleware管理対象サーバー、管理サーバーおよび更新するスキーマまたは構成を使用している可能性があるシステム・コンポーネント(OHSなど)を停止する必要があります。

注意:

サーバーやプロセスの停止に失敗すると、結果としてアップグレードが不完全になったり、失敗したりする場合があります。

WebLogic Server管理対象サーバーを停止するには、次のスクリプトを使用します。

(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)管理対象サーバー

  5. 管理サーバー

  6. ノード・マネージャ

    ノード・マネージャを実行している場合は、ノード・マネージャも停止する必要があります。これを行うには、ノード・マネージャが実行されているコンソール・ウィンドウを閉じるか、stopNodeManager WLSTコマンドを使用します。

  7. Web層(Oracle HTTP Serverを含む)

4.1.4 Upgrade Assistantの起動

次の手順を実行して、管理サーバーが実行されているホストでアップグレード・アシスタントを起動します。

  1. UNIXオペレーティング・システムでは、ディレクトリをORACLE_HOME/oracle_common/upgrade/binに変更します。

    Windowsオペレーティング・システムでは、ディレクトリをORACLE_HOME\oracle_common\upgrade\binに変更します。

  2. 次のコマンドを入力して、アップグレード・アシスタントを起動します。

    UNIXオペレーティング・システムの場合:

    ./ua

    Windowsオペレーティング・システムの場合:

    ua.bat

    次のUNIXの例に示すように、ロギング・パラメータを使用してアップグレード・アシスタントを起動することもできます。

    ./ua [-logLevel <log_level] [-logDir <log_directory>]

    ロギング・レベル。次のいずれかを選択します。
    • TRACE

    • NOTIFICATION

    • WARNING

    • ERROR

    • INCIDENT_ERROR

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

    注意:

    トラブルシューティングする場合、-logLevelTRACEに設定すると、より多くの情報がロギングされます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があるため、別の情報が必要ない場合は、logLevelを変更してください。

4.1.5 Upgrade Assistantを使用したSOAスキーマのアップグレード

Upgrade Assistantを使用して、サポートされているスキーマを12c (12.2.1.1)にアップグレードします

Upgrade Assistantでは、スキーマのアップグレード時に、次に示す一連の画面が表示されます。各画面でアクションを実行します。

表4-2 Upgrade Assistant画面: スキーマのアップグレード

画面 説明および必要なアクション

ようこそ

この画面では、アップグレード・アシスタントの概要と、アップグレード前の重要なタスクについての情報が示されます。

スキーマ

「個別に選択されたスキーマ」を選択します。

使用可能なコンポーネント

この画面では、アップグレード可能なスキーマがあるインストール済のOracle Fusion Middlewareコンポーネントのリストが提供されます。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。

たとえば、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)がアップグレードに含まれます。

GUID-C60649BE-E01A-4571-982C-090AA493C64B-default.pngの説明が続きます。
GUID-C60649BE-E01A-4571-982C-090AA493C64B-default.pngの説明

ドメイン・ディレクトリ

この画面では、「使用可能なコンポーネント」画面でOracle Platform Security ServicesまたはOracle監査サービスのどちらを選択したかが表示されます。

既存のWebLogicドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックして、アップグレードするドメイン・ディレクトリに移動して選択します。

前提条件

スキーマ・アップグレードの前提条件が満たされていることを確認します。「次」をクリックする前に、それぞれの前提条件を選択する必要があります。

注意: アップグレード・アシスタントは、これらの前提条件が満たされていることを確認しません。

スキーマ資格証明

この画面を使用して、アップグレードする各スキーマのデータベース接続の詳細を入力します。

  1. 「データベース・タイプ」ドロップダウン・メニューからデータベース・タイプを選択します。

  2. データベース接続の詳細を入力して、「接続」をクリックします。

  3. 「スキーマ・ユーザー名」ドロップダウン・メニューからアップグレードするスキーマを選択し、スキーマのパスワードを入力します。

    場合によっては(_ORASDPMなど)、スキーマ・ユーザー名とパスワードを手動で入力する必要があります。

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

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

注意:

  • スキーマ資格証明画面のタイトルは、アップグレードするスキーマに応じて変化します。たとえば、_SOAINFRAスキーマをアップグレードする場合、画面のタイトルはSOAINFRAスキーマと表示されます。

  • データベースへの接続に必要なフィールドの詳細は、「ヘルプ」をクリックします。

調査

各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するアップグレード・アシスタントのステータスを確認します。

スキーマごとに表示される「ソース・バージョン」に、アップグレード対象のスキーマの正しいバージョン番号が示されていることを確認します。

アップグレード・サマリー

スキーマ・アップグレードのために選択したオプションのサマリーを確認します。正しいソース・バージョンとターゲット・バージョンが、アップグレード対象の各スキーマにリストされていることを確認します。

「アップグレード」をクリックしてスキーマをアップグレードするか、構成を変更する場合は「戻る」をクリックします。

アップグレードの進行状況

現在のアップグレード・プロセスのステータスを確認します。

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

アップグレードが完了したら「次へ」をクリックします。

アップグレード成功

アップグレードが成功していれば「閉じる」をクリックします。

アップグレードが失敗した場合または正常に完了する前にアップグレードを取り消した場合は、ログ・ファイルを確認してバックアップ環境をリストアし、アップグレード・アシスタントを再起動する必要があります。

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

スキーマをアップグレードした後、再構成ウィザードを実行して、ドメイン・コンポーネント構成を12cに再構成します。

再構成ウィザードを実行して、WebLogic Serverドメインを再構成する場合は、ドメインのアプリケーションによって、次の項目が自動的に更新されます。

  • WLSコア・インフラストラクチャ

  • ドメイン・バージョン

注意:

再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。
具体的には、ドメインを再構成すると、次のようになります。
  • ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。

  • すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。

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

注意:

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

再構成ウィザードを使用して既存のドメインを再構成する手順に従います。ドメインの再構成に関する一般的な情報は、WebLogicドメインの再構成に関する項を参照してください。

4.1.6.1 ドメインのバックアップ

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

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

4.1.6.2 再構成ウィザードの起動

次の手順を実行して、再構成ウィザードをグラフィカル・モードで起動します。

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

    次のSQLコマンドを実行して、デフォルト・エディションを設定します。

    ALTER DATABASE DEFAULT EDITION = edition_name;
    

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

  4. 次のディレクトリに移動します。

    (UNIXオペレーティング・システムの場合) ORACLE_HOME/oracle_common/common/bin

    (Windowsオペレーティング・システムの場合) ORACLE_HOME\oracle_common\common\bin

    ORACLE_HOMEは12c Oracleホーム・ディレクトリです。

  5. 次のコマンドを実行します。

    (UNIXオペレーティング・システム) ./reconfig.sh -log=log_file -log_priority=ALL

    (Windowsオペレーティング・システム) reconfig.cmd -log=log_file -log_priority=ALL

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

    パラメータ -log_priority=ALLは、ログを詳細モードで出力します。

    注意:

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

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

    環境変数CONFIG_JVM_ARGSを設定することでキャッシュ・ディレクトリを変更できます。次に例を示します。

    CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

4.1.6.3 ドメインの再構成

次に示す画面は、いくつかが表示されないこともあります。また、使用する環境の設定に基づいた追加の画面を完了する必要がある場合もあります。詳細は、WebLogicドメインの再構成に関する項を参照してください。

表4-3 再構成ウィザードの画面

再構成ウィザードの画面 説明および必要なアクション
ドメインの選択

既存のドメイン・ディレクトリの絶対パスを入力するか、「参照」をクリックしてドメイン・ディレクトリを選択します。

再構成セットアップの進行状況

再構成テンプレートの適用の進行状況が表示されます。

ドメイン・モードおよびJDK

ドメイン・モードは変更できません。

ドメインで使用するJDKを選択するか、「参照」をクリックして使用するJDKに移動します。

Oracle Fusion Middleware 12cにはJava SE 7が必要であることに注意してください。詳細は、「動作保証要件とシステム要件の確認」を参照してください。

データベース構成タイプ

「RCUデータ」オプションを使用して、Server Table (_STB)スキーマを収集します。Repository Creation Utility (RCU)はサービス表スキーマを自動的に使用して、他の12cスキーマ資格証明を自動的にロードします。後続JDBC画面のデータを常に確認してください。

注意: 既存の11gデータ・ソースの場合、再構成では既存の値が保存されます。スキーマが12c RCUで作成された新しいデータ・ソースの場合、デフォルトの接続データは_STBスキーマから取得されます。特定のスキーマの接続データが_STBスキーマにない場合は、デフォルトの接続データが使用されます。

JDBCデータ・ソース

この画面は、11gでデータベースベースのOPSSセキュリティ・ストアまたは監査データ・ストア用にカスタム・データ・ソースを作成していた場合に表示されます。

この画面では、ドメイン・ソースで定義したJDBCデータ・ソースを構成します。

JDBCデータ・ソース・テスト

「JDBCデータ・ソース」画面で構成したデータ・ソース接続をテストします。

JDBCコンポーネント・スキーマ

各スキーマ名の横のチェック・ボックスを選択して、画面に表示された各スキーマのデータソース設定を指定します。

アップグレードしたスキーマに、11gスキーマの詳細を指定する必要があります。それ以外については、12.2.1.1スキーマの詳細を指定します。

JDBCコンポーネント・スキーマ・テスト

前の画面でデータ・ソースに指定した構成をテストします。テストするスキーマ名の横のチェック・ボックスを選択し、「選択された接続のテスト(T)」をクリックします。

テストの結果は、「ステータス」列に表示されます。すべてのスキーマでテストに成功した場合、「次へ」をクリックします。

ノード・マネージャ

この画面は、再構成するドメインで、ホストごとのノード・マネージャが使用されている場合にのみ表示されます。この画面を使用して、再構成するドメインに使用するノード・マネージャ構成を選択します。結果として得られる構成は、「ノード・マネージャ・タイプ」と「ノード・マネージャ構成」に選択したオプションの組合せによって異なります。

拡張構成

この画面に表示されるカテゴリは、ドメインの構成中にドメインに選択したテンプレートで定義されているリソースによって異なります。

たとえば、SOA SuiteおよびBPMテンプレートをドメインに適用するときに、次の事項が1つ以上当てはまる場合は、「管理対象サーバー、クラスタおよびCoherence」を選択します。

  • 単一のドメイン(たとえば、soa_server1やbam_server1)に複数の管理対象サーバーがある

  • クラスタまたはCoherenceのデータを変更する必要がある

「ノード・マネージャ」、「デプロイメントとサービス」、「ドメイン・フロントエンド・ホストのキャプチャ」、「JMSファイル・ストア」など、その他の拡張構成オプションの使用の詳細は、オンライン・ヘルプを参照してください。

管理対象サーバー

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

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

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

12.1.3から12.2.1.1にアップグレードするときは、適切なサーバー・グループにサーバーを割り当てる必要があります。「再構成ウィザードを使用したサーバー・グループのターゲット指定」を参照してください

サーバーのマシンへの割当て

アップグレード・プロセスの一部としてサーバーを作成した場合は、「サーバー」リスト・ボックスでサーバー名を選択して、適切なノード・マネージャ・マシンにターゲット設定します。

そうでない場合は、ドメインのアップグレード時または再構成時にこの画面で操作は必要ありません。

サーバーのクラスタへの割当

クラスタのアップグレードのみ: クラスタをアップグレードする場合は、この画面を使用して管理対象サーバーをクラスタに割り当てます。

「サーバー」リスト・ボックスには管理対象サーバーのみが表示されます。管理サーバーは、クラスタに割り当てることができないので、リストに表示されません。

注意:

SOA UPGRADES ONLY: OWSMPMが独自のクラスタにあり、SOAまたはOSBクラスタの一部でない場合、SOAクラスタにはSOA-MGD-SVRS-ONLYユーザー拡張可能サーバー・グループのみをターゲットし、OSBクラスタにはOSB-MGD-SVRS-ONLYをターゲットし、OWSMにはWSMPM-MAN-SVERサーバー・グループのみをターゲットする必要があります。12.1.3を12.2.11にアップグレードする場合、BAM-MGD-SVRS-ONLYをBAMクラスタにターゲット指定することも必要です。

構成のサマリー

構成のサマリーを確認します。

「再構成」をクリックしてドメインを再構成するか、「戻る」をクリックして構成を変更します。

再構成の進行状況

再構成の進行状況を確認します。処理が完了したら「次へ」をクリックします。

再構成に成功しました

再構成処理の最終的なステータスを確認します。「終了(F)」をクリックして再構成ウィザードを終了します。

4.1.7 SOAコンポーネント構成のアップグレード

WebLogicコンポーネント構成のアップグレード時のUpgrade Assistantの画面を示しています。

注意: 表示される画面は、使用している環境に基づいています。次に示す画面は、すべてが表示されない場合もあります。Upgrade Assistant画面の使用の詳細は、オンライン・ヘルプを参照してください。

注意:

追加の構成タスクが必要になる場合があります。

Upgrade Assistantによるスキーマとコンポーネント構成のアップグレードが正常に完了したら、「アップグレード後のタスクの実行」で説明されているタスクを実行して、コンポーネントが引き続き期待どおりに機能していることを確認する必要がある場合があります。

表4-4 Upgrade Assistant画面: WebLogicコンポーネント構成のアップグレード

画面 説明および必要なアクション

ようこそ

この画面では、アップグレード・アシスタントの概要と、アップグレード前の重要なタスクについての情報が示されます。

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

WebLogicコンポーネント

管理対象WebLogic Serverドメインのコンポーネント構成をアップグレードするには、「ドメインによって使用されるすべての構成」オプションを選択します。アップグレードするドメインのドメイン・ディレクトリを入力してください。

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

OWSMポリシー・マネージャ

この画面は、11g環境に複数のWebLogic Serverドメインがある場合に、OWSMポリシー・マネージャが1つのWLSドメインのみにあり、他のドメインにはOWSMエージェントがあるときに表示されます。

Oracle Web Services Manager (OWSM)ポリシー・マネージャがデプロイされているWebLogic管理サーバー・ドメインの資格証明を指定します。

このページのフィールドの詳細は、「ヘルプ」をクリックするか、OWSMポリシー・マネージャに関する項を参照してください。

コンポーネント・リスト

この画面では、ドメインのコンポーネント構成アップグレードに含められるコンポーネントのリストが提供されます。

前提条件

コンポーネント構成アップグレードの前提条件が満たされているかどうかを確認します。

注意: Upgrade Assistantは、これらの前提条件が実行されたことを確認しません。

UMS構成

この画面は、UMS 11g構成ファイルをホストする、リモートの管理対象サーバーがある場合に表示されます。アップグレード・アシスタントで構成ファイルにアクセスするには、これらのサーバーに資格証明を指定する必要があります。

注意: アップグレード・アシスタントでUMS構成ファイルを見つけられない場合は、それらのファイルを手動でコピーする必要があります。アップグレード・アシスタント: UMS構成ファイルのコピーを参照してください。

調査

各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証するアップグレード・アシスタントのステータスを確認します。

アップグレード・サマリー

スキーマ・アップグレードのために選択したオプションのサマリーを確認します。

「アップグレード」をクリックしてスキーマをアップグレードするか、構成を変更する場合は「戻る」をクリックします。

アップグレードの進行状況

アップグレード処理のステータスを確認します。

アップグレードが完了したら「次へ」をクリックします。

アップグレード成功

アップグレードが成功していれば「閉じる」をクリックします。

アップグレードが失敗した場合または正常に完了する前にアップグレードを取り消した場合は、ログ・ファイルを確認してバックアップ環境をリストアし、アップグレード・アシスタントを再起動する必要があります。

4.2 以前の12cリリースからBusiness Activity Monitoring (BAM) 12c (12.2.1.1)を含むOracle SOA Suiteへのアップグレード

既存の12cデプロイメントに、Business Activity Monitoring (BAM)を含むSOA Suiteが含まれる場合、12c (12.2.1.1)リリースにアップグレードするには、次のタスクを完了する必要があります。

  1. 必須のアップグレード前タスクをすべて完了します。
    このプロセスを開始する前に、アップグレード前タスクを完了します。アップグレード前チェックリストと、デプロイされたアプリケーションによって必須となる場合があるすべてのSOA固有のタスクを参照してください。リストアの必要が生じた場合のために、使用可能な完全なバックアップ・バージョンが存在することを確認します。
  2. Upgrade Assistantを-readinessモードで使用して、アップグレード前の準備状況チェックを実行します。
    12.2.1.1 OracleホームからUpgrade Assistantを起動して、12.1.3または12.2.1ドメインのアップグレードの準備状況を確認します。

    UNIXオペレーティング・システムのユーザーは、12.2.1.1 Oracleホームのoracle_common/upgrade/binに移動します

    次のコマンドを実行します。 ./ua — readiness

  3. Upgrade Assistant 12c (12.2.1.1)を使用して、12.1.3または12.2.1スキーマを12.2.1.1にアップグレードします。
    12.2.1 OracleホームからUpgrade Assistantを起動して、12.1.3または12.2.1スキーマをアップグレードします。

    UNIXオペレーティング・システムでは、ディレクトリをORACLE_HOME/oracle_common/upgrade/binに変更します

    次のコマンドを実行します。 ./ua

    Windowsオペレーティング・システムでは、ディレクトリをORACLE_HOME\oracle_common\upgrade\binに変更します

    次のコマンドを実行します。ua.bat

  4. 標準アップグレード・プロセス「Upgrade Assistantを使用したスキーマのアップグレード」の説明に従って、Upgrade Assistantの各画面を完了します
  5. 再構成ウィザード12c (12.2.1)を使用したドメイン構成のアップグレード
    12.2.1.1 Oracleホームから再構成ウィザードを起動して、12.1.3または12.2.1ドメインをアップグレードします。

    UNIXオペレーティング・システム・ユーザーは、次に移動します。

    12.2.1.1 Oracleホームのoracle_common/common/bin

    次のコマンドを実行します。 ./reconfig.sh

    標準再構成プロセス「再構成ウィザードを使用したドメインの再構成」の説明に従って再構成ウィザード画面を完了します

    重要: 再構成ウィザードの実行時には、次の追加のタスクを完了する必要があります。

    1. 「コンポーネント・データソース」画面で、BAMリース・スキーマの「スキーマ所有者」のフィールドの<prefix>_WLS_RUNTIMEを<prefix>_WLSに変更します。スキーマ所有者名に、DEV_WLS_RUNTIMEが不正確に表示される場合があります。
    2. 「再構成ウィザードを使用したサーバー・グループのターゲット指定」の説明に従って、再構成ウィザードの「管理対象サーバー」画面を完了します

4.3 再構成ウィザードを使用したサーバー・グループのターゲット指定

以前の12cリリースからアップグレードする場合、再構成ウィザードを使用して、適切なサーバー・グループに、サーバーを手動でターゲット指定する必要があります。

以前の12cリリース(たとえば12.1.3)で作成されたドメインをアップグレードする場合、アップグレードのドメイン再構成フェーズで、サーバーを正しいサーバー・グループにターゲット指定する必要があります。これらのサーバーのターゲット指定に失敗すると、アップグレードの失敗や不要なダウンタイムの発生につながることがあります。
  1. 再構成ウィザードを起動します。

    (UNIX) ORACLE_HOME/oracle_common/common/bin

    (Windows) ORACLE_HOME\oracle_common\common\bin

    ORACLE_HOMEはOracleホーム・ディレクトリです。

    (UNIX) ./reconfig.sh -log=<log_file> -log_priority=ALL

    (Windows) reconfig.cmd -log=<log_file> -log_priority=ALL

  2. 「拡張構成」画面に移動し、「管理対象サーバー、クラスタおよびCoherence」を選択します。
    GUID-06E78EBE-D671-49ED-8E1F-CE06C7C72EE9-default.pngの説明が続きます。
    GUID-06E78EBE-D671-49ED-8E1F-CE06C7C72EE9-default.pngの説明
  3. 「管理対象サーバー」画面で「サーバー・グループ」ドロップダウン・メニューから正しいグループ名を選択して、各サーバーを正しいサーバー・グループにターゲット指定します。
    GUID-E96F27A4-74D8-4A33-83E3-1829BDBD98B4-default.pngの説明が続きます。
    GUID-E96F27A4-74D8-4A33-83E3-1829BDBD98B4-default.pngの説明が続きます。

    注意:

    OWSMPMがそれ自身のクラスタにあり、SOAまたはOSBクラスタの一部ではない場合は、SOAクラスタへはSOA-MGD-SVRS-ONLYユーザー拡張可能サーバー・グループのみをターゲット指定し、OSBクラスタへはOSB-MGD-SVRS-ONLYのみをターゲット指定し、OWSMへはWSMPM-MAN-SVERサーバー・グループをターゲット指定してください。12.1.3を12.2.1.1にアップグレードする場合、BAM-MGD-SVRS-ONLYをBAMクラスタにターゲット指定することも必要です。
    コンポーネントとサーバー サーバー・グループ
    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
これで各サーバーは正しいサーバー・グループにターゲット指定されたはずであり、「未指定」とは表示されないはずです。