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

前
次

5 SOA SuiteおよびBusiness Process Management 12c (12.2.1)のアップグレード

この項では、単一ノードの本番SOA SuiteおよびBusiness Process Management 11g本番インストールを、SOA SuiteおよびBusiness Process Management 12c(12.2.1)にアップグレードする詳しい手順について説明します。

注意:

実際の本番環境の完全な作業用コピーを作成し、クローン環境をアップグレードし、アップグレードされたコンポーネントが予想どおりに動作することを確認してから(必ず確認した後で)、本番環境をアップグレードすることをお薦めします。

潜在的なアップグレードの問題をクローン環境で特定しておくと、本番環境で無駄な停止時間を排除できます。

アップグレードを開始する前に、次の(およびその他すべての)必須のアップグレード前手順を完了します。詳細は、「Oracle Fusion Middleware 12cアップグレード前チェックリスト」および「SOA固有のアップグレード前タスクの実行」を参照してください。

5.1 Oracle SOA SuiteおよびBusiness Process Management 12cのインストール

既存のSOAおよびBusiness Process Management (BPM) 11gのコンポーネントをアップグレードする前に、まず、SOA SuiteおよびBusiness Process Management 12c (12.2.1)ディストリビューションをインストールする必要があります。『Oracle SOA SuiteおよびBusiness Process Managementのインストールと構成』で説明されている手順に従ってください。

注意:

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

インストール・プロセス中に、新しくインストールしたドメインを構成するように指示されます。ただし、アップグレードの際、SOA 12.2.1ドメインの構成に構成ウィザードは使用しないでください。構成ウィザードは新しいドメインのインストールを構成するために使用します。既存のドメインは、アップグレード中にこのガイドで後述する再構成ウィザードを使用してアップグレードします。

5.2 SOAINFRAスキーマのアップグレード中のログ・ファイルの生成(推奨)

アップグレードのトラブルシューティングを容易にするために、_SOAINFRA スキーマのアップグレード時にログ・ファイルを生成することをお薦めします。デフォルトでは、ロギングは無効になっています。

ロギングを有効化するには:

  1. soainfraユーザー・ディレクトリをUPGRADE_DIRという名前で作成します。
  2. set_LogLevel(1)または ALTER PROCEDURE log_debug COMPILE PLSQL_CCFLAGS = 'debug_on:TRUE';関数を呼び出して、デバッグ・ログを有効化します。

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

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

ログ・ファイルの生成および使用の詳細は、オプションの引数を使用したアップグレード・アシスタントの起動に関する項を参照してください。

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

Upgrade Assistantとスキーマをアップグレードするには、このタスクに従います。

5.3.1 Upgrade Assistantを使用したスキーマのアップグレードについて

Upgrade Assistantには、スキーマをアップグレードするオプションが、「個別に選択されたスキーマ」「ドメインで使用されるすべてのスキーマ」の2つ用意されています。

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

このオプションを使用すると、アップグレードするコンポーネント・スキーマを選択できます。アップグレードしないコンポーネント・スキーマがドメイン内にある場合、このオプションを使用します。

たとえば、ドメインの外部にあるRCUを使用してスキーマを作成してUpgrade Assistantを試行してから、Upgrade Assistantを使用してこれらをアップグレードします。

ドメインで使用されるすべてのスキーマ

このオプションを使用すると、Upgrade Assistantが指定されたドメイン内で使用可能なスキーマをすべて検出し、これらをアップグレードに含めることができるようになります。

5.3.2 Upgrade Assistantでアップグレードできるスキーマの識別

Upgrade Assistantは、アップグレードできるすべてのスキーマを識別してアップグレードに含めます。アップグレードするスキーマを選択することもできます。アップグレードを開始する前に、利用できるスキーマのリストをチェックするには、スキーマ・バージョン・レジストリを問い合せます。

ヒント:

スキーマ・バージョン・レジストリから収集した情報を対応するスキーマと比較し、まだアップグレードできないスキーマがドメイン内にあるかどうかを確認します。

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 ;

SQLスクリプト(version.sqlなど)に保存されると、次のレポートが生成されます。

VERSIONの数値が11.1.1.6.0以上で、STATUS列がVALIDであれば、そのスキーマはアップグレードでサポートされます。

あるスキーマでアップグレードの必要がない場合、schema_version_registry表には、12.2.1アップグレード後もアップグレード前のバージョンでそのスキーマが保持されます。

アップグレードが必要なスキーマに関する注意

  • ほとんどのコンポーネントで、アップグレードできるスキーマ・バージョンの開始点は、11gリリース1 (11.1.1.6、1.1.1.7、11.1.1.8または11.1.1.9)または12c (12.1.2または12.1.3)のみです。スキーマが、サポートされているバージョンでない場合、12c (12.2.1)のアップグレード手順を使用する前に、それらをアップグレードする必要があります。

    Oracle Enterprise Data QualityやOracle Golden Gate Veridataなど、一部のコンポーネントでは、サポートされている標準的なOracle Fusion Middlewareバージョン以外のバージョンからのアップグレードがサポートされています。

    アップグレードに必要なスキーマに関する追加情報は、コンポーネント固有のインストールおよびアップグレードのドキュメントを参照してください。

  • 11gでファイルベースのポリシー・ストアを使用していた場合、Upgrade Assistantを実行する前に、ファイルベースのポリシー・ストアをデータベースベースのセキュリティ・ストアに再度関連付ける必要があります。

    詳細は、「アップグレード前のファイルベースのポリシー・ストアの再関連付け」を参照してください。

  • 11gでOIDベースのポリシー・ストアを使用していた場合は、アップグレード前に新しい12c OPSSスキーマが作成済であることを確認してください。

  • Oracle Fusion Middleware 12c (12.2.1)リリースでアップグレード可能な製品のスキーマのみをアップグレードできます。まだ12c (12.2.1)へのアップグレードが可能になっていないコンポーネントを含むドメインをアップグレードしないでください。

5.3.3 Upgrade Assistantの起動

Upgrade Assistantは、スキーマ、コンポーネント構成およびスタンドアロンのシステム・コンポーネントをアップグレードするために使用されます。

他のドメインのアップグレードを開始する前に、単一のドメインのスキーマのアップグレードおよびコンポーネント構成を正常に完了させることをお薦めします。

注意:

Upgrade Assistantは可能であればいつでも、SYSDBA以外のユーザーが実行する必要があります。SYSDBA以外のユーザーを作成する手順は、「アップグレード前のチェックリスト」で説明されています。
Upgrade Assistantを起動するには、次の手順に従います。
  1. Unixオペレーティング・システムでは、ディレクトリをORACLE_HOME/oracle_common/upgrade/binに変更します。
    Windowsオペレーティング・システムでは、ディレクトリをORACLE_HOME\oracle_common\upgrade\binに変更します。
  2. 次のコマンドを入力して、アップグレード・アシスタントを起動します。

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

    ./ua

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

    ua.bat

    Upgrade Assistantの各画面で必要な情報を指定します。表示される画面は、選択するアップグレードのタイプによって異なります。

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

スキーマのアップグレード時、アップグレード・アシスタントでは表5-1に示す一連の画面が表示されます。各画面でそれぞれの操作を実行します。「Oracle SOA」を選択すると、アップグレードには_IAU_MDS _OPSS_SOAINFRAおよび_UMSスキーマが含まれます。

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

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

ようこそ

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

スキーマ

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

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

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

たとえば、「Oracle SOA」を選択すると、アップグレードには_MDSおよび_UMSスキーマが含まれます。

Managed File Transferが選択された場合、監査サービス、Enterprise SchedulerおよびPlatform Security Servicesがアップグレードに含まれます。

img/GUID-C60649BE-E01A-4571-982C-090AA493C64B-default.png

ドメイン・ディレクトリ

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

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

前提条件

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

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

スキーマ資格証明

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

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

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

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

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

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

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

注意:

  • _OPSS_IAU _MDSおよび_ODIのスキーマには、昇格したログイン資格証明(AS SYSDBA)が必要です

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

  • データベースへの接続に必要なフィールドの詳細は、「ヘルプ」をクリックするか、スキーマ資格証明に関する項を参照してください。

調査

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

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

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

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

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

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

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

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

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

アップグレード成功

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

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

5.3.5 スキーマのアップグレードの確認

次のSQLコマンドを使用して、schema_version_registryのスキーマ・バージョンが正しく更新されていることを検証します。

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列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。「アップグレードが必要なスキーマ」を参照して、スキーマの更新されたバージョン番号が正しいことを確認します。

問合せ結果のSTATUSフィールドは、スキーマへのパッチ適用処理中は「UPGRADING」または「UPGRADED」に、処理が終了すると「VALID」になります。

ステータスが「INVALID」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。

5.3.6 インスタンスのアップグレードの確認(該当する場合)

スキーマのアップグレードの一部としてインスタンスをアップグレードした場合は、インスタンスにエラーがないことを確認します。

  • アップグレード・アシスタントのレポートに、アップグレード対象のインスタンスが存在しなくなったと示された場合は、アップグレード・アシスタントのUIを閉じて、残りのアップグレード手順(再構成ウィザードを起動するなど)を続行します。

  • アップグレード・アシスタントのレポートに、インスタンスのアップグレード中にエラーが発生したと示されている場合は、エラーを修正してからデータベース・ジョブを再発行して、アップグレードを完了します。Report Upgrade Summary管理スクリプト(オプション1)を使用して、レポートのUPGRADE ERROR COUNTセクションを確認することもできます。詳細は、「インスタンス・アップグレードのエラーの解決」を参照してください。

  • アップグレード対象のクローズされたインスタンスが残っている場合は、アップグレード・アシスタントの終了後に、クローズされたインスタンスのアップグレードがバックグラウンドで続行されることが通知されます。アップグレード・アシスタントが完了を報告し、次のメッセージが表示されるまでは、アップグレード・アシスタントを閉じないでください。

    Oracle SOA
    1. The Upgrade Assistant has successfully upgraded all active instances. You can now close the Upgrade Assistant.
    2. The automated upgrade of closed instances will continue in the background after the Upgrade Assistant is exited and until the SOA server is started,at which point the upgrade will stop. You can schedule the upgrade of any remaining closed instances for a time when the SOA server is less busy.
    Close the Upgrade Assistant and use the instance data administration scripts to administer and monitor the overall progress of this automated upgrade. For more information see "Administering and Monitoring the Upgrade of SOA Instance Data" in Upgrading SOA Suite and Business Process Management. 

5.3.7 無効なデータベース・オブジェクトの確認

Oracle Databaseを使用している場合は、アップグレード・アシスタントを実行した後、SYSとしてデータベースに接続し、SQL*Plusから次の方法を実行することで、データベース・オブジェクトを再コンパイルしてください。

SQL>@?/rdbms/admin/utlrp.sql

これによって、アップグレード・アシスタントによってアップグレードされたデータベース・オブジェクトがコンパイルされます。

その後、次の問合せを発行して、無効なデータベース・オブジェクトがなくなったことを確認します。

SELECT owner, object_name FROM all_objects WHERE status='INVALID';

この時点では、アップグレードされたスキーマに、無効になっているデータベース・オブジェクトはないはずです。もしあった場合は、utlrp.sqlコマンドをもう一度実行して再確認します。問題が続く場合は、サービス・リクエストを提出します。

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

再構成ウィザードは、12cの新しいツールです。ドメインの12cへのアップグレードは、Upgrade Assistantと組み合せて実行されます。

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

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

  • ドメイン・バージョン

注意:

再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。
具体的には、ドメインを再構成する場合、次のことが発生します。
  • ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンのメジャーおよびマイナー・バージョン番号(たとえば、12.2.1.1)に更新されます。

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

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

注意:

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

再構成ウィザードを使用して既存のドメインを変更するには、次の説明に従ってください。ドメイン再構成の一般情報については、WebLogicドメインの再構成に関する項を参照してください。

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

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

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

5.4.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はOracleホーム・ディレクトリです。

  5. 次のコマンドを実行します。
    (UNIX Operating Systems) ./reconfig.sh -log=<log_file> -log_priority=ALL
    (Windows Operating Systems) 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

5.4.3 ドメインの再構成

再構成ウィザードでは表5-2 に示す一連の画面が表示されます。各画面でそれぞれの操作を実行します。次に示す画面は、いくつかが表示されないこともあります。また、使用する環境の設定に基づいた追加の画面を完了する必要がある場合もあります。詳細は、WebLogicドメインの再構成に関する項を参照してください。

表5-2 再構成ウィザードの画面

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

ドメインの選択

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

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

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

ドメイン・モードおよび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データ・ソース」画面で構成したデータ・ソース接続をテストします。

このページのフィールドの詳細は、「ヘルプ」をクリックするか、JDBCデータ・ソースのテストに関する項を参照してください。

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

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

注意:

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

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

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にアップグレードする場合、サーバーを適切なサーバー・グループに割り当てる必要があります。

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

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

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

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

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

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

注意:

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

構成のサマリー

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

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

再構成の進行状況

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

再構成に成功しました

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

5.5 アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード

Upgrade Assistantを使用して、残りのドメイン内WebLogicコンポーネント構成をすべて更新します。

アップグレード・アシスタントを使用して追加ドメイン・コンポーネント構成をアップグレードするには、次の各項の手順に従います。

注意:

アップグレード・アシスタントを起動する前に、管理サーバーを起動しないでください。

5.5.1 Upgrade Assistantの起動

Upgrade Assistantは、スキーマ、コンポーネント構成およびスタンドアロンのシステム・コンポーネントをアップグレードするために使用されます。

他のドメインのアップグレードを開始する前に、単一のドメインのスキーマのアップグレードおよびコンポーネント構成を正常に完了させることをお薦めします。

注意:

Upgrade Assistantは可能であればいつでも、SYSDBA以外のユーザーが実行する必要があります。SYSDBA以外のユーザーを作成する手順は、「アップグレード前のチェックリスト」で説明されています。
Upgrade Assistantを起動するには、次の手順に従います。
  1. Unixオペレーティング・システムでは、ディレクトリをORACLE_HOME/oracle_common/upgrade/binに変更します。
    Windowsオペレーティング・システムでは、ディレクトリをORACLE_HOME\oracle_common\upgrade\binに変更します。
  2. 次のコマンドを入力して、アップグレード・アシスタントを起動します。

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

    ./ua

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

    ua.bat

    Upgrade Assistantの各画面で必要な情報を指定します。表示される画面は、選択するアップグレードのタイプによって異なります。

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

WebLogicコンポーネント構成のアップグレード時、アップグレード・アシスタントでは表5-3 に示す一連の画面が表示されます。各画面でそれぞれの操作を実行します。

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

注意:

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

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

表5-3 アップグレード・アシスタント画面: 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構成ファイルのコピーを参照してください。

調査

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

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

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

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

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

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

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

アップグレード成功

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

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

5.6 Oracle Business Process Managment (BPM) Webフォームのアップグレード

Oracle Business Process Management (BPM) 11g (11.1.1.7.0)で開発されたBPM Webフォームは、ほとんどが12cと互換性があります。少数ですが要素間に手動で空白を指定している場合があり、そのようなフォームは、12cで正しく動作しない可能性があります。これらのフォームは手動でアップグレードする必要があります。手動の操作がない場合、これらのフォームは一時停止モードになります。これらの手動によるレイアウトを使用しないフォームは、移行なしで正しく動作します。

BPM Webフォームをアップグレードするには、管理権限のあるユーザーが次のURLに移動し、プロンプトが表示されたら管理者資格証明を入力します。

http://hostname:port/workflow/DefaultToDoTaskFlow/migratewebforms

このページをロードすることでアップグレードが開始され、アップグレードされたフォームが表示されます。エラーが発生した場合は、ログ・ファイルを確認し、エラーがリカバリできる場合はページのロードを再試行します。エラーがリカバリできない場合は、エラーが発生したフォームが含まれるBPMコンポジットのデプロイを試行します。

注意:

このURLは何度でも起動できますが、Webフォームを使用しているアクティブ・ユーザーがいるときにはアップグレードは実行できません。

5.7 アップグレードしたOracle Fusion Middleware 12cソフトウェアの管理

表5-4に、Oracle SOA SuiteおよびBusiness Process Management 12c (12.2.1)にアップグレードした後で実行することが多いいくつかの一般的な管理タスクをリストします。また、コンポーネント固有の管理ガイドでは、アップグレード後に実行する追加の構成タスクについても説明している場合があります。


表5-4 基本的な管理タスク

タスク 説明 詳細

コンポーネントの追加のアップグレード後構成手順の実行

「アップグレード後のタスクの実行」で説明しているアップグレード後のタスクに加えて、追加の構成タスクを実行して、新しくアップグレードしたコンポーネントが期待どおりに機能するかどうかを確認する必要もあります。

  • 『Oracle Fusion Middlewareの管理』

  • Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理

  • Oracle Service Busの管理

  • Oracle User Messaging Serviceの管理

Fusion Middleware管理ツールについての学習

環境の管理に使用できる各種ツールについて習熟します。

Oracle Fusion Middlewareの管理ツールの概要

Secure Sockets Layer (SSL)の構成

Oracle Fusion Middlewareコンポーネント間で、SSLを使用したセキュアな通信を設定する方法について学習します。

Oracle Fusion MiddlewareでのSSLの構成

Oracle Fusion Middlewareのモニタリング

Oracle Fusion Middlewareコンポーネントのステータスを追跡する方法を学習します。

Oracle Fusion Middlewareのモニタリング