7 WebCenter Portalのアップグレード
この手順を使用して、WebCenter Portalを12c (12.2.1.4.0)から14c (14.1.2.0.0)にアップグレードします。
次の各項のステップに従って、アップグレードを実行します。
完全なバックアップの作成
アップグレードを開始する前に、Oracle Fusion Middlewareスキーマをホストするすべてのデータベースを含め、システムに重要なファイルをすべてバックアップします。
バックアップには、SCHEMA_VERSION_REGISTRY
表を含める必要があります。これにより、アップグレードが失敗したときに、コンテンツをアップグレード前の状態にリストアできるようになります。
実際のアップグレードを続行する前に、アップグレード・アシスタントの「前提条件」画面で、バックアップが実行されていることを確認するよう要求されます。ただし、アップグレード・アシスタントではバックアップが作成されていることが確認されない点に注意してください。
-
Oracle Fusion Middlewareの管理の環境のバックアップ
-
Oracle Fusion Middlewareのアップグレードのプランニングの14c (14.1.2.0.0)のためのOracleデータベースのアップグレードおよび準備
製品ディストリビューションのインストール
アップグレードを開始する前に、14c (14.1.2.0.0)のOracle Fusion Middleware InfrastructureおよびOracle WebCenter Portalのディストリビューションをターゲット・システムにダウンロードし、Oracle Universal Installerを使用してインストールします。
ノート:
アップグレードにInfrastructureが必要な場合は、その他のFusion Middleware製品をインストールする前に、まずOracle Fusion Middleware Infrastructureディストリビューションをインストールする必要があります。ご使用のJDKがサポートされていない場合、またはJDKをインストールしていない場合は、開始前に必要なJava SE JDKをダウンロードする必要がありますOracle HTTP Serverなど、ドメインを構成するすべてのOracle製品をダウンロードおよびインストールしたことを確認します。14.1.2.0.0バイナリは、新規のOracleホームにインストールする必要があります。既存のOracleホームと同じホスト上である必要があります。
ノート:
製品ディストリビューションをインストールしたら、適用可能なバンドル・パッチを適用する必要があります。必要なすべてのパッチが同じOracleホームに適用されるように、OracleホームにWebCenter ContentとWebCenter Portalの両方のバイナリが含まれていることを確認してください。アップグレード前の準備状況チェックの実行
アップグレードにかかわる潜在的な問題を特定するために、アップグレード・プロセスの開始前に、準備状況チェックの実行をお薦めします。準備状況チェックでは、アップグレードの潜在的な問題をすべて発見できるわけではないことに注意してください。準備状況チェック・レポートが成功しても、アップグレードが失敗する場合があります。
アップグレード前の準備状況チェックの実行について
アップグレード・アシスタントを-readiness
モードで実行することにより、実際にアップグレードを実行する前に問題を検出できます。準備状況チェックは、アップグレード・アシスタントを使用してGUIモードで実行するか、またはレスポンス・ファイルを使用してサイレント・モードで実行できます。
Upgrade Assistantの準備状況チェックは、サポート対象の開始ポイントにあるFusion MiddlewareのスキーマとWebLogicドメインの構成について、読取り専用のアップグレード前確認を実行します。この確認は、読取り専用の操作です。
準備状況チェックでは、フォーマットされ、タイムスタンプの付けられた準備状況レポートが生成され、実際のアップグレードを試みる前に潜在的な問題に対処できます。問題が検出されない場合は、アップグレード・プロセスを開始できます。アップグレードを実行する前に、このレポートを詳細に確認することをお薦めします。
準備状況チェックは、既存のOracle Fusion Middlewareドメインがオンライン(他のユーザーがアクティブに使用している間)またはオフラインである間に実行できます。
準備状況チェックは、実際のアップグレードの実行前に、何度でも実行できます。ただし、アップグレードの実行後には、準備状況チェックを実行しないでください。これは、レポート結果が、アップグレード前の準備状況チェックと異なることがあるためです。
ノート:
パフォーマンスが影響されることを回避するために、オフピーク時に準備状況チェックを実行することをお薦めします。
準備状況モードでのUpgrade Assistantの起動
-readiness
パラメータを使用して、アップグレード・アシスタントを準備状況モードで起動します。
アップグレード・アシスタントのパラメータ
コマンドラインからアップグレード・アシスタントを起動するときに、追加のパラメータを指定できます。
表7-1 アップグレード・アシスタントのコマンドライン・パラメータ
パラメータ | 必須またはオプション | 説明 |
---|---|---|
|
準備状況チェックの場合は必須
ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。 |
アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。 スキーマと構成がチェックされます。
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須 |
アップグレード・アシスタントがGUIモードで実行されているときに入力したデータから生成されるレスポンス・ファイルに保存されている入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。 |
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
オプション |
次のいずれかの属性を指定して、ログイン・レベルを設定します。
デフォルトのロギング・レベルは
|
|
オプション |
アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 (UNIX)
(Windows)
|
|
オプション |
すべてのコマンドライン・オプションを表示します。 |
アップグレード・アシスタントを使用した準備状況チェックの実行
Upgrade Assistantの各画面を通じて、アップグレード前の準備状況チェックを完了します。
準備状況レポートの理解
ドメインの準備状況チェックを実行した後、レポートを確認してアップグレードを成功させるためのアクションをとる必要があるかどうかを判断します。
準備状況レポート・ファイルの形式は、次のとおりです。
readiness<timestamp>.txt
ここで、timestamp
は、準備状況チェックが実行された日付と時刻を示します。
準備状況レポートには、次の情報が含まれています。
表7-2 準備状況レポートの要素
レポートの情報 | 説明 | 必要なアクション |
---|---|---|
全体的な準備状況ステータス: SUCCESSまたはFAILURE | レポートの上部に、準備状況チェックが合格したか1つ以上のエラーで完了したかが示されます。 | 1つ以上のエラーが発生してレポートが完了した場合、アップグレードを試みる前に、FAILを検索し、障害の原因となった問題を修正します。準備状況チェックは、アップグレードする前に必要に応じて何度でも再実行できます。 |
タイムスタンプ |
レポートが生成された日付と時刻です。 |
必要なアクションはありません。 |
ログ・ファイルの場所
|
生成されたログ・ファイルのディレクトリの場所です。 |
必要なアクションはありません。 |
ドメイン・ディレクトリ | ドメインの場所が表示されます | 必要なアクションはありません。 |
準備状況レポートの場所
|
生成された準備状況レポートのディレクトリの場所です。 |
必要なアクションはありません。 |
チェックされたコンポーネントの名前 |
チェックに含まれるコンポーネントの名前およびバージョンとステータス。 |
ドメインに、このリリースにアップグレードできないSOAコア拡張機能などのコンポーネントが含まれる場合は、アップグレードを試行しないでください。 |
チェックされたスキーマの名前 |
チェックに含まれるスキーマの名前および現在のバージョンとステータス。 |
スキーマのバージョン番号をレビューします。ドメインに、このリリースにアップグレードできないスキーマが含まれる場合は、アップグレードを試行しないでください。 |
個別のオブジェクトのテスト・ステータス: FAIL |
準備状況チェックのテストで、特定のオブジェクトに問題が検出されています。 |
失敗した問題がすべて解決されるまではアップグレードしないでください。 |
個別のオブジェクトのテスト・ステータス: PASS |
準備状況チェックのテストでは、特定のオブジェクトに問題が検出されませんでした。 |
準備状況チェック・レポートに「成功」ステータスのみが表示されている場合は、環境をアップグレードできます。ただし、準備状況チェックでは、ハードウェアやアップグレード時の接続性などの外部環境に関する問題を検出することはできません。アップグレードの進捗を常に監視する必要があります。 |
<オブジェクト>の準備状況チェックの完了ステータス: FAILURE | 準備状況チェックで、スキーマ、索引またはデータ型などの特定のオブジェクトに対して解決する必要がある1つ以上のエラーが検出されました。 | 失敗した問題がすべて解決されるまではアップグレードしないでください。 |
<オブジェクト>の準備状況チェックの完了ステータス: SUCCESS | 準備状況チェック・テストによって問題が検出されませんでした。 | 必要なアクションはありません。 |
サーバーとプロセスの停止
Upgrade Assistantを実行してスキーマと構成をアップグレードする前に、管理サーバーおよび管理対象サーバーを含むすべてのアップグレード前のプロセスとサーバーを停止する必要があります。
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リモート・コンソールを参照してください。
ノート:
次のサーバーを正しい順序で停止することが重要です。
ステップ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: 管理サーバーを停止する
管理サーバーを停止するには、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に関する項を参照してください。
製品スキーマのアップグレード
サーバーとプロセスの停止後、Upgrade Assistantを使用して、12.2.1.4.0スキーマをOracle Fusion Middlewareの14c (14.1.2.0.0)リリースにアップグレードします。
ノート:
ドメインにWLSSchemaDataSource
データ・ソースがある場合は、どのデータベース・ユーザーがそれに割り当てられているかを確認する必要があります。<PREFIX>_WLS_RUNTIME
が割り当てられている場合は、それを<PREFIX>_WLS
に変更する必要があります。詳細は、「WLSSchemaDataSourceデータ・ソースのデータベース・ユーザーの確認」を参照してください。
ノート:
-
14c (14.1.2.0.0)より前に作成された、エディションが無効になっているスキーマを、14c (14.1.2.0.0)にアップグレードすると、エディションが有効になります。
-
14c (14.1.2.0.0)で作成されたスキーマは、エディションが有効になった状態で作成されます。
アップグレード・アシスタントを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるアップグレード・アシスタントの画面は異なります。
アップグレードで使用可能な既存のスキーマの識別
アップグレード前にこのオプションのステップを使用して、スキーマ・バージョン・レジストリ表を問い合せることができます。この表には、スキーマ所有者、バージョン番号、コンポーネント名とID、作成日と変更日、カスタム接頭辞などのスキーマ情報が含まれています。
アップグレード・アシスタントでは、ドメイン内のすべてのスキーマをアップグレードすることも、アップグレードするスキーマを個々に選択することもできます。いずれかの方法を選択するために、次のステップに従って、アップグレードに使用可能なすべてのスキーマのリストを確認します。
-
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 WHERE OWNER LIKE UPPER('<PREFIX>_%');
-
生成されたレポートを確認します。
ノート:
-
アップグレード後、レポートを再度生成して、更新されたバージョンのスキーマを表示できます。アップグレードの必要がないスキーマがある場合は、そのスキーマのアップグレード前のバージョンが
schema_version_registry
表に維持されます。 -
既存のスキーマが、サポートされているバージョンからのものでない場合、14c (14.1.2.0.0)のアップグレード手順を使用する前に、それらをサポートされているバージョンにアップグレードする必要があります。詳細は、アップグレード前のバージョンのドキュメントを参照してください。
-
以前のバージョンでOIDベースのポリシー・ストアを使用していた場合、アップグレードを実行する前に新しいOPSSスキーマを必ず作成します。アップグレード後も、OPSSスキーマはLDAPベース・ストアのままです。
-
Oracle Fusion Middlewareリリース14c (14.1.2.0.0)でアップグレード可能な製品のスキーマのみをアップグレードできます。まだ14c (14.1.2.0.0)へのアップグレードが可能になっていないコンポーネントを含むドメインをアップグレードしないでください。
アップグレード・アシスタントの起動
Upgrade Assistantを実行して、製品のスキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを14c (14.1.2.0.0)にアップグレードします。
ノート:
Upgrade Assistantを起動する前に、Upgrade Assistantが稼働している環境に対して、JVM文字エンコードがUTF-8に設定されていることを確認します。文字エンコードがUTF-8に設定されていない場合、それらの名前にUnicode文字が含まれているファイルをダウンロードすることはできません。これによってアップグレードが失敗することがあります。文字エンコーディングを設定するには、次を実行します。
UNIXオペレーティング・システムの場合:
export UA_PROPERTIES="-Dfile.encoding=UTF-8 ${UA_PROPERTIES}"
Windowsオペレーティング・システムの場合:
set UA_PROPERTIES=-Dfile.encoding=UTF-8 %UA_PROPERTIES%
oracle_common/upgrade/bin
ディレクトリに移動します。- (UNIX)
ORACLE_HOME/oracle_common/upgrade/bin
- (Windows)
ORACLE_HOME\oracle_common\upgrade\bin
- (UNIX)
- Upgrade Assistantを起動します。
- (UNIX) ./ua
- (Windows) ua.bat
コマンドラインに指定可能なその他のパラメータ(ロギングのパラメータなど)の詳細は、次を参照してください。
アップグレード・アシスタントのパラメータ
コマンドラインからアップグレード・アシスタントを起動するときに、追加のパラメータを指定できます。
表7-3 アップグレード・アシスタントのコマンドライン・パラメータ
パラメータ | 必須またはオプション | 説明 |
---|---|---|
|
準備状況チェックの場合は必須
ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。 |
アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。 スキーマと構成がチェックされます。
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須 |
アップグレード・アシスタントがGUIモードで実行されているときに入力したデータから生成されるレスポンス・ファイルに保存されている入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。 |
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
オプション |
次のいずれかの属性を指定して、ログイン・レベルを設定します。
デフォルトのロギング・レベルは
|
|
オプション |
アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 (UNIX)
(Windows)
|
|
オプション |
すべてのコマンドライン・オプションを表示します。 |
アップグレード・アシスタントを使用したOracle WebCenterスキーマのアップグレード
Upgrade Assistantの各画面を通じて、製品スキーマをアップグレードします。
スキーマのアップグレードの確認
すべてのアップグレード・ステップを完了したら、schema_version_registry
のスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードの成功を検証します。
Oracle Databaseを使用する場合、Oracle DBAを持つユーザーとしてデータベースに接続し、SQL*Plusから次を実行して現行のバージョン番号を取得します。必ず<PREFIX>をスキーマ接頭辞に置き換えてください。
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, EDITION NAME, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY where owner like '<PREFIX>_%';
問合せ結果について:
EDITION NAME
列がORA$BASE
として表示されることを確認します。-
VERSION
列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。たとえば、スキーマ・バージョン番号が14.1.2.0.0になっていることを確認します。ノート:
すべてのスキーマ・バージョンが更新されるわけではありません。一部のスキーマではこのリリースへのアップグレードが必要なく、アップグレード前のバージョン番号が保持されます。
-
STATUS
フィールドは、スキーマのパッチ適用操作中はUPGRADING
またはUPGRADED
のどちらかになり、パッチ適用操作が完了するとVALID
になります。 -
ステータスが
「INVALID」
と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。 -
IAU_APPEND
とIAU_VIEWER
が所有するシノニム・オブジェクトは、INVALID
と表示されますが、失敗を意味するものではありません。これらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトは、アクセスされるときに有効になります。これに該当する
INVALID
オブジェクトは、無視しても問題ありません。
ドメインの再構成について
再構成ウィザードを実行して、ドメイン・コンポーネント構成を14c (14.1.2.0.0)に再構成します。
ノート:
ソースがクラスタ化環境の場合、プライマリ・ノードでのみ再構成ウィザードを実行します。
WebLogic Serverドメインを再構成すると、ドメイン内のアプリケーションに応じて、次の項目が自動的に更新されます。
-
WebLogic Serverコア・インフラストラクチャ
-
ドメイン・バージョン
ノート:
ドメインの再構成を開始する前に、次の制限事項に注意してください。
-
再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。
-
アップグレード・プロセス中に、非動的クラスタ・ドメインを動的クラスタ・ドメインに変換することはサポートされていません。
動的クラスタ機能は、再構成ウィザードの実行中に使用できますが、サポートされているアップグレードは非動的クラスタのアップグレードのみで、その後で動的クラスタを追加することになります。アップグレード・プロセス中に動的クラスタを追加することはできません。
-
アップグレードするインストールでOracle Access Management (OAM)が使用されない場合は、2つのファイルを編集して、再構成ウィザードが、存在しないOAMインフラストラクチャ・スキーマの更新(アップグレードが失敗する)を試みないようにする必要があります。
$DOMAIN/init-info/domain-info.xml
に次の例のような行をコメント・アウトします。<!--extention-template-ref name="Oracle Identity Navigator" version="14.1.2.0.0" location="/u01/app/oracle/product/fmw/iam111130/common/templates/applications/yourcomany.oinav_14.1.2.0.0_template.jar" symbol=""/--> <!--install-comp-ref name="oracle.idm.oinav" version="14.1.2.0.0" symbol="yourcompany.idm.oinav_14.1.2.0.0_iam141200_ORACLE_HOME" product_home="/u01/app/oracle/product/fmw/iam141200"/-->
また、同様に、
$DOMAIN/config/config.xml
に次の例のような行をコメント・アウトします。<!--app-deployment> <name>oinav#14.1.2.0.0</name> <target>AdminServer</target> <module-type>ear</module-type> <source-path>/u01/app/oracle/product/fmw/iam141200/oinav/modules/oinav.ear_14.1.2.0.0/oinav.ear</source-path> <deployment-order>500</deployment-order> <security-dd-model>DDOnly</security-dd-model> <staging-mode>nostage</staging-mode> </app-deployment-->
-
ドメインの
config.xml
ファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンに更新されます。 -
すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。
-
起動スクリプトが更新されます。
変更済の起動スクリプトを維持する場合は、そのスクリプトをバックアップしてから、再構成ウィザードを開始してください。
ノート:
ドメインの再構成プロセスを開始すると、それによって行われた変更を元に戻すことはできません。再構成ウィザードを実行する前に、アップグレード前のチェックリストに示されているようにドメインのバックアップを作成したことを確認します。再構成ウィザードの実行中にエラーまたは他の割込みが発生した場合、バックアップ場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーすることによって、ドメインをリストアする必要があります。これは、再構成前にドメインを確実に元の状態に戻す唯一の方法です。ドメインのバックアップ
再構成ウィザードの実行前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。
- ドメイン・ディレクトリのバックアップを作成します。
- 各リモート管理対象サーバーのドメインを更新する前に、各リモート・マシンのドメイン・ディレクトリのバックアップ・コピーを作成します。
- ドメインのバックアップしたバージョンが完全であることを確認します。
再構成ウィザードの起動
ノート:
再構成プロセスを開始する前に、管理サーバーおよびすべてのコロケート管理対象サーバーを停止します。「サーバーとプロセスの停止」を参照再構成ウィザードをグラフィカル・モードで起動するには:
ドメイン・コンポーネント構成のアップグレード
ドメインを再構成した後、Upgrade Assistantを使用して、更新したドメイン構成と一致するようドメイン内のドメイン・コンポーネント構成をアップグレードします。
アップグレード・アシスタントの起動
Upgrade Assistantを実行して、製品のスキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを14c (14.1.2.0.0)にアップグレードします。
ノート:
Upgrade Assistantを起動する前に、Upgrade Assistantが稼働している環境に対して、JVM文字エンコードがUTF-8に設定されていることを確認します。文字エンコードがUTF-8に設定されていない場合、それらの名前にUnicode文字が含まれているファイルをダウンロードすることはできません。これによってアップグレードが失敗することがあります。文字エンコーディングを設定するには、次を実行します。
UNIXオペレーティング・システムの場合:
export UA_PROPERTIES="-Dfile.encoding=UTF-8 ${UA_PROPERTIES}"
Windowsオペレーティング・システムの場合:
set UA_PROPERTIES=-Dfile.encoding=UTF-8 %UA_PROPERTIES%
oracle_common/upgrade/bin
ディレクトリに移動します。- (UNIX)
ORACLE_HOME/oracle_common/upgrade/bin
- (Windows)
ORACLE_HOME\oracle_common\upgrade\bin
- (UNIX)
- Upgrade Assistantを起動します。
- (UNIX) ./ua
- (Windows) ua.bat
コマンドラインに指定可能なその他のパラメータ(ロギングのパラメータなど)の詳細は、次を参照してください。
アップグレード・アシスタントのパラメータ
コマンドラインからアップグレード・アシスタントを起動するときに、追加のパラメータを指定できます。
表7-4 アップグレード・アシスタントのコマンドライン・パラメータ
パラメータ | 必須またはオプション | 説明 |
---|---|---|
|
準備状況チェックの場合は必須
ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。 |
アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。 スキーマと構成がチェックされます。
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須 |
アップグレード・アシスタントがGUIモードで実行されているときに入力したデータから生成されるレスポンス・ファイルに保存されている入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。 |
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
オプション |
次のいずれかの属性を指定して、ログイン・レベルを設定します。
デフォルトのロギング・レベルは
|
|
オプション |
アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 (UNIX)
(Windows)
|
|
オプション |
すべてのコマンドライン・オプションを表示します。 |
アップグレード・アシスタントを使用したドメイン・コンポーネント構成のアップグレード
Upgrade Assistantの各画面を通じて、WebLogicドメインのコンポーネント構成をアップグレードします。
再構成ウィザードを実行してWebLogicドメインを14c (14.1.2.0.0)に再構成した後に、アップグレード・アシスタントを実行して、ドメイン・コンポーネント構成を、更新されたドメイン構成に一致するようにアップグレードする必要があります。
ドメイン固有コンポーネント構成のアップグレードの確認
ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、リモート・コンソールにサインインし、アップグレードされた各コンポーネントのバージョン番号が14.1.2.0.0になっていることを確認します。
ノート:
ホストされたWebLogicリモート・コンソールにアクセスする前に、ホストされたWebLogicリモート・コンソールをデプロイする必要があります。詳細は、Remote Consoleオンライン・ヘルプを参照してください。
リモート・コンソールにサインインするには、http://hostname:port/rconsole
、またはHTTPSの場合は https://hostname:port/rconsole
に移動します。
ノート:
アップグレードに成功したら、管理ツールは、前のOracleホーム・ディレクトリではなく新しい14c (14.1.2.0.0)のOracleホーム・ディレクトリから必ず実行してください。
アップグレード・プロセス時に、一部のOWSMドキュメント(ポリシー・セット、ポリシーおよびアサーション・テンプレートなどの事前定義ドキュメント)のアップグレードが必要な場合があります。ポリシー・セットまたは事前定義ドキュメントがアップグレードされると、バージョン番号が1増分されます。
Upgrade Assistantを実行するためにFMWユーザーを作成した場合は、アップグレードが成功したことを確認してからアカウントを削除してください。
WebCenter Portalのアップグレード後のタスク
アップグレードの完了後、次の構成ステップを実行します。
- 次のフィールドのファセット検索およびソートが有効になっていることを確認します。
デスクトップ・クライアント・アプリケーションは、次のステップで使用する必要があります。
Access Configuration Managerにログインし、「拡張検索」を選択して次のフィールドを選択します。
- dDocAccount - 「編集」をクリックします - 選択されていない場合は、「フィルタ・カテゴリです」チェックボックスを選択します。「OK」をクリックします
- dDocAuthor - 「編集」をクリックします - 選択されていない場合は、「フィルタ・カテゴリです」および「ソート可能」チェックボックスを選択します。「OK」をクリックします
- dDocLastModifiedDate - 「編集」をクリックします - 選択されていない場合は、「フィルタ・カテゴリです」および「ソート可能」チェックボックスを選択します。「OK」をクリックします
- dDocTitle - 「編集」をクリックします - 選択されていない場合は、「ソート可能」チェックボックスを選択します。「OK」をクリックします
- dFormat - 「編集」をクリックします - 選択されていない場合は、「フィルタ・カテゴリです」チェックボックスを選択します。「OK」をクリックします
- xWCTags - 「編集」をクリックします - 選択されていない場合は、「フィルタ・カテゴリです」チェックボックスを選択します。「OK」をクリックします
- WebCenter Contentの検索索引の再構築
Oracle WebCenter Contentの検索索引を再構築および更新するには、次のステップでデスクトップ・クライアント・アプリケーションを使用する必要があります。
- リポジトリ・マネージャへのアクセス
- 「リポジトリ・マネージャ」ページで、「インデクサ」タブをクリックします。
- 「コレクション再構築サイクル」セクションで、「開始」をクリックし、ダイアログで「高速再構築の使用」の選択を解除して、「OK」をクリックして次に進みます。
importPortletClientMetadata()
WLSTコマンドを実行して、アップグレード前のステップでエクスポートされたポートレット・クライアントのカスタマイズをインポートします。アップグレード前にWLSTコマンドexportPortletClientMetadata()
を実行していない場合は、このステップを無視します。importPortletClientMetadata(appName='webcenter', fileName='/tmp/portletClientExport.ear')
- 次に示すように、Portalが最後になるように、すべての管理対象サーバーおよび検索サーバーを再起動します。
サーバーおよびプロセスの起動
正常なアップグレードの後に、管理サーバーや管理対象サーバーなど、すべてのプロセスおよびサーバーを再起動します。
コンポーネントは相互に依存していることがあるため、適切な順序で起動する必要があります。
ノート:
この項の手順では、WLSTコマンドライン・ユーティリティまたはスクリプトを使用してサーバーおよびプロセスを起動する方法について説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Serverリモート・コンソールを使用することもできます。管理サーバーと管理対象サーバーおよびノード・マネージャの起動と停止に関する項を参照してください。
リリース14c (14.1.2.0.0)以降、WebLogic Server管理コンソールは削除されました。同等の機能を使用するには、WebLogicリモート・コンソールを使用する必要があります。詳細は、Oracle WebLogicリモート・コンソールを参照してください。
Fusion Middleware環境を起動するには、次のステップに従います。
ノート:
既存のセキュリティ設定によっては、保護された本番モードが有効になっているドメインを管理する前に、追加の構成を実行することが必要な場合があります。詳細は、WebLogicリモート・コンソールを使用した管理サーバーへの接続に関する項を参照してください
ステップ1: 管理サーバーの起動
管理サーバーを起動するには、startWebLogic
スクリプトを使用します。
-
(UNIX)
NEW_DOMAIN_HOME/bin/startWebLogic.sh
-
(Windows)
NEW_DOMAIN_HOME\bin\startWebLogic.cmd
ノート:
保護された本番モードを使用する場合は、管理サーバーを起動するための追加パラメータを指定する必要があります。『Oracle WebLogic Serverセキュリティの管理』のWLSTを使用した管理サーバーへの接続に関する項を参照してください。
プロンプトが表示されたら、管理サーバーのユーザー名とパスワード、およびURLを入力します。
ステップ2: ノード・マネージャを起動する
ノード・マネージャを起動するには、startNodeManager
スクリプトを使用します。
-
(UNIX)
NEW_DOMAIN_HOME/bin/startNodeManager.sh
-
(Windows)
NEW_DOMAIN_HOME\bin\startNodeManager.cmd
ステップ3: 管理対象サーバーを起動する
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
ノート:
保護された本番モードを使用する場合は、管理対象サーバーを起動するための追加パラメータを指定する必要があります。『Oracle WebLogic Serverセキュリティの管理』の起動スクリプトを使用した管理対象サーバーの起動に関する項を参照してください。
ノート:
通常、管理対象サーバーを起動すると、そのサーバーにデプロイされているアプリケーションが開始されます。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。ステップ4: システム・コンポーネントを起動する
Oracle HTTP Serverなどのシステム・コンポーネントを起動するには、startComponent
スクリプトを使用します。
-
(UNIX)
NEW_DOMAIN_HOME/bin/startComponent.sh component_name
-
(Windows)
NEW_DOMAIN_HOME\bin\startComponent.cmd component_name
システム・コンポーネントは任意の順序で起動できます。
アップグレード後のドメイン・モードの変更
アップグレード後、ドメインは元のアップグレード前のドメイン・セキュリティ・モード設定を保持します。ドメイン・モードを変更する場合、たとえば拡張セキュリティを有効にするには、WebLogicリモート・コンソールを使用するか、DomainMBean
を変更して、設定を明示的に変更する必要があります。
ドメインが現在本番モードに設定されていて、追加のセキュリティを有効にする場合は、アップグレード後にWebLogicリモート・コンソールを使用してドメイン・モードを変更し、保護された本番モードを有効にします。Oracle WebLogic Remote Consoleオンライン・ヘルプのドメイン・モードの変更に関する項。
注意:
ドメイン・モードの変更には、ドメインの完全再起動が必要です。ローリング再起動では不十分です。ドメイン・モードを変更する前に、すべての管理対象サーバーを停止する必要があります。
ドメインを14c (14.1.2.0.0)にアップグレードするときに、明示的なセキュア・モード設定がない場合、再構成ウィザードによって、アップグレード後のドメインではセキュア・モードが明示的に無効に設定されます。これは、元のドメインに存在していた動作を保持するためです。明示的なセキュア・モード設定がある場合、その設定がアップグレード後のドメインに保持されます。詳細は、『Oracle WebLogic Server本番環境の保護』のドメイン・モードがデフォルトのセキュリティ構成に与える影響の理解に関する項を参照してください。
ノート:
保護された本番モードでは、より制限的で厳しいセキュリティ設定が強制され、脅威に対する脆弱性が軽減されます。ドメインがセキュアであることを確認するには、保護された本番モードを有効にした後で、証明書の取得と格納、ユーザー・アカウントの保護、ドメインが実行されるネットワークの保護など、ドメインが実行される環境に適したセキュリティ構成オプションを選択する必要があります。これらのオプションが適切に構成されていない場合は、WebLogic Serverの使用がブロックされます。
WebLogicドメインの作成後には、適切なセキュリティ構成の選択など、整合性を確保するための主要なステップがいくつか残っています。詳細は、『Oracle WebLogic Serverセキュリティの管理』のドメイン作成後の保護に関する項を参照してください。