9 WebCenter Sitesの以前の12cリリースからのアップグレード

以前の12cリリースからのアップグレードは、インプレース・アップグレードです。WebCenter Sitesを12.2.1.3.0にアップグレードするための12cの有効な開始ポイントは、WebCenter Sitesリリース12.2.1.0、12.2.1.0パッチ1、12.2.1.0パッチ2、12.2.1.1.0および12.2.1.2.0です。

ノート:

• アップグレード前の環境に行われた変更内容は、アップグレード・プロセス中に上書きされます。アップグレード後もそのまま使用できるように、カスタマイズされたファイルを共有ライブラリの場所に保存することをお薦めします。

• 既存のSites環境がデータベースへのNIOベースの共有ファイル・システムで構成されている場合は、アップグレード・プロセスを開始する前に、これをディスク・ストレージに戻します。

インプレース・アップグレードとアウトオブプレース・アップグレード間の違いに関する情報は、『Oracle Fusion Middlewareのアップグレードのプランニング』のインプレース・アップグレードとアウトオブプレース・アップグレード間の違いに関する項を参照してください。

ノート:

アップグレードする際に、要件にあわせて検討できる2つの方法があります。

1. 配信環境をアップグレードし、アップグレード後にそのクローンを作成して、開発環境と管理環境を作成します。

   この方法を検討する場合は、同期化が必要になります。アップグレードの前に、開発環境と管理環境から配信環境にコンテンツを公開する必要があります。その後、アップグレードした配信環境のクローンを作成して、開発環境と管理環境を作成します。

2. または、各環境を個別にアップグレードします。

   この方法を検討する場合、同期化は必要ありません。

次の各項のステップに従って、アップグレードを実行します。

• WebCenter Sitesの以前の12cリリースからのアップグレード・プロセスについて
  WebCenter Sitesのアップグレード・プロセスの概要に関するフローチャートとロードマップを確認します。
• 製品ディストリビューションのインストール
  アップグレードを開始する前に、ターゲット・システムに12c (12.2.1.3.0)のOracle Fusion Middleware InfrastructureおよびOracle WebCenter Sitesのディストリビューションをダウンロードし、Oracle Universal Installerを使用してインストールします。
• InsightsとともにSitesをインストールした場合...
  Oracle WebCenter Sites Insightsは12.2.1.1から非推奨になっています。その結果、アップグレード時に再構成テンプレートを使用できません。既存のデプロイメントにSites Insightsが含まれている場合は、このトピックのステップを実行する必要があります。
• アップグレード前の準備状況チェックの実行
  アップグレードにかかわる潜在的な問題を特定するために、アップグレード・プロセスの開始前に、準備状況チェックの実行をお薦めします。準備状況チェックでは、アップグレードの潜在的な問題をすべて発見できるわけではないことに注意してください。準備状況チェック・レポートが成功しても、アップグレードが失敗する場合があります。
• サーバーとプロセスの停止
  Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、すべてのアップグレード前のプロセス、および管理サーバーや管理対象サーバーを含めたすべてのサーバーを停止する必要があります。
• アップグレード・アシスタントを実行する前に
  アップグレード・アシスタントを実行して12.2.1.xのドメインをアップグレードする前に、このトピックにリストされているタスクを実行します。
• スキーマ・アップグレード実行前のチェックリスト
  
• 製品スキーマのアップグレード
  サーバーとプロセスの停止後に、Upgrade Assistantを使用して、サポートされている製品スキーマをOracle Fusion Middlewareの現在のリリースにアップグレードします。
• ドメインの再構成について
  再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.3.0)にあわせて再構成します。
• ドメイン・コンポーネント構成のアップグレード
  ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。
• サーバーおよびプロセスの起動
  正常なアップグレードの後に、管理サーバーや管理対象サーバーなど、すべてのプロセスおよびサーバーを再起動します。
• アップグレード後の検証タスク
  スキーマと構成が正常にアップグレードされた後でデータの整合性を確認するための、新しくアップグレードしたドメインで実行できる検証スクリプトが用意されています。検証の要約レポートをレビューして、スキーマと構成のアップグレード・プロセスの間にデータの不整合が発生していないか確認できます。
• アップグレード後のタスク
  アップグレード後のタスクには、カスタム設定のリストア、管理サーバーと管理対象サーバーの起動、パスワードの再構成、およびこのトピックにリストされているその他の管理タスクが含まれます。
• カスタムJavaライブラリまたは静的Webリソースの移行
  アップグレード前の環境でWebアプリケーションにカスタムJavaライブラリまたは静的Webリソースが追加されており、アップグレード後の環境でこれらを引き続き使用する場合にのみ、このオプション・ステップを実行します。

WebCenter Sitesの以前の12cリリースからのアップグレード・プロセスについて

WebCenter Sitesのアップグレード・プロセスの概要に関するフローチャートとロードマップを確認します。

図9-1 WebCenter Sitesの以前の12cリリースからのアップグレード・プロセスのフローチャート

「図9-1 WebCenter Sitesの以前の12cリリースからのアップグレード・プロセスのフローチャート」の説明

表9-1に、WebCenter Sitesを以前の12cリリースからアップグレードするために実行する必要がある、タスクのロードマップを示します。

表9-1 WebCenter Sitesの以前の12cリリースからのアップグレードに関するタスク

タスク	説明
必須 このガイドの概要に関するトピックを再確認して、アップグレード前のタスクを完了します(まだ実行していない場合)。	アップグレード前タスクには、ご使用の本番環境のクローニング、システム要件および資格証明の確認、未使用データのパージおよび非SYSDBAユーザーの作成が含まれます。 アップグレード前タスクの完全なリストは、「Oracle WebCenterコンポーネントのアップグレード前のタスク」を参照してください。 重要: アップグレード・プロセスを開始する前に、WebLogicドメイン、Sites構成ディレクトリ、Sites共有ディレクトリ、およびSitesスキーマをバックアップする必要があります。
必須 12c (12.2.1.3.0) Oracle Fusion Middleware InfrastructureおよびOracle WebCenter Sitesのディストリビューションをダウンロードおよびインストールします。	インフラストラクチャのディストリビューションには、その他のFusion Middleware製品をインストールするための基盤の設定に必要な、WebLogic ServerおよびJava Required Files (JRF)が同梱されています。 このガイドのアップグレード・トポロジに定義されているように、インフラストラクチャは新規のOracleホームにインストールする必要があります。 12.2.1.3.0Infrastructureをインストールすると作成されるOracleホームにOracle WebCenter Sitesのディストリビューションをインストールする必要があります。製品ディストリビューションをインストールするには、「製品ディストリビューションのインストール」の手順に従います。
WebCenter SitesをInsightsとともにインストールした場合は必要 拡張テンプレートを削除し、Insights、アプリケーション・サーバーinsights_server1、およびその依存関係へのコンポーネント参照をインストールします。	Oracle WebCenter Sites Insightsは、12.2.1.1から非推奨になっています。その結果、アップグレード時に再構成テンプレートを使用できません。既存のデプロイメントにSites Insightsが含まれている場合は、トピック「InsightsとともにSitesをインストールした場合...」のステップを実行する必要があります。
オプション アップグレード前の準備状況チェックを実行します。	「アップグレード前の準備状況チェックの実行」を参照してください。
必須 既存の環境を停止します(すべての管理サーバーと管理対象サーバーを停止します)。	警告: アップグレード中にサーバーを停止しないと、データが破壊される可能性があります。 「サーバーとプロセスの停止」を参照
必須 必要なタスクを実行してから、アップグレード・アシスタントを実行します。	アップグレード前のタスクは、アップグレード・アシスタントを使用してアップグレード・プロセスを開始する前に完了している必要がある、一連のタスクです。 これらのタスクは、「アップグレード・アシスタントを実行する前に」にリストされています。
必須 アップグレード・アシスタントを使用して製品スキーマをアップグレードします。	「製品スキーマのアップグレード」の手順に従い、アップグレード・アシスタントを使用して、アップグレード可能なスキーマ・コンポーネントをアップグレードします。
必須 既存の12cドメインを再構成します。	既存のドメインで再構成ウィザードを実行すると、再構成テンプレートを選択および適用してドメインのアップグレードの準備をします。 「ドメインの再構成について」で説明している手順に従って、ドメインを再構成します。
必須 ドメイン構成をアップグレードします。	「ドメイン・コンポーネント構成のアップグレード」で説明している手順に従い、アップグレード・アシスタントを使用して、12.2.1.0のドメインに含まれるすべての構成をアップグレードします。
必須 アップグレード後の検証タスクを実行します。	スキーマと構成が正常にアップグレードされた後でデータの整合性を確認するための、新しくアップグレードしたドメインで実行できる検証スクリプトが用意されています。検証の要約レポートをレビューして、スキーマと構成のアップグレード・プロセスの間にデータの不整合が発生していないか確認できます。 検証スクリプトを使用するには、「アップグレード後の検証タスク」を参照してください。
必須 その他のアップグレード後のタスクを実行します。	その他のアップグレード後のタスクには、カスタム設定のリストア、管理サーバーと管理対象サーバーの起動、パスワードの再構成、および「アップグレード後のタスク」にリストされているその他の管理タスクが含まれます。
必須 サーバーおよびプロセスを再起動します。	「サーバーとプロセスの起動」を参照してください。

製品ディストリビューションのインストール

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

ノート:

アップグレードにInfrastructureが必要な場合は、その他のFusion Middleware製品をインストールする前に、まずOracle Fusion Middlewareディストリビューションをインストールする必要があります。

Oracle HTTP Serverなど、ドメインを構成するすべてのOracle製品をダウンロードおよびインストールしたことを確認します。12.2.1.3.0バイナリは、新規のOracleホームにインストールする必要があります。既存のOracleホームと同じホスト上である必要があります。

12c (12.2.1.3.0)ディストリビューションをインストールするには:

1. ターゲットのシステムにサインインします。
2. Oracle Technology NetworkまたはOracle Software Delivery Cloudから次のものをターゲット・システムにダウンロードします。
   • Oracle Fusion Middlewareインフラストラクチャ (fmw_12.2.1.3.0_infrastructure_generic.jar)
   • Oracle WebCenter Sites (fmw_12.2.1.3.0_wcsites_generic.jar)
3. 12c (12.2.1.3.0)製品のディストリビューションをダウンロードしたディレクトリに移動します。
4. Oracle Fusion Middleware Infrastructureのインストール・プログラムを開始します。
   • (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.3.0_infrastructure_generic.jar
   • (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.3.0_infrastructure_generic.jar
5. UNIXオペレーティング・システムでは、このホストにOracle製品を初めてインストールする場合に、「インストール・インベントリの設定」画面が表示されます。
   中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名に対して中央インベントリの場所への書込み権限が付与されていることを確認し、「次」をクリックします。

   ノート:

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

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

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

   • 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インフラストラクチャ」を選択します。
   • Oracle WebCenter Sitesの場合は、「WebCenter Sites」を選択します。

     ノート:

     「WebCenter Sites - 例付き」ではなく、「WebCenter Sites」を選択していることを確認してください。

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

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

12. 「インストールの進行状況」画面で、プログレス・バーが100%完了になったら、「終了」をクリックしてインストーラを閉じるか、「次へ」をクリックしてサマリーを表示します。
13. 「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。情報を確認し、「終了」をクリックしてインストーラを閉じます。
14. Oracle Fusion Middleware Infrastructureのインストール後に、次のコマンドを入力して、製品ディストリビューションのインストーラを起動し、前述のステップを繰り返してインストーラの各画面を移動します。
    (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.3.0_wcsites_generic.jar
    (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.3.0_wcsites_generic.jar

InsightsとともにSitesをインストールした場合...

Oracle WebCenter Sites Insightsは、12.2.1.1から非推奨になっています。その結果、アップグレード時に再構成テンプレートを使用できません。既存のデプロイメントにSites Insightsが含まれている場合は、このトピックのステップを実行する必要があります。

ノート:

12.2.1.0からアップグレードしており、Oracle WebCenter SitesをInsightsとともにインストールした場合にのみ、この手順を実行します。

アップグレード前の準備状況チェックの前または再構成ウィザードの実行前に次のステップを実行します。

1. Insightsをインストールしたホストにサインインします。既存のドメインの完全なバックアップを作成します。
2. domain-info.xmlファイルから、Insightsへの拡張テンプレート参照を削除します。
   1. 次のディレクトリに変更します。
      (UNIX) EXISTING_ORACLE_HOME/user_projects/domains/DOMAIN_NAME/init-info/domain-info.xml
      (Windows) EXISTING_ORACLE_HOME\user_projects\domains\DOMAIN_NAME\init-info\domain-info.xml
   2. domain-info.xmlファイルを編集のために開きます。
   3. name "Oracle WebCenter Sites - Insights"を含む<extention-template-ref>を削除します。
   4. ファイルを保存して閉じます。
3. domain-info.xmlファイルから、Insightsへのインストール・コンポーネント参照を削除します。
   1. 次のディレクトリに変更します。
      (UNIX) EXISTING_ORACLE_HOME/user_projects/domains/DOMAIN_NAME/init-info/domain-info.xml
      (Windows) EXISTING_ORACLE_HOME\user_projects\domains\DOMAIN_NAME\init-info\domain-info.xml
   2. domain-info.xmlファイルを編集のために開きます。
   3. name="oracle.wcsites.insights"を含む<install-comp-ref>を削除します。
   4. ファイルを保存して閉じます。
4. config.xmlファイルから、アプリケーション・サーバーinsights_server1とその依存関係を削除します。
   1. 次のディレクトリに変更します。
      (UNIX) EXISTING_ORACLE_HOME/user_projects/domains/DOMAIN_NAME/config/config.xml
      (Windows) EXISTING_ORACLE_HOME\user_projects\domains\DOMAIN_NAME\config\config.xml
   2. config.xmlファイルを開いて編集します。
   3. アプリケーション・サーバーinsights_server1とその依存関係を削除します。
   4. ファイルを保存して閉じます。

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

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

• アップグレード前の準備状況チェックの実行について
  Upgrade Assistantを-readinessモードで実行することで、実際のアップグレードを実行する前に問題を検出できます。準備状況チェックは、アップグレード・アシスタントを使用してGUIモードで実行するか、またはレスポンス・ファイルを使用してサイレント・モードで実行できます。
• 準備状況モードでのUpgrade Assistantの起動
  -readinessパラメータを使用して、Upgrade Assistantを準備状況モードで起動します。
• Upgrade Assistantでの準備状況チェックの実行
  Upgrade Assistantの各画面を通じて、アップグレード前の準備状況チェックを完了します。
• 準備状況レポートの理解
  ドメインの準備状況チェックを実行した後、レポートを確認してアップグレードを成功させるためのアクションをとる必要があるかどうかを判断します。

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

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

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

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

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

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

ノート:

パフォーマンスが影響されることを回避するために、オフピーク時に準備状況チェックを実行することをお薦めします。

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

-readinessパラメータを使用して、アップグレード・アシスタントを準備状況モードで起動します。

Upgrade Assistantを使用して、アップグレード前の環境に対する準備状況チェックを実行するには:

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

   ノート:

   DISPLAY環境変数がGUIモードを使用できるように適切に設定されていない場合、次のエラーが表示される場合があります。

   Xlib: connection to ":1.0" refused by server
   Xlib: No protocol specified 

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

   DISPLAY変数を設定してもこれらのエラーが発生し続ける場合は、vncconfigなどの他のGUIツールの起動を試みてください。同じエラーが表示される場合は、DISPLAY環境変数が正しく設定されていない場合があります。

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

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

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

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

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

パラメータ	必須またはオプション	説明
-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	オプション	アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 (UNIX) NEW_ORACLE_HOME/oracle_common/upgrade/logs NEW_ORACLE_HOME/oracle_common/upgrade/temp (Windows) NEW_ORACLE_HOME/oracle_common/upgrade/logs NEW_ORACLE_HOME/oracle_common/upgrade/temp
-help	オプション	すべてのコマンドライン・オプションを表示します。

アップグレード・アシスタントを使用した準備状況チェックの実行

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

準備状況チェックは、サポートされるアップグレードの開始点にあるスキーマまたはコンポーネント構成に対してのみ実行されます。

準備状況チェックを完了するには:

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. 「準備状況の終了」画面で、準備状況チェックの結果(「準備状況成功」または「準備状況失敗」)を確認します。

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

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

準備状況レポートの理解

ドメインの準備状況チェックを実行した後、レポートを確認してアップグレードを成功させるためのアクションをとる必要があるかどうかを判断します。

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

readiness_timestamp.txt

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

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

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

レポートの情報	説明	必要なアクション
全体的な準備状況ステータス: SUCCESSまたはFAILURE	レポートの上部に、準備状況チェックが合格したか1つ以上のエラーで完了したかが示されます。	1つ以上のエラーが発生してレポートが完了した場合、アップグレードを試みる前に、FAILを検索し、障害の原因となった問題を修正します。準備状況チェックは、アップグレードする前に必要に応じて何度でも再実行できます。
タイムスタンプ	レポートが生成された日付と時刻です。	必要なアクションはありません。
ログ・ファイルの場所 NEW_ORACLE_HOME/oracle_common/upgrade/logs	生成されたログ・ファイルのディレクトリの場所です。	必要なアクションはありません。
準備状況レポートの場所 NEW_ORACLE_HOME/oracle_common/upgrade/logs	生成された準備状況レポートのディレクトリの場所です。	必要なアクションはありません。
チェックされたコンポーネントの名前	チェックに含まれるコンポーネントの名前およびバージョンとステータス。	ドメインに、このリリースにアップグレードできないSOAコア拡張機能などのコンポーネントが含まれる場合は、アップグレードを試行しないでください。
チェックされたスキーマの名前	チェックに含まれるスキーマの名前および現在のバージョンとステータス。	スキーマのバージョン番号をレビューします。ドメインに、このリリースにアップグレードできないスキーマが含まれる場合は、アップグレードを試行しないでください。
個別のオブジェクトのテスト・ステータス: FAIL	準備状況チェックのテストで、特定のオブジェクトに問題が検出されています。	失敗した問題がすべて解決されるまではアップグレードしないでください。
個別のオブジェクトのテスト・ステータス: PASS	準備状況チェックのテストでは、特定のオブジェクトに問題が検出されませんでした。	準備状況チェック・レポートに「成功」ステータスのみが表示されている場合は、環境をアップグレードできます。ただし、準備状況チェックでは、ハードウェアやアップグレード時の接続性などの外部環境に関する問題を検出することはできません。アップグレードの進捗を常に監視する必要があります。
<オブジェクト>の準備状況チェックの完了ステータス: FAILURE	準備状況チェックで、スキーマ、索引またはデータ型などの特定のオブジェクトに対して解決する必要がある1つ以上のエラーが検出されました。	失敗した問題がすべて解決されるまではアップグレードしないでください。
<オブジェクト>の準備状況チェックの完了ステータス: 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: NEW_ORACLE_HOME/oracle_common/upgrade/logs/ua2016-05-30-11-14-06AM.log
Readiness Check Report File: NEW_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: [e-mail]
     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.

12.1.3.0バージョンのOracle Fusion Middleware IAU Schemasを実行しており、それらのスキーマが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で作成されていた場合は発生しません。

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

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

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を入力します。

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

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

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

アップグレード・アシスタントを実行する前に

アップグレード・アシスタントを実行して12.2.1.xのドメインをアップグレードする前に、このトピックにリストされているタスクを実行します。

アップグレード・アシスタントを実行する前に、次のことを実行します。

1. ソースがクラスタ環境である場合は、プライマリ・ノードからドメインを圧縮し、それをセカンダリ・クラスタ・メンバー上に解凍します。
   1. セカンダリ・ノードのSitesのconfigフォルダを、プライマリ・ノードのもので置換します。
   2. EXISTING_DOMAIN_HOME/wcsites/wcsites/config/にある次のxmlファイルを更新します。

      • jbossTicketCacheReplicationConfig.xml:

        bind_addrプロパティを、このクラスタ・ノードの有効なホストまたはIPアドレスで正しく更新します。

        ノート:

        multicastGroupPortの値を、2048より大きい一意の値に変更することをお薦めします。jbossTicketCacheReplicationConfig.xmlで使用するマルチキャスト・ポートは、クラスタ内の各ノードで同じであるが、同じネットワーク上で実行されている他のクラスタでは異なることを確認してください。

      • cas-cache.xml:

        IPv6アドレスを使用している場合は、multicastGroupAddressの値を有効なIPv6マルチキャスト・アドレスに設定します。この値は、クラスタ内の各ノードで同一にする必要があります。たとえば、[ff0x:0:0:0:0:0:0:301]などです。

        timeToLiveパラメータに、環境に適した値を設定します(通常は1)。クラスタ・メンバーがすべて同じマシン上に配置されていない場合は、timeToLiveフィールドをデフォルト値の0から変更する必要があります。このフィールドは、次の表に示すように、クラスタ化マシンの分布に基づいて設定する必要があります。

        表9-4 timeToLiveの値の説明

        timeToLiveの値	説明
        1	同じサブネットに限定されるマルチキャスト・パケット。
        32	同じサイトに限定されるマルチキャスト・パケット。
        64	同じ地理的領域に限定されるマルチキャスト・パケット。
        128	同じ大陸に限定されるマルチキャスト・パケット。
        256	制限なし。

        このステップを、cs-cache.xml、linked-cache.xmlおよびss-cache.xmlの各ファイルで繰り返します。

2. 管理サーバーを起動し、続いて次の場所に移動して、新しいSitesのセキュリティJARの権限を付与します。
   EXISTING_DOMAIN_HOME/wcsites/bin/grant-opss-permission

   その後、管理サーバーを停止します。

3. xml構成ファイルに対するカスタム設定をリストアします。

   DB2の場合:

   1. ドメイン・クラスパスに、db2jcc.jarおよびdb2jcc_license_cu.jarの各ファイルを元どおり追加します。
   2. テキスト・エディタを使用して、次の場所にあるsetDomainEnv.shファイルを編集します。
      DOMAIN_HOME/bin
      次のテキストを探します。
      # ADD EXTENSIONS TO CLASSPATHS
      # ADD EXTENSIONS TO CLASSPATHSの後に次の行を追加します。
      PRE_CLASSPATH="path_to_db2jcc.jar:path_to_db2jcc_license_cu.jar:${PRE_CLASSPATH}
   3. setDomainEnv.shファイルを保存します。
4. 再構成プロセスの後にxml構成ファイル(たとえば、MobilityService.xmlなどのxmlファイル)に対して実行されたカスタマイズをリストアします。

スキーマ・アップグレード実行前のチェックリスト

アップグレード・スクリプトでは、様々なリリースごとに異なる表が追加されます。アップグレード前に、スキーマ内に存在する表と同じ名前の表を追加しないことを確認してください。

たとえば、12.2.1.2.0から12.2.1.3.0にアップグレードする場合、EloquaForms表は12.2.1.1.0で導入されているため受入可能です。しかし、CECSAudit表は、アップグレード前のスキーマ内では予期されません。

次に、12.2.1.1.0に追加された表のリストを示します。

• EloquaForm

• EloquaInstallations

• EloquaInstances

• AVISPORTS Sample

• FileResource

• FileResource_Dim

• FileResource_DimP

• FileResource_Rtgs

次に、12.2.1.3.0に追加された表のリストを示します。

• ContentCloud

• ContentCloudAudit

• ContentCloudPubTargets

• ContentCloud_Dim

• ContentCloud_DimP

• ContentCloud_Q

• ContentCloud_Rtgs

• WCS_ContentCloudSubtype

Upgrade Assistantを起動する前に、Sitesスキーマからこれらの表を削除または名前変更することをお薦めします。

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

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

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

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

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

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

Upgrade Assistantを起動するには:

ノート:

Upgrade Assistantを起動する前に、Upgrade Assistantが稼働している環境に対して、JVM文字エンコードがUTF-8に設定されていることを確認します。文字エンコードがUTF-8に設定されていない場合、それらの名前にUnicode文字が含まれているファイルをダウンロードすることはできません。これによってアップグレードが失敗することがあります。

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

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

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

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

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

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

パラメータ	必須またはオプション	説明
-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	オプション	アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 (UNIX) NEW_ORACLE_HOME/oracle_common/upgrade/logs NEW_ORACLE_HOME/oracle_common/upgrade/temp (Windows) NEW_ORACLE_HOME/oracle_common/upgrade/logs NEW_ORACLE_HOME/oracle_common/upgrade/temp
-help	オプション	すべてのコマンドライン・オプションを表示します。

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

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

Upgrade Assistantを使用して、製品スキーマをアップグレードするには:

1. 「ようこそ」画面には、Upgrade Assistantの概要と、アップグレード前のいくつかの重要なタスクについての情報が示されます。「次へ」をクリックします。

   ノート:

   Upgrade Assistantの画面の詳細は、画面上の「ヘルプ」をクリックしてください。
2. 「選択したスキーマ」画面で、「個別に選択されたスキーマ」または「ドメインで使用されるすべてのスキーマ」を選択して、WebCenter Sitesで使用されるすべてのコンポーネントのスキーマをアップグレードします。「次へ」をクリックします。
   Upgrade Assistantで、スキーマのアップグレードに使用可能なコンポーネントが識別されます。WebCenter Sitesで使用されるコンポーネントは次のとおりです。

   • Oracle Audit Services

   • Oracle Platform Security Services

   • Common Infrastructure Services

   • Oracle WebLogicServer

   • Oracle WebCenter Sites

3. 「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、ステップ2に示されているOracle WebCenter Sitesおよび他のコンポーネントを選択します。「次へ」をクリックします。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。
4. 「前提条件」画面で、すべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次へ」をクリックします。

   ノート:

   アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。
5. 「WebCenter Sitesソース・バージョン」画面で12.2.1.0.0以降を選択し、「次」をクリックします。これはアップグレードの開始ポイントです。
6. 「WebCenter Sitesソース・スキーマ」画面で、「データベース・タイプ」ドロップダウン・リストからデータベース・タイプを選択します。
   データベース接続文字列を次の書式で「データベース接続文字列」フィールドに指定します。
   • (Oracle Database) host:port/serviceまたはhost:port:SIDまたはTNS connect string
   • (Microsoft SQL Server) //host:port;DatabaseName=dbname
   • (IBM DB2) //host:port;DatabaseName=dbname
   「DBAユーザー名」フィールドに、ユーザー名とDBA権限を指定します。「DBAパスワード」フィールドに、DBAパスワードを指定します。
   「スキーマ・ユーザー名」フィールドと「スキーマ・パスワード」フィールドに、スキーマのユーザー名とパスワードをそれぞれ指定します。

   ノート:

   DB2データベース・スキーマのアップグレードについて、WebCenter SitesではWebLogicで提供されるものとは異なるドライバ・クラスが使用されるため、「選択したスキーマ」画面で「ドメインで使用されるすべてのスキーマ」を選択する場合、Oracle WebCenter Sitesコンポーネントは表示されません。そのため、「個別に選択されたスキーマ」を選択して、WebCenter Sitesで使用される残りのコンポーネントとは別にOracle WebCenter Sitesスキーマをアップグレードする必要があります。

7. 「WebCenter Sitesの場所」画面で、既存のSitesホームおよびSites共有ディレクトリの完全な場所と、12cの構成ファイル(wcs_properties.json)の場所を指定します。
   「次へ」をクリックします。
8. 「調査」画面で、各スキーマを調査したUpgrade Assistantのステータスを確認して、スキーマのアップグレードの準備が整っていることを検証します。ステータスが「調査が終了しました。」になっている場合は、「次」をクリックします。
   調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、一般的なアップグレード・エラーの解決の詳細をUpgrade Assistantによるアップグレード のアップグレードのトラブルシューティングで参照してください。

   ノート:

   • 確認フェーズ中に検出された問題を、アップグレードを進めずに解決した場合は、バックアップからリストアを再び行わずにUpgrade Assistantを開始できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックしてアップグレードを続行していた場合は、Upgrade Assistantを再開する前に、バックアップからアップグレード前の環境をリストアする必要があります。

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

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

    注意:

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

    ノート:

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

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

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

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

    ノート:

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

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

すべてのアップグレード・ステップを完了したら、schema_version_registryのスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードの成功を検証します。

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

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

問合せ結果について:

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

  ノート:

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

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

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

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

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

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

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

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

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

• ドメイン・バージョン

ノート:

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

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

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

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

• アップグレードするインストールでOracle Access Management (OAM)が使用されない場合は、2つのファイルを編集して、再構成ウィザードが、存在しないOAMインフラストラクチャ・スキーマの更新(アップグレードが失敗する)を試みないようにする必要があります。

  $DOMAIN/init-info/domain-info.xmlに次の例のような行をコメント・アウトします。

  <!--extention-template-ref name="Oracle Identity Navigator" 
    version="11.1.1.3.0" 
    location="/u01/app/oracle/product/fmw/iam111130/common/templates/applications/oracle.oinav_11.1.1.3.0_template.jar" 
    symbol=""/-->
  
  <!--install-comp-ref name="oracle.idm.oinav" version="11.1.1.3.0" 
    symbol="oracle.idm.oinav_11.1.1.3.0_iam111130_ORACLE_HOME" 
    product_home="/u01/app/oracle/product/fmw/iam111130"/-->

  また、同様に、$DOMAIN/config/config.xmlに次の例のような行をコメント・アウトします。

  <!--app-deployment> 
    <name>oinav#11.1.1.3.0</name>
    <target>AdminServer</target>
    <module-type>ear</module-type>
  
    <source-path>/u01/app/oracle/product/fmw/iam111130/oinav/modules/oinav.ear_11.1.1.3.0/oinav.ear</source-path>
    <deployment-order>500</deployment-order>
    <security-dd-model>DDOnly</security-dd-model>
    <staging-mode>nostage</staging-mode>
  </app-deployment-->
  

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

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

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

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

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

ノート:

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

再構成ウィザードを使用して既存のドメインを再構成する手順に従います。Oracle WebLogic ServerのアップグレードのWebLogicドメインの再構成を参照してください。

• ドメインのバックアップ
  
• 再構成ウィザードの起動
  
• 再構成ウィザードを使用したWebCenter Sitesドメインの再構成
  再構成ウィザードの各画面を移動して、既存のドメインを再構成します。

ドメインのバックアップ

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

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

1. コンテンツを保持するには、ソース・ドメインを別の場所にコピーします。
   (Windows) copy C:\domains\mydomain to C:\domains\mydomain_backup。
   (UNIX) cp mydomain /domains/mydomain_backup
2. 各リモート管理対象サーバーのドメインを更新する前に、各リモート・マシンのドメイン・ディレクトリのバックアップ・コピーを作成します。
3. ドメインのバックアップしたバージョンが完全であることを確認します。

なんらかの理由でドメインの再構成が失敗した場合は、すべてのファイルおよびディレクトリをバックアップ・ディレクトリから元のドメイン・ディレクトリにコピーしてドメインを完全に再構成前の元の状態に戻す必要があります。

再構成ウィザードの起動

ノート:

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

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

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

   ALTER DATABASE DEFAULT EDITION = edition_name;

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

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

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

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

   ノート:

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

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

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

   CONFIG_JVM_ARGS=-Dpython.cachedir=valid_directory

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

再構成ウィザードの各画面を通じて、既存のドメインを再構成します。

ノート:

すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。欠落としてレポートされたテンプレートが表示されている場合、ドメインに該当するOracle製品をインストールしたかどうかを確認します。たとえば、既存のドメインにOracle HTTP Serverが含まれている場合は、12c (12.2.1.3.0)のOracle HTTP Server製品ディストリビューションをインストールしていることを確認します。

ノート:

ソースがクラスタ化環境の場合、プライマリ・ノードでのみ再構成ウィザードを実行します。圧縮/解凍ユーティリティを使用して、ドメイン内の他のクラスタ・メンバーに変更を適用します。

再構成ウィザードを使用してドメインを再構成するには:

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

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

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

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

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

   ノート:

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

   ノート:

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

   ノート:

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

   ノート:

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

   ノート:

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

   ノート:

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

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

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

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

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

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

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

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

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

Upgrade Assistantを起動するには:

ノート:

Upgrade Assistantを起動する前に、Upgrade Assistantが稼働している環境に対して、JVM文字エンコードがUTF-8に設定されていることを確認します。文字エンコードがUTF-8に設定されていない場合、それらの名前にUnicode文字が含まれているファイルをダウンロードすることはできません。これによってアップグレードが失敗することがあります。

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

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

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

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

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

表9-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	オプション	アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 (UNIX) NEW_ORACLE_HOME/oracle_common/upgrade/logs NEW_ORACLE_HOME/oracle_common/upgrade/temp (Windows) NEW_ORACLE_HOME/oracle_common/upgrade/logs NEW_ORACLE_HOME/oracle_common/upgrade/temp
-help	オプション	すべてのコマンドライン・オプションを表示します。

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

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

再構成ウィザードを実行してWebLogicドメインを12c (12.2.1.3.0)に再構成した後に、アップグレード・アシスタントを実行して、ドメイン・コンポーネント構成を、更新されたドメイン構成に一致するようにアップグレードする必要があります。

Upgrade Assistantを使用して、ドメイン・コンポーネント構成をアップグレードするには:

1. 「ようこそ」画面には、Upgrade Assistantの概要と、アップグレード前のいくつかの重要なタスクについての情報が示されます。「次へ」をクリックします。

   ノート:

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

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

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

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

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

   ノート:

   アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。
5. 「WebCenter Sitesソース・バージョン」画面で12.2.1.0.0以降を選択し、「次」をクリックします。これはアップグレードの開始ポイントです。
6. (単一サーバー環境)ソースが単一サーバー環境である場合は、「WebCenter Sitesソースの詳細」画面が表示されます。
   「WebCenter Sitesソース・クラスタの詳細」画面で、Source_Version (12.2.1.0 or 12.2.1.1) Sitesインストール・ディレクトリとSource_Version Sitesデプロイメント・ディレクトリの完全パスを指定し、「アップグレード」をクリックします。
   「参照」をクリックして、ナビゲーション・ツリーを使用して特定のディレクトリを選択することもできます。
7. (クラスタ環境)ソースがクラスタ環境である場合は、「WebCenter Sitesソースの詳細」画面が表示されます。
   各ノードのSource_Version Sitesインストール・ディレクトリおよびSource_Version Sitesデプロイメント・ディレクトリを、ソースSource_Version Sitesインストール・ディレクトリ・フィールドとソースSource_Version Sitesデプロイメント・ディレクトリ・フィールドにそれぞれ指定します。
   Sitesデプロイメント・ディレクトリの例を次に示します。

   • (Tomcat) TOMCAT_HOME/webapps/sites

   • (WebSphere) WAS_HOME/installableApps/sites

   • (WebLogic) DOMAIN_HOME/manual/sites

   「参照」をクリックして、ナビゲーション・ツリーを使用して特定のディレクトリを選択することもできます。
   Source_Versionのディレクトリを指定したら、「アップグレード」をクリックします。

   ノート:

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

   ノート:

   • 確認フェーズ中に検出された問題を、アップグレードを進めずに解決した場合は、バックアップからリストアを再び行わずにUpgrade Assistantを開始できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックしてアップグレードを続行していた場合は、Upgrade Assistantを再開する前に、バックアップからアップグレード前の環境をリストアする必要があります。

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

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

    注意:

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

    ノート:

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

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

11. 構成のアップグレードが成功した場合は、次の場所にサマリー・ファイルが生成されます。
    NEW_ORACLE_HOME/oracle_common/upgrade/logs/
    ソース(12.2.1.0または12.2.1.1)がクラスタ環境である場合、サマリー詳細は次のようにクラスタごとに生成されます。
    NEW_ORACLE_HOME/oracle_common/upgrade/logs/
    ソース(12.2.1.0または12.2.1.1)が単一サーバー環境である場合は、次の3つのサマリー・ファイルが生成されます。

    • PropertyMigration_Summary.txt (プロパティの移行サマリー)
    • HomeMigration_Summary.txt (Siteホームの移行サマリー)
    • SharedMigration_Summary.txt (Sites共有の移行サマリー)
    スキーマのアップグレードが失敗した場合は、考えられるエラーをログでレビューします。ログ・ファイルは次の場所に生成されます。
    NEW_ORACLE_HOME/oracle_common/upgrade/logs
    「閉じる」をクリックしてアップグレード・アシスタントを閉じます。

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

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

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

Oracle Enterprise Manager Fusion Middleware Control Consoleにサインインするには、次に移動します。http://administration_server_host:administration_server_port/em

ノート:

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

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

Upgrade Assistantを実行するためにFMWユーザーを作成した場合は、アップグレードが成功したことを確認してからアカウントを削除してください。

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

正常なアップグレードの後に、管理サーバーや管理対象サーバーなど、すべてのプロセスおよびサーバーを再起動します。

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

ノート:

この項の手順では、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

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

アップグレード後の検証タスク

スキーマと構成が正常にアップグレードされた後でデータの整合性を確認するための、新しくアップグレードしたドメインで実行できる検証スクリプトが用意されています。検証の要約レポートをレビューして、スキーマと構成のアップグレード・プロセスの間にデータの不整合が発生していないか確認できます。

検証スクリプトを実行するには:

1. 検証スクリプトは次の場所にあります。
   (UNIX) NEW_Oracle_Home/wcsites/plugins/upgrade/
   (UNIX) ./validation.sh
   (Windows) NEW_Oracle_Home\wcsites\plugins\upgrade\
   (Windows) validation.bat
2. 検証チェックが完了すると、検証サマリー・レポート(Validation.txt)が生成されます。これをシステム上の任意の場所に保存します。
3. 検証サマリー・レポートをレビューして、既存のドメインと新しく構成した12.2.1.3.0のドメインの間にデータの不整合がないかチェックします。

   ノート:

    ソース(11.1.1.8)環境でパッチ12以上を使用している場合、web.xmlの比較レポートには、ターゲット(12.2.1.3.0)環境に存在する差異が表示されます。ターゲット(12.2.1.3.0)環境で利用可能なサマリー・レポートに示されている変更は無視できます。

アップグレード後のタスク

アップグレード後のタスクには、カスタム設定のリストア、管理サーバーと管理対象サーバーの起動、パスワードの再構成、およびこのトピックにリストされているその他の管理タスクが含まれます。

WebCenter Sites 12.2.1.3.0にアップグレードした後に、次の手順を実行します。

1. カスタム設定を既存の環境から12.2.1.3.0環境にリストアまたは再デプロイします。
   これには、Javaライブラリや静的Webリソースに対するカスタム変更、または要素の変更が含まれます。
   Javaライブラリまたは静的Webページに加えた変更をリストアするには、「カスタムJavaライブラリまたは静的Webリソースの移行」を参照してください。

   ノート:

   • WebCenter Sites 12cではODLロギング・フレームワークを使用しており、11g環境で設定されているカスタムLog4jログ・レベルはODLロギングに移行されません。これらのレベルはアップグレード後にリセットできます。

   • 11g MobilityService.xmlで行われたカスタマイゼーション(例: WURLFサービス)は、12.2.1.3.0 xmlに手動でポートする必要があります。

2. 管理サーバーと管理対象サーバーを起動します。「サーバーとプロセスの起動」を参照してください。

   ノート:

   管理サーバーまたは管理対象サーバーを起動する前に、ブラウザでキャッシュされたイメージおよびファイルをクリアしてください。

3. パブリッシュ・プロセスのパスワードを再構成します。
   1. 管理サーバーURLに管理者としてサインインします。
   2. 「管理」メニューに移動し、「パブリッシュ」の下の「宛先」をクリックします。
   3. パブリッシュの宛先URL、ポート、ユーザー名、パスワードを更新します。
4. 外部WebRootが構成されている場合は、Sites管理ユーザー・インタフェースからWebRootを更新します。
5. ソースがクラスタ環境であった場合は、configディレクトリのxmlファイル設定を、アップグレード・アシスタントを実行したソース環境から、アップグレード後の環境にあるその他のすべてのノードにコピーします。
   例を次に示します。

   • cs-cahe.xml
   • cas-cache.xml
   • ss-cache.xml
   • linked-cache.xml
   • MobilityServices.xml
   • Custom/RestResources.xml
   • wcs_properties_bootstrap.ini

     ノート:

     Lucene検索索引は、アップグレード・プロセスでの処理中に再度有効になります。アップグレード後のプロセスで索引が完全に再構築されるまで、コントリビュータUIの検索結果が遅延する可能性があります。
6. (SQLサーバーを使用している場合にのみ該当) Fusion Middleware Infrastructureのリリース12cでは、SQL Serverデータベースが大/小文字区別モードで構成されている必要があります。結果として、WebCenter Sitesによって提供されるics:sql jspタグでは、表値がデータベースで使用されているのと同じ大/小文字であることが必要になります。
   ics:sql文の構文を次に示します。

   <ics:sql
         sql="sql commands"
         listname="list name"
         table="name of table"
         [limit="max number of results"]/>

   SQL Serverデータベースで指定されているのと同じ大/小文字で表の名前を指定する必要があります。

7. 次のプロパティは、Sites構成設定プロセスでの処理中に指定した、アプリケーション管理者ユーザー・アカウント値にリセットされます。
   • xcelerate.batchuserおよびパスワード
   • cs.emailpassword
   プロパティ管理ツールを使用して、これらのプロパティを適切な値に更新する必要があります。
8. WCCの統合後に、WCC構成のwcc.server.passwordをリセットして、マップされたすべてのルールを表示します。
9. インスタンスが配信であり、サンプル・サイトが公開されている場合は、アップグレードされた開発インスタンスからサンプル・サイトを配信インスタンスに再公開する必要があります。
10. (以前の12cリリースのみからアップグレードしている場合およびSitesがRSSおよびサイト・キャプチャとともに同じドメインにインストールされている場合)
    1. RSSおよびサイト・キャプチャを含むSitesを12.2.1.0以降のリリースから12c (12.2.1.3.0)にアップグレードしている場合は、新しいドメインを作成し、RSSおよびサイト・キャプチャを再度インストールする必要があります。
    2. 同じポートにサイト・キャプチャをインストールしていない場合は、次の手順を実行します。

       1. Sites内のサイト・キャプチャのFW_View表およびFW_Application表のサイト・キャプチャ・ポートを変更します。

       2. valid.urlsプロパティのポート番号を変更します。

       3. SiteCaptureカテゴリのその他のプロパティのポート番号を変更します。

    3. RSSのインストール後に、RSSがSystemSatellite表のRSSポートにインストールされていない場合は、このポートを変更します。

カスタムJavaライブラリまたは静的Webリソースの移行

アップグレード前の環境でWebアプリケーションにカスタムJavaライブラリまたは静的Webリソースが追加されており、アップグレード後の環境でこれらを引き続き使用する場合にのみ、このオプション・ステップを実行します。

WebアプリケーションにカスタムJavaライブラリ(jarファイル)またはカスタムWebリソース(css、js、イメージなど)が含まれている場合は、アップグレード後に、それらをアップグレード後の環境に手動で移行する必要があります。これらのリソースを移行しないと、アップグレード後の環境でその機能にアクセスできなくなります。

WebCenter SitesのWebアプリケーションは、WARファイルとして出荷されます。Webアプリケーションは、最初に構成ウィザードの処理中にデプロイされ、アプリケーション・ライフサイクルでの処理中に何度でも再デプロイすることができます。変更はアップグレード・プロセスでの処理中に上書きされるため、実装固有のカスタマイズをSites WARファイルに含めないことをお薦めします。

WebLogic Server共有ライブラリ・フレームワークを拡張する場合、Sitesではextend.sites.webapp-lib.warが共有ライブラリとして提供されます。このファイルはNEW_ORACLE_HOME/wcsites/webcentersites/sites-home/ディレクトリにあります。静的Webリソースなどの実装固有のカスタマイズやJAVAライブラリを、このWARファイルに含めることができます。この共有ライブラリは、アプリケーションのライフサイクルの進行中にデプロイされ、Sitesと同じコンテキスト・ルーツ(/sites/)を共有します。この共有ライブラリのコンテンツは、パッチ適用プロセスでの処理中に上書きされることはありません。

また、Sites UIがカスタマイズされている場合は、コードの変更もアップグレード後の環境に移行する必要があります。