Oracle Internet Directoryの単一ノードの12c環境のアップグレード

3 Oracle Internet Directoryの単一ノードの12c環境のアップグレード

旧バージョンのOracle Fusion Middleware 12c (12.2.1.4.0)から最新バージョンの14c (14.1.2.1.0)リリースにOracle Internet Directoryをアップグレードできます。

次の各トピックでは、Oracle Internet Directoryを14c (14.1.2.1.0)リリースにアップグレードする方法について説明します。

Oracle Internet Directoryのアップグレード・プロセスについて
Oracle Internet Directoryのアップグレード・プロセスについてを示すロードマップを確認します。
サーバーとプロセスの停止
アップグレード・アシスタントを実行してスキーマおよび構成をアップグレードする前に、管理サーバー、管理対象サーバー、Oracle Internet Directoryインスタンス、プロセスおよびノード・マネージャを停止する必要があります。
ソフトウェアのアンインストール
この項の手順に従い、アンインストール・ウィザードを起動してソフトウェアを削除します。
Oracle Internet Directoryのインストール
アップグレードの開始前に、Oracle Fusion MiddlewareインフラストラクチャとOracle Internet Directory (OID) 14c (14.1.2.1.0)のディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。
アップグレード前の準備状況チェックの実行
アップグレードにかかわる潜在的な問題を特定するために、アップグレード・プロセスの開始前に、準備状況チェックの実行をお薦めします。準備状況チェックによって、アップグレードにかかわる潜在的な問題をすべて検出できるわけではない点に注意してください。準備状況チェックのレポートが成功を示していても、アップグレードが失敗することもあります。
必要なスキーマの作成
アップグレード時、必要なスキーマを作成する必要があります。リポジトリ作成ユーティリティ(RCU)を使用してカスタマイズ・スキーマを作成することも、オプションでアップグレード・アシスタントを使用して、デフォルトのスキーマ設定を使用してスキーマを作成することもできます。この手順では、RCUを使用してスキーマを作成する方法について説明します。アップグレード・アシスタントを使用したスキーマの作成に関する情報は、アップグレードの手順に記載されています。
製品スキーマのアップグレード
サーバーとプロセスの停止後に、Upgrade Assistantを使用して、12.2.1.4.0スキーマをOracle Fusion Middlewareの14c (14.1.2.1.0)リリースにアップグレードします。
ドメインの再構成
再構成ウィザードを実行して、ドメイン・コンポーネント構成を14c (14.1.2.1.0)に再構成します。
ドメイン・コンポーネント構成のアップグレード
ドメインを再構成した後、もう一度Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。
サーバーおよびプロセスの起動
正常なアップグレードの後に、管理サーバーや管理対象サーバーなど、すべてのプロセスおよびサーバーを再起動します。
14c (14.1.2.1.0)でのSSLウォレットの作成
12cのOracle Internet Directory (OID)サーバーでは、MD5シグネチャで署名された証明書はサポートされていません。
新しいOracle Directory Services Managerコンソールへのアクセス
Oracle Directory Services Manager (ODSM)コンソールのURLは、14c (14.1.2.1.0)で変更されています。

親トピック: Oracle Internet Directoryのインプレース・アップグレード

Oracle Internet Directoryのアップグレード・プロセスについて

Oracle Internet Directoryのアップグレード・プロセスの概要を示すロードマップを確認します。

注意:

Oracle Internet Directory 14c (14.1.2.1.0)リリースにアップグレードする前に、12c (12.2.1.4.0) EXISTING_DOMAIN_HOMEがMIDDLEWARE_HOMEの外部にあることを確認してください。

既存のドメインをアップグレードするために実行するステップは、ドメインがどのように構成されているか、およびどのコンポーネントをアップグレードするかによって異なります。各自のデプロイメントに該当するステップにのみ従ってください。

表3-1 Oracle Internet Directoryのアップグレードのタスク

タスク	説明
必須このガイドの概要に関するトピックを再確認して、アップグレード前のタスクを完了します(まだ実行していない場合)。	参照: Oracle Internet Directoryの14c (14.1.2.1.0)へのアップグレードの概要アップグレード前の要件
必須 12c (12.2.1.4.0)環境のすべてのサーバーとプロセスを停止します。これには、管理サーバー、管理対象サーバー、OIDサーバー、ノード・マネージャおよびその他のシステム・コンポーネントが含まれます。	警告: アップグレード中にサーバーを停止しないと、データが破壊される可能性があります。「サーバーとプロセスの停止」を参照
必須コロケート・インストールの場合、既存のOracleホームからOracle Fusion MiddlewareインフラストラクチャとOracle Internet Directory 12c (12.2.1.4.0)をアンインストールします。スタンドアロン・インストールの場合、既存のOracleホームからOracle Internet Directory 12c (12.2.1.4.0)をアンインストールします。	「ソフトウェアのアンインストール」を参照してください。
必須スタンドアロン・インストールの場合、既存のOracleホームにOracle Internet Directory 14c (14.1.2.1.0)をインストールします。また、パッチ32577294も適用するようにしてください。コロケート・デプロイメントの場合、既存のOracleホームにOracle Fusion MiddlewareインフラストラクチャとOracle Internet Directory 14c (14.1.2.1.0)の両方をインストールします。	「Oracle Internet Directoryのインストール」を参照してください。
省略可能アップグレード前の準備状況チェックを実行します	「アップグレード前の準備状況チェックの実行」を参照してください。
必須アップグレード・アシスタントを起動して12c (12.2.1.4.0)データベース・スキーマをアップグレードします。	「製品スキーマのアップグレード」を参照してください。アクティブ・インスタンス・データのアップグレードは、アップグレード・アシスタントの実行中に自動で開始されます。データが新しい14c (14.1.2.1.0)環境に正常にアップグレードされたら、Upgrade Assistantを終了してもかまいません。クローズされたインスタンスのアップグレードは、バックグランド・プロセスで継続されます。
再構成ウィザードを起動してドメインを再構成します。	ドメインの再構成を参照してください。
アップグレード・アシスタントを(再度)起動して、Oracle Internet Directoryドメイン・コンポーネント構成をアップグレードします。	「ドメイン・コンポーネント構成のアップグレード」を参照してください。
必須サーバーとシステム・コンポーネントを起動します。	アップグレード・プロセスが完了したら、14c (14.1.2.1.0)インスタンスを再起動します。「サーバーとプロセスの起動」を参照してください。

タスク

説明

必須

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

参照:

Oracle Internet Directoryの14c (14.1.2.1.0)へのアップグレードの概要
アップグレード前の要件

必須

12c (12.2.1.4.0)環境のすべてのサーバーとプロセスを停止します。これには、管理サーバー、管理対象サーバー、OIDサーバー、ノード・マネージャおよびその他のシステム・コンポーネントが含まれます。

警告: アップグレード中にサーバーを停止しないと、データが破壊される可能性があります。

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

必須

コロケート・インストールの場合、既存のOracleホームからOracle Fusion MiddlewareインフラストラクチャとOracle Internet Directory 12c (12.2.1.4.0)をアンインストールします。

スタンドアロン・インストールの場合、既存のOracleホームからOracle Internet Directory 12c (12.2.1.4.0)をアンインストールします。

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

必須

スタンドアロン・インストールの場合、既存のOracleホームにOracle Internet Directory 14c (14.1.2.1.0)をインストールします。また、パッチ32577294も適用するようにしてください。

コロケート・デプロイメントの場合、既存のOracleホームにOracle Fusion MiddlewareインフラストラクチャとOracle Internet Directory 14c (14.1.2.1.0)の両方をインストールします。

「Oracle Internet Directoryのインストール」を参照してください。

省略可能

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

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

必須

アップグレード・アシスタントを起動して12c (12.2.1.4.0)データベース・スキーマをアップグレードします。

「製品スキーマのアップグレード」を参照してください。

アクティブ・インスタンス・データのアップグレードは、アップグレード・アシスタントの実行中に自動で開始されます。データが新しい14c (14.1.2.1.0)環境に正常にアップグレードされたら、Upgrade Assistantを終了してもかまいません。クローズされたインスタンスのアップグレードは、バックグランド・プロセスで継続されます。

再構成ウィザードを起動してドメインを再構成します。

ドメインの再構成を参照してください。

アップグレード・アシスタントを(再度)起動して、Oracle Internet Directoryドメイン・コンポーネント構成をアップグレードします。

「ドメイン・コンポーネント構成のアップグレード」を参照してください。

必須

サーバーとシステム・コンポーネントを起動します。

アップグレード・プロセスが完了したら、14c (14.1.2.1.0)インスタンスを再起動します。

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

親トピック: Oracle Internet Directoryの単一ノードの12c環境のアップグレード

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

アップグレード・アシスタントを実行してスキーマおよび構成をアップグレードする前に、管理サーバー、管理対象サーバー、Oracle Internet Directoryインスタンス、プロセスおよびノード・マネージャを停止する必要があります。

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

ノート:

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

リリース14c (14.1.2.0.0)以降、WebLogic Server管理コンソールは削除されました。同等の機能を使用するには、WebLogicリモート・コンソールを使用する必要があります。詳細は、Oracle WebLogicリモート・コンソールを参照してください。

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

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

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

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

ステップ2: Oracle Internet Directoryサーバーを停止する

次のコマンドを実行して、Oracle Internet Directoryサーバーを停止します。

(UNIX) DOMAIN_HOME/bin/stopComponent.sh oid1
(Windows) DOMAIN_HOME\bin\stopComponent.cmd oid1

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

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

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

(UNIX) EXISTING_DOMAIN_HOME/bin/stopWebLogic.sh
(Windows) EXISTING_DOMAIN_HOME\bin\stopWebLogic.cmd

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

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

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

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

親トピック: Oracle Internet Directoryの単一ノードの12c環境のアップグレード

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

この項の手順に従って製品のアンインストール・ウィザードを起動し、ソフトウェアを削除します。

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

親トピック: Oracle Internet Directoryの単一ノードの12c環境のアップグレード

「アンインストール・ウィザード」の起動

アンインストール・ウィザードを起動します。

次のディレクトリを変更します。
(UNIX) ORACLE_HOME/oui/bin

(Windows) ORACLE_HOME\oui\bin
次のコマンドを入力します。
(UNIX) ./deinstall.sh

(Windows) deinstall.cmd

親トピック: ソフトウェアのアンインストール

アンインストールする製品の選択

Oracleホームには複数の製品が存在するため、適切な製品をアンインストールするようにしてください。

「アンインストール・ウィザード」を実行した後、「アンインストールする配布」画面が表示されます。ドロップダウン・メニューから、Oracle Internet Directory 12.2.1.3.0製品を選択し、「アンインストール」をクリックします。アンインストール・プログラムでは、「アンインストール・ウィザード画面のナビゲート」に記載された画面が表示されます。

アンインストール・ウィザードを再度実行して、Oracle Fusion Middlewareインフラストラクチャをアンインストールします。手順の詳細は、『Oracle Fusion Middleware Infrastructureのインストールと構成』の「Oracle Fusion Middleware Infrastructureのアンインストール」を参照してください。

親トピック: ソフトウェアのアンインストール

「アンインストール・ウィザード」画面のナビゲート

「アンインストール・ウィザード」には、ソフトウェアの削除を確認する一連の画面が表示されます。

表3-2に示す画面の詳細が必要な場合は、画面上で「ヘルプ」をクリックしてください。

表3-2 「アンインストール・ウィザード」画面および説明

画面	説明
ようこそ	製品の「アンインストール・ウィザード」が紹介されます。
アンインストール・サマリー	アンインストールされるOracleホーム・ディレクトリとその内容を示します。これが正しいディレクトリであることを確認してください。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。後でレスポンス・ファイルを使用して、製品をサイレント(コマンドライン)・モードでアンインストールできます。『Oracle Universal Installerによるソフトウェアのインストール』のサイレント・アンインストールでのOracle Universal Installerの実行に関する項を参照してください。「アンインストール」, をクリックしてソフトウェアの削除を開始します。
アンインストールの進行状況	アンインストールの進捗状況を表示します。
アンインストール完了	アンインストールが完了すると表示されます。この画面の情報を確認してから、「終了」をクリックして「アンインストール・ウィザード」を閉じます。

ノート:

製品がアンインストールされたら、ORACLE_HOMEフォルダが存在し、そこにファイルまたはフォルダが含まれていないことを確認します。ORACLE_HOMEフォルダにファイルまたはフォルダが残っている場合は、それらを削除します。

親トピック: ソフトウェアのアンインストール

Oracle Internet Directoryのインストール

アップグレードの開始前に、Oracle Fusion MiddlewareインフラストラクチャとOracle Internet Directory (OID) 14c (14.1.2.1.0)のディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。

ノート:

インストール後およびドメイン作成前に、OPatchを使用して、個別ADFパッチ(https://support.oracle.comでバグID 37376076を検索)をOracle Internet Directory 14c (14.1.2.1.0) ORACLE_HOMEに手動で適用します。これは、コロケートOIDインストールにのみ適用され、スタンドアロンのOracle Internet Directory 14c (14.1.2.1.0)インストールには適用されません。
Oracle Internet Directory 14c (14.1.2.1.0)は、既存のORACLE_HOMEの場所にインストールする必要があります。

たとえば、12c (12.2.1.4.0)がORACLE_HOME:/u01/oid/12cにインストールされている場合、12c (12.2.1.4.0) ORACLE_HOMEをアンインストールして、Oracle Internet Directory 14 c (14.1.2.1.0)を/u01/oid/12cにインストールします。

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

ターゲット・システムにサインインします。
Oracle Technology NetworkまたはOracle Software Delivery Cloudから次のものをターゲット・システムにダウンロードします。
- Oracle Fusion Middlewareインフラストラクチャ(fmw_14.1.2.0.0_infrastructure.jar)
- Oracle Internet Directory (UNIX: fmw_12.2.1.3.0_oid_<platform>.bin)、(Windows: fmw_12.2.1.3.0_oid_win64.exe)
の製品のディストリビューションをダウンロードしたディレクトリに移動します
Oracle Fusion Middleware Infrastructureのインストール・プログラムを開始します。
- (UNIX) JDK_HOME/bin/java -jar fmw_14.1.2.0.0_infrastructure.jar
- (Windows) JDK_HOME\bin\java -jar fmw_14.1.2.0.0_infrastructure.jar
UNIXオペレーティング・システムでは、「インストール・インベントリの設定」画面が表示されます。
プロンプトが表示されたら、中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システム・グループ名に中央インベントリの場所への書込み権限があることを確認し、「次へ」をクリックします。

ノート:
「インストール・インベントリの設定」画面は、Windowsオペレーティング・システムでは表示されません。
「ようこそ」画面で、情報をレビューしてすべての前提条件を満たしていることを確認します。「次へ」をクリックします。
「自動更新」画面で、オプションを選択します。
- この時点でソフトウェアの更新をシステムで確認しないようにする場合は、「自動更新をスキップ」を選択します。
- パッチ・ファイルをダウンロードした場合は、「ディレクトリからパッチを選択」を選択して、ローカル・ディレクトリに移動します。
- My Oracle Supportアカウントを持っている場合にソフトウェアの更新を自動でダウンロードするには、「My Oracle Supportで更新を検索」を選択します。Oracle Supportの資格証明を入力して、「検索」をクリックします。インストーラがMy Oracle Supportにアクセスするようにプロキシ・サーバーを構成するには、「プロキシ設定」をクリックします。「接続のテスト」をクリックして接続をテストします。
「次へ」をクリックします。
「インストールの場所」画面でOracleホーム・ディレクトリの場所を指定し、「次へ」をクリックします。
Oracle Fusion Middlewareディレクトリ構造の詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成のためのディレクトリの理解に関する項を参照してください。
「インストール・タイプ」画面で、次に示す項目を選択します。
- インフラストラクチャの場合は、「Fusion Middlewareインフラストラクチャ」を選択します。
「次へ」をクリックします。

ノート:
このドキュメントのトポロジにサーバーの例は含まれません。製品環境にはサンプルをインストールしないように強くお薦めします。
「前提条件チェック」画面では、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
検証済のタスクのリストを表示するには、「正常なタスクの表示」を選択します。ログの詳細を表示するには、「ログの表示」を選択します。前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。エラー・メッセージや警告メッセージを無視してインストールを続けるには、「スキップ」をクリックします(非推奨)。
「インストールの概要」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルには、入力したすべての情報が収集して格納され、後で(コマンドラインから)サイレント・インストールを実行するために使用できます。
「インストール」をクリックしてインストールを開始します。
「インストールの進行状況」画面で、プログレス・バーが100%完了になったら、「終了」をクリックしてインストーラを閉じるか、「次へ」をクリックしてサマリーを表示します。
「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。情報を確認し、「終了」をクリックしてインストーラを閉じます。
Oracle Fusion Middlewareインフラストラクチャをインストールした後、次のコマンドを入力してOracle Internet Directoryのインストーラを起動し、前述のステップを繰り返してインストーラの各画面を移動します。
(UNIX) ./fmw_12.2.1.3.0_oid_<platform>.bin

(Windows) fmw_12.2.1.3.0_oid_win64.exe
14c (14.1.2.1.0)が正常にインストールされたら、14c (14.1.2.1.0) Fusion Middlewareリリース・ノートに記載されているパッチをインストールします。

ノート:

Oracle Internet Directoryのインストールの詳細は、Oracle Internet DirectoryのインストールのOracle Internet Directoryソフトウェアのインストールに関する項を参照してください。
Oracle Fusion Middleware Infrastructureのインストール方法の詳細は、『Oracle Fusion Middleware Infrastructureのインストールと構成』の「Infrastructureソフトウェアのインストール」を参照してください。

親トピック: Oracle Internet Directoryの単一ノードの12c環境のアップグレード

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

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

ノート:

これは、同じ場所に配置されたOracle Internet Directoryのデプロイメント・シナリオにのみ適用でき、スタンドアロン・デプロイメントのアップグレードには適用できません。

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

親トピック: Oracle Internet Directoryの単一ノードの12c環境のアップグレード

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

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

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

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

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

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

ノート:

パフォーマンスに影響を及ぼさないよう、オフピーク時に準備状況チェックを実行することをお薦めします。

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

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

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

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

oracle_common/upgrade/binディレクトリに移動します。
- (UNIX) ORACLE_HOME/oracle_common/upgrade/bin
- (Windows) ORACLE_HOME\oracle_common\upgrade\bin
Upgrade Assistantを起動します。
- (UNIX) ./ua -readiness
- (Windows) ua.bat -readiness
ノート:
DISPLAY環境変数がGUIモードを有効にするように適切に設定されていないと、次に示すエラーが発生することがあります。
```
Xlib: connection to ":1.0" refused by server
Xlib: No protocol specified 
```
この問題を解決するには、DISPLAY環境変数をローカル・ワークステーションのシステム名またはIPアドレスに設定して、Upgrade Assistantを再実行します。

このようなエラーがDISPLAYの設定後にも続く場合は、別のGUIツール(vncconfigなど)を起動してみてください。同じエラーが表示される場合は、DISPLAY環境変数の設定に間違いが残っている可能性があります。
その他のコマンドラインに指定可能なパラメータの詳細は、次の項を参照してください。

Upgrade Assistantのパラメータ

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

Upgrade Assistantのパラメータ

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

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

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

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

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

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

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

「ようこそ」画面で、準備状況チェックに関する情報を確認します。「次へ」をクリックします。
「準備状況チェック・タイプ」画面で、実行する準備状況チェックを選択します。
- 「個別に選択されたスキーマ」: アップグレード前に確認するスキーマを個別に選択できます。準備状況チェックは、スキーマがアップグレードに対応しているかどうか、またはアップグレードが必要かどうかをレポートします。
  このオプションを選択すると、画面名が「選択したスキーマ」に変更されます。
- 「ドメイン・ベース」: Upgrade Assistantは、「ドメイン・ディレクトリ」フィールドで指定されたドメイン内で、アップグレード可能なスキーマまたはコンポーネントのすべてを検出して選択するようになります。
  このオプションを選択すると、画面名が「スキーマおよび構成」に変更されます。
  Upgrade Assistantですべてのスキーマとコンポーネント構成をチェックする場合は、デフォルトの選択を変更しないで使用します。それ以外の場合は、次に示す特定のオプションを選択します。
  - 「すべてのスキーマのチェックを含める」: アップグレードに対応したコンポーネントをすべて検出して確認します。
  - 「すべての構成のチェックを含める」: 管理対象WebLogic Serverドメインのコンポーネント構成を確認します。
「次へ」をクリックします。
「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、アップグレードに対応可能なスキーマを持つコンポーネントを選択して、準備状況チェックの実行対象にします。
「ドメイン・ベース」を選択した場合: 「コンポーネント・リスト」画面で、準備状況チェックを実行するドメインにあるコンポーネントのリストを確認します。

依存コンポーネントのあるコンポーネントを選択すると、該当するコンポーネントが自動的に選択されます。たとえば、Oracle Platform Security Servicesを選択すると、Oracle Audit Servicesが自動的に選択されます。
選択したコンポーネントによっては、追加の画面が表示されることがあります。たとえば、次のような作業が必要になることがあります。
- ドメイン・ディレクトリを指定します。
- 選択したスキーマに接続するために、次のスキーマ資格証明を指定します: 「データベース・タイプ」、「DBAユーザー名」および「DBAパスワード」。次に、「接続」をクリックします。
  
  ノート:
  Oracleデータベースは、デフォルトのデータベース・タイプです。データベース・タイプに間違いがないことを確認してから続行してください。間違ったデータベースを選択していることに気付いた場合でも、正しいタイプに変更するために、この画面に戻らないでください。そのかわりに、Upgrade Assistantを終了してから、正しいデータベース・タイプを選択した状態で準備状況チェックを再開し、すべてのスキーマに正しいデータベース・タイプが適用されるようにします。
- 「スキーマ・ユーザー名」オプションを選択して、「スキーマ・パスワード」を指定します。
  
  ノート:
  Upgrade Assistantでは、デフォルトの資格証明が自動的に有効になります。接続できない場合、スキーマの資格証明を手動で入力し、続行します。
「次」をクリックして、準備状況チェックを開始します。
「準備状況サマリー」画面で、選択内容に基づいて実行される準備状況チェックのサマリーを確認します。
選択内容を保存して、今後、レスポンス(サイレンス)モードでUpgrade Assistantを再実行する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所と名前を指定します。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。

詳細レポートを表示するには、「ログの表示」をクリックします。

「次へ」をクリックします。
「準備状況チェック」画面で、準備状況チェックのステータスを確認します。このプロセスには、数分かかることがあります。
複数のコンポーネントをチェックしている場合、それぞれのコンポーネントの進行状況は、それぞれ専用のプログレス・バーで同時に表示されます。

準備状況チェックが完了したら、「続行」をクリックします。
「準備状況の終了」画面で、準備状況チェックの結果(「準備状況成功」または「準備状況失敗」)を確認します。
- 準備状況チェックが成功した場合は、「準備状況レポートの表示」をクリックして完全なレポートを確認します。準備状況チェックが成功した場合でも、実際のアップグレードを実行する前に、準備状況レポートを確認するようにしてください。「検索」オプションは、レポート内の特定の語句を検索する際に使用します。また、このレポートには、完成した準備状況チェック・レポート・ファイルが格納されている場所も示されます。
- 準備状況チェックで問題またはエラーが発生した場合、「ログの表示」をクリックして、ログ・ファイルを確認して問題を特定し、問題を修正してから、準備状況チェックを再開してください。ログ・ファイルは、設定したコマンドライン・オプションにより管理されます。

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

準備状況レポートの理解

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

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

readiness<timestamp>.txt

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

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

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

レポートの情報	説明	必要なアクション
全体的な準備状況ステータス: 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.

準備状況レポート・ファイルのサンプルを次に示します。レポートにはこれらのチェックのすべてが含まれない場合があります。

Upgrade readiness check completed with one or more errors.

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

Starting readiness check of components.

Oracle Metadata Services
   Starting readiness check of Oracle Metadata Services.
     Schema User Name: DEV11_MDS
     Database Type: Oracle Database
     Database Connect String: machinename@yourcompany.com
     VERSION Schema DEV11_MDS is currently at version 12.2.1.4.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 12c Enterprise Edition Release 12.2.1.4.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.

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

必要なスキーマの作成

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

アップグレードの前に次のスキーマが存在する必要があります。現在どのスキーマが存在しているか不明な場合は、次のステップを参照してドメイン内の既存のスキーマを識別します。すでに存在する場合、これらのスキーマを再作成する必要はありません。

サービス表スキーマ(prefix_STB)。このスキーマは、ドメインベースのアップグレードに必要です。基本的なスキーマ構成情報(スキーマ接頭辞やパスワードなど)が格納され、他のOracle Fusion Middlewareコンポーネントはドメイン作成中にこれにアクセスして使用できます。このスキーマはリポジトリ作成ユーティリティ(RCU)を実行するときに自動的に作成されるもので、ここで他のスキーマに使用した既存のスキーマ所有者接頭辞を指定します。

ノート:

サービス表スキーマが存在しない場合、UPGAST-00328: スキーマ・バージョンのレジストリ表はこのデータベースに存在しません。その場合、アップグレード・アシスタントを実行するためにはサービス表スキーマを作成する必要がありますというエラー・メッセージが表示されることがあります

RCUを使用してスキーマを作成するには:

(オプション) 既存のドメインにスキーマが存在していることを確認する場合は、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 ;

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

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

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

オプション	説明および例
ホスト名	データベースが実行されるサーバーの名前を、次の書式で指定します。 `examplehost.exampledomain.com` Oracle RACデータベースの場合は、このフィールドにVIP名またはいずれかのノード名を指定します。
ポート	データベースのポート番号を指定します。Oracleデータベースのデフォルトのポート番号は、`1521`です。
サービス名	データベースのサービス名を指定します。通常、サービス名はグローバル・データベース名と同じです。 Oracle RACデータベースの場合、このフィールドにいずれかのノードのサービス名を指定します。たとえば: `examplehost.exampledomain.com`
ユーザー名	データベースのユーザー名を入力します。デフォルトのユーザー名は`SYS`です。
パスワード	データベース・ユーザーのパスワードを入力します。
ロール	ドロップダウン・リストからデータベース・ユーザーのロールを選択します。 NormalまたはSYSDBA

「コンポーネントの選択」画面で、次のようにします:
- バックエンド・ディレクトリのデプロイメントとしてOracle Unified Directory (OUD)がある場合、次のステップを実行します:
  1. 「新規接頭辞の作成」を選択し、カスタム接頭辞を指定します。
  2. Oracle Platform Security Servicesスキーマを選択します。
    依存関係に応じて、次のスキーマが自動的に選択されます:
    
    監査サービス
    
    監査サービス・アペンド
    
    監査サービス・ビューア
    
    WebLogicサービス
- バックエンド・ディレクトリのデプロイメントとしてのOracle Internet Directory (OID):
  既存の接頭辞を選択し、ドロップダウン・メニューから既存のスキーマの作成に使用された接頭辞を選択します(DEV14cなど)。
  この接頭辞は、スキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。次のスキーマが選択されていることを確認します。
  - Oracle Platform Security Services
  - 監査サービス
  - 監査サービス・アペンド
  - 監査サービス・ビューア
  - WebLogicサービス
ノート:
共通インフラストラクチャ・サービス(prefix_STB)スキーマがまだ作成されていない場合は、デフォルトで選択されます。

インストールするコンポーネントの接頭辞とスキーマ名をノートにとります。インストールの構成時にこの情報が必要になります。「次へ」をクリックします。
「前提条件チェック」ダイアログで、前提条件チェックが正常であることを確認し、「OK」をクリックします。
「スキーマ・パスワード」画面で、スキーマの所有者のパスワードを入力します。
この画面で入力したパスワードをノートにとってください。製品インストールの構成中に必要となります。
「表領域のマップ」画面で、作成するスキーマの目的の表領域マッピングを構成します。
「次へ」をクリックしてから、確認ダイアログの「OK」をクリックします。進行状況ダイアログに表領域の作成が完了したことが示されたら、「OK」をクリックします。
「サマリー」画面で情報を確認し、「作成」をクリックしてスキーマの作成を開始します。
この画面には、このRCU操作で作成されたログ・ファイルに関する情報が表示されます。特定のログ・ファイルの名前をクリックして、そのファイルの内容を表示します。
「完了サマリー」画面の情報を確認し、操作が正常に完了したことを確かめます。「閉じる」をクリックして、スキーマの作成を完了します。

親トピック: Oracle Internet Directoryの単一ノードの12c環境のアップグレード

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

サーバーとプロセスの停止後、Upgrade Assistantを使用して、12.2.1.4.0スキーマをOracle Fusion Middlewareの14c (14.1.2.1.0)リリースにアップグレードします。

ノート:

ドメインにWLSSchemaDataSourceデータ・ソースがある場合は、どのデータベース・ユーザーがそれに割り当てられているかを確認する必要があります。<PREFIX>_WLS_RUNTIMEが割り当てられている場合は、それを<PREFIX>_WLSに変更する必要があります。詳細は、「WLSSchemaDataSourceデータ・ソースのデータベース・ユーザーの確認」を参照してください。

ノート:

14c (14.1.2.1.0)では、将来のリリースへのゼロ・ダウンタイム・アップグレードを支援するために、次のスキーマが変更されています:

14c (14.1.2.1.0)より前に作成された、エディションが無効になっているスキーマを、14c (14.1.2.1.0)にアップグレードすると、エディションが有効になります。
14c (14.1.2.1.0)で作成されたスキーマは、エディションが有効になった状態で作成されます。

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

Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを14c (14.1.2.1.0)にアップグレードします。
Oracle Internet Directoryスキーマのアップグレード
アップグレード・アシスタントの各画面を通じて、製品スキーマをアップグレードします。
スキーマのアップグレードの確認
すべてのアップグレード・ステップを完了したら、schema_version_registryのスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードの成功を検証します。

親トピック: Oracle Internet Directoryの単一ノードの12c環境のアップグレード

Upgrade Assistantの起動

Upgrade Assistantを実行して、製品のスキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを14c (14.1.2.1.0)にアップグレードします。

一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。Upgrade Assistantを実行するユーザーの作成方法の詳細は、「Upgrade Assistantを実行するための非SYSDBAユーザーの作成」を参照してください。

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

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

親トピック: 製品スキーマのアップグレード

Oracle Internet Directoryスキーマのアップグレード

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

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

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

ノート:
Upgrade Assistantの画面の詳細は、画面上の「ヘルプ」をクリックしてください。
「選択したスキーマ」画面で、実行するスキーマ・アップグレード操作を選択します。
- 「個別に選択されたスキーマ」は、スタンドアロン・インストールがある場合、またはドメインで使用されるスキーマをすべてアップグレードするのではなく、アップグレードするスキーマを個別に選択する場合のオプションです。
  
  注意:
  対象の14c (14.1.2.1.0)コンポーネントをサポートするために使用するスキーマのみをアップグレードしてください。Oracle Fusion Middleware 14c (14.1.2.1.0)に含まれていないコンポーネントをサポートするために現在使用されているスキーマをアップグレードしないでください。
- 「ドメインで使用されるすべてのスキーマ」を使用すると、Upgrade Assistantは、ドメイン内でアップグレードに対応可能な「ドメイン・ディレクトリ」フィールドで指定されたスキーマを持つコンポーネントをすべて検出して選択します。これは、ドメイン支援のスキーマ・アップグレードとも呼ばれています。さらに、Upgrade Assistantはスキーマの入力画面に接続情報を事前に移入します。
  
  ノート:
  すべての必要なスキーマがアップグレードに含まれるように、ほとんどのアップグレードでは、「ドメインで使用されるすべてのスキーマ」を選択することをお薦めします。ただし、スタンドアロン・インストールには「個別に選択されたスキーマ」オプションを使用します。
「次へ」をクリックします。
「個別に選択されたスキーマ」を選択した場合: 「使用可能なコンポーネント」画面で、スキーマをアップグレードするコンポーネントを選択します。コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。
「前提条件」画面で、すべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次へ」をクリックします。

ノート:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。
スキーマ資格証明の画面で、アップグレードするスキーマごとにデータベース接続の詳細を指定します(この画面名は、選択したスキーマに応じて変化します)。
- 「データベース・タイプ」ドロップダウン・メニューからデータベース・タイプを選択します。
- データベース接続の詳細を入力して、「接続」をクリックします。
- 「スキーマ・ユーザー名」ドロップダウン・メニューからアップグレードするスキーマを選択し、スキーマのパスワードを入力します。アップグレードするスキーマに対して正しいスキーマ接頭辞を使用してください。
「調査」画面で、各スキーマを調査したUpgrade Assistantのステータスを確認して、スキーマのアップグレードの準備が整っていることを検証します。ステータスが「調査が終了しました。」になっている場合は、「次」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、一般的なアップグレード・エラーの解決の詳細をUpgrade Assistantによるアップグレードのアップグレードのトラブルシューティングで参照してください。
ノート:
- 確認フェーズ中に検出された問題を、アップグレードを進めずに解決した場合は、バックアップからリストアを再び行わずにUpgrade Assistantを開始できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックしてアップグレードを続行していた場合は、Upgrade Assistantを再開する前に、バックアップからアップグレード前の環境をリストアする必要があります。
- 調査プロセスを取り消してもスキーマまたは構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報を再収集する必要があります。
「アップグレード・サマリー」画面で、アップグレードまたは作成、あるいはその両方が行われるスキーマのサマリーを確認します。
アップグレード対象のスキーマごとに、正しいソース・バージョンとターゲット・バージョンがリストされていることを確認します。

これらのオプションを保存して、今後、レスポンス(サイレンス)モードでUpgrade Assistantを再実行する場合は、「レスポンス・ファイルの保存」をクリックして、レスポンス・ファイルの場所と名前を指定します。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。

「次へ」をクリックします。
「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

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

正しくアップグレードされていないスキーマがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

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

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

アップグレードが失敗した場合: 「アップグレード失敗」画面で、「ログの表示」をクリックし、エラーを表示してトラブルシューティングします。ログは、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列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。たとえば、スキーマ・バージョン番号が14.1.2.1.0になっていることを確認します。

ノート:

ただし、すべてのスキーマ・バージョンが更新されるわけではありません。一部のスキーマではこのリリースへのアップグレードが必要なく、アップグレード前のバージョン番号が保持されます。
STATUSフィールドは、スキーマのパッチ適用操作中はUPGRADINGまたはUPGRADEDのどちらかになり、パッチ適用操作が完了するとVALIDになります。
ステータスが「INVALID」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。
IAU_APPENDとIAU_VIEWERが所有するシノニム・オブジェクトは、INVALIDと表示されますが、失敗を意味するものではありません。

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

親トピック: 製品スキーマのアップグレード

ドメインの再構成

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

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

WebLogic Serverコア・インフラストラクチャ
ドメイン・バージョン

ノート:

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

元のMiddlewareホームに、エラーを引き起こす可能性のあるデプロイメントが含まれていないことを確認します。
再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。
アップグレード・プロセス中に、非動的クラスタ・ドメインを動的クラスタ・ドメインに変換することはサポートされていません。

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

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

ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。
すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。
起動スクリプトが更新されます。

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

ノート:

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

ドメインのバックアップ
再構成ウィザードの起動
Oracle Internet Directoryドメインの再構成
再構成ウィザードの各画面を移動して、既存のドメインを再構成します。

親トピック: Oracle Internet Directoryの単一ノードの12c環境のアップグレード

ドメインのバックアップ

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

ドメイン・ディレクトリのバックアップを作成します。
各リモート管理対象サーバーのドメインを更新する前に、各リモート・マシンのドメイン・ディレクトリのバックアップ・コピーを作成します。
ドメインのバックアップしたバージョンが完全であることを確認します。

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

親トピック: ドメインの再構成

再構成ウィザードの起動

ノート:

再構成プロセスを開始する前に、管理サーバーとすべての並置されている管理対象サーバーを停止します。

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

ドメインが存在するシステムにサインインします。
コマンド・シェル(UNIXオペレーティング・システムの場合)またはコマンド・プロンプト・ウィンドウ(Windowsオペレーティング・システムの場合)を開きます。
oracle_common/common/binディレクトリに移動します。
- (UNIX) NEW_ORACLE_HOME/oracle_common/common/bin
- (Windows) NEW_ORACLE_HOME\oracle_common\commom\bin
次に示すロギングオプションを指定して、再構成ウィザードを開始します。
- (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

親トピック: ドメインの再構成

Oracle Internet Directoryドメインの再構成

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

ノート:

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

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

「ドメインの選択」画面で、アップグレードするドメインの場所を指定するか、「参照」をクリックしてナビゲートし、ドメインのディレクトリを選択します。「次」をクリックします。
「再構成セットアップの進行状況」画面で、セットアップ・プロセスの進行状況を確認します。完了したら、「次へ」をクリックします。
このプロセスでは次の処理が行われます。
- Fusion Middleware製品を含む、インストール済製品の再構成テンプレートが自動的に適用されます。これにより、config.xml、config-groups.xml、security.xmlなどの様々なドメイン構成ファイルが更新されます。
- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。
- ドメイン・アップグレードが検証されます。
「ドメイン・モードおよびJDK」画面で、ドメインで使用するJDKを選択するか、「参照」をクリックして、使用するJDKにナビゲートします。14c (14.1.2.1.0)でサポートされているJDKバージョンは、17.0.12以降です。「次へ」をクリックします。

ノート:
このステージでは、「ドメイン・モード」を変更することはできません。

特定のプラットフォームでサポートされているJDKのリストは、Oracle Fusion Middlewareでサポートされているシステム構成の説明を参照してください。
「JDBCデータソース」画面で、データソースの「schedulerDS」を選択します。「次」をクリックします。
「JDBCデータ・ソース・テスト」画面で、接続テストが完了したことを確認します。「テストが完了しました。」というメッセージが表示されるまで待機してから「次へ」をクリックします。
「データベース構成タイプ」画面で、「RCUデータ」を選択して、サーバー表(_STB)スキーマに接続します。
RCUサービス表(_STB)スキーマ資格証明を使用してデータベース接続の詳細を入力して、「RCU構成の取得」をクリックします。

再構成ウィザードは、この接続を使用して、ドメインのコンポーネントに必要なデータソースを自動的に構成します。

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

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

チェックが成功した場合は、「次へ」をクリックします。チェックが失敗した場合は、接続の正しい詳細を再入力し、再試行します。

ノート:
12c (12.2.1.4.0)からアップグレードし、データベースに_OPSSまたは_IAU 12c (12.2.1.4.0)データベース・スキーマが含まれる場合、それらのスキーマのデータベース接続の詳細を手動で入力する必要があります。これらのスキーマは12cで不要であり、手動で作成する必要がありました。ユーザーはこれらのスキーマに名前を割り当てることができたため、再構成ウィザードではこれらは認識されません。_IAUの接続情報を指定するときに、IAU_APPENDユーザー情報を使用します。
「JDBCコンポーネント・スキーマ」画面で、各コンポーネント・スキーマのDBMS/サービスおよびホスト名が正しいことを確認し、「次へ」をクリックします。
「JDBCコンポーネント・スキーマ・テスト」画面で、すべてのコンポーネント・スキーマを選択して「選択された接続のテスト」をクリックして、各スキーマの接続をテストします。テストの結果は、「ステータス」列に表示されます。
チェックが完了したら、「次へ」をクリックします。
「拡張構成」画面で、拡張構成を実行するすべてのカテゴリを選択できます。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。

ノート:
「拡張構成」画面にリストされるカテゴリは、ドメインに選択したテンプレートに定義されているリソースによって異なります。

このアップグレードではオプションを選択せずに、「次へ」をクリックします。
「構成のサマリー」画面で、ドメインの詳細な構成設定を確認してから続行します。
「表示」ドロップダウン・リストからフィルタ・オプションを選択すると、右側のパネルに表示される項目を制限できます。

構成を変更するには、「戻る」をクリックして適切な画面に戻ります。ドメインを再構成するには、「再構成」をクリックします。

ノート:
ドメインを再構成しても、その場所は変更されません。
「再構成の進行状況」画面には、再構成プロセスの進行状況が表示されます。
このプロセスでは次の処理が行われます。
- ドメイン情報が抽出、保存および更新されます。
- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。
進捗バーが100%になったら、「次へ」をクリックします。
「構成の終了」画面に、再構成プロセスが成功して完了したか、または失敗したかどうかが示されます。管理サーバーURL(リスニング・ポートを含む)とともに再構成されたドメインの場所も表示します。再構成が成功した場合は、「Oracle Weblogic Serverの再構成に成功しました」と表示されます。
再構成プロセスが正常に完了しなかった場合は、その理由を示すエラー・メッセージが表示されます。問題を解決するための適切な措置を講じます。問題を解決できない場合は、My Oracle Supportに連絡してください。

以後の操作のためにドメインの場所と管理サーバーURLをノートにとります。

親トピック: ドメインの再構成

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

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

Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを14c (14.1.2.1.0)にアップグレードします。
ドメイン・コンポーネント構成のアップグレード
アップグレード・アシスタントの各画面を移動して、WebLogicドメイン内のコンポーネント構成をアップグレードします。
サーバーおよびプロセスの起動
正常なアップグレードの後に、管理サーバーや管理対象サーバーなど、すべてのプロセスおよびサーバーを再起動します。
ドメイン固有コンポーネント構成のアップグレードの確認
ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、リモート・コンソールにサインインし、アップグレードされた各コンポーネントのバージョン番号が14.1.2.1.0になっていることを確認します。

親トピック: Oracle Internet Directoryの単一ノードの12c環境のアップグレード

Upgrade Assistantの起動

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

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

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

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

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

再構成ウィザードを実行してWebLogicドメインを14c (14.1.2.1.0)に再構成した後、Upgrade Assistantを実行して、更新したドメイン構成と一致するようドメイン・コンポーネント構成をアップグレードします。

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

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

ノート:
Upgrade Assistantの画面の詳細は、画面上の「ヘルプ」をクリックしてください。
次の画面で、次を実行します。
- 「ドメインによって使用されるすべての構成」を選択します。画面名が「WebLogicコンポーネント」に変更されます。
- 「ドメイン・ディレクトリ」フィールドに、WebLogicドメイン・ディレクトリのパスを入力します。
「次へ」をクリックします。
アップグレード前の環境に複数のWebLogicドメインがあるが、Oracle Web Services Manager (OWSM)ポリシー・マネージャが1つのドメインのみにあり、OWSMエージェントが他のドメインにある場合: OWSMポリシー・マネージャ画面で、Oracle Web Services Manager (OWSM)ポリシー・マネージャがデプロイされているWebLogic管理サーバー・ドメインの資格証明を提供します。
「コンポーネント・リスト」画面で、構成をアップグレードするコンポーネントがリストにすべて含まれていることを確認し、「次」をクリックします。
アップグレードするコンポーネントが表示されない場合は、「戻る」をクリックして前の画面に移動し、異なるドメインを指定します。
「前提条件」画面で、すべてのチェック・ボックスを選択して、前提条件を満たしていることを確認します。「次へ」をクリックします。

ノート:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。
「調査」画面で、各コンポーネントを調査したUpgrade Assistantのステータスを確認して、コンポーネント構成のアップグレードの準備が整っていることを検証します。ステータスが「アップグレードの準備」になっている場合は、「次へ」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログの「いいえ」をクリックして、アップグレードをキャンセルすることをお薦めします。「ログの表示」をクリックしてエラーの原因を確認し、一般的なアップグレード・エラーの解決の詳細をUpgrade Assistantによるアップグレードのアップグレードのトラブルシューティングで参照してください。
ノート:
- 確認フェーズ中に検出された問題を、アップグレードを進めずに解決した場合は、バックアップからリストアを再び行わずにUpgrade Assistantを開始できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックしてアップグレードを続行していた場合は、Upgrade Assistantを再開する前に、バックアップからアップグレード前の環境をリストアする必要があります。
- 調査プロセスを取り消しても構成データに影響はありませんが、将来のアップグレード・セッションでは、Upgrade Assistantが収集した情報の再収集が必要になります。
「アップグレード・サマリー」画面で、コンポーネント構成のアップグレードに選択したオプションのサマリーを確認します。
レスポンス・ファイルには、入力したすべての情報が収集および格納されます。このファイルにより、その後のサイレント・アップグレードの実行が可能になります。サイレント・アップグレードは、Upgrade Assistantとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。
「アップグレードの進行状況」画面で、アップグレードのステータスを監視します。

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

正しくアップグレードされていないコンポーネントがある場合は、Upgrade Assistantのログ・ファイルで情報を確認します。

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

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

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

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

ノート:

アップグレードが成功すると、Oracle Internet Directoryコンポーネント・インスタンスに関連するアーティファクトが、ASインスタンスからWebLogicドメインにコピーされます。また、新しいマシン(oidhost1など)が作成されて、対応するOIDインスタンスに関連付けられます。

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

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

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

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

ノート:

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

Fusion Middleware環境を起動するには、次に示すステップを実行します。

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

ノート:

既存のセキュリティ設定によっては、保護された本番モードが有効なドメインを管理するために、追加の構成が必要な場合があります。詳細は、WebLogicリモート・コンソールを使用した管理サーバーへの接続に関する項を参照してください

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

(UNIX) DOMAIN_HOME/bin/startWebLogic.sh
(Windows) DOMAIN_HOME\bin\startWebLogic.cmd

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

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

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

(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
(Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

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

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

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

(UNIX) DOMAIN_HOME/bin/startNodeManager.sh
(Windows) DOMAIN_HOME\bin\startNodeManager.cmd

ステップ4: Oracle Internet Directoryコンポーネントを起動する

Oracle Internet Directoryコンポーネントを起動するには、startComponentスクリプトを使用します。

(UNIX) DOMAIN_HOME/bin/startComponent.sh component_name
(Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

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

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

ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、リモート・コンソールにサインインし、アップグレードされた各コンポーネントのバージョン番号が14.1.2.1.0になっていることを確認します。

ノート:

ホストされたWebLogicリモート・コンソールにアクセスする前に、ホストされたWebLogicリモート・コンソールをデプロイする必要があります。詳細は、Remote Consoleオンライン・ヘルプを参照してください。

リモート・コンソールにサインインするには、http://hostname:port/rconsole、またはHTTPSの場合は https://hostname:port/rconsoleに移動します。

ノート:

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

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

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

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

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

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

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

ノート:

Fusion Middleware環境を起動するには、次に示すステップを実行します。

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

ノート:

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

(UNIX) DOMAIN_HOME/bin/startWebLogic.sh
(Windows) DOMAIN_HOME\bin\startWebLogic.cmd

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

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

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

(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url
(Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

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

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

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

(UNIX) DOMAIN_HOME/bin/startNodeManager.sh
(Windows) DOMAIN_HOME\bin\startNodeManager.cmd

ステップ4: Oracle Internet Directoryコンポーネントを起動する

Oracle Internet Directoryコンポーネントを起動するには、startComponentスクリプトを使用します。

(UNIX) DOMAIN_HOME/bin/startComponent.sh component_name
(Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

親トピック: Oracle Internet Directoryの単一ノードの12c環境のアップグレード

14c (14.1.2.1.0)でのSSLウォレットの作成

12cのOracle Internet Directory (OID)サーバーでは、MD5シグネチャで署名された証明書はサポートされていません。

アップグレード後に、OIDサーバーに対して作成および使用されたMD5シグネチャに基づく証明書を、SHA1以上に基づく証明書に変更して、OIDサーバーとの適切なSSL通信を確保する必要があります。

SSLウォレットの作成の詳細は、『Oracle Internet Directoryの管理』のWLSTを使用したSSLの構成に関する項を参照してください。

親トピック: Oracle Internet Directoryの単一ノードの12c環境のアップグレード

新しいOracle Directory Services Managerコンソールへのアクセス

Oracle Directory Services Manager (ODSM)コンソールのURLは、14c (14.1.2.1.0)で変更されています。

Oracle Internet Directoryを14c (14.1.2.1.0)にアップグレードすると、次のURLのOracle Directory Services Manager (ODSM)コンソールにアクセスできます。

http://host:adminserver_port/odsm

デフォルトのポートは7001です。

親トピック: Oracle Internet Directoryの単一ノードの12c環境のアップグレード