6 管理対象Oracle HTTP Serverのアップグレード(以前の12cリリースから)
この章では、管理対象Oracle HTTP Serverを以前の12cリリースから最新の12cリリースにアップグレードするための手順について説明します。このアップグレードの有効な開始ポイントは、12cのリリース12.1.2以降です。
この手順は、システムに既存の12c Fusion Middleware Infrastructureがインストールおよび構成(完全JRFまたは制限付きJRFモードのいずれかのWebLogicドメイン)されていることを想定しています。
ノート:
管理対象/コロケートOracle HTTP Serverを完全JRFまたは制限付きJRFドメインのいずれかでインストールおよび構成できます。2つの主な違いは、制限付きJRFモードの場合、データベースの依存性がないことです。「完全JRFモードと制限付きJRFモードについて」を参照してください。
必要に応じて、完全JRFモードのデータベース・スキーマのみをアップグレードする必要があります。
- 管理対象Oracle HTTP Serverのアップグレード・プロセス(以前の12cリリースから)について
管理対象Oracle HTTP Serverのアップグレード・プロセスの概要に関するフローチャートとロードマップを再確認します。 - 製品ディストリビューションのインストール
アップグレードの開始前に、Oracle Fusion MiddlewareインフラストラクチャとOracle HTTP Server 12c (12.2.1.3.0)のディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。 - アップグレード前の準備状況チェックの実行
アップグレードにかかわる潜在的な問題を特定するために、アップグレード・プロセスの開始前に、準備状況チェックの実行をお薦めします。準備状況チェックによって、アップグレードにかかわる潜在的な問題をすべて検出できるわけではない点に注意してください。準備状況チェックのレポートが成功を示していても、アップグレードが失敗することもあります。 - サーバーとプロセスの停止
Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、すべてのアップグレード前のプロセス、および管理サーバーや管理対象サーバーを含めたすべてのサーバーを停止する必要があります。 - 製品スキーマのアップグレード(完全JRFにのみ適用可能)
サーバーとプロセスの停止後に、Upgrade Assistantを使用して、サポートされている製品スキーマをOracle Fusion Middlewareの現在のリリースにアップグレードします。 - ドメインの再構成について
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.3.0)にあわせて再構成します。 - ドメイン・コンポーネント構成のアップグレード
ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。 - サーバーとプロセスの起動
アップグレードが正常に完了したら、すべてのプロセスと管理サーバーや管理対象サーバーを含めたすべてのサーバーを再起動します。 - アップグレードの確認
管理コンソール、Enterprise Manager Fusion Middleware ControlおよびOHSのホーム・ページにログインできれば、アップグレードは正常に完了しています。
管理対象Oracle HTTP Serverのアップグレード・プロセス(以前の12cリリースから)について
管理対象Oracle HTTP Serverのアップグレード・プロセスの概要に関するフローチャートとロードマップを再確認します。
図6-1は、管理対象Oracle HTTP Serverを最新の12cリリースにアップグレードするためのプロセス・フローを示しています。各ステップで使用するツールのリストも示します。
図6-1 管理対象Oracle HTTP Serverのアップグレードのプロセス・フローチャート(以前の12cリリースから)
「図6-1 管理対象Oracle HTTP Serverのアップグレードのプロセス・フローチャート(以前の12cリリースから)」の説明
表6-1では、以前の12cリリースから12c (12.2.1.3.0)に管理対象Oracle HTTP Serverをアップグレードする際に実行する必要があるタスクについて説明します。
表6-1 管理対象Oracle HTTP Serverをアップグレードするためのタスク(以前の12cリリースから)
| タスク | 説明 |
|---|---|
|
必須 管理対象Oracle HTTP Serverをアップグレードしていることを確認します。 |
既存の環境にどの種類のOracle HTTP Serverが含まれるかを判断するには、Oracle HTTP Serverがスタンドアロンか管理対象(コロケート)かの判断を参照してください。 |
|
必須 このガイドの概要に関するトピックを再確認して、アップグレード前のタスクを完了します(まだ実行していない場合)。 |
アップグレード前タスクには、ご使用の本番環境のクローニング、システム要件および資格証明の確認、未使用データのパージおよび非SYSDBAユーザーの作成が含まれます。 アップグレード前タスクの完全なリストは、Oracle HTTP Serverのアップグレードの準備を参照してください。 |
|
必須 12.2.1.3.0 Fusion MiddlewareインフラストラクチャとOracle HTTP Serverのディストリビューションをダウンロードしてインストールします。 |
インフラストラクチャのディストリビューションには、その他のFusion Middleware製品をインストールするための基盤の設定に必要な、WebLogic ServerおよびJava Required Files (JRF)が同梱されています。 このガイドのアップグレード・トポロジに定義されているように、インフラストラクチャは新規のOracleホームにインストールする必要があります。 Oracle HTTP Serverは、12.2.1.3.0インフラストラクチャのインストール時に作成したOracleホームにインストールする必要があります。 「製品ディストリビューションのインストール」を参照してください。 |
|
オプション 準備状況チェックを実行します。 |
Upgrade Assistantを使用した準備状況チェックの実行は、アップグレード前の環境について、アップグレードの準備が整っているかどうかを判断する際に役立ちます。
完全な手順は、「アップグレード前の準備状況チェックの実行」を参照してください。 |
|
必須 12cインスタンスを停止します。 |
アップグレード・プロセスの開始前に、管理サーバー、管理対象サーバー、および12cインスタンスを停止します。 |
|
必須 Upgrade Assistantを使用して既存のスキーマをアップグレードします。 |
「製品スキーマのアップグレード(完全JRFにのみ適用可能)」を参照してください。 |
|
必須 既存のドメインを再構成します。 |
再構成ウィザードを12c Oracle HTTP Serverインストールから実行して、既存のドメインを再構成します。 再構成ウィザードを使用した既存のドメインの再構成を参照してください。 |
|
必須 既存のドメイン構成をアップグレードします。 |
インストール後、Upgrade Assistantを使用してOracle HTTP Serverおよびシステム・コンポーネント・インフラストラクチャをアップグレードする必要があります。 |
|
必須 サーバーおよびプロセスを再起動します。 |
アップグレード・プロセスは完了です。これで、管理サーバー、管理対象サーバーおよび12.2.1.3.0インスタンスを再起動できます。 「サーバーとプロセスの起動」を参照してください。 |
|
必須 アップグレードを検証します。 |
アップグレードの検証方法は、「アップグレードの確認」を参照してください。 |
製品ディストリビューションのインストール
アップグレードの開始前に、Oracle Fusion MiddlewareインフラストラクチャとOracle HTTP Server 12c (12.2.1.3.0)のディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。
ノート:
アップグレードにInfrastructureが必要な場合は、その他のFusion Middleware製品をインストールする前に、まずOracle Fusion Middlewareディストリビューションをインストールする必要があります。アップグレード前の準備状況チェックの実行
アップグレードにかかわる潜在的な問題を特定するために、アップグレード・プロセスの開始前に、準備状況チェックの実行をお薦めします。準備状況チェックによって、アップグレードにかかわる潜在的な問題をすべて検出できるわけではない点に注意してください。準備状況チェックのレポートが成功を示していても、アップグレードが失敗することもあります。
- アップグレード前の準備状況チェックの実行について
Upgrade Assistantを-readinessモードで実行することで、実際のアップグレードを実行する前に問題を検出できます。Upgrade Assistantを使用すると、準備状況チェックはGUIモードで実行できます。また、レスポンス・ファイルを使用するとサイレント・モードで実行できます。 - 準備状況モードでのUpgrade Assistantの起動
-readinessパラメータを使用して、Upgrade Assistantを準備状況モードで起動します。 - Upgrade Assistantでの準備状況チェックの実行
Upgrade Assistantの各画面を通じて、アップグレード前の準備状況チェックを完了します。 - 準備状況レポートの理解
ドメインの準備状況チェックを実行した後、レポートを確認してアップグレードを成功させるためのアクションをとる必要があるかどうかを判断します。
アップグレード前の準備状況チェックの実行について
Upgrade Assistantを-readinessモードで実行することで、実際のアップグレードを実行する前に問題を検出できます。Upgrade Assistantを使用すると、準備状況チェックはGUIモードで実行できます。また、レスポンス・ファイルを使用するとサイレント・モードで実行できます。
Upgrade Assistantの準備状況チェックは、サポート対象の開始ポイントにあるFusion MiddlewareのスキーマとWebLogicドメインの構成について、読取り専用のアップグレード前確認を実行します。この確認は、読取り専用の操作です。
準備状況チェックでは、フォーマットされ、タイムスタンプの付けられた準備状況レポートが生成され、実際のアップグレードを試みる前に潜在的な問題に対処できます。問題が検出されない場合は、アップグレード・プロセスを開始できます。アップグレードを実行する前に、このレポートを詳細に確認することをお薦めします。
準備状況チェックは、既存のOracle Fusion Middlewareドメインがオンライン(他のユーザーがアクティブに使用している間)またはオフラインである間に実行できます。
準備状況チェックは、実際のアップグレードの実行前に、何度でも実行できます。ただし、アップグレードの実行後には、準備状況チェックを実行しないでください。これは、レポート結果が、アップグレード前の準備状況チェックと異なることがあるためです。
ノート:
パフォーマンスが影響されることを回避するために、オフピーク時に準備状況チェックを実行することをお薦めします。
親トピック: アップグレード前の準備状況チェックの実行
準備状況モードでのUpgrade Assistantの起動
-readinessパラメータを使用して、Upgrade Assistantを準備状況モードで起動します。
Upgrade Assistantのパラメータ
コマンドラインからUpgrade Assistantを起動する際に、追加のパラメータを指定できます。
表6-2 Upgrade Assistantコマンドライン・パラメータ
| パラメータ | 必須またはオプション | 説明 |
|---|---|---|
|
|
準備状況チェックの場合は必須
ノート: スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では準備状況チェックを実行できません。 |
アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。 スキーマと構成がチェックされます。
|
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
|
サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須 |
レスポンス・ファイルに保存した入力を使用して、Upgrade Assistantを実行します。このレスポンス・ファイルは、GUIモードでUpgrade Assistantを実行したときの入力データから生成されます。このパラメータを使用すると、Upgrade Assistantがサイレント・モードで(Upgrade Assistant画面を表示せずに)実行されます。 |
|
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
|
オプション |
次のいずれかの属性を指定して、ログイン・レベルを設定します。
デフォルトのロギング・レベルは
|
|
|
オプション |
アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。既存の書込み可能なディレクトリを指定する必要があります。Upgrade Assistantは、このディレクトリにログ・ファイルと一時ファイルを作成します。 デフォルトの場所は次のとおりです。 (UNIX)
(Windows)
|
|
|
オプション |
すべてのコマンドライン・オプションを表示します。 |
Upgrade Assistantを使用した準備状況チェックの実行
Upgrade Assistantの各画面を通じて、アップグレード前の準備状況チェックを完了します。
親トピック: アップグレード前の準備状況チェックの実行
準備状況レポートの理解
ドメインの準備状況チェックを実行後、レポートを確認して、正常にアップグレードするために何かアクションを実行する必要があるかどうかを判断します。
準備状況レポート・ファイルの形式は、次のとおりです。
readiness<timestamp>.txt
ここで、timestampは、準備状況チェックが実行された日付と時刻を示します。
準備状況レポートには、次に示す情報が含まれています。
表6-3 準備状況レポートの要素
| レポートの情報 | 説明 | 必要なアクション |
|---|---|---|
| 全体的な準備状況ステータス: SUCCESSまたはFAILURE | レポートの上部には、準備状況チェックが成功したか、または1つ以上のエラーが発生して完了したかが示されます。 | 1つ以上のエラーが発生してレポートが完了した場合、アップグレードを試みる前に、FAILを検索し、障害の原因となった問題を修正します。準備状況チェックは、アップグレードする前に必要に応じて何度でも再実行できます。 |
|
タイムスタンプ |
レポートが生成された日付と時刻です。 |
必要なアクションはありません。 |
|
ログ・ファイルの場所
|
生成されたログ・ファイルのディレクトリの場所です。 |
必要なアクションはありません。 |
|
準備状況レポートの場所
|
生成された準備状況レポートのディレクトリの場所です。 |
必要なアクションはありません。 |
|
チェックされたコンポーネントの名前 |
チェックに含まれるコンポーネントの名前およびバージョンとステータス。 |
このリリースにアップグレードできないコンポーネント(SOAコア拡張など)がドメインに含まれている場合は、アップグレードを試みないでください。 |
|
チェックされたスキーマの名前 |
チェックに含まれるスキーマの名前および現在のバージョンとステータス。 |
スキーマのバージョン番号をレビューします。このリリースにアップグレードできないスキーマがドメインに含まれる場合は、アップグレードを試みないでください。 |
|
個別のオブジェクトのテスト・ステータス: FAIL |
準備状況チェックのテストで、特定のオブジェクトに問題が検出されています。 |
失敗した問題がすべて解決するまでアップグレードしないでください。 |
|
個別のオブジェクトのテスト・ステータス: PASS |
準備状況チェックのテストでは、特定のオブジェクトに問題が検出されませんでした。 |
準備状況チェック・レポートにPASSステータスのみが表示されている場合、環境をアップグレードできます。ただし、準備状況チェックでは、ハードウェアやアップグレード時の接続性などの外部環境に関する問題を検出することはできません。アップグレードの進捗を常に監視する必要があります。 |
| <オブジェクト>の準備状況チェックの完了ステータス: FAILURE | 準備状況チェックによって、スキーマ、索引、データ型などの特定のオブジェクトに関する、解決する必要があるエラーが1つ以上検出されました。 | 失敗した問題がすべて解決するまでアップグレードしないでください。 |
| <オブジェクト>の準備状況チェックの完了ステータス: SUCCESS | 準備状況チェック・テストによって問題が検出されませんでした。 | 必要なアクションはありません。 |
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.
Oracle Fusion Middleware IAU Schemasの12.1.3.0バージョンを実行していて、それらのスキーマが11g (11.1.1.7以降)または12c (12.1.2.0)からアップグレードされている場合には、準備状況チェックは次に示すエラーで失敗する可能性があります。
Starting index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes
INFO Audit schema index DYN_EVENT_CATEGORY_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_EVENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_TENANT_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_INDEX in table IAU_COMMON is missing
the required columns or index itself is missing. This maybe caused by a known
issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_COMPONENT_TYPE_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
INFO Audit schema index DYN_USER_TENANT_INDEX in table IAU_COMMON is
missing the required columns or index itself is missing. This maybe caused by
a known issue, anyway, this missing index will be added in 12.2.2 upgrade.
Completed index test for table IAU_COMMON: TEST_REQUIRED_INDEXES --> Test
that the table contains all the required indexes +++ FAILノート:
準備状況レポートの欠落している索引に関するエラーは無視してもかまいません。これは既知の問題です。欠落している索引に対応するものが、スキーマのアップグレード操作時に追加されます。このエラーは、アップグレードするスキーマがRCUを使用して12c (12.2.1.3.0)で作成されていた場合は発生しません。親トピック: アップグレード前の準備状況チェックの実行
サーバーとプロセスの停止
Upgrade Assistantを実行してスキーマおよび構成をアップグレードする前に、すべてのアップグレード前のプロセスと管理サーバーや管理対象サーバーを含めたすべてのサーバーを停止する必要があります。
Oracle Fusion Middleware環境は、1つのOracle WebLogic Serverドメイン、1つの管理サーバー、複数の管理対象サーバー、Javaコンポーネント、システム・コンポーネント(Identity Managementのコンポーネントなど)およびメタデータのリポジトリとして使用する1つのデータベースで構成できます。コンポーネントは相互に依存していることがあるため、適切な順序で停止する必要があります。
ノート:
この項の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用して既存のアップグレード前のサーバーとプロセスを停止する方法について説明します。また、Oracle Fusion Middleware ControlとOracle WebLogic Server管理コンソールを使用することもできます。管理サーバーと管理対象サーバーおよびノード・マネージャの起動と停止を参照してください。アップグレード前のFusion Middleware環境を停止するには、アップグレード前のドメインに移動し、次のステップに従います。
ステップ1: システム・コンポーネントを停止する
Oracle HTTP Serverなどのシステム・コンポーネントを停止するには、stopComponentスクリプトを使用します。
-
(UNIX)
EXISTING_DOMAIN_HOME/bin/stopComponent.sh component_name -
(Windows)
EXISTING_DOMAIN_HOME\bin\stopComponent.cmd component_name
システム・コンポーネントは任意の順序で停止できます。
ステップ2: 管理対象サーバーを停止する
WebLogic Server管理対象サーバーを停止するには、stopManagedWebLogicスクリプトを使用します。
-
(UNIX)
EXISTING_DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url -
(Windows)
EXISTING_DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url
プロンプトが表示されたらユーザー名とパスワードを入力します。
ステップ3: Oracle Identity Managementのコンポーネントを停止する
Oracle Internet Directoryなど、Oracle Identity Managementコンポーネントを停止します。-
(UNIX)
EXISTING_DOMAIN_HOME/bin/stopComponent.sh component_name -
(Windows)
EXISTING_DOMAIN_HOME\bin\stopComponent.cmd component_name
ステップ4: 管理サーバーを停止する
管理サーバーを停止するときに、管理サーバーで稼働しているプロセス(WebLogic Server管理コンソールやFusion Middleware Controlなど)も停止します。
管理サーバーを停止するには、stopWebLogicスクリプトを使用します。
-
(UNIX)
EXISTING_DOMAIN_HOME/bin/stopWebLogic.sh -
(Windows)
EXISTING_DOMAIN_HOME\bin\stopWebLogic.cmd
プロンプトが表示されたら、管理サーバーのユーザー名とパスワード、およびURLを入力します。
ステップ5: ノード・マネージャを停止する
ノード・マネージャを停止するには、それが実行されているコマンド・シェルを閉じます。
またはnodemanager.propertiesのQuitEnabledの属性をtrueに設定した後(デフォルトはfalseです)、WLSTを使用して、ノード・マネージャに接続して停止できます。WebLogic Server WLSTコマンド・リファレンスのstopNodeManagerを参照してください。
製品スキーマのアップグレード(完全JRFにのみ適用可能)
サーバーとプロセスの停止後、Upgrade Assistantを使用して、Oracle Fusion Middlewareの現在のリリースにあわせてサポート対象の製品スキーマをアップグレードします。
アップグレード・アシスタントを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるアップグレード・アシスタントの画面は異なります。
- アップグレードに対応可能な既存のスキーマの特定
このオプションの作業では、スキーマ・バージョン・レジストリを問い合せることで、アップグレードの開始前に、使用可能スキーマのリストを確認できます。このレジストリには、バージョン番号、コンポーネント名とID、作成日と変更日、カスタム接頭辞などのスキーマ情報が含まれています。 - Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。 - Upgrade Assistantを使用した製品スキーマのアップグレード
Upgrade Assistantの各画面を通じて、製品スキーマをアップグレードします。 - スキーマのアップグレードの確認
すべてのアップグレード・ステップを完了したら、schema_version_registryのスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードの成功を検証します。
アップグレードに対応可能な既存のスキーマの特定
このオプションのタスクにより、使用可能なスキーマのリストを確認してから、スキーマ・バージョン・レジストリに問い合せることでアップグレードを開始できます。このレジストリには、バージョン番号、コンポーネント名とID、作成日と変更日、カスタム接頭辞などのスキーマ情報が含まれています。
Upgrade Assistantでドメイン内のすべてのスキーマをアップグレードすることも、アップグレードするスキーマを個別に選択することもできます。この判断には、次に示すステップを実行して、アップグレードに対応可能なすべてのスキーマのリストを表示することが役立ちます。
-
Oracleデータベースを使用している場合、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; -
生成されたレポートを調査します。
アップグレードの必要がないスキーマがある場合は、そのスキーマのアップグレード前のバージョンが
schema_version_registry表に維持されます。 -
既存のスキーマに使用していたスキーマ接頭辞名ノートにとっておきます。新しい12c (12.2.1.3.0)スキーマの作成時に、同じ接頭辞を使用することになります。
ノート:
-
既存のスキーマがサポート対象のバージョンではない場合は、そのスキーマをサポート対象バージョンにアップグレードしてから、12c (12.2.1.3.0)のアップグレード手順を使用する必要があります。詳細は、アップグレード前のバージョンのドキュメントを参照してください。
-
一部のコンポーネント(Oracle Enterprise Data Quality、Oracle GoldenGate Monitor、Oracle GoldenGate Veridataなど)では、標準的なOracle Fusion Middlewareのサポート対象バージョン以外のバージョンからのアップグレードがサポートされています。
-
以前のバージョンでOIDベースのポリシー・ストアを使用していた場合、アップグレードを実行する前に新しいOPSSスキーマを必ず作成します。アップグレード後も、OPSSスキーマはLDAPベース・ストアのままです。
-
Oracle Fusion Middlewareリリース12c (12.2.1.3.0)でアップグレード可能な製品のスキーマのみをアップグレードできます。まだ12c (12.2.1.3.0)へのアップグレードが未対応のコンポーネントを含むドメインはアップグレードしないでください。
親トピック: 製品スキーマのアップグレード(完全JRFにのみ適用可能)
アップグレード・アシスタントの起動
Upgrade Assistantを実行して、製品のスキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。
ノート:
Upgrade Assistantを開始する前に、Upgrade Assistantを実行しているプラットフォームのJVM文字エンコーディングがUTF-8に設定されていることを確認します。文字エンコーディングがUTF-8に設定されていない場合、名前にUnicode文字を含むファイルをダウンロードできません。アップグレードが失敗する可能性があります。
oracle_common/upgrade/binディレクトリに移動します。- (UNIX)
NEW_ORACLE_HOME/oracle_common/upgrade/bin - (Windows)
NEW_ORACLE_HOME\oracle_common\upgrade\bin
- (UNIX)
- Upgrade Assistantを起動します。
- (UNIX) ./ua
- (Windows) ua.bat
コマンドラインに指定可能なその他のパラメータ(ロギングのパラメータなど)の詳細は、次を参照してください。
Upgrade Assistantのパラメータ
コマンドラインからUpgrade Assistantを起動する際に、追加のパラメータを指定できます。
表6-4 Upgrade Assistantコマンドライン・パラメータ
| パラメータ | 必須またはオプション | 説明 |
|---|---|---|
|
|
準備状況チェックの場合は必須
ノート: スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では準備状況チェックを実行できません。 |
アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。 スキーマと構成がチェックされます。
|
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
|
サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須 |
レスポンス・ファイルに保存した入力を使用して、Upgrade Assistantを実行します。このレスポンス・ファイルは、GUIモードでUpgrade Assistantを実行したときの入力データから生成されます。このパラメータを使用すると、Upgrade Assistantがサイレント・モードで(Upgrade Assistant画面を表示せずに)実行されます。 |
|
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
|
オプション |
次のいずれかの属性を指定して、ログイン・レベルを設定します。
デフォルトのロギング・レベルは
|
|
|
オプション |
アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。既存の書込み可能なディレクトリを指定する必要があります。Upgrade Assistantは、このディレクトリにログ・ファイルと一時ファイルを作成します。 デフォルトの場所は次のとおりです。 (UNIX)
(Windows)
|
|
|
オプション |
すべてのコマンドライン・オプションを表示します。 |
親トピック: Upgrade Assistantの起動
Upgrade Assistantを使用した製品スキーマのアップグレード
Upgrade Assistantの各画面を通じて、製品スキーマをアップグレードします。
親トピック: 製品スキーマのアップグレード(完全JRFにのみ適用可能)
スキーマのアップグレードの確認
すべてのアップグレード・ステップを完了したら、schema_version_registryのスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードの成功を検証します。
Oracle Databaseを使用する場合、Oracle DBAを持つユーザーとしてデータベースに接続し、SQL*Plusから次を実行して現行のバージョン番号を取得します。
SET LINE 120 COLUMN MRC_NAME FORMAT A14 COLUMN COMP_ID FORMAT A20 COLUMN VERSION FORMAT A12 COLUMN STATUS FORMAT A9 COLUMN UPGRADED FORMAT A8 SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;
問合せ結果について:
-
VERSION列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。たとえば、スキーマ・バージョン番号が12.2.1.3.0であることを確認します。ノート:
ただし、すべてのスキーマ・バージョンが更新されるわけではありません。一部のスキーマは、このリリースにあわせたアップグレードの必要がなく、アップグレード前のバージョン番号を維持します。
-
STATUSフィールドは、スキーマのパッチ適用操作中はUPGRADINGまたはUPGRADEDのどちらかになり、パッチ適用操作が完了するとVALIDになります。 -
ステータスが
「INVALID」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。 -
IAU_APPENDとIAU_VIEWERが所有するシノニム・オブジェクトは、INVALIDと表示されますが、失敗を意味するものではありません。これらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトは、アクセスされるときに有効になります。これに該当する
INVALIDオブジェクトは、無視しても問題ありません。
親トピック: 製品スキーマのアップグレード(完全JRFにのみ適用可能)
ドメインの再構成について
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.3.0)にあわせて再構成します。
スタンドアロン・ドメインを再構成すると、ドメイン内のアプリケーションに応じて、次の項目が自動的に更新されます。
-
WebLogic Serverコア・インフラストラクチャ
-
ドメイン・バージョン
ノート:
再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。-
ドメインの
config.xmlファイルのドメイン・バージョン番号は、ターゲットのOracle HTTP Serverのバージョンに更新されます。 -
Oracle HTTP Serverの再構成テンプレートが自動的に選択され、ドメインに適用されます。これらのテンプレートは、スタンドアロン・ドメインがターゲットのOracle HTTP Serverバージョンと互換性を持つために必要な再構成タスクを定義します。
-
起動スクリプトが更新されます。
変更済の起動スクリプトを維持する場合は、そのスクリプトをバックアップしてから、再構成ウィザードを開始してください。
ノート:
ドメイン再構成プロセスを開始すると、行う変更を元に戻すことができません。再構成ウィザードの実行前には、アップグレード前チェックリストで説明しているように、ドメインのバックアップが作成されていることを確認してください。再構成ウィザードの実行中にエラーまたは他の割込みが発生した場合、バックアップ場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーすることによって、ドメインをリストアする必要があります。これは、再構成前の元の状態にドメインを復元するための唯一の方法です。- ドメインのバックアップ
- 再構成ウィザードの起動
- 再構成ウィザードを使用したドメインの再構成
再構成ウィザードの各画面を通じて既存のドメインを再構成します。
ドメインのバックアップ
再構成ウィザードの実行前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。
ドメイン・ディレクトリのバックアップを作成するには:
親トピック: ドメインの再構成について
再構成ウィザードの起動
ノート:
再構成プロセスを開始する前に、管理サーバーおよびすべてのコロケート管理対象サーバーを停止します。「サーバーとプロセスの停止」を参照再構成ウィザードをグラフィカル・モードで起動するには:
親トピック: ドメインの再構成について
ドメイン・コンポーネント構成のアップグレード
ドメインの再構成後、更新したドメイン構成と一致するように、ドメイン内でUpgrade Assistantを使用してドメイン・コンポーネント構成をアップグレードします。
- Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。 - Upgrade Assistantを使用したドメイン・コンポーネントのアップグレード
Upgrade Assistantの各画面を通じて、WebLogicドメインのコンポーネント構成をアップグレードします。 - ドメイン固有コンポーネント構成のアップグレードの確認
ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlにサインインし、各コンポーネントのバージョン番号が12.2.1.3.0であることを確認します。
アップグレード・アシスタントの起動
Upgrade Assistantを実行して、製品のスキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。
ノート:
Upgrade Assistantを開始する前に、Upgrade Assistantを実行しているプラットフォームのJVM文字エンコーディングがUTF-8に設定されていることを確認します。文字エンコーディングがUTF-8に設定されていない場合、名前にUnicode文字を含むファイルをダウンロードできません。アップグレードが失敗する可能性があります。
oracle_common/upgrade/binディレクトリに移動します。- (UNIX)
NEW_ORACLE_HOME/oracle_common/upgrade/bin - (Windows)
NEW_ORACLE_HOME\oracle_common\upgrade\bin
- (UNIX)
- Upgrade Assistantを起動します。
- (UNIX) ./ua
- (Windows) ua.bat
コマンドラインに指定可能なその他のパラメータ(ロギングのパラメータなど)の詳細は、次を参照してください。
Upgrade Assistantのパラメータ
コマンドラインからUpgrade Assistantを起動する際に、追加のパラメータを指定できます。
表6-6 Upgrade Assistantコマンドライン・パラメータ
| パラメータ | 必須またはオプション | 説明 |
|---|---|---|
|
|
準備状況チェックの場合は必須
ノート: スタンドアロン・インストール(WebLogic Serverによって管理されないインストール)では準備状況チェックを実行できません。 |
アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。 スキーマと構成がチェックされます。
|
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
|
サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須 |
レスポンス・ファイルに保存した入力を使用して、Upgrade Assistantを実行します。このレスポンス・ファイルは、GUIモードでUpgrade Assistantを実行したときの入力データから生成されます。このパラメータを使用すると、Upgrade Assistantがサイレント・モードで(Upgrade Assistant画面を表示せずに)実行されます。 |
|
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
|
オプション |
次のいずれかの属性を指定して、ログイン・レベルを設定します。
デフォルトのロギング・レベルは
|
|
|
オプション |
アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。既存の書込み可能なディレクトリを指定する必要があります。Upgrade Assistantは、このディレクトリにログ・ファイルと一時ファイルを作成します。 デフォルトの場所は次のとおりです。 (UNIX)
(Windows)
|
|
|
オプション |
すべてのコマンドライン・オプションを表示します。 |
親トピック: Upgrade Assistantの起動
Upgrade Assistantを使用したドメイン・コンポーネントのアップグレード
Upgrade Assistantの各画面を通じて、WebLogicドメインのコンポーネント構成をアップグレードします。
再構成ウィザードを実行して、WebLogicドメインを12c (12.2.1.3.0)にあわせて再構成したら、Upgrade Assistantを実行してドメイン・コンポーネント構成を更新後のドメイン構成と一致するようにアップグレードする必要があります。
親トピック: ドメイン・コンポーネント構成のアップグレード
ドメイン固有コンポーネント構成のアップグレードの確認
ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlにサインインし、各コンポーネントのバージョン番号が12.2.1.3.0になっていることを確認します。
管理コンソールにサインインするには、次に移動します: http://administration_server_host:administration_server_port/console
Oracle Enterprise Manager Fusion Middleware Control Consoleにサインインするには、次に移動します: http://administration_server_host:administration_server_port/em
ノート:
アップグレード後、管理ツールは、前のOracleホーム・ディレクトリではなく新しい12c (12.2.1.3.0)のOracleホーム・ディレクトリから必ず実行してください。
アップグレード・プロセス時に、一部のOWSMドキュメント(ポリシー・セット、ポリシーおよびアサーション・テンプレートなどの事前定義ドキュメント)のアップグレードが必要な場合があります。ポリシー・セットまたは事前定義ドキュメントがアップグレードされると、バージョン番号が1増分されます。
Upgrade Assistantを実行するためにFMWユーザーを作成した場合は、アップグレードが成功したことを確認してからアカウントを削除してください。
親トピック: ドメイン・コンポーネント構成のアップグレード
サーバーおよびプロセスの起動
アップグレードが正常に完了したら、すべてのプロセスと管理サーバーや管理対象サーバーを含めたすべてのサーバーを再起動します。
コンポーネントは相互に依存していることがあるため、適切な順序で起動する必要があります。
ノート:
この項の手順では、WLSTコマンドラインまたはスクリプトを使用してサーバーとプロセスを起動する方法について説明します。また、Oracle Fusion Middleware ControlとOracle WebLogic Server管理コンソールを使用することもできます。『Oracle Fusion Middlewareの管理』の管理サーバーと管理対象サーバーおよびノード・マネージャの起動と停止に関する項を参照してください。Fusion Middleware環境を起動するには、次のステップに従います。
ステップ1: 管理サーバーの起動
管理サーバーを起動するときに、管理サーバーで稼働するプロセス(WebLogic Server管理コンソールやFusion Middleware Controlなど)も起動します。
管理サーバーを起動するには、startWebLogicスクリプトを使用します。
-
(UNIX)
NEW_DOMAIN_HOME/bin/startWebLogic.sh -
(Windows)
NEW_DOMAIN_HOME\bin\startWebLogic.cmd
プロンプトが表示されたら、管理サーバーのユーザー名とパスワード、およびURLを入力します。
ステップ2: ノード・マネージャを起動する
ノード・マネージャを起動するには、startNodeManagerスクリプトを使用します。
-
(UNIX)
NEW_DOMAIN_HOME/bin/startNodeManager.sh -
(Windows)
NEW_DOMAIN_HOME\bin\startNodeManager.cmd
ステップ3: Oracle Identity Managementのコンポーネントを起動する
目的の環境に含まれるOracle Identity Managementのコンポーネント(Oracle Internet Directoryなど)を起動します。-
(UNIX)
NEW_DOMAIN_HOME/bin/startComponent.sh component_name -
(Windows)
NEW_DOMAIN_HOME\bin\startComponent.cmd component_name
ステップ4: 管理対象サーバーを起動する
WebLogic Server管理対象サーバーを起動するには、startManagedWebLogicスクリプトを使用します。
-
(UNIX)
NEW_DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url -
(Windows)
NEW_DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url
プロンプトが表示されたらユーザー名とパスワードを入力します。
ノート:
通常、管理対象サーバーを起動すると、そのサーバーにデプロイされているアプリケーションが開始されます。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。ステップ5: システム・コンポーネントを起動する
Oracle HTTP Serverなどのシステム・コンポーネントを起動するには、startComponentスクリプトを使用します。
-
(UNIX)
NEW_DOMAIN_HOME/bin/startComponent.sh component_name -
(Windows)
NEW_DOMAIN_HOME\bin\startComponent.cmd component_name
システム・コンポーネントは任意の順序で起動できます。
- Oracle HTTP Serverの起動
Enterprise Manager Fusion Middleware Controlを使用すると、Oracle HTTP Serverを起動、停止および再起動できます。
Oracle HTTP Serverの起動
Enterprise Manager Fusion Middleware Controlを使用すると、Oracle HTTP Serverを起動、停止および再起動できます。
親トピック: サーバーとプロセスの起動