| Oracle® Fusion Middleware Oracle Fusion Middleware Infrastructureへのアップグレード 12c (12.2.1.2) E82835-01 |
|
 前へ |
 次へ |
| Oracle® Fusion Middleware Oracle Fusion Middleware Infrastructureへのアップグレード 12c (12.2.1.2) E82835-01 |
|
|
前へ |
次へ |
以前の12cリリースから、Oracle Fusion Middleware Infrastructure 12c (12.2.1.2)にアップグレードできます。
アップグレードを実行するために、次に示す各トピックの手順を完了します。
setDomainEnvなど)へのカスタム構成設定の再適用が必要な場合があります。これらのスクリプトは、アップグレード時に新しい12cバージョンで上書きされます。前のリリースで作成したカスタム構成設定は手動で再適用する必要があります。Oracle Fusion Middleware Infrastructureのアップグレード・プロセス(以前の12cリリースから)の概要に関するフローチャートとロードマップを再確認します。
図4-1 Oracle Fusion Middleware Infrastructureのアップグレード・プロセス・フローチャート(以前の12cリリースから)
表4-1は、Oracle Fusion Middleware Infrastructureリリース12.2.1.2へのアップグレードの際に実行する必要のある手順の概要リストです。
表4-1 Oracle Fusion Middleware Infrastructureをアップグレードするためのタスク(以前の12cリリースから)
| タスク | 説明 |
|---|---|
省略可能 Oracle Fusion Middleware Infrastructure 12.2.1.2へのアップグレード方法に影響する可能性がある、相互運用性と互換性に関する要因について理解します。 |
サポートされるOracle Fusion Middleware構成で、同一バージョンまたは異なるバージョンの2つ以上のOracle Fusion Middleware製品の連携(相互運用)方法を理解することが重要です。 相互運用性と互換性の詳細は、『Oracle® Fusion Middleware相互運用性および互換性の理解』を参照してください。 |
必須 このガイドの概要に関するトピックを確認して、必須のアップグレード前タスクを完了します(まだ実行していない場合)。 |
アップグレード前タスクには、ご使用の本番環境のクローニング、システム要件および資格証明の確認、未使用データのパージおよび非SYSDBAユーザーの作成が含まれます。 アップグレード前タスクの完全なリストは、Oracle Fusion Middlewareアップグレード前チェックリストを参照してください。 |
必須 12.2.1.2 Fusion Middleware Infrastructureディストリビューションをダウンロードしてインストールします。 |
インフラストラクチャのディストリビューションには、その他のFusion Middleware製品をインストールするための基盤の設定に必要な、WebLogic ServerおよびJava Required Files (JRF)が同梱されています。 このガイドのアップグレード・トポロジに定義されているように、インフラストラクチャは新規のOracleホームにインストールする必要があります。そのために、「Oracle Fusion Middleware Infrastructureのインストール」で説明する手順を実行してください。 |
省略可能 準備状況チェックを実行します。 |
Upgrade Assistantを使用した準備状況チェックの実行は、アップグレード前の環境について、アップグレードの準備が整っているかどうかを判断する際に役立ちます。 完全な手順は、「アップグレード前の準備状況チェックの実行」を参照してください。 |
必須 サーバーとプロセスを停止します |
アップグレード・プロセスの開始前に、すべてのサーバー、コンポーネントおよびプロセスを停止します。 |
必須 Upgrade Assistantを使用して、スキーマをアップグレードします。 |
Upgrade Assistantでは、「ドメインで使用されるすべてのスキーマ」オプションを選択できます。このオプションを選択すると、Upgrade Assistantはドメイン内でアップグレードに利用可能なすべてのスキーマを自動的に選択します。 「製品スキーマのアップグレード」を参照してください。 |
必須 再構成ウィザードを使用して、12.2.1.xドメインを再構成します。 |
既存のドメインで再構成ウィザードを実行した場合、再構成テンプレートを選択および適用することで、ドメインのアップグレード準備が行われます。これにより、ドメイン内に存在するJDBCデータ・ソースとコンポーネント・スキーマのテストも実行します。 ドメインを再構成するには、「ドメインの再構成」で説明する手順を実行します。 |
必須 Upgrade Assistantを使用して、12.2.1.xドメインの構成をアップグレードします。 |
既存の12.2.1.xドメインの再構成後には、Upgrade Assistantを実行して、12.2.1.xドメインで使用される構成をすべてアップグレードする必要があります。 ドメイン内でアップグレードの対象になるすべてのコンポーネントは、Upgrade Assistantの実行時に、「コンポーネント・リスト」画面で確認できます。手順の詳細は、「ドメイン・コンポーネント構成のアップグレード」を参照してください。 |
必須 サーバーおよびプロセスを再起動します。 |
アップグレード・プロセスは完了です。この時点で、サーバー、コンポーネントおよびプロセスを再起動できます。 「サーバーとプロセスの起動」を参照してください。 |
必須 アップグレード後のタスクを実行します。 |
アップグレード後のタスクのリストは、「アップグレードの検証チェックリストの使用」を参照してください。 |
既存の環境がクラスタ構成の場合は必須 プライマリ・ノードの既存のドメインをパックします。 |
|
既存の環境がクラスタ構成の場合は必須 ドメインのtemplate.jarファイルをセカンダリ・ノードにコピーします。 |
|
既存の環境がクラスタ構成の場合は必須 セカンダリ・ノードにjarファイルを解凍します |
|
既存の環境がクラスタ構成の場合は必須 サーバーおよびプロセスを再起動します。 |
アップグレード・プロセスは完了です。この時点で、サーバー、コンポーネントおよびプロセスを再起動できます。 「サーバーとプロセスの起動」を参照してください。 |
Fusion Middleware Infrastructureをインストールすると、Oracleホーム・ディレクトリが作成され、その他のFusion Middleware製品をインストールするためのサポート・ソフトウェアが配置されます。
注意:
以前の12cリリース(12.1.3.0、12.2.1.0または12.2.1.1)からアップグレードする場合は、Oracleホームに12c (12.2.1.2)ディストリビューションをインストールする必要があります。このアップグレードには、既存のOracleホームを再使用しないでください。12c (12.2.1.2)へのアップグレードは、パッチ・リリースではありません。アップグレードにかかわる潜在的な問題を特定するために、準備状況チェックを実行してから、アップグレード・プロセスを開始するようにしてください。準備状況チェックによって、アップグレードにかかわる潜在的な問題をすべて検出できるわけではない点に注意してください。準備状況チェックのレポートが成功を示していても、アップグレードが失敗することもあります。
-readinessモードでUpgrade Assistantを実行すると、実際のアップグレードを実行する前に問題を検出できます。Upgrade Assistantを使用すると、準備状況チェックはGUIモードで実行できます。また、レスポンス・ファイルを使用するとサイレント・モードで実行できます。 -readinessパラメータを使用して、準備状況モードでUpgrade Assistantを起動します。-readinessモードでUpgrade Assistantを実行すると、実際のアップグレードを実行する前に問題を検出できます。Upgrade Assistantを使用すると、準備状況チェックはGUIモードで実行できます。また、レスポンス・ファイルを使用するとサイレント・モードで実行できます。
Upgrade Assistantの準備状況チェックは、サポート対象の開始ポイントにあるFusion MiddlewareのスキーマとWebLogicドメインの構成について、読取り専用のアップグレード前確認を実行します。この確認は、読取り専用の操作です。
準備状況チェックでは、フォーマットされ、タイムスタンプの付けられた準備状況レポートが生成され、実際のアップグレードを試みる前に潜在的な問題に対処できます。問題が検出されない場合は、アップグレード・プロセスを開始できます。アップグレードを実行する前に、このレポートを詳細に確認することをお薦めします。
準備状況チェックは、既存のOracle Fusion Middlewareドメインがオンライン(他のユーザーがアクティブに使用している間)であっても、オフラインであっても実行できます。
準備状況チェックは、実際のアップグレードの実行前に、何度でも実行できます。ただし、アップグレードの実行後には、準備状況チェックを実行しないでください。これは、レポートの結果が、アップグレード前の準備状況チェックとは異なることがあるためです。
注意:
パフォーマンスへの影響を回避するために、準備状況チェックはピーク時以外に実行してください。
-readinessパラメータを使用して、準備状況モードでUpgrade Assistantを起動します。
コマンドラインからUpgrade Assistantを起動するときには、追加のパラメータを指定できます。
表4-2 Upgrade Assistantのコマンドライン・パラメータ
| パラメータ | 必須/省略可能 | 説明 |
|---|---|---|
|
準備状況チェックの場合は必須 注意: 準備状況チェックは、スタンドアロンのインストール(WebLogic Serverで管理されていないインストール)に対して実行できません。 |
アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。 スキーマと構成がチェックされます。
|
|
省略可能 | スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須 |
レスポンス・ファイルに保存した入力を使用して、Upgrade Assistantを実行します。このレスポンス・ファイルは、GUIモードでUpgrade Assistantを実行したときの入力データから生成されます。このパラメータを使用すると、Upgrade Assistantはサイレント・モード (Upgrade Assistantの画面を表示しないモード)で実行されます。 |
|
省略可能 |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
省略可能 |
次のいずれかの属性を指定して、ログイン・レベルを設定します。
デフォルトのロギング・レベルは
|
|
省略可能 |
アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。既存の書込み可能なディレクトリを指定する必要があります。Upgrade Assistantは、このディレクトリにログ・ファイルと一時ファイルを作成します。 デフォルトの場所は次のとおりです。 (UNIX) (Windows) |
|
省略可能 |
すべてのコマンドライン・オプションを表示します。 |
Upgrade Assistantの各画面を通じて、アップグレード前の準備状況チェックを完了します。
目的のドメインに準備状況チェックを実行したら、アップグレードを成功させるために、なんらかの処置を取る必要があるかどうかを判断するためにレポートを確認します。
準備状況レポート・ファイルの形式は、次のとおりです。
readiness_timestamp.txt
timestampは、準備状況チェックが実行された日時を示します。
準備状況レポートには、次に示す情報が含まれています。
表4-3 準備状況レポートの要素
| レポートの情報 | 説明 | 必要な操作 |
|---|---|---|
| 全体的な準備状況ステータス: SUCCESSまたはFAILURE | レポートの上部には、アップグレードの準備状況チェックが成功したか、または1つ以上のエラーが発生して完了したかが示されます。 | 1つ以上のエラーが発生してレポートが完了した場合、アップグレードを試みる前に、FAILを検索し、障害の原因となった問題を修正します。準備状況チェックは、アップグレードする前に必要に応じて何度でも再実行できます。 |
タイムスタンプ |
レポートが生成された日付と時刻です。 |
処理は必要ありません。 |
ログ・ファイルの場所
|
生成されたログ・ファイルのディレクトリの場所です。 |
処理は必要ありません。 |
準備状況レポートの場所
|
生成された準備状況レポートのディレクトリの場所です。 |
処理は必要ありません。 |
チェックされたコンポーネントの名前 |
チェックに含まれるコンポーネントの名前およびバージョンとステータス。 |
このリリースにアップグレードできないコンポーネント(SOAコア拡張など)がドメインに含まれる場合は、アップグレードを試みないでください。 |
チェックされたスキーマの名前 |
チェックに含まれるスキーマの名前および現在のバージョンとステータス。 |
スキーマのバージョン番号をレビューします。このリリースにアップグレードできないスキーマがドメインに含まれる場合は、アップグレードを試みないでください。 |
個別のオブジェクトのテスト・ステータス: FAIL |
準備状況チェックのテストで、特定のオブジェクトに問題が検出されています。 |
失敗した問題がすべて解決するまでアップグレードしないでください。 |
個別のオブジェクトのテスト・ステータス: PASS |
準備状況チェックのテストでは、特定のオブジェクトに問題が検出されませんでした。 |
準備状況チェック・レポートにPASSステータスのみが表示されている場合、環境をアップグレードできます。ただし、準備状況チェックでは、ハードウェアやアップグレード時の接続性などの外部環境に関する問題を検出することはできません。アップグレードの進捗を常に監視する必要があります。 |
| <オブジェクト>の準備状況チェックの完了ステータス: FAILURE | 準備状況チェックで特定のオブジェクト(スキーマ、索引、データ型など)に解決する必要のあるエラーが1つ以上検出されました。 | FAILED問題がすべて解決されるまではアップグレードしないでください。 |
| <オブジェクト>の準備状況チェックの完了ステータス: SUCCESS | 準備状況チェック・テストによって問題が検出されませんでした。 | 処理は必要ありません。 |
Upgrade readiness check completed with one or more errors. This readiness check report was created on Tue May 30 11:15:52 EDT 2016 Log file is located at: 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.1.1.1.0. Readiness checks will now be performed. Starting schema test: TEST_REQUIRED_TABLES Test that the schema contains all the required tables Completed schema test: TEST_REQUIRED_TABLES --> Test that the schema contains all the required tables +++ PASS Starting schema test: TEST_REQUIRED_PROCEDURES Test that the schema contains all the required stored procedures EXCEPTION Schema is missing a required procedure: GETREPOSITORYFEATURES Completed schema test: TEST_REQUIRED_PROCEDURES --> Test that the schema contains all the required stored procedures +++ FAIL Starting schema test: TEST_REQUIRED_VIEWS Test that the schema contains all the required database views Completed schema test: TEST_REQUIRED_VIEWS --> Test that the schema contains all the required database views +++ PASS Starting index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes Completed index test for table MDS_ATTRIBUTES: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS Starting index test for table MDS_COMPONENTS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes Completed index test for table MDS_TXN_LOCKS: TEST_REQUIRED_INDEXES --> Test that the table contains all the required indexes +++ PASS Starting schema test: TEST_REQUIRED_TRIGGERS Test that the schema has all the required triggers Completed schema test: TEST_REQUIRED_TRIGGERS --> Test that the schema has all the required triggers +++ PASS Starting schema test: TEST_MISSING_COLUMNS Test that tables and views are not missing any required columns Completed schema test: TEST_MISSING_COLUMNS --> Test that tables and views are not missing any required columns +++ PASS Starting schema test: TEST_UNEXPECTED_TABLES Test that the schema does not contain any unexpected tables Completed schema test: TEST_UNEXPECTED_TABLES --> Test that the schema does not contain any unexpected tables +++ PASS Starting schema test: TEST_UNEXPECTED_PROCEDURES Test that the schema does not contain any unexpected stored procedures Completed schema test: TEST_UNEXPECTED_PROCEDURES --> Test that the schema does not contain any unexpected stored procedures +++ PASS Starting schema test: TEST_UNEXPECTED_VIEWS Test that the schema does not contain any unexpected views Completed schema test: TEST_UNEXPECTED_VIEWS --> Test that the schema does not contain any unexpected views +++ PASS Starting index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes Completed index test for table MDS_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS Completed index test for table MDS_LABELS: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes +++ PASS Starting index test for table MDS_LARGE_ATTRIBUTES: TEST_UNEXPECTED_INDEXES --> Test that the table does not contain any unexpected indexes Starting schema test: TEST_UNEXPECTED_TRIGGERS Test that the schema does not contain any unexpected triggers Completed schema test: TEST_UNEXPECTED_TRIGGERS --> Test that the schema does not contain any unexpected triggers +++ PASS Starting schema test: TEST_UNEXPECTED_COLUMNS Test that tables and views do not contain any unexpected columns Completed schema test: TEST_UNEXPECTED_COLUMNS --> Test that tables and views do not contain any unexpected columns +++ PASS Starting datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes Completed datatype test for table MDS_ATTRIBUTES: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes +++ PASS Starting datatype test for table MDS_COMPONENTS: TEST_COLUMN_DATATYPES_V2 --> Test that all table columns have the proper datatypes Starting permissions test: TEST_DBA_TABLE_GRANTS Test that DBA user has privilege to view all user tables Completed permissions test: TEST_DBA_TABLE_GRANTS --> Test that DBA user has privilege to view all user tables +++ PASS Starting schema test: TEST_ENOUGH_TABLESPACE Test that the schema tablespaces automatically extend if full Completed schema test: TEST_ENOUGH_TABLESPACE --> Test that the schema tablespaces automatically extend if full +++ PASS Starting schema test: TEST_USER_TABLESPACE_QUOTA Test that tablespace quota for this user is sufficient to perform the upgrade Completed schema test: TEST_USER_TABLESPACE_QUOTA --> Test that tablespace quota for this user is sufficient to perform the upgrade +++ PASS Starting schema test: TEST_ONLINE_TABLESPACE Test that schema tablespaces are online Completed schema test: TEST_ONLINE_TABLESPACE --> Test that schema tablespaces are online +++ PASS Starting schema test: TEST_DATABASE_VERSION Test that the database server version number is supported for upgrade INFO Database product version: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options Completed schema test: TEST_DATABASE_VERSION --> Test that the database server version number is supported for upgrade +++ PASS Finished readiness check of Oracle Metadata Services with status: FAILURE.
Oracle Fusion Middleware IAUスキーマの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で作成された場合は発生しません。Upgrade Assistantを実行する前に、すべてのOracle Fusion Middleware管理対象サーバー、管理サーバーおよび更新するスキーマまたは構成を使用している可能性があるシステム・コンポーネント(OHSなど)を停止します。これを行わないと、結果としてアップグレードが不完全になったり、障害が発生する場合があります。
ノード・マネージャを実行している場合は、ノード・マネージャも停止する必要があります。これを行うには、ノード・マネージャが実行されているコンソール・ウィンドウを閉じるか、stopNodeManager WLSTコマンドを使用します。
Oracle Fusion Middleware環境を停止する手順は、『Oracle Fusion Middleware Oracle Fusion Middlewareの管理』のOracle Fusion Middleware環境の停止に関する項を参照してください。
サーバーとプロセスの停止後、Upgrade Assistantを使用して、Oracle Fusion Middlewareの現在のリリースにあわせてサポート対象の製品スキーマをアップグレードします。
アップグレード・アシスタントを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるアップグレード・アシスタントの画面は異なります。
schema_version_registryのスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードの成功を検証します。Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade Assistantは非SYSDBAとして実行して、一度にアップグレードするドメインは1つにすることをお薦めします。
oracle_common/upgrade/binディレクトリに移動します。ORACLE_HOME/oracle_common/upgrade/binORACLE_HOME\oracle_common\upgrade\binコマンドラインに指定可能なその他のパラメータ(ロギングのパラメータなど)の詳細は、次を参照してください。
コマンドラインからUpgrade Assistantを起動するときには、追加のパラメータを指定できます。
表4-4 Upgrade Assistantのコマンドライン・パラメータ
| パラメータ | 必須/省略可能 | 説明 |
|---|---|---|
|
準備状況チェックの場合は必須 注意: 準備状況チェックは、スタンドアロンのインストール(WebLogic Serverで管理されていないインストール)に対して実行できません。 |
アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。 スキーマと構成がチェックされます。
|
|
省略可能 | スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須 |
レスポンス・ファイルに保存した入力を使用して、Upgrade Assistantを実行します。このレスポンス・ファイルは、GUIモードでUpgrade Assistantを実行したときの入力データから生成されます。このパラメータを使用すると、Upgrade Assistantはサイレント・モード (Upgrade Assistantの画面を表示しないモード)で実行されます。 |
|
省略可能 |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
省略可能 |
次のいずれかの属性を指定して、ログイン・レベルを設定します。
デフォルトのロギング・レベルは
|
|
省略可能 |
アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。既存の書込み可能なディレクトリを指定する必要があります。Upgrade Assistantは、このディレクトリにログ・ファイルと一時ファイルを作成します。 デフォルトの場所は次のとおりです。 (UNIX) (Windows) |
|
省略可能 |
すべてのコマンドライン・オプションを表示します。 |
Upgrade Assistantの各画面を通じて、製品スキーマをアップグレードします。
すべてのアップグレード手順を完了したら、schema_version_registryのスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードの成功を検証します。
Oracle Databaseを使用する場合、Oracle DBAを持つユーザーとしてデータベースに接続し、SQL*Plusから次を実行して現行のバージョン番号を取得します。
SET LINE 120 COLUMN MRC_NAME FORMAT A14 COLUMN COMP_ID FORMAT A20 COLUMN VERSION FORMAT A12 COLUMN STATUS FORMAT A9 COLUMN UPGRADED FORMAT A8 SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;
問合せ結果について:
VERSION列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。たとえば、スキーマ・バージョン番号が12.2.1.2.0になっていることを確認します。ただし、すべてのスキーマ・バージョンが更新されるわけではない点に注意してください。一部のスキーマは、このリリースにあわせたアップグレードの必要がなく、アップグレード前のバージョン番号を維持します。
STATUSフィールドは、スキーマのパッチ適用操作中はUPGRADINGまたはUPGRADEDのどちらかになり、パッチ適用操作が完了するとVALIDになります。
ステータスが「INVALID」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。
IAU_APPENDとIAU_VIEWERが所有するシノニム・オブジェクトは、INVALIDと表示されますが、失敗を意味するものではありません。
これらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトは、アクセスされるときに有効になります。これに該当するINVALIDオブジェクトは、無視しても問題ありません。
再構成ウィザードを実行して、ドメイン・コンポーネント構成を12c (12.2.1.2)にあわせて再構成します。
WebLogic Serverドメインを再構成すると、ドメイン内のアプリケーションに応じて、次の項目が自動的に更新されます。
WebLogic Serverコア・インフラストラクチャ
ドメイン・バージョン
注意:
ドメインの再構成を開始する前に、次の制限事項に注意してください。
再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。
アップグレード・プロセス中に、非動的クラスタ・ドメインを動的クラスタ・ドメインに変換することはサポートされていません。
動的クラスタ機能は、再構成ウィザードの実行中に使用できますが、サポートされているアップグレードは非動的クラスタのアップグレードのみで、その後で動的クラスタを追加することになります。アップグレード・プロセス中に動的クラスタを追加することはできません。
ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。
すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。
起動スクリプトが更新されます。
変更済の起動スクリプトを維持する場合は、そのスクリプトをバックアップしてから、再構成ウィザードを開始してください。
注意:
ドメインの再構成プロセスを開始すると、元に戻すことはできません。再構成ウィザードの実行前には、アップグレード前チェックリストで説明しているように、ドメインのバックアップが作成されていることを確認してください。再構成ウィザードの実行中にエラーまたは他の割込みが発生した場合、バックアップ場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーすることによって、ドメインをリストアする必要があります。これは、ドメインを再構成前の元の状態に戻せるようにする唯一の方法です。再構成ウィザードの実行前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。
ドメイン・ディレクトリのバックアップを作成するには:
再構成ウィザードは、ドメインの場所を保持したままドメインを再構成します。再構成ウィザードの各画面を通じて、既存のドメインを再構成します。
重要
ソースがクラスタ化環境の場合、プライマリ・ノードでのみ再構成ウィザードを実行します。変更をドメイン内の他のクラスタ・メンバーに適用するには、既存の環境がクラスタ化構成の場合の説明に従って、パック/アンパック・ユーティリティを使用します。ドメインの再構成後、更新したドメイン構成と一致するように、ドメイン内でUpgrade Assistantを使用してドメイン・コンポーネント構成をアップグレードします。
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.2)にアップグレードします。Upgrade Assistantは非SYSDBAとして実行して、一度にアップグレードするドメインは1つにすることをお薦めします。
oracle_common/upgrade/binディレクトリに移動します。ORACLE_HOME/oracle_common/upgrade/binORACLE_HOME\oracle_common\upgrade\binコマンドラインに指定可能なその他のパラメータ(ロギングのパラメータなど)の詳細は、次を参照してください。
コマンドラインからUpgrade Assistantを起動するときには、追加のパラメータを指定できます。
表4-6 Upgrade Assistantのコマンドライン・パラメータ
| パラメータ | 必須/省略可能 | 説明 |
|---|---|---|
|
準備状況チェックの場合は必須 注意: 準備状況チェックは、スタンドアロンのインストール(WebLogic Serverで管理されていないインストール)に対して実行できません。 |
アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。 スキーマと構成がチェックされます。
|
|
省略可能 | スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須 |
レスポンス・ファイルに保存した入力を使用して、Upgrade Assistantを実行します。このレスポンス・ファイルは、GUIモードでUpgrade Assistantを実行したときの入力データから生成されます。このパラメータを使用すると、Upgrade Assistantはサイレント・モード (Upgrade Assistantの画面を表示しないモード)で実行されます。 |
|
省略可能 |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
省略可能 |
次のいずれかの属性を指定して、ログイン・レベルを設定します。
デフォルトのロギング・レベルは
|
|
省略可能 |
アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。既存の書込み可能なディレクトリを指定する必要があります。Upgrade Assistantは、このディレクトリにログ・ファイルと一時ファイルを作成します。 デフォルトの場所は次のとおりです。 (UNIX) (Windows) |
|
省略可能 |
すべてのコマンドライン・オプションを表示します。 |
Upgrade Assistantの各画面を移動して、WebLogicドメインのコンポーネント構成をアップグレードします。
再構成ウィザードを実行して、WebLogicドメインを12c (12.2.1.2)にあわせて再構成したら、Upgrade Assistantを実行してドメイン・コンポーネント構成を更新後のドメイン構成と一致するようにアップグレードする必要があります。
ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびFusion Middleware Controlにログインし、各コンポーネントのバージョン番号が12.2.1.2になっていることを確認します。
管理コンソールにログインするには、次に移動します: http://administration_server_host:administration_server_port/console
Fusion Middleware Controlにログインするには、次に移動します: http://administration_server_host:administration_server_port/em
注意:
アップグレード後、管理ツールは、前のOracleホームではなく新しい12cのOracleホームから必ず実行してください。
アップグレード・プロセス時に、一部のOWSMドキュメント(ポリシー・セット、ポリシーおよびアサーション・テンプレートなどの事前定義ドキュメント)のアップグレードが必要な場合があります。ポリシー・セットまたは事前定義ドキュメントがアップグレードされると、バージョン番号が1増分されます。
アップグレードが成功したら、管理サーバーと管理対象サーバーを含め、すべてのプロセスとサーバーを再起動します。
コンポーネントは相互に依存していることがあるため、適切な順序で起動する必要があります。
注意:
この項の手順では、WLSTコマンドラインまたはスクリプトを使用してサーバーとプロセスを起動する方法について説明します。また、Oracle Fusion Middleware ControlとOracle WebLogic Server管理コンソールを使用することもできます。『Oracle Fusion Middlewareの管理』の管理サーバーと管理対象サーバーおよびノード・マネージャの起動と停止に関する項を参照してください。Fusion Middleware環境を起動するには、次に示す手順を実行します。
ステップ1: 管理サーバーの起動
管理サーバーを起動するときに、管理サーバーで稼働するプロセス(WebLogic Server管理コンソールやFusion Middleware Controlなど)も起動します。
管理サーバーを起動するには、startWebLogicスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/startWebLogic.sh
(Windows) DOMAIN_HOME\bin\startWebLogic.cmd
プロンプトが表示されたら、管理サーバーのユーザー名とパスワード、およびURLを入力します。
ステップ2: ノード・マネージャを起動する
ノード・マネージャを起動するには、startNodeManagerスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/startNodeManager.sh
(Windows) DOMAIN_HOME\bin\startNodeManager.cmd
ステップ3: Oracle Identity Managementのコンポーネントを起動する
目的の環境に含まれるOracle Identity Managementのコンポーネント(Oracle Internet Directoryなど)を起動します。(UNIX) DOMAIN_HOME/bin/startComponent.sh component_name
(Windows) DOMAIN_HOME\bin\startComponent.cmd component_name
ステップ4: 管理対象サーバーを起動する
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
プロンプトが表示されたらユーザー名とパスワードを入力します。
注意:
通常、管理対象サーバーを起動すると、そのサーバーにデプロイされているアプリケーションが開始されます。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。ステップ5: システム・コンポーネントを起動する
Oracle HTTP Serverなどのシステム・コンポーネントを起動するには、startComponentスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/startComponent.sh component_name
(Windows) DOMAIN_HOME\bin\startComponent.cmd component_name
システム・コンポーネントは任意の順序で起動できます。
アップグレード後には、基本的な管理タスク(ノード・マネージャ、管理サーバー、Web層、管理コンソールおよびEnterprise Manager Fusion Middleware Controlを起動できるかどうかの確認など)が正常に完了できることを確認してください。
注意:
次のサーバーを起動する順序は重要です。それらを正しい順序で起動(停止)しないと、デプロイメントに関する問題が発生する可能性があるからです。
詳細は、「サーバーの正しい順序での起動と停止」を参照してください。
アプリケーション環境の12cへのアップグレードを完了するには、起動スクリプト(setDomainEnvなど)へのカスタム構成設定の再適用が必要な場合があります。これらのスクリプトは、アップグレード時に新しい12cバージョンで上書きされます。前のリリースで作成したカスタム構成設定は手動で再適用する必要があります。
詳細は、起動スクリプトへのカスタマイズの再適用を参照してください。
注意:
今後のアップグレードでカスタム構成設定が失われないようにするには、「カスタムsetDomainEnv設定のメンテナンス」を参照してください。
12cにおいて、Java EE Webサービスおよびクライアントに対するグローバル・ポリシー・アタッチメントのサポートを導入すると、既存のJava EE Webサービスおよびクライアント(12.1.2およびそれ以前)の後方互換性に影響する場合があります。ポリシーの不在に依存しているJava EE Webサービスまたはクライアント・エンドポイントが、グローバル・ポリシー・アタッチメントのスコープに含まれる場合、グローバル・ポリシー・アタッチメントの存在によって、そのエンドポイントのセキュリティ動作が変更される場合があります。
注意:
Fusion Middleware 12.1.2およびそれ以前では、SOAP WebサービスおよびSOAP Webサービス・クライアントのサブジェクト・タイプのために定義されたグローバル・ポリシー・アタッチメントは、Oracle Infrastructure Webサービスおよびクライアントにのみ適用可能であり、Java EE Webサービスおよびクライアントからは無視されていました。12c (12.2.1)へのアップグレード後は、これらのサブジェクト・タイプのために定義されたグローバル・ポリシー・アタッチメントは、Java EE Webサービスおよびクライアントにも適用され、既存のJava EE Webサービスおよびクライアントのセキュリティ動作に影響を与える場合があります。
後方互換性を維持するには、特定のサービスまたはクライアントにOWSM動作無効ポリシー(no_authentication_service_policy、no_authorization_service_policyまたはno_messageprotection_service_policyなど)をアタッチすることにより、それらのエンドポイントへのグローバル・ポリシー・アタッチメントを無効化できます。詳細は、『Oracle Fusion Middleware Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のグローバルにアタッチされたポリシーの無効化に関する項を参照してください。
注意:
WebLogic Wssp1.5-No-Op.xml動作無効ポリシーを使用できます。ただし、WebLogicセキュリティ・ポリシーは、プログラムでのみWebサービス・クライアントにアタッチできるため、コードの変更が必要です。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server WebLogic Webサービスの保護』のグローバルにアタッチされたポリシーの無効化に関する項を参照してください
このトピックでは、Infrastructure 12cへのアップグレード後に実行することが多い一般的な管理タスクおよび関連するドキュメント・リソースのリストを示しています。
表5-1に、Infrastructure 12cへのアップグレード後に実行する可能性の高い一般的な管理タスクを示します。
表4-7 基本的な管理タスク
| タスク | 説明 | 参照先 |
|---|---|---|
Fusion Middleware管理ツールについての学習 |
環境の管理に使用できる各種ツールについて習熟します。 |
Oracle Fusion Middlewareの管理のOracle Fusion Middleware管理ツールの概要。 |
製品およびサーバーの起動と停止 |
Oracle Fusion Middleware(管理サーバー、管理対象サーバー、コンポーネントを含む)起動と停止の方法について学習します。 |
Oracle Fusion Middlewareの管理のOracle Fusion Middlewareの起動と停止。 |
Secure Sockets Layer (SSL)の構成 |
Oracle Fusion Middlewareコンポーネント間で、SSLを使用したセキュアな通信を設定する方法について学習します。 |
Oracle Fusion Middlewareの管理のOracle Fusion MiddlewareでのSSLの構成。 |
Oracle Fusion Middlewareのモニタリング |
Oracle Fusion Middlewareコンポーネントのステータスを追跡する方法を学習します。 |
Oracle Fusion Middlewareの管理のOracle Fusion Middlewareの監視。 |
バックアップとリカバリの手順の理解 |
Oracle Fusion Middlewareのバックアップとリカバリの推奨手順について学習します。 |
Oracle Fusion Middlewareの管理のバックアップとリカバリの概要。 |
既存の環境がクラスタ構成の場合、パック・ユーティリティおよびアンパック・ユーティリティを使用してそのドメイン内の他のクラスタ・メンバーに変更を適用する必要があります。
アップグレードが成功したら、管理サーバーと管理対象サーバーを含め、すべてのプロセスとサーバーを再起動します。
コンポーネントは相互に依存していることがあるため、適切な順序で起動する必要があります。
注意:
この項の手順では、WLSTコマンドラインまたはスクリプトを使用してサーバーとプロセスを起動する方法について説明します。また、Oracle Fusion Middleware ControlとOracle WebLogic Server管理コンソールを使用することもできます。『Oracle Fusion Middlewareの管理』の管理サーバーと管理対象サーバーおよびノード・マネージャの起動と停止に関する項を参照してください。Fusion Middleware環境を起動するには、次に示す手順を実行します。
ステップ1: 管理サーバーの起動
管理サーバーを起動するときに、管理サーバーで稼働するプロセス(WebLogic Server管理コンソールやFusion Middleware Controlなど)も起動します。
管理サーバーを起動するには、startWebLogicスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/startWebLogic.sh
(Windows) DOMAIN_HOME\bin\startWebLogic.cmd
プロンプトが表示されたら、管理サーバーのユーザー名とパスワード、およびURLを入力します。
ステップ2: ノード・マネージャを起動する
ノード・マネージャを起動するには、startNodeManagerスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/startNodeManager.sh
(Windows) DOMAIN_HOME\bin\startNodeManager.cmd
ステップ3: Oracle Identity Managementのコンポーネントを起動する
目的の環境に含まれるOracle Identity Managementのコンポーネント(Oracle Internet Directoryなど)を起動します。(UNIX) DOMAIN_HOME/bin/startComponent.sh component_name
(Windows) DOMAIN_HOME\bin\startComponent.cmd component_name
ステップ4: 管理対象サーバーを起動する
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
プロンプトが表示されたらユーザー名とパスワードを入力します。
注意:
通常、管理対象サーバーを起動すると、そのサーバーにデプロイされているアプリケーションが開始されます。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。ステップ5: システム・コンポーネントを起動する
Oracle HTTP Serverなどのシステム・コンポーネントを起動するには、startComponentスクリプトを使用します。
(UNIX) DOMAIN_HOME/bin/startComponent.sh component_name
(Windows) DOMAIN_HOME\bin\startComponent.cmd component_name
システム・コンポーネントは任意の順序で起動できます。
