5 WebCenter Sitesの11gから12cへのアップグレード
11gから12cへのアップグレードは、アウトオブプレース移行です。これには、Upgrade Assistantを使用したデータ表とプラットフォーム構成の移行が含まれます。
WebCenter Sitesを12.2.1.3.0にアップグレードするための11gの有効な開始ポイントは、WebCenter Sites 11.1.1.8.0および11.1.1.8.0パッチ12+です。これは、アウトオブプレース移行です。
ノート:
アップグレードする際に、要件にあわせて検討できる2つの方法があります。
-
配信環境をアップグレードし、アップグレード後にそのクローンを作成して、開発環境と管理環境を作成します。
この方法を検討する場合は、同期化が必要になります。アップグレードの前に、開発環境と管理環境から配信環境にコンテンツを公開する必要があります。その後、アップグレードした配信環境のクローンを作成して、開発環境と管理環境を作成します。
-
または、各環境を個別にアップグレードします。
この方法を検討する場合、同期化は必要ありません。
ノート:
11.1.1.6.xからアップグレードする場合は、『Fusion Middleware WebCenter Sitesアップグレード・ガイド』のWebCenter Sitesのアップグレード・プロセスに関する項に記載されているWebCenter Sites 11gのアップグレード手順を使用して、リリース11.1.1.8にアップグレードする必要があります。WebCenter Sitesを11gから12cにアップグレードするには、次のタスクを実行します。
- WebCenter Sitesの11gから12cへのアップグレード・プロセスについて
Oracle WebCenter Sitesのアップグレード・プロセスの概要に関するフローチャートとロードマップを確認します。 - 製品ディストリビューションのインストール
アップグレードを開始する前に、ターゲット・システムに12c (12.2.1.3.0)のOracle Fusion Middleware InfrastructureおよびOracle WebCenter Sitesのディストリビューションをダウンロードし、Oracle Universal Installerを使用してインストールします。 - RCUを使用した必要な12cスキーマの作成
アップグレード時、必要なスキーマを作成する必要があります。リポジトリ作成ユーティリティ(RCU)を使用してカスタマイズ・スキーマを作成するか、またはオプションで、Upgrade Assistantを使用してデフォルトのスキーマ設定を使用するスキーマを作成できます。この手順では、RCUを使用してスキーマを作成する方法について説明します。Upgrade Assistantを使用してスキーマを作成する方法は、アップグレード手順で説明しています。 - 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 Sites 12cを構成した後に、このトピックにリストされているタスクを実行します。 - アップグレード・アシスタントを実行する前に
アップグレード・アシスタントを実行して11.1.1.8からアップグレードする前に、このトピックにリストされているタスクを実行します。 - 製品スキーマのアップグレード
サーバーとプロセスの停止後に、Upgrade Assistantを使用して、サポートされている製品スキーマをOracle Fusion Middlewareの現在のリリースにアップグレードします。 - ドメイン・コンポーネント構成のアップグレード
製品スキーマのアップグレード後に、Upgrade Assistantを使用して、ドメイン内のドメイン・コンポーネント構成を、更新されたドメイン構成に一致するようにアップグレードします。 - アップグレード後の検証タスク
スキーマと構成が正常にアップグレードされた後でデータの整合性を確認するための、新しくアップグレードしたドメインで実行できる検証スクリプトが用意されています。検証の要約レポートをレビューして、スキーマと構成のアップグレード・プロセスの間にデータの不整合が発生していないか確認できます。 - アップグレード後のタスク
アップグレード後のタスクには、カスタム設定のリストア、管理サーバーと管理対象サーバーの起動、パスワードの再構成、およびこのトピックにリストされているその他の管理タスクが含まれます。 - カスタムJavaライブラリまたは静的Webリソースの移行
アップグレード前の環境でWebアプリケーションにカスタムJavaライブラリまたは静的Webリソースが追加されており、アップグレード後の環境でこれらを引き続き使用する場合にのみ、このオプション・ステップを実行します。 - Oracle WebCenter Sitesのアップグレードに関する問題のトラブルシューティング
この項では、WebCenter Sitesを最新リリースにアップグレードする際に発生する可能性のある問題の解決策について説明します。
WebCenter Sitesの11gから12cへのアップグレード・プロセスについて
Oracle WebCenter Sitesのアップグレード・プロセスの概要に関するフローチャートとロードマップを確認します。
図5-1 WebCenter Sitesの11gから12cリリースへのアップグレード・プロセスのフローチャート
「図5-1 WebCenter Sitesの11gから12cリリースへのアップグレード・プロセスのフローチャート」の説明
表5-1に、WebCenter Sitesを11gから12cにアップグレードするために実行する必要がある、タスクのロードマップを示します。
表5-1 WebCenter Sitesの11gから12cリリースへのアップグレードに関するタスク
| タスク | 説明 |
|---|---|
|
必須 このガイドの概要に関するトピックを再確認して、アップグレード前のタスクを完了します(まだ実行していない場合)。 |
アップグレード前タスクには、ご使用の本番環境のクローニング、システム要件および資格証明の確認、未使用データのパージおよび非SYSDBAユーザーの作成が含まれます。 アップグレード前タスクの完全なリストは、「Oracle WebCenterコンポーネントのアップグレード前のタスク」を参照してください。 |
|
必須 12c (12.2.1.3.0) Oracle Fusion Middleware InfrastructureおよびOracle WebCenter Sitesのディストリビューションをダウンロードおよびインストールします。 |
インフラストラクチャのディストリビューションには、その他のFusion Middleware製品をインストールするための基盤の設定に必要な、WebLogic ServerおよびJava Required Files (JRF)が同梱されています。 このガイドのアップグレード・トポロジに定義されているように、インフラストラクチャは新規のOracleホームにインストールする必要があります。 12.2.1.3.0Infrastructureをインストールすると作成されるOracleホームにOracle WebCenter Sitesのディストリビューションをインストールする必要があります。製品ディストリビューションをインストールするには、「製品ディストリビューションのインストール」の手順に従います。 |
|
必須 必要なスキーマを作成します。 |
WebCenter Sites 11gからアップグレードする場合は、アップグレードを開始する前に、12cの必要なスキーマを作成する必要があります。 WebCenter Sitesに必要なスキーマは、Oracle Platform Security Services (OPSS)、Audit Services (IAU)およびWebCenter Sitesです。 「RCUを使用した必要な12cスキーマの作成」の説明に従い、リポジトリ作成ユーティリティ(RCU)を使用してスキーマを作成します。 |
|
必須 WebCenter Sitesドメインを構成します。 |
11gから12cへのアップグレードは、アウトオブプレース・アップグレードです。そのため、「WebCenter Sitesドメインの構成」の手順に従って、WebCenter Sites 12c (12.2.1.3.0)ドメインを構成します。 |
|
必須 WebCenter Sitesインスタンスを構成します。 |
「WebCenter Sitesインスタンスの構成」で説明している手順に従って、ブラウザベースのWebCenter Sitesコンフィギュレータを実行し、WebCenter Sitesインスタンスを構成します。 |
|
必須 構成後のタスクを実行します。 |
構成後のタスクには、LDAPベースまたはOAMベースの認証を使用した12c (12.2.1.3.0)ドメインの構成、ディレクトリ構造の検証、サインインとSitesのUIへのアクセス、管理対象サーバーの再起動などが含まれます。 これらのタスクは、「構成後のタスク」にリストされています。 |
|
必須 必要なタスクを実行してから、アップグレード・アシスタントを実行します。 |
アップグレード前のタスクは、アップグレード・アシスタントを使用してアップグレード・プロセスを開始する前に完了している必要がある、一連のタスクです。 これらのタスクは、「アップグレード・アシスタントを実行する前に」にリストされています。 |
|
必須 スキーマをアップグレードします。 |
「製品スキーマのアップグレード」の手順に従い、アップグレード・アシスタントを使用して、アップグレード可能なスキーマ・コンポーネントをアップグレードします。 |
|
必須 Sitesの構成をアップグレードします。 |
「Upgrade Assistantを使用したSitesの構成のアップグレード」の手順に従い、Upgrade Assistantを使用して、11g (11.1.1.8)のドメインに含まれるSitesの構成をアップグレードします。 |
|
必須 アップグレード後の検証タスクを実行します。 |
スキーマと構成が正常にアップグレードされた後でデータの整合性を確認するための、新しくアップグレードしたドメインで実行できる検証スクリプトが用意されています。検証の要約レポートをレビューして、スキーマと構成のアップグレード・プロセスの間にデータの不整合が発生していないか確認できます。 検証スクリプトを使用するには、「アップグレード後の検証タスク」を参照してください。 |
|
必須 その他のアップグレード後のタスクを実行します。 |
その他のアップグレード後のタスクには、カスタム設定のリストア、管理サーバーと管理対象サーバーの起動、パスワードの再構成、および「アップグレード後のタスク」にリストされているその他の管理タスクが含まれます。 |
製品ディストリビューションのインストール
アップグレードを開始する前に、ターゲット・システムに12c (12.2.1.3.0)のOracle Fusion Middleware InfrastructureおよびOracle WebCenter Sitesのディストリビューションをダウンロードし、Oracle Universal Installerを使用してインストールします。
ノート:
アップグレードにInfrastructureが必要な場合は、その他のFusion Middleware製品をインストールする前に、まずOracle Fusion Middlewareディストリビューションをインストールする必要があります。Oracle HTTP Serverなど、ドメインを構成するすべてのOracle製品をダウンロードおよびインストールしたことを確認します。12.2.1.3.0バイナリは、新規のOracleホームにインストールする必要があります。既存のOracleホームと同じホスト上である必要があります。
RCUを使用した必要な12cスキーマの作成
アップグレード時、必要なスキーマを作成する必要があります。リポジトリ作成ユーティリティ(RCU)を使用してカスタマイズ・スキーマを作成するか、またはオプションで、Upgrade Assistantを使用してデフォルトのスキーマ設定を使用するスキーマを作成できます。この手順では、RCUを使用してスキーマを作成する方法について説明します。Upgrade Assistantを使用してスキーマを作成する方法は、アップグレード手順で説明しています。
ノート:
以前のOracle Fusion Middleware 12cリリースからアップグレードする場合は、これに該当するスキーマを再作成する必要はありません(そのスキーマがすでに存在する場合)。ドメインの既存のスキーマを特定するには、次のステップを参照してください。アップグレードの前に次のスキーマが存在する必要があります。12cからアップグレードする際、現在どのスキーマが存在しているか不明な場合は、次のステップを参照してドメイン内の既存のスキーマを識別します。これらのスキーマがすでに存在している場合、再作成する必要はありません。
-
サービス表スキーマ(
prefix_STB)。このスキーマは、ドメインベースのアップグレードに必要です。基本的なスキーマ構成情報(スキーマ接頭辞やパスワードなど)が格納され、他のOracle Fusion Middlewareコンポーネントはドメイン作成中にこれにアクセスして使用できます。このスキーマはリポジトリ作成ユーティリティ(RCU)を実行すると自動的に作成されます。RCUでは他の12cスキーマに使用した既存のスキーマ所有者接頭辞を指定します。ノート:
サービス表スキーマが存在しない場合、
UPGAST-00328: スキーマ・バージョンのレジストリ表はこのデータベースに存在しません。その場合、Upgrade Assistantを実行するためにはサービス表スキーマを作成する必要があります。というエラー・メッセージが表示されることがあります。 -
Oracle Platform Security Services (OPSS)スキーマ(
prefix_OPSS)。このスキーマは、12cでOIDベースのセキュリティ・ストアを使用している場合に必要です。このスキーマは、リポジトリ作成ユーティリティ(RCU)の実行時に自動的に作成されます。LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directory (OID)のみです。LDAPベースのポリシー・ストアは、通常、本番環境で使用します。アップグレード前に、OIDベースのセキュリティ・ストアを再関連付けする必要はありません。アップグレード・アシスタントの実行中に、OPSSスキーマを選択できます。アップグレード・アシスタントは、OIDベースのセキュリティ・ストアを自動的にアップグレードします。ノート:
12c OPSSデータベース・スキーマが必要なのは、ドメインの再構成時に12cスキーマを参照するためです。ドメインでは、アップグレード完了後にOIDベースのセキュリティ・ストアが引き続き使用されます。
-
監査サービス(
IAU) -
WebCenter Sites
WebCenter Sitesドメインの構成
WebCenter Sites 11gから12cにアップグレードする場合は、構成ウィザードを使用してWebCenter Sitesドメインを構成する必要があります。
ノート:
IBM DB2, WebCenter Sitesでは、Fusion Middleware構成ウィザードによって作成されるデフォルトのデータ・ソースをサポートしません。DB2がサポートするドライバを使用して新しいデータ・ソースを作成するには:-
WebCenter Sitesドメインのクラス・パスに、IBM DB2ドライバJARファイルを追加します。
-
WebLogic Server管理サーバーを停止します。
-
ドメインのクラス・パスに追加できる場所に、DB2の
db2jcc.jarおよびdb2jcc_license_cu.jarファイルをコピーします。 -
NEW_DOMAIN_HOME/bin/setDomainEnv.shを編集し、# ADD EXTENSIONS TO CLASSPATHSの後に次の行を追加します。PRE_CLASSPATH="path_to_db2jcc.jar:path_to_db2jcc_license_cu.jar:${PRE_CLASSPATH}" -
管理サーバーを起動します。
-
-
前述のDB2ドライバを使用して新しいデータ・ソースを作成します。
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が機能するために必要な表とデータがデータベースに移入されます。コンフィギュレータは、必要なユーザー・アカウントを設定し、データベース・オブジェクトの必要な権限も設定します。
WebCenter Sitesインスタンスの構成の前提条件
WebCenter Sitesコンフィギュレータを使用する前に、いくつかの前提条件タスクを実行する必要があります。これらのタスクには、OPSSのアクセス権限の付与、キャッシュ・ファイルの変更、および環境のプロパティ値の設定が含まれます。
親トピック: WebCenter Sitesインスタンスの構成
コンフィギュレータによるWebCenter Sitesの構成
WebCenter Sitesコンフィギュレータは、WebCenter Sitesが機能するために必要な表およびデータをデータベースに移入します。コンフィギュレータは、必要なユーザー・アカウントを設定し、データベース・オブジェクトの必要な権限も設定します。
ノート:
低速ネットワーク上でWebCenter Sitesを構成する場合は、WebCenter Sitesコンフィギュレータを起動する前に、StuckThreadMaxTimeプロパティの設定をスレッドごとに1000秒に増加します。デフォルト値は600秒です。
ネットワーク関連の問題が発生する可能性のある特定の環境では、WebCenter Sites構成の設定プロセスで、サンプル・サイトのインポート・プロセスの1スレッド当たりの所要時間が600秒を超える可能性があります。これによって、インポート・プロセスまたはインストールが失敗し、ログ・ファイルに複数の例外が記録される可能性があります。サンプル・サイトのインストールが正常に完了するために、設定を1000秒に増加することをお薦めします。
StuckThreadMaxTimeの値を変更するには、ドメインのWebLogic Server管理コンソールで、「サーバー」に移動し、wcsites_server1をクリックします。「構成」で、「チューニング」をクリックします。
- Webサーバー上でWebCenter Sitesを構成するには、WebCenter Sitesの構成を開始する前に、Webサーバーの
timeout値を300 secに増加します。 - WebCenter Sitesプライマリ・クラスタ・ノードの管理対象サーバーを起動します。
- Webブラウザで、このURLにアクセスします:
http://sites-host:sites-port/sites/sitesconfigsetup。 - 表示されるWebCenter Sitesコンフィギュレータの画面で、「開始」をクリックします。
- 「データベース・パラメータ」画面で、WebCenter Sitesデータベース・リポジトリの「JNDI DataSource名」を指定します。これは、WebLogicドメインの設定時にリポジトリ作成ユーティリティを使用して作成したリポジトリです。
- 「Webアプリケーション・パラメータ」画面で、安全な接続を介してインストールしている場合は「はい」を選択し、すべてのパラメータをデフォルトの(事前に移入された)値のままにし、「次」をクリックします。
- 「CASデプロイメント情報」画面で、すべてのパラメータをデフォルトの(事前に移入された)値のままにし、「次」をクリックします。ロード・バランシングのためにクラスタとフロントエンドWebサーバーを使用している場合は、環境に応じてこれらの値を調整します。
- 「WebCenter Sites管理者アカウント」画面で、必要な資格証明を指定し、「次」をクリックします。
- (オプション) WebCenter Sitesのインストール時に「WebCenter Sites - 例」インストール・オプションを選択した場合、「サンプル・サイト」画面が表示されます。この画面で、目的のサンプル・サイトを選択し、「次」をクリックします。
- 「構成サマリー」画面で「テスト」をクリックし、すべてのテストが成功しているかどうかを確認します。「開始」をクリックし、構成プロセスが完了するのを待ちます。
- WebCenter Sitesアプリケーションの管理対象サーバーを再起動します。
- Webブラウザで次のURLにアクセスしてログインし、WebCenter Sitesが稼働中かどうかを確認します:
http://sites-host:sites-port/sites。
ノート:
cas.logのデフォルトの場所は、NEW_DOMAIN_HOME/servers/wcsites_server1/logs/です。
CLASSPATH環境変数に次のディレクトリを設定します。NEW_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プロパティ・ファイル・リファレンスのプロパティ管理ツールの使用に関する項を参照してください。
親トピック: WebCenter Sitesインスタンスの構成
構成後のタスク
WebCenter Sites 12cを構成した後に、このトピックにリストされているタスクを実行します。
- 既存のSites 11.1.1.8環境がLDAPベースまたはOAMベースの認証を使用して構成されている場合は、 12.2.1.3.0環境も同じように構成します。
LDAPベースの認証に切り替えるには、「LDAPディレクトリに対する認証への切替え」を参照してください。
LDAPベースの認証に切り替えるには、「Oracle Access Managerに対する認証への切替え」を参照してください。 - ディレクトリ構造を確認します。Oracleホーム(製品のバイナリが含まれる)、Sitesホーム(ドメインおよび構成データ)、およびSites共有ディレクトリが、WebCenter Sitesの構成後に作成されている必要があります。
- 管理者の資格証明を使用してSites UIにサインインします。
- 管理対象サーバーを再起動してWebCenter Sitesにアクセスします。
- LDAPディレクトリに対する認証への切替え
このトピックでは、WebCenter Sitesを外部LDAP認証プロバイダ・ディレクトリに対する認証に切り替える方法について説明します。Oracle Access Managementとの統合を実行できない場合、これは本番環境のための推奨のソリューションです。 - Oracle Access Managerに対する認証への切替え
Oracle Access Managerに対する認証を行うようにWebCenter Sitesを構成できます。このソリューションは本番環境にお薦めします。
LDAPディレクトリに対する認証への切替え
このトピックでは、WebCenter Sitesを外部LDAP認証プロバイダ・ディレクトリに対する認証に切り替える方法について説明します。Oracle Access Managementとの統合を実行できない場合、これは本番環境のための推奨のソリューションです。
親トピック: 構成後タスク
Oracle Access Managerに対する認証への切替え
Oracle Access Managerに対する認証を行うようにWebCenter Sitesを構成できます。このソリューションは本番環境にお薦めします。
oamconsoleを使用したOAMサーバーの構成とSites内の一部の構成の変更が必要です。
- WebCenter SitesのためのOracle Access Managerの構成で、保護リソース、パブリック・リソースおよび除外リソースを次のように更新します。
図5-2 WebCenter Sites用の保護されたリソース、パブリック・リソースおよび除外されたリソースのリスト
「図5-2 WebCenter Sites用の保護されたリソース、パブリック・リソースおよび除外されたリソースのリスト」の説明
- SiteCaptureのOAMとの統合
この項では、SiteCaptureのOAMとの統合ステップを示します。 - OAMとOracle WebCenter Sites: Satellite Serverの統合
この項では、OAMのOracle WebCenter Sites: Satellite Serverとの統合ステップを示します。 - OAMと訪問者サービスの統合
この項では、OAMのVisitor Servicesとの統合ステップを示します。
親トピック: 構成後タスク
SiteCaptureのOAMとの統合
この項では、SiteCaptureのOAMとの統合ステップを示します。
OAMとOracle WebCenter Sites: Satellite Serverの統合
この項では、OAMのOracle WebCenter Sites: Satellite Serverとの統合ステップを示します。
ノート:
次のコード例では、OAM OHSのRSS構成およびmod_wl_ohs.confファイルを指定します。<IfModule weblogic_module>
<Location /ss>
SetHandler weblogic-handler
WebLogicHost SATELLITESERVER_HOST
WebLogicPort SATELLITESERVER_HOST
</Location>
</IfModule>OAMと訪問者サービスの統合
この項では、OAMのVisitor Servicesとの統合ステップを示します。
ノート:
次のコード例では、OAM OHSの訪問者構成およびmod_wl_ohs.confファイルを指定します。<IfModule weblogic_module>
<Location /oamlogin>
SetHandler weblogic-handler
WebLogicHost SITES_HOST
WebLogicPort SITES_PORT
</Location>
</IfModule>
<IfModule weblogic_module>
<Location /visitors-webapp>
SetHandler weblogic-handler
WebLogicHost VISITORSERVICES_HOST
WebLogicPort VISITORSERVICES_HOST
</Location>
</IfModule>アップグレード・アシスタントを実行する前に
アップグレード・アシスタントを実行して11.1.1.8からアップグレードする前に、このトピックにリストされているタスクを実行します。
- Upgrade Assistantを実行するための非SYSDBAユーザーの作成
Upgrade Assistantを実行するには、FMWと呼ばれる非SYSDBAユーザーを作成することをお薦めします。このユーザーには、スキーマの変更に必要な権限はありますが、完全な管理者権限はありません。 - DB2ソースから新規ターゲット・データベースへの11.1.1.8スキーマのコピー
スキーマをアップグレードする前に、Sites 11.1.1.8のスキーマをソースDB2データベースからターゲット・データベース(12.2.1.3.0のSitesスキーマが設定されている)にインポートする必要があります。
アップグレード・アシスタントを実行するための非SYSDBAユーザーの作成
Upgrade Assistantを実行するために、FMWという非SYSDBAユーザーを作成することをお薦めします。このユーザーには、スキーマの変更に必要な権限はありますが、完全な管理者権限はありません。
ノート:
SYSDBAではないユーザーFMWは、アップグレード・アシスタントを実行するためにのみ作成されます。このステップが完了したら、このFMWユーザーを削除してください。アップグレード・アシスタントを実行するために必要な権限は、リリースごとに異なる可能性があります。v$xatrans$表は存在しません。ユーザーを作成する前に、XAVIEW.SQLスクリプトを実行して、この表を作成する必要があります。さらに、v$xatrans$表のgrant select権限は、Oracle Identity Governanceでのみ必要です。構成にOracle Identity Governanceが必要ない場合、またはv$xatrans$表が存在しない場合は、次の行をスクリプトから削除します。 grant select on v$xatrans$ to FMW with grant option;passwordはFMWユーザーに対して設定されたパスワードです。権限を付与する際は、必ず実際のパスワードを指定してください。create user FMW identified by password;
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;
grant select on dba_subscr_registrations to FMW with grant option;
grant manage scheduler to FMW;Oracle Identity Manager (OIM)スキーマをアップグレードする場合は、FMWユーザーに次の追加の権限が付与されていることを確認します。
grant execute on SYS.DBMS_FLASHBACK to fmw with grant option;
grant execute on sys.DBMS_SHARED_POOL to fmw with grant option;
grant execute on SYS.DBMS_XMLGEN to FMW with grant option;
grant execute on SYS.DBMS_DB_VERSION to FMW with grant option;
grant execute on SYS.DBMS_SCHEDULER to FMW with grant option;
grant execute on SYS.DBMS_SQL to FMW with grant option;
grant execute on SYS.DBMS_UTILITY to FMW with grant option;
grant ctxapp to FMW with admin option;
grant execute on SYS.DBMS_FLASHBACK TO FMW with grant option;
grant create MATERIALIZED VIEW to FMW with admin option;
grant all on SCHEMA_VERSION_REGISTRY TO FMW with grant option;
grant create SYNONYM to FMW with admin option;
grant execute on CTXSYS.CTX_ADM to FMW with grant option;
grant execute on CTXSYS.CTX_CLS TO FMW with grant option;
grant execute on CTXSYS.CTX_DDL TO FMW with grant option;
grant execute on CTXSYS.CTX_DOC TO FMW with grant option;
grant execute on CTXSYS.CTX_OUTPUT TO FMW with grant option;
grant execute on CTXSYS.CTX_QUERY TO FMW with grant option;
grant execute on CTXSYS.CTX_REPORT TO FMW with grant option;
grant execute on CTXSYS.CTX_THES TO FMW with grant option;
grant execute on CTXSYS.CTX_ULEXER TO FMW with grant option;
grant create JOB to FMW with admin option;親トピック: アップグレード・アシスタントを実行する前に
DB2ソースから新規ターゲット・データベースへの11.1.1.8スキーマのコピー
スキーマをアップグレードする前に、Sites 11.1.1.8のスキーマをソースDB2データベースからターゲット・データベース(12.2.1.3.0のSitesスキーマが設定されている)にインポートする必要があります。
ノート:
このタスクは、ご使用のデータベースがDB2上に存在する場合にのみ適用されます。OracleまたはMS SQL Serverデータベースの場合は、このタスクをスキップできます。
- データベースのインポートを実行するユーザーに、ターゲット・データベースに対する必要な権限が付与されていることを確認します。
- ターゲット・データベースのAPPLHEAPSZを、スキーマ・サイズに対応した適切な値に設定します。
親トピック: アップグレード・アシスタントを実行する前に
製品スキーマのアップグレード
サーバーとプロセスの停止後に、Upgrade Assistantを使用して、サポートされている製品スキーマをOracle Fusion Middlewareの現在のリリースにアップグレードします。
アップグレード・アシスタントを使用すると、個別に選択したスキーマまたはドメインに関連付けられているすべてのスキーマをアップグレードできます。選択したオプションによって、表示されるアップグレード・アシスタントの画面は異なります。
- Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。 - アップグレード・アシスタントを使用した製品スキーマのアップグレード
アップグレード・アシスタントの各画面を移動して、製品スキーマをアップグレードします。 - スキーマのアップグレードの確認
すべてのアップグレード・ステップを完了したら、schema_version_registryのスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードの成功を検証します。
アップグレード・アシスタントの起動
Upgrade Assistantを実行して、製品のスキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。
ノート:
Upgrade Assistantを起動する前に、Upgrade Assistantが稼働している環境に対して、JVM文字エンコードがUTF-8に設定されていることを確認します。文字エンコードがUTF-8に設定されていない場合、それらの名前にUnicode文字が含まれているファイルをダウンロードすることはできません。これによってアップグレードが失敗することがあります。
oracle_common/upgrade/binディレクトリに移動します。- (UNIX)
NEW_ORACLE_HOME/oracle_common/upgrade/bin - (Windows)
NEW_ORACLE_HOME\oracle_common\upgrade\bin
- (UNIX)
- Upgrade Assistantを起動します。
- (UNIX) ./ua
- (Windows) ua.bat
コマンドラインに指定可能なその他のパラメータ(ロギングのパラメータなど)の詳細は、次を参照してください。
アップグレード・アシスタントのパラメータ
コマンドラインからアップグレード・アシスタントを起動するときに、追加のパラメータを指定できます。
表5-9 アップグレード・アシスタントのコマンドライン・パラメータ
| パラメータ | 必須またはオプション | 説明 |
|---|---|---|
|
|
準備状況チェックの場合は必須
ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。 |
アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。 スキーマと構成がチェックされます。
|
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
|
サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須 |
アップグレード・アシスタントがGUIモードで実行されているときに入力したデータから生成されるレスポンス・ファイルに保存されている入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。 |
|
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
|
オプション |
次のいずれかの属性を指定して、ログイン・レベルを設定します。
デフォルトのロギング・レベルは
|
|
|
オプション |
アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 (UNIX)
(Windows)
|
|
|
オプション |
すべてのコマンドライン・オプションを表示します。 |
親トピック: Upgrade Assistantの起動
アップグレード・アシスタントを使用した製品スキーマのアップグレード
Upgrade Assistantの各画面を通じて、製品スキーマをアップグレードします。
親トピック: 製品スキーマのアップグレード
スキーマのアップグレードの確認
すべてのアップグレード・ステップを完了したら、schema_version_registryのスキーマ・バージョンが適切に更新されていることをチェックして、アップグレードの成功を検証します。
Oracle Databaseを使用する場合、Oracle DBAを持つユーザーとしてデータベースに接続し、SQL*Plusから次を実行して現行のバージョン番号を取得します。
SET LINE 120 COLUMN MRC_NAME FORMAT A14 COLUMN COMP_ID FORMAT A20 COLUMN VERSION FORMAT A12 COLUMN STATUS FORMAT A9 COLUMN UPGRADED FORMAT A8 SELECT MRC_NAME, COMP_ID, OWNER, VERSION, STATUS, UPGRADED FROM SCHEMA_VERSION_REGISTRY ORDER BY MRC_NAME, COMP_ID ;
問合せ結果について:
-
VERSION列の数値が、そのスキーマの最新のバージョン番号に一致していることを確認します。たとえば、スキーマ・バージョン番号が12.2.1.3.0になっていることを確認します。ノート:
ただし、すべてのスキーマ・バージョンが更新されるわけではありません。一部のスキーマではこのリリースへのアップグレードが必要なく、アップグレード前のバージョン番号が保持されます。
-
STATUSフィールドは、スキーマのパッチ適用操作中はUPGRADINGまたはUPGRADEDのどちらかになり、パッチ適用操作が完了するとVALIDになります。 -
ステータスが
「INVALID」と表示された場合は、ステータスの更新が失敗しています。ログ・ファイルを調べて、失敗した理由を判定する必要があります。 -
IAU_APPENDとIAU_VIEWERが所有するシノニム・オブジェクトは、INVALIDと表示されますが、失敗を意味するものではありません。これらは、シノニムの作成後にターゲット・オブジェクトが変更されるため無効になります。シノニム・オブジェクトは、アクセスされるときに有効になります。これに該当する
INVALIDオブジェクトは、無視しても問題ありません。
親トピック: 製品スキーマのアップグレード
ドメイン・コンポーネント構成のアップグレード
製品スキーマのアップグレード後に、Upgrade Assistantを使用して、ドメイン内のドメイン・コンポーネント構成を、更新されたドメイン構成に一致するようにアップグレードします。
- Upgrade Assistantの起動
Upgrade Assistantを実行して、製品スキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。 - Upgrade Assistantを使用したSites構成のアップグレード
Upgrade Assistantを使用して、Sites構成をアップグレードする必要があります。 - ドメイン固有コンポーネント構成のアップグレードの確認
ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlにサインインし、各コンポーネントのバージョン番号が12.2.1.3.0であることを確認します。
アップグレード・アシスタントの起動
Upgrade Assistantを実行して、製品のスキーマ、ドメイン・コンポーネント構成、またはスタンドアロンのシステム・コンポーネントを12c (12.2.1.3.0)にアップグレードします。一度に1つのドメインのアップグレードを完了して、アップグレード・アシスタントを非SYSDBAユーザーとして実行することをお薦めします。
ノート:
Upgrade Assistantを起動する前に、Upgrade Assistantが稼働している環境に対して、JVM文字エンコードがUTF-8に設定されていることを確認します。文字エンコードがUTF-8に設定されていない場合、それらの名前にUnicode文字が含まれているファイルをダウンロードすることはできません。これによってアップグレードが失敗することがあります。
oracle_common/upgrade/binディレクトリに移動します。- (UNIX)
NEW_ORACLE_HOME/oracle_common/upgrade/bin - (Windows)
NEW_ORACLE_HOME\oracle_common\upgrade\bin
- (UNIX)
- Upgrade Assistantを起動します。
- (UNIX) ./ua
- (Windows) ua.bat
コマンドラインに指定可能なその他のパラメータ(ロギングのパラメータなど)の詳細は、次を参照してください。
アップグレード・アシスタントのパラメータ
コマンドラインからアップグレード・アシスタントを起動するときに、追加のパラメータを指定できます。
表5-10 アップグレード・アシスタントのコマンドライン・パラメータ
| パラメータ | 必須またはオプション | 説明 |
|---|---|---|
|
|
準備状況チェックの場合は必須
ノート: 準備状況チェックはスタンドアロン・インストール上で実行できません(WebLogic Serverの管理対象でありません)。 |
アップグレードの準備状況チェックを実行します(実際のアップグレードは実行しません)。 スキーマと構成がチェックされます。
|
|
|
オプション |
スキーマの同時アップグレードまたはスキーマの準備状況チェックに使用可能なスレッドの数を特定します。 値は、1 - 8の正の整数である必要があります。デフォルトは4です。 |
|
|
サイレント・アップグレードまたはサイレント準備状況チェックの場合は必須 |
アップグレード・アシスタントがGUIモードで実行されているときに入力したデータから生成されるレスポンス・ファイルに保存されている入力を使用して、アップグレード・アシスタントを実行します。このパラメータを使用すると、アップグレード・アシスタントはサイレント・モード(アップグレード・アシスタントの画面表示なし)で実行されます。 |
|
|
オプション |
調査フェーズを実行しますが、実際のアップグレードは実行しません。
|
|
|
オプション |
次のいずれかの属性を指定して、ログイン・レベルを設定します。
デフォルトのロギング・レベルは
|
|
|
オプション |
アップグレード・ログ・ファイルと一時ファイルのデフォルトの場所を設定します。Upgrade Assistantによってログ・ファイルおよび一時ファイルが作成される、既存の書込み可能なディレクトリを指定する必要があります。 デフォルトの場所は次のとおりです。 (UNIX)
(Windows)
|
|
|
オプション |
すべてのコマンドライン・オプションを表示します。 |
親トピック: Upgrade Assistantの起動
Upgrade Assistantを使用したSites構成のアップグレード
アップグレード・アシスタントを使用して、Sitesの構成をアップグレードする必要があります。
構成のアップグレードは、11gの開始ポイントと同様にApache TomcatおよびIBM WebSphereサーバーでサポートされます。
-
Oracle
-
Microsoft SQL
-
DB2
-
Oracle WebLogic Server
-
Apache Tomcat
-
IBM WebSphere
ノート:
構成のアップグレードの準備状況チェックは、11gの開始ポイントでは使用できません。親トピック: ドメイン・コンポーネント構成のアップグレード
ドメイン固有コンポーネント構成のアップグレードの確認
ドメイン固有コンポーネント構成のアップグレードが成功したことを確認するには、管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlにサインインし、各コンポーネントのバージョン番号が12.2.1.3.0になっていることを確認します。
管理コンソールにサインインするには、次に移動します。http://administration_server_host:administration_server_port/console
Oracle Enterprise Manager Fusion Middleware Control Consoleにサインインするには、次に移動します。http://administration_server_host:administration_server_port/em
ノート:
アップグレード後、管理ツールは、前のOracleホーム・ディレクトリからではなく新しい12cのOracleホーム・ディレクトリから必ず実行してください。
アップグレード・プロセス時に、一部のOWSMドキュメント(ポリシー・セット、ポリシーおよびアサーション・テンプレートなどの事前定義ドキュメント)のアップグレードが必要な場合があります。ポリシー・セットまたは事前定義ドキュメントがアップグレードされると、バージョン番号が1増分されます。
Upgrade Assistantを実行するためにFMWユーザーを作成した場合は、アップグレードが成功したことを確認してからアカウントを削除してください。
親トピック: ドメイン・コンポーネント構成のアップグレード
アップグレード後の検証タスク
スキーマと構成が正常にアップグレードされた後でデータの整合性を確認するための、新しくアップグレードしたドメインで実行できる検証スクリプトが用意されています。検証の要約レポートをレビューして、スキーマと構成のアップグレード・プロセスの間にデータの不整合が発生していないか確認できます。
アップグレード後のタスク
アップグレード後のタスクには、カスタム設定のリストア、管理サーバーと管理対象サーバーの起動、パスワードの再構成、およびこのトピックにリストされているその他の管理タスクが含まれます。
- サーバーおよびプロセスの起動
正常なアップグレードの後に、管理サーバーや管理対象サーバーなど、すべてのプロセスおよびサーバーを再起動します。 - 既存のインスタンスが配信インスタンスの場合...
11gから最新の12cリリースにアップグレードしている場合および既存のインスタンスが配信インスタンスである場合は、ユーザーが公開したSitesのアプリケーションを手動で再度割り当てる必要があります。
サーバーおよびプロセスの起動
正常なアップグレードの後に、管理サーバーや管理対象サーバーなど、すべてのプロセスおよびサーバーを再起動します。
コンポーネントは相互に依存していることがあるため、適切な順序で起動する必要があります。
ノート:
この項の手順では、WLSTコマンドラインまたはスクリプトを使用してサーバーとプロセスを起動する方法について説明します。Oracle Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールを使用することもできます。『Oracle Fusion Middlewareの管理』の管理サーバーと管理対象サーバーおよびノード・マネージャの起動と停止に関する項を参照してください。Fusion Middleware環境を起動するには、次のステップに従います。
ステップ1: 管理サーバーの起動
管理サーバーを起動する場合、管理サーバーで稼働しているWebLogic Server管理コンソールやFusion Middleware Controlなどのプロセスも起動します。
管理サーバーを起動するには、startWebLogicスクリプトを使用します。
-
(UNIX)
NEW_DOMAIN_HOME/bin/startWebLogic.sh -
(Windows)
NEW_DOMAIN_HOME\bin\startWebLogic.cmd
プロンプトが表示されたら、管理サーバーのユーザー名とパスワード、およびURLを入力します。
ステップ2: ノード・マネージャを起動する
ノード・マネージャを起動するには、startNodeManagerスクリプトを使用します。
-
(UNIX)
NEW_DOMAIN_HOME/bin/startNodeManager.sh -
(Windows)
NEW_DOMAIN_HOME\bin\startNodeManager.cmd
ステップ3: Oracle Identity Managementのコンポーネントを起動する
環境を構成しているOracle Internet DirectoryなどのOracle Identity Managementコンポーネントがあれば、それをすべて起動します。-
(UNIX)
NEW_DOMAIN_HOME/bin/startComponent.sh component_name -
(Windows)
NEW_DOMAIN_HOME\bin\startComponent.cmd component_name
ステップ4: 管理対象サーバーを起動する
WebLogic Server管理対象サーバーを起動するには、startManagedWebLogicスクリプトを使用します。
-
(UNIX)
NEW_DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url -
(Windows)
NEW_DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url
プロンプトが表示されたらユーザー名とパスワードを入力します。
ノート:
通常、管理対象サーバーを起動すると、そのサーバーにデプロイされているアプリケーションが開始されます。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。ステップ5: システム・コンポーネントを起動する
Oracle HTTP Serverなどのシステム・コンポーネントを起動するには、startComponentスクリプトを使用します。
-
(UNIX)
NEW_DOMAIN_HOME/bin/startComponent.sh component_name -
(Windows)
NEW_DOMAIN_HOME\bin\startComponent.cmd component_name
システム・コンポーネントは任意の順序で起動できます。
親トピック: アップグレード後のタスク
既存のインスタンスが配信インスタンスの場合...
11gから最新の12cリリースにアップグレードしている場合および既存のインスタンスが配信インスタンスである場合は、ユーザーが公開したSitesのアプリケーションを手動で再度割り当てる必要があります。
- AdminSiteに管理者としてサインインします。
- ユーザー公開サイトに管理アプリケーションを追加するには:
- AdminSiteの下のWEM Adminに移動します。
- 「アプリケーション」をクリックします。次に、管理アプリケーションの下の「アプリケーションの管理」をクリックします。
- 「サイトへの割当て」をクリックします。「サイトの選択」、「続行」の順にクリックします。
- 上級ユーザー・ロールを選択し、変更を保存します。
- ユーザー公開サイトにコントリビュータ・アプリケーションを追加するには:
- AdminSiteの下のWEM Adminに移動します。
- 「アプリケーション」をクリックします。次に、管理アプリケーションの下の「アプリケーションの管理」をクリックします。
- 「サイトへの割当て」をクリックします。「サイトの選択」、「続行」の順にクリックします。
- Sitesユーザー・ロールを選択し、変更を保存します。
- その他のアプリケーションを追加するには、同様の手順を実行し、必要なロールを割り当てます。
親トピック: アップグレード後のタスク
カスタム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が共有ライブラリとして提供されます。このファイルはNEW_ORACLE_HOME/wcsites/webcentersites/sites-home/ディレクトリにあります。静的Webリソースなどの実装固有のカスタマイズやJAVAライブラリを、このWARファイルに含めることができます。この共有ライブラリは、アプリケーションのライフサイクルの進行中にデプロイされ、Sitesと同じコンテキスト・ルーツ(/sites/)を共有します。この共有ライブラリのコンテンツは、パッチ適用プロセスでの処理中に上書きされることはありません。
また、Sites UIがカスタマイズされている場合は、コードの変更もアップグレード後の環境に移行する必要があります。
Oracle WebCenter Sitesのアップグレードに関する問題のトラブルシューティング
この項では、WebCenter Sitesを最新リリースにアップグレードする際に発生する可能性のある問題の解決策について説明します。
- JSPがコンパイルに失敗
コンパイル済サイズがJVMの制限である65,535バイトを超えている場合、JSPはコンパイルに失敗します。
JSPがコンパイルに失敗
コンパイル済サイズがJVMの制限である65,535バイトを超えている場合、JSPはコンパイルに失敗します。
Oracle WebCenter Sites 12cでは、以前のバージョンのWebCenter Sitesより新しいバージョンのJavaであるJava 8を使用します。以前のバージョンでは正常にコンパイルされたが、12cではコンパイルに失敗するJSPが存在する可能性があります。これは、Java 8のコーディングが改善され、最終的なJSPのサイズがJVMバイト制限の64kを超えるために発生します。
この問題の1つの症状は、アセットをプレビューしようとすると空白のページが返されることです。これが発生すると、sites.logファイルに次のようなエラーが表示されることがあります:
[2016-09-26T19:19:16.407+00:00] [wcsites_server1] [ERROR] [] [oracle.wcsites.request] [tid: 122] [userId: ] [ecid: a7d5aa49-3d67-4d85-80b4-eec23130c460-00000119,0] [APP: sites] [partition-name: DOMAIN] [tenant-name: GLOBAL] Exception including resource /jsp/cs_deployed/Asset_C/AssetNavImage/Detail.jsp[[ javax.servlet.ServletException: weblogic.servlet.jsp.CompilationException: Failed to compile JSP /jsp/cs_deployed/Asset_C/AssetNavImage/Detail.jsp Detail.jsp:7:4: The code of method _jspService(HttpServletRequest, HttpServletResponse) is exceeding the 65535 bytes limit個々のJSPのサイズを減らすには、他のJSPの静的インクルードを動的インクルードに変更します。
詳細は、My Oracle Supportのノート2195050.1を参照してください