Oracle® Fusion Middleware

Oracle WebCenterのアップグレード

12c リリース2 (12.2.1.1)

E79352-01(原本部品番号:E71489-01)

2016年6月

既存のOracle WebCenter環境のアップグレード方法を説明します。

Oracle Fusion Middleware Oracle WebCenterのアップグレード, 12c リリース2 (12.2.1.1)

E79352-01

Copyright © 2015, 2016, Oracle and/or its affiliates  All rights reserved.

原本主著者: Lisa Jamen

原本協力者: Savita Thakur

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- 関連ドキュメント

- 表記規則

1 Oracle WebCenter 12c (12.2.1.1)のアップグレードの概要

- 1.1 Oracle WebCenterの12cへのアップグレードの理解

- 1.2 Oracle WebCenter 12cのアップグレードの開始ポイントの理解

- 1.3 相互運用性および互換性の制約の理解

- 1.4 Oracle WebCenterのアップグレード・プロセス・フローの理解

- 1.5 Oracle WebCenterのアップグレード手順の理解

2 Oracle WebCenterコンポーネントのアップグレード前のタスク

- 2.1 Oracle Fusion Middlewareのアップグレード前のチェックリスト

- 2.2 完全なバックアップの作成

- 2.2.1 スキーマ・バージョン・レジストリ表のバックアップ

- 2.2.2 カスタム・ドメイン環境設定のメンテナンス

- 2.3 テストのための本番環境のクローニング

- 2.4 動作保証およびシステム要件の確認

- 2.4.1 環境が動作保証要件を満たしていることの確認

- 2.4.2 システム要件と仕様の確認

- 2.4.3 Oracle Fusion Middlewareをホストしているデータベースがサポートされていることの確認

- 2.4.4 このリリースのOracle Fusion MiddlewareでJDKが動作保証されていることの確認

- 2.5 強化された暗号化(AES 256)を使用する場合のポリシー・ファイルの更新

- 2.6 不使用データのパージ

- 2.7 エディション・ベースの再定義のためのサーバー上でのエディションの作成

- 2.8 アップグレード・アシスタントを実行するための非SYSDBAユーザーの作成

- 2.9 Oracle WebCenterのアップグレード前のタスクの実行

- 2.9.1 アップグレード前の不要なコンポーネントの無効化

- 2.9.2 WebCenterのアップグレード可能なスキーマの判別

3 Oracle WebCenterドメインの12c (12.2.1.1)へのアップグレード

- 3.1 WebCenterに必要なOracle Fusion Middlewareのディストリビューションのインストール

- 3.2 WebCenter 12cのスキーマの作成

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

- 3.4 Upgrade Assistantを使用したスキーマのアップグレード

- 3.5 再構成ウィザードを使用したWebCenterドメインの再構成

- 3.6 アップグレード・アシスタントを使用したコンポーネント構成のアップグレード

- 3.7 アップグレード後の構成タスクの実行

- 3.7.1 管理サーバーの起動と停止

- 3.7.2 ノード・マネージャの起動と停止

- 3.7.3 管理対象サーバーの起動と停止

- 3.7.4 新規アプリケーションが予期したとおり動作することの確認

4 Oracle WebCenter Contentの12cへのアップグレード

- 4.1 Oracle WebCenter Content 12cへのアップグレードの理解

- 4.2 WebCenter Contentドメインのアップグレードの制約

- 4.3 WebCenter Contentのアップグレード前のタスクの実行

- 4.3.1 11g (11.1.1.6)インスタンスのアプリケーション名の変更

- 4.3.2 WebCenter Content Web UI 11gドメインのアップグレード前のメタデータ・スキーマ(_MDS)のアップグレード

- 4.3.3 アップグレード前の最新のInbound Refinery (IBR)のインストール

- 4.4 Oracle WebCenter Enterprise Captureのアップグレード前のタスクの実行

- 4.4.1 バッチ・プロセスが完了し取得JMSキューが空であることの確認

- 4.5 Oracle WebCenter Content Imagingのアップグレードの実行

- 4.6 Oracle WebCenter Contentのアップグレードの実行

- 4.7 WebCenter Contentのアップグレード後のタスクの実行

- 4.7.1 WebCenter Content - Web UIを含めるためのOracle WebCenter Contentサーバー・ドメインの構成

- 4.7.2 アップグレード後のE-Business Suite AXFスキーマの構成

- 4.7.3 Oracle WebCenter Content: ImagingのIPM/Viewer JMSサーバーの削除

- 4.7.4 Oracle WebCenter Content: ImagingのIPMサーバーの削除

- 4.7.5 WccAdf.earファイルの更新(オプション)

- 4.7.6 WebCenter Content Web UIのカスタム・スキンの移行

- 4.7.7 Oracle WebCenter Content用のOracleアプリケーション・アダプタのアップグレード

- 4.7.8 コンテンツ・サーバーでのレコード管理用のレポート・ライブラリの構成

- 4.7.9 IBRを監視するためのFusion Middleware Controlの使用方法

- 4.7.10 SOAまたはBAMを使用したOracle WebCenter Content Serverの起動

5 Oracle WebCenter Portalの11gから12cへのアップグレード

- 5.1 Oracle WebCenter Portalのアップグレード前のタスクの実行

- 5.1.1 OIDが起動し実行中であることの確認

- 5.1.2 ポートレット・プロデューサ・アプリケーションのメタデータのエクスポート

- 5.1.3 OmniPortletおよびWebクリッピング構成の保存

- 5.1.4 ポータル・フレームワーク・アプリケーションの移行

- 5.2 Oracle WebCenter Portal 11gインストールのアップグレード

- 5.2.1 upgradeWebCenterPortal WLSTコマンドの実行

- 5.2.1.1 upgradeWebCenterPortal WLSTコマンドによって生成される出力

- 5.2.2 アップグレード監査ツールの実行

- 5.2.3 アップグレード・メトリックへのアクセス

- 5.3 Oracle WebCenter Portalのアップグレード後のタスクの実行

- 5.3.1 11gのポートレット・プロデューサのアップグレード

- 5.3.1.1 ポートレット・プロデューサ・アプリケーションの移行

- 5.3.1.2 ポートレット・プロデューサ・アプリケーションの再デプロイ

- 5.3.1.3 カスタマイズ内容の移行

- 5.3.2 OmniPortletおよびWebクリッピング構成のリストア

- 5.3.3 重複したポータル・ページの削除

- 5.3.4 Content Server接続がアップグレードされたことの確認

- 5.3.5 WebCenter Portal 11gのアセットの12cへのアップグレード

- 5.4 非推奨機能のアップグレードによる影響の理解

- 5.4.1 ポータルレベルのデバイス設定

- 5.4.2 階層ポータル

- 5.4.3 非推奨のポートレット

- 5.5 Oracle WebCenter Portalのアップグレードに関する問題のトラブルシューティング

- 5.5.1 ACTIVITIESスキーマの余分なエントリが表示される

- 5.5.2 カスタム・ページ・テンプレートでフローティング・ツールバーを使用できない

- 5.5.3 プレデプロイメント・ツールの実行で11gのポートレット・プロデューサが更新されない

- 5.5.4 Oracle WebCenter Portalのアップグレード中のエラー処理

- 5.5.5 アップグレード後のポータルでドキュメント/ブログ/Wikiページにアクセスするとエラーが発生する

- 5.5.6 ポータルのアップグレードが失敗する

6 Oracle WebCenter Sitesの12c (12.2.1.1)へのアップグレード

- 6.1 WebCenter Sitesの11gから12cへのアップグレードの理解

- 6.2 WebCenter Sitesの11gから12cへのアップグレード

- 6.2.1 Fusion Middlewareインフラストラクチャのインストール

- 6.2.2 WebCenter Sites 12.2.1.1.0のディストリビューションのインストール

- 6.2.3 アップグレード前の必要なスキーマの作成

- 6.2.4 WebCenter Sitesドメインの構成

- 6.2.5 WebCenter Sitesインスタンスの構成

- 6.2.5.1 WebCenter Sitesインスタンスの構成の前提条件

- 6.2.5.2 コンフィギュレータによるWebCenter Sitesの構成

- 6.2.6 構成後のタスク

- 6.2.6.1 LDAPディレクトリに対する認証への切替え

- 6.2.6.2 Oracle Access Managerに対する認証への切替え

- 6.2.7 アップグレード・アシスタントを実行する前に

- 6.2.7.1 アップグレード・アシスタントを実行するための非SYSDBAユーザーの作成

- 6.2.7.2 DB2ソースから新規ターゲット・データベースへの11.1.1.8スキーマのコピー

- 6.2.8 アップグレード・アシスタントを使用したスキーマのアップグレード

- 6.2.9 アップグレード・アシスタントを使用した構成のアップグレード

- 6.2.10 アップグレード後の検証タスク

- 6.2.11 アップグレード後のタスク

- 6.3 WebCenter Sitesの以前の12cリリースからのアップグレード・プロセスの理解

- 6.4 WebCenter Sitesの以前の12cリリースからのアップグレード

- 6.4.1 Fusion Middlewareインフラストラクチャのインストール

- 6.4.2 WebCenter Sites 12.2.1.1.0のディストリビューションのインストール

- 6.4.3 管理サーバーと管理対象サーバーの停止

- 6.4.4 12.2.1.0の環境のバックアップ

- 6.4.5 再構成ウィザードを使用したWebCenter Sitesドメインの再構成

- 6.4.6 アップグレード・アシスタントを実行する前に

- 6.4.7 アップグレード・アシスタントを使用したスキーマのアップグレード

- 6.4.8 アップグレード・アシスタントを使用した構成のアップグレード

- 6.4.9 アップグレード後の検証タスク

- 6.4.10 アップグレード後のタスク

- 6.5 カスタムJavaライブラリまたは静的Webリソースの移行

7 クラスタ・トポロジのWebCenterのアップグレード

- 7.1 WebCenterクラスタのアップグレードのトラブルシューティング

- 7.1.1 アップグレード後のWebCenter Content URLへのアクセス

はじめに

『Oracle WebCenterのアップグレード』では、既存のOracle WebCenter環境をアップグレードするために必要なツールおよび手順について説明します。

- 対象読者

- 関連ドキュメント

- 表記規則

対象読者

このガイドは、既存のOracle Fusion Middlewareのユーザーのうち、使用しているOracle Fusion Middleware製品を、より新しいバージョンまたは最新バージョンにアップグレードするユーザーを対象としています。このドキュメントに記述されている手順に従うには、ユーザーとグループの作成、グループへのユーザーの追加、製品をインストールするコンピュータへのオペレーティング・システム・パッチのインストールなど、システム管理操作の実行に慣れている必要があります。Oracle Fusion MiddlewareソフトウェアをアップグレードするUNIXシステム・ユーザーは、一部のスクリプトを実行するためにrootアクセスが必要になることがあります。

親トピック: はじめに

関連ドキュメント

詳細は、次のマニュアルを参照してください。

- Oracle Fusion Middlewareの理解このマニュアルでは、Oracle Fusion Middleware環境での一般的な用語や概念を説明します。

- Oracle Fusion Middlewareの管理このマニュアルでは、インストールおよび構成が完了した後に、Oracle Fusion Middleware環境を管理するための情報を説明します。

- Oracle WebCenter Portalのインストールおよび構成

- Oracle WebCenter Contentのインストールと構成

- 高可用性ガイド。このマニュアルには、高可用性環境におけるOracle Fusion Middlewareのインストールに関する情報が含まれています。

親トピック: はじめに

表記規則

このマニュアルでは次の表記規則を使用します。

表記規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

親トピック: はじめに

1 Oracle WebCenter 12c (12.2.1.1)のアップグレードの概要

Oracle WebCenter 11g環境を12c (12.2.1.1)にアップグレードする場合、アップグレードがアップグレード前の環境にどのような影響を与えるかを理解する必要があります。

- Oracle WebCenterの12cへのアップグレードの理解

- Oracle WebCenter 12cのアップグレードの開始ポイントの理解

- 相互運用性および互換性の制約の理解

- Oracle WebCenterのアップグレード・プロセス・フローの理解

- Oracle WebCenterのアップグレード手順の理解

1.1 Oracle WebCenterの12cへのアップグレードの理解

Oracle WebCenter環境を12c (12.2.1.1)にアップグレードする場合、アップグレードがアップグレード前の環境にどのような影響を与えるかを理解する必要があります。たとえば、アップグレード時に既存の11gファイルを更新するスキーマおよびドメイン・ディレクトリのアップグレードは、「インプレース」で実行されます。12c (12.2.1.1)のOracleホーム・バイナリは新しいディレクトリにインストールされるため、「アウトオブプレース」でアップグレードされます。

12c (12.2.1.1)へのアップグレードには、中間層およびスキーマが含まれます。中間層のみ、またスキーマのみのアップグレードはできません。

- Oracle WebLogic Server、JRFおよびWebCenter Oracleホーム・バイナリ - アウトオブプレース・アップグレード
Oracle Infrastructure 12c (12.2.1.1) (WebLogic ServerおよびJRFを含みます)およびOracle WebCenterディストリビューション・バイナリを、新しいOracleホームにインストールします。11gバイナリは上書きされないため、バイナリのアップグレードは「アウトオブプレース」と考えられます。

- スキーマ - インプレースでアップグレード
11gスキーマは12c「インプレース」でアップグレードされるため、Upgrade Assistantはアップグレード処理時にスキーマを更新および上書きします。この処理の間は、サーバーを停止する必要があります。

例外: Oracle WebCenter Sitesのスキーマはアウトオブプレースでアップグレードされます。

- ドメイン・ディレクトリ再構成 - インプレースでアップグレード
既存のドメインは「インプレース」でアップグレードされます。アップグレードの間、11gドメインの場所を指定し、これが新しい12c (12.2.1.1)のホーム・ディレクトリをポイントするように再構成されます。

- ドメイン・コンポーネント構成 - インプレースでアップグレード
11gドメインを再構成した後、アップグレード・アシスタントを再度使用して、残りのドメイン・コンポーネント構成が新しい12c (12.2.1.1)のホーム・ディレクトリをポイントするようにアップグレードします。

1.2 Oracle WebCenter 12cのアップグレードの開始ポイントの理解

Oracle WebCenterの開始ポイントは、コンポーネントによって異なります。表をレビューして、Oracle WebCenter 12c (12.2.1.1)へのアップグレードがサポートされるバージョンを確認してください。

コンポーネント名

アップグレードがサポートされている開始ポイント

Oracle WebCenter Enterprise Capture[1]

11.1.1.8

11.1.1.9

12.2.1.0

Oracle WebCenter Content

11.1.1.7

11.1.1.8

11.1.1.9

12.2.1.0

Oracle WebCenter Portal

11.1.1.7

11.1.1.8

11.1.1.9

12.2.1.0

Oracle WebCenter Sites

11.1.1.8

12.2.1.0

1.3 相互運用性および互換性の制約の理解

11gから12cへのアップグレード・プロセスを開始する前に、アップグレードが11gドメインのすべてのコンポーネントにどのような影響を与えるかを理解する必要があります。相互運用性および互換性の理解には、同時にアップグレードできるコンポーネントと、アップグレードできないコンポーネントについての詳細なマトリックスが掲載されています。

通常、Oracle Fusion Middleware 12c (12.2.1.1)ではまだ使用できないコンポーネントを含むドメインはアップグレードできません。12c (12.2.1.1)にアップグレードできるコンポーネントには、別の制約もあります。これについての情報は、アップグレードを実行する前に慎重に確認する必要があります。

WebCenter Web UI 12cには、WebCenter ContentまたはApplication Development Framework 11gとの互換性がありません。

WebCenter Web UI 12c (12.2.1.1)をWebCenter Content 11gまたはApplication Development Framework 11gとともに使用することはできません。Web UIは12c (12.2.1.1)とのみ使用できます。

1.4 Oracle WebCenterのアップグレード・プロセス・フローの理解

この項では、Oracle WebCenter製品をアップグレードする手順の概要を説明します。

図1-1 Oracle WebCenterの12cへのアップグレード

1.5 Oracle WebCenterのアップグレード手順の理解

次の表では、Oracle WebCenter 11gを12cにアップグレードするために必要なタスクについて説明します。

手順

説明

詳細情報

1

Oracle Fusion Middlewareの、標準のアップグレード前のタスクと、追加のコンポーネント固有の必須タスクをすべて実行します。

Oracle WebCenterコンポーネントのアップグレード前のタスク

2

ドメインに含まれるすべての製品の製品ディストリビューションをインストールします。

12cでは、WebLogic ServerとJRFはインフラストラクチャのディストリビューションに含まれているため、これを最初にインストールする必要があります。

バイナリは、既存のデプロイメントと同じホストの新規Oracleホームにインストールする必要があります。

WebCenterに必要なOracle Fusion Middlewareのディストリビューションのインストール

3

管理サーバー、管理対象サーバー、および既存のデプロイメントで実行されている他のアプリケーションを停止します。

管理サーバーの起動と停止

4

11gから12cへのアップグレードのみ:

12cのリポジトリ作成ユーティリティ(RCU)を実行して、12cの必要なスキーマ(_STBおよび_OPSS)を作成します。

12cにはサービス表(STB)スキーマが必要です。

11gでOIDベースのポリシー・ストアが使用されていた場合は、OPSSスキーマが必要です。

WebCenter 12cのスキーマの作成

5

-readinessモードで実行された場合、アップグレード・アシスタントは読取り専用チェックを実行し、開始ポイント環境に正常なアップグレードの妨げになる問題がないかどうかを判別します。

チェックはコンポーネントによって異なり、考えられる問題のトラブルシューティングに役立つ完了レポートが生成されます。

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

6

アップグレード・アシスタントを実行して、選択したスキーマを個別に、またはドメインで使用されるスキーマをすべてアップグレードします。

Upgrade Assistantを使用したスキーマのアップグレード

7

再構成ウィザードを実行してドメインを再構成します。再構成ウィザードは、Oracle Fusion Middleware 12cの新しいツールです。

再構成ウィザードを使用したWebCenterドメインの再構成

8

WebCenter PortalおよびSitesのユーザーのみ: アップグレード・アシスタントを(再度)実行し、残りのコンポーネント構成をアップグレードします。

WebCenter Contentのユーザーのみ: 必要な構成変更は、サーバーの起動時(アップグレード後)に、ユーザーの介入なしに自動的に実行されるので、アップグレード・アシスタントは実行しません。

アップグレード・アシスタントを使用したコンポーネント構成のアップグレード

9

WebCenter Portalのユーザーのみ: Oracle WebCenter Portalを12cにアップグレードするには、一連の追加手順を実行する必要があります。

Oracle WebCenter Portal 11gインストールのアップグレード

10

コンポーネント固有のドキュメントで説明されている、アップグレード後に必要なすべてのタスクを実行します。

アップグレード後にこれらのタスクを実行しないと、一部のコンポーネントが正しく動作しないことがあります。

アップグレード後の構成タスクの実行

11

管理サーバーおよび管理対象サーバーを再起動します。

管理サーバーの起動と停止

12

アップグレードが成功したこと(アプリケーションが予期したとおり機能するなど)を確認します。

新規アプリケーションが予期したとおり動作することの確認

13

クラスタ・トポロジのWebCenterをアップグレードします(該当する場合)。

クラスタ・トポロジのWebCenterのアップグレード

[1]
WebCenter Capture 11.1.1.9.0をインストールした場合、11.1.1.9.0でのスキーマ変更はないため、スキーマ・バージョンは11.1.1.8.0のままです。

2 Oracle WebCenterコンポーネントのアップグレード前のタスク

既存のOracle WebCenterコンポーネントをアップグレードする前に、必須のアップグレード前のタスクを実行する必要があります。

Oracle WebCenter固有のアップグレード前のタスクを開始する前に、標準のFusion Middlewareのアップグレード前のチェックリストを完了させます。実行するタスクは、アップグレードするコンポーネントによって異なります。

- Oracle Fusion Middlewareのアップグレード前のチェックリスト
Oracle Fusion Middlewareのアップグレード前のチェックリストでは、限られた停止時間でアップグレードが成功するように、アップグレードを開始する前に実行するタスクを識別します。

- 完全なバックアップの作成
新しい12c (12.2.1.1)のディストリビューションをインストールして既存のOracle Fusion Middlewareをアップグレードを開始する前に、Oracle Fusion Middlewareスキーマをホストするデータベースを含む、重要なすべてのシステム・ファイルをバックアップしたことを確認してください。

- テストのための本番環境のクローニング
実際の本番環境の完全な作業用コピーを作成し、クローン環境をアップグレードし、アップグレードされたコンポーネントが予想どおりに動作することを確認してから(必ず確認した後で)、本番環境をアップグレードすることをお薦めします。

- 動作保証およびシステム要件の確認
ご使用の環境がインストールに必要な要件を満たしていることを確認するには、動作保証マトリックスおよびシステム要件のドキュメントをあわせて使用する必要があります。

- 強化された暗号化(AES 256)を使用する場合のポリシー・ファイルの更新
アップグレード後の環境でAdvanced Encryption Standard (AES) 256などの強化された暗号化を使用する予定がある場合に実行する、オプションの手順です。アップグレードする前に必要な最新のポリシー・ファイルをJDKに適用することをお薦めします。

- 不使用データのパージ
アップグレード前に使用しないデータをパージし、パージ方法を管理することで、アップグレード・プロセスを最適化できます。

- エディション・ベースの再定義のためのサーバー上でのエディションの作成
エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、データベース・サーバーに接続して、12cのデータベース・サーバーにエディションを作成する必要があります。

- アップグレード・アシスタントを実行するための非SYSDBAユーザーの作成
アップグレード・アシスタントを実行するための、FMWという非SYSDBAユーザーを作成することをお薦めします。FMWユーザーにはスキーマ変更に必要な権限はありますが、完全な管理者権限はありません。

- Oracle WebCenterのアップグレード前のタスクの実行

2.1 Oracle Fusion Middlewareアップグレード前のチェックリスト

Oracle Fusion Middlewareのアップグレード前のチェックリストでは、限られた停止時間でアップグレードが成功するように、アップグレードを開始する前に実行するタスクを識別します。

アップグレードはサーバーの停止中に実行されます。チェックリストは、アップグレード前の重要な(かつ時間がかかる)タスクを識別するためのものであり、これをアップグレード前に実行することで停止時間を短縮できます。アップグレード・プロセスを開始する前の準備を十分行うほど、オフライン時間を減らすことができます。

注意:
実行するアップグレード前の手順は、既存のシステムの構成、アップグレードするコンポーネントおよびアップグレードと構成プロセスの最後に作成する環境によって異なります。構成またはユースケースに該当するタスクのみを実行してください。

表2-1 Oracle Fusion Middleware 12cにアップグレードする前に実行するタスク

タスク

説明

ドキュメント

既存の環境の完全なバックアップを作成します。

必須

アップグレードを開始する前に、アップグレードしようとしているスキーマを含めてシステムに重要なファイルとデータベースをすべてバックアップします。

アップグレードに失敗した場合は、アップグレード前の環境をリストアして、アップグレードを再試行できます。

完全なバックアップの作成

既存のドメインの起動スクリプトを変更した場合、アップグレード中はそれらを一時ディレクトリ(既存のドメイン以外)の場所にコピーし、アップグレード後に再デプロイする必要があります。

カスタム・ドメイン環境設定のメンテナンス

使用する本番環境を、アップグレードのテスト用プラットフォームとしてクローンします。

オプション

システム・ファイルの完全なバックアップを作成する他に、本番環境のクローンも作成することをお薦めします。この環境は、アップグレードをテストするために使用されます。

テストのための本番環境のクローニング.

サポートされているハードウェアおよびソフトウェア構成上で、製品をインストールおよびアップグレードしていることを確認します。

サポートされている最新のオペレーティング・システムを使用できない場合はアップグレードしないでください。サポート対象のすべての構成と同様、こうした要件を守れない場合は、アップグレードが失敗する可能性があります。

必須

ハードウェアとソフトウェア(オペレーティング・システムも含む)の構成が最新の動作保証および要件のドキュメントでサポートされていることを確認します。

動作保証要件は頻繁に更新されるため、アップグレードを開始する直前に、この情報を確認することをお薦めします。

アップグレードの前に、コンポーネントに最新のパッチが適用されていることを確認します。

また、12c製品のディストリビューションをインストールする前に、サポートされるバージョンのJDKを使用していることを確認してください。

動作保証およびシステム要件の確認

現在32ビットのオペレーティング・システムを実行している場合は、アップグレードの前に、64ビットのオペレーティング・システムに移行する必要があります。

32ビットから64ビット・オペレーティング・システムへの移行(32ビットOSの場合のみ必須)

強化された暗号化(AES 256)を使用している場合は、セキュリティ・ポリシー・ファイルを更新します。

Fusion Middleware 12cで使用されているセキュリティ・アルゴリズムには、JDK用の追加のポリシー・ファイルが必要になるものがあります。

オプション

強化された暗号化(AES 256など)を使用する予定がある場合は、アップグレードの前に、最新の必須ポリシー・ファイルをJDKに適用することをお薦めします。

強化された暗号化(AES 256)を使用する場合のポリシー・ファイルの更新

アップグレードの前に、古いデータまたは使用しないデータを削除します。

オプション

パフォーマンスの最適化のために、アップグレードされた環境で使用しないデータおよびオブジェクトをパージすることを検討してください。

インスタンスのアップグレードを開始する前に、パージ・スクリプトを使用して、アップグレードした12c環境では不要になるクローズされた11gインスタンスをパージします。

不使用データのパージ

Oracle Databaseユーザーのみ: エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、データベース・サーバーに接続して、12c (12.2.1.1)のデータベース・サーバーにエディションを作成する必要があります。

EBRデータベースを使用している場合のみ必須

エディション・ベースの再定義(EBR)データベースを使用している場合は、アップグレードを開始する前にエディションを作成する必要があります。

エディション・ベースの再定義のためのサーバー上でのエディションの作成

アップグレード・アシスタントを実行するための非SYSDBAユーザーを作成します。

オプション
アップグレード・アシスタントを実行するための、FMWユーザーを作成することをお薦めします。ユーザーFMWは、システム管理者の権限を持たずにアップグレード・アシスタントを実行できます。

アップグレード・アシスタントを実行するための非SYSDBAユーザーの作成

2.2 完全なバックアップの作成

新しい12c (12.2.1.1)のディストリビューションをインストールして既存のOracle Fusion Middlewareをアップグレードを開始する前に、Oracle Fusion Middlewareスキーマをホストするデータベースを含む、重要なすべてのシステム・ファイルをバックアップしたことを確認してください。

スキーマ・アップグレードを実行する前にデータベースの完全なバックアップを実行することは、アップグレード・アシスタントを実行するための前提条件です。実際のアップグレードを続行する前に、Upgrade Assistant前提条件のGUI画面で、バックアップが実行されていることを確認する必要があります。

詳細は、Oracle Fusion Middleware環境のバックアップに関する項および「12cのためのOracle Databaseのアップグレードおよび準備」を参照してください。

注意:
システム・バックアップにはSYSTEM.SCHEMA_VERSION_REGISTRY$表が含まれている必要があります。

- スキーマ・バージョン・レジストリ表のバックアップ
システム・バックアップにはSYSTEM.SCHEMA_VERSION_REGISTRY$表が含まれている必要があります。

- カスタム・ドメイン環境設定のメンテナンス
各ドメインには、動的に生成されるドメインおよびサーバーの起動スクリプト(setDomainEnvなど)が含まれます。起動スクリプトに行った変更は、その後のドメインのアップグレードおよび再構成操作中に上書きされるため、これらの起動スクリプトを変更しないでください。

2.2.1 スキーマ・バージョン・レジストリ表のバックアップ

システム・バックアップにはSYSTEM.SCHEMA_VERSION_REGISTRY$表が含まれている必要があります。

SYSTEM.SCHEMA_VERSION_REGISTRY$表には、各Fusion Middlewareスキーマの行があります。Upgrade Assistantを実行して既存のスキーマを更新する際、正常に更新できなかった場合は、元のスキーマをリストアしてからやりなおす必要があります。必ず、既存のデータベース・スキーマをバックアップしてから、Upgrade Assistantを実行してください。

注意:
スキーマ・アップグレードを実行する前にこれらのバックアップを実行することは、Upgrade Assistantを実行するための前提条件です。実際のアップグレードを続行する前に、Upgrade Assistant前提条件のGUI画面で、バックアップが実行されていることを確認する必要があります。

2.2.2 カスタム・ドメイン環境設定のメンテナンス

すべてのドメインには、動的に生成されたドメインおよびsetDomainEnvなどのサーバー起動スクリプトがあります。起動スクリプトに行った変更は、その後のドメインのアップグレードおよび再構成操作中に上書きされるため、これらの起動スクリプトを変更しないでください。

カスタム・ドメイン・レベルの環境設定を維持するには、アップグレードの前に、カスタム・ドメイン情報を格納するファイルを別途作成してください。

たとえば、ドメインのすべてのサーバーに適用されるサーバー起動パラメータをカスタマイズする場合は、setUserOverrides.cmd (Windows)またはsetUserOverrides.sh (UNIX)という名前のファイルを作成することにより、たとえば、WebLogic Serverクラスパスにカスタム・ライブラリを追加する、サーバー実行用の追加のJavaコマンド行オプションを指定する、または追加の環境変数を指定する、などの構成が可能です。このファイルに追加されたカスタム設定はドメインのアップグレード操作中に保存され、packおよびunpackコマンドを使用する際にリモート・サーバーに継承されます。

setUserOverridesファイルにおける起動のカスタマイズの例を次に示します。

# add custom libraries to the WebLogic Server system claspath
if [ "${POST_CLASSPATH}" != "" ] ; then
POST_CLASSPATH="${POST_CLASSPATH}${CLASSPATHSEP}${HOME}/foo/fooBar.jar"
export POST_CLASSPATH
else
POST_CLASSPATH="${HOME}/foo/fooBar.jar"
export POST_CLASSPATH
fi

# specify additional java command line options for servers
JAVA_OPTIONS="${JAVA_OPTIONS}  -Dcustom.property.key=custom.value"

サーバーの起動中にsetUserOverridesファイルが存在する場合、このファイルが起動シーケンスに含まれ、このファイルにオーバーライドがあれば、有効になります。setUserOverridesファイルは、domain_home/binディレクトリに格納する必要があります。

注意:

アップグレード前に、setUserOverridesスクリプトを作成できない場合は、「起動スクリプトへのカスタマイズの再適用」の説明に従って、設定を再適用する必要があります。

2.3 テストのための本番環境のクローニング

実際の本番環境の完全な作業用コピーを作成し、クローン環境をアップグレードし、アップグレードされたコンポーネントが予想どおりに動作することを確認してから(必ず確認した後で)、本番環境をアップグレードすることをお薦めします。

アップグレードは元に戻せません。ほとんどの場合、エラーが発生したときには、アップグレードを中止してバックアップから環境全体をリストアし、アップグレード・プロセスを最初からやり直す必要があります。潜在的なアップグレードの問題を開発環境で特定しておくと、無駄な停止時間を排除できます。

注意:
すべてのコンポーネントおよびオペレーティング・システムのクローニング手順について、このドキュメントでは説明していません。クローニング手順は、コンポーネントおよびオペレーティング・システムに固有のものです。概略としては、アップグレード前のバージョンのコンポーネント・ドメインをテスト・マシンにインストールし、リポジトリ作成ユーティリティ(RCU)を使用して必要なスキーマを作成し、アップグレードを実行します。

本番環境のクローンでアップグレードを実行すると、次のようなメリットもあります。

- アップグレードに関する問題を明らかにし、修正します。

- エンドツーエンドのアップグレードを完了させる練習をします。

- アップグレードのパフォーマンスおよびパージ・スクリプトがどのように役立つかを理解します。

- アップグレードの完了までに必要な時間を理解します。

- データベース・リソースの使用(一時表領域、PGAなど)について理解します。

注意:
クローニングした本番環境でアップグレード前の準備状況チェックを実行すれば、データで発生しうるアップグレード時の問題は特定できますが、正常なアップグレードの万全を期すためには、クローニングした環境で完全なテスト・アップグレードを実行する必要があります。

2.4 動作保証およびシステム要件の確認

ご使用の環境がインストールに必要な要件を満たしていることを確認するには、動作保証マトリックスおよびシステム要件のドキュメントを併せて使用する必要があります。

注意:
動作保証、システム要件および相互運用性情報を確認する場合、特に32ビットまたは64ビットのシステム要件を確認するようにしてください。32ビットまたは64ビットの環境専用として設計されているソフトウェアを明示的にダウンロードすることが重要です。

警告:
アップグレードを開始する前に、現在の環境に最新のパッチが適用されていることを確認してください。動作保証は、特に指定がないかぎり、完全にパッチが適用された環境に基づいています。

- 環境が動作保証要件を満たしていることの確認
Oracleでは、動作保証済のすべてのシステムおよび環境で製品のパフォーマンスをテストおよび検証しています。製品をインストールする場合、サポートされているハードウェアまたはソフトウェア構成を使用します。

- システム要件と仕様の確認
ディスク領域、使用可能なメモリー、特定のプラットフォーム・パッケージおよびパッチ、その他のオペレーティング・システム固有の項目などのシステム要件が満たされていることを確認することが重要です。

- Oracle Fusion Middlewareをホストしているデータベースがサポートされていることの確認
Oracle Fusion Middleware 12cを実行する前に、サポートされるOracle Databaseを必須のスキーマで構成しておく必要があります。

- このリリースのOracle Fusion MiddlewareでJDKが動作保証されていることの確認
汎用インストーラを使用してOracle Fusion Middleware製品をインストールするには、インストーラを実行する前に、サポートされているJDKをシステムにダウンロードしてインストールする必要があります。

2.4.1 環境が動作保証要件を満たしていることの確認

Oracleでは、動作保証済のすべてのシステムおよび環境で製品のパフォーマンスをテストおよび検証しています。製品をインストールする場合、サポートされているハードウェアまたはソフトウェア構成を使用します。

新しい動作保証情報が発表された場合は、適切な動作保証ドキュメントにすぐに追加されます。新しい動作保証要件は随時確認される場合があるため、動作保証に関するドキュメントはドキュメント・ライブラリの外部に置かれ、Oracle Technology Networkで提供されています。詳細は、12c (12.2.1.1)の動作保証マトリックスに関する説明を参照してください。

2.4.2 システム要件と仕様の確認

ディスク領域、使用可能なメモリー、特定のプラットフォーム・パッケージおよびパッチ、その他のオペレーティング・システム固有の項目などのシステム要件が満たされていることを確認することが重要です。

Oracle Fusion Middlewareのシステム要件と仕様に関するドキュメントを使用して、動作保証要件を満たしていることを確認してください。たとえば、この動作保証に関するドキュメントに、ご使用の製品を64ビットOracle Linux 7上にインストールすることが動作保証されていると示されている場合、このドキュメントを使用して、Oracle Linux 7システムが最低限必要な仕様(ディスク領域、使用可能なメモリー、特定のプラットフォーム・パッケージとパッチおよびその他のオペレーティング・システム固有のアイテムなど)を満たしていることを確認します。このドキュメントは必要に応じて更新され、ドキュメント・ライブラリの外部に置かれています。最新バージョンは、Oracle Technology Networkから入手できます。

Oracle Fusion Middleware 12cのインストールおよび12cへのアップグレードの詳細は、「システム要件と仕様のレビュー」を参照してください。

注意:
アップグレード準備の一環としてOracle Fusion Middlewareリリース12cソフトウェアをインストールする際は、アップグレード前の既存のOracle Fusion Middlewareソフトウェアのインストールおよび構成に使用したものと同じユーザー・アカウントを使用する必要があります。UNIXオペレーティング・システムでは、これによって、正しい所有者とグループが新しいOracle Fusion Middleware 12cのファイルおよびディレクトリに確実に適用されます。

- 32ビットから64ビット・オペレーティング・システムへの移行(32ビットOSの場合のみ必須)
この手順は、32ビット環境を実行している場合にのみ必要です。32ビットOSが存在する場合は、アップグレード前に、32ビット環境を64ビット・ソフトウェア環境に移行する必要があります。

2.4.2.1 32ビットから64ビット・オペレーティング・システムへの移行(32ビットOSの場合のみ必須)

この手順は、32ビット環境を実行している場合にのみ必要です。32ビットOSが存在する場合は、アップグレード前に、32ビット環境を64ビット・ソフトウェア環境に移行する必要があります。

Oracle Fusion Middleware 11gソフトウェアがすべて適切に64ビット・マシンで動作することを確認してから、Oracle Fusion Middleware 12cへのアップグレードを実行してください。

次のタスクでは、ホストは、32ビット・ソース・マシンを指し、ターゲットは、新しい64ビット・ターゲット・マシンを指します。

注意:
これらの手順は、データベースが別のホスト上にあり、移動されないことを前提としています。

オペレーティング・システムのアップグレードには、通常、次の内容が含まれます。

注意:
これらの手順は、オペレーティング・システム・アップグレード・プロセスの例として説明されているため、特定のオペレーティング・システムを更新する場合に実行する必要がある手順がすべて含まれている場合と含まれていない場合があります。詳細は、使用しているオペレーティング・システムのアップグレード・ドキュメントを参照してください。

- アップグレードの64ビット・ソフトウェア要件をサポートするハードウェアを調達する
アップグレード・プロセスを開始する前に、サポートされている適切なターゲット・ハードウェアが存在することを確認してください。

- すべてのプロセスを停止する
アップグレードの前に、管理サーバー、管理対象サーバーおよびノード・マネージャがホスト上で起動している場合はこれらも含めて、すべてのプロセスを停止する必要があります。

- 32ビット・ホスト・マシンからすべてのファイルをバックアップする
11gデプロイメント全体の完全バックアップを作成したことを確認してからアップグレード・プロセスを開始する必要があります。移行中に問題が発生した場合、これらのファイルを使用してプロセスを再度開始する必要があります。

- 11gのホスト名およびIPアドレスを使用してターゲットの64ビット・マシンを設定する
ターゲット・マシンのホスト名およびIPアドレスはホストと同一にする必要があります。そのため、ソース・マシンのIPアドレスおよび名前を変更するか、ソース・マシンを停止してネットワークの干渉を回避する必要があります。

- 11gバックアップを32ビット・ホストから64ビット・ホストにリストアする
11gで使用したものと同じディレクトリ構造を使用して、32ビット・ホストからバックアップしたファイルをリストアします。ターゲット・マシンのディレクトリ構造は、ホスト・マシンのディレクトリ構造と同じである必要があります。

- 12c製品ディストリビューションをターゲット・マシンにインストールする
アップグレードはホーム外で実行することをお薦めします。したがって、12c製品ディストリビューションは、ターゲット・マシン上の新しいOracleホームでインストールする必要があります。

- 標準的なアップグレード手順を使用してターゲットの64ビット環境をアップグレードする
ターゲット・マシンに製品をインストールしたら、コンポーネント固有のアップグレード・ガイドで指定されたアップグレード・ユーティリティを使用して各製品コンポーネントを個々にアップグレードし、アップグレード後のタスクを実行する必要があります。

2.4.2.1.1 アップグレードの64ビット・ソフトウェア要件をサポートするハードウェアを調達する

アップグレード・プロセスを開始する前に、サポートされている適切なターゲット・ハードウェアが存在することを確認してください。

2.4.2.1.2 すべてのプロセスを停止する

アップグレードの前に、管理サーバー、管理対象サーバーおよびノード・マネージャがホスト上で起動している場合はこれらも含めて、すべてのプロセスを停止する必要があります。

たとえば、管理サーバーを停止するには、次のコマンドを入力します。

DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]

2.4.2.1.3 32ビット・ホスト・マシンからすべてのファイルをバックアップする

11gデプロイメント全体の完全バックアップを作成したことを確認してからアップグレード・プロセスを開始する必要があります。移行中に問題が発生した場合、これらのファイルを使用してプロセスを再度開始する必要があります。

注意:
同一のマシンで32ビットから64ビットへアップグレードする場合、アップグレードが失敗した場合、ソース環境が破損するリスクがあります。

11gのファイルのバックアップの詳細は、『Oracle® Fusion Middleware管理者ガイド』の環境のバックアップに関する項を参照してください。

アップグレード時に、次のコンテンツにアクセスする必要があります。

- 11gドメイン・ホーム

- $ORACLE_HOME/wlserver/common/にある、11gの/nodemanagerディレクトリ

『Oracle® Fusion Middleware管理者ガイド』の環境のバックアップに関する項で説明されている一部のバックアップおよびリカバリ手順は、製品に固有です。完全バックアップを作成するまでアップグレードを続行しないでください。

2.4.2.1.4 11gのホスト名およびIPアドレスを使用してターゲットの64ビット・マシンを設定する

ターゲット・マシンのホスト名およびIPアドレスはホストと同一にする必要があります。そのため、ソース・マシンのIPアドレスおよび名前を変更するか、ソース・マシンを停止してネットワークの干渉を回避する必要があります。

IPアドレスおよびホスト名を変更するプロセスは、オペレーティング・システムによって異なります。詳細は、オペレーティング・システムの管理ドキュメントを参照してください。

2.4.2.1.5 11gのバックアップを32ビット・ホストから64ビット・ホストにリストアする

11gで使用したものと同じディレクトリ構造を使用して、32ビット・ホストからバックアップしたファイルをリストアします。ターゲット・マシンのディレクトリ構造は、ホスト・マシンのディレクトリ構造と同じである必要があります。

64ビットターゲット・マシンに11gファイルをリストアする方法の詳細は、『Oracle® Fusion Middleware管理者ガイド』の環境のリカバリに関する項を参照してください。

2.4.2.1.6 12c製品ディストリビューションをターゲット・マシンにインストールする

アップグレードには、ホーム外のアプローチをお薦めします。したがって、12c製品ディストリビューションは、ターゲット・マシン上の新しいOracleホームでインストールする必要があります。

12cのディストリビューションを取得する方法の詳細は、製品ディストリビューションの理解と取得に関する説明を参照してください。インストール・ユーザーを識別するには、インストール・ユーザーの選択に関する説明を参照してください。インストールおよび構成のためのディレクトリ構造を理解するには、「インストールおよび構成のためのディレクトリの理解」を参照してください。インストールするコンポーネントの詳細は、コンポーネント固有のインストール・ガイドを参照してください。

2.4.2.1.7 標準的なアップグレード手順を使用してターゲットの64ビット環境をアップグレードする

ターゲット・マシンに製品をインストールしたら、コンポーネント固有のアップグレード・ガイドで指定されたアップグレード・ユーティリティを使用して各製品コンポーネントを個々にアップグレードし、アップグレード後のタスクを実行する必要があります。

詳細なアップグレード手順は、アップグレードするコンポーネントのコンポーネント固有のアップグレード・ガイドを参照してください。

注意:
ノード・マネージャ・アップグレード手順では、元のノード・マネージャ・ファイルにアクセスする必要があります。32ビット・ホスト・マシンからすべてのファイルをバックアップする手順の一部として、32ビット・ソース・マシンからバックアップされた11gノード・マネージャ・ファイルを使用します。

2.4.3 Oracle Fusion Middlewareをホストしているデータベースがサポートされていることの確認

Oracle Fusion Middleware 12cを実行する前に、サポートされるOracle Databaseを必須のスキーマで構成しておく必要があります。

アップグレード時のOracle Databaseの要件を理解し、Oracle Fusion Middlewareをホストするデータベースがサポートされており、アップグレードの実行に十分な領域が用意されていることを確認しているものとします。詳細は、12c (12.2.1.1)の動作保証マトリックスに関する説明を参照してください。

2.4.4 このリリースのOracle Fusion MiddlewareでJDKが動作保証されていることの確認

汎用インストーラを使用してOracle Fusion Middleware製品をインストールするには、サポートされているJDKをシステムにダウンロードしてインストールする必要があります。

このドキュメントの発行時に動作保証されていたJDKは1.8.0_51でした。

必要なJDKをダウンロードするには、ブラウザで次のURLにアクセスしてJava SE JDKをダウンロードします。

http://www.oracle.com/technetwork/java/javase/downloads/index.html

JDKは、Oracleホームの外部にインストールしてください。Oracle Universal Installerにより指定されたOracleホーム・ディレクトリが空であることが検証され、空のディレクトリが指定されていなければインストールは行われません。JDKをOracleホームにインストールした場合、今後の操作で問題が発生することがあります。したがって、JDKのインストール環境は、/home/oracle/products/jdkディレクトリに指定することをお薦めします。

汎用インストーラとプラットフォーム固有のインストーラの相違点の詳細は、Oracle Fusion Middlewareのダウンロード、インストールおよび構成のREADMEファイルの汎用とプラットフォーム固有のディストリビューションとの相違点の理解に関する項を参照してください。

2.5 強化された暗号化(AES 256)を使用する場合のポリシー・ファイルの更新

アップグレード後の環境でAdvanced Encryption Standard (AES) 256などの強化された暗号化を使用する予定がある場合に実行する、オプションの手順です。アップグレードする前に必要な最新のポリシー・ファイルをJDKに適用することをお薦めします。

Javaプラットフォームでは、暗号化、公開鍵インフラストラクチャ、認証、安全な通信、アクセス制御など、主要なセキュリティ分野に渡る一連のAPIが定義されています。これらのAPIによって、開発者はアプリケーション・コードにセキュリティ・メカニズムを簡単に統合できます。

Fusion Middleware 12cで使用されているセキュリティ・アルゴリズムには、JDK用の追加のポリシー・ファイルが必要になるものがあります。詳細は、Java暗号化アーキテクチャOracleプロバイダのドキュメントを参照してください。

アップグレードの開始前に、これらのポリシー・ファイルをJDKに適用せずに、強化された暗号化の使用を試行すると、アップグレードに失敗することがあります。その場合は、アップグレード前の環境全体をリストアして、アップグレードを最初からやり直す必要があります。

2.6 不使用データのパージ

アップグレード前に使用しないデータをパージし、パージ方法を管理することで、アップグレード・プロセスを最適化できます。

注意:
大量のデータをパージする必要がある場合は、表のパーティション化や、その他のデータ最適化戦略の採用について検討してください。大量のデータを削除するスクリプトを使用すると、パフォーマンスに影響を与えることがあります。「パージおよびパーティショニング方法の開発」と「データベース増分管理戦略の策定」を参照してください

一部のコンポーネントには、自動化されたパージ・スクリプトがあります。パージ・スクリプトを使用する場合、パージが完了するまで待ってから、アップグレード・プロセスを開始してください。アップグレード・アシスタントを使用してスキーマをアップグレードするときに、パージ・スクリプトを実行していると、アップグレードは失敗する可能性があります。

2.7 エディション・ベースの再定義のためのサーバー上でのエディションの作成

エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、最初にデータベース・サーバーに接続して、12cのデータベース・サーバーにエディションを作成する必要があります。

エディションベースの再定義を使用すると、アプリケーションの使用中にアプリケーションのデータベース・オブジェクトをアップグレードできるため、停止時間を最小限に抑えることや解消することが可能です。これは、エディションと呼ばれるプライベート環境でデータベース・オブジェクトを変更(再定義)することにより実行します。すべての変更が実行およびテストされている場合のみ、アプリケーションの新バージョンをユーザーが使用できるようにしてください。

注意:
このタスクは、DBA権限を持つOracle Databaseユーザーが実行する必要があります。

エディション・ベースの再定義(EBR)に対応したスキーマをアップグレードする前に、最初にデータベース・サーバーに接続して、12cのデータベース・サーバーにエディションを作成する必要があります。12cの新しいエディションは、既存の11gまたは12cエディションの子である必要があります。

データベース・サーバーにエディションを作成するには、SYSユーザー(またはDBA権限のある別のOracleユーザー)としてログインし、次のコマンドを入力します。

create edition Oracle_FMW_12_2_1 as child of Oracle_FMW_11_1_1_7_0;

ここで、Oracle_FMW_11_1_1_7_0が、11.1.1.7スキーマを作成したときにRCU 11.1.1.7で指定したエディション名の例です。エディションを作成する際は、実際に使用する名前を入力してください。

エディションが正常に作成されると、次のメッセージが表示されます。

エディションが作成されました。

アップグレードの間、再構成ウィザードを実行して既存のドメインを再構成するよう要求されます。再構成ウィザードの実行前に、データベースのデフォルト・エディションを指定する必要があります。次のようなSQLを使用して、データベースのデフォルト・エディション名を手動で次のように設定します。

ALTER DATABASE DEFAULT EDITION = Oracle_FMW_12_2_1;

2.8 アップグレード・アシスタントを実行するための非SYSDBAユーザーの作成

アップグレード・アシスタントを実行するための、FMWという非SYSDBAユーザーを作成することをお薦めします。FMWユーザーにはスキーマ変更に必要な権限はありますが、完全な管理者権限はありません。

SYSDBAはデータベースの作成、起動、停止、バックアップまたはリカバリなどの高度な管理操作を実行するために必要な管理権限です。SYSDBAシステム権限は、完全な権限を持つデータベース管理者が使用します。SYSDBA権限で接続すると、通常はユーザー名に関連付けられているスキーマではなく、デフォルトのスキーマで接続が確立されます。SYSDBAの場合、このスキーマはSYSです。デフォルト・スキーマへのアクセスは非常に強力な権限となる場合があります。たとえば、ユーザーSYSとして接続する場合、データ・ディクショナリの表における権限は無制限となります。したがって、スキーマをアップグレードするには、非SYSDBAユーザーを作成することをお薦めします。アップグレード・アシスタントを起動する前に、このトピックにリストされている権限を付与する必要があります。

注意:
v$xatrans$表は、デフォルトでは存在しません。ユーザーを作成する前に、XAVIEW.SQLスクリプトを実行して、この表を作成する必要があります。また、v$xatrans$表に対する権限付与が必要なのはOracle Identity Managerの場合のみです。構成にOracle Identity Managerが必要ない場合、またはv$xatrans$表が存在しない場合は、次の行をスクリプトから削除します。

grant select on v$xatrans$ to FMW with grant option;

次の例では、welcome1がパスワードです。権限を付与する際に、実際のパスワードを指定していることを確認します。

create user FMW identified by welcome1;
grant dba to FMW;
grant execute on DBMS_LOB to FMW with grant option;
grant execute on DBMS_OUTPUT to FMW with grant option;
grant execute on DBMS_STATS to FMW with grant option;
grant execute on sys.dbms_aqadm to FMW with grant option;
grant execute on sys.dbms_aqin to FMW with grant option;
grant execute on sys.dbms_aqjms to FMW with grant option;
grant execute on sys.dbms_aq to FMW with grant option;
grant execute on utl_file to FMW with grant option;
grant execute on dbms_lock to FMW with grant option;
grant select on sys.V_$INSTANCE to FMW with grant option;
grant select on sys.GV_$INSTANCE to FMW with grant option;
grant select on sys.V_$SESSION to FMW with grant option;
grant select on sys.GV_$SESSION to FMW with grant option;
grant select on dba_scheduler_jobs to FMW with grant option;
grant select on dba_scheduler_job_run_details to FMW with grant option;
grant select on dba_scheduler_running_jobs to FMW with grant option;
grant select on dba_aq_agents to FMW with grant option;
grant execute on sys.DBMS_SHARED_POOL to FMW with grant option;
grant select on dba_2pc_pending to FMW with grant option;
grant select on dba_pending_transactions to FMW with grant option;
grant execute on DBMS_FLASHBACK to FMW with grant option;
grant execute on dbms_crypto to FMW with grant option;
grant execute on DBMS_REPUTIL to FMW with grant option;
grant execute on dbms_job to FMW with grant option;
grant select on pending_trans$ to FMW with grant option;
grant select on dba_scheduler_job_classes to fmw with grant option;
grant select on SYS.DBA_DATA_FILES to FMW with grant option;
grant select on SYS.V_$ASM_DISKGROUP to FMW with grant option;
grant select on v$xatrans$ to FMW with grant option;
grant execute on sys.dbms_system to FMW with grant option;
grant execute on DBMS_SCHEDULER to FMW with grant option;
grant select on dba_data_files to FMW with grant option;
grant execute on UTL_RAW to FMW with grant option;
grant execute on DBMS_XMLDOM to FMW with grant option;
grant execute on DBMS_APPLICATION_INFO to FMW with grant option;
grant execute on DBMS_UTILITY to FMW with grant option;
grant execute on DBMS_SESSION to FMW with grant option;
grant execute on DBMS_METADATA to FMW with grant option;
grant execute on DBMS_XMLGEN to FMW with grant option;
grant execute on DBMS_DATAPUMP to FMW with grant option;
grant execute on DBMS_MVIEW to FMW with grant option;
grant select on ALL_ENCRYPTED_COLUMNS to FMW with grant option;
grant select on dba_queue_subscribers to FMW with grant option;
grant execute on SYS.DBMS_ASSERT to FMW with grant option;

注意:

Oracle Database 11.2.0.3データベース・ユーザーのみ: アップグレードを開始する前に、Oracleパッチ13036331を適用する必要があります。My Oracle Supportにアクセスしてパッチをダウンロードします。

このパッチを適用しない場合は、一部のスキーマで追加の権限を付与する必要があります。

2.9 Oracle WebCenterのアップグレード前のタスクの実行

この項には、12c (12.2.1.1)にアップグレードするOracle WebCenter製品に適用される、アップグレード前のタスクが含まれます。各自の環境に当てはまるタスクのみを実行してください。

Oracle WebCenterのアップグレード前のタスクは、次のとおりです。

アップグレード前のタスク

詳細情報

アップグレードの前に、非推奨または廃止されたコンポーネントをすべて無効化します。

アップグレード前の不要なコンポーネントの無効化

新しいOracleホームにOracle Fusion Middleware 12cのディストリビューションをインストールします。

- インフラストラクチャ(WebLogic ServerおよびJRF)

- WebCenter Portal、Capture、ContentおよびSites
アップグレード対象の製品のみをインストールします。

- Oracle SOA Suite 12cおよびBusiness Process Management (BPM)
WebCenter Content Imagingユーザーのみ: アップグレードを開始する前に、Oracle SOA Suite 12cを11g WebCenter Content Imagingにインストールしたことを確認してください。

WebCenterに必要なOracle Fusion Middlewareのディストリビューションのインストール

12cに必要なWebCenterスキーマを作成します。

これは、11gからアップグレードしている場合にのみ必要です。以前の12cリリースからアップグレードしている場合、このタスクはすでに完了しています。

WebCenter 12cのスキーマの作成

WebCenterのアップグレード可能なスキーマの判別

Oracle WebCenter Contentのアップグレード前のタスクを実行します(ContentまたはWebCenter Content Web UIをアップグレードする場合)。

WebCenter Contentのアップグレード前のタスクの実行

Oracle WebCenter Enterprise Captureのアップグレード前のタスクを実行します(Enterprise Captureをアップグレードする場合)。

Oracle WebCenter Enterprise Captureのアップグレード前のタスクの実行

Oracle WebCenter Portalのアップグレード前のタスクを実行します(WebCenter Portalをアップグレードする場合)。

Oracle WebCenter Portalのアップグレード前のタスクの実行

- アップグレード前の不要なコンポーネントの無効化

- WebCenterのアップグレード可能なスキーマの判別

2.9.1 アップグレード前の不要なコンポーネントの無効化

次のコンポーネントは廃止されたか無効であるため、アップグレードの前に無効化する必要があります。

注意:
これらのコンポーネントを無効化しない場合、アップグレードが失敗し、Content Serverが起動できなくなる可能性があります。

- AppAdapterUniversal

- CIS_Helper

- ContentTrackerReports

- SiteStudioExternalApplications

- FormEditor (非推奨になったFCKEditorを使用しています)

- proxyconnections8

- UrmAgent

- PDFExportConverter (IBR)

詳細は、「コンポーネント・マネージャを使用したコンポーネントの有効化または無効化」を参照してください。

2.9.2 WebCenterのアップグレード可能なスキーマの判別

この表では、12cにアップグレード可能なWebCenterスキーマについて説明します。環境によっては、一部のスキーマを使用しない場合があります。

表2-2 アップグレード可能なWebCenterスキーマ

コンポーネント名

スキーマ

アップグレード前のスキーマ・バージョン

アップグレード後のスキーマ・バージョン

依存関係

Oracle Enterprise Capture

prefix_CAPTURE

11.1.1.8

11.1.1.9

12.2.1.0

12.2.1.1

メタデータ・サービス(_MDS_

CaptureはADFアプリケーションであるため、WebCenterサーバーの起動前にMDSスキーマがアップグレードされている必要があります。

Oracle Platform Security Services (_OPSS)

CaptureはOPSSスキーマを直接使用しませんが、アップグレード・プロセスにOPSSスキーマのアップグレードが含まれている必要があります。

Oracle Portal

prefix_PORTAL

11.1.1.6

12.2.1.0

12.2.1.1

ありません。

WebCenter Portal (以前のWebCenter Spaces)

prefix_WEBCENTER

11.1.1.6

11.1.1.7

12.2.1.0

12.2.1.1

prefix_MDSスキーマを最初にアップグレードする必要があります。

Discussions (WebCenter Suite)

prefix_DISCUSSIONS

11.1.1.7

12.2.1.0

12.2.1.1

ありません。

ディスカッション・クローラ

prefix_DISCUSSIONS_CRAWLER

11.1.1.8

12.2.1.0

12.2.1.1

prefix_DISCUSSIONSスキーマを最初にアップグレードする必要があります。

注意: DISCUSSION_CRAWLERスキーマのパスワードは手動で指定する必要があります。ただし、その他のスキーマのパスワードは自動的に入力されます。

アクティビティ・グラフおよびアナリティクス

prefix_ACTIVITIES

11.1.1.7

12.2.1.0

12.2.1.1

ありません。

ポートレット

prefix_PORTLET

11.1.1.2

12.2.1.0

12.2.1.1

ありません。

Oracle Content Server 11g - 完全

prefix_OCS

11.1.1.6

11.1.1.7

11.1.1.8

11.1.1.9

12.2.1.0

12.2.1.1

ありません。

Oracle WebCenter Sites

prefix_WCSITES

11.1.1.8.0

12.2.1.0

12.2.1.1

ありません。

3 Oracle WebCenterドメインの12c (12.2.1.1)へのアップグレード

この項では、Oracle WebCenterおよびWebCenter Contentの一般的なアップグレード手順について説明します。追加のコンポーネント固有のタスクが必要になる場合があります。

以降の項に記述される手順では、基本的なWebCenterドメインを12c (12.2.1.1)にアップグレードするプロセスの概要を説明しています。ほとんどの場合、アップグレードではこれらの一般的な手順に従いますが、実際に実行するアップグレード手順は、アップグレードするコンポーネントによって異なります。コンポーネントに関連して、アップグレードの前後に追加の手順を実行することが必要になる場合があります。そのため、ドメインのアップグレードを行うには、アップグレード前の環境に存在するコンポーネントごとにアップグレード手順を確認する必要があります。

たとえば、Oracle WebCenterドメインにOracle WebCenter ContentとWebCenter Portalが含まれている場合は、「Oracle WebCenter Contentの12cへのアップグレード」と「Oracle WebCenter Portal 11gインストールのアップグレード」で説明している手順に従う必要があります。

表3-1 標準的なアップグレード手順

手順

タスク

1

WebCenterに必要なOracle Fusion Middlewareのディストリビューションのインストール

2

WebCenter 12cのスキーマの作成

3

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

オプション

アップグレード手順を開始する前に、アップグレード前の準備状況チェックを実行することをお薦めします。

4

Upgrade Assistantを使用したスキーマのアップグレード

5

再構成ウィザードを使用したWebCenterドメインの再構成

6

アップグレード・アシスタントを使用したコンポーネント構成のアップグレード

7

アップグレード後の構成タスクの実行

- WebCenterに必要なOracle Fusion Middlewareのディストリビューションのインストール

- WebCenter 12cのスキーマの作成

- アップグレード前の準備状況チェックの実行
アップグレード・アシスタントを-readinessモードで実行すると、実際にアップグレードを実行する前にアップグレードの潜在的な問題を特定できます。

- Upgrade Assistantを使用したスキーマのアップグレード

- 再構成ウィザードを使用したWebCenterドメインの再構成

- アップグレード・アシスタントを使用したコンポーネント構成のアップグレード

- アップグレード後の構成タスクの実行

3.1 WebCenterに必要なOracle Fusion Middlewareのディストリビューションのインストール

WebCenter 12cへのアップグレードを実行する前に、次のFusion Middlewareディストリビューションを既存の11gドメインにインストールする(ただし構成しない)必要があります。

ディストリビューション

インストレーション・ガイド

Oracle Fusion Middlewareインフラストラクチャ

Oracle Fusion Middleware Infrastructureのインストールと構成

Oracle WebCenter Content (ContentまたはEnterprise Captureをアップグレードする場合)

Oracle WebCenter Contentのインストールおよび構成

Oracle WebCenter Portal (Portalをアップグレードする場合)

Oracle WebCenter Portalのインストールおよび構成

Oracle SOA SuiteおよびBusiness Process Management

WebCenter Content Imagingのアップグレードのみ: Oracle WebCenter Content Imagingのアップグレードの前に、Oracle SOA Suite 12cをインストールする必要があります。12c SOAのバイナリが存在しない場合、アップグレードは失敗します。

Oracle SOA SuiteおよびBusiness Process Managementのインストールおよび構成

3.2 WebCenter 12cのスキーマの作成

Oracle WebCenterをアップグレードする前に、12cのスキーマ要件を確認します。

- サービス表(_STB)
Oracle Fusion Middleware 12cでは、サービス表(_STB)という新しい必須スキーマが導入されました。このスキーマは、リポジトリ作成ユーティリティ(RCU)の実行時に自動的に作成されます。これは、既存の11gデプロイメントをアップグレードする前に作成されている必要があります。詳細は、「サービス表スキーマの理解」を参照してください。

- Oracle Platform Security Services (_OPSS)
WebCenterはOPSSスキーマを直接使用しませんが、アップグレード・プロセスにOPSSスキーマのアップグレードが含まれている必要があります。11g環境にOracle Platform Security Services (_OPSS)スキーマが存在しない場合は、12c用に作成する必要があります。

- 監査スキーマ(OPSS_AUDIT_VIEWER)
11gでXMLベースのOPSS_AUDITを使用していた場合は、新しい12cのOPSS_AUDIT_VIEWERスキーマを作成しないと、ドメインの再構成が失敗します。

新しいスキーマを作成するには、Oracle Repository Creation Utility (RCU)を使用します。

1. JAVA_HOMEを設定し、JAVA_HOME/binを$PATHに追加します(まだ行っていない場合)。

2. システムの12cORACLE_HOME/oracle_common/binディレクトリにナビゲートします。

3. RCUを起動します。
UNIXオペレーティング・システムの場合:
./rcu

Windowsオペレーティング・システムの場合:
rcu.bat

4. RCUの画面をナビゲートして、サービス表スキーマ(およびその他の必須スキーマ)を作成します。「リポジトリの作成」を選択して、適切なロード・オプションを選択します。

注意: DBA権限を持っていない場合は、「システム・ロードに対するスクリプトの準備」を選択します。

5. 11gスキーマをホストするデータベースの接続詳細を指定します。

6. 「既存の接頭辞の選択」を選択して、11gスキーマの作成に使用した接頭辞を選択します。ドロップダウン・メニューを使用して11gの接頭辞を選択します。

デフォルトでは、共通インフラストラクチャ・サービスのスキーマDEV11G_STBはグレー表示されますが、リポジトリにすでに存在するその他のDEV11Gスキーマとともに、作成および保存されます。

7. リポジトリ作成ユーティリティの残りの画面を実行し、新しいスキーマを作成します。画面について支援が必要な場合は、「ヘルプ」をクリックします。

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

Upgrade Assistantを-readinessモードで実行することにより、実際にアップグレードを実行する前にアップグレードの潜在的な問題を特定できます。

準備状況チェックは、既存のドメインまたはデータベース・スキーマをスキャンし、スキャンの結果が記載されたテキスト・ファイルを生成する読取り専用操作です。アップグレード前の環境に問題がある場合、アップグレードする前にこれらの問題を修正してから、準備状況チェックを再実行できます。

デフォルトでは、準備状況チェック・レポートのファイルはOracle 12cディレクトリのORACLE_HOME/oracle_common/upgrade/logsに配置されます。

注意:
準備状況チェックは、システムがオンライン中に実行できます。チェックの複雑さによっては、準備状況チェックが終わるまでにしばらく時間がかかります。パフォーマンスの低下を回避するために、準備状況チェックは低速使用時に実行することをお薦めします。

アップグレード前の環境に対して準備状況チェックを実行するには、-readinessモードでアップグレード・アシスタントを起動します。

1. binディレクトリに移動します。
UNIXオペレーティング・システムの場合:

ORACLE_HOME/oracle_common/upgrade/bin

Windowsオペレーティング・システムの場合:

ORACLE_HOME\oracle_common\upgrade\bin

2. 次のコマンドを入力してアップグレード・アシスタントを起動します。
UNIXオペレーティング・システムの場合:

./ua -readiness

Windowsオペレーティング・システムの場合:

ua.bat -readiness

次のUNIXの例に示すように、ロギング・パラメータを使用してアップグレード・アシスタントを起動することもできます。

./ua [-logLevel <log_level] [-logDir <log_directory>]

ロギング・レベル。次のいずれかを選択します。

- TRACE

- NOTIFICATION

- WARNING

- ERROR

- INCIDENT_ERROR

デフォルトのロギング・レベルはNOTIFICATIONです。

トラブルシューティングする場合、-logLevelをTRACEに設定すると、より多くの情報がロギングされます。-logLevel TRACEが使用されると、Upgrade Assistantのログ・ファイルは非常に大きくなる可能性があるため、別の情報が必要ない場合は、logLevelを変更してください。

注意:
サービス表スキーマを作成していない場合、エラー・メッセージ「UPGAST-00328 : スキーマ・バージョン・レジストリ表がこのデータベースに存在しません。」が発生することがあります。これが発生した場合は、アップグレード・アシスタントを起動するために、サービス表スキーマを作成する必要があります。
これが発生した場合は、リポジトリ作成ユーティリティ(RCU)を使用して、12cの必須スキーマを作成する必要があります。

表3-2 Upgrade Assistant画面: 準備状況チェック

画面

画面が表示されるタイミング

説明

ようこそ

常に表示。

この画面には、準備状況チェックの概要が示されます。

準備状況チェック・タイプ:

- 個別に選択されたスキーマ

- ドメイン・ベース

常に表示。

準備状況チェックは、サポートされるアップグレードの開始点にあるスキーマまたはコンポーネント構成に対してのみ実行されます。次の2つのオプションがあります。次にこれらのオプションについて説明します。

- 「個別に選択されたスキーマ」オプションを使用すると、アップグレードする前に確認するスキーマを選択できます。

- 「ドメイン・ベース」オプションを使用して、ドメインごとに準備状況チェックが実行されるようにします。

使用可能なコンポーネント

「個別に選択されたスキーマ」が選択されている場合。

この画面には、スキーマが選択される使用可能なコンポーネントがリストされます。ここで何かを選択すると、そのコンポーネントのスキーマに対して準備状況チェックが実行されます。

すべてのスキーマのコンポーネント・リスト

スキーマの準備状況チェックが実行されるたび。

この画面は、スキーマの準備状況チェックが実行されるたびに表示されます。これは、「すべてのスキーマのチェックを含める」オプションを使用して「個別に選択されたスキーマ」または「ドメイン・ベース」を選択する場合です。

スキーマ資格証明

常に表示。

この画面を使用して、選択したスキーマとそのスキーマをホストするデータベースへの接続に必要な情報を入力します。アップグレードするスキーマが以前のFusion MiddlewareのリリースでRCUによって作成された場合は、使用可能なスキーマ名がリストされたドロップダウン・メニューが表示されます。

DBAユーザー名: アップグレード・アシスタントをSYSDBAではなくFMWとして実行することをお薦めします。FMWユーザーを作成していない場合は、「アップグレード・アシスタントを実行するための非SYSDBAユーザーの作成」を参照してください。

準備状況サマリー

常に表示。

この画面には、選択に基づいて実行される準備状況チェックの概要が示されます。

Upgrade Assistantを-response (またはサイレント)モードで再実行する場合は、「レスポンス・ファイルの保存」をクリックします。

準備状況チェック

常に表示。

この画面には、準備状況チェックの現在のステータスが表示されます。チェック対象として選択した内容によっては、このプロセスには数分かかる場合があります。

詳細レポートを表示するには、準備状況レポートのレビューをクリックします。このボタンは、準備状況チェックがすべて完了した後のみ表示されます。

注意:
パフォーマンスの低下を回避するには、準備状況チェックをオフピーク時に実行することを検討してください。

準備状況成功

準備状況チェックが正常に完了した場合。

これで、完全なレポートをレビューできるようになります。

準備状況チェックで問題またはエラーが発生した場合、ログ・ファイルをレビューして問題を特定し、問題を修正してから、準備状況チェックを再開してください。

デフォルトでは、準備状況チェック・レポートのファイルは次のOracle 12cディレクトリに配置されます。

ORACLE_HOME/oracle_common/upgrade/logs

3.4 Upgrade Assistantを使用したスキーマのアップグレード

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

アップグレード・アシスタントを起動するには、次の手順を実行します。

1. ディレクトリを、UNIXオペレーティング・システムではORACLE_HOME/oracle_common/upgrade/binに、Windowsオペレーティング・システムではORACLE_HOME\oracle_common\upgrade\binに変更します。

2. 次のコマンドを入力してアップグレード・アシスタントを起動します。

UNIXオペレーティング・システムの場合:

./ua

Windowsオペレーティング・システムの場合:

ua.bat

Upgrade Assistantの各画面で必要な情報を指定します。

注意:
表示される画面は、選択するアップグレード・オプションによって異なります。次の表に示す画面は、参照にのみ使用します。

画面

説明

アップグレードのオプション

スキーマをアップグレードする際、「個別に選択されたスキーマ」または「ドメインで使用されるすべてのスキーマ」を選択できます。

「個別に選択されたスキーマ」は、このバージョンのFusion Middlewareにアップグレードできないスキーマまたは現時点ではアップグレードしないスキーマをドメインで使用している場合にのみ選択してください。

コンポーネント・リスト

UAはドメイン・ディレクトリにインストールされている製品を自動的に検出します。

コンポーネント・リストは、ドメインに現在何がデプロイされているかによって異なります。

前提条件

内容を読んで各オプションを選択してから続行します。

アップグレード・アシスタントは前提条件が満たされているかどうかを検証しないことに注意してください。

スキーマ資格証明

スキーマの接続詳細を指定します。アップグレードするスキーマに対して正しいスキーマ接頭辞を使用してください。

調査

調査フェーズでは、コンポーネントのバージョンをスキャンして、アップグレードが必要かどうかを判別します。

アップグレード・サマリー

サマリーを確認してから「アップグレード」をクリックし、実際のアップグレード・プロセスを開始します。

アップグレードの進行状況

この画面でアップグレードの進行状況をモニターします。

アップグレードの終了

この画面にはアップグレード・ステータス(「成功」または「失敗」)が返されます。なんらかの理由でアップグレードが失敗した場合は、ログ・レポートを確認します。

3.5 再構成ウィザードを使用したWebCenterドメインの再構成

注意:

必要なスキーマがすべて作成されるまで、ドメインの再構成プロセスを開始しないでください。「WebCenter 12cのスキーマの作成」を参照してください。

次の手順を実行して、再構成ウィザードをグラフィカル・モードで起動します。

1. ドメインが存在するシステムにログインします。

コマンド・シェル(UNIXオペレーティング・システムの場合)またはコマンド・プロンプト・ウィンドウ(Windowsオペレーティング・システムの場合)を開きます。

2. 次のディレクトリに移動します。

(UNIX) ORACLE_HOME/oracle_common/common/bin

(Windows) ORACLE_HOME\oracle_common\common\bin

ここで、ORACLE_HOMEは12cのOracleホーム・ディレクトリです。

(UNIX) ./reconfig.sh -log=<log_file> -log_priority=ALL (Windows) reconfig.cmd -log=<log_file> -log_priority=ALL

log_fileは、ドメイン再構成セッション用に作成するログ・ファイルの絶対パスに置き換えます。これは、再構成処理をトラブルシューティングする必要がある場合に役立つことがあります。

パラメータ-log_priority=ALLは、ログを詳細モードで出力します。

reconfig.cmdまたはreconfig.shコマンドを実行すると、デフォルトのキャッシュ・ディレクトリが無効であることを示す次のエラー・メッセージが表示される場合があります。

*sys-package-mgr*: パッケージ・キャッシュ・ディレクトリを作成できません。

環境変数CONFIG_JVM_ARGSを設定することでキャッシュ・ディレクトリを変更できます。次に例を示します。

CONFIG_JVM_ARGS=-Dpython.cachedir= valid_directory

3. 次の表に示すように、再構成の各画面を実行します。

再構成ウィザードには、「再構成ウィザードの画面」にリストされている順序で画面が表示されます。各画面でそれぞれの操作を実行します。次に示す画面は、いくつかが表示されないこともあります。また、使用する環境の設定に基づいた追加の画面を完了する必要がある場合もあります。詳細は、『Oracle WebLogic Serverのアップグレード』のWebLogicドメインの再構成に関する項を参照してください。

再構成の画面:

画面

説明

画面

ドメインの選択

再構成するドメインの場所を指定します。

再構成セットアップの進行状況

再構成のセットアップ・プロセスで、WebLogic Serverのコア・インフラストラクチャが12c用に再構成され、テンプレートが適用され、ビューが作成されて検証されます。

ドメイン・モードおよびJDK

この画面でJDKおよびその他の情報を指定できます(使用するJDKが自動的に移入されない場合)。

データベース構成タイプ

この画面を使用して、prefix_MDSスキーマの11gデータベースの詳細と、新しいprefix_STBスキーマをロードする12cデータベース詳細を指定し、prefix_OCSスキーマとprefix_MDSスキーマが11g環境をポイントしていることを確認します。

JDBCコンポーネント・スキーマ

正しいSTBスキーマ資格証明と11gスキーマ所有者を指定すると、情報が自動移入されます。自動移入された画面で、個々のスキーマ・パスワードを更新する必要があります。

JDBCコンポーネント・スキーマ・テスト

再構成ウィザードは指定された情報を使用して、テスト接続を実行します。

ノード・マネージャ

11gにノード・マネージャ構成は存在しませんでしたが、12cには構成する必要があります。次に示すように、必要な情報を指定します。

再構成の進行状況

ドメインの再構成の進行状況とステータスをモニターします。

3.6 アップグレード・アシスタントを使用したコンポーネント構成のアップグレード

アップグレード・アシスタントを使用して、11gドメインのWebCenterコンポーネントのバイナリの場所を、新しい12cのバイナリをポイントするように更新します。これによって、管理サーバーと管理対象サーバーの起動時に、更新後のバイナリが使用されるようになります。

注意:
必要な構成変更はサーバーの起動時(アップグレード後)にユーザーの介入なしに自動的に実行されるため、Oracle WebCenter Contentをアップグレードする場合はこの手順を実行しないでください。

スキーマをすでにアップグレードした場合は、アップグレード・アシスタントを再度実行してコンポーネント構成をアップグレードします。12cのアップグレード・アシスタントにナビゲートします。

UNIXオペレーティング・システムの場合:

./ua

Windowsオペレーティング・システムの場合:

ua.bat

Upgrade Assistantの各画面で必要な情報を指定します。表示される画面は、選択するアップグレード・オプションによって異なります。

画面

説明

すべての構成

この画面を使用して、11gドメインの場所を指定し、アップグレード・アシスタントが11gドメインのWebCenterバイナリの場所を更新できるようにします。これによって、管理サーバーが起動時に12cのバイナリを取得できるようになります。

11gドメインの場所を指定します。

コンポーネント・リスト

アップグレード・アシスタントはドメインをスキャンして、アップグレードするコンポーネントを識別します。

調査

ドメインのコンポーネントを確認し、アップグレードの必要があるかどうかを判別します。

アップグレード・サマリー

情報を確認して「アップグレード」をクリックします。

アップグレード成功

11gのドメイン構成は12cにアップグレードされました。

3.7 アップグレード後の構成タスクの実行

デプロイメントに含まれるコンポーネントによっては、アップグレード後に追加の構成タスクを実行することが必要になります。

注意:

デプロイメントに次のものが含まれる場合は、追加のアップグレード後のタスクを実行します。

WebCenter Contentのアップグレード後のタスクの実行

Oracle WebCenter Portalのアップグレード後のタスクの実行

- 管理サーバーの起動と停止

- ノード・マネージャの起動と停止

- 管理対象サーバーの起動と停止

- 新規アプリケーションが予期したとおり動作することの確認

3.7.1 管理サーバーの起動と停止

Oracle WebLogic Server管理サーバーは、WLSTコマンドラインまたはスクリプトを使用して起動および停止できます。管理サーバーを起動または停止すると、WebLogic Server管理コンソールやFusion Middleware Controlなど、管理サーバーで実行されているプロセスも起動または停止されます。

たとえば、管理サーバーを起動するには、次のスクリプトを使用します。

DOMAIN_HOME/bin/startWebLogic.sh

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

DOMAIN_HOME/bin/stopWebLogic.sh
username password [admin_url]

3.7.2 ノード・マネージャの起動と停止

ノード・マネージャは、WLSTコマンド行またはスクリプトを使用して起動できます。

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

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

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

3.7.3 管理対象サーバーの起動と停止

Fusion Middleware Controlを使用してWebLogic Server管理対象サーバーを起動または停止するには、次の手順を実行します。

1. ナビゲーション・ペインからドメインを展開します。

2. 管理対象サーバーを選択します。

3. 「WebLogic Server」メニューから、「コントロール」を選択してから、「起動」または「停止」を選択します。

また、サーバーを右クリックして、「コントロール」を選択してから、「起動」または「停止」も選択できます。

スクリプトまたはWLSTを使用して、WebLogic Server管理対象サーバーを起動および停止できます。

たとえば、WebLogic Server管理対象サーバーを起動するには、次のスクリプトを使用します。

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

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

WebLogic Server管理対象サーバーを停止するには、次のスクリプトを使用します。

(UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh
managed_server_name admin_url username password
(Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd
managed_server_name admin_url username password

3.7.4 新規アプリケーションが予期したとおり動作することの確認

すべてのサーバーが正常に起動および停止されたら、コンポーネント・アプリケーションを開き、すべてが予期したとおりに動作していることを確認します。コンポーネント固有の管理者ガイドと開発者ガイドを使用して、アップグレード後の環境の新機能をナビゲートします。

4 Oracle WebCenter Contentの12cへのアップグレード

次の各項では、Oracle WebCenter Contentを、サポートされる11g環境からOracle WebCenter Content 12c (12.2.1.1)環境にアップグレードするプロセスについて説明します。

- Oracle WebCenter Content 12cへのアップグレードの理解

- WebCenter Contentドメインのアップグレードの制約

- WebCenter Contentのアップグレード前のタスクの実行

- Oracle WebCenter Enterprise Captureのアップグレード前のタスクの実行

- Oracle WebCenter Content Imagingのアップグレードの実行

- Oracle WebCenter Contentのアップグレードの実行

- WebCenter Contentのアップグレード後のタスクの実行

4.1 Oracle WebCenter Content 12cへのアップグレードの理解

Oracle WebCenter Contentドメインの12cへのアップグレードには、WebCenter Content、WebCenter Enterprise Capture、WebCenter Content Imaging、およびWebCenter Content Web UIが含まれます。アップグレードするコンポーネントによっては、アップグレードの前後に追加のタスクを実行することが必要になる場合があります。

WebCenter Content 12cの新機能

WebCenter Content 12cでは、すべてのWebCenter ContentおよびCaptureのコンポーネントに対して単一のWebLogic Serverドメインがサポートされるようになりました。ただし、Oracle WebCenter Content - Web UIをホストしているドメインをリリース11gから12cに直接アップグレードすることはできません。既存の11g Web UIドメインを廃止してから、ターゲットのアップグレード済WebCenter Content 12cドメインをWeb UIコンポーネントで拡張する必要があります。

4.2 WebCenter Contentドメインのアップグレードの制約

11gからアップグレードするOracle WebCenter Contentユーザーは、11gドメインでOracle Universal Records Management (URM)が有効化されている場合、12.2.1.1.0にアップグレードできません。アップグレードするには、最初にURMを除外してドメインを再構築する必要があります。URMが有効化されたまま12c (12.2.1.1)へのアップグレードを試行した場合、アップグレードは失敗します。

4.3 WebCenter Contentのアップグレード前のタスクの実行

既存のOracle WebCenter ContentおよびContent Serverの環境をアップグレードする前に、次のタスクを実行する必要があります。

注意:

WebCenter Content固有のタスクを実行する前に、Oracle WebCenterのアップグレード前に必要なタスクをすべて実行する必要があります。「Oracle WebCenterのアップグレード前のタスクの実行」を参照してください。

- 11g (11.1.1.6)インスタンスのアプリケーション名の変更

- WebCenter Content Web UI 11gドメインのアップグレード前のメタデータ・スキーマ(_MDS)のアップグレード
Oracle WebCenter Content Web UI 11gのドメインを12c (12.2.1.1)にアップグレードする場合は、ドメインのアップグレードを開始する前に、_MDSスキーマをアップグレードする必要があります。

- アップグレード前の最新のInbound Refinery (IBR)のインストール

4.3.1 11g (11.1.1.6)インスタンスのアプリケーション名の変更

11gのインスタンスをアップグレードしており、Content Serverのアプリケーション名を変更するためのパッチをまだ適用していない場合、または、サーバーに新しいアプリケーション名をまだ構成していない場合は、ドメインをアップグレードしないでください。アップグレードした場合は、Oracle Universal Content Management - Content Serverのスキーマを見つけることができません。

アップグレードを正常に行い、サーバーを正しく構成するには、アップグレードを開始する前に次のタスクを実行してください。

1. アプリケーション名をOracle Universal Content Management - Content Serverに変更するための修正を含むパッチをインストールします。

2. Content Serverアプリケーションを既存のドメインに再デプロイして、パッチのインストールを確認します。ドメインに既存のContent Serverアプリケーションが存在しない場合は、新しいContent Serverアプリケーションが新しいアプリケーション名で作成されます。これにより、Content Serverのスキーマが確実に見つかります。

4.3.2 WebCenter Content Web UI 11gドメインのアップグレード前のメタデータ・スキーマ(_MDS)のアップグレード

Oracle WebCenter Content Web UI 11gのドメインを12c (12.2.1.1)にアップグレードする場合は、ドメインのアップグレードを開始する前に、_MDSスキーマをアップグレードする必要があります。

注意:

この手順は、WebCenter Content Web UIドメインをリリース11gからリリース12cにアップグレードする場合にのみ必要です。

WebCenter Contentのサーバー・ドメインのみをアップグレードする場合は、「Oracle WebCenterドメインの12c (12.2.1.1)へのアップグレード」を参照してください。

12c (12.2.1.1)のWeb UIには、WebCenter Content 11gとの互換性がありません。Oracle WebCenter Content 12c (12.2.1.1)とアプリケーション開発者フレームワーク(ADF) 12c (12.2.1.1)コンテナを、Web UI 12c (12.2.1.1)とともに使用する必要があります。

アップグレード・アシスタントによって、アップグレードの処理中にドメインから参照されるすべてのスキーマのアップグレードが試行されるため、WebCenter Content Web UI 11gをアップグレードする前に、MDSスキーマのアップグレードが完了している必要があります。MDSスキーマ(WebCenter Contentでは本来使用されない)は、11gの(廃止された)ドメインによる参照のみが行われるため、アップグレード・プロセスによる参照(またはアップグレード)は行われません。WebCenter Contentドメインのアップグレードを開始する前にMDSスキーマをアップグレードすると、アップグレード・アシスタントによって、そのコンテンツもアップグレードされます。

注意:

_MDSをアップグレードしたら、標準の12cアップグレード・プロセス(Oracle WebCenterドメインの12c (12.2.1.1)へのアップグレード)に進みます。アップグレードの後、「WccAdf.earファイルの更新(オプション)」の説明に従ってWccAdf.earファイルを更新し、「WebCenter Content - Web UIを含めるためのOracle WebCenter Contentサーバー・ドメインの構成」の説明に従ってドメインを拡張してWeb UIを含める必要があります。

ディレクトリを、UNIXオペレーティング・システムではORACLE_HOME/oracle_common/upgrade/binに、Windowsオペレーティング・システムではORACLE_HOME\oracle_common\upgrade\binに変更します。

次のコマンドを入力してアップグレード・アシスタントを起動します。

UNIXオペレーティング・システムの場合:

./ua

Windowsオペレーティング・システムの場合:

ua.bat

MDSスキーマをアップグレードするには、アップグレード・アシスタントを起動し、「個別に選択されたスキーマを選択します。

コンポーネント・リストから「Oracle Metadata Services」を選択します。

データベース資格証明、11gのスキーマ所有者名およびパスワードを指定します。

調査フェーズでの処理中に、正しいソース・バージョンがアップグレードされることを確認してください。

正しいソース・バージョンが表示された場合は、アップグレードを続行します。

4.3.3 アップグレード前の最新のInbound Refinery (IBR)のインストール

現在は、古いバージョンのInbound Refinery (IBR)をこのリリースにアップグレードすることはできません。かわりに、最新の12cバージョンのInbound Refineryをインストールして構成し、Oracle WebCenter Contentの12cアップグレード後に新しくインストールしたアプリケーションを使用するように、Content Serverのプロバイダを調整します。

4.4 Oracle WebCenter Enterprise Captureのアップグレード前のタスクの実行

Oracle WebCenter Enterprise Captureをアップグレードする前に、次を確認して該当するすべてのタスクを実行します。

Oracle WebCenter Enterprise Captureのアップグレード前のタスクを完了したら、「Oracle WebCenterドメインの12c (12.2.1.1)へのアップグレード」の項に進みます。

- Oracle WebCenter Enterprise Captureがすでに実行されている、標準(Fusionアプリケーション以外)の環境のみをアップグレードします。

- クラスタ環境内にあるすべてのOracle WebCenter Enterprise Captureシステムを同時にアップグレードします。非依存のOracle WebCenter Enterprise Captureシステムは個別にアップグレードできます。

- 操作を妨げない時間を確認して更新を実行します。
更新の実行中はサービスを利用できません。

- アップグレードの前にOracle WebCenter Enterprise Captureサーバーを停止します。

- バッチ・プロセスが完了し、取得JMSキューが空であることを確認します。

- バッチ・プロセスが完了し取得JMSキューが空であることの確認

4.4.1 バッチ・プロセスが完了し取得JMSキューが空であることの確認

すべてのバッチ処理が完了し、Capture JMS問合せが空であることを確認します。

1. このドメインの管理コンソールを開きます。

http://<AdminServerName>:7001/console

それぞれの意味は次のとおりです。

<AdminServerName> = Captureドメインに関連付けられている管理サーバーの名前またはIPアドレス

7001 = 管理サーバーに関連付けられている通信ポート

2. 左側の「ドメイン構造」ナビゲーション・パネルで、「サービス」を展開します。

3. 「メッセージング」ノードを展開します。

4. ツリー・リストの「JMSサーバー」アイテムを選択します。

5. メイン・パネルの「JMSサーバー」リストで"capture-jms-server"アイテムを選択します。

6. 「監視」タブを選択します。

7. 「監視」サブタブを選択します。

8. 表の「現在のメッセージ数」および「保留メッセージ数」の値が両方とも0になっていることを確認します。

これらの値のいずれかがゼロより大きい場合(保留中のジョブを示します)は、すべてのジョブが処理され、これらのカウンタに"0"が表示されるまで待機してから続行してください。

4.5 Oracle WebCenter Content Imagingのアップグレードの実行

注意:

Oracle WebCenter Content Imaging 11gユーザーは、Imagingのこのリリースにアップグレードしないことをお薦めします。Imagingのすべての機能が使用可能になるのは、今後のリリースです。

WebCenter Content Imagingの機能セットは、独立コンポーネントからプライマリWebCenter Contentサーバーにマージされました。これは、WebCenter製品フットプリントの簡略化と統合への取組みの結果です。他のWebCenterコンポーネントとSOAコンポーネントは12cにアップグレードし、11g Imagingコンポーネントを非依存で実行し続けることもできます。

注意:

これらの変更に関する詳細な説明は、My Oracle SupportドキュメントのWebCenter Imaging & Enterprise Capture 12c Upgrade Guidance To Customers (ドキュメントID 2064485.1)を参照してください。

11g Imaging環境を保持したまま、今すぐ12cに移行する場合は、コア12cドメインをアップグレードし、Imagingコンポーネントをホストするための新しい11gドメインを再構築します。このプロセスの概要を次に示します。

1. 既存の11g環境の完全なバックアップ・コピーを作成します。

2. 新しいOracleホームに、新しく再構築された11g Imaging (IPM)インスタンスを作成します。この新しいホーム(C)に、Imaging (IPM)のみをインストールします。

詳細は、11g WebCenter Content Imagingのインストール・ドキュメントを参照してください。

この新しいインスタンスは元の11g製品ディストリビューションから作成されるため、既存のインスタンス(A)と同等になるようにパッチを適用する必要があります。Opatch inventoryコマンドを使用すると、システムに適用された既存のパッチのリストが表示されます。

この新しく再構築されたドメイン(C)の操作は、既存のImaging and Process Management (IPM)データベース(C)、11g Universal Content Manager (UCM)および11g SOA管理対象サーバー(A)に接続することで確認されます。

3. 元のIPM、UCMおよびSOA 11gドメイン(B)をインプレースでアップグレードし、新しいアップグレード後の12cドメイン(D)を作成します。「Oracle WebCenterドメインの12c (12.2.1.1)へのアップグレード」を参照してください。

Imaging Process Managementは12.2.1では非推奨であるため、IPM構成は12cドメインのアップグレードおよび再構成プロセスの処理中に削除されます(D)。IPM/Viewer JMSサーバーと元のIPMサーバーを手動で削除する必要があります。

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

4. この既存のIPMデータベースはアップグレードの影響を受けないため、接続は引き続きインプレースです(D)。再構築した11g Imagingドメイン(C)を新しい12c管理対象サーバー(E)に接続します。

4.6 Oracle WebCenter Contentのアップグレードの実行

アップグレード前の構成タスクをすべて完了したら、「Oracle WebCenterドメインの12c (12.2.1.1)へのアップグレード」で説明している標準のFusion Middlewareの手順を使用して、WebCenter Contentのドメインをアップグレードできます。

4.7 WebCenter Contentのアップグレード後のタスクの実行

Oracle WebCenter Contentをアップグレードした後に、これらのタスクを実行します。

注意:

これらのアップグレード後のタスクは、「アップグレード後の構成タスクの実行」で説明しているWebCenterの一般的なアップグレード後のタスクに追加で実行する必要があります。

- WebCenter Content - Web UIを含めるためのOracle WebCenter Contentサーバー・ドメインの構成

- アップグレード後のE-Business Suite AXFスキーマの構成
アップグレード後に、AXFスキーマのエンドポイント構成を更新するためのスクリプトを実行する必要があります。

- Oracle WebCenter Content: ImagingのIPM/Viewer JMSサーバーの削除

- Oracle WebCenter Content: ImagingのIPMサーバーの削除

- WccAdf.earファイルの更新(オプション)

- WebCenter Content Web UIのカスタム・スキンの移行

- Oracle WebCenter Content用のOracleアプリケーション・アダプタのアップグレード

- コンテンツ・サーバーでのレコード管理用のレポート・ライブラリの構成

- IBRを監視するためのFusion Middleware Controlの使用方法

- SOAまたはBAMを使用したOracle WebCenter Content Serverの起動

4.7.1 WebCenter Content - Web UIを含めるためのOracle WebCenter Contentサーバー・ドメインの構成

WebCenter Content Web UIコンポーネントを含めるためにアップグレード後のWebCenter Content Serverドメインを拡張する方法は、標準的なWebLogic Serverの構成手順に従っています。

Fusion Middleware構成ウィザードを使用したドメインの拡張の詳細は、「WebLogicドメインの拡張」を参照してください。

構成ウィザードを起動するには、次の手順を実行します。

UNIXオペレーティング・システムの場合:

cd /12c_Oracle_Home/oracle_common/common/bin

./config.sh

Windowsオペレーティング・システムの場合:

cd \12c_Oracle_Home\oracle_common\common\bin

プロンプトが表示されたら、次に示すように、WebCenter Content - Web UI - 12.2.1.1.0テンプレートを選択します。

4.7.2 アップグレード後のE-Business Suite AXFスキーマの構成

アップグレード後に、AXFスキーマのエンドポイント構成を更新するためのスクリプトを実行する必要があります。

アップグレード後に、Oracle E-Business Suite (EBS)ユーザーは、次のスクリプトを実行してE-Business Suite Application Extension Framework (AXF)スキーマのエンドポイントを更新できます。

1. Universal Content Management (Oracle UCM) 12c (12.2.1.1)のインストール・ディレクトリにナビゲートします。
cd /12cOracle_HOME/wccontent/ucm/Distribution/EBSIntegration/R12

2. 次のファイルを、EBS AXFスキーマをホストするデータベースの/binディレクトリにコピーします。
EbsUpdateScript.shおよびEbsUpdateTables.sql

3. /binディレクトリからスクリプトを実行し、プロンプトが表示されたら次の情報を指定します。
"EBSスキーマにAXFユーザー名を入力"

"EBSスキーマにAXFパスワードを入力"

"UCMが実行されているホスト名を入力"

"UCMが実行されているポートを入力"

この情報を指定すると、EBS AXFスキーマが更新されます。

4.7.3 Oracle WebCenter Content: ImagingのIPM/Viewer JMSサーバーの削除

ドメインの再構成の完了後も、コンソールに古いサーバーが表示されます。これらのJMSサーバーはアップグレード後に手動で削除する必要があります。

IPM/Viewer JMSサーバーを削除するには、次の手順を実行します。

1. 新しくアップグレードした管理サーバーのコンソールにログインします。

http://host:port/console

2. コンソールのナビゲーション・パネルから、「メッセージング」をクリックし、「JMSサーバー」を選択します。

3. IpmJmsServerおよびViewerJmsServerで始まるすべてのJMSサーバーを選択して、「削除」をクリックします。

4.7.4 Oracle WebCenter Content: ImagingのIPMサーバーの削除

ドメインの再構成の完了後も、コンソールに古いIPMサーバーが表示されます。これらのサーバーはアップグレード後に手動で削除する必要があります。

IPMサーバーを削除するには、次の手順を実行します。

1. 新しくアップグレードした管理サーバーのコンソールにログインします。

http://host:port/console

2. コンソールのナビゲーション・パネルから、「環境」をクリックし、「サーバー」を選択します。

3. IPMサーバー(IPM_server1)を選択して、「削除」をクリックします。

4.7.5 WccAdf.earファイルの更新(オプション)

ドメインのアップグレード後に、wccadf.earファイルを正しいMDSパーティション詳細(11gのインストール中に指定)に手動で変更できます。

wccadf.earファイルを更新するには、次の11gディレクトリにナビゲートし、WLSTをOFFLINEモードで起動します。

cd /<11g_MW_HOME>/oracle_common/common/bin/wlst.sh

wls:/offline> archive = getMDSArchiveConfig ('/ <12.2.1 wccadf.ear location>')

wls:/offline> archive.setAppMetadataRepository(repository='mds-<mds_repo_name>', partition='<11g_partition_name>', type='DB', jndi='jdbc/mds/<mds_repo_name>')

wls:/offline> archive.save()

次に例を示します。

archive = getMDSArchiveConfig('/12.2.1_Oracle_Home/wccontent/wccadf/WccAdf.ear')
archive.setAppMetadataRepository(repository='mds-WCCUIMDSREPO', partition='11.1.1.9.0_MDS_PARTITION', type='DB', jndi='jdbc/mds/WCCUIMDSREPO')
archive.save()

4.7.6 WebCenter Content Web UIのカスタム・スキンの移行

11gでWebCenter Content - Web UIにカスタム・スキンを適用していた場合は、アップグレード後にカスタム・スキンのJARファイルを新しい12cデプロイメントに移行する必要があります。

1. Oracle WebCenter Content -Web UIアプリケーションを12.2.1デプロイメントからアンインストールします。Oracle Universal Installer (OUI)を-deinstallモードで使用します。

2. 12.2.1のoracle.wcc.adf.skin.customライブラリを削除します。

3. 11gのカスタム・スキンJARファイルoracle.wcc.adf.skin.custom (11.1, 11.1.1.8.1)を、12.2.1の環境にデプロイします。

4. Oracle WebCenter Content - Web UI 12cアプリケーションを再インストールして、新しいカスタム・スキンJARファイルのコンテンツを取得します。

4.7.7 Oracle WebCenter Content用のOracleアプリケーション・アダプタのアップグレード

『Oracle WebCenterアプリケーション・アダプタの管理』で説明されているように、Oracle WebCenter Contentのアプリケーション・アダプタには、それぞれのERPシステム(EBSおよびPeopleSoft)にアダプタをインストールするための手動の手順が含まれています。前のリリースからアップグレードするには、これらのアダプタを再インストールする必要があります。

EBSアダプタを再インストールする手順は次のとおりです。

1. 『Oracle WebCenterアプリケーション・アダプタの管理』のOracle E-Business Suite Formsのコンパイルに関する項に記述されている手順を実行して、AXF_CUSTOM.PLLモジュールをアップグレードします。

2. SSL用に構成する場合は、『Oracle WebCenterアプリケーション・アダプタの管理』のSSL用の統合の構成についての説明に記載されている手順に従います。

PeopleSoftプロジェクトを再インポートするには、『Oracle WebCenterアプリケーション・アダプタの管理』のOracle PeopleSoftプロジェクトのインポートに関する項に記述されている手順(手順1 - 6)を実行します。

4.7.8 コンテンツ・サーバーでのレコード管理用のレポート・ライブラリの構成

コンテンツ・サーバーでレコード管理機能を構成する場合は、WebCenter Content管理対象サーバーを含むドメインを作成した後、最初に起動する前に、レコード管理のためのレポート・ライブラリを構成する必要があります。このライブラリがない場合は、テンプレートをコンテンツ・サーバーにチェックインできません。

レコード管理用のレポート・ライブラリの構成の詳細は、『Oracle WebCenter Contentのインストールと構成』のContent Serverでのレコード管理用のレポート・ライブラリの構成に関する項を参照してください。

4.7.9 IBRを監視するためのFusion Middleware Controlの使用方法

Inbound Refinery (IBR)を使用している場合は、ドメインを拡張して、IBRテンプレートにOracle Enterprise Managerプラグインを使用し、Enterprise Manager Fusion Middleware ControlでIBRをモニターするようにします。

注意:
Inbound Refinery (IBR) 11gは12cにアップグレードできません。12c環境で使用するための新しいIBRをインストールする必要があります。

次の手順は、IBRテンプレート用Oracle Enterprise Managerプラグインを含めるためにドメインを拡張する方法を説明しています。

1. ECM_Home/common/bin/に移動します。

2. config.shを実行します。

./config.sh

3. 「既存のWebLogicドメインの拡張」を選択します。

4. 拡張するドメインを選択します。

5. 次の画面で、IBR用のOracle Enterprise Managerプラグインを選択します。

6. 「拡張」をクリックして、IBRテンプレートでドメインを拡張します。

4.7.10 SOAまたはBAMを使用したOracle WebCenter Content Serverの起動

WebCenter ContentがOracle SOAまたはOracle Business Activity Monitoring (BAM)と統合されている場合、Oracle WebCenter ContentまたはOracle Inbound Refinery (IBR)を起動する前に、SOAやBAMを起動しておく必要があります。

Fusion Middleware ControlからのWebCenter Contentサーバーの起動の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』のOracle WebCenter Contentのスタート･ガイドを参照してください。

Oracle SOAまたはBAMサーバーを起動する前にWebCenter ContentまたはIBRを起動しようとすると、次のエラーが表示されます。

oracle.wsm.policymanager.PolicyManagerException:
WSM-02120 : Unable to connect to the policy access service.

5 Oracle WebCenter Portalの11gから12cへのアップグレード

既存のOracle WebCenter Portal 11.1.1.7.0、11.1.1.8.0、11.1.1.9.0インストールをリリース12.2.1.1.0にアップグレードできます。

注意:

この章の内容は次のとおりです。

注意:

Oracle WebCenter Portal 12.2.1からリリース12.2.1.1にパッチ適用するには、「Oracle WebCenterのアップグレード・プロセス・フローの理解」で説明している一般的なアップグレード手順に従います。リリース12.2.1.1に移行するための、WebCenter Portalに固有のアップグレード前後のタスクはありません。

この章では、「Oracle WebCenterのアップグレード手順の理解」にリストされている、WebCenter Portal 11gに固有のアップグレード手順について説明します。手順は「Oracle WebCenterのアップグレード手順の理解」にリストされている順序に従って実行してください。また、この章にリストされているアップグレード・タスクを実行する前に、必須の一般的な手順を実行したことを確認してください。

- Oracle WebCenter Portalのアップグレード前のタスクの実行

- Oracle WebCenter Portal 11gインストールのアップグレード

- Oracle WebCenter Portalのアップグレード後のタスクの実行

- 非推奨機能のアップグレードによる影響の理解

- Oracle WebCenter Portalのアップグレードに関する問題のトラブルシューティング

5.1 Oracle WebCenter Portalのアップグレード前のタスクの実行

既存のOracle WebCenter Portal環境をアップグレードする前に、次のタスクを実行します。

- OIDが起動し実行中であることの確認

- ポートレット・プロデューサ・アプリケーションのメタデータのエクスポート

- OmniPortletおよびWebクリッピング構成の保存

- ポータル・フレームワーク・アプリケーションの移行

5.1.1 OIDが起動し実行中であることの確認

WebCenter Portal環境でOIDベースのポリシー・ストアを使用している場合は、Oracle Internet Directory (OID)が起動し実行中であることを確認します。

5.1.2 ポートレット・プロデューサ・アプリケーションのメタデータのエクスポート

Oracle WebCenter Portal 11gには、OmniPortlet、Webクリッピング、WSRPパラメータ・フォーム・ポートレット、サンプルWSRPポートレット・プロデューサ、およびサンプルPDK-Javaポートレット・プロデューサなどの、様々な事前構成済ポートレット・プロデューサが用意されています。11gのポートレット・プロデューサ・アプリケーションのカスタマイズ内容またはメタデータを移行するには、Oracle WebCenter Portalをアップグレードする前に、11gのアプリケーションからデータをエクスポートする必要があります。その後、アップグレード後のインスタンスに、これらのカスタマイズ内容をインポートしてポートレット・プロデューサ・アプリケーションに戻します。

exportPortletClientMetadata WLSTコマンドを使用して、プロデューサ・メタデータをEARファイルにエクスポートできます。詳細は、『WebCenter WLSTコマンド・リファレンス』のexportPortletClientMetadataに関する項を参照してください。

5.1.3 OmniPortletおよびWebクリッピング構成の保存

11gのOracle WebCenter PortalインスタンスにWebクリッピングとOmniPortletsポートレットが含まれている場合は、WebCenter Portalのインスタンスをアップグレードする前に、それらのHTTPプロキシ・エントリのコピーを保存します。

1. 11gドメインの次の場所にある、provider.xmlファイルにナビゲートします。

Webクリッピング: 11g_DOMAIN_HOME/servers/WC_Portlet/tmp/_WL_user/portalTools_11.1.1.x.0/randomly_generated_directory/war/WEB-INF/providers/webClipping/provider.xml

OmniPortlet: 11g_DOMAIN_HOME/servers/WC_Portlet/tmp/_WL_user/portalTools_11.1.1.x.0/randomly_generated_directory/war/WEB-INF/providers/omniPortlet/provider.xml

2. 11gのprovider.xmlから、WebクリッピングとomniPortletのHTTPプロキシ・エントリをコピーします。次に例を示します。

<proxyInfo class="oracle.portal.provider.v2.ProxyInformation">
<httpProxyHost>proxy.example.com</httpProxyHost>
<httpProxyPort>80</httpProxyPort>
<dontProxyFor>*.example.com</dontProxyFor>
</proxyInfo>

これらのエントリを、アップグレード後のWebCenter Portalインスタンスのprovider.xmlファイルに追加する必要があります。

5.1.4 ポータル・フレームワーク・アプリケーションの移行

注意:
このアップグレード前のタスクは、11.1.1.6.0、11.1.1.7.0、11.1.1.8.x、または11.1.1.9.xのポートレット・フレームワーク・アプリケーションをWebCenter Portal 12cに移行する場合に適用されます。

Oracle WebCenter Portal 11gは、ポータル・フレーム・アプリケーション(以前はカスタム・ポータル・アプリケーションと呼ばれていた)をJDeveloperで作成およびデプロイするための、ポータル・フレームワーク・テクノロジをサポートしています。WebCenter Portal 12cリリースでは、ポータル・フレームワーク・テクノロジを使用できません。オラクル社では、ポータル・フレームワーク・アプリケーションをWebCenter Portalに移行するためのサポートを提供しています。このサポートは、アプリケーションをリリース11.1.1.6.0、11.1.1.7.0、11.1.1.8.x、または11.1.1.9.xから移行する場合に利用できます。移行後のアプリケーションは、WebCenter Portal 12cではポートレットとして使用できます。

ポータル・フレームワーク・アプリケーションをWebCenter Portal 12cに移行するには、最初に既存の環境にパッチを適用(Oracle WebCenter Portal 11.1.1.9.0用の最新パッチまで)してから、アプリケーションをリリース11.1.1.9.xに移行する必要があります。詳細は、『Oracle WebCenter Portalの管理』のポータル・フレームワーク・アプリケーションのWebCenter Portalへの移行に関する項を参照してください。パッチをWebCenter Portalリリース11.1.1.9.xまで適用したら、「Oracle WebCenterのアップグレード手順の理解」の説明に従って、リリース12cにアップグレードできます。

5.2 Oracle WebCenter Portal 11gインストールのアップグレード

次の表では、Oracle WebCenter Portal 11gを12cにアップグレードするために必要なタスクについて説明します。

注意:
Oracle WebCenter Portal 11gでは、管理対象サーバーのデフォルトの名前は、WC_Spaces、WC_Portlet、WC_Collaboration、およびWC_Utilitiesです。Oracle WebCenter Portal 12cのフレッシュ・インストールでは、AnalyticsをホストしていたWC_Utilitiesは非推奨になり、これはWC_PortalによってWC_Spacesに置き換わり、Analyticsをホストします。Oracle WebCenter Portal 11gから12cにアップグレードする際に、管理対象サーバーのデフォルトの名前は変更されません。また、AnalyticsはWC_Utilities管理対象サーバー上にデプロイされたままになります。

表5-1 Oracle WebCenter Portal 11gからのアップグレード

手順

説明

詳細情報

ノード・マネージャが設定されており、管理対象サーバーを管理コンソールから起動できる場合は、upgradeWebCenterPortal WLSTコマンドを実行します

upgradeWebCenterPortal WLSTコマンドを実行して、メタデータをMDSからDBに移動し、セキュリティ権限をアップグレードします。

upgradeWebCenterPortal WLSTコマンドの実行

ノード・マネージャが設定されていない場合:

- Folders_gベースのContent Serverを使用するように構成されているリリース11.1.1.7.0または11.1.1.8.0からアップグレードする場合は、FrameworkFoldersに移行し、upgradeWebCenterPortal WLSTコマンドを実行します

- Content Serverが構成されていない11.1.1.7.0または11.1.1.8.0からアップグレードする場合、またはFrameworkFoldersベースのContent Serverを使用しているリリース11.1.1.8.3+からアップグレードする場合は、upgradeWebCenterPortal WLSTコマンドを実行します

WebCenter PortalをFolders_gからFrameworkFoldersに移行してから、upgradeWebCenterPortal WLSTコマンドを実行するようにしてください。

- 『Oracle WebCenter Portalの管理』のFrameworkFoldersへのFolders_gの移行に関する項

- upgradeWebCenterPortal WLSTコマンドの実行

アップグレード・メトリックにアクセスします

オプション。

Oracle WebCenter Portalのアップグレード・メトリックにアクセスして、アップグレードのパフォーマンスを分析します。これは、サーバーを再起動する前に実行する必要があります。

アップグレード・メトリックへのアクセス

Content Serverで追加のコンポーネントを有効化し、サーバーを再起動します

Content Serverで、AutoSuggestConfig、DynamicConverter、およびImagingなどの追加のコンポーネントを有効化します。Site Studioが構成されている場合は、PortalVCRHelperを有効化します。次に、Content Serverを再起動します。

コンポーネント・マネージャを使用したコンポーネントの有効化または無効化

管理サーバーとすべての管理対象サーバーを再起動します

Oracle Fusion Middleware環境を開始します。これには、Oracle WebLogic Server、ノード・マネージャ、管理サーバー、管理対象サーバー、OPMN、およびすべてのシステム・コンポーネントの起動が含まれマシ。

アップグレード後の構成タスクの実行

listDeprecatedFeaturesUsage WLSTコマンドを実行して、アップグレード監査ツールを実行します

listDeprecatedFeaturesUsage WLSTコマンドを実行してアップグレード監査ツールを実行し、アップグレード後のWebCenter Portal 12cインストールに存在する非推奨機能のリストを表示します。

アップグレード監査ツールの実行

- upgradeWebCenterPortal WLSTコマンドの実行

- アップグレード監査ツールの実行

- アップグレード・メトリックへのアクセス

5.2.1 upgradeWebCenterPortal WLSTコマンドの実行

upgradeWebCenterPortal WLSTコマンドを実行して、メタデータをMDSからデータベースに移動し、アップグレード後のOracle WebCenter Portal 11gのセキュリティ権限をアップグレードします。

upgradeWebCenterPortal WLSTコマンドを実行するには、次の手順を実行します。

1. 次のように、WebCenter Portal Oracleホーム・ディレクトリに移動してWLSTスクリプトを起動します。

(UNIX) ORACLE_HOME/common/bin/wlst.sh

(Windows) ORACLE_HOME\common\bin\wlst.cmd

2. WLSTコマンド・プロンプトで、次のコマンドを入力してOracle WebCenter Portalの管理サーバーに接続します。

wls:/offline>connect('user_name','password', 'host_name:port_number')

それぞれの意味は次のとおりです。

- user_nameは、管理サーバーに接続しているオペレータのユーザー名です。

- passwordは、管理サーバーに接続しているオペレータのパスワードです。

- host_nameは、管理サーバーのホスト名です。

- port_numberは、管理サーバーのポート番号です。

次に例を示します。

connect(username='weblogic', password='mypassword', url='myhost.example.com:7001')

このコマンドのヘルプについては、WLSTコマンド・プロンプトでhelp('connect')と入力してください。

3. upgradeWebCenterPortal WLSTコマンドを実行します。コマンド構文の詳細は、『WebCenter WLSTコマンド・リファレンス』のupgradeWebCenterPortalに関する項を参照してください。表示されるメッセージと生成されるレポートの詳細は、「upgradeWebCenterPortal WLSTコマンドによって生成される出力」を参照してください。

- upgradeWebCenterPortal WLSTコマンドによって生成される出力

5.2.1.1 upgradeWebCenterPortal WLSTコマンドによって生成される出力

upgradeWebCenterPortal WLSTコマンドでは、次のレポートが生成されます。

- UpgradeSummary.txt: アップグレードが試行され成功および失敗したポータルまたはポータル・テンプレートの合計数がリストされます。

- UpgradeDetails.txt: 各ポータルのアップグレードの詳細情報が表示され、ページ数、リソース・カタログ、アップグレードされたナビゲーションなどの詳細がリストされます。ポータルに対してレポートされたアップグレード・エラーの詳細も表示されます。

- UpgradeDiagnostic.log: upgradeWebCenterPortal WLSTコマンドの診断情報が表示されます。

upgradeWebCenterPortalを実行するたびに、前回の実行以降の詳細が追加され、レポートが更新されます。いずれかの手順でレポートされたアップグレード・エラーがある場合は、エラーを修正し、upgradeWebCenterPortalを再度実行します。upgradeWebCenterPortalによってポータルまたはポータル・テンプレートに対するアップグレード試行の失敗がレポートされなくなると、アップグレード・プロセスは完了したと見なされ、最後の出力に「WebCenter Portalアプリケーションのアップグレードが完了しました。」というメッセージが表示されます。

アップグレードに関する問題のトラブルシューティングの詳細は、「Oracle WebCenter Portalのアップグレードに関する問題のトラブルシューティング」を参照してください。

サンプル・コマンド1

upgradeWebCenterPortal WLSTコマンドを実行する際に、要件に応じたパラメータを指定できます。

たとえば、次のコマンドは、メタデータをMDSからDBに移動してセキュリティ権限をアップグレードします。

upgradeWebCenterPortal(appName='webcenter', server='WC_Spaces', migrationDirectory='/scratch/upgrade_log')

このコマンドを実行したときに表示されるメッセージの例を次に示します。

Starting WebCenter Portal application upgrade.
Already in Domain Runtime Tree

To effect connection changes, you must restart the managed server on which the WebCenter application is deployed.
If you have set adminPassword, keystorePassword, or privateKeyPassword in your content server connection, then set the values again in the underlying RIDC connection. Do this by running setContentServerConnection and specifying the values, if applicable.

Starting data migration from MDS to database...

[TRACE]: Upgrade may take some time to complete depending on the number of portals and pages in your Oracle WebCenter Portal installation. To monitor the upgrade progress, refer to the diagnostic log file WC_Portal-diagnostic.log at the location "/scratch/software/user_projects/domains/base_domain/servers/WC_Spaces/logs".

#######################################################
Upgrade Run: 1
#######################################################
Upgrade of 44 Portals/Portal Templates attempted.
Upgrade of 44 Portals/Portal Templates succeeded.
Upgrade of 0 Portals/Portal Templates failed.

Data migration from MDS to database is successfully completed.

Policy URI For Authenticated Access: oracle/wss10_saml_token_service_policy

Already in Domain Runtime Tree

Command FAILED, Reason: JPS-04207: Matching Grantee not found: [GranteeEntry: codeSource=file:${common.components.home}/modules/oracle.wsm.agent.common_11.1.1/wsm-agent-core.jar principals=[]].

Already in Domain Runtime Tree

Command FAILED, Reason: JPS-04201: Cannot grant permission(s). Grant already exists for grantee [GranteeEntry: codeSource=null principals=[[AppRole: appID=webcenter name=s5f9c65ed_c93c_4467_96cf_06a82f3dad22#-#Spaces-User displayName=null description=null category=null uniquename=cn=s5f9c65ed_c93c_4467_96cf_06a82f3dad22\#-\#Spaces-User,cn=Roles,cn=webcenter,cn=opssSecurityStore,cn=JPSContext,cn=opssRoot guid=108CDE506D8A11E5BFE5CF1BB12B2942 members=[] classname=oracle.security.jps.service.policystore.ApplicationRole type=JPS_APPLICATION_ROLE]]].

Starting upgrade for portal roles...
Upgrade of the portal roles is complete.

Permissions upgrade completed with warnings

WebCenter Portal application upgrade is complete.

注意:

upgradeWebCenterPermissions WLSTコマンドを実行すると、権限がすでに存在する特定のエラー・メッセージが表示されます。次に例を示します。

Already in Domain Runtime Tree

Command FAILED, Reason: JPS-04201: Cannot grant permission(s). Grant already exists for grantee [GranteeEntry: codeSource=null principals=[[AppRole: appID=webcenter name=s5f9c65ed_c93c_4467_96cf_06a82f3dad22#-#Spaces-User displayName=null description=null category=null uniquename=cn=s5f9c65ed_c93c_4467_96cf_06a82f3dad22\#-\#Spaces-User,cn=Roles,cn=webcenter,cn=opssSecurityStore,cn=JPSContext,cn=opssRoot guid=108CDE506D8A11E5BFE5CF1BB12B2942 members=[] classname=oracle.security.jps.service.policystore.ApplicationRole type=JPS_APPLICATION_ROLE]]].

そのようなエラー・メッセージによる機能への影響はありません。エラー・メッセージを無視しても問題なく、WebCenter Portalインスタンスのアップグレードを続行できます。

サンプル・コマンド2

次のサンプル・コマンドは、Content Serverを使用するように構成されたWebCenter Portalをアップグレードします。

upgradeWebCenterPortal(appName='webcenter', server='WC_Spaces', migrationDirectory='/scratch/upgrade_log', contentServerName='UCM_server1', contentDbConnectionUrl='wccdbhost:wccdbport:wccdbsid',contentDbUserName='DEV_OCS')

このコマンドを実行したときに表示されるメッセージの例を次に示します。

Starting WebCenter Portal application upgrade.

Restarting Content Server to verify whether the Node Manager is configured properly.
Already in Domain Runtime Tree

Shutting down the server UCM_server1 with force=true while connected to AdminServer ...
.
Starting server UCM_server1 .............................................................................
Server with name UCM_server1 started successfully

Already in Domain Runtime Tree

Enter the password for OCS Schema owner : XXXXX

Starting migration to FrameworkFolders.

Starting export of Folders_g data.
Already in Domain Runtime Tree

Export of Folders_g data is complete.

Starting migration of WebCenter Content Server to FrameworkFolders.

Enabling 'FrameworkFolders' server components.
Already in Domain Runtime Tree

Enabling 'FrameworkFolders' server components is complete.

Starting update of Content Server general configuration.
Already in Domain Runtime Tree

Updating Content Server general configuration is complete.

Restarting Content Server.
Already in Domain Runtime Tree

Shutting down the server UCM_server1 with force=true while connected to AdminServer ...
..
Starting server UCM_server1 .............................................................................................
Server with name UCM_server1 started successfully

Restarting Content Server is complete.

Migration of 'PersonalSpaces' folder and content from Folders_g to the FrameworkFolders data structure started.
Already in Domain Runtime Tree

Migration of 'PersonalSpaces' folder and content from Folders_g to the FrameworkFolders data structure is complete.
Already in Domain Runtime Tree

Migration of 'WebCenterSpaces-Root' folder and content from Folders_g to the FrameworkFolders data structure started.
Already in Domain Runtime Tree

Migration of 'WebCenterSpaces-Root' folder and content from Folders_g to the FrameworkFolders data structure is complete.

Starting update of Content Server general configuration.
Already in Domain Runtime Tree

Updating Content Server general configuration is complete.

Restarting Content Server.
Already in Domain Runtime Tree

Shutting down the server UCM_server1 with force=true while connected to AdminServer ...
..
Starting server UCM_server1 ..................................................................
Server with name UCM_server1 started successfully

WebCenter Content Server migration to FrameworkFolders is complete.

Starting migration of WebCenter Portal data to FrameworkFolders.
Already in Domain Runtime Tree

Migration of WebCenter Portal data to FrameworkFolders is complete.
Already in Domain Runtime Tree

Shutting down the server UCM_server1 with force=true while connected to AdminServer ...
...
Starting server UCM_server1 ........................................................................................
Server with name UCM_server1 started successfully

Already in Domain Runtime Tree

Shutting down the server WC_Portal with force=true while connected to AdminServer ...
.....
Starting server WC_Spaces .........................................................................................................................................................................................................
Server with name WC_Spaces started successfully

Migration to FrameworkFolders is complete.

Starting WebCenter Portal application upgrade.
Already in Domain Runtime Tree

To effect connection changes, you must restart the managed server on which the WebCenter application is deployed.
If you have set adminPassword, keystorePassword, or privateKeyPassword in your content server connection, then set the values again in the underlying RIDC connection. Do this by running setContentServerConnection and specifying the values, if applicable.

Starting data migration from MDS to database...

[TRACE]: Upgrade may take some time to complete depending on the number of portals and pages in your Oracle WebCenter Portal installation. To monitor the upgrade progress, refer to the diagnostic log file WC_Portal-diagnostic.log at the location "/scratch/software/user_projects/domains/base_domain/servers/WC_Spaces/logs".

#######################################################
Upgrade Run: 1
#######################################################
Upgrade of 44 Portals/Portal Templates attempted.
Upgrade of 44 Portals/Portal Templates succeeded.
Upgrade of 0 Portals/Portal Templates failed.

Data migration from MDS to database is successfully completed.

Policy URI For Authenticated Access: oracle/wss10_saml_token_service_policy

Already in Domain Runtime Tree

Command FAILED, Reason: JPS-04207: Matching Grantee not found: [GranteeEntry: codeSource=file:${common.components.home}/modules/oracle.wsm.agent.common_11.1.1/wsm-agent-core.jar principals=[]].

Already in Domain Runtime Tree

Command FAILED, Reason: JPS-04201: Cannot grant permission(s). Grant already exists for grantee [GranteeEntry: codeSource=null principals=[[AppRole: appID=webcenter name=s5f9c65ed_c93c_4467_96cf_06a82f3dad22#-#Spaces-User displayName=null description=null category=null uniquename=cn=s5f9c65ed_c93c_4467_96cf_06a82f3dad22\#-\#Spaces-User,cn=Roles,cn=webcenter,cn=opssSecurityStore,cn=JPSContext,cn=opssRoot guid=108CDE506D8A11E5BFE5CF1BB12B2942 members=[] classname=oracle.security.jps.service.policystore.ApplicationRole type=JPS_APPLICATION_ROLE]]].

Starting upgrade for portal roles...
Upgrade of the portal roles is complete.

Permissions upgrade completed with warnings

WebCenter Portal application upgrade is complete.

5.2.2 アップグレード監査ツールの実行

Oracle WebCenter Portal 12cでは、投票およびドキュメント・タスク・フローなどの特定の機能が非推奨になりました。アップグレード後にアップグレード監査ツールを実行して、アップグレード後のWebCenter Portalインストールでのすべての非推奨機能の使用状況をリストできます。

listDeprecatedFeaturesUsage WLSTコマンドを実行して、アップグレード後のOracle WebCenter Portalインストールでの非推奨機能の使用状況をリストします。

listDeprecatedFeaturesUsage(appName='webcenter', server='WC_Spaces', reportDirectory='/scratch/audit', portal='portal1, portal2')

それぞれの意味は次のとおりです。

- appNameは、非推奨機能を監査する対象のWebCenter Portalアプリケーションです。

- serverは、WebCenter Portalがデプロイされている管理対象サーバーです。

- reportDirectoryは、監査レポートが生成される書込み可能なディレクトリのパスです。

- portalは、監査対象の特定のポータルのリストです。ポータル名のカンマ区切りリストを渡すことができます。これはオプション・パラメータです。このパラメータを指定しない場合、WebCenter Portalアプリケーション全体のレポートが生成されます。

たとえば、次のコマンドでは、WC_Spacesという管理対象サーバーにデプロイされたWebCenter Portalアプリケーションの監査レポートを生成し、/scratch/auditというフォルダにレポートを保存します。

listDeprecatedFeaturesUsage(appName='webcenter', server='WC_Spaces', reportDirectory='/scratch/audit')

WebCenter Portalアプリケーション全体のアップグレード監査レポートを生成する場合、WLSTコマンドのreportDirectoryパラメータで指定したディレクトリのauditReportサブディレクトリに、次のファイルが生成されます。

- summary.txt: 図5-1に示すように、非推奨機能が含まれるポータルとポータル・テンプレートをリストし、非推奨機能が含まれるアーティファクトの数を示します。

- connections.txt: WebCenter Portalの非推奨接続をリストします。

注意:

機能上の問題が発生する可能性があるため、非推奨接続を削除する必要があります。

- 非推奨機能が含まれる、ポータルおよびポータル・テンプレートごとの.txtファイル: 非推奨機能が含まれるアーティファクト(ページ、ページ・テンプレート、リソース・カタログなど)をリストし、非推奨機能の名前を示します。図5-3に、特定のポータルの監査レポートを示します。

図5-1 アップグレード監査レポート - summary.txt

図5-2 アップグレード監査レポート - connections.txt

図5-3 Portalのアップグレード監査レポート

次の例では、MyPortalという名前のポータルのみを対象とした監査レポートが生成されます。これによりMyPortal.txtファイルのみが生成されます。ポータルに対する接続ファイルとサマリー・ファイルは生成されません。

listDeprecatedFeaturesUsage(appName='webcenter', server='WC_Spaces', reportDirectory='/scratch/audit', portal='MyPortal')

アップグレード後のWebCenter Portalで、ポータル・ページに非推奨機能が含まれている場合、ページ・ビュー・モードではその機能が空白で表示されます。ページ編集モードでは、機能が非推奨であるというメッセージが表示され、必要なアクションがリストされます。たとえば、図5-4では、非推奨の投票タスク・フローがページ・エディタにリストされています。メッセージには、非推奨のタスク・フローを削除する必要があることが示されています。

図5-4 アップグレード後のWebCenter Portalインスタンスのページ・エディタに表示された非推奨タスク・フロー

5.2.3 アップグレード・メトリックへのアクセス

Oracle Dynamic Monitoring Service (DMS)を使用すると、アップグレード・メトリックを表示して、アップグレード・プロセス全体および各ポータルとそのWebCenterサービス・ハンドラの所要時間を分析できます。

アップグレード・メトリックにアクセスするには、次の手順を実行します。

1. 次のURL形式を使用して、DMSスパイ・サーブレットにアクセスします。

http://host:port/dms/Spy

ここで、host:portは、Oracle WebCenter Portalがインストールされている場所を参照します。

2. 管理者としてログオンします。

3. 左ペインでwebcenter_upgradeメトリックを探します。

各ポータルのアップグレード・メトリックがミリ秒で表示されます。

4. 目的のポータルのアップグレード・プロセスの時間を参照します。ポータルごとに、upgradeProcessingTimeとcleanupProcessingTimeのメトリックが関連しています。

メトリックには、ポータル・サーバー全体のアップグレードの合計処理時間も表示されます。

必要に応じてこのレポートをPDFとして保存し、後で参照することができます。アップグレード・メトリックはサーバーを再起動すると失われます。

5. 左の列でwebcenter_upgrade_portalメトリックを探します。

アップグレード・メトリックは、ポータルごとに各WebCenterサービス・ハンドラのアップグレード・プロセス所要時間を示します。各ポータルのアップグレード所要時間の内訳を示します。

5.3 Oracle WebCenter Portalのアップグレード後のタスクの実行

Oracle WebCenter Portalをアップグレードした後に、アップグレード後のタスクを実行します。

- 11gのポートレット・プロデューサのアップグレード

- OmniPortletおよびWebクリッピング構成のリストア

- 重複したポータル・ページの削除

- Content Server接続がアップグレードされたことの確認

- WebCenter Portal 11gのアセットの12cへのアップグレード

5.3.1 11gのポートレット・プロデューサのアップグレード

アップグレード後のOracle WebCenter Portalインスタンスでは、11gのポートレットにアクセスできません。ポートレットを有効にするには、必要なポートレット・プロデューサ・アプリケーションをリリース12.2.1に移行する必要があります。また、ポートレット・プロデューサのカスタマイズ内容をインポートして、ポートレット・プロデューサ・アプリケーションを再デプロイする必要があります。

このトピックの内容は次のとおりです。

- ポートレット・プロデューサ・アプリケーションの移行

- ポートレット・プロデューサ・アプリケーションの再デプロイ

- カスタマイズ内容の移行

5.3.1.1 ポートレット・プロデューサ・アプリケーションの移行

11gのポートレット・プロデューサ・アプリケーションをリリース12cに移行するには、次の手順を実行します。

1. Oracle JDeveloper 12cをインストールします。

Oracle JDeveloperは、ポータルおよびカスタム・ポータル・コンポーネントの開発のための統合開発環境(IDE)を提供します。Oracle JDeveloperの取得およびインストールの詳細は、次に示すOTNのOracle JDeveloperに関するページを参照してください。

http://www.oracle.com/technetwork/developer-tools/jdev/overview/index.html

2. Oracle WebCenter Portal拡張バンドルをインストールします。詳細は、『Oracle JDeveloperによるWebCenter Portalアセットとカスタム・コンポーネントの開発』のJDeveloper対応のWebCenter Portal拡張機能に関する項を参照してください。

3. JDeveloper 12cを起動します。

4. 11gのポートレット・プロデューサ・アプリケーションを開きます。

これにより移行ウィザードが呼び出されます。このウィザードは、11gのアプリケーションをJDeveloper 12cで開くたびに表示されます。

5. 「確認」ページでは、デフォルトで「はい」オプションが選択されています。「次へ」をクリックして、アプリケーションを移行することを確認します。

6. 「Java Webプロジェクト」ページで「はい」をクリックして、JavaServer Pages JSTLを使用して作成したプロジェクトを最新バージョンに移行することを指定します。

7. 「終了」をクリックして、アプリケーションのアップグレードを開始します。

アップグレード・プロセスの実行中は進行状況を示すダイアログが表示されます。

8. アプリケーションのアップグレードが完了すると、アップグレードされたプロジェクトのリストが「移行ステータス」ダイアログに表示されます。「OK」をクリックします。

アップグレードしたアプリケーションが開き、そのプロジェクトがアプリケーション・ナビゲータに表示されます。アプリケーションのアップグレード中にエラーが発生した場合は、エラーが「メッセージ - ログ」ウィンドウに表示されます。

5.3.1.2 ポートレット・プロデューサ・アプリケーションの再デプロイ

アップグレード済ポートレット・プロデューサ・アプリケーションは、Oracle WebLogic Serverの管理対象サーバーでOracle WebCenter Portalのポートレット・プロデューサをサポートする構成のサーバーであれば、どのサーバーにもデプロイできます。デプロイメントには、Oracle Enterprise Manager Fusion Middleware Control、Oracle WebLogic Server管理コンソールまたはOracle WebLogic Scripting Tool (WLST)を使用できます。詳細は、『Oracle WebCenter Portalの管理』のポートレット・プロデューサ・アプリケーションのデプロイに関する項を参照してください。

WebLogicサーバーへのアクセスに必要な資格証明がある場合は、JDeveloperを使用して、ポートレット・プロデューサ・アプリケーションを開発環境から直接Oracle WebLogic Serverインスタンスにデプロイすることも可能です。詳細は、『Oracle JDeveloperによる、WebCenter Portalアセットおよびカスタム・コンポーネントの開発』の事前構成済ポートレット・プロデューサのデプロイに関する項を参照してください。

5.3.1.3 カスタマイズ内容の移行

ポートレット・プロデューサのアップグレード後に、カスタマイズ内容が共有されていない場合、またはアップグレード済ポートレット・プロデューサからカスタマイズ内容にアクセスできない場合は、そのカスタマイズ内容をインポートする必要があります。「Oracle WebCenter Portalのアップグレード前のタスクの実行」で説明しているようにエクスポートしたEARから、カスタマイズ内容をインポートします。

カスタマイズ内容をインポートするには、importPortletClientMetadata WLSTコマンドを使用します。詳細は、『WebCenter WLSTコマンド・リファレンス』のimportPortletClientMetadataに関する項を参照してください。

5.3.2 OmniPortletおよびWebクリッピング構成のリストア

OmniPortletおよびWebクリッピング構成を保存(「OmniPortletおよびWebクリッピング構成の保存」参照)した後、Oracle WebCenter Portalインスタンスが正常にアップグレードされたら、それらをリストアします。

1. アップグレード後のドメインの次の場所にある、provider.xmlファイルにナビゲートします。

Webクリッピング: ORACLE_HOME/servers/WC_Portlet/tmp/_WL_user/portalTools/randomly_generated_directory/war/WEB-INF/providers/webClipping/provider.xml

OmniPortlet: ORACLE_HOME/servers/WC_Portlet/tmp/_WL_user/portalTools/randomly_generated_directory/war/WEB-INF/providers/omniPortlet/provider.xml

2. 11gのprovider.xmlから、WebクリッピングとomniPortletのHTTPプロキシ・エントリを貼り付けます。次に例を示します。

<proxyInfo class="oracle.portal.provider.v2.ProxyInformation">
<httpProxyHost>proxy.example.com</httpProxyHost>
<httpProxyPort>80</httpProxyPort>
<dontProxyFor>*.example.com</dontProxyFor>
</proxyInfo>

3. ファイルを保存します。

5.3.3 重複したポータル・ページの削除

リリース11.1.1.7.0では、ポータルのナビゲーション内のページ(以前はスペースと呼ばれた)は、ページ問合せによるものです。12cにアップグレードすると、これらの各ページはナビゲーションに追加されます。そのため、ポータルに重複したページが作成されることになります。『Oracle WebCenter Portalでのポータルの構築』のページの削除に関する項の説明に従って、重複したページを削除できます。

5.3.4 Content Server接続がアップグレードされたことの確認

upgradeWebCenterPortalコマンドを正常に実行できたら、listContentServerConnections WLSTコマンドを実行して、Content Server接続がアップグレードされたことを確認します。詳細は、『WebCenter WLSTコマンド・リファレンス』.のlistContentServerConnectionsに関する項を参照してください。

listContentServerConnections WLSTコマンドの出力に次のメッセージが表示された場合は、upgradeWebCenterPortalを再度実行して、Content Server接続をアップグレードします。

基になるRIDC接続がありません。

5.3.5 WebCenter Portal 11gのアセットの12cへのアップグレード

アップグレード後のWebCenter Portal 12cインスタンスでWebCenter Portal 11gのアセットを使用するには、アセットをアップグレードする必要があります。たとえば、11gのスキン、ページ・テンプレート、またはページ・スタイルを、アップグレード後の12cポータルで使用するためにアップグレードできます。

11gのWebCenter Portalアセットを12cにアップグレードするには、次の手順を実行します。

1. Oracle JDeveloper 11gで、アップグレードするアセットを含むアプリケーションを開きます。

2. 必要なアセットのソース・コードをコピーします。たとえば、CSSファイルからスキンのソース・コードをコピーします。

3. Oracle JDeveloper 12cで、必要なアセット・タイプを指定して、WebCenter Portalのアセット・アプリケーションを作成します。たとえば、スキン・アセットをアップグレードする場合は、アセット・タイプとしてSkinを指定して、アセット・アプリケーションを作成します。

詳細は、『Oracle JDeveloperによるWebCenter Portalアセットとカスタム・コンポーネントの開発』のWebCenter Portalアセット・アプリケーションの作成に関する項を参照してください。

4. 新しく作成したアセット・アプリケーションからソース・コードを削除し、手順2でコピーしたアセットの11gのソース・コードを貼り付けます。たとえば、スキン・アセット・アプリケーションでソース・コードを削除し、11gのCSSファイルからコピーしたソース・コードを貼り付けます。

5. アセット・アプリケーションを保存します。

6. WebCenter Portal 12cに共有アセットとして、または特定のポータルに対して、アセット・アプリケーションをデプロイします。詳細は、『Oracle JDeveloperによるWebCenter Portalアセットとカスタム・コンポーネントの開発』のWebCenter Portalアセットの公開に関する項を参照してください。

5.4 非推奨機能のアップグレードによる影響の理解

このトピックでは、リリース12.2.1で非推奨になった11gの機能をアップグレードすることによる影響について説明します。

次のトピックが含まれています:

- ポータルレベルのデバイス設定

- 階層ポータル

- 非推奨のポートレット

5.4.1 ポータルレベルのデバイス設定

デバイス設定によって、デスクトップ・ブラウザ、スマートフォン、タブレットなどの様々な種類のデバイスにおけるポータルのレンダリング方法が制御されます。リリース12cでは、デバイス設定はWebCenter Portalアプリケーション・レベルでのみ構成でき、個別のポータルではできません。リリース12.2.1にアップグレードする際に、デバイス設定に対するポータル・レベルのカスタマイズは失われます。アップグレード後のWebCenter Portalインスタンスにはアプリケーション・レベルのデバイス設定のみが適用されます。

5.4.2 階層ポータル

リリース11gでは、親ポータルとそのサブポータルで構成されるポータル階層をサポートしており、デフォルトでは、サブポータルは親ポータルで定義されたセキュリティを継承します。WebCenter Portalをリリース12cにアップグレードする際、サブポータルは最上位レベルのポータルに移動します。アップグレードの処理中に、そのようにアップグレードされた各ポータルには、次の2つの属性が追加されます。

- 11g.upgraded.portal.parent.guid - 親ポータルのIDを指定します。

- 11g.upgraded.portal.parent.security.id - セキュリティを継承した元のポータルを指定します(存在する場合)。値がnullである場合は、サブポータルが親ポータルからセキュリティを継承しておらず、サブポータルが独自のセキュリティを管理していることを示します。

5.4.3 非推奨のポートレット

12cでは、Webクリッピング・ポートレットとリッチ・テキスト・ポートレットは非推奨になりました。アップグレード後のポータル・ページに非推奨のポートレットが含まれている場合、ページにはリモート・ポートレット・エラーが表示されます。ページから非推奨のポートレットを削除するか、12cの同等のものに置き換える必要があります。

12cでは、以前のリリースのWebCenter Portalで利用されていたWebクリッピング・ポートレットの機能が、ページレット・プロデューサに置き換わりました。リッチ・テキスト・ポートレットの機能は、コンテンツ寄与と公開コンポーネントに置き換わりました。

5.5 Oracle WebCenter Portalのアップグレードに関する問題のトラブルシューティング

このトピックでは、WebCenter Portalの最新リリースへのアップグレードで発生する可能性がある問題の解決策について説明します。

- ACTIVITIESスキーマの余分なエントリが表示される

- カスタム・ページ・テンプレートでフローティング・ツールバーを使用できない

- プレデプロイメント・ツールの実行で11gのポートレット・プロデューサが更新されない

- Oracle WebCenter Portalのアップグレード中のエラー処理

- アップグレード後のポータルでドキュメント/ブログ/Wikiページにアクセスするとエラーが発生する

- ポータルのアップグレードが失敗する

5.5.1 ACTIVITIESスキーマの余分なエントリが表示される

問題

アップグレード後のWebCenter Portal 12.2.1インスタンスで、ACTIVITIESスキーマに余分なエントリが表示されます。

解決策

リリース12.2.1では、アクティビティ・グラフが非推奨になりました。11gリリースからアップグレードする際に、既存のアクティビティ・グラフのエントリが削除されません。ただし、Oracle WebCenter Portal 12.2.1のフレッシュ・インスタンスをインストールした場合、これらのエントリはACTIVITIESスキーマに表示されません。

5.5.2 カスタム・ページ・テンプレートでフローティング・ツールバーを使用できない

アップグレード後のWebCenter Portalインスタンスにおいて、アップグレード後のポータルにコンテンツ寄与をサポートするページが含まれており、以前のリリースで作成されたカスタム・ページ・テンプレートを使用している場合は、フローティング・ツールバーを使用できません。フローティング・ツールバーを有効化するには、カスタム・ページ・テンプレートに追加します。詳細は、『Oracle JDeveloperによるWebCenter Portalアセットとカスタム・コンポーネントの開発』のページ・テンプレートへのフローティング・ツールバーの追加に関する項を参照してください。

5.5.3 プレデプロイメント・ツールの実行で11gのポートレット・プロデューサが更新されない

WebCenter Portalには、必要な構成をポートレット・プロデューサ・アプリケーションのEARファイルに追加し、WSRP上でポートレットを公開する事前デプロイ・ツールがあります。11gバージョンからポートレットEARでプレデプロイメント・ツールを直接実行することはできません。Oracle JDeveloperでポートレット・プロデューサ・アプリケーションを移行し、EARを再生成してからプレデプロイメント・ツールを実行する必要があります。ポートレット・プロデューサの移行の詳細は、「11gのポートレット・プロデューサのアップグレード」を参照してください。プレデプロイメント・ツールの実行の詳細は、『Oracle WebCenter Portalの管理』のポートレット・プロデューサの管理に関する項を参照してください。

5.5.4 Oracle WebCenter Portalのアップグレード中のエラー処理

Oracle WebCenter Portalのアップグレード中に、エラー・メッセージが表示される場合があります。upgradeWebCenterPortal WLSTコマンドの実行時に表示されるエラー・メッセージの一部を次に示します。

エラー・メッセージ1

アップグレードの終了時に次のいずれかのメッセージが表示されます。

- Migration of Content Server from Folders_g to FrameworkFolders failed, Check MigrationDiagnostic.log for further details.
- An error occurred during migration, Check MigrationDiagnostic.log for further details.

エラー・メッセージ2

アップグレードの終了時に次のメッセージが表示されます。

- Export of Folders_g data failed.
- Updating Content Server general configuration failed.
- Migration of <folder name> folder and content from Folders_g to the FrameworkFolders data structure failed.
- Migration of WebCenter Portal data to FrameworkFolders failed.
- Enabling <component name> server components failed.
- Disabling <component name> server components failed.
- Migration to FrameworkFolders failed.

エラー・メッセージ3

アップグレードの終了時に次のメッセージが表示されます。

- WebCenter Content Server foldering service is not supported. Supported foldering service is FrameworkFolders version 2.1 and above.

解決策

問題を修正するには、次の手順を実行する必要があります。

1. WebCenter Content Serverをリストアします。

2. 『Oracle WebCenter Portalの管理』のFrameworkFoldersへのFolders_gの移行に関する項の説明に従って、Folders_gからFrameworkFoldersに手動で移行します。

3. 次のコマンドを実行します。

upgradeWebCenterPortal(appName='webcenter', server='WC_Spaces', migrationDirectory='/tmp/upgrade',contentServerName='UCM_server1')

コマンドの詳細は、『WebCenter WLSTコマンド・リファレンス』のupgradeWebCenterPortalに関する項を参照してください。

5.5.5 アップグレード後のポータルでドキュメント/ブログ/Wikiページにアクセスするとエラーが発生する

アップグレード後に、アップグレード後のポータルのドキュメント、ブログ、またはWikiページにアクセスしてエラーが発生する場合は、次の手順を実行して、アップグレードが正しく完了したかどうかをContent Serverで確認してください。

1. host:port/csのURL形式を使用して、Content Serverにログインします。

2. エンタープライズ・ライブラリにナビゲートして、ポータルのフォルダ名を識別します。

3. 次のURL形式にアクセスします。
host:port/cs/idcplg?IdcService=FLD_INFO&path=/Enterprise Libraries/portal-folder-name&IsSoap=1

4. 結果の出力で、fApplicationGUIDを探します。大文字のGUIDが含まれている場合は、Oracleサポートに連絡してください。

5.5.6 ポータルのアップグレードが失敗する

Oracle WebCenter Portalのアップグレード中にポータルのアップグレードが失敗する場合は、ログを確認して問題を識別してください。UpgradeDetails.txtで、NAMESPACEまたはDOCUMENT_DEFのようなキーワードを検索し、関連する例外スタックを探して詳細を確認します。このトピックでは、ポータルのアップグレード失敗のトラブルシューティングのシナリオについて説明します。

エラー・メッセージ1

UpgradeDetails.txtでアップグレードが失敗したポータルのDOCUMENT_REFを検索すると、次のエントリが表示されます。

- java.sql.SQLException: ORA-12899: value too large for column "DEV_WEBCENTER"."WC_PORTAL_ENTITY"."DOCUMENT_REF"

解決策

ポータルのアップグレード失敗の原因の1つとして、space.xmlにロゴやアイコンの属性としてバイナリまたはコード化されたコンテンツが含まれており、これらの属性の値が文字数制限を超えていることが考えられます。両方の属性の値を変更して、バイナリ・コンテンツからロゴとアイコンのファイルのMDSパスに置き換えます。ポータルのアップグレードが成功した後で、必要に応じてポータル・ロゴとアイコンを再度変更できます。

この問題を修正するには:

1. importMetadata WLSTコマンドを使用して、ターゲット・ポータルのMDSからspace.xmlをエクスポートします。
たとえば、次のコマンドではMyPortalという名前のポータルのspaces.xmlが指定した場所にエクスポートされます。

exportMetadata(application='webcenter', server='WC_Spaces', toLocation='/scratch/export', docs='/oracle/webcenter/space/metadata/spaces/MyPortal/space.xml')

exportMetadata WLSTコマンド構文の詳細は、『インフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』のexportMetadataに関する項を参照してください。

2. エクスポートされたspace.xmlファイルで、Icon属性とLogo属性の値を確認します。これらの属性の値がdata:imageで始まっている場合は、属性を次の値に編集してファイルを保存します。

- Icon: /oracle/webcenter/siteresources/scopedMD/shared/images/portalnew_icon.png

- Logo: /oracle/webcenter/siteresources/scopedMD/shared/images/portalnew_logo.png

3. importMetadata WLSTコマンドを使用して、変更済のspace.xmlファイルをインポートします。
たとえば、次のコマンドではMyPortalのspaces.xmlが指定した場所からエクスポートされます。

importMetadata(application='webcenter',server='WC_Spaces',fromLocation='/scrat ch/export',docs='/oracle/webcenter/space/metadata/spaces/MyPortal/space.xml')

importMetadata WLSTコマンドの構文の詳細は、『インフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』のimportMetadataに関する項を参照してください。

4. ポータル・フレームワーク・アプリケーションを再度アップグレードします。

5. ポータルのアップグレードが成功したら、WebCenter Portalにログオンしてポータルにナビゲートし、必要に応じてポータルのロゴとアイコンを変更します。詳細は、『Oracle WebCenter Portalでのポータルの構築』のポータルのルック・アンド・フィール設定の管理に関する項を参照してください。

エラー・メッセージ2

UpgradeDetails.txtでアップグレードが失敗したポータルのNAMESPACEを検索すると、次のエントリが表示されます。

java.sql.SQLException: ORA-12899: value too large for column "DEV_WEBCENTER"."WC_PORTAL_ENTITY"."NAMESPACE"

解決策

この問題の原因の1つとして、ポータル・リソースのタイトル属性の値が200文字の制限を超えていることが考えられます。文字数制限を超えないように、値を変更します。

1. UpgradeDetails.txtファイルを確認して、問題の原因となるポータル・リソースを識別します。
たとえば、Page20PageDef.xmlという名前のページ定義ファイルのタイトルが200文字を超えているとします。

2. exportMetadata WLSTコマンドを使用して、ポータル・リソースをエクスポートします。
次に示すコードでは、Page20PageDef.xmlファイルが指定した場所にエクスポートされます。

exportMetadata(application='webcenter', server='WC_Spaces', toLocation='/scratch/export', docs='/pageDefs/oracle/webcenter/page/scopedMD/sfe492158_7b1a_421c_a242_37897a 2529e7/Page20PageDef.xml')

exportMetadata WLSTコマンド構文の詳細は、『インフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』のexportMetadataに関する項を参照してください。

3. エクスポートされたリソースのpage_title属性とpage_info属性の値を編集して200文字未満にします。

4. importMetadata WLSTコマンドを使用して、ポータル・リソースをインポートします。たとえば、次のコマンドでは更新後のPage20PageDef.xmlを指定した場所からインポートします。

importMetadata(application='webcenter',server='WC_Spaces',fromLocation='/scrat ch/export', docs='/pageDefs/oracle/webcenter/page/scopedMD/sfe492158_7b1a_421ca242_37897a 2529e7/Page20PageDef.xml')

importMetadata WLSTコマンドの構文の詳細は、『インフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』のimportMetadataに関する項を参照してください。

5. ポータル・フレームワーク・アプリケーションを再度アップグレードします。

6 Oracle WebCenter Sitesの12c (12.2.1.1)へのアップグレード

既存のOracle WebCenter Sites 11.1.1.8および12.2.1.0インストールをリリース12.2.1.1にアップグレードできます。

11gから12cへのアップグレードは、アウトオブプレース移行です。これには、Upgrade Assistantを使用したデータ表とプラットフォーム構成の移行が含まれます。

12.2.1.0から12.2.1.1へのアップグレードは、インプレース・アップグレードです。

注意:

アップグレードする際に、要件にあわせて検討できる2つの方法があります。

1. 配信環境をアップグレードし、アップグレード後にそのクローンを作成して、開発環境と管理環境を作成します。
この方法を検討する場合は、同期化が必要になります。アップグレードの前に、開発環境と管理環境から配信環境にコンテンツを公開する必要があります。その後、アップグレードした配信環境のクローンを作成して、開発環境と管理環境を作成します。

2. または、各環境を個別にアップグレードします。
この方法を検討する場合、同期化は必要ありません。

この章の内容は次のとおりです。

- WebCenter Sitesの11gから12cへのアップグレードの理解
このトピックでは、フローチャートを使用して、WebCenter Sitesを11gから12cリリースにアップグレードするためのプロセス・フローについて説明します。

- WebCenter Sitesの11gから12cへのアップグレード
WebCenter Sitesを12.2.1.1にアップグレードするための11gの有効な開始ポイントは、WebCenter Sites 11.1.1.8以上です。これは、アウトオブプレース移行です。

- WebCenter Sitesの以前の12cリリースからのアップグレード・プロセスの理解
このトピックでは、フローチャートを使用して、WebCenter Sitesを以前の12cリリースからアップグレードするためのプロセス・フローについて説明します。

- WebCenter Sitesの以前の12cリリースからのアップグレード
WebCenter Sitesを12.2.1.1にアップグレードするための12cの有効な開始ポイントは、WebCenter Sites 12.2.1.0です。これは、インプレース・アップグレードです。

- カスタムJavaライブラリまたは静的Webリソースの移行
アップグレード前の環境でWebアプリケーションにカスタムJavaライブラリまたは静的Webリソースが追加されており、アップグレード後の環境でこれらを引き続き使用する場合にのみ、このオプション手順を実行します。

6.1 WebCenter Sitesの11gから12cへのアップグレードの理解

このトピックでは、フローチャートを使用して、WebCenter Sitesを11gから12cリリースにアップグレードするためのプロセス・フローについて説明します。

図6-1 WebCenter Sitesの11gから12cリリースへのアップグレード・プロセスのフローチャート

表6-1に、WebCenter Sitesを11gから12cにアップグレードするために実行する必要がある、タスクのロードマップを示します。

表6-1 WebCenter Sitesの11gから12cリリースへのアップグレード・プロセスのロードマップ

手順番号

タスク

説明

1

12.2.1.1のOracle Fusion Middlewareインフラストラクチャをインストールします。

インフラストラクチャのディストリビューションには、その他のFusion Middleware製品をインストールするための基盤の設定に必要な、WebLogic ServerおよびJava Required Files (JRF)が同梱されています。

このガイドのアップグレード・トポロジに定義されているように、インフラストラクチャは新規のOracleホームにインストールする必要があります。 そのため、「Fusion Middlewareインフラストラクチャのインストール」で説明している手順に従ってください。

2

12.2.1.1のOracle WebCenter Sitesのディストリビューションをインストールします。

「WebCenter Sites 12.2.1.1.0のディストリビューションのインストール」の説明に従って、Oracle WebCenter Sitesのディストリビューションをインストールします。

3

必要なスキーマを作成します。

WebCenter Sites 11gからアップグレードする場合は、アップグレードを開始する前に、12cの必要なスキーマを作成する必要があります。 WebCenter Sitesに必要なスキーマは、Oracle Platform Security Services (OPSS)、Audit Services (IAU)およびWebCenter Sitesです。

「アップグレード前の必要なスキーマの作成」の説明に従い、リポジトリ作成ユーティリティ(RCU)を使用してスキーマを作成します。

4

WebCenter Sitesドメインを構成します。

11gから12cへのアップグレードは、アウトオブプレース・アップグレードです。そのため、「WebCenter Sitesドメインの構成」で説明している手順に従って、12.2.1.1のWebCenter Sitesドメインを構成します。

5

WebCenter Sitesインスタンスを構成します。

「WebCenter Sitesインスタンスの構成」で説明している手順に従って、ブラウザベースのWebCenter Sitesコンフィギュレータを実行し、WebCenter Sitesインスタンスを構成します。

6

構成後のタスクを実行します。

構成後のタスクには、LDAPベースまたはOAMベースの認証を使用した12.2.1.1ドメインの構成、ディレクトリ構造の検証、サインインとSitesのUIへのアクセス、管理対象サーバーの再起動などが含まれます。

これらのタスクは、「構成後のタスク」にリストされています。

7

アップグレード前のタスクを実行します。

アップグレード前のタスクは、アップグレード・アシスタントを使用してアップグレード・プロセスを開始する前に完了している必要がある、一連のタスクです。

これらのタスクは、「アップグレード・アシスタントを実行する前に」にリストされています。

8

スキーマをアップグレードします。

「アップグレード・アシスタントを使用したスキーマのアップグレード」で説明している手順に従い、アップグレード・アシスタントを使用して、アップグレード可能なスキーマ・コンポーネントをアップグレードします。

9

ドメイン構成をアップグレードします。

「アップグレード・アシスタントを使用した構成のアップグレード」で説明している手順に従い、アップグレード・アシスタントを使用して、11.1.1.8のドメインに含まれるすべての構成をアップグレードします。

10

アップグレード後の検証タスクを実行します。

スキーマと構成が正常にアップグレードされた後でデータの整合性を確認するための、新しくアップグレードしたドメインで実行できる検証スクリプトが用意されています。検証の要約レポートをレビューして、スキーマと構成のアップグレード・プロセスの間にデータの不整合が発生していないか確認できます。

検証スクリプトを使用するには、「アップグレード後の検証タスク」を参照してください。

11

その他のアップグレード後のタスクを実行します。

その他のアップグレード後のタスクには、カスタム設定のリストア、管理サーバーと管理対象サーバーの起動、パスワードの再構成、および「アップグレード後のタスク」にリストされているその他の管理タスクが含まれます。

6.2 WebCenter Sitesの11gから12cへのアップグレード

WebCenter Sitesを12.2.1.1にアップグレードするための11gの有効な開始ポイントは、WebCenter Sites 11.1.1.8以上です。これは、アウトオブプレース移行です。

注意:
11.1.1.6.xからアップグレードする場合は、『Fusion Middleware WebCenter Sitesアップグレード・ガイド』に記載されているWebCenter Sites 11gのアップグレード手順を使用して、リリース11.1.1.8にアップグレードする必要があります。

WebCenter Sitesを11gから12cにアップグレードするには、次のタスクを実行します。

- Fusion Middlewareインフラストラクチャのインストール
Fusion Middlewareインフラストラクチャをインストールすると、Oracleホーム・ディレクトリが作成され、その他のFusion Middleware製品をインストールするためのサポート・ソフトウェアが配置されます。

- WebCenter Sites 12.2.1.1.0のディストリビューションのインストール
次に、WebCenter Sitesリリース12.2.1.1.0をターゲット・マシンにインストールします。

- アップグレード前の必要なスキーマの作成
WebCenter Sites 11gからアップグレードする場合は、アップグレードを開始する前に、12cの必要なスキーマを作成する必要があります。WebCenter Sitesに必要なスキーマは、Oracle Platform Security Services (OPSS)、Audit Services (IAU)およびWebCenter Sitesです。

- WebCenter Sitesドメインの構成
WebCenter Sites 11gから12cにアップグレードする場合は、構成ウィザードを使用してWebCenter Sitesドメインを構成する必要があります。

- WebCenter Sitesインスタンスの構成
Oracle WebCenter Sitesドメインを構成した後に、ブラウザベースのWebCenter Sitesコンフィギュレータを実行して、WebCenter Sitesインスタンスを構成できます。 WebCenter Sitesランタイムは、WebCenter Sites、CAS Webアプリケーション(WARファイル)およびクラスタ・メンバー間の共有コンポーネント(configディレクトリ、dataディレクトリおよびデータベース・インスタンス)で構成されています。

- 構成後のタスク
WebCenter Sites12cを構成した後に、このトピックにリストされているタスクを実行します。

- アップグレード・アシスタントを実行する前に
アップグレード・アシスタントを実行して11.1.1.8.0のドメインをアップグレードする前に、このトピックにリストされているタスクを実行します。

- アップグレード・アシスタントを使用したスキーマのアップグレード
アップグレード・アシスタントを使用して、11gのスキーマをアップグレードする必要があります。

- アップグレード・アシスタントを使用した構成のアップグレード
アップグレード・アシスタントを使用して、11gのドメイン構成をアップグレードする必要があります。

- アップグレード後の検証タスク
スキーマと構成が正常にアップグレードされた後でデータの整合性を確認するための、新しくアップグレードしたドメインで実行できる検証スクリプトが用意されています。検証の要約レポートをレビューして、スキーマと構成のアップグレード・プロセスの間にデータの不整合が発生していないか確認できます。

- アップグレード後のタスク
アップグレード後のタスクには、カスタム設定のリストア、管理サーバーと管理対象サーバーの起動、パスワードの再構成、およびこのトピックにリストされているその他の管理タスクが含まれます。

6.2.1 Fusion Middlewareインフラストラクチャのインストール

Fusion Middlewareインフラストラクチャをインストールすると、Oracleホーム・ディレクトリが作成され、その他のFusion Middleware製品をインストールするためのサポート・ソフトウェアが配置されます。

Fusion Middlewareインフラストラクチャのディストリビューションをインストールするには、次の手順を実行します。

1. 12.2.1.1製品の配布をインストールするターゲット・システムにログインします。

2. Oracle Fusion Middleware Infrastructureの配布(fmw_12.2.1.1.0_infrastructure_generic.jar)を、Oracle Technology NetworkまたはOracle Software Delivery Cloudからお使いのターゲット・システムにダウンロードします。

3. 12.2.1.1の製品のディストリビューションをダウンロードしたディレクトリに移動します。

4. 次のコマンドを入力して、インストール・プログラムを起動します。
UNIXオペレーティング・システムの場合:

$JDK_HOME/bin/java [-d64] -jar fmw_12.2.1.1.0_infrastructure_generic.jar

注意:
HP-UX Itaniumを使用している場合のみ"-d64"フラグを使用します。

Windowsオペレーティング・システムの場合:

%JDK_HOME%\bin\java -jar fmw_12.2.1.1.0_infrastructure_generic.jar

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

注意:
「インストール・インベントリの設定」画面は、Windowsオペレーティング・システムでは表示されません。

6. 「ようこそ」画面で、情報をレビューしてすべての前提条件を満たしていることを確認し、「次へ」をクリックします。

7. 「自動更新」画面で「自動更新をスキップ」を選択し、「次へ」をクリックします。

- 自動更新をスキップ: このときにソフトウェアの更新をシステムで確認しないようにする場合。

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

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

8. 「インストールの場所」画面でOracleホーム・ディレクトリの場所を指定し、「次へ」をクリックします。
Oracle Fusion Middlewareのディレクトリ構造の詳細は、『Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成用のディレクトリの選択に関する項を参照してください。

9. 「インストール・タイプ」画面で「Fusion Middlewareインフラストラクチャ」を選択し、「次へ」をクリックします。

注意:
このドキュメントのトポロジにサーバーの例は含まれません。製品環境にはサンプルをインストールしないように強くお薦めします。

10. 「前提条件チェック」画面では、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
いずれかの前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。

エラー・メッセージや警告メッセージを無視してインストールを続ける場合は、「スキップ」をクリックします(このアプローチはお薦めできません)。

11. 「セキュリティ更新」画面で、My Oracle Supportアカウント情報を入力すると、最新の製品情報およびセキュリティ・アップデートをMy Oracle Supportアカウントを介して受け取ることができます。
この画面は、ホスト上にOracle製品を初めてインストールすると表示されます。

Oracle Supportアカウントを所有していない場合、この手順をスキップするには、チェック・ボックスの選択を解除し、フォローアップのダイアログ・ボックスで選択内容を確認します。

12. 「インストールの概要」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存するには、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルを使用して、サイレント・インストールを実行できます。「インストール」をクリックします。

13. 進捗バーの表示が100%になったら、「インストールの進行状況」画面で「次へ」をクリックします。

14. 「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

6.2.2 WebCenter Sites 12.2.1.1.0のディストリビューションのインストール

次に、WebCenter Sitesリリース12.2.1.1.0をターゲット・マシンにインストールします。

WebCenter Sitesをインストールするには、次の手順を実行します。

1. 12.2.1.1製品の配布をインストールするターゲット・システムにログインします。

2. Oracle Fusion Middleware WebCenter Sitesのディストリビューション(fmw_12.2.1.1.0_wcsites_generic.jar)を、Oracle Technology NetworkまたはOracle Software Delivery Cloudからお使いのターゲット・システムにダウンロードします。

3. 12.2.1.1の製品のディストリビューションをダウンロードしたディレクトリに移動します。

4. 次のコマンドを入力して、インストール・プログラムを起動します。
UNIXオペレーティング・システムの場合:

$JDK_HOME/bin/java [-d64] -jar <distribution_file_name>.jar

注意:
HP-UX Itaniumを使用している場合のみ"-d64"フラグを使用します。

Windowsオペレーティング・システムの場合:

%JDK_HOME%\bin\java -jar <distribution_file_name>.jar

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

注意:
「インストール・インベントリの設定」画面は、Windowsオペレーティング・システムでは表示されません。

6. 「ようこそ」画面で、情報をレビューしてすべての前提条件を満たしていることを確認し、「次へ」をクリックします。

7. 「自動更新」画面で「自動更新をスキップ」を選択し、「次へ」をクリックします。

- 自動更新をスキップ: このときにソフトウェアの更新をシステムで確認しないようにする場合。

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

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

8. 「インストールの場所」画面でOracleホーム・ディレクトリの場所を指定し、「次へ」をクリックします。
Oracle Fusion Middlewareのディレクトリ構造の詳細は、『Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成用のディレクトリの選択に関する項を参照してください。

9. 「インストール・タイプ」画面で「WebCenter Sites」を選択し、「次へ」をクリックします。

10. 「前提条件チェック」画面では、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
いずれかの前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。

エラー・メッセージや警告メッセージを無視してインストールを続ける場合は、「スキップ」をクリックします(このアプローチはお薦めできません)。

11. 「インストールの概要」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存するには、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルを使用して、サイレント・インストールを実行できます。「インストール」をクリックします。

12. 進捗バーの表示が100%になったら、「インストールの進行状況」画面で「次へ」をクリックします。

13. 「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

6.2.3 アップグレード前の必要なスキーマの作成

WebCenter Sites 11gからアップグレードする場合は、アップグレードを開始する前に、12cの必要なスキーマを作成する必要があります。WebCenter Sitesに必要なスキーマは、Oracle Platform Security Services (OPSS)、Audit Services (IAU)およびWebCenter Sitesです。

注意:
この手順は、全データベース管理者権限を持つSYSまたはSYSDBAユーザーを想定しています。制限されたデータベース権限を持つユーザーである場合は、「制限されたデータベース権限を持つユーザーとしてのスキーマの作成」で説明している手順に従ってください。RCUの使用の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』を参照してください。

12cスキーマを作成するには、次の手順を実行します。

1. 次のディレクトリに移動します。
UNIXオペレーティング・システムの場合:

$ORACLE_HOME/oracle_common/bin

Windowsオペレーティング・システムの場合:

%ORACLE_HOME%\oracle_common\bin

2. 次のコマンドを入力して、RCUを実行します。
UNIXオペレーティング・システムの場合:

./rcu

Windowsオペレーティング・システムの場合:

rcu.bat

3. 「ようこそ」画面で「次へ」をクリックします。

4. 「リポジトリの作成」画面で、「リポジトリの作成」、「システム・ロードおよび製品ロード」の順に選択します。「次へ」をクリックします。
DBA権限を持っていない場合は、「システム・ロードに対するスクリプトの準備」を選択します。

5. 「データベース接続の詳細」画面で「データベース・タイプ」を選択し、次の詳細を入力します。

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

オプション

説明および例

ホスト名

データベースが稼働しているサーバーの名前を、次の形式で指定します。

examplehost.exampledomain.com

Oracle RACデータベースの場合は、このフィールドにVIP名またはいずれかのノード名を指定します。

ポート

データベースのポート番号を指定します。Oracleデータベースのデフォルトのポート番号は1521です。

サービス名

データベースのサービス名を指定します。通常、サービス名はグローバル・データベース名と同じです。

Oracle RACデータベースの場合、このフィールドにいずれかのノードのサービス名を指定します。次に例を示します。

examplehost.exampledomain.com

ユーザー名

データベースのユーザー名を入力します。デフォルトのユーザー名はSYSです。

パスワード

データベース・ユーザーのパスワードを入力します。

ロール

ドロップダウン・リストからデータベース・ユーザーのロールを選択します。

「標準」または「SYSDBA」

表6-3 MySQLデータベースに対する接続資格証明

オプション

説明および例

ホスト名

データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。

ポート

データベースのポート番号を指定します。

データベース名

データベースの名前を指定します。

ユーザー名

管理者権限を持つユーザーの名前を指定します。

パスワード

データベース・ユーザーのパスワードを入力します。

表6-4 Microsoft SQL Serverデータベースに対する接続資格証明

オプション

説明および例

Unicodeのサポート

ドロップダウン・リストから「はい」または「いいえ」を選択します。

サーバー名

データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。

ポート

データベースのポート番号を指定します。

データベース名

データベースの名前を指定します。

ユーザー名

管理者権限を持つユーザーの名前を指定します。

パスワード

データベース・ユーザーのパスワードを入力します。

表6-5 IBM DB2データベースに対する接続資格証明

オプション

説明および例

サーバー名

データベースが稼働しているサーバーのホスト名、IPアドレスまたは詳細なサーバー名を、host\server形式で指定します。

ポート

データベースのポート番号を指定します。

データベース名

データベースの名前を指定します。

ユーザー名

DB所有者の権限が付与されているユーザーの名前を指定します。IBM DB2データベースのデフォルトのユーザー名はdb2adminです。

パスワード

データベース・ユーザーのパスワードを入力します。

前提条件のチェックが成功した場合は、「OK」をクリックして次のページに進みます。チェックが失敗した場合は、入力した詳細を確認して再試行します。

6. 「コンポーネントの選択」画面で「新規接頭辞の作成」を選択し、11gスキーマと同じ接頭辞を入力します。
カスタム接頭辞は、これらのスキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。

次のコンポーネント・スキーマを選択します。

- Oracle Platform Security Services

- 監査サービス

- 監査サービス・アペンド

- 監査サービス・ビューア

- WebCenter Sites

- WebCenter Sites - Visitorサービス

構成ウィザードによって、「共通インフラストラクチャ・サービス」スキーマが自動的に作成されます。このスキーマはグレー表示され、選択または選択を解除することはできません。このスキーマを使用すると、ドメインの構成中にRCUから情報を取得できるようになります。

7. 「前提条件チェック」ダイアログ・ボックスで、前提条件チェックが成功したことを確認します。「OK」をクリックして、次のページに進みます。

8. 「スキーマ・パスワード」画面で、スキーマ所有者のパスワードを指定します。
この画面で入力したパスワードは忘れないでください。この情報は製品インストールの構成中に必要になります。これらの値をメモしておくことをお薦めします。

9. 「表領域のマップ」画面で、作成するスキーマの目的の表領域マッピング構成します。
「次へ」をクリックすると、別のダイアログ・ウィンドウが開き、これらの表領域の作成を確認するように求められます。「OK」をクリックして先に進み、このダイアログ・ウィンドウを閉じます。

表領域作成の進行状況を示す2番目のダイアログ・ウィンドウが表示されます。この処理が完了したら、「OK」をクリックしてこのウィンドウを閉じ、次の画面に進みます。

RCUの起動時に、Transparent Data Encryption (TDE)がデータベース(OracleまたはOracle EBR)内で有効化されている場合にのみ、「表領域の暗号化」チェック・ボックスが表示されます。RCUにより作成されるすべての新しい表領域を暗号化するには、「表領域のマップ」画面で「表領域の暗号化」チェック・ボックスを選択します。

10. 「サマリー」画面で情報を確認し、「作成」をクリックしてスキーマの作成を開始します。
この画面には、このRCU操作で作成されたログ・ファイルに関する情報が表示されます。特定のログ・ファイルの名前をクリックして、そのファイルの内容を表示できます。

11. 「完了サマリー」画面の情報をレビューし、操作が正常に完了したことを確認します。「閉じる」をクリックして、スキーマの作成を完了し、RCUを終了します。

どのスキーマを作成したらよいですか。

作成するスキーマの決定

システム・ロードと製品ロードとは何ですか。

システム・ロードおよび製品ロードの理解

カスタム接頭辞とは何ですか。

カスタム接頭辞の理解

スキーマ作成の計画:

スキーマ作成の計画

6.2.4 WebCenter Sitesドメインの構成

WebCenter Sites 11gから12cにアップグレードする場合は、構成ウィザードを使用してWebCenter Sitesドメインを構成する必要があります。

WebCenter Sitesドメインを構成するには、次の手順を実行します。

1. 次のディレクトリに移動します。
UNIXオペレーティング・システムの場合:

ORACLE_HOME/oracle_common/common/bin

Windowsオペレーティング・システムの場合:

ORACLE_HOME\oracle_common\common\bin

2. 次のコマンドを入力して、構成ウィザードを起動します。
UNIXオペレーティング・システムの場合:

./config.sh

Windowsオペレーティング・システムの場合:

config.cmd

3. 「構成タイプ」画面で「新規ドメインの作成」を選択し、「次へ」をクリックします。
「ドメインの場所」フィールドでドメインのホーム・ディレクトリを指定し、「次へ」をクリックします。

ドメイン・ディレクトリの場所には、Fusion Middleware製品がインストールされているOracleホーム・ディレクトリ以外の場所を選択することをお薦めします。推奨されるディレクトリ構造の詳細は、Oracle Fusion Middlewareの理解のOracle Fusion Middlewareの主要なディレクトリに関する項を参照してください。

4. 「テンプレート」画面で、「製品テンプレートを使用してドメインを作成」を選択します。
「テンプレート・カテゴリ」ドロップダウン・リストから、次を選択します。

- Oracle WebCenter Sites - 12.2.1.1.0 [wcsites]

- Oracle JRF - 12.2.1.1.0 [oracle_common]

- Oracle Enterprise Manager - 12.2.1.1.0 [em]

- WebLogic Coherence Cluster Extension - 12 2.1.1.0 [wlserver]

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

5. 「アプリケーションの場所」画面で、「アプリケーションの場所」にパスを入力するか、ナビゲーション・ツリーを使用するための「参照」をクリックして、ドメインに関連付けられたアプリケーションの格納場所を指定します。アプリケーションの場所は、アプリケーション・ホーム・ディレクトリとも呼ばれます。
アプリケーションの場所には、Fusion Middleware製品がインストールされているOracleホーム・ディレクトリ以外の場所を選択することをお薦めします。推奨されるディレクトリ構造の詳細は、Oracle Fusion Middlewareの理解のOracle Fusion Middlewareの主要なディレクトリに関する項を参照してください。

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

6. 「管理者アカウント」画面で、11.1.1.8.0 WebCenter Sitesドメイン用のユーザー名とパスワードを指定し、「次へ」をクリックします。
これらのアカウント詳細は、WebCenter Sitesドメインの管理サーバーを起動し、これに接続するために使用されます。

7. 「ドメイン・モードおよびJDK」画面で、「本番」とOracle HotSpot JDKを、ドメイン・モードとJDKのセクションでそれぞれ選択して、「次へ」をクリックします。

8. 「データベース構成タイプ」画面で、データベースおよびデータベース・スキーマの詳細について指定します。
「RCUデータ」を選択します。このオプションでは、構成ウィザードに対して、データベースおよびサービス表(STB)スキーマに接続し、ドメインの構成に必要なスキーマのスキーマ情報を自動的に取得するように指示します。

この画面で「手動構成」を選択した場合は、「JDBCコンポーネント・スキーマ」画面でスキーマのパラメータを手動で入力する必要があります。

次のフィールドに接続の詳細を指定します。

注意:
11gスキーマと12cスキーマが同じデータベースの同じ場所に配置されていることを確認してください。

表6-6 「データベース構成タイプ」画面のフィールドの説明

フィールド

説明

DBMS/サービス

データベースのDBMS名(サービス・タイプ・ドライバを選択している場合はサービス名)を入力します。

例: orcl.exampledomain.com

ホスト名

データベースをホストするサーバーの名前を入力します。

例: examplehost.exampledomain.com

ポート

データベースがリスニングするポート番号を入力します。

例: 1521

スキーマ所有者およびスキーマ・パスワード

RCUを使用してスキーマを作成したときに指定した、データベースのサービス表スキーマに接続するためのユーザー名とパスワードを入力します。

デフォルトのユーザー名はprefix_STBです。prefixは、RCUで定義したカスタム接頭辞です。

「RCU構成の取得」をクリックします。

「接続結果ログ」の次の出力は、操作が成功したことを示します。「OK」をクリックして、次の画面に進みます。

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK

Successfully Done.

9. 「JDBCコンポーネント・スキーマ」画面で、データベース・スキーマの詳細を確認または指定します。
すべてのスキーマの値が正しいことを確認します。「データベース構成タイプ」画面で「RCUデータ」を選択した場合、スキーマ表はすでに正しく入力されています。

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

10. 「JDBCコンポーネント・スキーマ・テスト」画面を使用して、データ・ソース接続をテストします。
「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから、「選択された接続のテスト」をクリックして接続テストを再試行してください。

デフォルトでは、スキーマの作成時に指定したパスワードが、各スキーマ・コンポーネントのスキーマ・パスワードです。スキーマ・コンポーネントに応じて異なるパスワードを使用する場合は、前の画面(「JDBCコンポーネント・スキーマ」)で各行の「スキーマ・パスワード」列に使用するパスワードを入力して手動で編集します。パスワードを指定した後、パスワードを変更したスキーマに対応するチェック・ボックスを選択し、再度接続をテストします。

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

11. 「拡張構成」画面を使用して、ドメイン構成を完了します。拡張構成を実行するオプションを選択して、「次へ」をクリックします。

表6-7 「拡張構成」画面のオプション

オプション

説明

管理サーバー

管理サーバーのリスニング・アドレスを適切に構成するために必要です。

ノード・マネージャ

ノード・マネージャを構成するために必要です。

トポロジ

WebCenter Sites管理対象サーバーを構成するために必要です。

12. 「管理サーバー」画面で、「サーバー名」フィールドにサーバー名を指定します。
「リスニング・アドレス」ドロップダウン・リストから、管理サーバーを配置するホストのIPアドレスを選択します。「すべてのローカル・アドレス」は選択しないでください。

「リスニング・ポート」フィールドでは、デフォルト値を保持することも、1から65535の範囲の数値を指定することもできます。カスタム値は、SSLリスニング・ポートおよびCoherenceポートと同じにしないでください。

管理サーバーに「サーバー・グループ」は指定しないでください。

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

13. 「ノード・マネージャ」画面を使用して、構成するノード・マネージャのタイプおよびノード・マネージャ資格証明を選択します。
「ノード・マネージャ・タイプ」には、「ドメインごとのデフォルトの場所」を選択します。

「ノード・マネージャ資格証明」フィールドに、ユーザー名とパスワードを指定します。

14. 「管理対象サーバー」画面では、管理対象サーバーの追加、クローン作成または削除を行ったり、管理対象サーバーにサーバー・グループ(使用可能な場合)を割り当てたりできます。

a. 「リスニング・アドレス」ドロップダウン・リストで、管理対象サーバーを配置するホストのIPアドレスを選択します。単一のIPアドレスにマップされるシステム名またはDNS名を指定することもできます。「すべてのローカル・アドレス」は選択しないでください。

b. セキュリティを有効にするには、「SSLの有効化」をクリックします。

デフォルトで追加される各管理対象サーバーのデフォルトのサーバー・グループは、構成ウィザードによって自動的に入力されます。サーバーをさらに追加する場合は、「サーバー・グループ」ドロップダウン・リストから「WCSITES-MGD-SERVER」を選択します。

サーバー・グループは、定義されたアプリケーション・サービス・グループを、定義された各サーバー・グループにマップすることにより、Fusion Middlewareのアプリケーションおよびサービスを1つ以上のサーバーにターゲット指定します。必要に応じて、特定のアプリケーション・サービス・グループを複数のサーバー・グループにマップすることができます。アプリケーション・サービスを特定のサーバー・グループにマップすると、そのグループに割り当てられているすべてのサーバーが自動的にサービスのターゲットに設定されます。

管理対象サーバーの追加、クローン作成、または削除の詳細を参照するには、「ヘルプ」をクリックしてください。

終了したら、「次へ」をクリックします。

15. 「クラスタ」画面で、「追加」をクリックして新規クラスタを作成します。
クラスタはWebLogic Serverインスタンスのグループであり、それらが連携して動作することにより、アプリケーションに拡張性と高可用性を提供します。クラスタを作成すると、管理対象サーバーをグループ化し、アプリケーションおよびリソースをホストするシングル・ホストとして動作するようにできます。

「クラスタ名」フィールドに、クラスタの名前(wcs_cluster_1など)を指定します。「クラスタ・アドレス」フィールドは空白のままにします。

これを繰り返し、クラスタをもう1つ(wcs_cluster_2など)追加して、「次へ」をクリックします。

詳細は、「ヘルプ」をクリックします。

注意:
Enterprise Manager Fusion Middleware Controlを使用してクラスタを作成することもできます。

16. 「サーバーのクラスタへの割当」画面を使用して、管理対象サーバーを新しいクラスタに割り当てます。

a. 「クラスタ」ペインで、管理対象サーバーを割り当てるクラスタを選択します。たとえば、wcs_cluster_1などです。

b. 「サーバー」次のいずれかの手順を実行して、サーバーをクラスタに割り当てます。

- 「サーバー」ペインでサーバーを1回クリックし、右矢印ボタン(>)をクリックして、選択したクラスタの下に移動させます。

- 「サーバー」ペインでサーバーをダブルクリックし、選択したクラスタの下に移動させます。

c. この手順を繰り返して、すべてのサーバーをクラスタに割り当てます。

注意:
「サーバー」ペインの下には、管理対象サーバーのみが表示されます。管理サーバーはクラスタに割り当てることができないため、リストされません。

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

17. 「Coherenceクラスタ」画面は、インフラストラクチャのインストール時にCoherenceを含めた場合にのみ表示されます。
Coherenceクラスタの名前を「クラスタ名」フィールドに指定します。デフォルト名を保持することもできます。

「クラスタ・リスニング・ポート」をデフォルトのポート番号0のままにして、「次へ」をクリックします。構成後、Coherenceクラスタがドメインに自動的に追加されます。

18. 「マシン」画面で、ドメイン内に新規マシンを作成します。サーバーを起動および停止するためにノード・マネージャを使用するには、マシンが必要です。
「マシン」タブ(Windows)または「UNIXマシン」タブ(UNIX)を選択し、「追加」をクリックして新しいマシンを作成します。

名前フィールドにマシンの名前を指定します。たとえば、wcs_machine_1などです。

「ノード・マネージャ・リスニング・アドレス」フィールドで、管理対象サーバーを構成したマシンのIPアドレスを選択します。

localhostではなく、特定のインタフェースを選択する必要があります。これにより、Coherenceクラスタのアドレスが動的に計算されます。

注意:
既存のドメインを拡張している場合は、既存のマシンにサーバーを割り当てることもできます。新しいマシンが不要な場合は、マシンを作成する必要はありません。

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

19. 「サーバーのマシンへの割当」画面で、管理サーバーと管理対象サーバーを、「マシン」画面で作成した新規マシンに割り当てます。

a. 「マシン」ペインで、管理サーバーと管理対象サーバーを割り当てるマシンを選択します。たとえば、wcs_machine_1などです。

b. 「サーバー」ペインで、次のいずれかの手順を実行して、各サーバーをマシンに割り当てます。

- 「サーバー」ペインでサーバーを1回クリックし、右矢印ボタン(>)をクリックして、選択したマシンの下に移動させます。

- 「サーバー」ペインでサーバーをダブルクリックし、選択したマシンの下に移動させます。

c. この手順を繰り返して、すべてのサーバーをマシンに割り当てます。

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

20. 「仮想ターゲット」画面で、「次へ」をクリックします。

21. 「パーティション」画面で、「次へ」をクリックします。

22. 「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。
画面上の各項目をレビューし、情報が正しいことを確認し、「作成」をクリックしてドメインを作成します。

「表示」ドロップダウン・リストからフィルタ・オプションを選択すると、サマリー・ペインに表示される項目を制限することができます。

変更を行うには、「戻る」をクリックするか、ナビゲーション・ペインで画面を選択して、前の画面に戻ります。ドメイン作成は、「作成」をクリックするまで開始されません。

23. 「構成の進行状況」画面には、ドメイン作成プロセスの進行状況が表示されます。
ドメイン作成が成功した場合は、「次へ」をクリックします。

ドメイン作成が失敗した場合は、エラーをレビューして再試行します。エラーをトラブルシューティングできない場合は、My Oracle Supportに連絡してください。

24. 「構成の終了」画面には、作成したドメインの管理サーバーURLとドメインの場所が表示されます。
以後の操作のために値をメモしておきます。

注意:IBM DB2, WebCenter Sitesでは、Fusion Middleware構成ウィザードによって作成されるデフォルトのデータ・ソースをサポートしません。DB2がサポートするドライバを使用して新しいデータ・ソースを作成する手順:

1. WebCenter Sitesドメインのクラス・パスに、IBM DB2ドライバJARファイルを追加します。

a. WebLogic Server管理サーバーを停止します。

b. ドメインのクラス・パスに追加できる場所に、DB2のdb2jcc.jarおよびdb2jcc_license_cu.jarファイルをコピーします。

c. DOMAIN_HOME/bin/setDomainEnv.shを編集し、# ADD EXTENSIONS TO CLASSPATHSの後に次の行を追加します。
PRE_CLASSPATH="path_to_db2jcc.jar:path_to_db2jcc_license_cu.jar:${PRE_CLASSPATH}"

d. 管理サーバーを起動します。

2. 前述のDB2ドライバを使用して新しいデータ・ソースを作成します。

6.2.5 WebCenter Sitesインスタンスの構成

Oracle WebCenter Sitesドメインを構成した後に、ブラウザベースのWebCenter Sitesコンフィギュレータを実行して、WebCenter Sitesインスタンスを構成できます。 WebCenter Sitesランタイムは、WebCenter Sites、CAS Webアプリケーション(WARファイル)およびクラスタ・メンバー間の共有コンポーネント(configディレクトリ、dataディレクトリおよびデータベース・インスタンス)で構成されています。

次のトピックでは、WebCenter Sitesの構成方法を説明します。

- WebCenter Sitesインスタンスの構成の前提条件
WebCenter Sitesコンフィギュレータを使用する前に、いくつかの前提条件タスクを実行する必要があります。これらのタスクには、OPSSのアクセス権限の付与、キャッシュ・ファイルの変更、および環境のプロパティ値の設定が含まれます。

- コンフィギュレータによるWebCenter Sitesの構成
WebCenter Sitesコンフィギュレータによって、WebCenter Sitesが機能するために必要な表とデータがデータベースに移入されます。コンフィギュレータは、必要なユーザー・アカウントを設定し、データベース・オブジェクトの必要な権限も設定します。

6.2.5.1 WebCenter Sitesインスタンスの構成の前提条件

WebCenter Sitesコンフィギュレータを使用する前に、いくつかの前提条件タスクを実行する必要があります。これらのタスクには、OPSSのアクセス権限の付与、キャッシュ・ファイルの変更、および環境のプロパティ値の設定が含まれます。

WebCenter Sitesを構成する前に、これらの前提条件タスクが完了していることを確認してください。

1. 次のスクリプトを実行して、ORACLE_HOME/wcsites/wcsites_common/lib/sites-security.jarにOracle Platform Security Services資格証明ストアの読取り、書込みおよび削除のアクセス権限を付与します。

- UNIXオペレーティング・システムの場合:
$DOMAIN_HOME/wcsites/bin/grant-opss-permission.sh

- Windowsオペレーティング・システムの場合:
$DOMAIN_HOME\wcsites\bin\grant-opss-permission.bat

スクリプトから入力を要求されたら、WebLogic Server管理者のユーザー名とパスワードを使用します。

Fusion Middleware構成ウィザードでデフォルト(ORACLE_HOME/user_projects/domains/domain_name)以外のドメイン・ホームを指定した場合は、grant-opss-permission.shまたはgrant-opss-permission.batを実行する前に、指定したドメイン名が含まれていることを確認してください。必要に応じて、ファイルを編集してドメイン名を更新します。

2. WebCenter Sitesのconfigディレクトリのcs-cache.xml、ss-cache.xml、linked-cache.xmlおよびcas-cache.xmlファイルを次のように変更します。

a. 次のセクションを見つけます。
<cacheManagerPeerProviderFactory class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory" properties="peerDiscovery=automatic, multicastGroupAddress=230.0.0.0, multicastGroupPort=4444, timeToLive=0" />

b. peerDiscoveryプロパティの値を手動に変更します。

c. ファイルを保存して閉じます。

d. WebCenter Sites管理対象サーバーを起動します。

6.2.5.2 コンフィギュレータによるWebCenter Sitesの構成

WebCenter Sitesコンフィギュレータは、WebCenter Sitesが機能するために必要な表およびデータをデータベースに移入します。コンフィギュレータは、必要なユーザー・アカウントを設定し、データベース・オブジェクトの必要な権限も設定します。

ただし、WebCenter Sitesを11gからアップグレードする場合は、11gの管理ユーザー資格証明と同じ管理ユーザー・アカウントを指定します。

注意:

低速ネットワーク上でWebCenter Sitesを構成する場合は、WebCenter Sitesコンフィギュレータを起動する前に、StuckThreadMaxTimeプロパティの設定をスレッドごとに1000秒に増加します。デフォルト値は600秒です。

ネットワーク関連の問題が発生する可能性のある特定の環境では、WebCenter Sites構成の設定プロセスで、サンプル・サイトのインポート・プロセスの1スレッド当たりの所要時間が600秒を超える可能性があります。これによって、インポート・プロセスまたはインストールが失敗し、ログ・ファイルに複数の例外が記録される可能性があります。サンプル・サイトのインストールが正常に完了するために、設定を1000秒に増加することをお薦めします。

StuckThreadMaxTimeの値を変更するには、ドメインのWebLogic Server管理コンソールで、「サーバー」、「wcsites_server1」、「構成」、「チューニング」の順に移動します。

対応するWebLogicドメインが正常に設定された後、ブラウザ・ベースのWebCenter Sitesコンフィギュレータを実行する手順:

1. (オプション)コンフィギュレータをサイレント・モードで実行するには:

a. DOMAIN_HOME/wcsites/wcsites/config/wcs_properties_bootstrap.iniファイルを編集し、インラインの指示を完了します。

b. WebCenter Sites管理対象サーバーを起動します。

c. 次のコマンドを使用してWebCenter Sitesの構成プロセスを開始します。

- UNIXオペレーティング・システム: xdg-open http://sites-host:sites-port/sites/sitesconfig

- Windowsオペレーティング・システム: start http://sites-host:sites-port/sites/sitesconfig

2. Webサーバー上でWebCenter Sitesを構成するには、WebCenter Sitesの構成を開始する前に、Webサーバーのtimeout値を300 secに増加します。

3. (オプション) 管理インタフェースのプロパティ管理ツールを使用して、環境に応じて次のプロパティの値を設定します。これらのプロパティは、NIOデータベース・ベースのファイル・システムを使用するクラスタに設定します。ファイルをデフォルトの場所(DOMAIN_HOME/wcsites/wcsites/config下の個別フォルダ)以外に保存する場合は、WebCenter Sitesが稼働中になるとそれを変更できなくなるため、その場所をプロパティ値として指定します。

プロパティ

説明

xcelerate.transformpath

WebCenter Sitesのアセットに変換される前に、Microsoft Wordのファイルが保存されているディレクトリ。

cs.pgcachefolder

非推奨。Oracleサポートから指示された場合にのみ設定します。

cs.xmlfolder

HTMLレンダリングのための作業ディレクトリ。

cs.pgexportfolder

ディスクへのエクスポートの配信タイプによりアセットを公開するときに作成されるHTMLファイルのベース・エクスポート・ディレクトリ。

vis.path

WebCenter Sitesがインストールされているディレクトリ。末尾のスラッシュを含める必要があります。

mwb.path

WebCenter Sitesがインストールされているディレクトリ。末尾のスラッシュを含める必要があります。

contentserver.installation.folder

WebCenter Sitesがインストールされているディレクトリ。末尾のスラッシュを含める必要があります。Satellite ServerとWebCenter Sitesが同じWebアプリケーションで実行するため、ユーザーのセッションを共有する必要がある場合のインストールに適用されます。これを指定すると、Satellite ServerがWebCenter Sitesのリソースにアクセスできます。

cs.csdtfolder

WebCenter Sitesの開発者ツールのインポートが格納されるディレクトリ。

前述のプロパティの詳細は、Oracle WebCenter Sitesプロパティ・ファイル・リファレンスを参照してください。

4. WebCenter Sitesプライマリ・クラスタ・ノードの管理対象サーバーを起動します。

5. Webブラウザで、このURLにアクセスします: http://sites-host:sites-port/sites/sitesconfigsetup。

6. 表示されるWebCenter Sitesコンフィギュレータの画面で、「開始」をクリックします。

7. 「データベース・パラメータ」画面で、WebCenter Sitesデータベース・リポジトリの「JNDI DataSource名」を指定します。これは、WebLogicドメインの設定時にリポジトリ作成ユーティリティを使用して作成したリポジトリです。

8. 「Webアプリケーション・パラメータ」画面で、安全な接続を介してインストールしている場合は「はい」を選択し、すべてのパラメータをデフォルトの(事前に移入された)値のままにし、「次」をクリックします。

9. 「CASデプロイメント情報」画面で、すべてのパラメータをデフォルトの(事前に移入された)値のままにし、「次」をクリックします。ロード・バランシングのためにクラスタとフロントエンドWebサーバーを使用している場合は、環境に応じてこれらの値を調整します。

10. 「WebCenter Sites管理者アカウント」画面で、必要な資格証明を指定し、「次」をクリックします。

11. (オプション) WebCenter Sitesのインストール時に「WebCenter Sites - 例」インストール・オプションを選択した場合、「サンプル・サイト」画面が表示されます。この画面で、目的のサンプル・サイトを選択し、「次」をクリックします。

12. 「構成サマリー」画面で「テスト」をクリックし、すべてのテストが成功しているかどうかを確認します。「開始」をクリックし、構成プロセスが完了するのを待ちます。

13. WebCenter Sitesアプリケーションの管理対象サーバーを再起動します。

14. Webブラウザで次のURLにアクセスしてログインし、WebCenter Sitesが稼働中かどうかを確認します: http://sites-host:sites-port/sites。

注意:
cas.logのデフォルトの場所は、DOMAIN_HOME/servers/wcsites_server1/logs/です。

XMLPostとBulkloaderが稼働するためには、CLASSPATH環境変数に次のディレクトリを設定します。

ORACLE_HOME\wcsites\webcentersites\sites-home\lib\*
ORACLE_HOME\oracle_common\modules\clients\*

追加のクラスタ・ノードを構成する方法の詳細は、「クラスタの設定」を参照してください。

外部LDAP認証プロバイダの構成方法の詳細は、「LDAPディレクトリに対する認証への切替え」を参照してください。

Oracle Access Managerの統合を構成する方法の詳細は、「Oracle Access Managerに対する認証への切替え」を参照してください。

WebCenter Sites構成のインポート/エクスポート・ユーティリティの使用方法の詳細は、Oracle WebCenter Sitesプロパティ・ファイル・リファレンスのプロパティ管理ツールの使用に関する項を参照してください。

6.2.6 構成後のタスク

WebCenter Sites12cを構成した後に、このトピックにリストされているタスクを実行します。

1. 既存のSites 11.1.1.8環境がLDAPベースまたはOAMベースの認証を使用して構成されている場合は、12.2.1.1環境も同じように構成します。
LDAPベースの認証に切り替えるには、「LDAPディレクトリに対する認証への切替え」を参照してください。
LDAPベースの認証に切り替えるには、「Oracle Access Managerに対する認証への切替え」を参照してください。

2. ディレクトリ構造を確認します。Oracleホーム(製品のバイナリが含まれる)、Sitesホーム(ドメインおよび構成データ)、およびSites共有ディレクトリが、WebCenter Sitesの構成後に作成されている必要があります。

3. 管理者の資格証明を使用してSites UIにサインインします。

4. 管理対象サーバーを再起動してWebCenter Sitesにアクセスします。

- LDAPディレクトリに対する認証への切替え
このトピックでは、WebCenter Sitesを外部LDAP認証プロバイダ・ディレクトリに対する認証に切り替える方法について説明します。Oracle Access Managementとの統合を実行できない場合、これは本番環境のための推奨のソリューションです。

- Oracle Access Managerに対する認証への切替え
Oracle Access Managerに対する認証を行うようにWebCenter Sitesを構成できます。これは本番環境のための推奨のソリューションです。

6.2.6.1 LDAPディレクトリに対する認証への切替え

このトピックでは、WebCenter Sitesを外部LDAP認証プロバイダ・ディレクトリに対する認証に切り替える方法について説明します。Oracle Access Managementとの統合を実行できない場合、これは本番環境のための推奨のソリューションです。

認証プロバイダを変更する前に、WebCenter Sitesをインストールし構成してください。

WebCenter Sitesを外部LDAPディレクトリに対する認証に切り替える手順:

1. (オプション) LDAPディレクトリが大/小文字を区別する場合は、DOMAIN_HOME/wcsites/wcsites/config/wcs_properties.jsonファイルのldap.caseAwareプロパティをtrueに設定します。

2. LDAPコンフィギュレータにアクセスし(http://sites-host:sites-port/sites-context/ldapconfig)、画面に表示される指示に従って、使用する環境に応じて値を入力します。

3. LDAPのロールバックの場合は、WebCenter Sites管理対象サーバーを再起動し、同じLDAPコンフィギュレータURLにアクセスします。

現在は、手動によるLDAP統合のみがあります。LDAPサーバーへの書込みはなく、DOMAIN_HOME/wcsites/wcsites/config/ldapフォルダ下にLDIFファイルのみが作成されます。peopleparent、groupparent、usernameおよびその他のフィールドは、以前のリリースのように事前移入されません。

4. 使用する環境に応じて、DOMAIN_HOME/wcsites/wcsites/config/にあるLDIFファイルの値を変更します。

フィールドが事前移入されていないので、次のORACLEDIRの例に従ってください:

ldap server type -- ORACLEDIR
ldap DSN -- dc=oracle,dc=com
ldap host -- localhost
ldap port -- 389
ldap username -- cn=orcladmin
ldap password -- password
ldap peopleParent -- cn=Users,dc=oracle,dc=com
ldap groupparent -- cn=Groups,dc=oracle,dc=com

5. 使用しているLDAPサーバーが大/小文字を区別する場合は、DOMAIN_HOME/wcsites/wcsites/config/wcs_properties.jsonプロパティ・ファイルを編集してldap.caseAwareプロパティの値をtrueに変更します。

デフォルトでは、ldap.caseAwareの値はfalseに設定されています。大/小文字を区別するLDAPサーバーを使用しているとき、このプロパティがfalseに設定されている場合、ログインに失敗します。

注意:
SitesとLDAPを統合する際、LDAP内のユーザー・データがカンマで区切られている場合(例: test,user)、そのデータはフェッチされません。このデータを取得するには、..sites/installディレクトリにあるdir.iniファイルの構文を、"syntax.escape=\\からsyntax.escape=\#"に変更する必要があります。

6. Oracle Virtual DirectoryをLDAP認証プロバイダとして選択すると、WebCenter Sitesに生成されるLDIFファイルをOracle Internet Directoryサーバーにインポートし、Oracle Virtual Directoryにアダプタを作成してOracle Internet Directoryサーバーに接続できます。

Oracle Virtual DirectoryのLDAPサーバーにはそれ独自の記憶域がないので、LDIFファイルを直接にOracle Virtual Directoryにインポートすることはできません。

7. 外部LDAP認証プロバイダにLDIFファイルをインポートします。

8. このWebCenter Sitesインスタンスを実行しているWebLogic管理対象サーバーを再起動します。

6.2.6.2 Oracle Access Managerに対する認証への切替え

Oracle Access Managerに対する認証を行うようにWebCenter Sitesを構成できます。これは本番環境のための推奨のソリューションです。

WebCenter Sitesとの統合は、Oracle Access Manager 11.1.2.2.0および11.1.2.3.0でサポートされます。

WebCenter SitesをOracle Access Managerに対する認証に切り替える手順:

1. ターゲットWebCenter Sitesインスタンスが含まれているWebLogicドメインに、ORACLE_HOME/wcsites/webcentersites/sites-homeにあるoamlogin.warおよびoamtoken.warアプリケーション・ファイルをデプロイします。

2. 次のプロパティ・ファイルを作成します: DOMAIN_HOME/wcsites/wcsites/config/wemsites_settings.properties

3. wemsites_settings.propertiesファイルに、次のように入力します。

要素

プロパティ

oamredirect

http://oam_server_host:oam_port/oam/server/auth_cred_submit

oamlogout

oamlogout=http://oam_server_host:oam_port/oam/server/logout

forgotpassword

helpdesk-email-address

4. DOMAIN_HOME/wcsites/wcsites/config/SSOConfig.xmlに次のプロパティを設定します。

要素

プロパティ

serviceUrl

http://{ohs_server_host}:{ohs_port}/{sites_context_root}/REST

ticketUrl

http://{oamtoken_server_host}:{oamtoken_port}/oamtoken

signoutURL

http://{oam_server_host}:{oam_port}/oam/server/logout?end_url={end_url}

このURLを使用して、WebCenter Sitesのログアウトを呼び出します。これには、Oracle Access Managerによるすべてのログアウト処理が完了した後にブラウザから戻される、エンコードされたURLが含まれます。

end_url

テスト(ステージング)環境: http%3A%2F%2F{ohs_server_host}%3A{ohs_port}%2F{sites_context_root}%2Fwem%2Ffatwire%2Fwem%2FWelcome

本番(デリバリ)環境: http%3A%2F%2F{ohs_server_host}%3A{ohs_port}%2F{sites_context_root}%2FXcelerate%2FLoginPage.html

dbUsername

WebCenter Sitesの一般管理者のユーザー・アカウント名。

dbPassword

WebCenter Sitesの一般管理者のユーザー・アカウントのパスワード。

trustConfigured

WebCenter Sites管理対象サーバーとOracle Access ManagementのOracle HTTP ServerのWebゲートとの間に信頼関係が確立されているかどうかをWebCenter Sitesに指定します。この2つの間に信頼関係が存在する場合、すべてのリクエストにIDアサーションを含める必要がなくなります。信頼関係が存在する場合はtrue、そうでない場合はfalseに設定します。

5. Oracle Access ManagerインスタンスのobAccsessClient.xmlおよびcwallet.ssoファイルを、ターゲットWebCenter Sitesインスタンス上のDOMAIN_HOME/wcsites/wcsites/config/oblix/lib/ディレクトリにコピーします。

6. 互換性モードとoblixパスを設定するために、sites-configディレクトリのoamtoken.xmlファイルを編集します。互換性モードは11Gに設定し、oblixパスはoblix/libフォルダが含まれているsites-configフォルダに設定します。

7. WebCenter SitesのためのOracle Access Managerの構成で、保護リソース、パブリック・リソースおよび除外リソースを次のように更新します。

###########################
protected_uris
###########################
/oamlogin/test
/sites/Xcelerate/LoginPage.html
/sites/Satellite/.../*
/sites/faces/jspx/.../*
/sites/wem/fatwire/.../*
/sites/ContentServer/.../*
/sites/wem/fatwire/wem/Welcome
/console

###########################
Exclusion Scheme    OraDefaultExclusionAuthNScheme
/sites/REST
/index.html
/oamlogin/oamsso/.../*
/sites/wem/fatwire/home
/sites/**

詳細は、エンタープライズ・デプロイメントの保護、パブリックおよび除外リソースの更新に関する項を参照してください。

8. Weblogic ServerにOAMSDKクライアントをoamtoken.warアプリケーションとして統合するために、WebCenter Sitesドメインのjps-config.xmlファイルを編集します。このファイルは、WebLogic Server 12 cの起動スクリプトの一部であり、デフォルトでは、WebLogicドメインはこのファイルを使用して実行されます。

-Doracle.security.jps.config=ORACLE_HOME/user_projects/domains/DOMAIN_NAME/config/fmwconfig/jps-config.xml

a. 次の例に示すように、既存のjsp-config.xmlファイル内の既存のサービス・インスタンスの隣に、サービス・インスタンスを追加します。
<serviceInstance name="credstore.oamtoken" provider="credstoressp" location="./oamtoken">

<description>File Based Credential Store Service Instance</description>

<property name="location" value="./oamtoken"/>

</serviceInstance>

locationは、cwallet.ssoファイルを含むディレクトリのパスです。前述の例では、このパスは、現在のjsp-config.xmlファイルへの参照に設定されています。omtokenフォルダが、現在のディレクトリを基準にして作成され、そこにcwallet.ssoファイルが配置されていることを確認してください。locationの値は、cwallet.ssoファイルが配置されている場所への絶対パスにすることもできます。

b. <jpsContext name="default">の下に、<serviceInstanceRef ref="credstore.oamtoken"/>を追加します。

c. <jpsContexts default="default">の下に、次の<jpsContext>要素を追加します。
<jpsContext name="OAMASDK">

<serviceInstanceRef ref="credstore.oamtoken"/>

</jpsContext>

9. oamtoken.warのコードを使用できるように権限を追加します。
クライアントは、Oracle Access Managerに作成されたWebゲートにアクセスします。セキュリティの制約に対処するために、WebCenter Sitesドメインに資格証明を追加する必要があります。

a. wlst.shスクリプトでWebLogic Scripting Toolを起動します。
cd ORACLE_HOME/oracle_common/common/bin/./wlst.sh

b. WebCenter Sitesドメインの管理サーバーに接続します。
connect('user-name','password','sites-host:admin-port')

c. 権限を付与します。
grantPermission(codeBaseURL="file:/scratch/idc/newoam/rend/Oracle_Home/user_projects/domains/renddomain/servers/wcsites_server1/tmp/_WL_user/oamtoken/-", permClass="oracle.security.jps.service.credstore.CredentialAccessPermission",permTarget="context=SYSTEM,mapName=OAMAgent,keyName=*",permActions="*")

基本的に、前述のパスは、WebLogic Serverのoamtoken.warアプリケーションが展開されている場所へのパスです。

d. ターゲットWebCenter Sites管理対象サーバーを再起動します。

10. (オプション) WebCenter SitesとOracle Access Managerの間の信頼が確立していない場合は、WebCenter SitesのWeb層の設定を次のように変更します。

a. Oracle Access Managerコンソールにログインします。

b. Webゲートの認可ポリシー(保護されたリソースのポリシーの下)の「レスポンス」タブに移動します。

c. 「IDアサーション」チェック・ボックスを有効化(選択)します。

d. 「適用」をクリックして、変更を保存します。

11. (オプション) WebCenterSitesがOAM統合を使用するクラスタにデプロイされている場合。次の手順がoamticketcacheキャッシュにレプリケートされている必要があります。

a. configディレクトリにあるcas-cache.xmlには、oamticketcacheがデフォルトで構成されています。

b. oamticketcacheという名前のキャッシュ内で、次のように表示されるコメント化されたセクションのコメントを解除します。

<cacheEventListenerFactory
class="net.sf.ehcache.distribution.RMICacheReplicatorFactory"
properties="replicateAsynchronously=true, replicatePuts=true,
replicateUpdates=true,
replicateUpdatesViaCopy=false, replicateRemovals=true"/>
<bootstrapCacheLoaderFactory
class="net.sf.ehcache.distribution.RMIBootstrapCacheLoaderFactory"
properties="bootstrapAsynchronously=false,
maximumChunkSizeBytes=5000000"
propertySeparator="," />

c. cacheManagerPeerProviderFactoryを次のように修正し、ポートが一意であることを確認してください。

<cacheManagerPeerProviderFactory
class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
properties="peerDiscovery=automatic,
multicastGroupAddress=230.0.0.8,
multicastGroupPort=40002, timeToLive=1" />

d. 前の手順で指定したように、cacheManagerPeerProviderFactoryとcacheManagerPeerListenerFactoryのポートは異なるものである必要があります。

e. 両方のプロパティについて、すべてのクラスタ・ノードのポートが同じである必要があります。

12. このWebCenter SitesインスタンスをホストしているWebLogic管理対象サーバーを再起動します。

6.2.6.2.1 サイト・キャプチャとOracle Access Managerの統合

サイト・キャプチャとOAMを統合するには、次の手順を実行します。

1. Protected Resource Policyの構成:

a. 「アプリケーション・ドメイン」、「開く」の順にクリックします。

b. 「検索」→WCSitesWebGateおよび「認証ポリシー」タブをクリックします。

c. 「保護されたリソース・ポリシー」をクリックします。
「認証スキーム」にLDAPWemSchemeを選択します。以前に認証スキームが作成されていることを確認してください。

d. 「レスポンス」タブをクリックします。

e. 「IDアサーション」オプションを選択します。

f. 認証ポリシーが承認されると、レスポンスが作成されます。レスポンスは、WebCenter SitesのHTTPフィルタでLDAP属性を識別し、認証済ユーザーについての情報を提供するために必要です。レスポンスを作成するには、次の手順を実行します。

a. 「追加」をクリックします。

b. 「名前」フィールドに「FATGATE_CSTIMEOUT」を入力します。

c. 「タイプ」でHeaderを選択します。

d. 「ヘッダー値」として30を入力します。

2. 次の手順に従ってリソースを追加します。

a. 「アプリケーション・ドメイン」をクリックします。

b. 「開く」をクリックします。

c. 「検索」をクリックします。

d. WCSitesWebGate→「リソース」→「検索」および「作成」を選択します。

e. 「タイプ」にHTTPホストを入力します。

f. 「ホスト識別子」にWCSitesWebGateを入力します。

g. 「リソースURL」に「/__admin/**」を入力します。

h. 「保護レベル」を「保護」に設定します。

i. 「認証ポリシー」および「認可ポリシー」に保護されているリソース・ポリシーを設定します。

6.2.7 アップグレード・アシスタントを実行する前に

アップグレード・アシスタントを実行して11.1.1.8.0のドメインをアップグレードする前に、このトピックにリストされているタスクを実行します。

アップグレード・アシスタントを実行する前に、次のことを実行します。

1. 既存のSites 11.1.1.8環境がクラスタ化構成である場合は、プライマリ・ノードを12.2.1.1にアップグレードしてターゲットのクラスタ設定を再構成するか、すべてのクラスタ・メンバーをアップグレードします。
すべてのクラスタ・メンバーをアップグレードするには、次の手順を実行してクラスタ・ノードを登録します。

a. Sitesの管理サーバーURLにサインインします。

b. 「管理」に移動し、「システム・ツール」の下の「クラスタ・ノード管理」をクリックします。

c. 各クラスタのノード名をソース環境に従って構成します。
この手順で構成したノードは、アップグレード・プロセスでの処理中に、最終的には対応する11.1.1.8のノードにマップされます。

2. ソース(11.1.1.8)およびターゲット(12.2.1.1)の、管理サーバーと管理対象サーバーのインスタンスを停止します。

3. ソース(11.1.1.8)とターゲット(12.2.1.1)が異なる物理マシン上にある場合は、アップグレード・プロセスを開始する前に、次のソース・インストール・ディレクトリをターゲットに移行しておくことをお薦めします。
ソースのインストール・ディレクトリをターゲット・マシンに移行しておくと、アップグレードの処理時間を短縮できます。

- Sites 11.1.1.8.0のSitesインストール/ホーム

- Sites 11.1.1.8.0のSites共有

- Sites 11.1.1.8.0のデプロイ済Sites warのWebアプリケーション・パス

4. 既存のSites 11.1.1.8環境がクラスタ環境である場合は、ソース・マシンからターゲット・マシンにノードを移行します。
ソース・インスタンス・ディレクトリは、どのような順序で移行してもかまいません。次に例を示します。

ソース環境が2つのノードのクラスタ設定である場合は、「クラスタ・ノード管理」の処理中にノードの登録で指定した名前の、2つのディレクトリを作成します。 たとえば、ノードの登録で指定したノード名がNodeAとNodeBである場合は、ターゲット・マシンにNodeAとNodeBの2つのディレクトリを作成します。

ソース・データをターゲット・マシンに次の形式でコピーします。

NodeA (Primary node)
Sites-install/Home
Sites-Shared
Location of deployed sites war
NodeB (Secondary node)
Sites-install/Home
Location of deployed sites war

注意:
Sites-Sharedをノードごとにコピーする必要はありません。

5. ソース・スキーマ(11g)とターゲット・スキーマ(12c)が同じデータベース・サーバーに配置されていることを確認してください。

Oracle
<Single DB Instance>
11g schema
12c schema

MS SQL Server
<Single DB Instance>
11g schema
12c schema

DB2
<Single DB Instance>
11g schema
12c schema

6. Oracleユーザーである場合は、アップグレードを実行するために、非SYSDBAユーザーを作成する必要があります。非SYSDBAユーザーを作成するには、アップグレード・アシスタントを実行するための非SYSDBAユーザーの作成を参照してください。

7. DB2ユーザーである場合は、アップグレードを開始する前に、次の事項を考慮してください。

- スキーマのアップグレードを開始する前に、Sites 11.1.1.8.0のスキーマをソース・データベースからターゲット・データベース(12.2.1.1.0のSitesスキーマが設定されている)にインポートします。手順の詳細は、DB2ソースから新規ターゲット・データベースへの11.1.1.8スキーマのコピーを参照してください。

- アップグレード・プロセスでの処理中に既存のSites 11.1.1.8.0ランタイムへの影響が生じないように、DB2データベースを同じマシンにインポートします。

- ソース・スキーマとターゲット・スキーマが単一のDBインスタンスに存在するため、スキーマのアップグレード・プロセスでの処理中は、ターゲット・データベースのインスタンス詳細とスキーマ詳細を指定します。

8. 11gのソース・スキーマからのデータ移行が正常に完了するように、12.2.1.1のターゲット・スキーマの表領域サイズに十分な容量があることを確認してください。デフォルトのターゲット・スキーマ・サイズは、RCUによって5 GBに設定されます。ソース・スキーマのサイズにあわせて表領域を調整できます。

- アップグレード・アシスタントを実行するための非SYSDBAユーザーの作成
アップグレード・アシスタントを実行するための、FMWという非SYSDBAユーザーを作成することをお薦めします。FMWユーザーにはスキーマ変更に必要な権限はありますが、完全な管理者権限はありません。

- DB2ソースから新規ターゲット・データベースへの11.1.1.8スキーマのコピー
スキーマをアップグレードする前に、Sites 11.1.1.8のスキーマをソースDB2データベースからターゲット・データベース(12.2.1.1のSitesスキーマが設定されている)にインポートする必要があります。

6.2.7.1 アップグレード・アシスタントを実行するための非SYSDBAユーザーの作成

アップグレード・アシスタントを実行するための、FMWという非SYSDBAユーザーを作成することをお薦めします。FMWユーザーにはスキーマ変更に必要な権限はありますが、完全な管理者権限はありません。

SYSDBAはデータベースの作成、起動、停止、バックアップまたはリカバリなどの高度な管理操作を実行するために必要な管理権限です。SYSDBAシステム権限は、完全な権限を持つデータベース管理者が使用します。SYSDBA権限で接続すると、通常はユーザー名に関連付けられているスキーマではなく、デフォルトのスキーマで接続が確立されます。SYSDBAの場合、このスキーマはSYSです。デフォルト・スキーマへのアクセスは非常に強力な権限となる場合があります。たとえば、ユーザーSYSとして接続する場合、データ・ディクショナリの表における権限は無制限となります。したがって、スキーマをアップグレードするには、非SYSDBAユーザーを作成することをお薦めします。アップグレード・アシスタントを起動する前に、このトピックにリストされている権限を付与する必要があります。

注意:
v$xatrans$表は、デフォルトでは存在しません。ユーザーを作成する前に、XAVIEW.SQLスクリプトを実行して、この表を作成する必要があります。また、v$xatrans$表に対する権限付与が必要なのはOracle Identity Managerの場合のみです。構成にOracle Identity Managerが必要ない場合、またはv$xatrans$表が存在しない場合は、次の行をスクリプトから削除します。

grant select on v$xatrans$ to FMW with grant option;

次の例では、welcome1がパスワードです。権限を付与する際に、実際のパスワードを指定していることを確認します。

create user FMW identified by welcome1;
grant dba to FMW;
grant execute on DBMS_LOB to FMW with grant option;
grant execute on DBMS_OUTPUT to FMW with grant option;
grant execute on DBMS_STATS to FMW with grant option;
grant execute on sys.dbms_aqadm to FMW with grant option;
grant execute on sys.dbms_aqin to FMW with grant option;
grant execute on sys.dbms_aqjms to FMW with grant option;
grant execute on sys.dbms_aq to FMW with grant option;
grant execute on utl_file to FMW with grant option;
grant execute on dbms_lock to FMW with grant option;
grant select on sys.V_$INSTANCE to FMW with grant option;
grant select on sys.GV_$INSTANCE to FMW with grant option;
grant select on sys.V_$SESSION to FMW with grant option;
grant select on sys.GV_$SESSION to FMW with grant option;
grant select on dba_scheduler_jobs to FMW with grant option;
grant select on dba_scheduler_job_run_details to FMW with grant option;
grant select on dba_scheduler_running_jobs to FMW with grant option;
grant select on dba_aq_agents to FMW with grant option;
grant execute on sys.DBMS_SHARED_POOL to FMW with grant option;
grant select on dba_2pc_pending to FMW with grant option;
grant select on dba_pending_transactions to FMW with grant option;
grant execute on DBMS_FLASHBACK to FMW with grant option;
grant execute on dbms_crypto to FMW with grant option;
grant execute on DBMS_REPUTIL to FMW with grant option;
grant execute on dbms_job to FMW with grant option;
grant select on pending_trans$ to FMW with grant option;
grant select on dba_scheduler_job_classes to fmw with grant option;
grant select on SYS.DBA_DATA_FILES to FMW with grant option;
grant select on SYS.V_$ASM_DISKGROUP to FMW with grant option;
grant select on v$xatrans$ to FMW with grant option;
grant execute on sys.dbms_system to FMW with grant option;
grant execute on DBMS_SCHEDULER to FMW with grant option;
grant select on dba_data_files to FMW with grant option;
grant execute on UTL_RAW to FMW with grant option;
grant execute on DBMS_XMLDOM to FMW with grant option;
grant execute on DBMS_APPLICATION_INFO to FMW with grant option;
grant execute on DBMS_UTILITY to FMW with grant option;
grant execute on DBMS_SESSION to FMW with grant option;
grant execute on DBMS_METADATA to FMW with grant option;
grant execute on DBMS_XMLGEN to FMW with grant option;
grant execute on DBMS_DATAPUMP to FMW with grant option;
grant execute on DBMS_MVIEW to FMW with grant option;
grant select on ALL_ENCRYPTED_COLUMNS to FMW with grant option;
grant select on dba_queue_subscribers to FMW with grant option;
grant execute on SYS.DBMS_ASSERT to FMW with grant option;

注意:

Oracle Database 11.2.0.3データベース・ユーザーのみ: アップグレードを開始する前に、Oracleパッチ13036331を適用する必要があります。My Oracle Supportにアクセスしてパッチをダウンロードします。

このパッチを適用しない場合は、一部のスキーマで追加の権限を付与する必要があります。

6.2.7.2 DB2ソースから新規ターゲット・データベースへの11.1.1.8スキーマのコピー

スキーマをアップグレードする前に、Sites 11.1.1.8のスキーマをソースDB2データベースからターゲット・データベース(12.2.1.1のSitesスキーマが設定されている)にインポートする必要があります。

インポート操作が正常に実行されるように、次の基準を考慮してください。

- データベースのインポートを実行するユーザーに、ターゲット・データベースに対する必要な権限が付与されていることを確認します。

- ターゲット・データベースのAPPLHEAPSZを、スキーマ・サイズに対応した適切な値に設定します。

Sites 11.1.1.8のスキーマをソース・データベースからターゲット・データベースにコピーするには、次の手順を実行します。

1. データベース・ディレクトリを作成した場所から、次のコマンドを入力します。
$ db2move <old_db> COPY -sn <schemaname> -co TARGET_DB <targetDB> user <username> using <password>

表6-8 DatabaseMovementコマンドのパラメータ

パラメータ

説明

db2move

データベース移動ツール・コマンド。DB2データベース内の表をソース・システムからターゲット・システムに移動するために使用します。

old_db

ソース・システムの既存のデータベースの名前を指定します。

COPY

データベース移動ツールがコピー操作を実行することを示します。

schemaname

ソース・システムの既存のデータベースのスキーマ名を指定します。

targetDB

ターゲット・データベースの名前を指定します。

username

ユーザー名を指定します。

password

パスワードを指定します。

次に例を示します。

$ db2move dot8db COPY -sn dot8schema -co TARGET_DB 12cdb user dot8user using test1234

2. 次の手順を実行して、コピー操作が成功したことを確認します。

a. DB2コンソールにサインインします。

b. 新規(ターゲット)データベースに接続します。

c. データが正しくコピーされたことを確認するために、表のリストと問合せを行います。

3. アップグレードの前に、DB_SITE (RCU 12c Sitesユーザー)に必要な権限を付与します。

6.2.8 アップグレード・アシスタントを使用したスキーマのアップグレード

アップグレード・アシスタントを使用して、11gのスキーマをアップグレードする必要があります。

11g のスキーマをアップグレードするには、次の手順を実行します。

1. 12.2.1.1のOracleホームから次のコマンドを入力して、アップグレード・アシスタントを実行します。
UNIXオペレーティング・システムの場合:

$Oracle_Home/oracle_common/upgrade/bin/ua

Windowsオペレーティング・システムの場合:

%Oracle_Home%\oracle_common\upgrade\bin\ua.bat

2. 「ようこそ」画面には、アップグレード・アシスタントの概要と、重要なアップグレード前のタスクに関する情報が表示されます。「次」をクリックします。
アップグレード・アシスタントの使用の詳細を参照するには、アップグレード・アシスタントの画面で「ヘルプ」をクリックします。

3. 「選択したスキーマ」画面で「個別に選択されたスキーマ」を選択し、「次」をクリックします。
スキーマのアップグレード対象になるコンポーネントはアップグレード・アシスタントによって識別され、ユーザーがアップグレードに含めるスキーマを選択できるようになります。

4. 「使用可能なコンポーネント」画面には、アップグレード可能なスキーマがあるインストール済のOracle Fusion Middlewareコンポーネントのリストが表示されます。
コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。

「Oracle WebCenter Sites」を選択し、「次」をクリックします。

5. 「前提条件」画面ですべてのチェック・ボックスを選択し、前提条件を満たしていることを確認応答します。「次」をクリックします。

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

6. 「WebCenter Sitesソース・バージョン」画面で11.1.1.8.0を選択し、「次」をクリックします。これはアップグレードの開始ポイントです。

7. 「WebCenter Sitesの場所」画面で、既存のSitesホームおよびSites共有ディレクトリの完全な場所と、12cの構成ファイル(wcs_properties.json)の場所を指定します。
「次へ」をクリックします。

8. 「WebCenter Sitesソース・スキーマ」画面で、「データベース・タイプ」ドロップダウン・リストからデータベース・タイプを選択します。
「データベース接続文字列」フィールドに、データベース接続文字列をhost_name:port/service_nameの形式で指定します。

「DBAユーザー名」フィールドに、ユーザー名とDBA権限を指定します。たとえば、sys as SYSDBAなどです。「DBAパスワード」フィールドに、DBAパスワードを指定します。

「スキーマ・ユーザー名」フィールドと「スキーマ・パスワード」フィールドに、スキーマのユーザー名とパスワードをそれぞれ指定します。

Oracle Databaseを使用している場合:

a. WCSITESスキーマ・ページに、12cのスキーマの詳細を入力します。

b. ドロップダウン・リストからスキーマ・ユーザー名を選択します。

c. パスワードを入力して次に進みます。

d. WCSITES_SOURCEスキーマ・ページに、Sites 11.1.1.8.0のスキーマの詳細を入力します。

e. 11.1.1.8.0の表を持つスキーマのスキーマ・ユーザー名とパスワードを更新します。

SQL Serverを使用している場合:

a. WCSITESスキーマ・ページに、12cのスキーマの詳細を入力します。

b. ドロップダウン・リストからスキーマ・ユーザー名を選択します。ドロップダウン・リストには、RCUによって作成されたWebCenter Sitesスキーマのみがリストされます。

c. パスワードを入力して次に進みます。

d. WCSITES_SOURCEスキーマ・ページに、Sites 11.1.1.8.0のスキーマの詳細を入力します。dbaユーザーとSitesユーザーを指定する必要があります。

e. WCSITES SourceSchema接頭辞ページに、Sites 11.1.1.8.0のスキーマで使用していたデフォルト接頭辞を入力します。たとえば、接頭辞が"dbo"である場合は、これを使用します。

9. 「調査」画面には、各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証する、アップグレード・アシスタントのステータスが表示されます。ステータスが「調査が終了しました。」である場合は、「アップグレード」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログ・ボックスで「いいえ」をクリックして、アップグレードを取り消すことをお薦めします。「ログの表示」をクリックして、エラーの原因を調査し、アップグレードのトラブルシューティングに関する説明で一般的なアップグレード・エラーの解決方法を参照してください。

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、アップグレード・アシスタントを再起動する前に、アップグレード前の環境をバックアップからリストアする必要があります。

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

10. 「アップグレード・サマリー」画面でツリーを展開し、選択したオプションのサマリーをレビューします。
アップグレードを続行する前に、「ソース・バージョン」と「ターゲット・バージョン」をレビューして、両方のバージョンが正しいことを確認します。

このレスポンス・ファイルは、アップグレード・アシスタントのグラフィカル・ユーザー・インタフェース画面で入力したすべての情報を収集および保存し、後でサイレント・アップグレードを実行することができます。サイレント・アップグレードは、Upgrade Assistantウィザードとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合、「保存」をクリックし、レスポンス・ファイルの名前および場所を指定します。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

11. 「アップグレードの進行状況」画面には、アップグレード・プロセスのステータスと、アップグレードが成功した後のコンポーネントの予測されるターゲット・バージョンが表示されます。「次」をクリックします。

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

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

12. スキーマのアップグレードが成功した場合は、次の場所にサマリー・ファイルが生成されます。
$ORACLE_HOME/oracle_common/upgrade/logs/wcsites_upgrade/schema/Source Version/Database Type/summary.txt

この場合、Source Versionは11.1.1.8.0であり、Database Typeは使用しているデータベースです。

スキーマのアップグレードが失敗した場合は、考えられるエラーをログでレビューします。ログ・ファイルは次の場所に生成されます。

$ORACLE_HOME/oracle_common/upgrade/logs

「閉じる」をクリックしてアップグレード・アシスタントを閉じます。

6.2.9 アップグレード・アシスタントを使用した構成のアップグレード

アップグレード・アシスタントを使用して、11gのドメイン構成をアップグレードする必要があります。

注意:
構成のアップグレードの準備状況チェックは、11gの開始ポイントでは使用できません。

11g のドメインをアップグレードするには、次の手順を実行します。

1. 12.2.1.1のOracleホームから次のコマンドを入力して、アップグレード・アシスタントを実行します。
UNIXオペレーティング・システムの場合:

$Oracle_Home/oracle_common/upgrade/bin/ua

Windowsオペレーティング・システムの場合:

%Oracle_Home%\oracle_common\upgrade\bin\ua.bat

2. 「ようこそ」画面には、アップグレード・アシスタントの概要と、重要なアップグレード前のタスクに関する情報が表示されます。「次」をクリックします。
アップグレード・アシスタントの使用の詳細を参照するには、アップグレード・アシスタントの画面で「ヘルプ」をクリックします。

3. 「すべての構成」画面で「ドメインによって使用されるすべての構成」を選択し、11.1.1.8のドメインの場所を「ドメイン・ディレクトリ」フィールドに直接入力するか、「参照」をクリックしてナビゲーション・ツリーを使用し、有効なドメイン・ディレクトリを選択することで指定します。「次」をクリックします。

4. 「コンポーネント・リスト」画面で、ドメイン内のアップグレード対象のコンポーネントがすべてリストされていることを確認し、「次」をクリックします。
アップグレード対象のコンポーネントが表示されていない場合は、「戻る」をクリックして前の画面に戻り、別のドメインを指定します。

5. 「前提条件」画面ですべてのチェック・ボックスを選択し、前提条件を満たしていることを確認応答します。「次」をクリックします。

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

6. 「WebCenter Sitesソース・バージョン」画面で11.1.1.8.0を選択し、「次」をクリックします。これはアップグレードの開始ポイントです。

7. ソースが単一サーバー環境である場合は、「WebCenter Sitesソースの詳細」画面が表示されます。
「WebCenter Sitesソース・クラスタの詳細」画面で、11.1.1.8.0のSitesインストール・ディレクトリと11.1.1.8.0のSites Webアプリケーションの場所の完全パスを指定し、「アップグレード」をクリックします。

「参照」をクリックして、ナビゲーション・ツリーを使用して特定のディレクトリを選択することもできます。

8. ソースがクラスタ環境である場合は、「WebCenter Sitesソースの詳細」画面が表示されます。
各ノードのSitesインストールとSites Webアプリケーション・ディレクトリを、「Sitesインストール」列と「Sites Webアプリケーション」列にそれぞれ指定します。

「参照」をクリックして、ナビゲーション・ツリーを使用して特定のディレクトリを選択することもできます。

11.1.1.8.0のディレクトリを指定したら、「アップグレード」をクリックします。

注意:
アップグレード・アシスタントにリストされるノード名は、「クラスタ・ノード管理」画面でノードを登録した際に指定した名前です。

9. 「調査」画面には、各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証する、アップグレード・アシスタントのステータスが表示されます。ステータスが「調査が終了しました。」である場合は、「アップグレード」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログ・ボックスで「いいえ」をクリックして、アップグレードを取り消すことをお薦めします。「ログの表示」をクリックして、エラーの原因を調査し、アップグレードのトラブルシューティングに関する説明で一般的なアップグレード・エラーの解決方法を参照してください。

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、アップグレード・アシスタントを再起動する前に、アップグレード前の環境をバックアップからリストアする必要があります。

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

10. 「アップグレード・サマリー」画面でツリーを展開し、選択したオプションのサマリーをレビューします。
アップグレードを続行する前に、「ソース・バージョン」と「ターゲット・バージョン」をレビューして、両方のバージョンが正しいことを確認します。

このレスポンス・ファイルは、アップグレード・アシスタントのグラフィカル・ユーザー・インタフェース画面で入力したすべての情報を収集および保存し、後でサイレント・アップグレードを実行することができます。サイレント・アップグレードは、Upgrade Assistantウィザードとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合、「保存」をクリックし、レスポンス・ファイルの名前および場所を指定します。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

11. 「アップグレードの進行状況」画面には、アップグレード・プロセスのステータスと、アップグレードが成功した後のコンポーネントの予測されるターゲット・バージョンが表示されます。「次」をクリックします。

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

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

12. 構成のアップグレードが成功した場合は、次の場所にサマリー・ファイルが生成されます。
$ORACLE_HOME/oracle_common/upgrade/logs/wcsites_upgrade/config/Source Version/

この場合のSource Versionは、11.1.1.8.0です。

ソース(11.1.1.8.0)がクラスタ環境である場合、サマリー詳細は次のようにクラスタごとに生成されます。

$ORACLE_HOME/oracle_common/upgrade/logs/wcsites_upgrade/config/Source Version/$nodename

ソース(11.1.1.8.0)が単一サーバー環境である場合は、次の3つのサマリー・ファイルが生成されます。

- PropertyMigration_Summary.txt (プロパティの移行サマリー)

- HomeMigration_Summary.txt (Siteホームの移行サマリー)

- SharedMigration_Summary.txt (Sites共有の移行サマリー)

スキーマのアップグレードが失敗した場合は、考えられるエラーをログでレビューします。ログ・ファイルは次の場所に生成されます。

$ORACLE_HOME/oracle_common/upgrade/logs

「閉じる」をクリックしてアップグレード・アシスタントを閉じます。

6.2.10 アップグレード後の検証タスク

スキーマと構成が正常にアップグレードされた後でデータの整合性を確認するための、新しくアップグレードしたドメインで実行できる検証スクリプトが用意されています。検証の要約レポートをレビューして、スキーマと構成のアップグレード・プロセスの間にデータの不整合が発生していないか確認できます。

検証スクリプトを実行するには、次の手順を実行します。

1. 検証スクリプトは次の場所にあります。
$Oracle_Home/wcsites/plugins/upgrade/

UNIXオペレーティング・システムの場合は、次のコマンドを入力して検証スクリプトを実行します。

./validation.sh

Windowsオペレーティング・システムの場合は、次のコマンドを入力して検証スクリプトを実行します。

validation.bat

2. 検証チェックが完了すると、検証サマリー・レポート(Validation.txt)が生成されます。これをシステム上の任意の場所に保存します。

3. 検証サマリー・レポートをレビューして、既存のドメインと新しく構成した12.2.1.1のドメインの間にデータの不整合がないかチェックします。

注意:
ソース(11.1.1.8)環境でパッチ12以上を使用している場合、web.xmlの比較レポートには、Eloqua統合フィルタが製品カスタマイズとして表示されます。フィルタはターゲット(12.2.1.1)環境で使用可能であるため、これは無視してかまいません。また、context-parameterの下のinipathパラメータ値について表示される差異も無視してください。

6.2.11 アップグレード後のタスク

アップグレード後のタスクには、カスタム設定のリストア、管理サーバーと管理対象サーバーの起動、パスワードの再構成、およびこのトピックにリストされているその他の管理タスクが含まれます。

WebCenter Sites 12.2.1.1にアップグレードした後に、次の手順を実行します。

1. カスタム設定を既存の環境から12.2.1.1環境にリストアまたは再デプロイします。
これには、Javaライブラリや静的Webリソースに対するカスタム変更、または要素の変更が含まれます。

Javaライブラリまたは静的Webページに加えた変更をリストアするには、「カスタムJavaライブラリまたは静的Webリソースの移行」を参照してください。

注意:
WebCenter Sites 12cではODLロギング・フレームワークを使用しており、11g環境で設定されているカスタムLog4jログ・レベルはODLロギングに移行されません。これらのレベルはアップグレード後にリセットできます。

2. 管理サーバーと管理対象サーバーを起動します。

3. パブリッシュ・プロセスのパスワードを再構成します。

a. 管理サーバーURLに管理者としてサインインします。

b. 「管理」メニューに移動し、「パブリッシュ」の下の「宛先」をクリックします。

c. パブリッシュの宛先URL、ポート、ユーザー名、パスワードを更新します。

4. 11gデプロイメントからアップグレードしている場合は、ユーザーをSitesアプリケーションに割り当てます。

a. AdminSiteに管理者としてサインインします。

b. AdminSiteの下のWEB管理に移動します。
「アプリケーション」をクリックします。次に、管理アプリケーションの下の「アプリケーションの管理」をクリックします。

「サイトへの割当て」をクリックします。「サイトの選択」、「続行」の順にクリックします。

上級ユーザー・ロールを選択し、変更を保存します。

c. AdminSiteの下のWEB管理に移動します。
「アプリケーション」をクリックします。次に、管理アプリケーションの下の「アプリケーションの管理」をクリックします。

「サイトへの割当て」をクリックします。「サイトの選択」、「続行」の順にクリックします。

Sitesユーザー・ロールを選択し、変更を保存します。

d. この手順を繰り返して、その他のアプリケーションをユーザーに追加し、そのユーザーにロールを割り当てます。

5. 外部WebRootが構成されている場合は、Sites管理ユーザー・インタフェースからWebRootを更新します。

6. ソースがクラスタ環境であった場合は、configディレクトリのxmlファイル設定を、アップグレード・アシスタントを実行したソース環境から、アップグレード後の環境にあるその他のすべてのノードにコピーします。
次のような要因があります。

- cs-cahe.xml

- cas-cache.xml

- ss-cache.xml

- linked-cache.xml

- MobilityServices.xml

- Custom/RestResources.xml

- wcs_properties_bootstrap.ini

注意:
Lucene検索索引は、アップグレード・プロセスでの処理中に再度有効になります。アップグレード後のプロセスで索引が完全に再構築されるまで、コントリビュータUIの検索結果が遅延する可能性があります。

7. Fusion Middlewareインフラストラクチャのリリース12cでは、SQL Serverデータベースが大/小文字区別モードで構成されていることが必要になります。結果として、WebCenter Sitesによって提供されるics:sql jspタグでは、表値がデータベースで使用されているのと同じ大/小文字であることが必要になります。
ics:sql文の構文を次に示します。

<ics:sql
sql="sql commands"
listname="list name"
table="name of table"
[limit="max number of results"]/>

SQL Serverデータベースで指定されているのと同じ大/小文字で表の名前を指定する必要があります。

8. 次のプロパティは、Sites構成設定プロセスでの処理中に指定した、アプリケーション管理者ユーザー・アカウント値にリセットされます。

- xcelerate.batchuserおよびパスワード

- cs.emailpassword

プロパティ管理ツールを使用して、これらのプロパティを適切な値に更新する必要があります。

9. WCCの統合後に、WCC構成のwcc.server.passwordをリセットして、マップされたすべてのルールを表示します。

6.3 WebCenter Sitesの以前の12cリリースからのアップグレード・プロセスの理解

このトピックでは、フローチャートを使用して、WebCenter Sitesを以前の12cリリースからアップグレードするためのプロセス・フローについて説明します。

図6-2 WebCenter Sitesの以前の12cリリースからのアップグレード・プロセスのフローチャート

表6-9に、WebCenter Sitesを以前の12cリリースからアップグレードするために実行する必要がある、タスクのロードマップを示します。

表6-9 WebCenter Sitesの以前の12cリリースからのアップグレード・プロセスのロードマップ

手順番号

タスク

説明

1

12.2.1.1のOracle Fusion Middlewareインフラストラクチャをインストールします。

インフラストラクチャのディストリビューションには、その他のFusion Middleware製品をインストールするための基盤の設定に必要な、WebLogic ServerおよびJava Required Files (JRF)が同梱されています。

このガイドのアップグレード・トポロジに定義されているように、インフラストラクチャは新規のOracleホームにインストールする必要があります。 そのため、「Fusion Middlewareインフラストラクチャのインストール」で説明している手順に従ってください。

2

12.2.1.1のOracle WebCenter Sitesのディストリビューションをインストールします。

「WebCenter Sites 12.2.1.1.0のディストリビューションのインストール」の説明に従って、Oracle WebCenter Sitesのディストリビューションをインストールします。

3

管理サーバーおよび管理対象サーバーを停止します。

アップグレード・プロセスを開始する前に、「管理サーバーと管理対象サーバーの停止」で説明している手順に従って、管理サーバーと管理対象サーバーを停止します。

4

12.2.1.0の環境をバックアップします。

ドメイン構成がインプレースでアップグレードされるため、アップグレードの前に既存の環境をバックアップすることが重要です。バックアップによって、アップグレードが失敗した場合またはアップグレードの結果に問題がある場合に、アップグレード前の環境をリストアできるようになります。

バックアップ・アイテムのリストは、「12.2.1.0の環境のバックアップ」を参照してください。

5

12.2.1.0のドメインを再構成します。

既存のドメインで再構成ウィザードを実行した場合、再構成テンプレートを選択および適用することで、ドメインのアップグレード準備が行われます。

再構成ウィザードを使用したWebCenter Sitesドメインの再構成で説明している手順に従って、ドメインを再構成します。

6

アップグレード前のタスクを実行します。

アップグレード前のタスクは、アップグレード・アシスタントを使用してアップグレード・プロセスを開始する前に完了している必要がある、一連のタスクです。

これらのタスクは、「アップグレード・アシスタントを実行する前に」にリストされています。

7

スキーマをアップグレードします。

「アップグレード・アシスタントを使用したスキーマのアップグレード」で説明している手順に従い、アップグレード・アシスタントを使用して、アップグレード可能なスキーマ・コンポーネントをアップグレードします。

8

ドメイン構成をアップグレードします。

「アップグレード・アシスタントを使用した構成のアップグレード」で説明している手順に従い、アップグレード・アシスタントを使用して、12.2.1.0のドメインに含まれるすべての構成をアップグレードします。

9

アップグレード後の検証タスクを実行します。

スキーマと構成が正常にアップグレードされた後でデータの整合性を確認するための、新しくアップグレードしたドメインで実行できる検証スクリプトが用意されています。検証の要約レポートをレビューして、スキーマと構成のアップグレード・プロセスの間にデータの不整合が発生していないか確認できます。

検証スクリプトを使用するには、「アップグレード後の検証タスク」を参照してください。

10

その他のアップグレード後のタスクを実行します。

その他のアップグレード後のタスクには、カスタム設定のリストア、管理サーバーと管理対象サーバーの起動、パスワードの再構成、および「アップグレード後のタスク」にリストされているその他の管理タスクが含まれます。

6.4 WebCenter Sitesの以前の12cリリースからのアップグレード

WebCenter Sitesを12.2.1.1にアップグレードするための12cの有効な開始ポイントは、WebCenter Sites 12.2.1.0です。これは、インプレース・アップグレードです。

注意:
既存のSites環境がデータベースへのNIOベースの共有ファイル・システムで構成されている場合は、アップグレード・プロセスを開始する前に、これをディスク・ストレージに戻します。

WebCenter Sites 12.2.1.1を以前の12cリリースからアップグレードするには、次のタスクを実行します。

- Fusion Middlewareインフラストラクチャのインストール
Fusion Middlewareインフラストラクチャをインストールすると、Oracleホーム・ディレクトリが作成され、その他のFusion Middleware製品をインストールするためのサポート・ソフトウェアが配置されます。

- WebCenter Sites 12.2.1.1.0のディストリビューションのインストール
次に、WebCenter Sitesリリース12.2.1.1.0をターゲット・マシンにインストールします。

- 管理サーバーと管理対象サーバーの停止
12.2.1システムの管理サーバーと管理対象サーバーを停止する必要があります。

- 12.2.1.0の環境のバックアップ
アップグレード・プロセスを開始する前に、WebLogicドメイン、Sites構成ディレクトリ、Sites共有ディレクトリ、およびSitesスキーマをバックアップする必要があります。

- 再構成ウィザードを使用したWebCenter Sitesドメインの再構成
アップグレード・アシスタントを実行する前に、再構成ウィザードを使用して、最初に12.2.1.0のSitesドメインを再構成する必要があります。

- アップグレード・アシスタントを実行する前に
アップグレード・アシスタントを実行して12.2.1.0のドメインをアップグレードする前に、このトピックにリストされているタスクを実行します。

- アップグレード・アシスタントを使用したスキーマのアップグレード
アップグレード・アシスタントを使用して12.2.1.0のスキーマをアップグレードする必要があります。

- アップグレード・アシスタントを使用した構成のアップグレード
アップグレード・アシスタントを使用して、12.1.1.0.0のドメイン構成をアップグレードする必要があります。

- アップグレード後の検証タスク
スキーマと構成が正常にアップグレードされた後でデータの整合性を確認するための、新しくアップグレードしたドメインで実行できる検証スクリプトが用意されています。検証の要約レポートをレビューして、スキーマと構成のアップグレード・プロセスの間にデータの不整合が発生していないか確認できます。

- アップグレード後のタスク
アップグレード後のタスクには、カスタム設定のリストア、管理サーバーと管理対象サーバーの起動、パスワードの再構成、およびこのトピックにリストされているその他の管理タスクが含まれます。

6.4.1 Fusion Middlewareインフラストラクチャのインストール

Fusion Middlewareインフラストラクチャをインストールすると、Oracleホーム・ディレクトリが作成され、その他のFusion Middleware製品をインストールするためのサポート・ソフトウェアが配置されます。

Fusion Middlewareインフラストラクチャのディストリビューションをインストールするには、次の手順を実行します。

1. 12.2.1.1製品の配布をインストールするターゲット・システムにログインします。

2. Oracle Fusion Middleware Infrastructureの配布(fmw_12.2.1.1.0_infrastructure_generic.jar)を、Oracle Technology NetworkまたはOracle Software Delivery Cloudからお使いのターゲット・システムにダウンロードします。

3. 12.2.1.1の製品のディストリビューションをダウンロードしたディレクトリに移動します。

4. 次のコマンドを入力して、インストール・プログラムを起動します。
UNIXオペレーティング・システムの場合:

$JDK_HOME/bin/java [-d64] -jar fmw_12.2.1.1.0_infrastructure_generic.jar

注意:
HP-UX Itaniumを使用している場合のみ"-d64"フラグを使用します。

Windowsオペレーティング・システムの場合:

%JDK_HOME%\bin\java -jar fmw_12.2.1.1.0_infrastructure_generic.jar

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

注意:
「インストール・インベントリの設定」画面は、Windowsオペレーティング・システムでは表示されません。

6. 「ようこそ」画面で、情報をレビューしてすべての前提条件を満たしていることを確認し、「次へ」をクリックします。

7. 「自動更新」画面で「自動更新をスキップ」を選択し、「次へ」をクリックします。

- 自動更新をスキップ: このときにソフトウェアの更新をシステムで確認しないようにする場合。

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

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

8. 「インストールの場所」画面でOracleホーム・ディレクトリの場所を指定し、「次へ」をクリックします。
Oracle Fusion Middlewareのディレクトリ構造の詳細は、『Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成用のディレクトリの選択に関する項を参照してください。

9. 「インストール・タイプ」画面で「Fusion Middlewareインフラストラクチャ」を選択し、「次へ」をクリックします。

注意:
このドキュメントのトポロジにサーバーの例は含まれません。製品環境にはサンプルをインストールしないように強くお薦めします。

10. 「前提条件チェック」画面では、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
いずれかの前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。

エラー・メッセージや警告メッセージを無視してインストールを続ける場合は、「スキップ」をクリックします(このアプローチはお薦めできません)。

11. 「セキュリティ更新」画面で、My Oracle Supportアカウント情報を入力すると、最新の製品情報およびセキュリティ・アップデートをMy Oracle Supportアカウントを介して受け取ることができます。
この画面は、ホスト上にOracle製品を初めてインストールすると表示されます。

Oracle Supportアカウントを所有していない場合、この手順をスキップするには、チェック・ボックスの選択を解除し、フォローアップのダイアログ・ボックスで選択内容を確認します。

12. 「インストールの概要」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存するには、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルを使用して、サイレント・インストールを実行できます。「インストール」をクリックします。

13. 進捗バーの表示が100%になったら、「インストールの進行状況」画面で「次へ」をクリックします。

14. 「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

6.4.2 WebCenter Sites 12.2.1.1.0のディストリビューションのインストール

次に、WebCenter Sitesリリース12.2.1.1.0をターゲット・マシンにインストールします。

WebCenter Sitesをインストールするには、次の手順を実行します。

1. 12.2.1.1製品の配布をインストールするターゲット・システムにログインします。

2. Oracle Fusion Middleware WebCenter Sitesのディストリビューション(fmw_12.2.1.1.0_wcsites_generic.jar)を、Oracle Technology NetworkまたはOracle Software Delivery Cloudからお使いのターゲット・システムにダウンロードします。

3. 12.2.1.1の製品のディストリビューションをダウンロードしたディレクトリに移動します。

4. 次のコマンドを入力して、インストール・プログラムを起動します。
UNIXオペレーティング・システムの場合:

$JDK_HOME/bin/java [-d64] -jar <distribution_file_name>.jar

注意:
HP-UX Itaniumを使用している場合のみ"-d64"フラグを使用します。

Windowsオペレーティング・システムの場合:

%JDK_HOME%\bin\java -jar <distribution_file_name>.jar

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

注意:
「インストール・インベントリの設定」画面は、Windowsオペレーティング・システムでは表示されません。

6. 「ようこそ」画面で、情報をレビューしてすべての前提条件を満たしていることを確認し、「次へ」をクリックします。

7. 「自動更新」画面で「自動更新をスキップ」を選択し、「次へ」をクリックします。

- 自動更新をスキップ: このときにソフトウェアの更新をシステムで確認しないようにする場合。

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

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

8. 「インストールの場所」画面でOracleホーム・ディレクトリの場所を指定し、「次へ」をクリックします。
Oracle Fusion Middlewareのディレクトリ構造の詳細は、『Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成用のディレクトリの選択に関する項を参照してください。

9. 「インストール・タイプ」画面で「WebCenter Sites」を選択し、「次へ」をクリックします。

10. 「前提条件チェック」画面では、ホスト・コンピュータを分析して、特定のオペレーティング・システムの前提条件を満たしているか確認します。
いずれかの前提条件のチェックが失敗すると、エラー・メッセージが画面の下方に表示されます。エラーを修正し、「再実行」をクリックして再試行します。

エラー・メッセージや警告メッセージを無視してインストールを続ける場合は、「スキップ」をクリックします(このアプローチはお薦めできません)。

11. 「インストールの概要」画面で、選択したインストール・オプションを確認します。
これらのオプションをレスポンス・ファイルに保存するには、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を入力します。レスポンス・ファイルを使用して、サイレント・インストールを実行できます。「インストール」をクリックします。

12. 進捗バーの表示が100%になったら、「インストールの進行状況」画面で「次へ」をクリックします。

13. 「インストール完了」画面に、インストールの場所とインストールされた機能セットが表示されます。この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

6.4.3 管理サーバーと管理対象サーバーの停止

12.2.1システムの管理サーバーと管理対象サーバーを停止する必要があります。

サーバー・インスタンスを停止するには、次の手順を実行します。

1. 次のコマンドを入力して、管理サーバーを停止します。
UNIXオペレーティング・システムの場合:

$DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]

Windowsオペレーティング・システムの場合:

$DOMAIN_HOME\bin\stopWebLogic.cmd username password [admin_url]

2. 次のコマンドを入力して、管理対象サーバーを停止します。
UNIXオペレーティング・システムの場合:

$DOMAIN_HOME/bin/stopManagedWebLogic.sh managed_server_name admin_url

Windowsオペレーティング・システムの場合:

$DOMAIN_HOME\bin\stopManagedWebLogic.cmd managed_server_name admin_url

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

6.4.4 12.2.1.0の環境のバックアップ

アップグレード・プロセスを開始する前に、WebLogicドメイン、Sites構成ディレクトリ、Sites共有ディレクトリ、およびSitesスキーマをバックアップする必要があります。

6.4.5 再構成ウィザードを使用したWebCenter Sitesドメインの再構成

アップグレード・アシスタントを実行する前に、再構成ウィザードを使用して、最初に12.2.1.0のSitesドメインを再構成する必要があります。

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

ドメインを再構成するには、次の手順を実行します。

1. 次のコマンドを入力して、再構成ウィザードを実行します。
UNIXオペレーティング・システムの場合:

$ORACLE_HOME/oracle_common/common/bin/reconfig.sh

Windowsオペレーティング・システムの場合:

%ORACLE_HOME%\oracle_common\common\bin\reconfig.cmd

注意:
reconfig.cmdまたはreconfig.shコマンドを実行すると、デフォルトのキャッシュ・ディレクトリが無効であることを示す次のエラー・メッセージが表示される場合があります。
*sys-package-mgr*: パッケージ・キャッシュ・ディレクトリを作成できません。

コマンドに-Dpython.cachedir=valid_directoryパラメータを含めることで、キャッシュ・ディレクトリを変更できます。

次の例に示すように、再構成ウィザードを起動する際には、"log"オプションを指定することをお薦めします。

./reconfig.sh -log=/$ORACLE_HOME/logs/reconfig.log -log_priority=ALL

要件に応じてlog_priorityを設定できます。

2. 「ドメインの選択」画面で、アップグレードするドメインの場所を指定するか、「参照」をクリックしてナビゲートし、ドメインのディレクトリを選択します。「次へ」をクリックします。

3. 「再構成セットアップの進行状況」画面には、設定プロセスの進行状況が表示されます。完了したら、「次へ」をクリックします。
このプロセスでは次の処理が行われます。

- Fusion Middleware製品を含む、インストール済製品の再構成テンプレートが自動的に適用されます。これにより、config.xml、config-groups.xml、security.xmlなどの様々なドメイン構成ファイルが更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

- ドメイン・アップグレードが検証されます。

4. 「ドメイン・モードおよびJDK」画面で、ドメインで使用するJDKを選択するか、「参照」をクリックして、使用するJDKにナビゲートします。「次へ」をクリックします。

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

特定のプラットフォームでサポートされているJDKのリストは、Oracle Fusion Middlewareでサポートされているシステム構成の説明を参照してください。

5. 「データベース構成タイプ」画面で、「RCUデータ」を選択します。
RCUサービス表(STB)スキーマ資格証明を使用してデータベース接続の詳細を入力し、「RCU構成の取得」をクリックします。

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

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

6. 「JDBCコンポーネント・スキーマ」画面で、各コンポーネント・スキーマのDBMS/サービスおよびホスト名が正しいことを確認し、「次へ」をクリックします。

7. DB2の場合は、再構成のために、「コンポーネント・データソース」画面でWCSITESコンポーネント・スキーマのDBMS/サービスおよびホスト名を入力します。

8. 「JDBCコンポーネント・スキーマ・テスト」画面で、すべてのコンポーネント・スキーマを選択して「選択された接続のテスト」をクリックし、各スキーマの接続をテストします。
チェックが完了したら、「次へ」をクリックします。

9. 「拡張構成」画面で、拡張構成を実行するすべてのカテゴリを選択できます。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。

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

このアップグレードではオプションを選択せずに、「次へ」をクリックします。

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

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

注意:
ドメインを再構成しても、その場所は変更されません。

11. 「再構成の進行状況」画面には、再構成プロセスの進行状況が表示されます。
このプロセスでは次の処理が行われます。

- ドメイン情報が抽出、保存および更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

進捗バーが100%になったら、「次へ」をクリックします。

12. 「構成の終了」画面には、再構成プロセスが正常に完了したか失敗したかが示されます。管理サーバーURL(リスニング・ポートを含む)とともに再構成されたドメインの場所も表示します。再構成が成功した場合は、「Oracle Weblogic Serverの再構成に成功しました」と表示されます。
再構成プロセスが成功して完了しなかった場合は、その理由を示すエラー・メッセージが表示されます。問題を解決するための適切な措置を講じます。問題を解決できない場合は、My Oracle Supportに連絡してください。

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

6.4.6 アップグレード・アシスタントを実行する前に

アップグレード・アシスタントを実行して12.2.1.0のドメインをアップグレードする前に、このトピックにリストされているタスクを実行します。

アップグレード・アシスタントを実行する前に、次のことを実行します。

1. ソースがクラスタ環境である場合は、プライマリ・ノードからドメインを圧縮し、それをセカンダリ・クラスタ・メンバー上に解凍します。

2. セカンダリ・ノードのSitesのconfigフォルダを、プライマリ・ノードのもので置換します。

3. $DOMAIN_HOME/wcsires/config/にある次のxmlファイルを更新します。

a. jbossTicketCacheReplicationConfig.xml:
bind_addrプロパティを、このクラスタ・ノードの有効なホストまたはIPアドレスで正しく更新します。

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

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

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

表6-10 timeToLiveの値の説明

timeToLiveの値

説明

1

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

32

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

64

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

128

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

256

制限なし。

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

4. 次のコマンドを入力して、新規Sitesのセキュリティjarに対する権限を付与します。
$DOMAIN_HOME/wcsites/bin/grant-opss-permission

5. xml構成ファイルに対するカスタム設定をリストアします。DB2の場合:

a. ドメイン・クラスパスに、db2jcc.jarおよびdb2jcc_license_cu.jarの各ファイルを元どおり追加します。

b. テキスト・エディタを使用して、次の場所にあるsetDomainEnv.shファイルを編集します。
$Domain_Home/bin

次のテキストを探します。

# ADD EXTENSIONS TO CLASSPATHS

# ADD EXTENSIONS TO CLASSPATHSの後に次の行を追加します。

PRE_CLASSPATH="path_to_db2jcc.jar:path_to_db2jcc_license_cu.jar:${PRE_CLASSPATH}

6. setDomainEnv.shファイルを保存します。

7. 再構成プロセスの後にxml構成ファイルに対して実行されたカスタマイズをリストアします。

6.4.7 アップグレード・アシスタントを使用したスキーマのアップグレード

アップグレード・アシスタントを使用して、12.2.1.0のスキーマをアップグレードする必要があります。

12.2.1.0のスキーマをアップグレードするには、次の手順を実行します。

1. 12.2.1.1のOracleホームから次のコマンドを入力して、アップグレード・アシスタントを実行します。
UNIXオペレーティング・システムの場合:

$Oracle_Home/oracle_common/upgrade/bin/ua

Windowsオペレーティング・システムの場合:

%Oracle_Home%\oracle_common\upgrade\bin\ua.bat

2. 「ようこそ」画面には、アップグレード・アシスタントの概要と、重要なアップグレード前のタスクに関する情報が表示されます。「次」をクリックします。
アップグレード・アシスタントの使用の詳細を参照するには、アップグレード・アシスタントの画面で「ヘルプ」をクリックします。

3. 「選択したスキーマ」画面で「個別に選択されたスキーマ」を選択し、「次」をクリックします。
スキーマのアップグレード対象になるコンポーネントはアップグレード・アシスタントによって識別され、ユーザーがアップグレードに含めるスキーマを選択できるようになります。

4. 「使用可能なコンポーネント」画面には、アップグレード可能なスキーマがあるインストール済のOracle Fusion Middlewareコンポーネントのリストが表示されます。
コンポーネントを選択すると、スキーマとすべての依存関係が自動的に選択されます。

「Oracle WebCenter Sites」を選択し、「次」をクリックします。

5. 「前提条件」画面ですべてのチェック・ボックスを選択し、前提条件を満たしていることを確認応答します。「次」をクリックします。

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

6. 「WebCenter Sitesソース・バージョン」画面で12.2.1.0.0以降を選択し、「次」をクリックします。これはアップグレードの開始ポイントです。

7. 「WebCenter Sitesの場所」画面で、既存のSitesホームおよびSites共有ディレクトリの完全な場所と、12cの構成ファイル(wcs_properties.json)の場所を指定します。
「次へ」をクリックします。

8. 「WebCenter Sitesソース・スキーマ」画面で、「データベース・タイプ」ドロップダウン・リストからデータベース・タイプを選択します。
「データベース接続文字列」フィールドに、データベース接続文字列をhost_name:port/service_nameの形式で指定します。

「DBAユーザー名」フィールドに、ユーザー名とDBA権限を指定します。「DBAパスワード」フィールドに、DBAパスワードを指定します。

「スキーマ・ユーザー名」フィールドと「スキーマ・パスワード」フィールドに、スキーマのユーザー名とパスワードをそれぞれ指定します。

9. 「調査」画面には、各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証する、アップグレード・アシスタントのステータスが表示されます。ステータスが「調査が終了しました。」である場合は、「アップグレード」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログ・ボックスで「いいえ」をクリックして、アップグレードを取り消すことをお薦めします。「ログの表示」をクリックして、エラーの原因を調査し、アップグレードのトラブルシューティングに関する説明で一般的なアップグレード・エラーの解決方法を参照してください。

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、アップグレード・アシスタントを再起動する前に、アップグレード前の環境をバックアップからリストアする必要があります。

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

10. 「アップグレード・サマリー」画面でツリーを展開し、選択したオプションのサマリーをレビューします。
アップグレードを続行する前に、「ソース・バージョン」と「ターゲット・バージョン」をレビューして、両方のバージョンが正しいことを確認します。

このレスポンス・ファイルは、アップグレード・アシスタントのグラフィカル・ユーザー・インタフェース画面で入力したすべての情報を収集および保存し、後でサイレント・アップグレードを実行することができます。サイレント・アップグレードは、Upgrade Assistantウィザードとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合、「保存」をクリックし、レスポンス・ファイルの名前および場所を指定します。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

11. 「アップグレードの進行状況」画面には、アップグレード・プロセスのステータスと、アップグレードが成功した後のコンポーネントの予測されるターゲット・バージョンが表示されます。「次」をクリックします。

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

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

12. スキーマのアップグレードが成功した場合は、次の場所にサマリー・ファイルが生成されます。
$ORACLE_HOME/oracle_common/upgrade/logs/wcsites_upgrade/schema/Source Version/Database Type/summary.txt

この場合、Source Versionは12.2.1.1であり、Database Typeは使用しているデータベースです。

スキーマのアップグレードが失敗した場合は、考えられるエラーをログでレビューします。ログ・ファイルは次の場所に生成されます。

$ORACLE_HOME/oracle_common/upgrade/logs

「閉じる」をクリックしてアップグレード・アシスタントを閉じます。

6.4.8 アップグレード・アシスタントを使用した構成のアップグレード

アップグレード・アシスタントを使用して、12.1.1.0.0のドメイン構成をアップグレードする必要があります。

12.2.1.1.0のドメインをアップグレードするには、次の手順を実行します。

1. 12.2.1.1のOracleホームから次のコマンドを入力して、アップグレード・アシスタントを実行します。
UNIXオペレーティング・システムの場合:

$Oracle_Home/oracle_common/upgrade/bin/ua

Windowsオペレーティング・システムの場合:

%Oracle_Home%\oracle_common\upgrade\bin\ua.bat

2. 「ようこそ」画面には、アップグレード・アシスタントの概要と、重要なアップグレード前のタスクに関する情報が表示されます。「次」をクリックします。
アップグレード・アシスタントの使用の詳細を参照するには、アップグレード・アシスタントの画面で「ヘルプ」をクリックします。

3. 「すべての構成」画面で「ドメインによって使用されるすべての構成」を選択し、12.2.1.0のドメインの場所を「ドメイン・ディレクトリ」フィールドに直接入力するか、「参照」をクリックしてナビゲーション・ツリーを使用し、有効なドメイン・ディレクトリを選択することで指定します。「次」をクリックします。

4. 「コンポーネント・リスト」画面で、ドメイン内のアップグレード対象のコンポーネントがすべてリストされていることを確認し、「次」をクリックします。
アップグレード対象のコンポーネントが表示されていない場合は、「戻る」をクリックして前の画面に戻り、別のドメインを指定します。

5. 「前提条件」画面ですべてのチェック・ボックスを選択し、前提条件を満たしていることを確認応答します。「次」をクリックします。

注意:
アップグレード・アシスタントでは前提条件が満たされているかどうかを確認できません。

6. 「WebCenter Sitesソース・バージョン」画面で12.2.1.0.0以降を選択し、「次」をクリックします。これはアップグレードの開始ポイントです。

7. ソースが単一サーバー環境である場合は、「WebCenter Sitesソースの詳細」画面が表示されます。
「WebCenter Sitesソース・クラスタの詳細」画面で、12.2.1.1.0のSitesインストール・ディレクトリと12.2.1.1.0のSites Webアプリケーションの場所の完全パスを指定し、「アップグレード」をクリックします。

「参照」をクリックして、ナビゲーション・ツリーを使用して特定のディレクトリを選択することもできます。

8. ソースがクラスタ環境である場合は、「WebCenter Sitesソースの詳細」画面が表示されます。
各ノードの12.2.1.1.0 Sitesインストールと12.2.1.1.0 Sites Webアプリケーション・ディレクトリを、「Sitesインストール」列と「Sites Webアプリケーション」列にそれぞれ指定します。

「参照」をクリックして、ナビゲーション・ツリーを使用して特定のディレクトリを選択することもできます。

12.2.1.1.0のディレクトリを指定したら、「アップグレード」をクリックします。

注意:
アップグレード・アシスタントにリストされるノード名は、「クラスタ・ノード管理」画面でノードを登録した際に指定した名前です。

9. 「調査」画面には、各コンポーネントを調査し、コンポーネントのアップグレード準備が整っていることを検証する、アップグレード・アシスタントのステータスが表示されます。ステータスが「調査が終了しました。」である場合は、「アップグレード」をクリックします。
調査フェーズが失敗した場合は、「調査失敗」ダイアログ・ボックスで「いいえ」をクリックして、アップグレードを取り消すことをお薦めします。「ログの表示」をクリックして、エラーの原因を調査し、アップグレードのトラブルシューティングに関する説明で一般的なアップグレード・エラーの解決方法を参照してください。

注意:

- 調査フェーズの間に、アップグレードを続行せずに検出された問題を解決した場合は、バックアップからリストアすることなしに、アップグレード・アシスタントを再起動できます。ただし、「調査失敗」ダイアログ・ボックスで「はい」をクリックして続行した場合は、アップグレード・アシスタントを再起動する前に、アップグレード前の環境をバックアップからリストアする必要があります。

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

10. 「アップグレード・サマリー」画面でツリーを展開し、選択したオプションのサマリーをレビューします。
アップグレードを続行する前に、「ソース・バージョン」と「ターゲット・バージョン」をレビューして、両方のバージョンが正しいことを確認します。

このレスポンス・ファイルは、アップグレード・アシスタントのグラフィカル・ユーザー・インタフェース画面で入力したすべての情報を収集および保存し、後でサイレント・アップグレードを実行することができます。サイレント・アップグレードは、Upgrade Assistantウィザードとまったく同じ機能を実行しますが、データを手動で再入力する必要はありません。これらのオプションをレスポンス・ファイルに保存する場合、「保存」をクリックし、レスポンス・ファイルの名前および場所を指定します。

「アップグレード」をクリックして、アップグレード・プロセスを開始します。

11. 「アップグレードの進行状況」画面には、アップグレード・プロセスのステータスと、アップグレードが成功した後のコンポーネントの予測されるターゲット・バージョンが表示されます。「次」をクリックします。

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

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

12. 構成のアップグレードが成功した場合は、次の場所にサマリー・ファイルが生成されます。
$ORACLE_HOME/oracle_common/upgrade/logs/wcsites_upgrade/config/Source Version/

この場合のSource Versionは、12.2.1.1.0です。

ソース(12.2.1.1.0)がクラスタ環境である場合、サマリー詳細は次のようにクラスタごとに生成されます。

$ORACLE_HOME/oracle_common/upgrade/logs/wcsites_upgrade/config/Source Version/$nodename

ソース(12.2.1.1.0)が単一サーバー環境である場合は、次の3つのサマリー・ファイルが生成されます。

- PropertyMigration_Summary.txt (プロパティの移行サマリー)

- HomeMigration_Summary.txt (Siteホームの移行サマリー)

- SharedMigration_Summary.txt (Sites共有の移行サマリー)

スキーマのアップグレードが失敗した場合は、考えられるエラーをログでレビューします。ログ・ファイルは次の場所に生成されます。

$ORACLE_HOME/oracle_common/upgrade/logs

「閉じる」をクリックしてアップグレード・アシスタントを閉じます。

6.4.9 アップグレード後の検証タスク

スキーマと構成が正常にアップグレードされた後でデータの整合性を確認するための、新しくアップグレードしたドメインで実行できる検証スクリプトが用意されています。検証の要約レポートをレビューして、スキーマと構成のアップグレード・プロセスの間にデータの不整合が発生していないか確認できます。

検証スクリプトを実行するには、次の手順を実行します。

1. 検証スクリプトは次の場所にあります。
$Oracle_Home/wcsites/plugins/upgrade/

UNIXオペレーティング・システムの場合は、次のコマンドを入力して検証スクリプトを実行します。

./validation.sh

Windowsオペレーティング・システムの場合は、次のコマンドを入力して検証スクリプトを実行します。

validation.bat

2. 検証チェックが完了すると、検証サマリー・レポート(Validation.txt)が生成されます。これをシステム上の任意の場所に保存します。

3. 検証サマリー・レポートをレビューして、既存のドメインと新しく構成した12.2.1.1のドメインの間にデータの不整合がないかチェックします。

注意:
ソース(11.1.1.8)環境でパッチ12以上を使用している場合、web.xmlの比較レポートには、Eloqua統合フィルタが製品カスタマイズとして表示されます。フィルタはターゲット(12.2.1.1)環境で使用可能であるため、これは無視してかまいません。また、context-parameterの下のinipathパラメータ値について表示される差異も無視してください。

6.4.10 アップグレード後のタスク

アップグレード後のタスクには、カスタム設定のリストア、管理サーバーと管理対象サーバーの起動、パスワードの再構成、およびこのトピックにリストされているその他の管理タスクが含まれます。

WebCenter Sites 12.2.1.1にアップグレードした後に、次の手順を実行します。

1. カスタム設定を既存の環境から12.2.1.1環境にリストアまたは再デプロイします。
これには、Javaライブラリや静的Webリソースに対するカスタム変更、または要素の変更が含まれます。

Javaライブラリまたは静的Webページに加えた変更をリストアするには、「カスタムJavaライブラリまたは静的Webリソースの移行」を参照してください。

注意:
WebCenter Sites 12cではODLロギング・フレームワークを使用しており、11g環境で設定されているカスタムLog4jログ・レベルはODLロギングに移行されません。これらのレベルはアップグレード後にリセットできます。

2. 管理サーバーと管理対象サーバーを起動します。

3. パブリッシュ・プロセスのパスワードを再構成します。

a. 管理サーバーURLに管理者としてサインインします。

b. 「管理」メニューに移動し、「パブリッシュ」の下の「宛先」をクリックします。

c. パブリッシュの宛先URL、ポート、ユーザー名、パスワードを更新します。

4. 11gデプロイメントからアップグレードしている場合は、ユーザーをSitesアプリケーションに割り当てます。

a. AdminSiteに管理者としてサインインします。

b. AdminSiteの下のWEB管理に移動します。
「アプリケーション」をクリックします。次に、管理アプリケーションの下の「アプリケーションの管理」をクリックします。

「サイトへの割当て」をクリックします。「サイトの選択」、「続行」の順にクリックします。

上級ユーザー・ロールを選択し、変更を保存します。

c. AdminSiteの下のWEB管理に移動します。
「アプリケーション」をクリックします。次に、管理アプリケーションの下の「アプリケーションの管理」をクリックします。

「サイトへの割当て」をクリックします。「サイトの選択」、「続行」の順にクリックします。

Sitesユーザー・ロールを選択し、変更を保存します。

d. この手順を繰り返して、その他のアプリケーションをユーザーに追加し、そのユーザーにロールを割り当てます。

5. 外部WebRootが構成されている場合は、Sites管理ユーザー・インタフェースからWebRootを更新します。

6. ソースがクラスタ環境であった場合は、configディレクトリのxmlファイル設定を、アップグレード・アシスタントを実行したソース環境から、アップグレード後の環境にあるその他のすべてのノードにコピーします。
次のような要因があります。

- cs-cahe.xml

- cas-cache.xml

- ss-cache.xml

- linked-cache.xml

- MobilityServices.xml

- Custom/RestResources.xml

- wcs_properties_bootstrap.ini

注意:
Lucene検索索引は、アップグレード・プロセスでの処理中に再度有効になります。アップグレード後のプロセスで索引が完全に再構築されるまで、コントリビュータUIの検索結果が遅延する可能性があります。

7. Fusion Middlewareインフラストラクチャのリリース12cでは、SQL Serverデータベースが大/小文字区別モードで構成されていることが必要になります。結果として、WebCenter Sitesによって提供されるics:sql jspタグでは、表値がデータベースで使用されているのと同じ大/小文字であることが必要になります。
ics:sql文の構文を次に示します。

<ics:sql
sql="sql commands"
listname="list name"
table="name of table"
[limit="max number of results"]/>

SQL Serverデータベースで指定されているのと同じ大/小文字で表の名前を指定する必要があります。

8. 次のプロパティは、Sites構成設定プロセスでの処理中に指定した、アプリケーション管理者ユーザー・アカウント値にリセットされます。

- xcelerate.batchuserおよびパスワード

- cs.emailpassword

プロパティ管理ツールを使用して、これらのプロパティを適切な値に更新する必要があります。

9. WCCの統合後に、WCC構成のwcc.server.passwordをリセットして、マップされたすべてのルールを表示します。

6.5 カスタムJavaライブラリまたは静的Webリソースの移行

アップグレード前の環境でWebアプリケーションにカスタムJavaライブラリまたは静的Webリソースが追加されており、アップグレード後の環境でこれらを引き続き使用する場合にのみ、このオプション手順を実行します。

WebアプリケーションにカスタムJavaライブラリ(jarファイル)またはカスタムWebリソース(css、js、イメージなど)が含まれている場合は、アップグレード後に、それらをアップグレード後の環境に手動で移行する必要があります。これらのリソースを移行しないと、アップグレード後の環境でその機能にアクセスできなくなります。

WebCenter SitesのWebアプリケーションは、WARファイルとして出荷されます。Webアプリケーションは、最初に構成ウィザードの処理中にデプロイされ、アプリケーション・ライフサイクルでの処理中に何度でも再デプロイすることができます。変更はアップグレード・プロセスでの処理中に上書きされるため、実装固有のカスタマイズをSites WARファイルに含めないことをお薦めします。

WebLogic Server共有ライブラリ・フレームワークを拡張する場合、Sitesではextend.sites.webapp-lib.warが共有ライブラリとして提供されます。このファイルはORACLE_HOME/wcsites/webcentersites/sites-home/ディレクトリにあります。静的Webリソースなどの実装固有のカスタマイズやJavaライブラリを、このWARファイルに含めることができます。この共有ライブラリは、アプリケーションのライフサイクルの進行中にデプロイされ、Sitesと同じコンテキスト・ルーツ(/sites/)を共有します。この共有ライブラリのコンテンツは、パッチ適用プロセスでの処理中に上書きされることはありません。

また、Sites UIがカスタマイズされている場合は、コードの変更もアップグレード後の環境に移行する必要があります。

7 クラスタ・トポロジのWebCenterのアップグレード

この手順は、クラスタ化されたWebCenterトポロジをアップグレードするために使用します。単一ノード・トポロジをアップグレードする場合は、このガイドの他の項を参照してください。

WebCenterのクラスタ・トポロジ(複数のマシンでサーバーが実行されるドメイン)をアップグレードするには、次に示すように、最初のノード(Node 1)ですべてのアップグレード・プロセスを実行し、ドメインを圧縮して他のノードで解凍します。

クラスタ・トポロジをアップグレードするには、次の手順を実行します。

1. Node 1でアップグレードをすべて実行します。Oracle WebCenterドメインの12c (12.2.1.1)へのアップグレード

a. アップグレード後の構成タスクをすべて実行します。アップグレード後の構成タスクの実行

b. アップグレードが成功したことを確認します。新規アプリケーションが予期したとおり動作することの確認

2. 管理サーバーを圧縮します。

cd ORACLE_HOME/common/bin
./pack.sh -managed=true -domain=DOMAIN_HOME -template=wcdomaintemplate.jar -template_name=wc_domain_template

3. wcdomaintemplate.jarを他のマシンのORACLE_HOME/common/binにコピーします。

4. 他のマシンの古いドメイン・ディレクトリ(DOMAIN_HOMEおよびAPPLICATION_HOME)を削除または移動します。

5. 他の各マシンのドメインを解凍します。

cd ORACLE_HOME/common/bin
./unpack.sh -domain=DOMAIN_HOME -template=wcdomaintemplate.jar -overwrite_domain=true

WebCenterクラスタのアップグレードのトラブルシューティング

- WebCenterクラスタのアップグレードのトラブルシューティング
WebCenterのクラスタ・トポロジのアップグレード中にエラーが発生した場合は、これらのアップグレード後のタスクを確認してください。

7.1 WebCenterクラスタのアップグレードのトラブルシューティング

WebCenterのクラスタ・トポロジのアップグレード中にエラーが発生した場合は、これらのアップグレード後のタスクを確認してください。

- アップグレード後のWebCenter Content URLへのアクセス
この手順は、クラスタ・トポロジのアップグレード後にWebCenter Content URLにアクセスできない場合にのみ必要です。

親トピック: クラスタ・トポロジのWebCenterのアップグレード

7.1.1 アップグレード後のWebCenter Content URLへのアクセス

この手順は、クラスタ・トポロジのアップグレード後にWebCenter Content URLにアクセスできない場合にのみ必要です。

セカンダリ・ノードで圧縮と解凍を実行した後、セカンダリ・ノードでWebCenter Content URLにアクセスできなくなることがあります。これは、圧縮と解凍のプロセスによってWebCenter Content Serverがセカンダリ・ノードに完全に伝播されない場合に発生します。

1. Intradoc.cfgファイルの変数を変更します。
a) <Domain_Home>/ucm/cs/binにナビゲートします。
b) Intradoc.cfgファイルを探し、サーバー・ディレクトリ: IdcHomeDirを、11gのインストール場所ではなく、新しい12.2.1のインストール場所に変更します。

注意: これをWebCenter Contentの管理対象サーバーごとに実行する必要があります。

2. idcs_components.hdaファイルを変更します。
a) <Domain_Home>/ucm/cs/dataにナビゲートします。
b) idcs_components.hdaファイルを探し、廃止されたコンポーネントをすべて削除します。

ヒント: ファイルの更新をすばやく行うには、Node1の既存のidcs_components.hdaファイルのコピーを作成し、Node2の同じ場所(<Domain_Home>/ucm/cs/data)に貼り付けます。これによってNode2のファイルが上書きされます。

.

親トピック: WebCenterクラスタのアップグレードのトラブルシューティング

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。