3 Oracle Data Integratorスタンドアロン・エージェント環境の11gからのアップグレード

WebLogicドメイン内に構成されていないOracle Data Integratorスタンドアロン・エージェント環境をOracle Fusion Middleware 11gから12c (12.2.1.3.0)にアップグレードできます。

• Oracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスについて
  WebLogicドメイン内に構成されていないOracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスの概要を示すフローチャートおよびロードマップを確認します。
• Oracle Data Integratorスタンドアロン・エージェント環境のインストール
  アップグレードを開始する前に、Oracle Data Integrator 12c (12.2.1.3.0)ディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。
• 必要な12cスキーマの作成
  11gからアップグレードする場合は、必要な12cスキーマを作成する必要があります。リポジトリ作成ユーティリティ(RCU)を使用してカスタマイズされたスキーマを作成するか、オプションで、アップグレード・アシスタントを使用してデフォルトのスキーマ設定を使用してスキーマを作成できます。この手順では、RCUを使用してスキーマを作成する方法について説明します。アップグレード・アシスタントを使用してスキーマを作成する方法については、アップグレード手順で説明しています。
• サーバーとプロセスの停止
  Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、すべてのアップグレード前のプロセス、および管理サーバーや管理対象サーバーを含めたすべてのサーバーを停止する必要があります。
• 製品スキーマのアップグレード
  サーバーとプロセスの停止後に、Upgrade Assistantを使用して、サポートされている製品スキーマをOracle Fusion Middlewareの現在のリリースにアップグレードします。
• スタンドアロン・システム・コンポーネント構成のアップグレード
  エージェントがOPMNによって管理される場合、アップグレード・アシスタントを使用してスタンドアロン・エージェントのコンポーネント構成をアップグレードします。スタンドアロン・コンポーネント構成のアップグレードは、OPMNによって管理されないスタンドアロン・エージェントのアップグレードをサポートしていません。
• サーバーおよびプロセスの起動
  アップグレードが成功した後、管理サーバーおよび管理対象サーバーを含め、すべてのプロセスおよびサーバーを再起動します。

Oracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスについて

WebLogicドメイン内に構成されていないOracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスの概要を示すフローチャートおよびロードマップを確認します。

図3-1 Oracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスのフローチャート

「図3-1 Oracle Data Integratorスタンドアロン・エージェントのアップグレード・プロセスのフローチャート」の説明

表3-1 Oracle Data Integratorスタンドアロン・エージェントを11gからアップグレードするためのタスク

タスク	説明
必須 このガイドの概要のトピックをまだ確認していない場合は確認し、必要なアップグレード前のタスクを完了します。	次を参照してください。 Oracle Data Integratorの12c (12.2.1.3.0)へのアップグレードの概要 アップグレード前の要件
必須 Oracle Data Integratorスタンドアロン12c (12.2.1.3.0)を新しいOracleホームにインストールします。	アップグレードを開始する前に、11g本番デプロイメントと同じホスト上の新しいOracleホームに製品ソフトウェアをインストールします。12cでは、11g Middlewareホームを表現するために、Oracleホームを使用します。 「Oracle Data Integratorスタンドアロン・エージェント環境のインストール」を参照してください。
必須 リポジトリ作成ユーティリティ(RCU)を起動して、必要な12cデータベース・スキーマを作成します。	STBスキーマを作成します。 必要な12cスキーマの作成を参照してください。
必須 11g環境を停止します(すべての管理サーバーと管理対象サーバーを停止します)。	警告: アップグレード中にサーバーを停止しないと、データが破壊される可能性があります。 「サーバーとプロセスの停止」を参照
必須 アップグレード・アシスタントを起動して、11gのデータベース・スキーマをアップグレードし、すべてのアクティブ(進行中の)インスタンス・データを移行します。	製品スキーマのアップグレードを参照してください。 注意: アクティブ・インスタンス・データのアップグレードは、アップグレード・アシスタントの実行中に自動で開始されます。データが正常に新しい12c (12.2.1.3.0)環境にアップグレードされたら、アップグレード・アシスタントを終了してもかまいません。クローズされたインスタンスのアップグレードは、バックグランド・プロセスで継続されます。
OPMNによって管理される場合は必須 アップグレード・アシスタントを(再度)起動して、スタンドアロン・システム・コンポーネント構成をアップグレードします。	エージェントがOPMNによって管理される場合、アップグレード・アシスタントを実行してスタンドアロン・エージェントのコンポーネント構成をアップグレードします。スタンドアロン・コンポーネント構成のアップグレードは、OPMNによって管理されないスタンドアロン・エージェントのアップグレードをサポートしていません。 スタンドアロン・システム・コンポーネント構成のアップグレードを参照してください。
必須 サーバーおよび12c (12.2.1.3.0)インスタンスを再起動します。	アップグレード・プロセスが完了したら、12c (12.2.1.3.0)インスタンスを再起動します。 サーバーおよびプロセスの起動を参照してください。
必須 アップグレードを確認します。	バックアップを削除する前に、アップグレードしたコンポーネントがすべて期待どおりに動作していることを確認します。

Oracle Data Integratorスタンドアロン・エージェント環境のインストール

アップグレードを開始する前に、Oracle Data Integrator 12c (12.2.1.3.0)ディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。

12c (12.2.1.3.0)ディストリビューションをインストールする手順は次のとおりです。

1. ターゲット・システムにサインインします。
2. 次の12c (12.2.1.3.0)製品ディストリビューションをOracle Technology NetworkまたはOracle Software Delivery Cloudからターゲット・システムにダウンロードします。
   • Oracle Data Integrator (fmw_12.2.1.3.0_odi_Disk1_1of2.zipおよびfmw_12.2.1.3.0_odi_Disk1_2of2.zip )
3. 12c (12.2.1.3.0)製品のディストリビューションをダウンロードしたディレクトリに移動します。
4. インストールfmw_12.2.1.3.0_odi_Disk1_1of2.zipおよびfmw_12.2.1.3.0_odi_Disk1_2of2.zipファイルを解凍します。
5. 次のコマンドを入力して製品ディストリビューションのインストーラを起動し、前述のステップを繰り返してインストーラの各画面を移動します。
   (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.3.0_odi_generic.jar
   (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.3.0_odi_generic.jar
6. UNIXオペレーティング・システムでは、このホストにOracle製品を初めてインストールする場合に、「インストール・インベントリの設定」画面が表示されます。
   中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名に対して中央インベントリの場所への書込み権限が付与されていることを確認し、「次」をクリックします。

   注意:

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

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

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

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

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

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

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

必要な12cスキーマの作成

11gからアップグレードする場合は、必要な12cスキーマを作成する必要があります。リポジトリ作成ユーティリティ(RCU)を使用してカスタマイズされたスキーマを作成するか、オプションで、アップグレード・アシスタントを使用してデフォルトのスキーマ設定を使用してスキーマを作成できます。この手順では、RCUを使用してスキーマを作成する方法について説明します。アップグレード・アシスタントを使用してスキーマを作成する方法については、アップグレード手順で説明しています。

このガイドで説明するODI環境では、必須のスキーマは次のとおりです。

• ODIスタンドアロン・エージェント(WebLogicドメインなし): STB

• ODIスタンドアロン・コロケート・エージェント(WebLogicドメインあり): STB、OPSS、IAU、IAU_VIEWERおよびIAU_APPEND

• ODI Java EEエージェント: STB、OPSS、IAU、IAU_VIEWERおよびIAU_APPEND

注意:

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

12cにアップグレードする前に、次のスキーマが存在している必要があります。11gからアップグレードする場合で、現在どのスキーマがあるかわからないときは、次のステップを参照してドメイン内の既存のスキーマを確認してください。すでに存在する場合は、スキーマを再作成する必要はありません。

• サービス表スキーマ(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ベースのセキュリティ・ストアが引き続き使用されます。

• 監査スキーマ。監査サービス(_IAU)をアップグレードする場合、_IAUに加えて、_IAU_VIEWERおよび_IAU_APPENDを必ず選択します。これらが選択されていると、アップグレード・アシスタントによって自動的に作成されます。

RCUを使用して12cスキーマを作成する手順は次のとおりです。

1. (オプション) 11gからのアップグレードで、既存のドメインにどのスキーマが存在しているかを確認するには、DBA権限を持つユーザーとしてデータベースに接続し、SQL*Plusから次のコードを実行します。

   SET LINE 120
   COLUMN MRC_NAME FORMAT A14
   COLUMN COMP_ID FORMAT A20
   COLUMN VERSION FORMAT A12
   COLUMN STATUS FORMAT A9
   COLUMN UPGRADED FORMAT A8
   SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;
   

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

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

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

   表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)を選択します。この接頭辞は、スキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。

   注意:

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

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

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

アップグレード・アシスタントを実行してスキーマと構成をアップグレードする前に、管理サーバーおよび管理対象サーバーを含むすべてのアップグレード前のプロセスおよびサーバーを停止する必要があります。

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

注意:

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

アップグレード前のFusion Middleware環境を停止するには、アップグレード前のドメインに移動し、次のステップに従います。

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

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

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

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

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

ステップ2: 管理対象サーバーの停止

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

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

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

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

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

Oracle Identity Managementのコンポーネント(Oracle Internet Directoryなど)を停止します。

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

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

ステップ4: 管理サーバーの停止

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

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

• (UNIX) EXISTING_DOMAIN_HOME/bin/stopWebLogic.sh

• (Windows) EXISTING_DOMAIN_HOME\bin\stopWebLogic.cmd

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

注意:

リポジトリ用に外部のパスワード記憶域が設定されている場合は、アップグレード中に作業リポジトリのパスワードを取得できるように、資格証明ストアをホストしているサーバーが稼働している必要があります。『Oracle Data Integratorの管理』の外部パスワード記憶域の設定に関する項を参照してください。

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

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

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

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

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

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

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

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

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

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

注意:

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

1. oracle_common/upgrade/binディレクトリに移動します。
   • (UNIX) NEW_ORACLE_HOME/oracle_common/upgrade/bin
   • (Windows) NEW_ORACLE_HOME\oracle_common\upgrade\bin
2. アップグレード・アシスタントを起動します。
   • (UNIX) ./ua
   • (Windows) ua.bat

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

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

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

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

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

パラメータ	必須またはオプション	説明
-readiness	準備状況チェックに必須 注意: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。	実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。 スキーマおよび構成がチェックされます。 -examineパラメータを指定した場合、このパラメータを使用しないでください。
-threads	オプション	スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。
-response	サイレント・アップグレードまたはサイレント準備状況チェックに必須	アップグレード・アシスタントがGUIモードで実行されたときに入力されたデータから生成されたレスポンス・ファイルに保存された入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。
-examine	オプション	調査フェーズを実行しますが、実際のアップグレードは実行しません。 -readinessパラメータを指定した場合、このパラメータを指定しないでください。
-logLevel attribute	オプション	次のいずれかの属性を指定してロギング・レベルを設定します。 TRACE NOTIFICATION WARNING ERROR INCIDENT_ERROR デフォルトのロギング・レベルはNOTIFICATIONです。 より多くの情報がロギングされるように-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。
-logDir location	オプション	アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。アップグレード・アシスタントによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 (UNIX) NEW_ORACLE_HOME/oracle_common/upgrade/logs NEW_ORACLE_HOME/oracle_common/upgrade/temp (Windows) NEW_ORACLE_HOME/oracle_common/upgrade/logs NEW_ORACLE_HOME/oracle_common/upgrade/temp
-help	オプション	すべてのコマンドライン・オプションを表示します。

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

アップグレード・アシスタントの各画面を移動して、製品スキーマをアップグレードします。

注意:

• 外部認証を使用している場合は、製品スキーマをアップグレードする前に、外部認証が内部認証に変更されていることを確認してください。

• エディションベースの再定義(EBR)ユーザーのみ: エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、データベース・サーバーに接続して、12cのデータベース・サーバーにエディションを作成する必要があります。12cの新しいエディションは、既存の11cエディションの子である必要があります。「エディション・ベースの再定義のためのサーバー上でのエディションの作成」を参照してください。

注意:

アップグレード・アシスタントを起動する前に、管理サーバーおよび管理対象サーバーが停止していることを確認してください。

アップグレード・アシスタントで製品スキーマをアップグレードする手順は次のとおりです。

1. 「ようこそ」画面で、アップグレード・アシスタントの概要と、重要なアップグレード前のタスクに関する情報を確認します。「次へ」をクリックします

   注意:

   アップグレード・アシスタント画面の詳細は、画面で「ヘルプ」をクリックしてください。
2. 「選択したスキーマ」画面で、「個別に選択されたスキーマ」を選択します。

   注意:

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

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

3. 「使用可能なコンポーネント」画面で、マスターおよび作業リポジトリ・スキーマをアップグレードするために「Oracle Data Integrator」を選択します。
4. 「前提条件」画面ですべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次へ」をクリックします

   注意:

   アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。
5. ODIスキーマ画面で、アップグレードする各スキーマのデータベース接続の詳細を指定します。

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

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

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

6. 「ODIオプション」画面で、すべてのオプションを選択します。

   表3-7 ODIのオプション

   オプション	説明
   ナレッジ・モジュールを必須更新で置換	これを選択すると、標準ナレッジ・モジュールが最新バージョンに置き換えられます。Oracleによりインストールされたナレッジ・モジュールに対するカスタマイズ内容は上書きされます。ただし、インストールされたナレッジ・モジュールをコピーしてからそのナレッジ・モジュールをカスタマイズした場合、カスタマイズ内容は失われません。
   トポロジおよびセキュリティ・メタデータのアップグレード	これを選択すると、テクノロジ、データ型、セキュリティ・プロファイルなどのトポロジおよびセキュリティ・アーティファクトが最新バージョンに置き換えられます。インストールされたオブジェクトのカスタマイズ内容は上書きされます。オブジェクトをコピーしてからカスタマイズした場合、カスタマイズ内容は失われません。

   「高度なアップグレード・オプション」を参照してください(これは、ODIリポジトリを11gから12cにアップグレードする場合に重要です)。

7. 「ODIスーパーバイザ」画面に、アップグレードするODIリポジトリのスーパーバイザ・アカウント資格証明を入力します。

   インストールされているスーパーバイザ・アカウントはSUPERVISORです。正しいスーパーバイザのアカウント名およびパスワード(ODIのマスター・リポジトリおよび作業リポジトリの作成時、リポジトリ作成ユーティリティ(RCU)のプロンプトに入力したもの)は、ODI管理者に確認してください。

   図3-2 ODIリポジトリのアカウント資格証明

   
   「図3-2 ODIリポジトリのアカウント資格証明」の説明

   注意:

   「ドメインで使用されるすべてのスキーマ」が選択されている場合、ODIのスーパーバイザ資格証明はドメインに含まれていないため、最初のインスタンスにあらかじめ移入されません。複数のODIスキーマがある場合、アップグレード・アシスタントは最初の資格証明のセットを使用してユーザー・エントリに移入します。
8. 「ODIアップグレード・キー」画面で、自動生成されたアップグレード・キーを使用して、リポジトリ・オブジェクトの11g IDを一意のGUIDに変換するか、独自のキーを「アップグレード・キー」フィールドに指定します。

   推奨事項:

   • 自動生成されたキーを編集して、覚えやすい意味のあるキーを指定します。

   • ODIオブジェクトがXMLファイルからインポートされるときに同じアップグレード・キーを指定できるように、アップグレード・キーを書き留めます。

   ODIオブジェクトはODIリポジトリに存在し、そのリポジトリからエクスポートされたXMLファイルにも存在します。これは、たとえば、リポジトリ間のメタデータ交換で使用できます。そのため、同一オブジェクトの複数のコピーが異なるリポジトリおよびXMLファイルに含まれる場合があります。

   12cでは、ODIはオブジェクト識別に数字の内部IDではなくGUIDを使用します。アップグレード後にオブジェクトIDが保持されるようにするため、決定性アルゴリズムが適用され、既存のオブジェクトの内部IDからGUIDが計算されます(新規オブジェクトの場合、ODIにより無作為のGUIDが生成されます)。

   数字の内部IDは実際にはユニバーサルに一意ではなく、リポジトリIDに依存して疑似的な一意性が実現されており、ODIでは、重複したGUIDが生成される可能性を低減するため、ユーザーがアップグレード・キーを指定できます。アップグレード・キーが数字の内部IDとともにGUID生成アルゴリズムに提供され、GUIDが計算されます。

   このように、異なるアップグレード・キーを選択することで、偶然に同じ数字の内部IDを持つオブジェクトが重複したGUIDを取得することを防ぎます。ただし、同じオブジェクトの複数のコピーが(リポジトリ内に、またはXMLファイルにエクスポートされて)存在する場合、オブジェクトのすべてのコピーに対して同じGUIDが生成される必要があります。そのため、その特定のオブジェクトのコピーに関係するすべてのアップグレード操作に対して、同じアップグレード・キーを使用する必要があります。

   たとえば、11gリポジトリにIDとして1001を持つプロジェクトがあり、同じリポジトリからエクスポートされたファイルにも、また同じプロジェクト(ID = 1001)が含まれるとします。この場合、リポジトリのアップグレードに使用されるアップグレード・キーは、アップグレード済の12cリポジトリにXMLファイルをインポートする際に使用されるアップグレード・キーと同じである必要があります。これによって、インポート・ファイルのプロジェクト・オブジェクトは、リポジトリのプロジェクト・オブジェクトと正しく一致します(いずれかのSYNONYMインポート・モードを使用した場合)。ただし、別のリポジトリで作成されたオブジェクトを含むソースから11g XMLエクスポート・ファイルが提供され、そのリポジトリの情報がない場合、偶然同じ内部ID (1001)を持つプロジェクトが含まれている可能性があります。この場合、誤ったオブジェクトの一致によるメタデータの破損を防ぐため、そのファイルをリポジトリにインポートする際には、別のカスタム・アップグレード・キーを使用する必要があります。

9. 「調査」画面で、各スキーマを調査した際のアップグレード・アシスタントのステータスを確認し、スキーマのアップグレード準備が整っていることを確認します。ステータスが「調査が終了しました。」になっている場合は、「次へ」をクリックします。
   調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、一般的なアップグレード・エラーの解決の詳細をUpgrade Assistantによるアップグレード のアップグレードのトラブルシューティングで参照してください。

   注意:

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

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

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

    注意:

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

    注意:

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

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

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

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

    注意:

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

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

すべてのアップグレード・ステップの完了後、schema_version_registryのスキーマ・バージョンが正しく更新されたことを確認して、アップグレードが成功したことを確認します。

Oracle Databaseを使用する場合、Oracle DBAを持つユーザーとしてデータベースに接続し、SQL*Plusから次を実行して現行のバージョン番号を取得します。

SET LINE 120
COLUMN MRC_NAME FORMAT A14
COLUMN COMP_ID FORMAT A20
COLUMN VERSION FORMAT A12
COLUMN STATUS FORMAT A9
COLUMN UPGRADED FORMAT A8
SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;

問合せ結果:

• VERSION列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。たとえば、スキーマ・バージョン番号が12.2.1.3.0になっていることを確認します。

  注意:

  ただし、すべてのスキーマ・バージョンが更新されるわけではありません。一部のスキーマではこのリリースへのアップグレードが必要なく、アップグレード前のバージョン番号が保持されます。

• STATUSフィールドは、スキーマのパッチ適用操作中はUPGRADINGまたはUPGRADEDのどちらかになり、パッチ適用操作が完了するとVALIDになります。

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

• IAU_APPENDおよびIAU_VIEWERによって所有されるシノニム・オブジェクトは、INVALIDとして表示されますが、失敗を示すものではありません。

  それらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトはアクセスされると有効になります。これらのINVALIDオブジェクトは無視しても問題ありません。

スタンドアロン・システム・コンポーネント構成のアップグレード

エージェントがOPMNによって管理される場合、アップグレード・アシスタントを使用してスタンドアロン・エージェントのコンポーネント構成をアップグレードします。スタンドアロン・コンポーネント構成のアップグレードは、OPMNによって管理されないスタンドアロン・エージェントのアップグレードをサポートしていません。

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

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

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

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

注意:

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

1. oracle_common/upgrade/binディレクトリに移動します。
   • (UNIX) NEW_ORACLE_HOME/oracle_common/upgrade/bin
   • (Windows) NEW_ORACLE_HOME\oracle_common\upgrade\bin
2. アップグレード・アシスタントを起動します。
   • (UNIX) ./ua
   • (Windows) ua.bat

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

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

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

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

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

パラメータ	必須またはオプション	説明
-readiness	準備状況チェックに必須 注意: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。	実際のアップグレードを実行せずにアップグレードの準備状況チェックを実行します。 スキーマおよび構成がチェックされます。 -examineパラメータを指定した場合、このパラメータを使用しないでください。
-threads	オプション	スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を識別します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。
-response	サイレント・アップグレードまたはサイレント準備状況チェックに必須	アップグレード・アシスタントがGUIモードで実行されたときに入力されたデータから生成されたレスポンス・ファイルに保存された入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。
-examine	オプション	調査フェーズを実行しますが、実際のアップグレードは実行しません。 -readinessパラメータを指定した場合、このパラメータを指定しないでください。
-logLevel attribute	オプション	次のいずれかの属性を指定してロギング・レベルを設定します。 TRACE NOTIFICATION WARNING ERROR INCIDENT_ERROR デフォルトのロギング・レベルはNOTIFICATIONです。 より多くの情報がロギングされるように-logLevel TRACE属性を設定することを検討してください。これは、失敗したアップグレードをトラブルシューティングするときに役立ちます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があります。
-logDir location	オプション	アップグレード・ログ・ファイルおよび一時ファイルのデフォルトの場所を設定します。アップグレード・アシスタントによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 (UNIX) NEW_ORACLE_HOME/oracle_common/upgrade/logs NEW_ORACLE_HOME/oracle_common/upgrade/temp (Windows) NEW_ORACLE_HOME/oracle_common/upgrade/logs NEW_ORACLE_HOME/oracle_common/upgrade/temp
-help	オプション	すべてのコマンドライン・オプションを表示します。

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

アップグレード・アシスタントの各画面を移動して、スタンドアロン・システム・コンポーネント構成をアップグレードします。

注意:

エージェントがOPMNによって管理される場合のみ、アップグレード・アシスタントを使用してスタンドアロン・エージェントのコンポーネント構成をアップグレードします。スタンドアロン・コンポーネント構成のアップグレードは、OPMNによって管理されないスタンドアロン・エージェントのアップグレードをサポートしていません。

アップグレード・アシスタントを使用してスタンドアロン・システム・コンポーネント構成をアップグレードする手順は次のとおりです。

1. 「ようこそ」画面で、アップグレード・アシスタントの概要と、重要なアップグレード前のタスクに関する情報を確認します。「次へ」をクリックします

   注意:

   アップグレード・アシスタント画面の詳細は、画面で「ヘルプ」をクリックしてください。
2. 次の画面で次のようにします。
   • 「スタンドアロン・システム・コンポーネント構成」を選択し、「新規ドメインの作成」を選択します。

     注意:

     12cより、スタンドアロン・システム・コンポーネントには、独自のスタンドアロン・ドメインがそれぞれ作成されます。11gスタンドアロン・システム・コンポーネント(以前にドメインの関連付けをしていない)をアップグレードする場合、最初にシステム・コンポーネントに新規スタンドアロン・ドメインを作成する必要があります。
   • 「ドメイン・ディレクトリ」フィールドで、作成するドメインのフルパスを指定します。ドメイン・ホームがOracleホーム・ディレクトリの外部にある場合、『Oracle Fusion Middlewareのインストールのプランニング』の推奨ディレクトリ構造の理解に関する項に要約されているディレクトリ構造に従ってドメイン・ホームを配置することをお薦めします。このディレクトリ構造は、ソフトウェアのアップグレードや再インストールが必要になったときに問題を回避するために役立ちます。

     ヒント:

     「既存のドメインの更新」オプションは、別のシステム・コンポーネントのアップグレードまたは以前の部分的なOracle Data Integratorアップグレードのいずれかにより、アップグレードがすでに実行され、ドメインが作成されている場合に使用できます。このような場合、新規ドメインの作成が不要となります。

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

3. 「コンポーネント・リスト」画面で、構成をアップグレードするすべてのコンポーネントがリストに含まれていることを確認して「次へ」をクリックします。
   アップグレード対象のコンポーネントが表示されていない場合は、「戻る」をクリックして前の画面に戻り、別のドメインを指定します。
4. 「前提条件」画面ですべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次へ」をクリックします

   注意:

   アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。
5. 「インスタンス・ディレクトリ」画面で、アップグレード対象となる1つ以上のOracleインスタンス・ディレクトリの場所を指定します。
6. 「ノード・マネージャ」画面で、スタンドアロン・システム・コンポーネントのアップグレード時にドメインの作成に使用されるノード・マネージャの資格証明を指定します。
7. 「調査」画面で、各スタンドアロン・コンポーネントを調査した際のアップグレード・アシスタントのステータスを確認し、スタンドアロン・コンポーネント構成のアップグレード準備が整っていることを確認します。ステータスが「調査が終了しました。」になっている場合は、「次へ」をクリックします。
   調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、一般的なアップグレード・エラーの解決の詳細をUpgrade Assistantによるアップグレードのアップグレードのトラブルシューティングで参照してください。

   注意:

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

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

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

   「アップグレード」をクリックして、アップグレード・プロセスを開始します。

9. 「アップグレードの進行状況」画面でアップグレードのステータスを監視します。

   注意:

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

   注意:

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

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

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

    アップグレードが失敗した場合、「アップグレード失敗」画面で「ログの表示」をクリックし、エラーを表示してトラブルシューティングします。ログはORACLE_HOME/oracle_common/upgrade/logsにあります。アップグレードに失敗した場合、アップグレード前の環境をバックアップからリストアし、問題を修正して、アップグレード・アシスタントを再起動する必要があります。

サーバーおよびプロセスの起動

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

これらのコンポーネントは相互に依存する場合があるため、正しい順序で起動する必要があります。

注意:

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

Fusion Middleware環境を起動するには、次のステップに従います。

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

管理サーバーを起動する場合、管理サーバーで稼働しているWebLogic Server管理コンソールやFusion Middleware Controlなどのプロセスも起動します。

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

• (UNIX) NEW_DOMAIN_HOME/bin/startWebLogic.sh

• (Windows) NEW_DOMAIN_HOME\bin\startWebLogic.cmd

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

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

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

• (UNIX) NEW_DOMAIN_HOME/bin/startNodeManager.sh

• (Windows) NEW_DOMAIN_HOME\bin\startNodeManager.cmd

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

環境を構成しているOracle Internet DirectoryなどのOracle Identity Managementコンポーネントがあれば、それをすべて起動します。

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

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

ステップ4: 管理対象サーバーの起動

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

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

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

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

注意:

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

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

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

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

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

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

ステップ6: 外部認証への変更

スキーマをアップグレードする前に内部認証に変更した場合は、サーバーおよびプロセスを起動した後に外部認証に戻します。