1. Oracle WebCenterのアップグレード
  2. 停止時間が短縮されたアップグレード・プロセスについて

B 停止時間が短縮されたアップグレード・プロセスについて

停止時間が短縮されたアップグレードを実行する場合は、Oracle Fusion Middlewareのアップグレード・プロセスの概要に関するフローチャートとロードマップを再確認します。

停止時間が短縮されたアップグレード・プロセスは、標準のFusion Middlewareアップグレード・プロセスとは異なります。このタイプのアップグレードでは、停止時間が短縮されたアップグレードを実現するために、少なくとも2ノードのクラスタ環境が必要であり、1つのノードが常に稼働するようにローリング方式で実行されます。標準のアップグレード・フローでは、アップグレードを開始する前にすべてのサーバーおよびプロセスが停止します。

停止時間が短縮されたアップグレードを開始する前に:
  • データベース・スキーマをバックアップします。
  • ドメイン・ディレクトリおよびアプリケーション・ディレクトリをバックアップします。
  • UI/同様のカスタマイズをバックアップします。

バックアップの詳細は、「完全なバックアップの作成」を参照してください。

必要なバックアップを作成した後、以前のバージョンのソフトウェアをアンインストールして、新しい製品ディストリビューションのインストールに空のOracleホームを使用できるようにします。これが、2つのアップグレード・プロセスの主な違いです。また、製品でスキーマまたは構成(あるいはその両方)のアップグレードが必要な場合は、アップグレード・アシスタントを2回(スキーマのアップグレードと構成のアップグレードにそれぞれ1回ずつ)実行する必要があります。

ノート:

Oracle Fusion Middleware 12c (12.2.1.3)から停止時間の短縮アップグレードがサポートされるようになりました。サポートされているFusion Middleware 11gまたは12c (12.2.1.2.0以前)リリースからアップグレードする場合、またはマルチノードの環境がない場合、停止時間が短縮されたアップグレードを実行できません。12c (12.1.3または12.2.1.2)から停止時間が短縮されたアップグレードを実行するには、まず、標準アップグレード・プロセスを使用して、12.2.1.3にアップグレードする必要があります。「Oracle WebCenterの以前の12cリリースからのアップグレード」を参照してください。

図B-1 停止時間が短縮されたアップグレードのプロセス・フローチャート

図B-1の説明が続きます
「図B-1 停止時間が短縮されたアップグレードのプロセス・フローチャート」の説明
表B-1に、Oracle Fusion Middleware 12c (12.2.1.3.0)リリースの停止時間が短縮されたアップグレードの際に実行する必要のあるステップの概要を示します。追加するホストごとに、これらのステップを繰り返す必要があります。

表B-1 Oracle Fusion Middleware 12c (12.2.1.3.0)リリースの停止時間が短縮されたアップグレードを実行するためのタスク

タスク 説明

必須

停止時間が短縮されたアップグレードを開始する前に、必要なアップグレード前タスクを実行する必要があります。

アップグレード前タスクには、アップグレード前チェックリストの確認、Oracleホーム、ドメイン・ディレクトリおよびコンポーネント・スキーマのバックアップ、および適切なJDKバージョンの使用が含まれます。

アップグレード前タスクの完全なリストは、「開始前に完了しておく必要がある必須タスク」を参照してください。

必須

すべてのホストで、既存の環境の完全なバックアップを作成します。

「完全なバックアップの作成」を参照してください。

必須

ホスト1でサーバーおよびプロセスを停止します。

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

「ホスト1でのコンポーネント、サーバーおよびプロセスの停止」を参照してください。

必須

ホスト1でFusion Middleware 12c (12.2.1.3.0)製品ディストリビューションをアンインストールします。

Fusion Middleware Infrastructure 12c (12.2.1.4.0)を同じディレクトリにインストールできるように、既存のORACLE_HOMEからFusion Middleware 12c (12.2.1.3.0)製品ディストリビューションをアンインストールします。

「ソフトウェアのアンインストール」を参照してください。

必須

12c (12.2.1.4.0)製品ディストリビューションをホスト1上の既存のOracleホームにインストールします。

Oracle Universal Installerを使用して、Oracle Fusion Middleware Infrastructure 12c (12.2.1.4.0)をインストールします。12c (12.2.1.4.0)製品ディストリビューションを同じORACLE_HOMEにインストールする必要があります。

「Oracle WebCenterの12c (12.2.1.4.0)製品ディストリビューションのインストール」を参照してください。

オプション

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

アップグレード・アシスタントを使用した準備状況チェックの実行は、アップグレード前の環境について、アップグレードの準備が整っているかどうかを判断する際に役立ちます。

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

必須

ご使用の製品に該当する場合は、アップグレード・アシスタントを使用して、ホスト1で個別にスキーマおよび構成のアップグレードを実行します。
次のトピックを参照してください。
12c (12.2.1.4.0)にアップグレードできるスキーマおよびコンポーネント構成のリストは、『Oracle Fusion Middleware Upgrade Assistantによるアップグレード』の次の項を参照してください

必須

製品に構成のアップグレードが含まれていた場合は、ホスト1でドメインをパックします。

「ドメインのパックおよびドメイン・プロパティの更新」を参照してください。

必須

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

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

「ホスト1でのノード・マネージャ、管理サーバー、管理対象サーバーおよびコンポーネントの再起動」を参照してください。

必須

ホスト1でアップグレードを検証します。

アップグレードが完了したら、アップグレードの検証タスクを実行します。

「アップグレードの検証」を参照してください。

必須

ホスト2でサーバーおよびプロセスを停止します。

アップグレードの開始前に、ホスト2上のシステム・コンポーネント、管理対象サーバーおよびノード・マネージャを停止する必要があります。

「ホスト2でのコンポーネント、サーバーおよびプロセスの停止」を参照してください。

必須

ホスト2でFusion Middleware Infrastructure 12c (12.2.1.3.0)をアンインストールします。

Fusion Middleware Infrastructure 12c (12.2.1.4.0)を同じディレクトリにインストールできるように、既存のORACLE_HOMEからFusion Middleware Infrastructure 12c (12.2.1.3.0)をアンインストールします。

「ソフトウェアのアンインストール」を参照してください。

必須

Fusion Middleware Infrastructure 12c (12.2.1.4.0)およびホスト2のドメインで実行するその他の製品ディストリビューションをインストールします。

「既存のミドルウェア・ホームへのソフトウェアのインストール」を参照してください。

必須

ホスト1でドメインをパックした場合は、ホスト2でドメインをアンパックします。

「追加の各ホストでのドメインのアンパック」を参照してください。

必須

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

アップグレードが完了したら、サーバーおよびプロセスを再起動します。

「管理対象サーバーおよびプロセスの再起動」を参照してください。

必須

ホスト2でアップグレードを検証します。

サーバーおよびプロセスを再起動した後、アップグレードの検証タスクを実行します。

「アップグレードの検証」を参照してください。

  • 停止時間が短縮されたアップグレードの実行
    Fusion Middleware 12c (12.2.1.3)リリースからアップグレードする場合、このプロセスを使用することにより、すべてのサーバーを同時にシャットダウンせずにマルチノード・ドメインをアップグレードできます。

停止時間の短縮アップグレードの実行

Fusion Middleware 12c (12.2.1.3)リリースからアップグレードする場合、このプロセスを使用することにより、すべてのサーバーを同時にシャットダウンせずにマルチノード・ドメインをアップグレードできます。

この項で説明する手順は、Oracle Fusion Middleware Standardインストール・トポロジ(SIT)に基づいており、マルチノード環境を使用している必要があります。Oracle Fusion Middleware Infrastructureの標準インストール・トポロジには、2台の管理対象サーバーを含む1つのクラスタと管理サーバーが1台の標準的なWebLogic Serverドメインがあります。ホスト1は、管理サーバーを使用してホスト上で実行される手順の説明、ホスト2は、他の管理対象サーバー・ホストで実行される手順の説明に使用されます。環境内に2つ以上のホストが含まれる場合、追加のノードごとに手順を必ず完了してください。

開始前に完了しておく必要がある必須タスク

停止時間の短縮アップグレードを開始する前に、次の点を確認してください:

  • デプロイメントのコンポーネントのアップグレード前チェックリストを確認します。チェックリストは、コンポーネント別のアップグレード・ガイドに記載されています。一部の製品では、アップグレードの実行前に追加のステップが必要になる場合があります。
  • アップグレードを実行する前に、Oracleホーム(すべてのノード)、ドメイン・ディレクトリ全体(すべてのノード)およびコンポーネント・スキーマの完全なバックアップ作成します。ドメイン・ディレクトリに加えて、UIカスタマイズのバックアップおよびアプリケーション・ディレクトリを作成することもお薦めします。「完全なバックアップの作成」を参照してください。
  • このリリースに適切なJDKバージョンを使用していることを確認してください。このリリースでは、正しいバージョンはjdk1.8.0_211です
  • 共有コンポーネント・ディレクトリをアップグレードする場合は、アップグレード前に共有ディレクトリの内容をバックアップしてください。構成のアップグレードにより、これらのディレクトリが変更されます。
  • バックアップに、setStartupEnv.shなどの変更されたスクリプトが含まれていることを確認します。アップグレードにより、カスタマイズされたファイルが上書きされ、変更が失われます。

親トピック: 停止時間が短縮されたアップグレード・プロセスについて

ホスト1でのアップグレードの実行

管理サーバーをホストし、デプロイメント用のプライマリ・マシンとして機能するマシン上で、次のタスクを実行します。

親トピック: 停止時間の短縮アップグレードの実行

ホスト1でのコンポーネント、サーバーおよびプロセスの停止

管理サーバー、すべての管理対象サーバーおよびノード・マネージャ(実行されている場合)を含むすべてのシステム・コンポーネント、プロセスおよびサーバーを停止する必要があります。

ノート:

この項内の手順では、WLSTコマンドラインまたはスクリプトを使用してコンポーネント、サーバーおよびプロセスを停止する方法を説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。
Oracle Fusion Middleware環境は、Oracle WebLogic Serverドメイン、管理サーバー、複数の管理対象サーバー、Javaコンポーネント、アイデンティティ管理コンポーネントなどのシステム・コンポーネント、およびメタデータのリポジトリに使用されるデータベースで構成できます。コンポーネントは相互に依存していることがあるため、次の順序で停止する必要があります。
  • システム・コンポーネント(ある場合)
  • 管理対象サーバー
  • 管理サーバー
  • ノード・マネージャ
システム・コンポーネントの停止

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

コンポーネントごとに次のスクリプトを実行します:
 
(UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name
(Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name
管理対象サーバーの停止
WebLogic Server管理対象サーバーを停止するには、stopManagedWebLogicスクリプトを使用します。
  1. 次のコマンドを入力します。
    (UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url
    (Windows)DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url
  2. プロンプトが表示されたらユーザー名とパスワードを入力します。
管理サーバーの停止

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

管理サーバーを停止するには:
  1. 次のコマンドを入力します。
    (UNIX) DOMAIN_HOME/bin/stopWebLogic.sh
    (Windows) DOMAIN_HOME\bin\stopWebLogic.cmd
  2. プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよびURLを入力します。
ノード・マネージャの停止

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

またはnodemanager.propertiesのQuitEnabledの属性をtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。

ソフトウェアのアンインストール

ローリング・アップグレードを実行する場合、アップグレード前に新しいバイナリをインストールするために空のディレクトリが必要です。

ノート:

upperstackのコンポーネントを先に削除してから、JRFを削除する必要があります。JRFを削除したら、残りのファイルをバックアップし、ディレクトリ内のすべてのファイルを削除します。インストール・ディレクトリは空である必要があります。

既存のORACLE_HOMEからソフトウェアを削除するには、この項の手順に従います。このディレクトリに新しいソフトウェアを再インストールします。

アンインストール・モードでOracle Universal Installerを起動するには、次のコメントを実行します。

UNIX: ORACLE_HOME/oui/bin/deinstall.sh

Windows: ORACLE_HOME\oui\bin\deinstall.cmd

サイレント(コマンド・ライン)・モードの製品のアンインストールを実行する場合は、Oracle Fusion Middleware Oracle Universal Installerによるソフトウェアのインストールのサイレント・アンインストールのためのOracle Universal Installerの実行を参照してください。

Oracle WebCenterの12c (12.2.1.4.0)製品ディストリビューションのインストール

アップグレードを開始する前に、既存のOracleホームからソフトウェアをアンインストールしてから、Oracle Universal Installerを使用して、ターゲット・システム上の同じOracleホームに12c (12.2.1.4.0)製品ディストリビューションをインストールします。アップグレード中に各ホストに製品ディストリビューションをインストールする必要があります。

ノート:

アップグレードにInfrastructureが必要な場合は、その他のFusion Middleware製品をインストールする前に、まずOracle Fusion Middlewareディストリビューションをインストールする必要があります。
開始する前に、次の点に注意してください。

  • 必ずアンインストールした製品バイナリのみをインストールしてください。たとえば、12c (12.2.1.3) OracleホームにWebCenter Content (WCC)およびWebCenter Portal (WCP)がある場合、それらをアンインストールし、12c (12.2.1.4) WCCとWCPの両方の製品バイナリをインストールします。同様に、12c (12.2.1.3) OracleホームにWCCのみがある場合は、12c (12.2.1.4) WCCのみをアンインストールしてインストールします。

  • アンインストールした以前のディストリビューションに使用したパスと同じインストール・パス(Oracleホーム)を新しいディストリビューションのインストールに使用します。
12c (12.2.1.4.0)ディストリビューションをインストールするには:
  1. ターゲットのシステムにサインインします。
  2. Oracle Technology NetworkまたはOracle Software Delivery Cloudからターゲット・システムに適用可能な製品ディストリビューションをダウンロードします:
    • Oracle Fusion Middlewareインフラストラクチャ(fmw_12.2.1.4.0_infrastructure)
    • Oracle WebCenter Content (fmw_12.2.1.4.0_wccontent.jar)
    • Oracle WebCenter Portal (fmw_12.2.1.4.0_wcportal.jar)
    • Oracle WebCenter Sites (fmw_12.2.1.4.0_wcsites.jar)
  3. 12c (12.2.1.4.0)製品のディストリビューションをダウンロードしたディレクトリに移動します。
  4. Oracle Fusion Middleware Infrastructureのインストール・プログラムを開始します。
    • (UNIX) JDK_HOME/bin/java -jar fmw_12.2.1.4.0_infrastructure.jar
    • (Windows) JDK_HOME\bin\java -jar fmw_12.2.1.4.0_infrastructure.jar

Infrastructureのインストールが完了した後に、適切なディストリビューション名を使用して、残りのディストリビューションを同様にインストールします。たとえば、Oracle WebCenter Contentのインストール・プログラムを開始するには、ディストリビューション名としてfmw_12.2.1.4.0_wccontent_generic.jarを使用します。

  1. UNIXオペレーティング・システムでは、このホストにOracle製品を初めてインストールする場合に、「インストール・インベントリの設定」画面が表示されます。
    中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名に対して中央インベントリの場所への書込み権限が付与されていることを確認し、「次」をクリックします。

    ノート:

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

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

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

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

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

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

  8. 「インストールの進行状況」画面で、プログレス・バーが100%完了になったら、「終了」をクリックしてインストーラを閉じるか、「次へ」をクリックしてサマリーを表示します。
  9. 「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。情報を確認し、「終了」をクリックしてインストーラを閉じます。
  10. Oracle Fusion Middleware Infrastructureのインストール後に、前述のステップを繰り返して、その他の製品ディストリビューションをインストールします。
アップグレード前の準備状況チェックの実行

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

親トピック: ホスト1でのアップグレードの実行

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

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

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

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

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

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

ノート:

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

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

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

アップグレード・アシスタントを使用して、アップグレード前の環境に対して準備状況チェックを実行するには:
  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

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

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

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

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

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

表B-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)

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

オプション

すべてのコマンドライン・オプションを表示します。
アップグレード・アシスタントを使用した準備状況チェックの実行

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

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

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

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

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

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

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

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

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

  3. 「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、アップグレードに対応可能なスキーマを持つコンポーネントを選択して、準備状況チェックの実行対象にします。
    「ドメイン・ベース」を選択した場合: 「コンポーネント・リスト」画面で、準備状況チェックを実行するドメインに存在するコンポーネントのリストを確認します。
    依存コンポーネントのあるコンポーネントを選択すると、該当するコンポーネントが自動的に選択されます。たとえば、Oracle Platform Security Servicesを選択すると、Oracle Audit Servicesが自動的に選択されます。

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

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

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

      ノート:

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

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

      ノート:

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

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

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

準備状況レポートの理解

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

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

readiness<timestamp>.txt

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

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

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

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

タイムスタンプ

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

必要なアクションはありません。

ログ・ファイルの場所

/oracle_common/upgrade/logs

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

必要なアクションはありません。
ドメイン・ディレクトリ ドメインの場所が表示されます 必要なアクションはありません。

準備状況レポートの場所

/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 Fri Aug 16 13:29:41 PDT 2019
Log file is located at: /oracle/work/middleware_latest/oracle_common/upgrade/logs/ua2019-08-16-13-23-36PM.log
Readiness Check Report File: /oracle/work/middleware_latest/oracle_common/upgrade/logs/readiness2019-08-16-13-29-41PM.txt
Domain Directory: /oracle/work/middleware_1212/user_projects/domains/jrf_domain

Starting readiness check of components.

Oracle Platform Security Services
   Starting readiness check of Oracle Platform Security Services.
     Schema User Name: DEV3_OPSS
     Database Type: Oracle Database
     Database Connect String: 
     VERSION Schema DEV3_OPSS is currently at version 12.1.2.0.0.  Readiness checks will now be performed.
   Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
     INFO   Database product version: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
   Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
   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 that the schema does not contain any unexpected tables  TEST_UNEXPECTED_TABLES
   Completed schema test: Test that the schema does not contain any unexpected tables --> TEST_UNEXPECTED_TABLES +++ Test that the schema does not contain any unexpected tables
   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 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:  SEQUENCE_TEST  Test that the Oracle Platform Security Services schema sequence and its properties are valid
   Completed schema test: SEQUENCE_TEST --> Test that the Oracle Platform Security Services schema sequence and its properties are valid +++ PASS
   Finished readiness check of Oracle Platform Security Services with status: SUCCESS.

Oracle Audit Services
   Starting readiness check of Oracle Audit Services.
     Schema User Name: DEV3_IAU
     Database Type: Oracle Database
     Database Connect String: 
     VERSION Schema DEV3_IAU is currently at version 12.1.2.0.0.  Readiness checks will now be performed.
   Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
     INFO   Database product version: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
   Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
   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_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_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 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_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_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 OIDCOMPONENT:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table OIDCOMPONENT: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting datatype test for table IAU_CUSTOM_01:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table IAU_CUSTOM_01: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting datatype test for table IAU_BASE:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table IAU_BASE: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting datatype test for table WS_POLICYATTACHMENT:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table WS_POLICYATTACHMENT: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting datatype test for table OWSM_PM_EJB:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table OWSM_PM_EJB: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting datatype test for table XMLPSERVER:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table XMLPSERVER: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting datatype test for table SOA_HCFP:  TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes
   Completed datatype test for table SOA_HCFP: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS
   Starting schema test:  SEQUENCE_TEST  Test that the audit schema sequence and its properties are valid
   Completed schema test: SEQUENCE_TEST --> Test that the audit schema sequence and its properties are valid +++ PASS
   Starting schema test:  SYNONYMS_TEST  Test that the audit schema required synonyms are present
   Completed schema test: SYNONYMS_TEST --> Test that the audit schema required synonyms are present +++ PASS
   Finished readiness check of Oracle Audit Services with status: FAILURE.

Common Infrastructure Services
   Starting readiness check of Common Infrastructure Services.
     Schema User Name: DEV3_STB
     Database Type: Oracle Database
     Database Connect String: 
   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
   Completed schema test: ALL_TABLES --> TEST_REQUIRED_TABLES +++ Test that the schema contains all the required tables
   Starting schema test:  TEST_UNEXPECTED_TABLES  Test that the schema does not contain any unexpected tables
   Completed schema test: ALL_TABLES --> TEST_UNEXPECTED_TABLES +++ Test that the schema does not contain any unexpected tables
   Starting schema test:  TEST_REQUIRED_VIEWS  Test that the schema contains all the required database views
   Completed schema test: ALL_TABLES --> TEST_REQUIRED_VIEWS +++ Test that the schema contains all the required database views
   Starting schema test:  TEST_MISSING_COLUMNS  Test that tables and views are not missing any required columns
   Completed schema test: ALL_TABLES --> TEST_MISSING_COLUMNS +++ Test that tables and views are not missing any required columns
   Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
   Starting schema test:  TEST_DATABASE_VERSION  Test that the database server version number is supported for upgrade
     INFO   Database product version: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
   Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS
   Completed schema test: ALL_TABLES --> TEST_DATABASE_VERSION +++ Test that the database server version number is supported for upgrade
   Finished readiness check of Common Infrastructure Services with status: SUCCESS.

Oracle JRF
   Starting readiness check of Oracle JRF.
   Finished readiness check of Oracle JRF with status: SUCCESS.

System Components Infrastructure
   Starting readiness check of System Components Infrastructure.
   Starting config test:  TEST_SOURCE_CONFIG  Checking the source configuration.
     INFO /oracle/work/middleware_1212/user_projects/domains/jrf_domain/opmn/topology.xml was not found. No upgrade is needed.
   Completed config test: TEST_SOURCE_CONFIG --> Checking the source configuration. +++ PASS
   Finished readiness check of System Components Infrastructure with status: ALREADY_UPGRADED.

Common Infrastructure Services
   Starting readiness check of Common Infrastructure Services.
   Starting config test:  CIEConfigPlugin.readiness.test  This tests the readiness of the domain from CIE side.
   Completed config test: CIEConfigPlugin.readiness.test --> This tests the readiness of the domain from CIE side. +++ PASS
   Finished readiness check of Common Infrastructure Services with status: SUCCESS.

Finished readiness check of components.
アップグレード・アシスタントを使用したOracle WebCenterスキーマのアップグレード

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

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

    ノート:

    Upgrade Assistantの画面の詳細は、画面上の「ヘルプ」をクリックしてください。
  2. 「選択したスキーマ」画面で、実行するスキーマ・アップグレード操作を選択します。
    • 個別に選択されたスキーマ。アップグレード用のスキーマを個別に選択する場合で、ドメインで使用されるすべてのスキーマをアップグレードしない場合。

      注意:

      12c (12.2.1.4.0)コンポーネントをサポートするために使用されるスキーマのみをアップグレードしてください。Oracle Fusion Middleware 12c (12.2.1.4.0)に含まれていないコンポーネントをサポートするために現在使用されているスキーマをアップグレードしないでください。
    • ドメインで使用されるすべてのスキーマ。アップグレード・アシスタントは、「ドメイン・ディレクトリ」シールドに指定されているドメイン内のアップグレード可能なスキーマがあるすべてのコンポーネントを検索し、選択できます。これは、ドメイン支援のスキーマ・アップグレードとも呼ばれています。さらに、Upgrade Assistantはスキーマの入力画面に接続情報を事前に移入します。

      ノート:

      必要なすべてのスキーマがアップグレードに確実に含まれるようにするため、ほとんどのアップグレードについて「ドメインで使用されるすべてのスキーマ」を選択することをお薦めします。

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

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

    ノート:

    アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。
  5. スキーマ資格証明画面で、アップグレードする各スキーマのデータベース接続詳細を指定します(選択したスキーマに応じて画面名が変更されます)。

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

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

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

      ノート:

      リリース12.1.2のUCSUMSスキーマでは、コンポーネントIDまたはスキーマ名が変わるため、アップグレード・アシスタントは、使用可能なスキーマを自動的に認識し、それらをドロップダウン・リストに表示することはありません。テキスト・フィールドに手動で名前を入力する必要があります。名前はアップグレードの開始ポイントに応じて、prefix_ORASDPMまたはprefix_UMSのいずれかになります。
  6. 「調査」画面で、各スキーマを調査したUpgrade Assistantのステータスを確認して、スキーマのアップグレードの準備が整っていることを検証します。ステータスが「調査が終了しました。」になっている場合は、「次」をクリックします。
    調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、共通するアップグレード・エラーの解決に関する情報を『Oracle Fusion Middleware Upgrade Assistantによるアップグレード』のアップグレードのトラブルシューティングに関する項で参照します。

    ノート:

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

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

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

    注意:

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

    ノート:

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

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

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

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

    ノート:

    アップグレードが失敗した場合は、バックアップからアップグレード前の環境をリストアし、問題を修正してから、Upgrade Assistantを再起動する必要があります。
WebCenter Portalドメイン・コンポーネントのアップグレード
アップグレード・アシスタントを使用して、WebCenter Portalドメイン・コンポーネントをアップグレードできます。手順については、『Oracle Fusion Middleware Upgrade Assistantによるアップグレード』のコンポーネント構成のアップグレードの理解に関する項を参照してください。

ノート:

構成のアップグレードは、WebCenter Contentには適用されません。
アップグレード・アシスタントを使用したWebCenter Sitesドメイン・コンポーネントのアップグレード

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

WebCenter Sitesの停止時間の短縮アップグレードを実行する場合、コンポーネント構成をアップグレードするためにアップグレード・アシスタントを2回実行する必要があります。このステップは、他のWebCenterコンポーネントでは不要です。

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

    ノート:

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

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

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

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

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

    ノート:

    アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。
  5. 「WebCenter Sitesソース・バージョン」画面で12.2.1.0.0以降を選択し、「次」をクリックします。これはアップグレードの開始ポイントです。
  6. (クラスタ環境)ソース環境がクラスタ環境の場合、pack/unpackユーティリティを使用して、変更をドメイン内の他のクラスタ・メンバーに適用します。
    プライマリ・ノードで、ターゲット環境のパスに移動し、PACKコマンドを実行します:
    $ORACLE_HOME/oracle_common/common/bin
    セカンダリ・クラスタ・メンバー・ノードで、ターゲット環境に移動し、UNPACKコマンドを実行します:
    $ORACLE_HOME/oracle_common/common/bin
    1. セカンダリ・クラスタ・メンバー・ノードのそれぞれで、プライマリ・ノードの各ノードに$DOMAIN_HOME/wcsites/wcsites/config/をコピーすることにより、Sitesのconfigフォルダをプライマリ・ノードのもので置換します。
    2. セカンダリ・クラスタ・メンバー・ノードのそれぞれで、DOMAIN_HOME/wcsites/wcsites/config/にある次のファイルを更新します:
      • ホスト・プロパティ:

        このファイルで、プライマリ・ノードのIPアドレス詳細をセカンダリ・ノードの詳細で置換します。

      • jbossTicketCacheReplicationConfig.xml:

        このセカンダリ・クラスタ・ノードのセカンダリ・ノード詳細を含むプライマリ・ノードの有効なホストまたはIPアドレスでbind_addrプロパティを更新します

        ノート:

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

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

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

        表B-4 「timeToLive」フィールドの様々な値の説明

        timeToLiveの値 説明

        1

        同じサブネットに限定されるマルチキャスト・パケット。

        32

        同じサイトに限定されるマルチキャスト・パケット。

        64

        同じ地理的領域に限定されるマルチキャスト・パケット。

        128

        同じ大陸に限定されるマルチキャスト・パケット。

        256

        制限なし。

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

        ノート:

        この4つのxmlファイル(cas-cache.xml、cs-cache.xml、linked-cache.xmlおよびss-cache.xml)すべてについて、プライマリ・ノードで"multicastGroupAddress"、"timeToLive"、"multicastGroupPort"が適した値になっている必要があります
    3. セカンダリ・クラスタ・メンバー・ノードのそれぞれで、パスEXISTING_DOMAIN_HOME/binに移動し、setStartupEnv.shファイルを変更します
      • –Dsites.node=<セカンダリ・クラスタ・ノード名>であることを確認します。このパラメータが存在しない場合は、このパラメータを追加します
      • –Dsites.config=<wcs_properties.jsonファイルが含まれるフォルダ・パス>であることを確認します

      ノート:

      wcs_properties.jsonファイルはプライマリ・クラスタ・メンバー・ノードとセカンダリ・クラスタ・メンバー・ノードの間で共有されるため、プライマリ・クラスタ・メンバー・ノードとセカンダリ・クラスタ・メンバー・ノードでこのファイルのロケーション・パスが同じである必要があります。
  7. 「調査」画面で、各コンポーネントを調査したUpgrade Assistantのステータスを確認して、コンポーネント構成のアップグレードの準備が整っていることを検証します。ステータスが「調査が終了しました。」になっている場合は、「次」をクリックします。
    調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、共通するアップグレード・エラーの解決に関する情報を『Oracle Fusion Middleware Upgrade Assistantによるアップグレード』のアップグレードのトラブルシューティングに関する項で参照します。

    ノート:

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

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

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

    注意:

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

    ノート:

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

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

  10. 構成のアップグレードが成功した場合は、次の場所にサマリー・ファイルが生成されます。
    NEW_ORACLE_HOME/oracle_common/upgrade/logs/
    ソースがクラスタ環境である場合、サマリー詳細は次のようにクラスタごとに生成されます:
    NEW_ORACLE_HOME/oracle_common/upgrade/logs/
    スキーマのアップグレードが失敗した場合は、考えられるエラーをログでレビューします。ログ・ファイルは次の場所に生成されます。
    NEW_ORACLE_HOME/oracle_common/upgrade/logs
    「閉じる」をクリックしてアップグレード・アシスタントを閉じます。
ドメインのパックおよびドメイン・プロパティの更新

停止時間が短縮されたアップグレードの一部としてWebCenter SitesまたはWebCenter Portalをアップグレードする場合、ホスト1からドメインをパックし、アップグレード中にホスト2でアンパックする必要があります。また、サーバーを起動する前に構成プロパティを更新する必要もあります。

1. 管理サーバーが存在するホスト(ホスト1)でドメインを圧縮します

ホスト1でのアップグレードが正常に完了した後、次のコマンドを使用してドメインを圧縮します。後で、ホスト2で使用するドメインを解凍します。

cd ORACLE_HOME/common/bin 
./pack.sh -managed=true -domain=DOMAIN_HOME -template=wcdomaintemplate.jar -template_name=wc_domain_template
2. 適切なWebCenter Sites構成プロパティを使用して、setStartupEnv.shを更新します。

setStartupEnv.shは、DOMAIN_HOME\binにあります。

"%STARTUP_GROUP%"=="WCSITES-MGD-SVR"でsetStartupEnv.shファイルを開き、SERVER_SYSTEM_PROPERTIESを更新します。

たとえば、-Dsites.config=/u01/shared/wcsites/wcsites/config

WebCenter Sites.configurationパラメータが適切な値で更新されていることを確認してください

ホスト1でのノード・マネージャ、管理サーバー、管理対象サーバーおよびコンポーネントの再起動

アップグレード後、コンポーネント、サーバーおよびプロセスを正しい順序で再起動する必要があります。

ノート:

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

コンポーネントは、次の順序で起動する必要があります。

  • ノード・マネージャ
  • 管理サーバー
  • 管理対象サーバー
  • システム・コンポーネント

ノート:

ホスト1で次のコンポーネントのいずれも正常に起動できない場合は、残りのホストでアップグレードを続行しないでください。まず、ホスト1のコンポーネントの問題を解決する必要があります。

ノート:

Windowsユーザーのみ: Windowsオペレーティング・システムでサーバーを再起動する場合、アップグレードしたドメインが解析例外で失敗する可能性があります。この解析エラーを修正するには、プロパティ-Doracle.xml.schema/Ignore_Duplicate_components=trueをサーバー起動スクリプトsetDomainEnv.cmdに追加します。
ノード・マネージャの起動
ノード・マネージャを起動するには:
  1. 次のコマンドを入力します。
    (UNIX) DOMAIN_HOME/bin/startNodeManager.sh
    (Windows) DOMAIN_HOME\bin\startNodeManager.cmd
管理サーバーの起動
管理サーバーを起動するには:
  1. 次のコマンドを入力します。
    (UNIX) DOMAIN_HOME/bin/startWebLogic.sh
    (Windows) DOMAIN_HOME\bin\startWebLogic.cmd
  2. プロンプトが表示されたら、管理サーバーのユーザー名、パスワードおよびURLを入力します。
管理対象サーバーの起動
管理サーバーを起動するには:
  1. 次のコマンドを入力します。
    (UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
    (Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url
  2. プロンプトが表示されたらユーザー名とパスワードを入力します。
コンポーネント・プロセスの起動

管理サーバーを停止したら、管理サーバーで稼働しているプロセス(WebLogic Server管理コンソールやFusion Middleware Controlなど)も停止するため、アップグレード後にこれらのプロセスをすべて再起動する必要があります。

  1. DOMAIN_HOME\binディレクトリに移動します。
  2. コンポーネントごとに次のスクリプトを実行します
    /startComponent.sh component_name

ホスト2でのアップグレードの実行

ホスト1上でのアップグレードが完了したら、環境内の追加ホストごとに次のステップを実行します。標準トポロジ例には2つのホストのみが含まれますが、別のホストを使用することもできます。

親トピック: 停止時間の短縮アップグレードの実行

ホスト2でのコンポーネント、サーバーおよびプロセスの停止

ホスト2で実行されているシステム・コンポーネント、管理対象サーバーおよびノード・マネージャを停止する必要があります。

最初にシステム・コンポーネントを停止してから、管理対象サーバー、ノード・マネージャの順に停止します。正しい順序でコンポーネントを停止しないと、アップグレードが失敗する可能性があります。
システム・コンポーネントの停止

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

DOMAIN_HOME\binディレクトリに移動し、コンポーネントごとに次のスクリプトを実行します。
./stopComponent.sh component_name
管理対象サーバーの停止
WebLogic Server管理対象サーバーを停止するには、stopManagedWebLogicスクリプトを使用します。
  1. 次のコマンドを入力します。
    (UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url
    (Windows)DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url
  2. プロンプトが表示されたらユーザー名とパスワードを入力します。
    SOAサーバーおよびプロセスは、次の順番で停止してください。
ノード・マネージャの停止

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

またはnodemanager.propertiesのQuitEnabledの属性をtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。

ソフトウェアのアンインストール

ローリング・アップグレードを実行する場合、アップグレード前に新しいバイナリをインストールするために空のディレクトリが必要です。

ノート:

upperstackのコンポーネントを先に削除してから、JRFを削除する必要があります。JRFを削除したら、残りのファイルをバックアップし、ディレクトリ内のすべてのファイルを削除します。インストール・ディレクトリは空である必要があります。

既存のORACLE_HOMEからソフトウェアを削除するには、この項の手順に従います。このディレクトリに新しいソフトウェアを再インストールします。

アンインストール・モードでOracle Universal Installerを起動するには、次のコメントを実行します。

UNIX: ORACLE_HOME/oui/bin/deinstall.sh

Windows: ORACLE_HOME\oui\bin\deinstall.cmd

サイレント(コマンド・ライン)・モードの製品のアンインストールを実行する場合は、Oracle Fusion Middleware Oracle Universal Installerによるソフトウェアのインストールのサイレント・アンインストールのためのOracle Universal Installerの実行を参照してください。

既存のミドルウェア・ホームへのソフトウェアのインストール

空のミドルウェア・ホームにソフトウェアをインストールします。

12c (12.2.1.4.0)製品ディストリビューションをインストールする前に、既存のOracleホームからソフトウェアをアンインストールします。ホスト1へのインストールに使用したのと同じプロセスを使用してソフトウェアをインストールします。

Oracle WebCenter Sitesをアップグレードする際、ドメインを解凍し、構成ディレクトリをホスト1からホスト2にコピーします。

追加の各ホストでのドメインのアンパック

新しい12c (12.2.1.4.0)バイナリをホスト2にある同じFusion Middlewareホームにインストールした後、ホスト1でのアップグレード時にパックした適用可能な製品(WebCenter SitesまたはWebCenter Portal)のドメイン・ディレクトリをコピーする必要があります。

cd ORACLE_HOME/common/bin 

./unpack.sh -domain=DOMAIN_HOME -template=wcdomaintemplate.jar -overwrite_domain=true
管理対象サーバーおよびプロセスの再起動

ホスト2でのアップグレードが完了したら、管理対象サーバーを再起動します。

管理サーバーを起動するには:
  1. 次のコマンドを入力します。
    (UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
    (Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url
  2. プロンプトが表示されたらユーザー名とパスワードを入力します。

アップグレードの検証

すべてのホストでアップグレードが完了したら、標準的なアップグレードの検証タスクを実行して、すべてのコンポーネントが期待どおりに引き続き機能することを確認します。

「アップグレード後に実行するタスク」を参照してください。

ノート:

使用環境、構成およびプリファレンスに関連するタスクのみを実行してください。これらのタスクは、アップグレードが成功したことを検証する作業を支援することを目的としています。構成に基づいて追加のテストを実行することが必要な場合があります。

失敗したアップグレードからのリカバリ

アップグレードに失敗した場合は、バックアップから環境をリストアする必要があります。バックアップした構成およびスクリプト・ファイルが含まれていることを確認します。(すべてのノードの)Oracleホーム、(すべてのノードの)ドメイン・ディレクトリ全体、およびコンポーネント・スキーマのバックアップをリストアします。また、ドメイン・ディレクトリに加えて、UIのカスタマイズとアプリケーション・ディレクトリもリストアする必要があります。

親トピック: 停止時間の短縮アップグレードの実行