| Oracle® Fusion Middleware Oracle Portal管理者ガイド 11g リリース1(11.1.1) B61385-02 |
|
 前 |
 次 |
この付録では、Oracle Fusion Middleware Portalの使用中に発生する可能性のある一般的な問題と、それらの解決方法について説明します。また、Oracle Portalの問題の診断方法について詳細な手順を示します。この項の内容は次のとおりです。
この項では、一般的な障害と解決策について説明します。次の項目が含まれます。
たとえば、Oracle Portalへのアクセスを試みたときに、ページが表示されないか、「HTTP 503: サービスが使用できません」エラー、またはリクエスト処理中にエラーが発生しました。ブラウザをリフレッシュしてください。この問題が継続して発生する場合は、サイトの管理者にお問い合せください。エラーが発生します。
Oracle Portalでは、Oracle HTTP Server、Oracle Web Cache、Portalサービス、Oracle Metadata Repository、WLS_PORTALなどのOracle Fusion Middlewareコンポーネントが起動され、稼働中であることが必要です。これらのコンポーネントのいずれかが使用不能(停止中)である可能性があります。
問題1
Oracle HTTP Serverが停止中です。
解決策1
Fusion Middleware Controlで、Oracle Portalのホーム・ページを表示します。詳細は、第8.2項「Fusion Middleware Controlを使用したOracle Portalの監視と管理」を参照してください。
Oracle HTTP Serverが稼働中であるかどうかを確認します。Oracle HTTP Serverの状態が、Oracle Fusion Middleware Controlホーム・ページの「Fusion Middleware」ペインに表示されます。
状態が「稼働中」の場合は、次の手順に進みます。
状態が「停止中」の場合は、Fusion Middleware ControlからOracle HTTP Serverを起動します。
Fusion Middleware Controlを使用してOracle HTTP Serverを起動するには、次の手順を実行します。
ナビゲーション・ペインで「Web層」を開いて、HTTP Serverを選択します(デフォルトではohs1)。
「ohs1」を右クリックして、「制御」→「起動」を選択してOracle HTTP Serverを起動します。
Oracle HTTP Serverが正常に起動した場合は、ポータルにアクセスできるかどうかを確認します。
Oracle HTTP Serverを起動できない場合は、Log Viewerを使用してOracle HTTP Serverのエラー・ログ・ファイルを調べて問題の特定を試みてください。詳細は、第G.2.4項「Fusion Middleware ControlのLog Viewerの使用」を参照してください。
Log Viewerを使用していない場合は、ORACLE_INSTANCE\diagnostics\logs\OHS\ohs1\access_logディレクトリおよびORACLE_INSTANCE\diagnostics\logs\OHS\ohs1\console~OHS~1.logディレクトリにある関連のエラー・ログ・ファイルを確認します。
|
関連項目: 『Oracle Fusion Middleware Administrator's Guide for Oracle HTTP Server』 |
問題2
Oracle Web Cacheが停止中です。
解決策2
Oracle Web Cacheプロセスが実行されているOracle PortalのFusion Middleware Controlに移動します。詳細は、Oracle Fusion Middleware Oracle Web Cache管理者ガイドを参照してください。
Oracle Web Cacheが稼働中であるかどうかを確認します。Oracle Web Cacheの状態は、Fusion Middlewareの「システム・コンポーネント」表に表示されます。
状態が「稼働中」の場合は、次の手順に進みます。
状態が「停止中」の場合は、Fusion Middleware Controlを使用してOracle Web Cacheを起動します。
Fusion Middleware ControlでOracle Web Cacheの監視および管理のページにアクセスするには、Fusion Middlewareの「システム・コンポーネント」表の「Webキャッシュ」をクリックします。
Oracle Web Cacheが正常に起動した場合は、ポータルにアクセスできるようになったかどうかを確認します。
Oracle Web Cacheを起動できない場合は、Oracle Web Cacheのエラー・ログ・ファイルを調べて問題の特定を試みてください。詳細は、第G.2.4項「Fusion Middleware ControlのLog Viewerの使用」を参照してください。
Log Viewerを使用していない場合は、ORACLE_INSTANCE\diagnostics\logs\WebCache\wc1\access_logディレクトリおよびORACLE_INSTANCE\diagnostics\logs\WebCache\wc1\event_logディレクトリにある関連のエラー・ログ・ファイルを確認してください。
問題3
Portal DADの構成が不正なため、Oracle Portalが稼働していません。
解決策3
Oracle Portal DADの状態および構成を確認します。Fusion Middleware Controlで、Oracle Portalのホーム・ページに移動します。Oracle Portalホーム・ページで「設定」→「データベース・アクセス記述子」をクリックします。「データベース・アクセス記述子の構成」ページの「DAD」表で、ポータルに構成したDADが稼働しているかどうかを確認します。
状態が「稼働中」の場合は、次の手順に進みます。
状態が「停止中」の場合は、「DAD」表でDADの名前をクリックし、すべてのプロパティが正しく設定されていることを確認します。変更を保存し、WLS_PORTALとOracle HTTP Serverの両方を再起動して、変更を有効にします。ポータルのホーム・ページでDADを構成する方法については、第5.6.4項「Fusion Middleware Controlを使用したポータルDADの構成」を参照してください。
|
注意: DADのデータベース接続の詳細は、ポータルのOracle Fusion Middlewareに関連付けられたOracleホーム・ディレクトリから、SQL*Plusを使用して確認できます。DAD設定のページには、パスワードが暗号化された形式で表示されるため、パスワードを再入力して、パスワードの有効性に問題がないことを確認します。 |
ポータルにアクセスできるようになったかどうかを確認します。
問題4
Oracle Metadata Repositoryが停止中です。
解決策4
Oracle Fusion Middleware Controlで、Oracle Portalのホーム・ページを表示します。詳細は、第8.2項「Fusion Middleware Controlを使用したOracle Portalの監視と管理」を参照してください。
「Portalによって使用されるOracle Metadata Repository」セクションを調べます。
状態が「稼働中」の場合は、次の手順に進みます。
状態が「停止中」の場合は、データベースを起動します。
データベースが正常に起動した場合は、ポータルにアクセスできるようになったかどうかを確認します。
問題5
WLS_PORTALサービスが停止中です。
解決策5
Oracle Fusion Middleware Controlで、Oracle Portalインスタンスのドメインのホーム・ページを表示します。詳細は、第8.1項「Oracle Enterprise Manager 11g Fusion Middleware Controlの使用」を参照してください。
WLS_PORTALの状態は、「システム・コンポーネント」表に表示されます。
状態が「稼働中」の場合は、次の手順に進みます。
状態が「停止中」の場合は、Oracle Fusion Middleware Controlを使用してWLS_PORTALを起動します。
Oracle Fusion Middleware ControlでWLS_PORTALの監視および管理のページにアクセスするには、次のいずれかの場所で「WLS_PORTAL」をクリックします。
「Parallel Page Engineサービス」ページ(Oracle Portalホーム・ページの「コンポーネント・ステータス」表からアクセス可能)
Fusion Middlewareの「システム・コンポーネント」表
WLS_PORTALが正常に起動した場合は、ポータルにアクセスできるようになったかどうかを確認します。
WLS_PORTALを起動できない場合は、WLS_PORTALのエラー・ログ・ファイルを調べて問題の特定を試みてください。詳細は、第G.2.4項「Fusion Middleware ControlのLog Viewerの使用」を参照してください。
問題6
SQL* Netリスナーが停止中であるか、構成が間違っています。
解決策6
メタデータ・リポジトリがインストールされているホストで、SQL*NET TNSリスナーが稼働中であるかどうかを確認します。データベースが存在するコンピュータにログインします。現在のディレクトリが$PATHでない場合は、ORACLE_INSTANCE/binディレクトリに移動し、次のコマンドを使用して、TNSリスナーの状態を確認します。
lsnrctl status
サービスが稼働していない場合は、次のコマンドでサービスを起動します。
lsnrctl start
サービスがすでに稼働している場合は、Oracle Databaseドキュメント・ライブラリの『Oracle Database Net Services管理者ガイド』を参照し、Oracle Net Servicesのトラブルシューティングの方法を確認してください。
問題7
Portalサービスが別のエラーをレポートしています。
解決策7
次の手順に従って、問題を解決します。
ORACLE_HOME/opmn/binに移動して、opmntl statusコマンドを発行します。キー・サービスの状態が稼働中であることを確認します。稼働中でない場合は、ORACLE_HOME/opmn/logsの下にあるファイルで詳細を調べてください。
ORACLE_INSTANCE/webcache/logsに移動します。event_logファイルで、問題箇所を調べます。
パブリック・ホームページにアクセスできるのに、ログインできません。この問題の一般的な現象は次のとおりです。
「ログイン」をクリックしても、ログイン・ページが表示されません。
OracleAS Single Sign-Onのログイン・ページで資格証明を入力した後、エラーが発生します。
認証された後、Oracle Portalのページでエラーが発生します。
問題1
Oracle Portalへのログイン・プロセス中に発生した問題が原因で、Oracle Portalにログインできないと考えられます。
Oracle Portalのログイン・プロセスは、論理的に次の3つの部分に分けることができます。
OracleAS PortalとOracle Single Sign-On間の通信
Oracle PortalとOracle Internet Directory間の通信
ホームページの割当て
解決策1
この問題の原因を診断するには、ログイン・プロセスの各部分に焦点をおいて解決策を調べます。
Oracle PortalとOracleAS Single Sign-On間の通信の検証
ログイン・プロセスの最初の部分を理解するために、Oracle Portalが次のURLでアクセスされると想定します。
http://www.company.com/portal/pls/portal/
パブリック・ホームページで「ログイン」をクリックすると、OracleAS Single Sign-Onのページにリダイレクトされます。たとえば、次のURLに変更されます。
http://login.company.com:4443/pls/sso
管理者から指定されたユーザー名とパスワードを入力して「ログイン」をクリックすると、ユーザー情報がOracleAS Single Sign-OnからOracle Portalに送り返されます。
ログイン・プロセスのこの部分で発生した問題の原因を診断するには、次の手順を実行します。
Oracle Enterprise Manager 11g Fusion Middleware ControlでOracleAS Single Sign-Onのホーム・ページを表示します。
OracleAS Single Sign-Onのホーム・ページには、Infrastructureホーム・ディレクトリ・インスタンスのホーム・ページからアクセスできます。
詳細は、『Oracle Application Server Single Sign-On管理者ガイド』の「スタンドアロン・コンソールのホームページの解説と使用方法」を参照してください。
Oracle HTTP Serverが稼働中であるかどうかを確認します。
「関連リンク」セクションに表示された「HTTP_Server」をクリックします。
状態が「稼働中」の場合は、次の手順に進みます。
状態が「停止中」の場合は、Oracle Fusion Middleware Controlを使用してOracle HTTP Serverを起動します。
Oracle Fusion Middleware ControlでOracle HTTP Serverの監視および管理のページにアクセスするには、次のいずれかの場所で「HTTP_Server」をクリックします。
OracleAS Single Sign-Onのホーム・ページ
Fusion Middlewareの「システム・コンポーネント」表
Oracle HTTP Serverが正常に起動した場合は、ログインできるようになったかどうかを確認します。
Oracle HTTP Serverを起動できない場合は、Oracle HTTP Serverのエラー・ログ・ファイルを調べて問題の特定を試みてください。詳細は、第G.2.4項「Fusion Middleware ControlのLog Viewerの使用」を参照してください。Log Viewerを使用していない場合は、次のディレクトリにある関連のエラー・ログ・ファイルを確認してください。
ORACLE_INSTANCE\diagnostics\logs\OHS\ohs1\access.log
OracleAS Single Sign-On DADの状態および構成を確認します。
OracleAS Single Sign-Onのホーム・ページで、次の手順を実行します。
OracleAS Single Sign-Onのホーム・ページの「関連リンク」セクションで、「HTTP_Server」をクリックします。
「管理」をクリックします。
「PL/SQLのプロパティ」をクリックして、「DAD」セクションを確認します。
状態が「稼働中」の場合は、次の手順に進みます。
状態が「停止中」の場合は、「DAD」表でDADの名前をクリックし、すべてのプロパティが正しく設定されていることを確認します。変更を保存し、Oracle HTTP ServerとWLS_PORTALを再起動して変更を有効にします。
ログインできるようになったかどうかを確認します。
OracleAS Single Sign-Onスキーマが含まれるデータベースが稼働しているかどうかを確認します。
データベース情報は、Oracle Enterprise Manager 11g Fusion Middleware ControlのOracleAS Single Sign-Onのホーム・ページに表示されます。さらに詳しい情報を表示するには、ドリルダウンします。
状態が「稼働中」の場合は、次の手順に進みます。
状態が「停止中」の場合は、データベースを起動します。
データベースが正常に起動した場合は、OracleAS Single Sign-Onスキーマにアクセスできるようになったかどうかを確認します。
SQL* Netリスナーの状態および構成を確認します。
ID管理リポジトリがインストールされているホストで、SQL*NET TNSリスナーが稼働中であるかどうかを確認します。データベースがあるコンピュータにログインします。現在のディレクトリが$PATHでない場合は、ORACLE_INSTANCE/binディレクトリに移動し、次のコマンドを使用して、TNSリスナーの状態を確認します。
lsnrctl status
サービスが稼働していない場合は、次のコマンドでサービスを起動します。
lsnrctl start
サービスが稼働している場合は、Oracle Database 11gドキュメント・ライブラリのOracle Database Net Services管理者ガイドを参照し、返されたエラー番号を確認して、適切な処置を取ります。
Oracle PortalとOracle Internet Directory間の通信の検証
Oracle Portalのログイン・プロセスの2つ目の部分では、OracleAS Single Sign-Onから提供された資格証明を使用して、Oracle PortalがOracle Internet Directoryからグループ・メンバーシップ情報を取得します。
ログイン・プロセスのこの部分で発生した問題の原因を診断するには、Metadata Repositoryのログを確認します。
ホーム・ページの割当ての検証
Oracle Portalのログイン・プロセスの最後の部分では、グループ・メンバーシップに基づいて、ユーザーが適切なOracle Portalのホーム・ページにリダイレクトされます。ホームページのプリファレンスは、システム、グループまたはユーザーのレベルで指定されます。
ユーザーにホーム・ページが指定されている場合は、ログイン時にそのホーム・ページが表示されます。ホーム・ページが指定されていない場合でも、ユーザーがデフォルト・グループに属していて、そのデフォルト・グループにホーム・ページが指定されていれば、そのホーム・ページが表示されます。ユーザーにホーム・ページが指定されておらず、ユーザーがデフォルト・グループに属していないか、またはデフォルト・グループにホーム・ページが指定されていない場合は、システム・レベルのデフォルトのホーム・ページが表示されます。
問題の原因を診断するには、ユーザー、グループまたはシステムのレベルで、ホームページの「表示」権限がユーザーに付与されているかどうかを確認します。
ホームページを表示するには、そのページを表示する権限が必要です。権限は次のいずれかに付与できます。
ユーザー
ユーザー・グループ
パブリック
これらのどのレベルにもページを表示する権限が付与されていない場合は、「WWC-44131: この操作を行う権限がありません。」というエラー・メッセージが表示されます。
グループまたはシステムのレベルで、ユーザーが属するグループにページを表示するための正しい権限が付与されているかどうかを管理者に確認します。
ポータル管理者は、次の手順を実行して、ユーザーのホーム・ページを指定する必要があります。
ユーザーのプロファイルを編集し、ユーザーのデフォルト・ホームページとデフォルト・グループを見つけます。
デフォルト・ホームページがユーザーにすでに指定されている場合は、ここで終了します。指定されていない場合は、デフォルト・グループのグループ・プロファイルを編集し、デフォルト・ホームページが指定されているかどうかを確認します。
デフォルト・ホームページがデフォルト・グループに指定されている場合は、ここで終了します。指定されていない場合は、「グローバル設定」ページからデフォルト・ホームページを確認します。
ホームページを確立したら、次に、そのページに付与されている権限を調べます。ページを編集して、「アクセス」をクリックします。パブリックでページが表示できるかどうかを確認します。さらに、権限受領者のリストを調べます。ユーザーまたはユーザーが属するグループに、そのページに対する「表示」またはそれ以上の権限が付与されているかどうかを確認します。必要に応じて、適切な権限を付与します。ユーザーがメンバーであるグループに権限が付与されている場合は、そのユーザーの名前がメンバー・リストに表示されていることを確認します。
カテゴリ・ページまたはパースペクティブ・ページの作成時に、次のエラーが発生する場合があります。
WWS-32022: 「カテゴリは作成されていますが、検索ポートレットをカテゴリ・ページに配置できませんでした。カテゴリ・ページには、このカテゴリのアイテムまたはページは表示されません。」
WWS-32023: 「パースペクティブは作成されていますが、検索ポートレットをパースペクティブ・ページに配置できませんでした。パースペクティブ・ページには、このパースペクティブのアイテムまたはページは表示されません。」
問題
ページ・グループにカテゴリを作成すると、カテゴリ・テンプレートに基づいてカテゴリ・ページが作成されます。同様に、パースペクティブを作成すると、パースぺクティブ・テンプレートに基づいてパースペクティブ・ページが作成されます。これらの基になるカテゴリまたはパースペクティブのテンプレートを変更した場合は、新しいカテゴリまたはパースペクティブを作成すると、前述のいずれかのメッセージが表示されることがあります。
解決策
これらのエラーのいずれかが表示された場合は、現在のカテゴリまたはパースペクティブのテンプレートを削除してから、スクリプトを実行して次の操作を行います。
現行のカテゴリまたはパースペクティブのテンプレートを元のバージョンに置き換えます。
現行のテンプレートに基づいたカテゴリ・ページまたはパースペクティブ・ページを再作成します。これは、すべてのページ・グループにも、特定のページ・グループにも実行できます。
これにより、すべての新しいカテゴリ・ページまたはパースペクティブ・ページがエラーなしで作成され、すべての既存のカテゴリ・ページまたはパースペクティブ・ページに、関連付けられたアイテムおよびページが予想どおりに表示されます。
これらのスクリプトの検索場所と実行方法の詳細は、第B.9項「カテゴリおよびパースペクティブ・スクリプトの使用」を参照してください。
第6.3項「ロード・バランス・ルーターを使用する複数の中間層の構成」の手順に従った後、次のエラーが発生します。
Timeout occurred while retrieving page metadata
問題
NATバウンスバック・ルールがLBRに対して正しく設定されていない場合、複数の中間層を構成する際に、ループバック・リクエストに対するレスポンスが削除され、Oracle Portalのページがタイムアウトになります。
解決策
NATバウンスバック・ルールは、LBRごとに異なる内容になります。詳細は、LBRの構成ガイドを参照してください。正常なループバック通信を実現するためにLBRに追加の構成が必要になる理由の詳細は、第6.3項「ロード・バランス・ルーターを使用する複数の中間層の構成」を参照してください。
Oracle Portalのユーザーおよびグループ情報が、Oracle Internet Directoryの情報と一致しません。
問題
Oracle Internet Directoryからの変更が、Oracle Portalに伝播されません。Oracle Portalでは、ユーザーまたはグループの権限情報が変更されたときに通知を受けるために、プロビジョニング・プロファイルを使用します。これにより、Oracle Portalの認可情報をOracle Internet Directoryに格納されている情報と一致させておくことが可能になります。デフォルトでは、このプロビジョニング・プロファイルは有効です。
解決策
次の手順を実行して、この問題の原因を診断します。
プロビジョニングが有効かどうかを確認します。
次の手順を実行して、プロビジョニングが有効かどうかを確認します。
Oracle Portalにログインします。「管理」タブをクリックします。「Portalビルダー」ページで、「サービス」の下の「グローバル設定」をクリックします。
「SSO/OID」タブをクリックして、「ディレクトリ同期」セクションまでスクロールします。このセクションで、ディレクトリ同期を有効にするかどうかを指定できます。「ディレクトリ同期の有効化」が選択され、デフォルトでイベント通知の送信頻度n秒が300秒に設定されている必要があります。
「ディレクトリ同期」セクションが表示されていない場合、または「ディレクトリ同期の有効化」のチェック・ボックスが選択されていない場合、プロビジョニング・プロファイルは有効になっていません。「ディレクトリ同期の有効化」チェック・ボックスを選択してから、「OK」または「適用」をクリックして、プロビジョニング・プロファイルを有効にします。
エラーが発生した場合は、次の例に示すように、oidprovtoolツールを使用してプロビジョニング・プロファイルを再作成する必要があります。
oidprovtool operation=create ldap_host=myhost.mycompany.com ldap_port=389 \ ldap_user_dn="cn=orcladmin" ldap_user_password=welcome1 application_dn="orclApplicationCommonName=PORTAL,cn=Portal,cn=Products,cn=OracleContext" \ organization_dn="dc=us,dc=mycompany,dc=com" interface_name=PORTAL.WWSEC_OID_SYNC \ interface_type=PLSQL interface_connect_info=myhost:1521:iasdb:PORTAL:password \ schedule=360 event_subscription="USER:dc=us,dc=mycompany,dc=com:DELETE" \ event_subscription="GROUP:dc=us,dc=mycompany,dc=com:DELETE" \ event_subscription="USER:dc=us,dc=mycompany,dc=com:MODIFY(orclDefaultProfileGroup,userpassword)" \ event_subscription="GROUP:dc=us,dc=mycompany,dc=com:MODIFY(uniqueMember)" \ profile_mode=OUTBOUND
Oracle Directory Integration Platformが起動され、稼働しているかどうかを確認します。
これを行うには、次の手順を実行します。
Oracle Enterprise Manager 11g Fusion Middleware Controlを表示します。詳細は、第8.1項「Oracle Enterprise Manager 11g Fusion Middleware Controlの使用」を参照してください。ポータルに関連付けられたInfrastructureホーム・ディレクトリのOracle Fusion Middleware Controlに移動します。
Oracle Internet Directoryの状態は、Fusion Middlewareのページに表示されます。
状態が「稼働中」の場合は、次の手順に進みます。
状態が「停止中」の場合は、Fusion Middleware Controlを使用してOracle Internet Directoryを起動します。
Oracle Fusion Middleware ControlでOracle Internet Directoryの監視および管理のページにアクセスするには、Fusion Middlewareの「システム・コンポーネント」表の「OID」をクリックします。
Oracle Internet Directoryが正常に起動した場合は、次の手順に進みます。
Oracle Internet Directoryを起動できない場合は、Oracle Internet Directoryのエラー・ログ・ファイルを調べて問題の特定を試みてください。詳細は、第G.2.4項「Fusion Middleware ControlのLog Viewerの使用」を参照してください。
Oracle Directory Integration Platformが稼働中であるかどうかを確認します。
Fusion Middlewareの「システム・コンポーネント」表の「OID」をクリックします。その次のページで、「ステータス」セクションの「ディレクトリ統合」をクリックします。
状態が「稼働中」の場合は、次の手順に進みます。
状態が「停止中」の場合は、Oracle Enterprise Manager 11gのFusion Middleware Controlを使用してOracle Directory Integration Platformサーバーを起動します。
|
関連項目:
|
トレース・ログ・ファイルと監査ログ・ファイルの内容を確認します。
変更が伝播されると、結果がトレース・ファイルと監査ファイルに書き込まれます。これらのファイルの内容を確認することで、伝播の失敗についての追加情報が得られます。次の手順を実行して、これらのファイルの内容を確認します。
Oracle Directory Integration Platformサーバーが稼働しているコンピュータにログインします。
通常、Oracle Internet DirectoryがインストールされているコンピュータにはOracle Directory Integration Platformサーバーがあります。
トレース・ログ・ファイルと監査ログ・ファイルを調べます。
ORACLE_INSTANCE/ldap/odi/log/ディレクトリに移動します。
各プロビジョニング・プロファイルには、ログ・ディレクトリの*.trc(トレース)ログ・ファイルと*.aud(監査)ログ・ファイルの2つの関連ファイルがあります。
デフォルトでは、トレース・ログ・ファイルには300秒ごとに生成されたエントリが保存されます。これは、イベント通知の送信頻度n秒のデフォルト値が300に設定されているためです。このファイルには、Oracle Directory Integration Platformで記録された最新情報のログのほかに、発生したエラーもすべて保存されます。トレース・ログ・ファイルは、一定時間が経過すると再利用されます。
監査ログ・ファイルには、プロビジョニング・プロファイルに伝播されたすべての変更の履歴が含まれています。監査ログ・ファイルに記録されるメッセージの例を次に示します。
Tue Jun 19 17:07:30 GMT 2004 - Audit Log Start ----------------------------------------------------- Group Exists Check - DN : cn=super_users,cn=ASDB.COMPANY.US.COM,cn=Database Instances,cn=SES,cn=Portal,cn=Products,cn=OracleContext,dc=us,dc=co mpany,dc=com ,GUID (CE0D473B93B521FAE0340003BA109AC2) - Response : =============Event ID : 2320 - (GROUP_MODIFY)============= Source : orclapplicationcommonname= ASDB.COMPANY.COM,cn=database instances,cn=ses,cn=portal,cn=products,cn=oraclecontext Time : 20031209170036z Object Name: super_users Object GUID: CE0D473B93B521FAE0340003BA109AC2 Object DN : cn=super_users,cn= ASDB.COMPANY.COM,cn=Database Instances,cn=ses,cn=Portal,cn=Products,cn=OracleContext,dc=us,dc=co mpany,dc=com AttrName - OpType - Value ------------------------------------------- uniquemember - ADD - cn=portal,cn=users,dc=us,dc=company,dc=com EVENT_NTFY Response : 1 2320 : Success : 2 : cn=super_users,cn= ASDB.COMPANY.COM,cn=Database Instances,cn=ses,cn=Portal,cn=Products,cn=OracleContext,dc=us,dc=co mpany,dc=com -----------------------------------------------------
伝播情報はトレース・ログ・ファイルに書き込まれ、定期的に監査ログ・ファイルに追加されます。変更が正しく伝播されると、トレース・ログ・ファイル内のタイム・スタンプが更新されます。
変更が正しく伝播されているのに、Oracle Portalに反映されていない場合は、「変更が正しく伝播されているか」に進んでください。
トレース・ログ・ファイルと監査ログ・ファイルが見つからない場合は、次の手順を実行して、プロビジョニング・プロファイルが存在するかどうかを確認します。
Oracle Portalにログインします。「管理」タブをクリックします。「Portalビルダー」ページで、「サービス」の下の「グローバル設定」をクリックします。
「SSO/OID」タブをクリックして、「ディレクトリ同期」セクションまでスクロールします。このセクションで、ディレクトリ同期を有効にするかどうかを指定できます。「ディレクトリ同期の有効化」が選択され、イベント通知の送信頻度n秒がデフォルトで300秒に設定されている必要があります。
これらの値が設定されていない場合は、次の項で説明するように、プロビジョニング・プロファイルを作成する必要があります。
ORACLE_INSTANCE/ldap/odi/log/ディレクトリでトレース・ログ・ファイルと監査ログ・ファイルが見つからない場合は、プロビジョニング・プロファイルが削除された可能性があります。プロビジョニング・プロファイルを再作成するには、oidprovtoolツールを次のように実行します。
ldap_user_dn="cn=orcladmin" ldap_user_password=welcome1 application_dn="orclApplicationCommonName=PORTAL,cn=Portal,cn=Products,cn=OracleContext" \ organization_dn="dc=us,dc=mycompany,dc=com" interface_name=PORTAL.WWSEC_OID_SYNC \ interface_type=PLSQL interface_connect_info=myhost:1521:iasdb:PORTAL:password \ schedule=360 event_subscription="USER:dc=us,dc=mycompany,dc=com:DELETE" \ event_subscription="GROUP:dc=us,dc=mycompany,dc=com:DELETE" \ event_subscription="USER:dc=us,dc=mycompany,dc=com:MODIFY(orclDefaultProfileGroup,userpassword)" \ event_subscription="GROUP:dc=us,dc=mycompany,dc=com:MODIFY(uniqueMember)" \ profile_mode=OUTBOUND
変更が正しく伝播されているか
変更が正しく伝播されるかどうかを診断するには、Oracle Internet DirectoryでOracle Portalを使用して、ユーザーの作成、削除、再作成を順に実行します。これを行うには、次の手順を実行します。
「管理」タブをクリックします。
「ユーザー」から「新規ユーザーの作成」をクリックします。
ユーザーのプロファイルを編集します。
ユーザーを削除します。
同じ名前でユーザーを再作成します。
間隔(メッセージの「イベント通知の送信頻度」に指定した時間)の間待機します。待機時間を最小にするには、この値を300秒未満に再設定します。その後、新規作成したユーザーとしてログインします。ログイン時に次のエラーが表示された場合は、Oracle Internet DirectoryからOracle Portalに情報が伝播されていません。
エラーWWC-41742: 「割り当てたユーザー名に競合が発生しました。異なるグローバル一意識別子を持つ、この名前のユーザー・エントリが存在します。この名前でログオンする前に解決する必要があります。管理者に連絡してください。」
情報が伝播されない場合、Oracle Portalでは、同じユーザー名が異なるGUIDで格納されているため、このエラーがスローされます。
変更が正しく伝播されない場合は、Oracle Directory Integration Platformに問題があるか、またはOracle Directory Integration PlatformによるOracle Portalの構成に問題があると思われます。Oracle Portal構成の問題である場合は、ptlconfigツールを次のように実行します。
ptlconfig -dad <dad> -dipreg
Oracle Portalでは、ページのロードが遅いなど、パフォーマンスの問題が発生する場合があります。
ポータルが遅くなるには、いくつかの理由が考えられます。これらの問題の一部をここで説明します。
問題1
キャッシュができません。
解決策1
Oracle Fusion Middleware Controlを使用して、第5.6.6項「Fusion Middleware Controlを使用したポータル・キャッシュの構成」で説明しているように、Portalの「キャッシング」オプションが「オン」に設定されていることを確認します。
問題2
ページ・メタデータがOracle Web Cacheにキャッシュされません。Oracle Portalのバージョンを確認するために中間層からOracle Portalスキーマに行われた最初の一度かぎりのコールが失敗した可能性があります。
解決策2
この問題を解決するには、次のタスクを実行します。
ページ・メタデータがOracle Web Cacheにキャッシュされていないことを確認します。これを行うには、次の手順を実行します。
ページのURLの末尾に&_debug=1を追加してブラウザを更新し、Oracle Web Cacheページ・メタデータのキャッシュの状態がMISS, NON-CACHEABLEになっているかどうかを確認します。
すべてのWLS_PORTALインスタンスを再起動します。
ステップ1を再び実行し、ページ・メタデータがOracle Web Cacheにキャッシュされるようになったかどうかを確認します。
問題3
接続プールの再利用が少ないかまったくありません。
解決策3
Fusion Middleware ControlのMBeanブラウザを使用して、MaxRequestsPerSessionパラメータを1000に設定します。
|
注意: MaxRequestsPerSession属性が1に設定されていないことを確認してください。設定されていると、接続プーリングが無効になります。MaxRequestsPerSession属性の詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』を参照してください。 |
MaxRequestsPerSession属性を変更するには、次の手順を実行します。
適切なファームのFusion Middleware Controlインスタンスに移動します。
詳細は、第8.1項「Oracle Enterprise Manager 11g Fusion Middleware Controlの使用」を参照してください。
「ファーム」メニューから、「管理」→「システムMBeanブラウザ」を選択します。
検索機能を使用してMBeanの属性PlsqlMaxRequestsPerSessionを検索するか、またはナビゲーション・ペインを使用して「MBean」→「oracle.mas.config」→「PortalConfig」→「pls/portal」を開きます。
「属性」タブで、PlsqlMaxRequestsPerSession属性までスクロールしてクリックします。
属性値を「1000」にリセットし、「OK」をクリックします。
Oracle HTTP ServerとWLS_PORTALを再起動します。
Oracle HTTP ServerとWLS_PORTALのコンポーネントの再起動の詳細は、第5.6.3項「Fusion Middleware Controlを使用したポータル・コンポーネントの停止および起動」を参照してください。
問題4
サイトが応答していません。
解決策4
WebCacheおよびOHSのログの診断メッセージを確認して、これらのOracleコンポーネントを調整する必要がないかどうかを調べます。
Oracle Fusion Middleware ControlのMBeanブラウザ属性を変更するには、次の手順を実行します。
適切なファームのFusion Middleware Controlインスタンスに移動します。
詳細は、第8.1項「Oracle Enterprise Manager 11g Fusion Middleware Controlの使用」を参照してください。
「ファーム」メニューから、「管理」→「システムMBeanブラウザ」を選択します。
検索機能を使用してMBeanの属性を検索するか、またはナビゲーション・ペインを使用して「MBean」→「oracle.mas.config」→「PortalConfig」→「グローバル」を開きます。
「属性」タブで、当該の属性までスクロールしてクリックします。
属性値をリセットし、「OK」をクリックします。
Oracle HTTP ServerとWLS_PORTALを再起動します。
Oracle HTTP ServerとWLS_PORTALのコンポーネントの再起動の詳細は、第5.6.3項「Fusion Middleware Controlを使用したポータル・コンポーネントの停止および起動」を参照してください。
問題6
ディスクの入出力が分散されません。
解決策6
次のような多くのコンポーネントが常にディスクにアクセスしています。
Oracle HTTP Serverのアクセス・ログおよびエラー・ログ
Portalのキャッシュされたコンテンツ
Webコンテンツ・サービス
その他のローカル・アプリケーション
これらのコンポーネントはすべて、ファイル・システムのリソースを確保するために競合します。入力または出力のボトルネックを減らすには、物理ディスク間で分散処理が確実に行われるようにします。
問題7
ネットワーク・ホップが多すぎます。通常、次のいずれかの問題が発生します。
クラスタ化されたOracle HTTP Server環境で、PPEループバックが構成されません。
サーブレット・エンジンが、Oracle HTTP Serverでもmod_weblogicでもないコンピュータで稼働します。
Infrastructureのコンポーネントが、複数のルーターがある広いネットワーク間で稼働しています。
解決策7
前述の問題について回避または対処することにより、ネットワーク・ホップ数を減らすようにします。
問題8
コンテンツの提供にHTTPSプロトコルを使用します。
保護が不要な普通のコンテンツにHTTPSを使用するようにポータルを構成している可能性があります。
解決策8
HTTPSの不要な使用を避けます。ほとんどの場合、HTTPで十分です。セキュアな環境が実際に必要な場合は、HTTPSとSSL(Secure Socket Layer)を管理するリバース・プロキシ・ハードウェアを使用します。詳細は、第6.6項「リバース・プロキシ・サーバーを使用するためのOracle Portalの構成」を参照してください。
問題9
提示された解決策の作業をすべて実行したにもかかわらず、Oracle Portalの速度が遅いままです。
解決策9
Oracle Portal、Oracle Portalのホストおよび関連コンポーネントのメトリック情報を確認します。
Oracle Portalに必要なすべてのコンポーネントが予想どおりに稼働している場合は、次の手順としてOracle Fusion Middleware Controlでメトリック情報を確認します。この情報を確認することにより、問題を特定できる場合があります。
ポータルのホーム・ページの「すべてのメトリック」をクリックし、メトリック情報を確認します。他の関連コンポーネント(Oracle Web Cache、Oracle HTTP Serverなど)のホーム・ページ上で、これを繰り返します。
Oracle Portal Diagnostics Assistantを実行します。
Oracle Portal Diagnostics Assistantを使用して生成されたレポートを調べると、ポータル関連の問題を診断できます。詳細は、第G.2.5項「Oracle Portal Diagnostics Assistantの使用」を参照してください。
|
関連項目:
|
|
注意: パフォーマンス監視スクリプトのzipファイルは、Oracle Fusion Middlewareのインストールの一部としても入手できます。 |
Oracle PortalでWebフォルダを作成しようとすると、Webサーバーのエラー・ログ・ファイルにORA-20504エラーが生成されます。
問題
wwdav$path表とwwdav$asl表が壊れています。
解決策
表に値を再び移入するには、DAVローダー(wwdav_loader)・ユーティリティを実行する必要があります。SQL*Plusから次のプロシージャを実行することで、DAVローダー・ユーティリティを実行できます。
set serveroutput on size 1000000
begin
wwdav_loader.create_dav_content;
end;
これによりすべてのDAVデータが再作成されます。さらに多くのデバッグ情報を取得するには、次のプロシージャも使用できます。
set serveroutput on size 1000000
begin
wwdav_loader.create_dav_content(
p_debug_mode => true);
end;
DAVローダーの実行により、DAV表から一時ドキュメントと、ドキュメントに対するロックが削除されます。承認のために送信されたアイテムは、受け入れられるか拒否されるまで、DAVローダーには表示されなくなります。
今後、DAVスキーマにデータの破損があるかどうかを調べるには、DAV Reportユーティリティを使用できます。このユーティリティを使用するには、次の手順を実行します。
ディレクトリをORACLE_HOME//portal/admin/plsql/wwu/に変更します。ここにdavreprt.sqlファイルがあります。
PORTALスキーマ・ユーザーとしてSQL*Plusにログインします。
DAV Reportユーティリティを次のように実行します。
davreprt.sql
これにより、一連のテストが実行されます。すべてのテストに合格すると、DAVスキーマには既知のデータの破損が見つからなかったことになります。いずれかのテストに失敗した場合は、DAVローダーを実行して、データの破損を修正する必要があります。
「新規ユーザーの作成」ポートレットと「新規グループの作成」ポートレットは、ユーザー権限に基づいて表示されます。ポートレットは、様々な理由から表示されないことが考えられます。
問題1
十分な権限がありません。
解決策1
Delegated Administration Servicesセルフサービス・コンソールを使用して、ユーザーおよびグループを管理できるかどうかを確認します。必要な権限を持っていない場合は、必要な権限を付与するように管理者に要求します。しかし、セルフサービス・コンソールからこれらの操作を正常に実行できた場合は、次の2つの問題に関連している可能性があります。問題について管理者に通知してください。
問題2
Oracle Internet Directoryが停止中か、Oracle Internet Directoryのグループ情報が間違っています。
解決策2
Oracle Internet Directoryのグループ・メンバーシップ情報が間違っているか、Oracle Internet Directoryが起動されず、稼働中でない場合は、次の手順を実行して、この問題の原因を診断します。
Oracle Enterprise Manager 11gのFusion Middleware Controlで、ポータルのホーム・ページを表示します。詳細は、第8.1項「Oracle Enterprise Manager 11g Fusion Middleware Controlの使用」を参照してください。ポータルに関連付けられたInfrastructureホーム・ディレクトリのOracle Fusion Middleware Controlコンソールに移動します。
Oracle Internet Directoryが稼働中であるかどうかを確認します。Oracle Internet Directoryの状態は、「Fusion Middleware」ページに表示されます。
状態が「稼働中」の場合は、次の手順に進みます。
状態が「停止中」の場合は、Oracle Fusion Middleware Controlコンソールまたはコマンドラインを使用してOracle Internet Directoryを起動します。
Oracle Fusion Middleware ControlコンソールでOracle Internet Directoryの監視および管理のページにアクセスするには、Fusion Middlewareの「システム・コンポーネント」表の「Oracle Internet Directory」をクリックします。
Oracle Internet Directoryが正常に起動した場合、「新規ユーザーの作成」ポートレットと「新規グループの作成」ポートレットが表示されるかどうかを確認します。
Oracle Internet Directoryを起動できない場合は、Oracle Internet Directoryのエラー・ログ・ファイルを調べて問題の特定を試みてください。詳細は、第G.2.4項「Fusion Middleware ControlのLog Viewerの使用」を参照してください。
問題3
Oracle PortalとOracle Internet Directoryの接続構成が間違っています。
解決策3
Enterprise Managerにログインして、「ポータル・ワイヤ構成」ページで正しいOIDパラメータが入力されていることを確認します。
Oracle Portalへのログインを試みると、ORACLE_INSTANCE/diagnostics/logs/OHSComponent/ohs1ディレクトリにある診断ログ・ファイルに、次のいずれかのエラーが生成されます。
ORA-20000: 「有効なセッションを介さずにセッション・コンテキストにアクセスしようとしました。」
このエラーは、そのブラウザ・セッションに関連付けられたOracle Portalセッションが中断または消去されたか、またはセッションCookieそのものが見つからないことを示します。
ORA-20001: 「セッションCookieが破損しているため、セッション情報を取得できません。ブラウザを閉じてから再接続してください。」
このエラーは、セッションCookieが壊れているか、無効であることを示します。
ORA-20005: 「セッションに非アクティブのマークが付けられているため、セッション・コンテキストを復元できませんでした。」
このエラーは、セッションCookieが非アクティブなセッションを指定している場合に発生します。ブラウザから送られたCookieは、セッションに格納されているCookieと一致しますが、セッションはアクティブではありません。
ORA-20006: 「Cookieの値がセッション・リポジトリに格納されている値と一致しないため、セッション・コンテキストを復元できませんでした。」
このエラーは、ブラウザから送られたCookieと、セッションに格納されているCookieの間に不一致があることを示します。
|
注意: これらのエラーのいくつかが発生するものと理解しておいてください。発生する例外が異常な数にのぼる場合のみ、オラクル社カスタマ・サポート・センターに問題を報告してください。詳細は、第G.3項「さらにサポートが必要な場合」を参照してください。 |
これらのエラーの詳細は、次の各項で説明します。
ORA-20000「有効なセッションを介さずにセッション・コンテキストにアクセスしようとしました。」
このエラーは、次のいずれかの問題によって発生します。
セッション行がない
各セッションCookieには、対応するセッションがあります。セッションを格納しているポータル・スキーマには、セッションに対応するセッションCookieの情報が含まれています。セッションには、セッションID、ユーザー名、セッション開始時刻、ユーザーがログインしているかどうか、ユーザーのログイン時刻、セッションがアクティブか消去用としてマークされているかどうか、などのデータが格納されています。ORA-20000エラーは、Cookieで指定されたセッションIDが、Oracle Metadata Repositoryのポータル・スキーマに格納されているセッションに存在しない場合に発生します。
セッションが消去される
Oracle Metadata Repositoryのポータル・スキーマから古いセッションを消去するために、バックグラウンド・ジョブが頻繁に実行されます。デフォルトでは、8日以上経過したセッションを消去するようにこのジョブが構成されています。バックグラウンド・ジョブにより消去されたセッションにアクセスしようとすると、ORA-20000エラーが発生します。詳細は、第B.5項「セッション・クリーン・アップ・ジョブの管理」を参照してください。
セッションCookieがない
Oracle Metadata Repositoryのポータル・スキーマで使用するために構成されたDADが複数あり、それらのDADで指定されたCookie名が同じでない場合、その名前はwwctx_cookie_info$表のcookie_name値になり、DADの1つを介して新規セッション作成のリクエストが受信されるたびに値が変わります。その結果、ORA-20000エラーが発生します。
ORA-20001: 「セッションCookieが破損しているため、セッション情報を取得できません。ブラウザを閉じてから再接続してください。」
ORA-20001エラーは、次のいずれかの問題によって発生します。
Cookieが切り捨てられる
リクエストの送信中にブラウザの「停止」ボタンをクリックすると、Cookieが切り捨てられる場合があります。次回ブラウザにアクセスしたときに、サーバーはそのCookieの暗号を正しく解読できません。
別のサーバーからのCookieが受信された
ドメイン全体のCookie範囲で構成された別のOracle Portalに最近アクセスした場合、ORA-20001エラーが発生する可能性があります。そのポータルのCookie名が、現在のポータルのCookie名と同じ場合、Oracle PortalはそのCookieを使用しようとします。しかし、ポータルのCookieはポータル固有のキーで暗号化されているため、Oracle PortalはそのCookieの暗号を解読できず、Cookieが壊れているとみなして、ORA-20001エラーを生成します。
このネームスペースの衝突の問題を回避するには、これらのCookieの取得先を特定する必要があります。ブラウザを閉じると、セッションCookieがすべて消去されます。Cookieの取得先を確認するために、Cookieの警告を有効にしてブラウザを起動することにより、問題をデバッグできます。
Cookieの暗号化キーが変更される
Cookieは、DES3暗号化を使用して暗号化されます。暗号化キーは、Oracle Metadata Repositoryのポータル・スキーマに格納されます。その値は通常Oracle Portalのインストール時に設定され、その後変わりません。この値がインストール後に変更されると、未処理のセッションCookieは暗号を解読できなくなります。また、このキーで暗号化されたその他の値も解読できません。この値は変更しないように注意してください。
ORA-20005「セッションに非アクティブのマークが付けられているため、セッション・コンテキストを復元できませんでした。」
ORA-20005エラーは、セッションCookieで非アクティブなセッションを指している場合に発生します。ブラウザから送信されたCookieはセッションで保存されたCookieと一致していますが、そのセッションがアクティブではありません。これは、ログアウト・リクエストを発行していても、ブラウザでCookieがリセットされる前に別のリクエストが送信されたことを示しています(たとえば、他のユーザーが言語ポートレットから言語を変更するリクエストを送信した場合など)。
セッションが非アクティブとしてマークされている
ユーザーがログアウトする際、ポータル・スキーマに格納されているセッションが非アクティブの状態に更新される可能性があります。しかし、ブラウザの「停止」ボタンをクリックしても、そのCookieがユーザーのブラウザから消去されません。この状態になると、ブラウザから古いCookieが送信されるため、Oracle Portalは非アクティブなセッションを探そうとします。このような場合にORA-20000エラーが発生します。
ORA-20006「Cookieの値がセッション・リポジトリに格納されている値と一致しないため、セッション・コンテキストを復元できませんでした。」
ORA-20006エラーは、ブラウザから送られたCookieとセッションに格納されているCookieに不一致があることを示しています。これは、Cookieがあるリクエストに基づいて変更されたにもかかわらず、ブラウザでCookieが実際に更新される前に、ユーザーが別のリクエストを送信したときに発生する可能性があります。たとえば、ユーザーが言語ポートレットから言語を変更するリクエストを作成したのに、最初のリクエストが完了する前に別のリクエストを送信した場合などです。これはORA-20005エラーと似ていますが、Cookie自体にクライアントとサーバー間の不一致が含まれている点が異なります。
タイム・スタンプが一致しない
Cookieの暗号が正しく解読されても、Cookie内のタイム・スタンプが関連セッション行内のタイム・スタンプと一致しない場合、Cookieは壊れているとみなされます。タイム・スタンプのこの不一致は、ユーザーが2回ログインを起動した場合、ネットワーク構成の問題またはセッション作成ロジックの不具合がある場合、あるいは悪質なセッション攻撃を受けた場合に発生する可能性があります。
Oracle Portalの中間層とは異なるコンピュータにあるリモートWebプロバイダは、WLS_PORTALサービスが最初に起動されたときに稼働しますが、しばらくすると停止します。長いタイムアウト時間が経過した後、同じプロバイダからの各ポートレットのかわりに「エラー: ポートレットに接続できませんでした。」というメッセージが表示されます。ポートレットのタイムアウト時間のエラーは、WLS_PORTAL WLS_PORTAL-diagnostic.logファイルにも書き込まれます。WLS_PORTALを再起動すると、Webプロバイダは再び稼働しますが、限られた時間のみ稼働します。
問題
Webプロバイダがドメイン名からIPアドレスへのマッピングに動的DNS(DDNS)を使用していることがこの問題の原因である可能性があります。DDNSでは、Webプロバイダのドメイン名が、時間によって異なるIPアドレスに解決されています。一方、Javaのデフォルトのキャッシュ・ポリシーでは、解決済のIPアドレスはそのまま永続的にキャッシュされたままとなります。つまり、DDNSを使用しているために、WebプロバイダのIPアドレスが変更された場合でも、Javaのキャッシュには古いIPアドレスが保持されています。
解決策
この問題を解決するには、リモートWebプロバイダのタイムアウトを防止する構成をWLS_PORTALで別途設定します。WLS_PORTALのsun.net.inetaddr.ttlシステム・プロパティを変更する必要があります。JDK 1.3以降では、sun.net.inetaddr.ttlシステム・プロパティを使用して、キャッシュされたIPアドレスに対する存続時間(TTL)を秒単位で指定できます。
例
次のようにopmn.xmlファイルを編集します。
<java-option value="-server -Xincgc -Xnoclassgc -Xms256m -Xmx512m -Dsun.net.inetaddr.ttl=120"/>
opmnとそのすべてのサブプロセスを停止し、最新の構成の変更が有効になるように再起動します。
これを行うには、次のコマンドを実行します。
ORACLE_INSTANCE/opmn/bin/opmnctl stopall ORACLE_INSTANCE/opmn/bin/opmnctl startall
「ORA-04031: 共有メモリーの30192バイトを割当てできません」というエラーが表示されます。
問題
デフォルトでは、Oracle Fusion Middlewareのshared_pool_sizeの値は32MBです。次のようなメモリーの使用量が多い操作を実行する場合は、これが問題になることがあります。
エクスポートまたはインポート
Portalのフォームまたはレポートの作成
解決策
メモリーの使用量が多い操作を問題なく実行できるようにするには、shared_pool_sizeパラメータの値を大きくする必要があります。
データベース初期化パラメータの更新に関する手順が不明な場合は、Oracle Database 11gドキュメント・ライブラリのOracle Database管理者ガイドで、サーバー・パラメータ・ファイルを使用した初期化パラメータの管理に関する項を参照してください。
|
注意: オプションの手順として、Oracle Portal Diagnostics Assistantを実行して、データベースの既存の値と推奨値のレポートを表示することをお薦めします。詳細は、「Oracle Portal Diagnostics Assistantの実行」を参照してください。 |
Oracle Textの索引を作成しようとすると、次のエラーが発生する場合があります。
CTXAPPロールをポータルに付与できません
エラー: CTXSYSでのデータ・ストア・プロシージャの作成
エラー: Oracle Textデータ・ストアの設定
予期しないエラーが発生しました。(WWS-32100)
問題
Oracle Textの索引を作成しようとすると、問題が発生します。
解決策
Oracle Textは、ポータル・スキーマと同じOracle Databaseのホーム・ディレクトリにインストールする必要があります。詳細は、第9.3.2項「Oracle Textの前提条件」を参照してください。
この問題を解決するには、次のいずれかのオプションを選択してください。
データベースにアクセスし、Oracle Portalスキーマの所有者としてログインします。SQL*Plusを起動し、inctxgrn.sqlスクリプトを実行します。このスクリプトは、ORACLE_HOME\portal\admin\plsql\wwsディレクトリにあります。このスクリプトを実行すると、Oracle Textデータ・ストア・プロシージャが作成され、さらに、Oracle PortalスキーマにCTXAPPロールが付与されます。
データベースへのアクセス権はあっても、inctxgrn.sqlスクリプトのコピーがない場合は、SQL*Plusを使用してスキーマ所有者としてデータベースに接続し、次のコマンドを実行します。
set serveroutput on size 10000 begin wwv_context_util.grantCtxRole(user); end; @@sbrimtlx
(user)を、Oracle Portalスキーマの所有者(portalなど)に置き換えます。
Oracle Portalで、オンライン・ヘルプの一部しか翻訳されていないように見えます。
問題
Oracle Portalでは、オンライン・ヘルプで複数言語を使用できます。しかし、状況依存ヘルプのトピックの一部しか、日本語以外の言語に翻訳されていません。
解決策
これは予想される動作です。
スタイルシートを編集したのに、ポータル・ページのコンテキストでスタイルシートをプレビューまたは表示すると、古いスタイルシートのデータが表示されます。
問題
スタイルシートに行った変更がポータル・ページに反映されていません。これは、Last-Modifiedヘッダーを生成する数値に、グリニッジ標準時(GMT)がタイムゾーンを調整しないまま付加されるためです。オリジナル・サーバーのタイムゾーンがGMTよりも先行している場合、生成されるLast-Modifiedヘッダーは、実際には将来の日付になります。
解決策
次のエラーが発生した場合は、『Oracle Application Server Portalエラー・メッセージ・ガイド』に説明されている診断手順を実行します。
WWC-40018: General invalidation message processing exception: %1 WWC-40019: Could not open web cache connection
これらの手順で問題が解決しない場合は、Oracle Web Cacheホストとデータベース・ホストで、日付、時刻およびタイムゾーンが現在の値に設定されていることを確認します。また、データベースのタイムゾーンが、データベース・ホストのタイムゾーンと一致する設定になっていることを確認します。データベースのタイムゾーンは、次の問合せを実行することで判別できます。
SQL> SELECT DBTIMEZONE FROM DUAL;
データベースのタイムゾーンがデータベース・ホストのタイムゾーンと異なる場合は、ALTER DATABASE SET TIME_ZONEコマンドを使用してデータベースのタイムゾーンをデータベース・ホストのタイムゾーンに設定し、データベースを再起動します。
たとえば、次のようになります。
SQL> ALTER DATABASE SET TIME_ZONE = '-05:00';
変更された設定は、データベースを再起動するまで有効になりません。
ポータル・ページのコンテンツが更新されず、古いコンテンツが表示されます。
問題
ブラウザのキャッシュの設定が間違っている可能性があります。
解決策
ブラウザのキャッシュの設定が「なし」に設定されていないことを確認します。
この設定を確認するには、『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』の「はじめに」でブラウザの推奨事項に関する項を参照してください。
Oracle Portalの使用時に、次のような問題が発生する場合があります。
イメージが表示されません。
ポータルをログアウトした後、ブラウザを再起動しないとログインできません。
問題
解決策
イメージが自動的にロードされることを確認します。この設定を確認するには、『Oracle Fusion Middleware Oracle Portalユーザーズ・ガイド』の「はじめに」でブラウザの推奨事項に関する項を参照してください。
|
注意: この設定は常に有効にすることをお薦めします。 |
Oracle Portalのアクセス時または使用時に、ハンドルされていない例外が発生する場合があります。たとえば、「エラー30526: ハンドルされていない例外が発生」などが発生します。
問題
Oracle Portalで、リカバリ不能なデータベース・エラーが発生します。
解決策
ハンドルされていない例外エラーの場合、エラーの実際の原因は不明です。考えられるエラーの原因について、より多くの情報を集めるには、トレース・ファイルを生成します。
トレースを有効にすると、トレース・ファイルはデータベース・パラメータuser_dump_destに指定されているディレクトリに生成されます。このディレクトリの名前を検索するには、次のいずれかのコマンドを使用します。
select value from v$parameter where name = 'user_dump_dest'; show parameter user_dump_dest;
トレース・ファイルを生成する手順については、第G.2.2項「トレース・ファイルの生成」を参照してください。これらのトレース・ファイルはフォーマットされません。フォーマットするには、tkprofユーティリティを使用します。
ポートレットを構築するためにOmniPortletプロバイダを構成すると、いくつかの問題が発生する場合があります。これらの問題の多くを解決するには、OmniPortletプロバイダのアプリケーション・ログ・ファイルWLS_Portal.logを確認する必要があります。このログ・ファイルは次の場所にあります。
DOMAIN_HOME\servers\WLS_PORTAL\logs
問題
必要なSSLライブラリがライブラリ・パスにありません。
OracleAS PDKがPortalインスタンスにインストールされている場合、次のエラーが発生する場合があります。
"java.lang.NoClassDefFoundError: at oracle.security.ssl.OracleSSLCipherSuite.isSSLLibDomestic when accessing HTTPS site with certificate"
解決策
SSLライブラリがライブラリ・パスにあることを確認します。詳細は、「HTTPSアクセス用のライブラリのコピー(PDK専用)」を参照してください。
ポータル・ページに古いポートレットの内容が表示され、ポートレット定義が反映されません。この問題は、Oracle Web Cache構成時の次のエラーによって発生する場合があります。
問題1
ポートの値がcache.xmlファイルに正しく指定されていません。次のエラーが発生する場合があります。
CONFIGURATION: Encountered a Cache Invalidation Exception. oracle.net.http.HttpConfigurationException: Bad "port" value in configuration element "invalidation"
解決策1
正しいポート番号をcache.xmlファイルに設定します。
cache.xmlファイルのテンプレートのコピーは、ORACLE_INSTANCE/portal/conf ディレクトリにあります。ポートを指定するには、この構成ファイルを、次の例のイタリック体の部分が示すように変更してください。
<?xml version="1.0"?>
<webcache>
<invalidation
host="cache.us.oracle.com"
port="4001"
authorization="0510198d5df8efd5779406342be2528aa0cccb179ea6b77baf49f019f5075a3a11"/>
</webcache>
問題2
cache.xmlファイルで認証値が暗号化されていません。次のエラーが発生する場合があります。
CONFIGURATION: Encountered a Cache Invalidation Exception. oracle.net.http.HttpConfigurationException: Bad "authorization" value in configuration element "invalidation." String un-obfuscation error
解決策2
Oracle Web Cacheインスタンスの情報は、ORACLE_INSTANCE/portal/confディレクトリのcache.xmlファイルに維持されます。Web Cacheの無効化の設定が変更された場合は、このファイルを更新する必要があります。詳細は、第E.2.1.3項「キャッシュの構成(PDK専用)」を参照してください。
問題3
oracle.http.configfileシステム・プロパティが定義されていません。つまり、Web Cacheの無効化に関して構成ファイルが定義されていません。WLS_Portalインスタンスを起動したときに、次のエラーが発生する場合があります。
Error: CONFIGURATION: Provider Test Page: Web Cache Invalidation config file not defined by "oracle.http.configfile"
標準のデスクトップ・ブラウザと比べて、モバイル・デバイスには、詳細なエラー情報を表示する適切なインタフェースがありません。そのため、多くのエラー情報は、Oracle Application Server Wirelessログ・ファイルに記録されます。このログ・ファイルには、Activity Loggerと呼ばれるWebベースの監視ツールを使用してアクセスできます。Activity Loggerの使用方法の詳細は、『Oracle Application Server Wireless管理者ガイド』を参照してください。
OracleAS Wireless経由でOracle Portalにアクセスすると、次のようなエラーが発生する場合があります。
サービス・エラー
一時エラー
サービス・エラー
サービス・エラーは、ワイヤレス・サーバーにバックエンド・サーバーへのアクセスの問題がある場合に、OracleAS Wirelessサーバーによって生成されます。サービス・エラーは次のように表示されます。
Service Error
サービス・エラーは、次のいずれかの理由により生成されます。
textまたはvnd.oracle.mobilexmlタイプではないドキュメントがOracleAS Wirelessサーバーに返されました。
textまたはvnd.oracle.mobilexmlタイプのドキュメントがOracleAS Wirelessサーバーに返されましたが、コンテンツが無効なXMLです。
textまたはvnd.oracle.mobilexmlタイプのドキュメントがOracleAS Wirelessサーバーに返されましたが、コンテンツが無効なOracleAS Wireless XMLです。
エラー・ステータスがOracleAS Wirelessサーバーに返されましたが、ユーザーに返すことができる添付ドキュメントがありません。
一時エラー
一時エラーは、モバイル・デバイスにエラー・ドキュメントのレンダリングの問題がある場合に、Parallel Page Engine(PPE)によって生成されるメッセージです。一時エラーは次のように表示されます。
A temporary error has prevented Oracle Portal from servicing your request. (id=<nnnnn>)
値<nnnn>は、ログのエラーIDです。
標準のデスクトップ・ブラウザでは、エラー・ドキュメントをレンダリングすると、データベースへのメタデータのコールによって生成されたエラー・ドキュメントが、PPEによって取得され、ユーザーに渡されます。モバイル・デバイスでは、モバイル・リクエストに対してレンダリングされるドキュメントはOracleAS Wireless XMLである必要があるため、これは実行できません。
PPEがモバイル・リクエストを処理している場合、データベースが無効なOracleAS Wireless XMLのエラー・ドキュメントをレンダリングすると、PPEは次のタスクを実行します。
このドキュメントをDOMAIN_HOME\servers\WLS_PORTAL\logsディレクトリにあるサーブレット・エラー・ログ・ファイルに書き込みます。
一意のIDをこのエラーに割り当てます。
標準のエラー・テンプレートを次のフォーマットでユーザーに渡します。
A temporary error has prevented Oracle Portal from servicing your request. (id=<nnnnn>)
<nnnn>は、ログのエラーIDです。
サービス・エラーと一時エラーの問題および回避策
サービス・エラーと一時エラーの様々な問題および回避策については、次の項で説明します。
|
注意: 推奨される回避策を実行したら、キャッシュをクリアし、ブラウザを再起動してください。エラー・ページがキャッシュされていると、バックエンド・サービスにアクセスしたときに再びサービス・エラーが発生する可能性があるため、これは必ず実行してください。 |
問題1
Oracle Application Serverが正しく構成されていません。サービス・エラーが検出されます。
解決策1
Oracle Application Serverで、Oracle PortalとOracleAS Wirelessの構成を確認します。これらの設定の確認方法の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
問題2
モバイル・デバイスまたはシミュレータからOracle Portalへのアクセスが認証されていません。これは、ログオン時のセッションCookieの妥当性チェックで、IPアドレスの照合が失敗したことが原因と考えられます。サービス・エラーが検出されます。
解決策2
Cookieの妥当性チェックにおけるIPチェックの状態を変更します。詳細は、第B.2項「セッションCookieの妥当性チェック時のIPチェックの構成」を参照してください。
モバイル・デバイスまたはシミュレータからOracle Portalへアクセスして、サービス・エラーが発生するかどうかを確認します。
問題3
xml.validation.modeパラメータがTrueに設定されています。このパラメータがTrueに設定されていると、OracleAS Wirelessは、無効なXMLフォーマットのエラー・メッセージ・ファイルの妥当性チェックを試みます。サービス・エラーが検出されます。
解決策3
OracleAS Wirelessインスタンスで、次の場所にあるweb.xmlファイルのxml.validation.modeパラメータがFalseに設定されていることを確認します。
ORACLE_HOME/j2ee/OC4J_Wireless/applications/wdk/wdk-web/WEB-INF
モバイル・デバイスまたはシミュレータからOracle Portalへアクセスして、サービス・エラーが発生するかどうかを確認します。
問題4
OracleAS Wirelessの動作が変更されています。サービス・エラーが検出されます。
解決策4
OracleAS Wirelessサーバーで、任意のサービスを実行できるかどうか確認します。たとえば、モバイル・デバイスまたはシミュレータから、OracleAS Wirelessのサンプルを実行できるかどうかを確認します。詳細は、『Oracle Application Server Wireless管理者ガイド』を参照してください。
サンプルのサービスが動作しない場合は、OracleAS Wirelessを再インストールして、構成しなおす必要があります。詳細は、OracleAS Wirelessのドキュメントを参照してください。
サンプルのサービスが正常に動作した場合は、OracleAS Wirelessサーバーのログ・ファイルでトラブルシューティング情報を調べます。ログ・ファイルには、問題の原因となっているポータル・サービスからのレスポンスに関する情報が格納されています。この情報を使用すれば、ポータルがエラー・ステータスまたは無効なOracleAS Wireless XMLを返していないかどうかを確認できます。
OracleAS Wireless Activity Loggerの下部にある「ログの表示」をクリックして、OracleAS Wirelessサーバー・ログ・ファイルにアクセスします。ログ・ファイルの最後の500行が表示されます。ワイヤレス・サーバーのログ・ファイルは、ORACLE_INSTANCE/wireless/logs/ directory or the /var/tmp/ディレクトリにあります。
ログ・ファイルの情報に基づいて、修正手順を実行するか、またはオラクル社カスタマ・サポート・センターに問い合せます。
|
注意: ログ・ファイルを表示するときは、表示行数を変更できますが、大きなログ・ファイルの情報を検索する場合は、オペレーティング・システムのvi、emacs、moreなどのコマンドを使用してファイルを表示することをお薦めします。 |
問題5
メタデータの取得時にエラーが発生します。一時エラーが検出されます。
解決策5
トラブルシューティング情報を確認するには、DOMAIN_HOME\servers\WLS_PORTAL\logsディレクトリにある、サーブレットのエラー・ログ・ファイルWLS_PORTAL-diagnostic.logにアクセスします。サーブレットのエラー・ログ・ファイルには、元のエラー・ドキュメントとそのヘッダーが記録されるため、問題が発生したときに標準のデスクトップ・ブラウザで利用できる情報と同僚の情報が格納されます。エラー・ログ・ファイルの情報を使用して、通常のOracle Portalのトラブルシューティング分析を行います。
問題6
モバイル・ブラウザでログイン・リンクをクリックすると、サービス・エラーが発生します。
解決策6
第5.7.1項および第5.7.2項に説明があるAS WirelessパッチおよびOracle SSOパッチが適用されていることを確認します。
Oracle Portal 3.0.9または9.0.4からアップグレードした後に、Oracle Portalのエクスポートおよびインポートを実行すると、予期しないエラーが発生する場合があります。
問題1
トランスポート・セットにカテゴリまたはパースペクティブが含まれている場合は、カテゴリおよびパースペクティブのテンプレートに不適切なページ・タイプID(11ではなく1)が設定されていることにより、エラーが発生する場合があります。
解決策1
トランスポート・セットを確認します。カテゴリまたはパースペクティブが含まれている場合は、Oracle Portalのエクスポートおよびインポート・ユーティリティを実行する前に、次のスクリプトを実行して、この問題を修正します。
SQL> @pstpgcre.sql
このスクリプトは、ORACLE_INSTANCE/portal/admin/plsql/wws/pstpgcre.sqlにあります。このスクリプトを実行すると、カテゴリおよびパースペクティブのテンプレートとその関連ページが削除され、再作成されます。
カテゴリおよびパースペクティブのスクリプトの使用方法は、第B.9項「カテゴリおよびパースペクティブ・スクリプトの使用」を参照してください。
問題2
Oracle Portalを3.0.9からアップグレードすると、カテゴリ名とパースペクティブ名の末尾にpageidとsiteidが追加されます。これがポータル間のエクスポートとインポートに影響を与えています。たとえば、GENERALという名前のカテゴリをバージョン3.0.9からバージョン9.0.4にアップグレードし、さらにバージョン11.1.1にアップグレードすると、アップグレード後のカテゴリ名はGENERAL_12345_0になります。この場合の12345がpageidで、0がsiteidです。
同じカテゴリとパースペクティブでありながら、その名前がソースのポータルとターゲットのポータルで異なっている場合、ポータル間のエクスポートおよびインポートを実行すると、カテゴリまたはパースペクティブを検索するようにカスタマイズされている検索ポートレットから、カテゴリとパースペクティブの検索条件が失われます。
解決策2
ソースとターゲットのポータルで、カテゴリ名とパースペクティブ名が完全に一致していることを確認します。たとえば、次のようになります。
カテゴリ名とパースペクティブ名の末尾に追加されたIDを削除して、アップグレード前の名前に変更します。たとえば、GENERAL_12345_0を元のGENERALに変更します。
または、新しいカテゴリ名とパースペクティブ名を指定します。指定した名前のカテゴリまたはパースペクティブがすでに存在する場合は、別の名前にするよう促すメッセージが表示されます。
|
注意: ソースとターゲットの両方のポータルで同じ変更を行ってください。 |
ポータルの言語が中国語(繁体字)に設定されている場合、「カスタム検索」ポートレットなどのポートレットの操作時、またはナビゲータの使用時にエラーが発生することがあります。
問題
Oracle Metadata RepositoryデータベースのSHARED_POOL_SIZEに設定された値が小さすぎると、ポートレットの操作時にエラーが発生する可能性があります。
解決策
これに対処するには、Oracle Metadata RepositoryデータベースのSHARED_POOL_SIZEの値を大きくします。推奨される最小サイズは144MBですが、この設定は中国語(繁体字)には小さすぎます。SHARED_POOL_SIZEを216MB以上に増やしてみてください。
ポータル・コンテンツをアップロードしており、そのコンテンツがOracle PortalのOracle Text検索を使用して返されない場合は、コンテンツの索引が適切に作成されておらず、検索可能な状態でない可能性があります。
問題
コンテンツがポータルにアップロードされていますが、検索したときに返されません。
解決策
アップロードされたコンテンツの索引が正しく作成されており、検索可能になっていることを確認してください。たとえば、フィルタが原因でドキュメントの索引が正しく作成されていないと、索引内にトークンが存在しないため、ドキュメント内の用語が索引内のトークンと一致せず、検索可能な状態になりません。
コンテンツの索引が正しく作成されており、検索可能な状態であることを確認するには、ファイルベースとURLベースのアイテム・タイプにMIMEタイプ属性およびキャラクタ・セット属性を追加(またはファイルベースとURLベースのアイテムを新規作成してこれらの属性を追加)し、コンテンツのアップロード時にMIMEタイプとキャラクタ・セットを指定します。
Oracle Portalは、中間層とデータベース層で構成され、各層は多数のコンポーネントで構成されています。これらのコンポーネントは多数のコンピュータに分散でき、大量のリクエストを同時に処理することもできます。
Oracle Portalの機能の問題を分析および解決するために、Oracle Portal上で診断ツールを使用することもできます。
この項には次の項目が含まれています。
問題の診断を容易にするために、コンポーネントでは受信したリクエストに関連する情報をログ・ファイルに記録できます。ここでは、問題を診断するために様々なログ・ファイルを構成し、使用する方法、およびExecution Context Identifier(ECID)を使用して、個々のリクエストを最初から最後まで追跡する方法を説明します。
実行コンテキスト識別子
Oracle Portalは同時に多数のリクエストに対応できるため、様々なOracle Portalコンポーネントを通して1つのリクエストを追跡するのは、これらのリクエストに関連する情報が混ざってしまい難しい場合があります。
Oracle Portalでは、リクエストに割り当てられ、そのリクエストについて記録された情報に付加される一意の番号であるECIDを利用します。リクエストが1つのコンポーネントから別のコンポーネントに渡されるときに、ECIDを増分して、順序を付けることができます。このECIDの順序をたどれば、任意の数のコンポーネントを通る個々のリクエストを追跡できます。
ECIDは、ECIDなしの最初のリクエストを受信するOracle Fusion Middlewareコンポーネントが生成します。図G-2は、ECIDの生成と伝播を示しています。この図では、破線がECID付きのリクエストを示しています。
ECIDの生成は、Oracle Web Cache、Oracle HTTP ServerおよびParallel Page Engine(PPE)で行われます。ECIDは、まだ存在しない場合にのみ生成されます。このリリースでは、Oracle Web Cacheのポータル無効化のログに元のリクエストのECIDが含まれるようになりました。これを使用して、元の編集やパーソナライズに無効化を関連付けることができます。
|
関連項目: ECID、およびこれを利用してOracle Fusion Middlewareコンポーネントからのメッセージの関係を調べる方法については、『Oracle Fusion Middleware管理者ガイド』を参照してください。 |
プロセスで内部エラーが検出されたときに、エラーの情報をトレース・ファイルに書き込むことができます。この情報は、ハンドルされていない例外エラーを分析する場合に役立ちます。詳細は、第G.1.17項「ハンドルされていない例外エラー」を参照してください。
データベース・インスタンスのセッションに対するトレース・ファイルを生成するには、次の方法を使用できます。
データベース・インスタンスの特定のセッションに対するSQLトレースは、新しいDADを作成し、PlsqlBeforeProcedureおよびPlsqlAfterProcedureプロシージャの値を設定することで有効にできます。
|
注意: PlsqlBeforeProcedureとPlsqlAfterProcedureの値は元のDADに設定することもできますが、他のユーザーに影響を与える可能性があります。したがって、新しいDADを作成することをお薦めします。 |
トレースを有効にするには、次の手順を実行します。
ポータル・スキーマのutltrace.sqlスクリプトを実行します。デフォルトのポータル・スキーマ名は、portalです。
|
注意: スクリプトutltrace.sqlは、Oracle Fusion Middleware Repository Creation AssistantのCD-ROMのORACLE_INSTANCE/portal/admin/plsql/wwcディレクトリにあります。このCD-ROMは、Oracle Portalのインストールに使用したOracle Fusion Middleware CD-ROMパックに含まれています。
Oracle Portal 11.1.1の場合は、次のURLのOracle Metalinkから |
portal_trcなどの新しいDADを作成します。『Oracle Fusion Middleware mod_plsqlユーザーズ・ガイド』を参照してください。
「OK」をクリックして、HTTP ServerのPL/SQLプロパティに戻ります。
DADステータスセクションで、作成したDADをクリックします。「拡張」をクリックして、次の値を設定します。
PlsqlBeforeProcedure: portal.wwutl_trace.trace_on
PlsqlAfterProcedure: portal.wwutl_trace.trace_off
HTTP ServerとWLS_PORTALを停止して、起動します。
|
注意: 新しいDADのCookieは、ポータルURLのDADと置き換えることができるように、ポータルのDADと同じにする必要があります。新しいDADのCookie名がポータルのDADと異なる場合は、新しいDADのCookie名をポータルのDADのCookie名に置き換えてください。Cookie名の確認方法または更新方法の詳細は、第12.2.1項「PlsqlSessionCookieName値の確認」を参照してください。 |
Oracle Portal URLのDADを、ステップ2で定義した新しいDADに変更し、そのURLを使用してOracle Portalにアクセスします。たとえば、
http://<hostname>:<port>/portal/pls/portal/portal.home
次のように変更します。
http://<hostname>:<port>/portal/pls/portal_trc/portal.home
イベントを設定した後、2つのトレース・ファイルがuser_dump_destディレクトリに書き込まれます。このファイルを開いて、発生したハンドルされていない例外エラーについての情報を確認します。
sql_traceデータベースの初期化パラメータを設定して、トレースを有効化できます。
イベントを設定した後、そのイベントを有効にするには、データベース・インスタンスを再起動する必要があります。
データベース・インスタンスのすべてのセッションのトレースを有効にするには、次のSQL構文を使用して、SPFILEのsql_traceパラメータをtrueに設定します。
ALTER SYSTEM SET sql_trace=true COMMENT = 'turn tracing ON for all sessions' SCOPE=SPFILE;
トレースを無効にするには、次の構文を使用します。
ALTER SYSTEM SET sql_trace=false COMMENT = 'turn tracing OFF for all sessions' SCOPE=SPFILE;
データベースの初期化パラメータの更新手順に精通していない場合は、Oracle Database 11gドキュメント・ライブラリの『Oracle Database管理者ガイド』で、サーバー・パラメータ・ファイルを使用した初期化パラメータの管理に関する項を参照してください。
データベース・イベント10046を設定すると、データベース・インスタンスのすべてのセッションのトレースを有効にできます。イベント10046は、パラメータ・ファイルのsql_traceの値をtrueに設定することと同義です。さらに、イベント10046を設定する場合は、トレースのレベルも指定できます。
|
注意: イベントの設定は、オラクル社カスタマ・サポート・センターのサポートがある場合にのみ行ってください。 |
表G-1は、トレース・レベルを示しています。
表G-1 トレース・レベル
| レベル | 説明 |
|---|---|
|
|
標準の |
|
|
標準の |
|
|
標準の これは主にラッチ待機の識別に使用しますが、全表スキャンおよび全索引スキャンの識別にも使用できます。 |
|
|
標準の |
|
注意: データベース・イベントを設定する際は、次の点を考慮してください。
|
SPFILEのデータベース・イベント10046を設定してトレースを有効にするには、次の構文を使用します。
ALTER SYSTEM SET
EVENT = '10325 trace name context forever, level 10:10015 trace name context forever, level 1'
COMMENT = 'Debug tracing of control and rollback'
SCOPE=SPFILE;
データベースの初期化パラメータの更新手順に精通していない場合は、Oracle Database 11gドキュメント・ライブラリの『Oracle Database管理者ガイド』で、サーバー・パラメータ・ファイルを使用した初期化パラメータの管理に関する項を参照してください。
様々なOracle Portalコンポーネントの診断出力を構成できます。次のコンポーネントが該当します。
Java Portal Development Kit(JPDK)は、Javaベースのポートレットとポートレット・プロバイダを構築するためのフレームワークを提供します。Javaベースのプロバイダ、つまりWebプロバイダは、Webアプリケーションとして記述されます。JPDKには、プロバイダ・アダプタごとに制御されるロギング機能も含まれます。
表G-2は、使用できるログ・レベルとその説明です。ログ・レベルの値の許容範囲は1から8で、累積的です。たとえば、ログ・レベルの3を指定すると、ログ・レベルの1および2の出力も記録されます。
JPDKログ・ファイルの内容
プロバイダ・アダプタの診断情報は、サーブレットのコンテキスト・ログ・ファイルWLS_PORTAL-diagnostic.logに記録されます。
JPDKメッセージには、次の2種類があります。
標準JPDKメッセージ
パフォーマンスJPDKメッセージ
プロバイダ・アダプタのWLS_PORTAL-diagnostic.logファイルに記録される標準JPDKメッセージの例を次に示します。
07/12/31 02:58:59 jpdk: [instance=1926_EXPIRESSAMPLE_886361, id=1024597399815ApplicationServerThread-12,4] Beginning rendering of portlet: 1926_EXPIRESSAMPLE_886361
標準のJPDKメッセージの内容は、次のとおりです。
日時: 07/12/31 02:58:59
Webアプリケーション: jpdk
ECID、順序番号: id=1024597399815ApplicationServerThread-12,4
ポートレット・インスタンス識別子: instance=1926_EXPIRESSAMPLE_886361
メッセージ: Beginning rendering of portlet: 1926_EXPIRESSAMPLE_886361
ポートレット・インスタンス識別子は、特定のページの特定のポートレット・インスタンスを識別し、次のように分類されます。
内部順序番号: 1926
ポートレット名: EXPIRESSAMPLE
プロバイダ識別子: 886361
これらの値の一部についてのさらに詳しい情報を表G-3に示します。
Portalサービスのパフォーマンスは、Oracle HTTP Serverを介してログに記録されます。error_logファイルのデフォルト・ディレクトリは、UNIXの場合はORACLE_INSTANCE/Apache/Apache/log、Windowsの場合はORACLE_INSTANCE\Apache\Apache\logです。ログは、構成ファイルhttpd.confのLogLevelパラメータで制御されます。
Parallel Page Engine(PPE)は、ページ・レイアウトを表すデータを受け入れて、このデータをポートレットを含むページに変換する共有サーバー・プロセス・サーブレットです。
PPEのログは、サーブレットおよびリクエスト・レベルで制御できます。リクエストのログ・レベルを指定しない場合は、リクエストに対してサーブレット・レベルが使用されます。サーブレットとリクエストの両方のログ・レベルを指定する場合は、この2つの高いほうのレベルがリクエストに使用されます。
サーブレットレベルのログ
Oracle Portalの診断ログ設定は、WLS_PORTALインスタンスのlogging.xmlファイル(DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL)に保持されます。
デフォルトでは、ログ・レベルはNOTIFICATION:1で、ログ出力「oracle」に設定されます。Portalのログ出力「oracle.portal」は「oracle」ログ出力の子であり、logging.xmlでログ・レベルが指定されていない場合は親からログ・レベルを継承します。必要に応じて、ログ出力「oracle.portal」に独自のログ・レベルを設定できます。たとえば、次のようになります。
<logger name="oracle.portal" level="FINE"/>
パフォーマンス・ログは、appConfig.xml(DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration\appConfig.xml)で設定します。デフォルトでは、offに設定されています。
<perfLogMode>off</perfLogMode>
onまたはperfを指定することで有効にできます。パフォーマンス・ログの出力は、診断ログと同じターゲットに送信されます。
表G-4は、oracle.portalログ出力のレベル設定がPPEのログ出力に与える影響を示しています。
表G-4 ログ・レベルとその説明
| ログ・レベル | 説明 |
|---|---|
|
なし |
メッセージはありません。 |
|
重大 |
デバッグ・メッセージはありません。警告およびエラーに関する情報が得られます。 |
|
構成 |
デバッグ・メッセージはありません。構成に関するメッセージの情報が得られます。 |
|
密 |
構成に関するメッセージおよび一般的なデバッグ・メッセージの情報が得られます。 |
|
詳細 |
「密」ログ・レベルのすべての情報およびPPEによるリクエストの詳細が得られます。 |
|
最も詳細 |
「詳細」ログ・レベルのすべての情報およびPPEとメタデータ解析で生成されるリクエストのコンテンツの詳細が得られます。 |
リクエストレベルのログ
PPEリクエストレベルのログは、_debug URLパラメータで制御されます。たとえば、次のURLに対してリクエストレベルのログを指定するとします。
http://myserver.myplace.com:3000/portal/page?_pageid=111&_dad=myDAD&_schema=mySchema
次のパラメータを手動で挿入する必要があります。
&_debug=3
変更後のURLは次のようになります。
http://myserver.myplace.com:3000/portal/page?_pageid=111&_dad=myDAD&_schema=mySchema&_debug=3
表G-5に、_debugの値を示します。
表G-5 PPEリクエスト・ログのレベル
| 値 | 詳細 |
|---|---|
|
0 |
ページのデバッグ情報を有効にします。 |
|
1 |
ページのデバッグ情報を有効にします。 |
|
2 |
ページにログを記録し、リクエストのログ・モードを |
|
3 |
ページにログを記録し、リクエストのログ・モードを |
|
4 |
ページにログを記録し、リクエストのログ・モードを |
|
5 |
ページにログを記録し、リクエストのログ・モードを |
ページのログ
_debugを2、3、4または5に設定すると、ページのログが有効になります。つまり、リクエストに対して記録されたメッセージは、PPEのログ・ファイルと、返されるページに記録されます。
ページのログは、リクエストに関連する詳細情報を取得するための手段です。この結果、これはセキュリティの問題ともなるため、urlDebugModeサーブレット初期化引数が用意されています。
urlDebugMode引数は、ポータルのappConfig.xmlファイル(DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration\appConfig.xml)の中でoracle.portalloggerと並んで記述されています。
<urlDebugMode>4</urlDebugMode>
表G-6に、urlDebugMode引数の値を示します。デフォルト値は、1です。
表G-6 PPEのurlDebugModeレベル
| 値 | 詳細 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
PPEログ・ファイルの内容
PPE診断メッセージは、サーブレット・コンテキストのWLS_PORTAL-diagnostic.logファイルに記録されます。このファイルは、次の場所にあります。
DOMAIN_HOME\servers\WLS_PORTAL\logs
PPEメッセージには、次の2種類があります。
標準PPEメッセージ
パフォーマンスPPEメッセージ
標準PPEメッセージ
ログ・ファイルに記録される標準のPPEメッセージの例を次に示します。
03/12/31 11:54:35 portal: id=22020914339,0 DEBUG: active=53 ContentFetcher Unexpected Exception Request Failed:java.lang.IllegalArgumentException name=content-fetcher52 label=dbPortlet url=https://abc.company.com:5001/pls/ptl_ 9_0_4_0_87/!PTL_9_0_4_0_87.wwpro_app_provider.execute_portlet/391497559/4 time=38975ms timeout=15000ms process=ResponseHeaders
この標準のPPEメッセージの内容は、次のとおりです。
日時: 03/12/31 11:54:35
Webアプリケーション: portal
logmodeフラグ: DEBUG
アクティブな数: active=53
ECID: id=22020914339, 0
メッセージ: ContentFetcher Unexpected Exception Request Failed
表G-7に、これらの一部の値の詳細を示します。
表G-7 PPE標準メッセージの属性
| 値 | 詳細 |
|---|---|
|
|
ログ・モードが |
|
アクティブな数 |
PPEのスレッド・グループに含まれているスレッドの数を示します。 |
|
ECID |
|
パフォーマンスPPEメッセージ
ログ・ファイルに記録されるパフォーマンスPPEメッセージの例を次に示します。
07/06/16 06:06:37 portal: [perf] 140.87.20.124 https://abc.company.com:8250/portal/ page?_pageid=40,1&_dad=portal&_ schema=PORTAL&_mode=16 id=8198110376563,1 type=page name=40,1 status=200 user=PORTAL subscriberID=1 reqTime=187ms waitTime=0ms cache=(null) timeout=No redirects=0 bytes=33865 authLevel=10 webCacheStatus=(null) webCacheExpires=(null) webCacheAge=(null) csConv=No readTime=No,0ms pageTimeout=No procTime=0ms
Oracle Fusion Middleware Portal Developer Kit(PDK)は、Java、Web Services、XML、ASP、Perl、PL/SQLなどの様々なWeb言語でポートレットおよびポートレット・プロバイダを構築するためのフレームワークを提供します。したがって、PDKにはJPDKも含まれています。
PDKは、中核となるロギング機能を提供し、特定の開発者キットでログ記録を行うことによってこの機能を拡張します。PDKログは、図G-3に示したようなWebベースのユーザー・インタフェースを通して制御されます。
このPDKログ・ページは、次の場所にあります。
http://<host>:<port>/portal/pls/<dad>/<schema>.wwpro_log.render
サンプルのURLは次のとおりです。
http://myserver.myplace.com:3000/portal/pls/portal/PORTAL.wwpro_log.render
このページから、表G-8に示したログ・レベルを適用できます。
表G-8 PDKログ・レベル
| レベル | 詳細 |
|---|---|
|
No debugging |
ログを記録しません |
|
PROHTTPJ |
プロバイダ・フレームワークのログ |
|
PROGRP |
プロバイダのログ |
|
ADAPTER |
連携型ポータル・アダプタのログ |
|
CACHE |
キャッシュのログ |
|
FORCE |
Oracle内部 |
|
INVAL |
無効化のログ |
|
PROREG |
プロバイダ登録のログ |
|
PROLOGIN |
ページ・メタデータの生成、ログインおよびセッションの初期化のログ |
|
PROPROV |
プロバイダ通信のログ |
|
PROPMR |
ポートレット・メタデータ・リポジトリのログ |
|
PROHTTP |
Webプロバイダ・フレームワークのログ |
|
All |
すべてのログ・レベルを有効にします |
PDKログ・ファイルの内容
図G-4に示したように、PDKログの設定に使用したものと同じページで、PDKログ・エントリを表示できます。
Oracle Metadata Repositoryは、Oracle Portalデータベース・スキーマに存在するすべてのメタデータ、ポータル・コンテンツおよびPL/SQLコードから構成されています。Oracle Portalスキーマで実行されるPL/SQLコードは、Oracle Portalの他のコンポーネントから生成される診断出力と相互に関係付けることができる診断出力も生成します。
ログ・ファイルはOracle Metadata Repositoryで生成されるため、Oracle Portalを実行するデータベースは、これが可能なように構成されている必要があります。これを行うには、CREATE DIRECTORY文を使用してディレクトリ・オブジェクトを作成する必要があります。
ディレクトリ・オブジェクトは、外部ファイルと外部表データがあるサーバー・ファイル・システム上のディレクトリの別名を指定します。
|
注意: ディレクトリはすべて単一のネームスペースで作成され、個々のスキーマにより所有されます。特定のユーザーにディレクトリでのオブジェクト権限を付与することにより、ディレクトリ構造内に格納されたファイルへのアクセスを保護できます。 |
CREATE DIRECTORY文を使用するには、CREATE ANY DIRECTORYシステム権限が必要です。ディレクトリを作成すると、そのディレクトリに対するREADおよびWRITEのオブジェクト権限が自動的に付与されます。その結果、ディレクトリの作成者、つまりデータベース管理者は、これらの権限を他のユーザーやロールに付与できます。
|
注意: ディレクトリに対するWRITE権限は、外部表との接続において便利です。この権限により、権限受領者は、外部表エージェントがそのディレクトリにログ・ファイルまたは不良ファイルを書き込めるかどうかを決定できます。 |
ファイル記憶域用に対応するオペレーティング・システム・ディレクトリも作成する必要があります。システムまたはデータベース管理者は、オペレーティング・システム・ディレクトリにOracle Databaseプロセスに対する正しいREAD権限とWRITE権限があることを確認する必要があります。
ディレクトリに付与される権限は、オペレーティング・システム・ディレクトリに定義されている権限とは関係なく作成され、これら2つは正確に一致する場合も、しない場合もあります。たとえば、サンプル・ユーザーhrにディレクトリ・オブジェクトに対するREAD権限が付与されているのに、対応するオペレーティング・システム・ディレクトリにOracle Databaseプロセスに対して定義されたREAD権限がない場合には、エラーが発生します。
新しいディレクトリ・オブジェクトを作成するには、次の構文を使用します。
CREATE [OR REPLACE] DIRECTORY AS 'path_name';
表G-9に、CREATE DIRECTORY構文で使用するパラメータを示します。
表G-9 CREATE DIRECTORYのパラメータ
| セマンティクス | 説明 |
|---|---|
|
|
ディレクトリ・データベース・オブジェクトがすでに存在する場合は、再作成するために 再定義されたディレクトリに対するアクセス権限がすでに付与されている既存のユーザーは、権限を再び付与されることなく、そのディレクトリにアクセスできます。 |
|
|
作成されるディレクトリ・オブジェクトの名前を指定します。 Oracle Databaseでは、指定するディレクトリが実際に存在するかどうかが検証されません。したがって、オペレーティング・システムで有効なディレクトリが指定されていることを確認する必要があります。さらに、オペレーティング・システムで大文字と小文字を区別するパス名が使用される場合は、必ず正しい形式でディレクトリを指定してください。パス名の最後にスラッシュを付ける必要はありません。 |
|
|
ファイルがあるサーバーのオペレーティング・システム・ディレクトリのフル・パス名を指定します。一重引用符が必要です。その結果、パス名は大文字と小文字が区別されます。 |
たとえば、次の文では、サーバー上のディレクトリを指定するディレクトリ・データベース・オブジェクトが作成されます。
CREATE DIRECTORY admin AS 'oracle/admin';
次の文は、bfile_dirディレクトリ・データベース・オブジェクトを再定義して、オペレーティング・システム・ディレクトリ/private1/lob/filesに格納されているファイルへのアクセスを可能にします。
CREATE OR REPLACE DIRECTORY bfile_dir AS '/private1/LOB/files';
リリース9.2より前のOracle Databaseの場合、PL/SQLコードにより診断出力を生成するには、次の行を追加して、データベースの初期化パラメータ・ファイルを更新します。
UTL_FILE_DIR=<directory where you want to write the log file>
データベースの初期化パラメータの更新手順に精通していない場合は、Oracle Database 11gドキュメント・ライブラリの『Oracle Database管理者ガイド』で、サーバー・パラメータ・ファイルを使用した初期化パラメータの管理に関する項を参照してください。
多数のUTL_FILE_DIRエントリが存在する場合があるため、書き込むディレクトリがすでに定義されている場合は、このファイルを変更する必要はありません。
|
注意: Oracle Metadata Repositoryのインストールでは、インストール先のデータベースにUTL_FILE_DIRパラメータがある場合、Oracle Portalインストーラは、Oracle Metadata Repositoryログ・ファイルの場所としてデータベース・パラメータに最初に定義されたディレクトリを使用するようにOracle Metadata Repositoryを構成します。UTL_FILE_DIRディレクトリが構成されていない場合は、インストール時にOracle Metadata Repositoryログは設定されません。 |
Oracle Metadata Repositoryのログは、ログ・パッケージによって実行されます。このログ・パッケージは、SQL*Plusから実行する必要があるlogcfg.sqlスクリプトによって制御されます。
logcfg.sqlスクリプトは、次の場所にあります。
ORACLE_INSTANCE/portal/admin/plsql/wwc
logcfg.sqlスクリプトには、log_level、log_state_level、log_format、log_file、log_directoryの順に、5つのパラメータを指定できます。指定したパラメータが5つ未満の場合は、1つ以上の値がリクエストされます。このリクエストに対するレスポンスとして値を受け取らない場合は、現在の値が維持されます。
表G-10は、logcfg.sqlパラメータの詳細を示しています。
表G-10 リポジトリのログ・パッケージのパラメータ
| パラメータ | 詳細 |
|---|---|
|
|
記録されたメッセージのレベルを示します。値は、次のとおりです。
値は、累積的です。デフォルト値は、 |
|
|
状態情報が自動的にログに記録されるメッセージのレベルを示します。値は、次のとおりです。
値は、累積的です。 |
|
|
状態情報のフォーマットとは異なる、自動的に記録されたコンテキスト情報のフォーマットを示します。値は、次のとおりです。
|
|
|
書き込むログ・ファイルの名前を指定します。このファイルがまだ存在しない場合は、作成を試みます。 |
|
|
utl_file_dir=/export/home/oracle/as1014/logs データベース・パラメータ・ファイルを変更する場合は、変更を有効にするためにデータベースを再起動する必要があります。 この値がディレクトリ・オブジェクトの場合、ディレクトリ・オブジェクト名を大文字で指定する必要があります。たとえば、 |
たとえば、logcfg.sqlスクリプトをSQL*Plusから次のように実行できます。
@logcfg.sql 3 3 1 portal.log /export/home/oracle/as1014/logs
ディレクトリ・オブジェクトを参照する場合は、ディレクトリ・オブジェクト名を大文字で指定する必要があります。たとえば、logsという名前のディレクトリ・オブジェクトを参照するには、logcfg.sqlスクリプトをSQL*Plusから次のように実行します。
@logcfg.sql 3 3 1 portal.log LOGS
logcfg.sqlを実行すると、使用方法が表示されます。
Configure Portal diagnostics usage: logcfg.sql <log_level> <log_state_level> <log_format> <log_file> <log_directory> If for any of the params a null value is specified the existing value will be maintained. Log levels: 0 : None (turn diagnostics off) 1 : Error 2 : Warning 3 : Information 4 : Trace 5 : Debug 6 : Fine Debug Log formats: 0 : Simple 1 : Detailed
現在の値も表示されます。
Current settings: Log level: 3 Log state level: 3 Log format: 1 Log file: portal.log Log directory: /export/home/oracle/as101202/dblogs
Oracle Metadata Repository診断ログ・ファイルを切り捨てるには、ORACLE_INSTANCE/portal/admin/plsql/wwcにあるSQLスクリプトlogtrunc.sqlを実行します。
リポジトリ・ログ・ファイルの内容
Oracle Metadata Repositoryの診断情報の場所は、リポジトリ診断パッケージ・パラメータのlog_fileおよびlog_directoryによって指定されます。
Oracle Metadata Repositoryログ・ファイルに記録されるERRORタイプ・メッセージの例を次に示します。
[06-AUG-2007 15:02:15] [ERROR] id=(102733434) ctx=wwsrc_simple_edit.render_simple_edit_prefs user=PORTAL subscriberId=1 language=us userAgent="Mozilla/5.0" ip=192.0.0.1 ORA-30625: method dispatch on NULL SELF [START-ERROR-STACK] ORA-30625: method dispatch on NULL SELF [END-ERROR-STACK] [START-CALL-STACK] ----- PL/SQL Call Stack ----- object line object handle number name 81b35e6c 350 package body PORTAL.WWLOG_API_DIAG 81b35e6c 443 package body PORTAL.WWLOG_API_DIAG 81b35e6c 526 package body PORTAL.WWLOG_API_DIAG 86765ac8 259 package body PORTAL.WWSRC_SIMPLE_EDIT 86765ac8 334 package body PORTAL.WWSRC_SIMPLE_EDIT 84317130 19 package body PORTAL.WWSBR_BASIC_SEARCH 88857980 713 package body PORTAL.WWSBR_SITEBUILDER_PROVIDER 8323ad18 1 anonymous block 87e53d5c 648 package body PORTAL.WWPRO_API_PROVIDER 81ae1e50 2644 package body PORTAL.WWPOB_PAGE 877a0d9c 12 anonymous block [END-CALL-STACK] [START-QUERY-STRING] _providerid=102274117 _portletid=14 _mode=5 _title=Basic%20Search _referencepath=1875_BASICSEARCH_102274117 _back_url=http%3A%2F%2Fmyserver.myplace.com%3A3000%2Fpls%2Fportal% _portlet_reference=33_31293_33_1_1 [END-QUERY-STRING]
ログ・ファイルに記録されるメッセージは次のとおりです。
ORA-30625: method dispatch on NULL SELF: メッセージ本体。
ログ・ファイルには、コンテキスト情報および状態情報も記録されます。
コンテキスト情報
コンテキスト情報は、詳細またはシンプルのいずれかのフォーマットで生成されます。これは、log_formatパラメータで指定します。次の例は、フォーマットの詳細です。
06-AUG-2007 15:02:15: 日時
ERROR: メッセージ・レベル
id=(102733434, 1): ECID
ctx=wwsrc_simple_edit.render_simple_edit_prefs: メッセージ・コンテキスト
user=PORTAL: データベース・ユーザー
subscriberId=1: サブスクライバ識別子
language=us: グローバリゼーション・サポート言語
userAgent="Mozilla/5.0": ユーザー・エージェント
ip=192.0.0.1: クライアントIPアドレス
シンプルな書式は、詳細な書式の一部であり、次の情報が含まれます。
06-AUG-2007 15:02:15: 日時
ERROR: メッセージ・レベル
ctx=wwsrc_simple_edit.render_simple_edit_prefs: メッセージ・コンテキスト
表G-11に、これらの一部の値の補足情報を示します。
表G-11 リポジトリ・コンテキストの属性
| 値 | 詳細 |
|---|---|
|
クライアントIPアドレス |
通常、これは使用しているクライアントのブラウザまたはHTTPプロキシのIPアドレスです。Oracle Portalページ・アセンブリ・プロセスはループバック・コールを使用しているため、IPアドレスは中間層そのものを表すこともできます。 |
|
サブスクライバ識別子 |
リポジトリにアクセスしたサブスクライバを識別します。 |
|
ユーザー・エージェント |
使用しているブラウザの説明です。 |
状態情報
状態情報は、エラー・スタック、コール・スタックおよび問合せ文字列で構成されます。それぞれの例を次に示します。
|
注意: PL/SQLエラー・スタックは、ERRORタイプのメッセージがログに記録されている場合にのみ表示されます。 |
エラー・スタック:
[START-ERROR-STACK] ORA-30625: method dispatch on NULL SELF [END-ERROR-STACK]
コール・スタック:
[START-CALL-STACK] ----- PL/SQL Call Stack ----- object line object handle number name 81b35e6c 350 package body PORTAL.WWLOG_API_DIAG 81b35e6c 443 package body PORTAL.WWLOG_API_DIAG 81b35e6c 526 package body PORTAL.WWLOG_API_DIAG 86765ac8 259 package body PORTAL.WWSRC_SIMPLE_EDIT 86765ac8 334 package body PORTAL.WWSRC_SIMPLE_EDIT 84317130 19 package body PORTAL.WWSBR_BASIC_SEARCH 88857980 713 package body PORTAL.WWSBR_SITEBUILDER_PROVIDER 8323ad18 1 anonymous block 87e53d5c 648 package body PORTAL.WWPRO_API_PROVIDER 81ae1e50 2644 package body PORTAL.WWPOB_PAGE 877a0d9c 12 anonymous block [END-CALL-STACK]
問合せ文字列:
[START-QUERY-STRING] _providerid=102274117 _portletid=14 _mode=5 _title=Basic%20Search _referencepath=1875_BASICSEARCH_102274117 _back_url=http%3A%2F%2Fmyserver.myplace.com%3A3000%2Fpls%2Fportal% _portlet_reference=33_31293_33_1_1 [END-QUERY-STRING]
リポジトリ診断ログ・ファイルの登録
Oracle Enterprise Manager 11gには、Log ReaderとLog Viewerがあります。Log Readerを使用すると、管理者はログ・ファイルをファイルベースのログ・リポジトリにアップロードできます。Log Viewerを使用すると管理者はリポジトリにロードされたログ・エントリの表示や問合せを行うことができます。詳細は、第G.2.4項「Fusion Middleware ControlのLog Viewerの使用」を参照してください。
リポジトリ診断ログ・ファイルのエントリのロードや表示を行うためには、先にログ・ファイルをOracle Enterprise Manager 11gに登録する必要があります。これを行うには、次のファイルを編集します。
ORACLE_INSTANCE/diagnostics/config/registration/PORTAL.xml
このファイルには、ログ・ファイルの詳細を反映するようにコピーして拡張できるテンプレート・エントリがあります。テンプレートは、次のとおりです。
<logs xmlns="http://www.oracle.com/iAS/EMComponent/ojdl" helpIDLogs="psm_cs_xml_log_info">
<!--
<log path="<PATH>" componentId="PORTAL">
<logreader type="SimpleTextLog">
<property name="ComponentId" value="PORTAL"/>
<property name="ModuleId" value="Portal:<INSTANCE>"/>
<property name="TimestampFormat" value="[dd-MMM-yyyy HH:mm:ss]"/>
<property name="TimestampLocale" value="en_US"/>
</logreader>
<logviewer ComponentName="ID_VLOGS_PORTAL_REP@ResourceBundle"
LogType="ERROR"
LogName="Diagnostics for Portal instance <INSTANCE>"/>
</log>
-->
</logs>
コピーしたテンプレート・エントリに含まれる情報を次のように変更します。
<PATH>: ログ・ファイルの絶対パスとファイル名。
<INSTANCE>: 定義されている場合、Oracle Enterprise Manager 11gでのOracle Portalターゲットの名前。対応するOracle PortalターゲットがOracle Enterprise Manager 11gにない場合は、<portal schema name>-<db service name>など、Oracle Portalインスタンスの名前とデータベースの詳細を使用します。この値は、Log Viewerでこのログ・エントリを他のOracle Portalインスタンスのログ・エントリと区別するために使用します。
新しいPORTAL.xmlエントリを保存すると、Log Readerはログ・ファイルの定期的なアップロードを開始し、Log Viewerを使用してログ・ファイルの表示や問合せを行えるようになります。
Oracle Metadata Repositoryは多数の中間層を通してアクセスされるので、次の手順を実行する必要があります。
リポジトリ診断ログ・ファイルをOracle Portal中間層を監視しているいずれかのOracle Enterprise Manager 11g Fusion Middleware Controlインスタンスに登録します。
Oracle PortalデータベースがOracle Portal中間層以外のコンピュータにある場合は、ネットワーク・ファイル・システムからログ・ファイルにアクセスできるようにします。
複数の中間層環境でログを相互に関連付けるには、Oracle Portal中間層を監視する各Oracle Enterprise Manager 11gインスタンスにリポジトリ診断ログ・ファイルを登録する必要があります。
|
注意: Oracle Enterprise Manager 11gを使用して、ORACLE_INSTANCE/diagnostics/config/registration/にあるPORTAL.xmlファイル内のリポジトリ診断ログ・ファイルの場所を更新する必要があります。 |
Oracle Web Cacheのイベントとエラーは、イベント・ログに格納されます。イベント・ログは、どのドキュメントまたはオブジェクトがキャッシュに挿入されたかを確認するうえで役立ちます。リスニング・ポートの競合または起動や停止の問題を特定することもできます。デフォルトでは、イベント・ログのファイル名はevent_logであり、UNIXではORACLE_INSTANCE/webcache/logsに、WindowsではORACLE_INSTANCE\webcache\logsに格納されています。
|
関連項目: 『Oracle Fusion Middleware Administrator's Guide for Oracle Web Cache』 |
Oracle Enterprise Manager 11g Fusion Middleware Controlでは、次のログ・ファイルのエントリの表示や問合せが可能です。そのため、Oracle Portalに関連する問題の診断に役立ちます。関連するOracle Fusion Middlewareのコンポーネントのログ・ファイルには、次のものがあります。
Portal:<instance>: ポータル・インスタンスごとに、<customer_specified_log_name>という1つの診断エラー・ログ・ファイルを表示します。このログ・ファイルは、関連するOracle Metadata Repositoryによって生成されます。
HTTP_Server: error_log、access_logという複数のエラー・ログ・ファイルまたはアクセス・ログ・ファイルを表示します。これらのログ・ファイルには、すべての関連するPortalサービスのログ情報が含まれています。
WLS_Portal: WLS_PORTAL-diagnostic.logという複数のアプリケーション・ログ・ファイルを表示します。このログ・ファイルには、すべての関連するPPEログ情報が含まれています。
Web Cache: event_logおよびaccess_logというエラー・ログ・ファイルおよびアクセス・ログ・ファイルを表示します。
登録手順を完了しなければ、Oracle Metadata Repositoryログ・ファイルをFusion Middleware ControlのLog Viewerで使用することはできません。手順については、「リポジトリ診断ログ・ファイルの登録」を参照してください。
JPDK WLSインスタンスがOracle Portalの中間層のOracleホームにない場合は、そのログ・ファイルはローカルのFusion Middleware Controlのインスタンスを使用しないと表示できません。診断の相関関係を作成する必要がある場合は、Oracle Metadata Repositoryログ・ファイルをリモートに配置する場合の手順と同様のリモート登録手順に従う必要があります。
Oracle Fusion Middleware ControlのLog Viewerでログ・ファイルのエントリを表示する方法以外にも、ECID値を使用してログ・ファイル間でエントリを相互に関連付けることによって、詳細な診断を行うこともできます。詳細は、第G.2.1項「ECIDロギングの有効化」を参照してください。このドリルダウンの相関関係は、Oracle Fusion Middleware ControlのLog Viewerに自動的に表示されます。
ログ・ファイルのエントリを表示するには、各Oracle Fusion Middleware Controlのコンポーネントのホーム・ページの上部と下部にある「ログ」をクリックします。
|
関連項目: Log Viewerの使用方法の詳細は、Oracle Fusion Middleware管理者ガイドを参照してください。このマニュアルでは、診断ログ・ファイル情報に対する高度な問合せ、ログ・リポジトリ内での診断メッセージ(選択したOracle Fusion Middlewareコンポーネントから収集)の検索、およびログ・ファイルとコンポーネント間でのメッセージ相互の関連付けの方法についても説明します。 |
Oracle Portalのインストール後に問題のトラブルシューティングを行う場合は、Oracle Portal Diagnostics Assistantを使用します。Oracle Portalへのアクセスの問題から、Oracle Portal内の異なるレベルでのエラー発生などの様々な問題があります。
Oracle Portal Diagnostics Assistantの結果を調べることで、問題を診断できます。また、結果をオラクル社カスタマ・サポート・センターにアップロードして、問題のトラブルシューティングに役立てることもできます。
エラーおよび違反(Oracle Portal Diagnostics Assistantで検出された場合のみ)のサマリー
Oracle Portalリポジトリのデータベース情報
OracleAS Single Sign-Onのデータベース情報
Oracle Internet Directoryの診断レポート
Oracle Textの診断レポート
Apacheのエラー・ログ・ファイル分析
また、利便性のために、すべてのOracle Portal関連の構成ファイルおよびログ・ファイルが収集され、圧縮されます。
Oracle Portal Diagnostics Assistantを実行するには、UNIXの場合はスクリプトpda.csh、Windowsの場合はpda.cmdを使用する必要があります。スクリプトを実行するたびに、生成されたファイル用の新しいディレクトリが、Oracle Portal Diagnostics Assistantのzipファイルをダウンロードしたディレクトリの下に作成されます。ディレクトリ名は、タイムスタンプの形式で表されます。たとえば、070623132344の場合、次のような意味になります。
Oracle Portal Diagnostics Assistantの実行後、該当するディレクトリに移動して、ブラウザのウィンドウでpda.htmという名前のHTMLレポートを開きます。このレポートを調べて、診断情報を確認します。
オラクル社カスタマ・サポート・センターに問題のトラブルシューティングのサポートを依頼する場合は、Oracle Metalink(http://metalink.oracle.com)にログオンして、生成されたPDA<directory_name>.zipというzipファイル(PDA040623132344.zipなど)をアップロードします。
Oracle Portal Diagnostics Assistantの使用方法および収集された情報の詳細は、Oracle Portal Diagnostics Assistantをダウンロードしたディレクトリのreadmeファイルを参照してください。
Oracle Portal Diagnostics Assistantの実行
Oracle Portal Diagnostics Assistantを使用して診断情報を生成するには、次の手順を実行します。
次のURLにアクセスし、OTNの「Support and Metalink」セクションで、Oracle Portal Diagnostics Assistantの最新の更新およびパッチ情報を確認します。
http://www.oracle.com/technology/
最新のOracle Portal Diagnostics Assistantスクリプトをダウンロードします。「Support/Upgrade」は、「Product Information」セクションにあります。
ORACLE_INSTANCE環境変数が、正しいOracle Portal中間層のOracleホーム・ディレクトリに設定されていることを確認します。
Oracle Portal Diagnostics AssistantをデータベースのOracleホーム・ディレクトリから実行しようとすると、失敗し、診断情報は収集されません。
Oracle Portal Diagnostics Assistantをダウンロードして解凍した場所に移動します。
UNIXでは、次のようにOracle Portal Diagnostics Assistantを実行します。
pda.csh -schema <portal schema name> -password <portal schema password> -connect <Portal connect string> -ssoSchema <SSO schema name> -ssoPassword <SSO schema password> -ssoConnect <SSO connect string> [-apacheLogDir <directory name>] [-apacheLogName <file name>] [-logFileLimit <number of rows>] [-show] [-showall]
ヘルプ情報を表示するには、パラメータを使用せずにスクリプトを実行します。
表G-12は、Oracle Portal Diagnostics Assistantのスクリプトで使用するパラメータとその説明です。
表G-12 Oracle Portal Diagnostics Assistantのスクリプトのパラメータ
| パラメータ | 説明 |
|---|---|
|
-schema |
Oracle Portalスキーマの名前。このパラメータは必須です。デフォルトは |
|
-password |
Oracle Portalスキーマのパスワード。このパラメータは必須です。デフォルトは |
|
-connect |
Oracle Portalスキーマの接続文字列。 |
|
-ssoSchema |
OracleAS Single Sign-Onスキーマの名前。このパラメータは必須です。 |
|
-ssoPassword |
OracleAS Single Sign-Onスキーマのパスワード。このパラメータは必須です。 |
|
-ssoConnect |
OracleAS Single Sign-Onスキーマの接続文字列。 |
|
-apacheLogDir |
Oracle HTTP Serverのエラー・ログ・ファイルのディレクトリ。このパラメータはオプションです。デフォルトは、 |
|
-apacheLogName |
エラー・ログ・ファイル名。このパラメータはオプションです。デフォルトは |
|
-logFileLimit |
エラー・ログ・ファイル内の行数。このパラメータはオプションです。デフォルトは |
|
-show |
必要な問合せのセットのみに基づいて診断情報を生成します。他のパラメータが選択されていない場合、これが診断情報を生成する際のデフォルト・モードとなります。 |
|
-showall |
すべての問合せに基づいて診断情報を生成します。このモードでは、関連するセキュリティ・テーブルからすべてのポータル・オブジェクトとその権限を取得する問合せも使用されます。そのため、 |
UNIXプラットフォームでのOracle Portal Diagnostics Assistantの実行例を次に示します。
# Set the environment # setenv ORACLE_INSTANCE /oracle/productsAS # # Run PDA # pda.csh \ -schema portal \ -password <portal_password> \ -connect abc.oracle.com:1521:orcl1 \ -ssoSchema orasso \ -ssoPassword <orasso_password> \ -ssoConnect defg.oracle.com:1521:orcl2 -show
Windowsでは、次のようにOracle Portal Diagnostics Assistantを実行します。
コマンド・プロンプトを起動して、次のコマンドを実行します。
pda.cmd -schema <portal schema name> -password <portal schema password> -connect <Portal connect string> -ssoSchema <SSO schema name> -ssoPassword <SSO schema password> -ssoConnect <SSO connect string> [-apacheLogDir <directory name>] [-apacheLogName <file name>] [-logFileLimit <number of rows>] [-show] [-showall]
ヘルプ情報を表示する場合は、パラメータを使用せずにスクリプトを実行します。
表G-12は、Oracle Portal Diagnostics Assistantのスクリプトで使用するパラメータとその説明です。
ブラウザのウィンドウで最新のHTMLレポート(pda.htm)を開き、Oracle Portalの問題の診断に役立てます。
標準のデスクトップ・ブラウザと比べて、モバイル・デバイスには、詳細なエラー情報を表示する適切なインタフェースがありません。次に示す情報は、Oracle Portalでモバイル関連の問題を分析する場合に役立ちます。
_debugパラメータの使用
すべてのOracle Portalページは、実行時間とキャッシュの情報が表示される特殊なモードで実行できます。ページのURLの末尾に_debug=1パラメータを付けると、表示されるレスポンスに他の実行時間の情報が追加されます。
選択したいくつかのページとポートレットに関するデバッグ情報を表示する場合は、_debug URLパラメータを使用してログ・レベルを制御できます。_debugの有効な値は、0、1、2、3、4および5です。実行時間およびキャッシュの統計の詳細は、第B.6項「実行時間とキャッシュの統計」を参照してください。
モバイル・ブラウザからアクセスする場合は、_debug URLパラメータを使用すると問題が生じることがあります。これは、次の理由によります。
モバイル・デバイスでOracle Portalのアクセスに使用されるURLは、Oracle Portalではなく、OracleAS Wirelessサービスを参照しています。したがって、モバイル・ブラウザでは、_debug=1パラメータを直接URLに付加することはできません。
モバイル・デバイスで情報をレンダリングするには、レスポンス・ページが有効なOracleAS Wireless XMLであることが必要です。追加情報は有効なOracleAS Wireless XMLでない場合があるため、モバイルのレスポンス・ページのインラインに追加できません。
この問題を解決して_debugパラメータを使用するには、次のタスクを実行します。
OracleAS Wirelessに登録されているデフォルトのPortalサービスを使用するかわりに、ページに直接アクセスする新しいサービスをOracleAS Wirelessサーバーに作成します。URLは、次のフォーマットで指定します。
http://<host.domain>:<port>/portal/pls/portal/MyGroup/MyPage?_debug=1
モバイル・デバイスで、デフォルトのPortalサービスではなく、新しいサービスをリクエストします。
サーブレットのログ・ファイルを表示して、記録されたパフォーマンス情報を調べます。この情報は、次のようなフォーマットで表示されます。
4/23/02 5:38 AM portal: [perf] Information for Portlet 33,31071. Portlet Timing: 234 msecs (wait=0) Timing Status: XSLT Timing: null msecs Caching information of portlet: Portlet Cache status: <I>Web Cache:-</I> MISS,NON-CACHEABLE [N], <I>File System Cache:-</I> MISS,NEW From Cache: <I>Web Cache:-</I> -, <I>File System Cache:-</I> None From Portlet: Cache Key: NORMAL, Cache Level: USER 4/23/02 5:38 AM portal: [perf] Information for Page 33%2C31060%2C33_31062 Elapsed Time: 2470 msecs Page meta-time 7 msecs (wait = 994) Page meta Cache Status: <I>Web Cache:-</I> MISS,NON-CACHEABLE [N], Cache Expires: null secs, Age in Cache: null secs , <I>File System Cache:-</I> MISS,NEW Login meta-time 1227 msecs (wait = 1) Login meta Cache Status: <I>Web Cache:-</I> MISS,NON-CACHEABLE [N], Cache Expires: null secs, Age in Cache: null secs
サポートに役立つモバイル情報
第G.1.20項「モバイル・デバイスからOracle Portalへのアクセスに関する問題」で説明したトラブルシューティングの手順を使用してもモバイル関連の問題を解決できない場合は、オラクル社カスタマ・サポート・センターに問い合せます。オラクル社カスタマ・サポート・センターを利用する際は、あらかじめ次の質問に対する回答を用意してください。
エラーはどのような現象ですか (エラー・メッセージが表示された、欠落しているレスポンスがあった、空白の画面が表示された、など)。
エラーはどのような状況で発生しますか。
ユーザーはログオンしていましたか。
認証されたすべてのユーザーに同じ問題が発生していますか。
その問題はパブリック・ユーザーにも発生していますか。
ログオンの段階で問題は発生しますか。
ログオンできるまでにどのくらい時間がかかりましたか。
通常どおりにログオンしましたか、あるいはログオンするよう指示されましたか。
ページを表示するときに問題は発生しますか。
ページの構造を説明してください。
タイトルをパーソナライズできるポートレットはありますか。
通信ネットワーク上のOracleAS Wirelessを介さずに、標準のデスクトップ・ブラウザでページをプレビューできますか。
個々のポートレットを表示するときに問題は発生しますか。
問題が発生するのはすべてのモバイル・ページ、一部のページ、1ページのみのいずれですか。
可能であれば、OracleAS Wirelessデバッグ・ツールを使用してPortalサービスを実行します。これには、特定のOracleAS Wirelessアクセスが必要です。詳細は、『Oracle Application Server Wireless管理者ガイド』を参照してください。
表G-13に示すログ・ファイルのいずれかに、問題が記録されていますか。
表G-13 エラー・ログ・ファイルとその場所
| ログ・ファイル | 場所 |
|---|---|
|
OracleAS Wirelessサーバーのログ・ファイル |
サーバーJVMの標準出力:
プロバイダJVMの標準出力:
|
|
Oracle HTTP Serverのログ・ファイル |
|
|
Parallel Page Engineサーバーのログ・ファイル |
|
Oracle Portalでパフォーマンス・ログを有効にするには、次の手順を実行します。
logging.xmlを開きます。これは、DOMAIN_HOME/config/fmwconfig/servers/WLS_PORTALディレクトリに存在します。
次のように、nameにoracle.portal、levelにNotification:16を指定してlogger要素を追加します。
<logger name="oracle.portal" level="NOTIFICATION:16"/>
|
注意: パフォーマンス・ログを無効にするには、前述の行をlogging.xmlから削除するか、levelをERROR:1に変更します。 |
WLS_PORTALサーバーを再起動します。
ログ・エントリは、DOMAIN_HOME/servers/WLS_PORTAL/logsディレクトリのWLS_PORTAL-diagnostic.logファイルに書き込まれます。
|
注意:
|
次のURLのOracle MetaLinkには、さらに多くの解決策が掲載されています。
ここでも問題の解決策が見つからない場合は、オラクル社カスタマ・サポート・センターに問い合せてください。
オラクル社カスタマ・サポート・センターに問題のトラブルシューティングを依頼する場合は、次の手順を実行してください。
Oracle Portal Diagnostics Assistantを実行します。
Oracle Portal Diagnostics Assistantを使用して生成されたレポートを調べると、ポータル関連の問題を診断できます。詳細は、第G.2.5項「Oracle Portal Diagnostics Assistantの使用」でも説明しています。
オラクル社カスタマ・サポート・センターに問い合せます。
ポータルにアクセスできない原因が特定できない場合は、オラクル社カスタマ・サポート・センターに問い合せます。オラクル社カスタマ・サポート・センターが問題のトラブルシューティングを行う際に役立つ、次の情報を用意してください。
Oracle Portal Diagnostics Assistantで生成されたZIPファイル。
実行したコマンドライン・スクリプト(ptlconfigなど)と使用したすべてのパラメータの詳細。
Oracle Fusion Middlewareコンポーネントがどのように構成されているかを示す、おおまかなネットワーク図。
|
関連項目: Microsoft Windows (32ビット)用Oracle Fusion Middlewareのリリース・ノート(OTNのhttp://www.oracle.com/technology/documentation/index.htmlで入手可能) |
