プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle Fusion Middleware Infrastructureへのアップグレード
12c (12.2.1.2)
E82835-01
目次へ移動
目次
前
前 		次
次へ

3 Oracle Fusion Middleware Infrastructureのアップグレード(11gから)

Oracle Fusion Middleware Infrastructureは、Oracle Fusion Middlewareリリース11gから12c (12.2.1.2)にアップグレードできます。

アップグレードを実行するために、次に示す各トピックの手順を完了します。

3.1 Oracle Fusion Middleware Infrastructureのアップグレード・プロセス(11gから12c)について

Oracle Fusion Middleware Infrastructureのアップグレード・プロセス(11gから12c)の概要に関するフローチャートとロードマップを確認します。

図3-1 Oracle Fusion Middleware Infrastructureのアップグレード・プロセス・フローチャート(11gから12c)

図3-1の説明が続きます
「図3-1 Oracle Fusion Middleware Infrastructureのアップグレード・プロセス・フローチャート(11gから12c)」の説明

表3-1は、Oracle Fusion Middleware Infrastructureリリース12.2.1.2へのアップグレードの際に実行する必要のある手順の概要リストです。

表3-1 Oracle Fusion Middleware Infrastructureをアップグレードするためのタスク(11gリリースから)

タスク 説明

省略可能

Oracle Fusion Middleware Infrastructure 12.2.1.2へのアップグレード方法に影響する可能性がある、相互運用性と互換性に関する要因について理解します。

サポートされるOracle Fusion Middleware構成で、同一バージョンまたは異なるバージョンの2つ以上のOracle Fusion Middleware製品の連携(相互運用)方法を理解することが重要です。

相互運用性と互換性の詳細は、『Oracle® Fusion Middleware相互運用性および互換性の理解』を参照してください。

必須

このガイドの概要に関するトピックを確認して、必須のアップグレード前タスクを完了します(まだ実行していない場合)。

アップグレード前タスクには、ご使用の本番環境のクローニング、システム要件および資格証明の確認、未使用データのパージおよび非SYSDBAユーザーの作成が含まれます。

アップグレード前タスクの完全なリストは、Oracle Fusion Middlewareアップグレード前チェックリストを参照してください。

必須

12.2.1.2 Fusion Middleware Infrastructureディストリビューションをダウンロードしてインストールします。

Infrastructureのディストリビューションには、その他のFusion Middleware製品をインストールするための基盤の設定に必要な、WebLogic ServerおよびJava Required Files (JRF)が同梱されています。

このガイドのアップグレード・トポロジに定義されているように、インフラストラクチャは新規のOracleホームにインストールする必要があります。そのために、「Oracle Fusion Middleware Infrastructureのインストール」で説明する手順を実行してください。

必須

必要な12cスキーマを作成します。

11gリリースからアップグレードする場合、RCUを使用して必要なスキーマを作成する必要があります。Oracle Fusion Middleware 11gと異なり、サポートされているデータベースに必要なスキーマをインストールしないと、Oracle Fusion Middleware 12cドメインを構成することはできません。

省略可能

準備状況チェックを実行します。

「アップグレード前の準備状況チェックの実行」を参照してください。

必須

サーバーとプロセスを停止します

アップグレード・プロセスの開始前に、すべてのサーバー、コンポーネントおよびプロセスを停止します。

「サーバーとプロセスの停止」を参照

必須

再構成ウィザードを使用して、12.2.1.xドメインを再構成します。

既存のドメインで再構成ウィザードを実行した場合、再構成テンプレートを選択および適用することで、ドメインのアップグレード準備が行われます。これにより、ドメイン内に存在するJDBCデータ・ソースとコンポーネント・スキーマのテストも実行します。

ドメインを再構成するには、「ドメインの再構成」で説明する手順を実行します。

必須

Upgrade Assistantを使用して、12.2.1.xドメインの構成をアップグレードします。

12.2.1.xドメインの再構成後には、Upgrade Assistantを実行して、12.2.1.xドメインで使用されている構成をすべてアップグレードする必要があります。

ドメイン内でアップグレードの対象になるすべてのコンポーネントは、Upgrade Assistantの実行時に、「コンポーネント・リスト」画面で確認できます。手順の詳細は、「ドメイン・コンポーネント構成のアップグレード」を参照してください。

必須

サーバーおよびプロセスを再起動します。

アップグレード・プロセスは完了です。この時点で、サーバー、コンポーネントおよびプロセスを再起動できます。

「サーバーとプロセスの起動」を参照してください。

必須

アップグレード後のタスクを実行します。

アップグレード後のタスクのリストは、「アップグレードの検証チェックリストの使用」を参照してください。

既存の環境がクラスタ構成の場合は必須

プライマリ・ノードの既存のドメインをパックします。

pack.sh|cmdスクリプトを実行して、プライマリ・ノードのdomaintemplate.jarファイルに既存のドメインをパックします。既存の環境がクラスタ構成の場合を参照してください

既存の環境がクラスタ構成の場合は必須

ドメインのtemplate.jarファイルをセカンダリ・ノードにコピーします。

domaintemplate.jarファイルをセカンダリ・ノードにコピーして、セカンダリ・ノードにファイルの内容を解凍できるようにします。既存の環境がクラスタ構成の場合を参照してください

既存の環境がクラスタ構成の場合は必須

セカンダリ・ノードにjarファイルを解凍します

unpack.sh|cmdスクリプトを実行して、セカンダリ・ノードにdomaintemplate.jarファイルを解凍します。既存の環境がクラスタ構成の場合を参照してください

既存の環境がクラスタ構成の場合は必須

サーバーおよびプロセスを再起動します。

アップグレード・プロセスは完了です。この時点で、サーバー、コンポーネントおよびプロセスを再起動できます。

「サーバーとプロセスの起動」を参照してください。

3.2 Oracle Fusion Middleware Infrastructureのインストール

Fusion Middleware Infrastructureをインストールすると、Oracleホーム・ディレクトリが作成され、その他のFusion Middleware製品をインストールするためのサポート・ソフトウェアが配置されます。

12c (12.2.1.2)のサポート対象JDKバージョンは、1.8.0_101です。最新のJDKバージョンにアップグレードしてから、12c (12.2.1.2)ソフトウェアをインストールしてください。

注意:

以前の12cリリース(12.1.3.0、12.2.1.0または12.2.1.1)からアップグレードする場合は、Oracleホームに12c (12.2.1.2)ディストリビューションをインストールする必要があります。このアップグレードには、既存のOracleホームを再使用しないでください。12c (12.2.1.2)へのアップグレードは、パッチ・リリースではありません。
Oracle Fusion Middleware Infrastructureディストリビューションをインストールするには:
  1. 12c (12.2.1.2)の製品ディストリビューションをインストールするターゲット・システムにサインインします。
  2. Oracle Technology NetworkまたはOracle Software Delivery Cloudから、ターゲット・システムにOracle Fusion Middleware Infrastructure (fmw_12.2.1.2.0_infrastructure_generic.jar)をダウンロードします。
  3. 12c (12.2.1.2)の製品ディストリビューションをダウンロードしたディレクトリに移動します。
  4. Oracle Fusion Middleware Infrastructureのインストール・プログラムを起動します。
    • (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.2.0_infrastructure_generic.jar
    • (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.2.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. 「インストール・タイプ」画面で「Fusion Middlewareインフラストラクチャ」を選択し、「次へ」をクリックします。
  10. 「前提条件チェック」画面では、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
    確認されたタスクのリストを表示するには、「正常なタスクの表示」を選択します。ログの詳細を表示するには、「ログの表示」を選択します。前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。エラー・メッセージや警告メッセージを無視してインストールを続けるには、「スキップ」をクリックします(非推奨)。
  11. 「セキュリティ更新」画面で、My Oracle Supportアカウント情報を入力すると、最新の製品情報およびセキュリティ・アップデートをMy Oracle Supportアカウントを介して受け取ることができます。
    この画面は、ホスト上にOracle製品を初めてインストールすると表示されます。
    Oracle Supportアカウントを所有していない場合、この手順をスキップするには、チェック・ボックスの選択を解除し、フォローアップのダイアログ・ボックスで選択内容を確認します。
  12. 「インストールの概要」画面で、選択したインストール・オプションを確認します。
    これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルには、入力したすべての情報が収集して格納され、後で(コマンドラインから)サイレント・インストールを実行するために使用できます。

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

  13. 「インストールの進行状況」画面で、プログレス・バーの表示が100%になったら、「終了」クリックしてインストーラを閉じるか、「次へ」をクリックしてサマリーを確認します。
  14. 「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。情報を確認し、「終了」をクリックしてインストーラを閉じます。

3.3 RCUを使用した必要な12cスキーマの作成

11gからアップグレードする場合は、アップグレードの開始前に、リポジトリ作成ユーティリティ(RCU)を使用して必要な12cスキーマを作成する必要があります。

注意:

以前の12cリリースのOracle Fusion Middlewareからアップグレードする場合は、これに該当するスキーマを再作成する必要はありません(そのスキーマが存在している場合)。ドメインの既存のスキーマを特定するには、次の手順を参照してください。

11gからアップグレードする場合は、「アップグレード前チェックリスト」を参照してドメインに既存のスキーマを特定します。12cにアップグレードする前に、次のスキーマが存在している必要があります。

  • サービス表スキーマ(prefix_STB)。このスキーマは12cで新規のものであり、ドメインベースのアップグレードに必要になります。基本的なスキーマ構成情報(スキーマ接頭辞やパスワードなど)が格納され、他のOracle Fusion Middlewareコンポーネントはドメイン作成中にこれにアクセスして使用できます。このスキーマはリポジトリ作成ユーティリティ(RCU)を実行するときに自動的に作成され、ここで他の11gスキーマに使用した既存のスキーマ所有者接頭辞を指定します。注意: サービス表スキーマが存在しない場合、UPGAST-00328: スキーマ・バージョンのレジストリ表はこのデータベースに存在しません。その場合、アップグレード・アシスタントを実行するためにはサービス表スキーマを作成する必要があります。というエラー・メッセージが表示されることがあります。

  • Oracle Platform Security Services (OPSS)スキーマ(prefix_OPSS)。このスキーマは、11gでOIDベースのセキュリティ・ストアを使用している場合に必要です。このスキーマは、リポジトリ作成ユーティリティ(RCU)の実行時に自動的に作成されます。LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directory (OID)のみです。LDAPベースのポリシー・ストアは、通常、本番環境で使用します。アップグレード前に、OIDベースのセキュリティ・ストアを再関連付けする必要はありません。アップグレード・アシスタントの実行中に、OPSSスキーマを選択できます。アップグレード・アシスタントは、OIDベースのセキュリティ・ストアを自動的にアップグレードします。注意: 12c OPSSデータベース・スキーマが必要なのは、ドメインの再構成時に12cスキーマを参照するためです。ドメインでは、アップグレード完了後にOIDベースのセキュリティ・ストアが引き続き使用されます。

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.2)の場合、動作保証されているJDKは1.8.0_101以降です。
    JAVA_HOME環境変数が、動作保証済JDKの場所に設定されていることを確認します。次に例を示します。
    • (UNIX) setenv JAVA_HOME /home/Oracle/Java/jdk1.8.0_101
    • (Windows) set JAVA_HOME=C:\home\Oracle\Java\jdk1.8.0_101
    $JAVA_HOME/binを$PATHに追加します。
  3. oracle_common/binディレクトリに移動します。
    • (UNIX) ORACLE_HOME/oracle_common/bin
    • (Windows) ORACLE_HOME\oracle_common\bin
  4. RCUを起動します。
    • (UNIX) ./rcu
    • (Windows) rcu.bat
  5. 「ようこそ」画面で「次へ」をクリックします。
  6. 「リポジトリの作成」画面で「リポジトリの作成」を選択し、「システム・ロードおよび製品ロード」を選択します。
    DBA権限を持っていない場合は、「システム・ロードに対するスクリプトの準備」を選択します。これにより、SQLスクリプトが生成されます。このスクリプトには、RCUが選択されたコンポーネントに対してアクションを実行するときにコールするものと同じSQL文とブロックがすべて含まれています。このスクリプトが生成された後は、必要なSYSまたはSYSDBA権限を持つユーザーが、このスクリプトを実行してシステム・ロード・フェーズを完了できます。

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

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

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

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

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

    examplehost.exampledomain.com

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

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

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

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

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

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

    「標準」またはSYSDBA

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

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

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

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

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

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

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

    ドロップダウン・リストから「はい」または「いいえ」を選択します。
    サーバー名 データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。

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

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

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

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

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

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

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

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

アップグレードにかかわる潜在的な問題を特定するために、準備状況チェックを実行してから、アップグレード・プロセスを開始するようにしてください。準備状況チェックによって、アップグレードにかかわる潜在的な問題をすべて検出できるわけではない点に注意してください。準備状況チェックのレポートが成功を示していても、アップグレードが失敗することもあります。

3.4.1 アップグレード前の準備状況チェックの実行について

-readinessモードでUpgrade Assistantを実行すると、実際のアップグレードを実行する前に問題を検出できます。Upgrade Assistantを使用すると、準備状況チェックはGUIモードで実行できます。また、レスポンス・ファイルを使用するとサイレント・モードで実行できます。 

Upgrade Assistantの準備状況チェックは、サポート対象の開始ポイントにあるFusion MiddlewareのスキーマとWebLogicドメインの構成について、読取り専用のアップグレード前確認を実行します。この確認は、読取り専用の操作です。

準備状況チェックでは、フォーマットされ、タイムスタンプの付けられた準備状況レポートが生成され、実際のアップグレードを試みる前に潜在的な問題に対処できます。問題が検出されない場合は、アップグレード・プロセスを開始できます。アップグレードを実行する前に、このレポートを詳細に確認することをお薦めします。

準備状況チェックは、既存のOracle Fusion Middlewareドメインがオンライン(他のユーザーがアクティブに使用している間)であっても、オフラインであっても実行できます。

準備状況チェックは、実際のアップグレードの実行前に、何度でも実行できます。ただし、アップグレードの実行後には、準備状況チェックを実行しないでください。これは、レポートの結果が、アップグレード前の準備状況チェックとは異なることがあるためです。

注意:

パフォーマンスへの影響を回避するために、準備状況チェックはピーク時以外に実行してください。

3.4.2 準備状況モードでのUpgrade Assistantの起動

-readinessパラメータを使用して、準備状況モードでUpgrade Assistantを起動します。

Upgrade Assistantを使用して、アップグレード前の環境に対して準備状況チェックを実行するには:
  1. oracle_common/upgrade/binディレクトリに移動します。
    • (UNIX) ORACLE_HOME/oracle_common/upgrade/bin
    • (Windows) ORACLE_HOME\oracle_common\upgrade\bin
  2. Upgrade Assistantを起動します。
    • (UNIX) ./ua -readiness
    • (Windows) ua.bat -readiness

    注意:

    DISPLAY環境変数がGUIモードを有効にするように適切に設定されていないと、次に示すエラーが発生することがあります。
    Xlib: connection to ":1.0" refused by server
Xlib: No protocol specified

    この問題を解決するには、DISPLAY環境変数をローカル・ワークステーションのシステム名またはIPアドレスに設定して、Upgrade Assistantを再実行します。

    このようなエラーがDISPLAYの設定後にも続く場合は、別のGUIツール(vncconfigなど)を起動してみてください。同じエラーが表示される場合は、DISPLAY環境変数の設定に間違いが残っている可能性があります。

    その他のコマンドラインに指定可能なパラメータの詳細は、次の項を参照してください。

3.4.2.1 Upgrade Assistantのコマンドライン・パラメータ

コマンドラインからUpgrade Assistantを起動するときには、追加のパラメータを指定できます。

表3-6 Upgrade Assistantのコマンドライン・パラメータ

パラメータ 必須/省略可能 説明

-readiness

 準備状況チェックの場合は必須

注意: 準備状況チェックは、スタンドアロンのインストール(WebLogic Serverで管理されていないインストール)に対して実行できません。

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

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

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

-threads

 省略可能

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

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

-response

サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須

レスポンス・ファイルに保存した入力を使用して、Upgrade Assistantを実行します。このレスポンス・ファイルは、GUIモードでUpgrade Assistantを実行したときの入力データから生成されます。このパラメータを使用すると、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) ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

(Windows) ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

省略可能

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

3.4.3 Upgrade Assistantを使用した準備状況チェックの実行

Upgrade Assistantの各画面を通じて、アップグレード前の準備状況チェックを完了します。

準備状況チェックは、サポートされるアップグレードの開始点にあるスキーマまたはコンポーネント構成に対してのみ実行されます。
準備状況チェックを完了するには:
  1. 「ようこそ」画面で、準備状況チェックに関する情報を確認します。「次」をクリックします。
  2. 「準備状況チェック・タイプ」画面で、実行する準備状況チェックを選択します。
    • 「個別に選択されたスキーマ」: アップグレード前に確認するスキーマを個別に選択できます。準備状況チェックは、スキーマがアップグレードに対応しているかどうか、またはアップグレードが必要かどうかを報告します。

      このオプションを選択すると、画面名が「選択したスキーマ」に変更されます。

    • 「ドメイン・ベース」: Upgrade Assistantは、「ドメイン・ディレクトリ」フィールドで指定されたドメイン内で、アップグレード可能なスキーマまたはコンポーネントのすべてを検出して選択するようになります。

      このオプションを選択すると、画面名が「スキーマおよび構成」に変更されます。

      すべてのスキーマとコンポーネント構成をUpgrade Assistantでチェックする場合は、デフォルトの選択を変更しないで使用します。それ以外の場合は、次に示す特定のオプションを選択します。

      • 「すべてのスキーマのチェックを含める」: アップグレードに対応したコンポーネントをすべて検出して確認します。

      • 「すべての構成のチェックを含める」: 管理対象WebLogic Serverドメインのコンポーネント構成を確認します。

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

  3. 「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、アップグレードに対応可能なスキーマを持つコンポーネントを選択して、準備状況チェックの実行対象にします。

    依存コンポーネントのあるコンポーネントを選択すると、該当するコンポーネントが自動的に選択されます。たとえば、Oracle Platform Security Servicesを選択すると、Oracle Audit Servicesが自動的に選択されます。

    選択したコンポーネントによっては、追加の画面が表示されることがあります。たとえば、次のような作業が必要になることがあります。

    • ドメイン・ディレクトリを指定します。

    • 選択したスキーマに接続するために、次のスキーマ資格証明を指定します: 「データベース・タイプ」、「DBAユーザー名」および「DBAパスワード」。次に、「接続」をクリックします。

      注意

      Oracleデータベースは、デフォルトのデータベース・タイプです。データベース・タイプに間違いがないことを確認してから続行してください。間違ったデータベースを選択していることに気付いた場合でも、正しいタイプに変更するために、この画面に戻らないでください。そのかわりに、Upgrade Assistantを終了してから、正しいデータベース・タイプを選択した状態で準備状況チェックを再開し、すべてのスキーマに正しいデータベース・タイプが適用されるようにします。

    • 「スキーマ・ユーザー名」を選択して、「スキーマ・パスワード」を指定します。

    「次」をクリックして、準備状況チェックを開始します。
  4. 「準備状況サマリー」画面で、選択内容に基づいて実行された準備状況チェックのサマリーを確認します。
    選択内容を保存して、今後、レスポンス(サイレンス)モードでUpgrade Assistantを再実行する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所と名前を指定します。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。
    詳細レポートを表示するには、「ログの表示」をクリックします。
    「次へ」をクリックします。
  5. 「準備状況チェック」画面で、準備状況チェックのステータスを確認します。このプロセスには、数分かかることがあります。
    複数のコンポーネントをチェックしている場合、それぞれのコンポーネントの進行状況は、それぞれ専用のプログレス・バーで同時に表示されます。
    準備状況チェックが完了したら、「続行」をクリックします。
  6. 「準備状況の終了」画面で、準備状況チェックの結果(「準備状況成功」または「準備状況失敗」)を確認します。

    • 準備状況チェックが成功した場合は、「準備状況レポートの表示」をクリックして完全なレポートを確認します。準備状況チェックが成功した場合でも、実際のアップグレードを実行する前に、準備状況レポートを確認するようにしてください。「検索」オプションは、レポート内の特定の語句を検索する際に使用します。また、このレポートには、完成した準備状況チェック・レポート・ファイルが格納されている場所も示されます。

    • 準備状況チェックで問題またはエラーが発生した場合は、「ログの表示」をクリックしてログ・ファイルを確認し、問題を特定して修正してから、準備状況チェックを再開します。ログ・ファイルは、設定したコマンドライン・オプションによって管理されます。

3.4.4 準備状況レポートの理解

目的のドメインに準備状況チェックを実行したら、アップグレードを成功させるために、なんらかの処置を取る必要があるかどうかを判断するためにレポートを確認します。

準備状況レポート・ファイルの形式は、次のとおりです。

readiness_timestamp.txt

timestampは、準備状況チェックが実行された日時を示します。

準備状況レポートには、次に示す情報が含まれています。

表3-7 準備状況レポートの要素

レポートの情報 説明 必要な操作
全体的な準備状況ステータス: SUCCESSまたはFAILURE レポートの上部には、アップグレードの準備状況チェックが成功したか、または1つ以上のエラーが発生して完了したかが示されます。 1つ以上のエラーが発生してレポートが完了した場合、アップグレードを試みる前に、FAILを検索し、障害の原因となった問題を修正します。準備状況チェックは、アップグレードする前に必要に応じて何度でも再実行できます。

タイムスタンプ

レポートが生成された日付と時刻です。

処理は必要ありません。

ログ・ファイルの場所

ORACLE_HOME/oracle_common/upgrade/logs

生成されたログ・ファイルのディレクトリの場所です。

処理は必要ありません。

準備状況レポートの場所

ORACLE_HOME/oracle_common/upgrade/logs

生成された準備状況レポートのディレクトリの場所です。

処理は必要ありません。

チェックされたコンポーネントの名前

チェックに含まれるコンポーネントの名前およびバージョンとステータス。

このリリースにアップグレードできないコンポーネント(SOAコア拡張など)がドメインに含まれる場合は、アップグレードを試みないでください。

チェックされたスキーマの名前

チェックに含まれるスキーマの名前および現在のバージョンとステータス。

スキーマのバージョン番号をレビューします。このリリースにアップグレードできないスキーマがドメインに含まれる場合は、アップグレードを試みないでください。

個別のオブジェクトのテスト・ステータス: FAIL

準備状況チェックのテストで、特定のオブジェクトに問題が検出されています。

失敗した問題がすべて解決するまでアップグレードしないでください。

個別のオブジェクトのテスト・ステータス: PASS

準備状況チェックのテストでは、特定のオブジェクトに問題が検出されませんでした。

準備状況チェック・レポートにPASSステータスのみが表示されている場合、環境をアップグレードできます。ただし、準備状況チェックでは、ハードウェアやアップグレード時の接続性などの外部環境に関する問題を検出することはできません。アップグレードの進捗を常に監視する必要があります。

<オブジェクト>の準備状況チェックの完了ステータス: FAILURE 準備状況チェックで特定のオブジェクト(スキーマ、索引、データ型など)に解決する必要のあるエラーが1つ以上検出されました。 FAILED問題がすべて解決されるまではアップグレードしないでください。
<オブジェクト>の準備状況チェックの完了ステータス: SUCCESS 準備状況チェック・テストによって問題が検出されませんでした。 処理は必要ありません。
準備状況レポート・ファイルのサンプルを次に示します。使用対象のレポートにはこれらすべてのチェックが含まれる場合や含まれない場合があります。 
Upgrade readiness check completed with one or more errors.

This readiness check report was created on Tue May 30 11:15:52 EDT 2016
Log file is located at: ORACLE_HOME/oracle_common/upgrade/logs/ua2016-05-30-11-14-06AM.log
Readiness Check Report File: ORACLE_HOME/oracle_common/upgrade/logs/readiness2016-05-30-11-15-52AM.txt

Starting readiness check of components.

Oracle Metadata Services
   Starting readiness check of Oracle Metadata Services.
     Schema User Name: DEV11_MDS
     Database Type: Oracle Database
     Database Connect String: machinename@yourcompany.com
     VERSION Schema DEV11_MDS is currently at version 12.1.1.1.0.  Readiness checks will now be performed.
   Starting schema test:  TEST_REQUIRED_TABLES  Test that the schema contains all the required tables
   Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS
   Starting schema test:  TEST_REQUIRED_PROCEDURES  Test that the schema contains all the required stored procedures
     EXCEPTION     Schema is missing a required procedure: GETREPOSITORYFEATURES
   Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ FAIL
   Starting schema test:  TEST_REQUIRED_VIEWS  Test that the schema contains all the required database views
   Completed schema test: TEST_REQUIRED_VIEWS --> Test that the schema contains all the required database views +++ PASS
   Starting index test for table MDS_ATTRIBUTES:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
   Completed index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
   Starting index test for table MDS_COMPONENTS:  TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes
   Completed index test for table MDS_TXN_LOCKS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS
   Starting schema test:  TEST_REQUIRED_TRIGGERS  Test that the schema has all the required triggers
   Completed schema test: TEST_REQUIRED_TRIGGERS --> Test that the schema has all the required triggers +++ PASS
   Starting schema test:  TEST_MISSING_COLUMNS  Test that tables and views are not missing any required columns
   Completed schema test: TEST_MISSING_COLUMNS --> Test that tables and views are not missing any required columns +++ PASS
   Starting schema test:  TEST_UNEXPECTED_TABLES  Test that the schema does not contain any unexpected tables
   Completed schema test: TEST_UNEXPECTED_TABLES --> Test that the schema does not contain any unexpected tables +++ PASS
   Starting schema test:  TEST_UNEXPECTED_PROCEDURES  Test that the schema does not contain any unexpected stored procedures
   Completed schema test: TEST_UNEXPECTED_PROCEDURES --> Test that the schema does not contain any unexpected stored procedures +++ PASS
   Starting schema test:  TEST_UNEXPECTED_VIEWS  Test that the schema does not contain any unexpected views
   Completed schema test: TEST_UNEXPECTED_VIEWS --> Test that the schema does not contain any unexpected views +++ PASS
   Starting index test for table MDS_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
   Completed index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
   Completed index test for table MDS_LABELS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS
   Starting index test for table MDS_LARGE_ATTRIBUTES:  TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes
   Starting schema test:  TEST_UNEXPECTED_TRIGGERS  Test that the schema does not contain any unexpected triggers
   Completed schema test: TEST_UNEXPECTED_TRIGGERS --> Test that the schema does not contain any unexpected triggers +++ PASS
   Starting schema test:  TEST_UNEXPECTED_COLUMNS  Test that tables and views do not contain any unexpected columns
   Completed schema test: TEST_UNEXPECTED_COLUMNS --> Test that tables and views do not contain any unexpected columns +++ PASS
   Starting datatype test for table MDS_ATTRIBUTES:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting datatype test for table MDS_COMPONENTS:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Starting permissions test:  TEST_DBA_TABLE_GRANTS  Test that DBA user has privilege to view all user tables
   Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS
   Starting schema test:  TEST_ENOUGH_TABLESPACE  Test that the schema tablespaces automatically extend if full
   Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS
   Starting schema test:  TEST_USER_TABLESPACE_QUOTA  Test that tablespace quota for this user is sufficient to perform the upgrade
   Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS
   Starting schema test:  TEST_ONLINE_TABLESPACE  Test that schema tablespaces are online
   Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS
   Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
     INFO   Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
   Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
   Finished readiness check of Oracle Metadata Services with status: FAILURE.

Oracle Fusion Middleware IAUスキーマの12.1.3.0バージョンを実行しているときに、そのスキーマが11gリリース(11.1.1.7以降)または12c (12.1.2.0)からアップグレードされていると、次に示すエラーによって準備状況チェックが失敗することがあります。

Starting index test for table IAU_COMMON:  TEST_REQUIRED_INDEXES --> Test 
that the table contains all the required indexes 
     INFO Audit schema index DYN_EVENT_CATEGORY_INDEX in table IAU_COMMON is 
missing the required columns or index itself is missing. This maybe caused by 
a known issue, anyway, this missing index will be added in 12.2.2 upgrade. 
     INFO Audit schema index DYN_EVENT_TYPE_INDEX in table IAU_COMMON is 
missing the required columns or index itself is missing. This maybe caused by 
a known issue, anyway, this missing index will be added in 12.2.2 upgrade. 
     INFO Audit schema index DYN_TENANT_INDEX in table IAU_COMMON is missing 
the required columns or index itself is missing. This maybe caused by a known 
issue, anyway, this missing index will be added in 12.2.2 upgrade. 
     INFO Audit schema index DYN_USER_INDEX in table IAU_COMMON is missing 
the required columns or index itself is missing. This maybe caused by a known 
issue, anyway, this missing index will be added in 12.2.2 upgrade. 
     INFO Audit schema index DYN_COMPONENT_TYPE_INDEX in table IAU_COMMON is 
missing the required columns or index itself is missing. This maybe caused by 
a known issue, anyway, this missing index will be added in 12.2.2 upgrade. 
     INFO Audit schema index DYN_USER_TENANT_INDEX in table IAU_COMMON is 
missing the required columns or index itself is missing. This maybe caused by 
a known issue, anyway, this missing index will be added in 12.2.2 upgrade. 
   Completed index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test 
that the table contains all the required indexes +++ FAIL

注意:

準備状況レポートの欠落している索引に関するエラーは無視してもかまいません。これは既知の問題です。欠落している索引に対応するものが、スキーマのアップグレード操作時に追加されます。このエラーは、アップグレードするスキーマがRCUを使用して12cで作成された場合は発生しません。

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

アップグレード・アシスタントを実行してスキーマをアップグレードする前に、管理サーバーや管理対象サーバーを含め、すべてのプロセスとサーバーをシャットダウンします。

Oracle Fusion Middleware環境は、1つのOracle WebLogic Serverドメイン、1つの管理サーバー、複数の管理対象サーバー、Javaコンポーネント、システム・コンポーネント(Identity Managementのコンポーネントなど)およびメタデータのリポジトリとして使用する1つのデータベースで構成できます。コンポーネントは相互に依存していることがあるため、適切な順序で停止する必要があります。

注意:

この項の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用してサーバーとプロセスを停止する方法について説明します。また、Oracle Fusion Middleware ControlとOracle WebLogic Server管理コンソールを使用することもできます。『Oracle Fusion Middlewareの管理』の管理サーバーと管理対象サーバーおよびノード・マネージャの起動と停止に関する項を参照してください。

Fusion Middleware環境を停止するには、次に示す手順を実行します。

ステップ1: システム・コンポーネントを停止する

Oracle HTTP Serverなどのシステム・コンポーネントを停止するには、stopComponentスクリプトを使用します。

  • (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

  • (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

システム・コンポーネントは任意の順序で停止できます。

ステップ2: 管理対象サーバーを停止する

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

  • (UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url

  • (Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url

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

ステップ3: Oracle Identity Managementのコンポーネントを停止する

目的の環境に含まれるOracle Identity Managementのコンポーネント(Oracle Internet Directoryなど)を停止します。

  • (UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name

  • (Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

ステップ4: 管理サーバーを停止する

管理サーバーを停止するときに、管理サーバーで稼働しているプロセス(WebLogic Server管理コンソールやFusion Middleware Controlなど)も停止します。

管理サーバーを停止するには、stopWebLogicスクリプトを使用します。

  • (UNIX) DOMAIN_HOME/bin/stopWebLogic.sh

  • (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd

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

ステップ5: ノード・マネージャを停止する

ノード・マネージャを停止するには、それが実行されているコマンド・シェルを閉じます。

またはnodemanager.propertiesのQuitEnabledの属性をtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。詳細は、『Oracle Fusion Middleware WebLogic Server WLSTコマンド・リファレンス』のstopNodeManagerに関する項を参照してください。

3.6 ドメインの再構成

再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)にあわせて再構成します。

WebLogic Serverドメインを再構成すると、ドメイン内のアプリケーションに応じて、次の項目が自動的に更新されます。

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

  • ドメイン・バージョン

注意:

ドメインの再構成を開始する前に、次の制限事項に注意してください。

  • 再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。

  • アップグレード・プロセス中に、非動的クラスタ・ドメインを動的クラスタ・ドメインに変換することはサポートされていません。

    動的クラスタ機能は、再構成ウィザードの実行中に使用できますが、サポートされているアップグレードは非動的クラスタのアップグレードのみで、その後で動的クラスタを追加することになります。アップグレード・プロセス中に動的クラスタを追加することはできません。

具体的には、ドメインを再構成する場合、次のことが発生します。

  • ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。

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

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

    変更済の起動スクリプトを維持する場合は、そのスクリプトをバックアップしてから、再構成ウィザードを開始してください。

注意:

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

再構成ウィザードを使用して既存のドメインを再構成する手順に従います。ドメインの再構成の一般情報は、『Oracle Fusion Middleware Oracle WebLogic Serverのアップグレード』のWebLogicドメインの再構成に関する項を参照してください。

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

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

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

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

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

再構成ウィザードをグラフィカル・モードで起動する手順は次のとおりです。

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

    ALTER DATABASE DEFAULT EDITION = edition_name;

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

  4. oracle_common/common/binディレクトリに移動します。
    • (UNIX) ORACLE_HOME/oracle_common/common/bin
    • (Windows) 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

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

再構成ウィザードで、ドメインの場所を保持しながらドメインを再構成します。再構成ウィザードの各画面を通じて、既存のドメインを再構成します。

重要

ソースがクラスタ環境である場合は、再構成ウィザードをプライマリ・ノードでのみ実行します。変更をドメイン内の他のクラスタ・メンバーに適用するには、既存の環境がクラスタ化構成の場合の説明に従って、パック/アンパック・ユーティリティを使用します。
ドメインを再構成するには、次の手順を実行します。
  1. ドメインが存在するシステムにサインインします。
  2. エディション・ベースのデータベース・ユーザーのみ: エディション・ベースの再関連付けを有効にしてスキーマを構成した場合は、再構成ウィザードを実行する前に、デフォルトのエディション名を手動で指定する必要があります。
    デフォルトのエディションを設定するには、次のSQLコマンドを入力します。
    ALTER DATABASE DEFAULT EDITION = edition_name;

    ここで、edition_nameは、デフォルトのデータベース・エディションの名前です。

  3. 「ドメインの選択」画面で、アップグレードするドメインの場所を指定するか、「参照」をクリックしてナビゲートし、ドメインのディレクトリを選択します。「次」をクリックします
  4. 「再構成セットアップの進行状況」画面で、セットアップ・プロセスの進行状況を確認します。完了したら、「次へ」をクリックします。
    このプロセス中に、次の操作が行われます。

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

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

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

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

    注意:

    このステージでは、「ドメイン・モード」を変更することはできません。
    特定のプラットフォームでサポートされているJDKのリストは、Oracle Fusion Middlewareでサポートされているシステム構成の説明を参照してください。
  6. 「JDBCデータ・ソース」画面で、ドメイン・ソースで定義したJDBCデータ・ソースを構成します。
    ドメインを作成する製品に関連付けられるJDBCデータ・ソースは、画面の下半分にリスト表示されます。JDBCデータ・ソースには、データ・ソース・インスタンスの作成時、デプロイ時もしくはターゲット指定時、またはサーバー起動時に作成されるデータベース接続のプールが含まれます。 アプリケーションはJNDIツリーでデータ・ソースをルックアップしてから、接続をリクエストします。アプリケーションに接続する必要がなくなった場合は、接続がデータ・ソースの接続プールに戻されます。
    「データソース名」ドロップダウン・リストから、設定を指定するデータ・ソースを選択します。指定した値は、選択されたデータ・ソースのデータ・ソース・リストの適切な列に表示されます。
    データ・ソースがOracle RAC構成の場合は、次の3つのオプションのいずれかを選択できます。
    • GridLinkへ変換
    • RACマルチ・データ・ソースへ変換
    • 変換しない

    各オプションの詳細は、「ヘルプ」をクリックしてください。

    詳細を指定したら、「次へ」をクリックします。
    「JDBCデータ・ソース」画面でデータ・ソースを選択しないと、次に示す警告が表示されます。
    ドライバがありません
    「OK」をクリックして検証せずに続行するか、「取消」をクリックして「JDBCデータ・ソース」ページに戻ります。
    この場合、「OK」をクリックしてもデータ・ソースは検証されません。
  7. 「JDBCデータ・ソース・テスト」画面で、「JDBCデータ・ソース」画面で構成したデータ・ソース接続のチェック・ボックスを選択し、「選択された接続のテスト」をクリックしてデータ・ソース接続をテストします。

    注意:

    データベース接続をテストするには、接続するデータベースが起動している必要があります。接続をテストしない場合は、データ・ソースを選択しません。「次へ」をクリックして続行します。
  8. 「データベース構成タイプ」画面で、「RCUデータ」を選択して、サーバー表(_STB)スキーマに接続します。
    RCUサービス表(_STB)スキーマ資格証明を使用してデータベース接続の詳細を入力して、「RCU構成の取得」をクリックします。
    再構成ウィザードは、この接続を使用して、ドメインのコンポーネントに必要なデータソースを自動的に構成します。

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

    チェックが成功した場合は、「次へ」をクリックします。チェックが失敗した場合は、接続の正しい詳細を再入力し、再試行します。
  9. 「JDBCコンポーネント・スキーマ・テスト」画面で、すべてのコンポーネント・スキーマを選択して「選択された接続のテスト」をクリックし、各スキーマの接続をテストします。テストの結果は、「ステータス」列に表示されます。
    チェックが完了したら、「次へ」をクリックします。
  10. 「ノード・マネージャ」画面は、再構成するドメインで、ホストごとのノード・マネージャが使用されている場合にのみ表示されます。
    「ノード・マネージャ」画面で、再構成したドメインで使用するノード・マネージャ構成を選択します。結果として生成される構成は、「ノード・マネージャ・タイプ」および「ノード・マネージャ構成」で選択したオプションの組合せに応じて異なります。

    表3-8 ノード・マネージャ画面のフィールドの説明

    オプション 説明
    ドメインごとのデフォルトの場所

    このオプションを選択すると、ノード・マネージャ・ホームが$domain_name/nodemanagerに再定義され、ノード・マネージャ・ホームを編集できなくなります。
    ドメインごとのカスタムの場所

    このオプションは、このドメインの特定の場所に、ドメインごとのノード・マネージャ構成ファイルを作成する場合に選択します。「ノード・マネージャ・ホーム」フィールドでディレクトリを指定するか、「参照」をクリックしてナビゲーション・ツリーを使用してその場所を選択します。指定するディレクトリは空である必要があります。このディレクトリに、nodemanager.propertiesおよびnodemanager.domainsファイルが作成されます。
    ノード・マネージャ・ホーム

    ドメインごとのカスタムの場所オプションを選択した場合は、「参照」をクリックして、ドメインごとのノード・マネージャ構成の格納に使用するディレクトリの場所に移動します。
    手動ノード・マネージャ・セットアップ

    このオプションを選択した場合は、ドメインのノード・マネージャ構成の作成がスキップされ、残りのフィールドはすべて変更できなくなるため、ドメインでノード・マネージャを使用する場合はノード・マネージャ構成の実行の説明に従って、ノード・マネージャを手動で構成する必要があります。再構成されたドメインでは、ホストごとのノード・マネージャ構成が引き続き使用されます。

    既存のドメインがノード・マネージャを使用するように構成されておらず、再構成されたドメインでノード・マネージャを使用しない場合も、このオプションを選択する必要があります。

    ノード・マネージャ構成の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。
    ノード・マネージャ構成 次の2つのオプションから1つを選択します。「手動ノード・マネージャ・セットアップ」を選択した場合は、次のフィールドを使用できません。
    新規構成の作成 nodemanager.propertiesのデフォルトの設定を使用して、再構成されたドメインに、ドメインごとのノード・マネージャ構成が自動的に作成されます。ドメインが正常に再構成された後に、必要に応じて、nodemanager.propertiesを変更できます。
    既存の構成を移行 すでに存在するホストごとのノード・マネージャ構成が、再構成されたドメインのドメインごとの構成に移行されます。これには、ListenAddress、ListenPort、StartScriptName、JavaHomeおよびLogFileの環境固有の設定は含まれません。
    ノード・マネージャ・ホーム 「既存の構成を移行」オプションを選択した場合は、再構成したドメインの移行先にするノード・マネージャのホーム・ディレクトリを入力するか、参照してください。
    Oracle推奨デフォルトの適用

    このチェック・ボックスは、「既存の構成を移行」オプションを選択した場合に、nodemanager.propertiesファイルに指定されているOracle推奨のデフォルトを使用するときに選択します。移行されるnodemanager.propertiesファイルの設定を引き続き使用する場合は、このチェック・ボックスの選択を解除してください。

    推奨されるプロパティのデフォルト値は次のとおりです。

    LogLimit=0
AuthenticationEnabled=true
LogLevel=INFO
DomainsFileEnabled=true
NativeVersionEnabled=true
LogToStderr=true
SecureListener=true
LogCount=1
StopScriptEnabled=false
QuitEnabled=false
LogAppend=true
StateCheckInterval=500
CrashRecoveryEnabled=false
StartScriptEnabled=true
LogFormatter=weblogic.nodemanager.server.LogFormatter
ListenBacklog=50
    ノード・マネージャ資格証明: ユーザー名、パスワード 再構成されたドメインで、ノード・マネージャの起動に使用するユーザー名とパスワードを指定します。
  11. 「拡張構成」画面で、拡張構成を実行するすべてのカテゴリを選択できます。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。

    注意:

    「拡張構成」画面にリストされるカテゴリは、ドメインに選択したテンプレートに定義されているリソースによって異なります。
    このアップグレードではオプションを選択せずに、「次へ」をクリックします。
  12. 「構成のサマリー」画面で、ドメインの詳細な構成設定を確認してから続行します。
    「表示」ドロップダウン・リストからフィルタ・オプションを選択すると、右側のパネルに表示される項目を制限できます。
    構成を変更するには、「戻る」をクリックして適切な画面に戻ります。ドメインを再構成するには、「再構成」をクリックします。

    注意:

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

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

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

    進捗バーが100%になったら、「次へ」をクリックします。
  14. 「構成の終了」画面には、再構成プロセスが正常に完了したか失敗したかが示されます。管理サーバーURL(リスニング・ポートを含む)とともに再構成されたドメインの場所も表示します。再構成が成功した場合は、「Oracle Weblogic Serverの再構成に成功しました」と表示されます。
    再構成プロセスが正常に完了しなかった場合は、その理由を示すエラー・メッセージが表示されます。問題を解決するための適切な措置を講じます。問題を解決できない場合は、My Oracle Supportに連絡してください。
    以後の操作のためにドメインの場所と管理サーバーURLをメモします。
拡張構成関連のすべての画面(「管理対象サーバー」、「クラスタ」、「マシン」、「HTTPプロキシ・アプリケーション」、「Coherenceクラスタ」、「システム・コンポーネント」など)については、『Oracle Fusion Middleware Oracle WebLogic Serverのアップグレード』を参照してください。
ドメインの再構成時にエラーが発生した場合は、『Oracle Fusion Middleware Oracle WebLogic Serverのアップグレード』のドメインのアップグレード・プロセスについての注意事項に関する項を参照してください。

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

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

  • Upgrade Assistantの起動
    Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade Assistantは非SYSDBAとして実行して、一度にアップグレードするドメインは1つにすることをお薦めします。
  • Upgrade Assistantを使用したドメイン構成のアップグレード
    Upgrade Assistantの各画面を通じて、WebLogicドメインのコンポーネント構成をアップグレードします。
  • ドメイン固有コンポーネント構成のアップグレードの確認
    ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびFusion Middleware Controlにログインし、各コンポーネントのバージョン番号が12.2.1.2であることを確認します。

3.7.1 Upgrade Assistantの起動

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

Upgrade Assistantを起動するには、次の手順に従います。
  1. oracle_common/upgrade/binディレクトリに移動します。
    • (UNIX) ORACLE_HOME/oracle_common/upgrade/bin
    • (Windows) ORACLE_HOME\oracle_common\upgrade\bin
  2. Upgrade Assistantを起動します。
    • (UNIX) ./ua
    • (Windows) ua.bat

コマンドラインに指定可能なその他のパラメータ(ロギングのパラメータなど)の詳細は、次を参照してください。

3.7.1.1 Upgrade Assistantのコマンドライン・パラメータ

コマンドラインからUpgrade Assistantを起動するときには、追加のパラメータを指定できます。

表3-9 Upgrade Assistantのコマンドライン・パラメータ

パラメータ 必須/省略可能 説明

-readiness

 準備状況チェックの場合は必須

注意: 準備状況チェックは、スタンドアロンのインストール(WebLogic Serverで管理されていないインストール)に対して実行できません。

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

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

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

-threads

 省略可能

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

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

-response

サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須

レスポンス・ファイルに保存した入力を使用して、Upgrade Assistantを実行します。このレスポンス・ファイルは、GUIモードでUpgrade Assistantを実行したときの入力データから生成されます。このパラメータを使用すると、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) ORACLE_HOME/oracle_common/upgrade/logs
ORACLE_HOME/oracle_common/upgrade/temp

(Windows) ORACLE_HOME\oracle_common\upgrade\logs
ORACLE_HOME\oracle_common\upgrade\temp

-help

省略可能

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

3.7.2 Upgrade Assistantを使用したドメイン構成のアップグレード

Upgrade Assistantの各画面を移動して、WebLogicドメインのコンポーネント構成をアップグレードします。

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

Upgrade Assistantを使用して、ドメイン・コンポーネント構成をアップグレードするには:
  1. 「ようこそ」画面には、Upgrade Assistantの概要と、アップグレード前のいくつかの重要なタスクについての情報が示されます。「次」をクリックします。

    注意:

    Upgrade Assistantの画面の詳細は、画面上の「ヘルプ」をクリックしてください。
  2. 「すべての構成」画面で、「ドメインによって使用されるすべての構成」を選択し、ドメインの場所を「ドメイン・ディレクトリ」フィールドに直接入力するか、「参照」をクリックしてナビゲーション・ツリーで有効なドメイン・ディレクトリを選択して指定します。「次」をクリックします。
  3. 「コンポーネント・リスト」画面で、構成をアップグレードするコンポーネントがリストにすべて含まれていることを確認し、「次」をクリックします。
    アップグレード対象のコンポーネントが表示されていない場合は、「戻る」をクリックして前の画面に戻り、別のドメインを指定します。
  4. 「前提条件」画面で、すべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次」をクリックします。

    注意:

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

    注意:

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

    注意:

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

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

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

    注意:

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

    注意:

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

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

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

    注意:

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

3.7.3 ドメイン固有コンポーネント構成のアップグレードの確認

ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびFusion Middleware Controlにログインし、各コンポーネントのバージョン番号が12.2.1.2になっていることを確認します。

管理コンソールにログインするには、次に移動します: http://administration_server_host:administration_server_port/console

Fusion Middleware Controlにログインするには、次に移動します: http://administration_server_host:administration_server_port/em

注意:

アップグレード後、管理ツールは、前のOracleホームではなく新しい12cのOracleホームから必ず実行してください。

アップグレード・プロセス時に、一部のOWSMドキュメント(ポリシー・セット、ポリシーおよびアサーション・テンプレートなどの事前定義ドキュメント)のアップグレードが必要な場合があります。ポリシー・セットまたは事前定義ドキュメントがアップグレードされると、バージョン番号が1増分されます。

3.8 サーバーとプロセスの起動

アップグレードが成功したら、管理サーバーと管理対象サーバーを含め、すべてのプロセスとサーバーを再起動します。

コンポーネントは相互に依存していることがあるため、適切な順序で起動する必要があります。

注意:

この項の手順では、WLSTコマンドラインまたはスクリプトを使用してサーバーとプロセスを起動する方法について説明します。また、Oracle Fusion Middleware ControlとOracle WebLogic Server管理コンソールを使用することもできます。『Oracle Fusion Middlewareの管理』の管理サーバーと管理対象サーバーおよびノード・マネージャの起動と停止に関する項を参照してください。

Fusion Middleware環境を起動するには、次に示す手順を実行します。

ステップ1: 管理サーバーの起動

管理サーバーを起動するときに、管理サーバーで稼働するプロセス(WebLogic Server管理コンソールやFusion Middleware Controlなど)も起動します。

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

  • (UNIX) DOMAIN_HOME/bin/startWebLogic.sh

  • (Windows) DOMAIN_HOME\bin\startWebLogic.cmd

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

ステップ2: ノード・マネージャを起動する

ノード・マネージャを起動するには、startNodeManagerスクリプトを使用します。

  • (UNIX) DOMAIN_HOME/bin/startNodeManager.sh

  • (Windows) DOMAIN_HOME\bin\startNodeManager.cmd

ステップ3: Oracle Identity Managementのコンポーネントを起動する

目的の環境に含まれるOracle Identity Managementのコンポーネント(Oracle Internet Directoryなど)を起動します。

  • (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

  • (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

ステップ4: 管理対象サーバーを起動する

WebLogic Server管理対象サーバーを起動するには、startManagedWebLogicスクリプトを使用します。

  • (UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

  • (Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

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

注意:

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

ステップ5: システム・コンポーネントを起動する

Oracle HTTP Serverなどのシステム・コンポーネントを起動するには、startComponentスクリプトを使用します。

  • (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

  • (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

システム・コンポーネントは任意の順序で起動できます。

3.9 アップグレードの検証チェックリストの使用

アップグレード後には、基本的な管理タスク(ノード・マネージャ、管理サーバー、Web層、管理コンソールおよびEnterprise Manager Fusion Middleware Controlを起動できるかどうかの確認など)が正常に完了できることを確認してください。

注意:

次のサーバーを起動する順序は重要です。それらを正しい順序で起動(停止)しないと、デプロイメントに関する問題が発生する可能性があるからです。

詳細は、「サーバーの正しい順序での起動と停止」を参照してください。

  1. ノード・マネージャを起動できることを確認します。
  2. 管理サーバーおよび管理対象サーバー(ある場合)を、元のドメイン・ホームのbinディレクトリから起動できることを確認します。Windowsオペレーティング・システム・ユーザーの場合は、新しいコマンド・プロンプトで(12cのUpgrade Assistantを起動したコマンド・プロンプトではなく)サーバーを起動すると便利です。

    注意:

    OHS自身の構成には、管理対象サーバーは必要ありません。
  3. Web層(OHSサーバー)を起動できることを確認します。
  4. 次のURLを使用して、管理コンソールおよびEnterprise Managerに接続できることを確認します。
    管理コンソール: http://machinename.my_company_com:administration_port/console
    Enterprise Manager: http://machinename.my_company_com:administration_port/em

3.10 カスタム構成設定のsetDomainEnvへの再適用

アプリケーション環境の12cへのアップグレードを完了するには、起動スクリプト(setDomainEnvなど)へのカスタム構成設定の再適用が必要な場合があります。これらのスクリプトは、アップグレード時に新しい12cバージョンで上書きされます。前のリリースで作成したカスタム構成設定は手動で再適用する必要があります。

詳細は、起動スクリプトへのカスタマイズの再適用を参照してください。

注意:

今後のアップグレードでカスタム構成設定が失われないようにするには、「カスタムsetDomainEnv設定のメンテナンス」を参照してください。

3.11 Oracle Fusion Middleware 12c監査データ・ストアの構成

11gデプロイメントでファイルベースの監査ストアを使用していた場合は、Oracle Fusion Middleware 12cへのアップグレード後に、データベースベースの監査データ・ストアへの監査データのロードを有効にする必要があります。

包括的なアップグレード処理の一環として、他のOracle Fusion Middlewareスキーマが存在するデータベースにIAUスキーマを作成しておく必要があります。監査データ・ストアの使用の詳細は、 Fusion Middlewareアプリケーション・セキュリティ・ガイドの監査の構成および管理を参照してください。

3.12 古いJava EE Webサービス・アプリケーションのセキュリティ・ステータスのメンテナンス

12cにおいて、Java EE Webサービスおよびクライアントに対するグローバル・ポリシー・アタッチメントのサポートを導入すると、既存のJava EE Webサービスおよびクライアント(12.1.2およびそれ以前)の後方互換性に影響する場合があります。ポリシーの不在に依存しているJava EE Webサービスまたはクライアント・エンドポイントが、グローバル・ポリシー・アタッチメントのスコープに含まれる場合、グローバル・ポリシー・アタッチメントの存在によって、そのエンドポイントのセキュリティ動作が変更される場合があります。

注意:

Fusion Middleware 12.1.2およびそれ以前では、SOAP WebサービスおよびSOAP Webサービス・クライアントのサブジェクト・タイプのために定義されたグローバル・ポリシー・アタッチメントは、Oracle Infrastructure Webサービスおよびクライアントにのみ適用可能であり、Java EE Webサービスおよびクライアントからは無視されていました。12c (12.2.1)へのアップグレード後は、これらのサブジェクト・タイプのために定義されたグローバル・ポリシー・アタッチメントは、Java EE Webサービスおよびクライアントにも適用され、既存のJava EE Webサービスおよびクライアントのセキュリティ動作に影響を与える場合があります。

後方互換性を維持するには、特定のサービスまたはクライアントにOWSM動作無効ポリシー(no_authentication_service_policy、no_authorization_service_policyまたはno_messageprotection_service_policyなど)をアタッチすることにより、それらのエンドポイントへのグローバル・ポリシー・アタッチメントを無効化できます。詳細は、『Oracle Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のグローバルにアタッチされたポリシーの無効化に関する項を参照してください。

注意:

WebLogic Wssp1.5-No-Op.xml動作無効ポリシーを使用できます。ただし、WebLogicセキュリティ・ポリシーは、プログラムでのみWebサービス・クライアントにアタッチできるため、コードの変更が必要です。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server WebLogic Webサービスの保護』のグローバルにアタッチされたポリシーの無効化に関する項を参照してください

3.13 Oracle Fusion Middleware 12cソフトウェアの管理のためのドキュメント・リソース

このトピックでは、Infrastructure 12cへのアップグレード後に実行することが多い一般的な管理タスクおよび関連するドキュメント・リソースのリストを示しています。

表5-1に、Infrastructure 12cへのアップグレード後に実行する可能性の高い一般的な管理タスクを示します。

表3-10 基本的な管理タスク

タスク 説明 参照先

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

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

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

製品およびサーバーの起動と停止

Oracle Fusion Middleware(管理サーバー、管理対象サーバー、コンポーネントを含む)起動と停止の方法について学習します。

Oracle Fusion Middlewareの管理のOracle Fusion Middlewareの起動と停止。

Secure Sockets Layer (SSL)の構成

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

Oracle Fusion Middlewareの管理のOracle Fusion MiddlewareでのSSLの構成。

Oracle Fusion Middlewareのモニタリング

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

Oracle Fusion Middlewareの管理のOracle Fusion Middlewareの監視。

バックアップとリカバリの手順の理解

Oracle Fusion Middlewareのバックアップとリカバリの推奨手順について学習します。

Oracle Fusion Middlewareの管理のバックアップとリカバリの概要。

3.14 Oracle Fusion Middleware 12cでの11gアプリケーション・デプロイメントの使用

Oracle Fusion Middleware 12cへのアップグレード後、Oracle Fusion Middleware 11gにデプロイしていたカスタムJavaおよびApplication Development Framework (ADF)は、Oracle Fusion Middleware 11gと同じように動作します。ただし、ADF 12cおよびJDeveloper 12cで利用可能ないくつかの新機能があります。

次の項では、アプリケーションをJDeveloper 12cに移行する方法についての追加情報を示します。

  • Oracle Application Development Framework (ADF) 12cについて
    Oracle ADFは、エンドツーエンドJava EEフレームワークです。これによって、追加設定なしで使用できるインフラストラクチャ・サービスと、視覚的で宣言的な開発エクスペリエンスが提供され、アプリケーション開発が簡素化されます。
  • Oracle JDeveloper 12cについて
    Oracle JDeveloperは、アプリケーション・ライフサイクルの各段階に対処するJavaベースのアプリケーションの開発を簡素化する統合開発環境です。JDeveloperは、Oracleのプラットフォームおよびアプリケーションに対する完全なエンド・ツー・エンドの開発を提供します。

3.14.1 Oracle Application Development Framework (ADF) 12cについて

Oracle ADFは、エンドツーエンドJava EEフレームワークです。これによって、追加設定なしで使用できるインフラストラクチャ・サービスと、視覚的で宣言的な開発エクスペリエンスが提供され、アプリケーション開発が簡素化されます。

Oracle ADFの詳細は、次のOracle Fusion Middleware 12cのドキュメント・ライブラリを参照してください。

3.14.2 Oracle JDeveloper 12cについて

Oracle JDeveloperは、アプリケーション・ライフサイクルの各段階に対処するJavaベースのアプリケーションの開発を簡素化する統合開発環境です。JDeveloperは、Oracleのプラットフォームおよびアプリケーションに対する完全なエンド・ツー・エンドの開発を提供します。

3.14.2.1 Oracle JDeveloper 12cのインストール

Oracle JDeveloperは、アプリケーションをローカルでテストするために使用できる埋込みバージョンのOracle WebLogic Serverを提供します。

Oracle JDeveloper 12cをインストールする場合は、『Oracle Fusion Middleware Oracle JDeveloperのインストール』のOracle JDeveloperソフトウェアのインストールに関する項を参照してください。

JDeveloperを使用したアプリケーションのテストの詳細は、『Oracle Fusion Middleware Oracle JDeveloperのインストール』のOracle JDeveloperで開発したアプリケーションのデプロイとテストに関する項を参照してください。

3.14.2.2 Oracle JDeveloper 12cを使用したアプリケーションの移行

Oracle JDeveloper 12cのインストール後、Oracle JDeveloper 12cでカスタム・アプリケーション・プロジェクトを開いて、Oracle JDeveloper 12cに自動的に移行できます。

詳細は、『Oracle Fusion Middleware Oracle JDeveloperのインストール』の以前のバージョンからのOracle JDeveloperの移行に関する項を参照してください。

3.14.2.3 Oracle JDeveloper 12cを使用した非同期Webサービスの移行について

アプリケーションにApplication Development Framework Business Components (ADF BC)非同期Webサービスが含まれている場合、Oracle JDeveloperまたはojdeployコマンド行ツールを使用してそれを再作成し、必要なデプロイメント・ディスクリプタをデプロイメント・アーカイブに生成します。

非同期Webサービスの開発の詳細は、『Oracle Fusion Middleware Oracle Infrastructure Webサービスの開発』の非同期Webサービスの開発の概要に関する項を参照してください。

3.15 既存の環境がクラスタ構成の場合

既存の環境がクラスタ構成の場合、パック・ユーティリティおよびアンパック・ユーティリティを使用してそのドメイン内の他のクラスタ・メンバーに変更を適用する必要があります。

3.15.1 プライマリ・ノードのドメインのパック

プライマリ・ノードのドメインをパックする手順は、次のとおりです。
  1. プライマリ・ノードにログインします。
  2. 次の例に示すように、ドメインをパックします。
    ./pack.sh -managed=true -domain=$DOMAIN_HOME/user_projects/domains/base_domain -template=sampledomaintemplate.jar -template_name=sample_domain_template

3.15.2 セカンダリ・ノードのドメインのアンパック

セカンダリ・ノードのドメインをアンパックする手順は、次のとおりです。
  1. セカンダリ・ノードにログインします。
  2. 次の例に示すように、ドメインを含むsampledomaintemplate.jarファイルをアンパックします。
    ./unpack.sh -domain=$DOMAIN_HOME/user_projects/domains/base_domain -template=$ORACLE_HOME/oracle_common/common/bin/sampledomaintemplate.jar -app_dir=$DOMAIN_HOME/user_projects/applications -overwrite_domain=true

3.16 サーバーとプロセスの起動

アップグレードが成功したら、管理サーバーと管理対象サーバーを含め、すべてのプロセスとサーバーを再起動します。

コンポーネントは相互に依存していることがあるため、適切な順序で起動する必要があります。

注意:

この項の手順では、WLSTコマンドラインまたはスクリプトを使用してサーバーとプロセスを起動する方法について説明します。また、Oracle Fusion Middleware ControlとOracle WebLogic Server管理コンソールを使用することもできます。『Oracle Fusion Middlewareの管理』の管理サーバーと管理対象サーバーおよびノード・マネージャの起動と停止に関する項を参照してください。

Fusion Middleware環境を起動するには、次に示す手順を実行します。

ステップ1: 管理サーバーの起動

管理サーバーを起動するときに、管理サーバーで稼働するプロセス(WebLogic Server管理コンソールやFusion Middleware Controlなど)も起動します。

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

  • (UNIX) DOMAIN_HOME/bin/startWebLogic.sh

  • (Windows) DOMAIN_HOME\bin\startWebLogic.cmd

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

ステップ2: ノード・マネージャを起動する

ノード・マネージャを起動するには、startNodeManagerスクリプトを使用します。

  • (UNIX) DOMAIN_HOME/bin/startNodeManager.sh

  • (Windows) DOMAIN_HOME\bin\startNodeManager.cmd

ステップ3: Oracle Identity Managementのコンポーネントを起動する

目的の環境に含まれるOracle Identity Managementのコンポーネント(Oracle Internet Directoryなど)を起動します。

  • (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

  • (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

ステップ4: 管理対象サーバーを起動する

WebLogic Server管理対象サーバーを起動するには、startManagedWebLogicスクリプトを使用します。

  • (UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

  • (Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

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

注意:

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

ステップ5: システム・コンポーネントを起動する

Oracle HTTP Serverなどのシステム・コンポーネントを起動するには、startComponentスクリプトを使用します。

  • (UNIX) DOMAIN_HOME/bin/startComponent.sh component_name

  • (Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

システム・コンポーネントは任意の順序で起動できます。

前
前 		次
次へ
目次へ移動
目次