| Oracle® Fusion Middleware Oracle Portal管理者ガイド 11gリリース1 (11.1.1) B61385-05 |
|
 前 |
 次 |
Oracle Fusion Middlewareの一部としてOracle Portalをインストールした後は、いくつかのスクリプトがインストール後の構成を行うために使用できるようになります。
この付録の内容:
Oracle Portalは、パフォーマンスを向上させるためにキャッシュを使用します。使用されるキャッシュのタイプの1つに、無効化ベースのキャッシュがあります。無効化ベースのキャッシュでは、Oracle Portalは様々なオブジェクト(ページ、ポートレットなど)を一定期間キャッシュします。これらのオブジェクトがリクエストされると、オブジェクトがキャッシュされている場合はキャッシュから取得され、キャッシュされていない場合はMetadata Repositoryから再生成されます。これらのオブジェクトのキャッシュは、最大キャッシュ時間に達したとき、または無効化メッセージによってオブジェクトが明示的に無効化したときに期限切れになります。
Oracle Portalは、キャッシュ内のオブジェクトを期限切れにするときに、無効化メッセージを使用します。無効化メッセージは、強い無効化と弱い無効化に分類されます。強い無効化はすぐに有効になります。つまり、無効化するオブジェクトはすぐにキャッシュから期限切れになります。弱い無効化は、無効化処理ジョブによって処理されたときに有効になります。無効化ジョブの実行頻度は構成可能です。これは、cachjsub.sqlスクリプトを使用して行います。
無効化処理ジョブの実行頻度を変更するには、次の手順を実行します。
次のディレクトリに移動します。
ORACLE_HOME\portal\admin\plsql\wwc
ポータル・スキーマがインストールされているデータベースで、そのスキーマの適切なユーザー名とパスワードを使用してSQL*Plusにログインします。
例:
sqlplus portal/portal
次のコマンドを入力して、無効化処理ジョブの実行頻度を更新します。
SQL> @cachjsub.sql <start_time> <start_time_fmt> <interval_mins>
cachjsub.sqlは、次の3つのパラメータをとります。
start_timeには、最初のジョブが実行される時間またはSTARTを指定します。
start_time_fmtには、start_timeの値に適用するOracle日付書式モデルを指定します。Oracle日付書式モデルの詳細は、データベースのドキュメント・ライブラリを参照してください。
interval_minsには、実行の間隔を分単位で指定します。
|
注意: 最初のパラメータにSTARTを指定すると、2番目のパラメータは無視され、デフォルトで現在の時刻が開始時刻になります。 |
例1
SQL> @cachjsub.sql START null 120
例2
SQL> @cachjsub.sql '02-22-2005 7:30' 'MM-DD-YYYY HH:MI' 1440
例3
SQL> @cachjsub.sql '06-14-2005 15:30' 'MM-DD-YYYY HH24:MI' 60
注意: 例3では、24時間形式で時刻が表示されます。
デフォルトでは、Oracle Portalは、Oracle Internet Directoryに接続するときに、SSLを使用しないLDAPを使用します。Oracle Internet DirectoryサーバーがSSLポートに対応している場合は、LDAP over SSL (LDAPS)を使用するようにOracle Portalを構成できます。
|
関連項目: Oracle Fusion Middleware Oracle Internet Directory管理者ガイド |
SSLを使用してOracle Internet Directoryに接続するようにOracle Portalを構成するには、secupoid.sqlスクリプトを実行する必要があります。このスクリプトにより、Oracle Internet Directoryに関連する次のOracle Portal構成パラメータを変更できます。
Oracle Internet Directoryホスト名
Oracle Internet Directoryポート
アプリケーションOracle Internet Directoryパスワード
SSL設定
Oracle Portalをインストールすると、Oracle Internet Directoryサーバーを使用するように自動的に構成されます。ただし、SSLを使用するかどうかなど、インストール後に一部の設定を変更できます。Oracle Internet DirectoryのSSL接続に変更するには、PORTALスキーマのORACLE_HOME/portal/admin/plsql/wwc/secupoid.sqlスクリプトを実行してLDAPポートのかわりにLDAPSポートを指定すると、SSLを使用するように指定されます。
secupoid.sqlスクリプトの実行
この項では、SQL*Plusからsecupoid.sqlを実行した例を示します。
この例では、LDAPをポート3060で実行するようにOracle Internet Directoryを初期構成しています。次にLDAPSポートを3130上で有効にします。サーバー名は変わらないため、以前の値を保持したままポートを更新し、SSLを使用することを指定するために「Use SSL?」に対して「Y」を設定します。このスクリプトを実行すると、現在の構成が表示され、変更可能な構成を置き換えることができます。スクリプトの実行後に、Oracle PortalのOracle Internet Directoryキャッシュを更新することもできます。SSLを有効にしても、Oracle PortalによってキャッシュされたOracle Internet Directory情報は変更されません。このため、通常はこうした状況でキャッシュを更新する必要はありません。
SQL> @secupoid Current Configuration -------------------- OID Host: oid.domain.com OID Port: 3060 Application DN: orclapplicationcommonname=ssl_portal.080130.052806.514018000,cn=portal,cn=products,cn=oraclecontext Application Password: 2E1325D176112857A6E76E803E6284B0 Use SSL? N PL/SQL procedure successfully completed. Updating OID Configuration Entries Press [Enter] to retain the current value for each parameter For SSL Connection to LDAP, specify "Y"es or "N"o ------------------------------------------------ Enter value for oid_host: Enter value for oid_port: 3130 Enter value for app_password: Enter value for use_ssl_to_connect_to_ldap: Y Enter value for refresh_with_new_settings: N PL/SQL procedure successfully completed. No errors.
このスクリプトの実行後に、Oracle Portalは、Oracle Internet DirectoryでLDAPSアクセスを使用するように構成されます。
secupoid.sqlを実行すると、Oracle Metadata Repositoryのポータル・スキーマに格納されているOracle Internet Directoryのポート番号が変更される場合があります。
Oracle Portalは、セッションCookieを使用して、ポータル・アプリケーションのセッション状態を保持します。ポータルが正常に機能するよう、クライアントのブラウザはサーバーのCookieを受け取るように構成しておく必要があります。インストール時には、ポータル・セッションCookieに、ほとんどのインストールで適用できるように設定されているデフォルトの名前、適用範囲およびセキュリティが定義されます。この項ではこれらのデフォルトについて説明し、必要な場合にこれらの値を変更する方法について説明します。
デフォルトでは、ポータルのセッションCookieに、ポータル・スキーマへのアクセスに使用されるデフォルトのデータベース・アクセス記述子(DAD)に従ってportalという名前が設定されます。明示的に別の設定をする必要がある場合は、Oracle Enterprise Manager 11gを使用してCookie名を変更することができます。これを行うには、Oracle Enterprise Manager 11g Fusion Middleware ControlのDADの編集ページにアクセスする必要があります。このページは、Oracle Portalの中間層コンポーネントのmod_plsqlサービスにあります。Cookie名は、「文書、別名およびセッション」ページで設定できます。Cookie名を変更するには、「セッションCookie」セクションの「セッション・クッキー名」フィールドに名前を指定します。
2つの中間層から同じポータルに同時にアクセスする場合や、PL/SQLアダプタ機能に必要なポータルCookieドメインを開く場合は、そのアーキテクチャが使用するすべての中間層サーバーにOracle PortalセッションCookieが送信されるように、Cookieの適用範囲を定義する必要があります。デフォルトでは、セッションCookieのドメインは、その生成元のホストに適用されます。Cookieのパスは「/」に設定されます。
|
注意: これらの変更はポータルで通信量が発生していないときに行ってください。そのようにしないと、セッションCookie名を変更した後、既存のセッションでセッション・エラー(ORA-20000)が発生します。 |
たとえば、Cookieがwww.company.comから生成された場合は、そのCookieのドメインはwww.company.comとなります。しかし、たとえば別のサーバーportal.company.comも、このセッションCookieにアクセスする必要がある中間層のサーバーである場合があります。この場合は、Cookieドメインを広げて、portal.company.comサーバーもこのCookieを参照できるようにする必要があります。
ポータル・セッションCookieの適用範囲を変更するには、次の手順を実行します。
次のディレクトリに移動します。
ORACLE_HOME\portal\admin\plsql\wwc
作成したOracle Portalスキーマがインストールされているデータベースで、ポータル・スキーマとしてSQL*Plusにログインします。例:
sqlplus portal\portal_pwd
次のコマンドを入力します。
SQL> @ctxckupd OracleAS Portal Current Settings for Portal Session Cookie: Cookie Domain : Only send cookie back to originating host:port Set Cookie as Secure: Y Enter the domain for the session cookie: .company.com Should cookie be flagged as secure for HTTPS sessions? (Y/N): N Settings changed to Cookie Domain : .company.com Do not set cookie as secure. (N) SQL>
このコマンドを使用すると、セッションCookieのCookieドメインを設定できます。この例では、Cookieドメインは.company.comに設定されます。
|
注意:
|
Oracle Portalのこのリリースでは、スクリプトctxckupd.sqlに付加的なオプションSet Cookie as Secureが含まれています。
このスクリプトは、デフォルトではORACLE_HOME\portal\admin\plsql\wwcにあります。このスクリプトを実行すると、次のように出力されます。
SQL> @ctxckupd
OracleAS Portal
Current Settings for Portal Session Cookie:
Cookie Domain : Only send cookie back to originating host:port
Set Cookie as Secure: Y
Enter the domain for the session cookie...
Leave blank to scope to originating host:
Should cookie be flagged as secure for HTTPS sessions? (Y/N): N
Settings changed to
Cookie Domain : Only send cookie back to originating host:port
Do not set cookie as secure. (N)
SQL>
Set Cookie as Secureは、リクエストがHTTPS接続を介してのみ渡される場合は、Cookieをサーバーへ返信しなければならないことを意味します。この設定では、セッションCookieを保護する必要がある場合には、必ずセキュアな接続を介して転送されるようになります。デフォルトでは、このオプションはYesに設定されており、ほとんどの配置においてこれで問題ありません。
ただし場合によっては、Set Cookie as SecureオプションをNoに設定しなければならないことがあります。たとえば、HTTPとHTTPSの両方を介してポータルにアクセスし、両方のプロトコルでセッションCookieを共有する場合があります(これは、両者ともデフォルトのポート、つまりHTTPでは80、HTTPSでは443で実行されている場合に可能です)。このような場合には、Set Cookie as SecureがNoに設定されている場合は、HTTPSリクエストを介して生成された同じCookieが、後続のどのHTTPリクエストにも送信されます。
Oracle PortalとOracleAS Single Sign-Onは、他のWebベース・アプリケーションと同様に、セッション管理を行います。セッションはCookieを使用して管理されます。セッション情報は、Oracle PortalスキーマおよびOracleAS Single Sign-Onスキーマの表に格納されます。ユーザーがログアウトすると、セッション情報は非アクティブのマークが設定されます。DBMSジョブは、非アクティブな行をクリーン・アップします。
セッション表には、アクティブのマークが設定された行の数が累計されます。ユーザーがログアウトするかわりにブラウザをシャットダウンしたときは、実際に使用されていない場合でも、その行はアクティブになります。クリーン・アップ・ジョブは、指定された期間を経過したアクティブな行をクリーン・アップします。
Oracle Portalをインストールすると、セッション表(WWCTX_SSO_SESSION$)のセッション・クリーン・アップを実行するDBMSジョブがインストールされます。クリーン・アップ・ジョブは、24時間ごとに実行されるように設定されます。最初にスケジュールされたクリーン・アップは、ジョブのインストールから24時間後に発生します。
ジョブが実行されると、非アクティブなセッションがすべて削除され、さらにアクティブのマークが設定されたセッション(WWCTX_SSO_SESSION$.ACTIVE = 1)のうち、7日間を経過したもの(WWCTX_SSO_SESSION$.SESSION_START_TIME < sysdate - 7)がすべて削除されます。
これらのデフォルト設定を変更するには、ポータル・セッションを管理するOracleAS Single Sign-OnスキーマまたはOracleAS Single Sign-Onセッションを管理するOracle Portalスキーマにあるジョブ管理スクリプトをいくつか実行します。これらのジョブ管理スクリプトは、同じセッション管理インフラストラクチャを利用します。
現在のクリーン・アップ・ジョブ情報を取得するには、次の手順を実行します。
次のディレクトリに移動します。
ORACLE_HOME\portal\admin\plsql\wwc
Oracle PortalスキーマまたはOracleAS Single Sign-Onスキーマがインストールされているデータベースで、そのスキーマの適切なユーザー名とパスワードを使用してSQL*Plusにログインします。
例:
sqlplus portal\portal
次のコマンドを入力して、現在のジョブ情報を取得します。
SQL> @ctxjget
現在インストールされているジョブ情報が、DBMS_JOBパッケージから返されて表示されます。
The session cleanup job is job ID 7381
dbms_job.isubmit(job=>7381,what=>'begin execute immediate''begin
wwctx_sso.cleanup_sessions(p_hours_old => 168); end;''; exception when
others then null; end;',next_date=>to_date('2001-04-17:14:07:20',
'YYYY-MM-DD:HH24:MI:SS'),interval=>'SYSDATE + 24/24',no_parse=>TRUE);
PL/SQL procedure successfully completed.
結果には、実行するプロシージャ、それに渡すパラメータ、次の呼出しが発生する日時が示されています。この例では、1週間(168時間)経過しているアクティブ・セッションをこのジョブでクリーン・アップします。また、このジョブの次回実行予定は2001年4月17日の午後5:14で、それ以降は24時間ごとに実行されます。
削除の対象とするセッションの有効期間を調整したり、クリーン・アップの頻度を変更したりするなど、ジョブの実行を変更する必要がある場合は、ctxjsub.sqlスクリプトを実行し、変更した実行パラメータを送信します。
変更済の実行パラメータを送信するには、次の手順を実行します。
次のディレクトリに移動します。
ORACLE_HOME\portal\admin\plsql\wwc
Oracle PortalスキーマまたはOracleAS Single Sign-Onスキーマがインストールされているデータベースで、そのスキーマの適切なユーザー名とパスワードを使用してSQL*Plusにログインします。例:
sqlplus portal\portal
次のコマンドを入力して、新しいクリーン・アップ・ジョブ情報を送信します。
@ctxjsub <hours_old> <start_time> <time_format> <interval_hours>
表B-1は、ctxjsubパラメータの一覧です。
表B-1 ctxjsubのパラメータ
| パラメータ | 説明 |
|---|---|
|
|
削除の対象とするアクティブ・セッションの有効期間 |
|
|
次のジョブを実行する時刻 |
|
|
|
|
|
クリーン・アップ・ジョブの実行間隔(時間) |
例:
SQL> @ctxjsub 200 '04/17/2001 10:00' 'MM/DD/YYYY HH24:MI' 12
ジョブの情報が、次のように表示されます。
Created path for job id. DBMS_JOB id = 7381 Cleanup job updated. Job ID = 7381 PL/SQL procedure successfully completed.
実行パラメータを変更するためのクリーン・アップ・ジョブ送信スクリプトは、何度でも実行できます。スクリプトを起動するたびに、クリーン・アップ・ジョブのジョブIDに関連付けられているジョブ情報が更新されます。このジョブIDは、プリファレンス・ストアで管理され、ジョブ情報が更新されます。このため、複数のジョブが送信されることがありません。
STARTにstart_timeを指定することもできます。この場合、time_formatパラメータは無視されますが、NOWのようななんらかの値を渡す必要はあります。現在時刻から<interval_hours>の時間間隔でジョブが実行されます。
SQL> @ctxjsub 168 START NOW 24
これにより、インストール時と同じ設定で、ジョブが送信されます。
クリーン・アップ・ジョブをすぐに実行する場合は、ctxjget.sqlをコールして、ジョブIDを取得します。ジョブIDを取得したら、製品スキーマに入っている次のコマンドを発行して、そのジョブを実行できます。
SQL> exec dbms_job.run(7381);
この例では、ctxjget.sqlをコールして返されたジョブIDは7381です。この方法でジョブを実行すると、この手動起動のinterval_hours時間後に、次のジョブが自動的に起動します。このジョブを元のスケジュールで実行するには、ctxjsub.sqlを使用して目的のstart_timeを再送信します。
すべてのOracle Portalページは、実行時間とキャッシュの情報が表示される特殊なモードで実行できます。このデバッグ情報をすべてのページに表示する場合は、appConfig.xmlファイルでParallel Page EngineのshowPageDebugパラメータにtrueを設定します。
選択したいくつかのページとポートレットに関するデバッグ情報を表示する場合は、_debug URLパラメータによってログ・レベルを制御することができます。たとえば、次のOracle Portalページの実行時間の統計を参照するには、次のようにします。
http://abc.com/servlet/page?_pageid=21
これに手動で?_debug=3を挿入します。
次のようになります。
http://abc.com/servlet/page?_pageid=21?_debug=3
_debugの有効な値は、0、1、2、3、4および5です。
1より大きい値を使用すると、リクエストの間にlogmodeの値が増え、すべてのリクエストのログ・メッセージが、ページ・レスポンスへエコーされるようトリガーされることがあります。
|
注意: 0より大きい値を指定すると、 |
表B-2は、_debugの結果の値を表しています。
表B-2 実行時間とキャッシュの_debug値の統計
| 値 | 実行時間とキャッシュの統計 | プロバイダへのフラグの転送 (値1として) | 最小値まで増えるlogmode | ページ・レスポンスへのログ・メッセージの書込み |
|---|---|---|---|---|
|
0 |
はい |
- |
- |
- |
|
1 |
はい |
はい |
- |
- |
|
2 |
はい |
はい |
デバッグ |
はい |
|
3 |
はい |
はい |
リクエスト |
はい |
|
4 |
はい |
はい |
コンテンツ |
はい |
|
5 |
はい |
はい |
解析中 |
はい |
urlDebugModeおよびurlDebugUsersは付加的なパラメータで、これを使用してURLでの_debugの使用を制限できます。詳細は、第5.6.9項「PortalのParallel Page Engineの構成」を参照してください。
ポータル・ページをデバッグ・モードで実行すると、次の統計を表示できます。
図B-1は、_debug=0モードで実行されているページを表しています。
図B-1は、ポートレットに関連する様々な統計をポートレットごとに示しています。各ポートレットは、固有の内部参照識別番号を持ちます。この番号は「ポートレットの情報」サマリーで使用されます。図B-1の左上端のポートレットでは、この番号が6256になっています。
ポートレットごとに次の統計が表示されます。
ポートレット表示時間: (ミリ秒)(ミリ秒間待機)
ポートレットの取得に要する時間とリクエストがキューに入っている時間(ミリ秒)が表示されます。
表示時間ステータス
この統計は非推奨で、今では使用されていません。
XSLTの実行時間: (ミリ秒)
XSLスタイル・シートの取得に必要な時間(ミリ秒)が表示されます(XMLポートレットの場合)。
ポートレット・キャッシュ・ステータス: Web Cache(値)、ファイル・システム・キャッシュ(値)
Oracle Web CacheおよびPortalキャッシュのキャッシュ・ステータスです。
Oracle Web Cacheの有効な値は、次のとおりです。
「MISS」または「NEW [M]」は、Oracle Web Cacheにキャッシュ・ミスが発生していることを示します。ポートレットによって新しいコンテンツが生成されています。
「MISS」または「STALE [G]」は、Oracle Web Cache内の古いコンテンツが原因でキャッシュ・ミスが発生していることを示します。
「HIT [H]」は、Oracle Web Cacheがヒットしたことを示します。
ファイル・システム・キャッシュの有効な値は、次のとおりです。
「HIT_PING」は、妥当性チェック・ベースのポートレットのキャッシュ・ヒットを示します。
「HIT_EXPIRES」は、有効期限ベースのポートレットのキャッシュ・ヒットを示します。
「MISS_STALE」は、キャッシュにあるコンテンツが古いためにキャッシュ・ミスが発生していることを示します。これは、有効期限ベースおよび妥当性チェック・ベースのポートレットに適用されます。
「MISS_NEW」は、キャッシュ・ミスが発生していることを示します。ポートレットによって新しいコンテンツが生成されています。これは、有効期限ベースおよび妥当性チェック・ベースのポートレットに適用されます。
ポートレットがファイル・システム・キャッシュを使用する場合は、前述の情報が表示されます。そうでない場合は、NULLになります。
Oracle Web Cacheがヒットした場合は、コンテンツがOracle Web Cacheから直接提供されるため、ファイル・システム・キャッシュに関する詳細は表示されません。また、ポートレットがOracle Web Cacheを使用しない場合、Web Cache情報は出力されません。
キャッシュから: Web Cache: キャッシュ有効期限(秒)、キャッシュ経過時間(秒)、ファイル・システム・キャッシュ(値)
ポートレットが使用するキャッシュのタイプに基づいて、Oracle Web Cacheとファイル・システム・キャッシュの情報がここに出力されます。
|
関連項目: Oracle Fusion Middleware Oracle Web Cache管理者ガイド |
「キャッシュ有効期限」には、Oracle Web Cacheのポートレット・コンテンツの有効期間(秒)が表示されます。
キャッシュ経過時間には、ポートレット・コンテンツがOracle Web Cacheにキャッシュされている時間(秒)が表示されます。
「File System Cache」には、ファイル・システム・キャッシュから取得された情報が表示されます。つまり、キャッシュ・キーとキャッシュ有効期限が表示されます。キャッシュがヒットした場合は、キャッシュ・レベルと、「HIT_PING」または「HIT_EXPIRES」のキャッシュ・ステータスが表示されます。
キャッシュがヒットしたときは、妥当性チェック・ベースのポートレットの場合はキャッシュ・キー、キャッシュ・レベルおよび「HIT_PING」のキャッシュ・ステータス値が表示され、有効期限ベースのポートレットの場合はキャッシュ有効期限、キャッシュ・レベルおよび「HIT_EXPIRES」のキャッシュ・ステータス値が表示されます。
妥当性チェック・ベースおよび有効期限ベースのポートレットの場合、新しいポートレット・コンテンツが生成されたためにキャッシュ・ミスが発生したときは、「なし」が出力されます。ポートレットには、新しいキャッシュ・キー、キャッシュ有効期限およびキャッシュ・レベルを取得するように通知されます(「キャッシュ・ステータス」: 「MISS_NEW」)。
妥当性チェック・ベースのポートレットの場合、キャッシュ内のコンテンツが失効したためにキャッシュ・ミスが発生したときは、キャッシュに現在入っているキャッシュ・キーとキャッシュ・レベルの値が表示されます。この場合、ポートレットに対して、更新済のキャッシュ・キーとキャッシュ・レベルを取得するように通知されます(「キャッシュ・ステータス」: 「MISS_STALE」)。
有効期限ベースのポートレットの場合、キャッシュ内のコンテンツが失効したためにキャッシュ・ミスが発生したときは、「キャッシュ有効期限」フィールドが「INVALID」になり、キャッシュ・レベルが表示されます。この場合、ポートレットに対して、更新済のキャッシュ有効期限とキャッシュ・レベルを取得するように通知されます(「キャッシュ・ステータス」: 「MISS_STALE」)。
ポートレットから: (キャッシュ・キー)(キャッシュ・レベル)
ポートレットから: (キャッシュ・キー)(キャッシュ・レベル)
ファイル・システムのキャッシュ・キー、キャッシュ有効期限およびキャッシュ・レベルについて、ポートレットから取得された情報です。キャッシュ・ミスが発生し、更新済または新規の値を取得するようにポートレットに通知があると表示されます(「キャッシュ・ステータス」: 「MISS_NEW」または「MISS_STALE」)。Oracle Web Cacheに関連する情報は、このセクションに表示されません。
妥当性チェック・ベースのポートレットの場合、キャッシュがヒットしてpingが正常に終了したとき(キャッシュ内のコンテンツが引き続き有効な場合)、ポートレットは新しいキャッシュ・キーとキャッシュ・レベルを返しません。つまり、キャッシュは引き続き有効であることを示します。この場合、Ping成功と表示されます(「キャッシュ・ステータス」: 「HIT_PING」)。
有効期限ベースのポートレットの場合、キャッシュがヒットしてコンテンツが失効していないときは、ポートレットに対してコンテンツの要求は通知されません。この場合、「Not contacted」が表示されます(「キャッシュ・ステータス」: 「HIT_EXPIRES」)。
次に、様々なキャッシュ・シナリオとその出力例をいくつか示します。ここでは、ページおよびポートレット関連の出力例はあげません。
|
注意: このリリースでは、ページ・ポートレットは、コンテナ・ページ定義とは別のポートレットとしてリクエストされます。そのため、デバッグ出力ではページ・ポートレットごとに、ポートレットとページのキャッシュ情報が表示されます。 |
例B-1 キャッシュ情報のデバッグ出力1
ポートレット・キャッシュ: ファイル・システム・キャッシュ、キャッシュ・タイプ: 妥当性チェック・ベース、ステータス: MISS, STALE
Caching information for portlet: Portlet Cache status: File System Cache:- MISS,STALE From Cache: File System Cache:- Cache Key: 42, Cache Level: USER From Portlet: Cache Key: 44, Cache Level: USER
例B-2 キャッシュ情報のデバッグ出力2
ポートレット・キャッシュ: ファイル・システム・キャッシュ、キャッシュ・タイプ: 有効期限ベース、ステータス: MISS, NEW
Caching information for portlet: Portlet Cache status:File System Cache:- MISS,NEW From Cache: File System Cache:-None From Portlet: Cache Expires: 1, Cache Level: USER
例B-3 キャッシュ情報のデバッグ出力3
ポートレット・キャッシュ: ファイル・システム・キャッシュ、Web Cache、キャッシュ・タイプ: 妥当性チェック・ベースおよび無効化ベース、ステータス: MISS, NEW(ファイル・システム・キャッシュおよびWeb Cache内)
Caching information for portlet: Portlet Cache status: Web Cache:- MISS,NEW [M], File System Cache:- MISS,NEW From Cache: Web Cache:- Cache Expires: 86400 secs, Age in Cache: 0 secs , File System Cache:- None From Portlet: Cache Key: 9.0.2.2.1502:04:18:09:19:56, Cache Level: SYSTEM
図B-1に示したページ上のポートレットと同様に、すべてのページには一意の内部参照識別番号があります。
ページの場合は、次の統計が表示されます。
経過時間: (ミリ秒)
Parallel Page Engine (PPE)で計算されたページを生成するために必要な時間の合計です。ネットワーク・オーバーヘッドによって、ブラウザで実際に生成される時間は、これより長くなる可能性があります。
経過時間は、ページ・メタ待機時間とストリーム時間で構成されます。ページ・メタ待機時間は、HTTP接続でコンテンツを待機した時間です。ストリーム時間は、コンテンツの要素をストリーム化および収集した時間です。ストリーム時間は、次の要素で構成されます。
ページ・メタ時間
ポートレットの完了を待機した時間
コンテンツをストリーム化してブラウザに書き込んだ時間
経過時間は、ページを収集(リクエストを受信してから最後のバイトをブラウザに書き込むまで)するためにかかった時間(ミリ秒)です。
ページ・メタ時間: (ミリ秒)(ミリ秒待機)
ページ・メタデータの取得にかかった時間が表示されます。待機時間(ミリ秒)は、リクエストがキューに入っていた時間です。
ページ・メタ・キャッシュ・ステータス: (Web Cacheの値)、(キャッシュ有効期限: ミリ秒)、(キャッシュ経過時間: ミリ秒)、(ファイル・システム・キャッシュの値)
Oracle Web CacheとPortalキャッシュのキャッシュ・ステータスを表します。Oracle Web Cacheの有効な値は、「MISS, or NEW」および「HIT」です。Portalキャッシュの有効な値は、「HIT, or PING」および「MISS, or STALE」です。Webキャッシュ有効期限と「キャッシュ経過時間」の値は、ミリ秒単位です。
ログイン・メタ時間: (ミリ秒)(ミリ秒間待機)
ログイン・メタ・データの取得にかかった時間(ミリ秒)が表示されます。待機時間は、リクエスト・キュー内にリクエストが入っていた時間(ミリ秒)が表示されます。
ログイン・メタ・キャッシュ・ステータス
前述のページ・メタ・キャッシュ・ステータスと同様に、Web CacheとPortalキャッシュのログイン・メタ・データのキャッシュ・ステータスを表します。
Stream info: (ミリ秒)
ページをストリーム化してブラウザに書き込んだ時間(ミリ秒)を表します。
processing: (ミリ秒)
ストリーム化にかかった時間(ミリ秒)。
write: (ミリ秒)
write行は、複数回繰り返されることがあります。write行は、ストリームに対して各物理バッファが書き込んだことを表します。各バッファが書き込むたびに、1 write行が記録されます。
flush: (ミリ秒)
flushログは、書込みストリームがフラッシュされたことを示します。これは、ネットワーク・ラウンドトリップの数を追跡するために記録されます。
Oracle PortalまたはOracleAS Wirelessのポータル・サービスURLに対するポータルの参照を変更する場合は、スクリプトcfgiasw.plを使用して参照を手動で更新する必要があります。このスクリプト・ファイルは次の場所にあります。
ORACLE_HOME\assistants\opca
パラメータを指定せずにスクリプトを実行すると、次のような使用方法が画面に表示されます。
使用方法:
perl cfgiasw.pl -s portal_schema
-w ias wireless url
-h portal home page url
-c connect_string
表B-3 Oracle Application Server Wireless構成パラメータ
| パラメータ | 説明 |
|---|---|
|
-s |
Oracle Portalデータ・オブジェクトのOracle Databaseスキーマ。
|
|
-w |
Oracle Portalに対するモバイル・リクエスト用のOracle Application Server WirelessゲートウェイのURL。このパラメータは必須です(デフォルトはなし)。このパラメータの値は、二重引用符で囲む必要があります。 |
|
-h |
Oracle Portalホーム・ページのURL。これは、Oracle Portal中間層の文字セットを特定するためにポータル内で使用されます。この情報は、Oracle Application Server Wirelessサービスを作成するときに必要です。このパラメータは必須ではありません(デフォルトはなし)。このパラメータの値は、二重引用符で囲む必要があります。 |
|
-c |
データベースに対する接続文字列(デフォルトはなし)。 |
|
注意:
|
ホストされていないPortalでは、OracleAS WirelessのPortalサービスのURL参照を、「グローバル設定」ページの「モバイル」タブで設定できます。ただし、Oracle Portalホーム・ページのURLは例外で、これはcfgiaswスクリプトでしか設定できません。
このスクリプトは、Oracle Portalで、OracleAS WirelessのPortalサービスのURLおよびOracle Portalホーム・ページのURLの両方に対する参照を設定する場合に使用します。これは、ホストされた環境でURL参照の設定に使用でき、すべてのサブスクライバに影響を与えます。この情報はサブスクライバごとに個別に構成されないためです。例:
perl cfgiasw.pl -s portal -c portal_db -w "http://<iaswhost>:<port>/ptg/rm?PAoid=$wireless_service_id"
この例では、モバイル・デバイスが、Oracle Application Server Wireless サーバーの仲介なしでOracle Portalに対してリクエストを直接作成すると、Oracle Portalによってクライアントがここで指定されたURLにリダイレクトされます。このURLは、Oracle Application Server WirelessサーバーのOracle PortalのサービスのURLで、次の書式になります。
http://<host>:<port>/ptg/rm?PAoid=<service_id>
この設定が空白の場合は、Oracle Portalに対して直接作成されたモバイル・クライアントのリクエストは、リクエストがサポートされていないことを示すHTTPステータスを受け取ります。
Oracle Portalで他のモバイル設定を構成する場合は、第5.7項「Oracle Portalでのモバイル・サポートの構成」を参照してください。
Oracle Portalで使用されるキャッシュ・キーは、多数のコンポーネントによって構成されています。これらのコンポーネントの1つはURLに、別のコンポーネントはOracleAS WirelessヘッダーであるX-Oracle-Device.Classに基づいています。これらのコンポーネントにより、使用するモバイル・デバイスのクラスに基づいてポートレット・コンテンツがキャッシュされます。デバイスのクラスには、pcbrowser、pdabrowser、microbrowserなどがあります。
デバイスのクラスではなく、特定のデバイス名に基づいてポートレット・コンテンツをキャッシュできます。これを行うには、キャッシュ・キーのデバイス・コンポーネントのX-Oracle-Device.ClassヘッダーをX-Oracle-Device.Nameヘッダーに置き換える必要があります。
Oracle Portalが、X-Oracle-Device.Nameヘッダーの値に基づいてキャッシュされたポートレット・コンテンツと正常に動作するには、次の作業が必要です。
Oracle Portalがこのヘッダーを使用できるようにします。実行手順は、第B.7.1項「portal_dads.confファイルへのPlsqlCGIEnvironmentListパラメータの追加」を参照してください。
キャッシュを無効にするか、Oracle PortalがX-Oracle-Device.Nameヘッダーに基づいてコンテンツをキャッシュできるように構成します。Oracle PortalがX-Oracle-Device.Nameヘッダーに基づいてポートレット・コンテンツをキャッシュできるように構成するには、次の作業を実行します。
|
関連項目: ポータル・コンテンツのキャッシュを無効にする手順は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。 |
Oracle PortalがX-Oracle-Device.Nameヘッダーを使用できるようにするには、新しいパラメータPlsqlCGIEnvironmentListをOracle Fusion Middlewareインスタンスのportal_dads.confファイルに追加する必要があります。portal_dads.confファイルを編集するには、次の手順を実行します。
次のディレクトリにあるportal_dads.confファイルを開きます。
DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration
次のエントリをファイルに追加します。
PlsqlCGIEnvironmentList HTTP_X_ORACLE_DEVICE_NAME
portal_dads.confファイルを保存します。
|
注意: portal_dads.confファイルは、手動で編集することもできますが、Application Server Controlを使用することをお薦めします。これを行うには、Fusion Middleware Controlを使用して、第A.2項「DAD構成ファイル(portal_dads.conf)」に説明されている手順に従ってください。 手動で |
次のコマンドを実行してOracle HTTP Serverを再起動します。
INSTANNCE_HOME\bin\opmnctl restartproc type=OHS
モバイル・デバイスを使用してOracle Portalにアクセスすると、コンテンツは使用しているモバイル・デバイスに基づいてレンダリングされます。また、キャッシュの容量も増えます。
Oracle PortalがX-Oracle-Device.Nameヘッダーを使用できるようにするには、cfgxodnc.plスクリプトをonモードで実行します。このスクリプトは次の場所にあります。
Oracle_HOME\assistants\opca
使用方法:
perl cfgxodnc.pl -s portal_schema
-c portal_connect_string
-on|-off
このスクリプトを実行するには、すべてのパラメータを指定する必要があります。
表B-4 cfgxodncスクリプトのパラメータ
| パラメータ | 説明 |
|---|---|
|
-s |
Oracle Portalデータ・オブジェクトのOracle Databaseスキーマ。 デフォルトは |
|
-c |
データベースに対する接続文字列(デフォルトはなし)。 |
|
-on/-off |
キャッシュ・キーで |
|
注意: Oracle Fusion Middlewareのインストールの一部として入手できるPerlバージョンを使用してください。パス変数は次のように設定します。 Windowsの場合: PATH ORACLE_INSTANCE\perl\bin\ SolarisまたはLinuxの場合: PATH ORACLE_INSTANCE/perl/bin |
|
注意: cfgxodnc.plスクリプトの実行時、パスワードの入力を求められます。スクリプトの実行を続けるには、ポータル・スキーマのパスワードを指定します。 |
cfgxodnc.plスクリプトを使用してX-Oracle-Device.Nameヘッダーを有効にする例を次に示します。
perl cfgxodnc.pl -s PORTAL -c portal_database -on
X-Oracle-Device.Nameヘッダーをキャッシュ・キーのデバイス・コンポーネントで使用すると、キャッシュ・サイズは増加します。使用するヘッダーをX-Oracle-Device.Classに戻すと、キャッシュ・サイズは減少します。
キャッシュ・キーのデバイス・コンポーネントで使用するヘッダーをX-Oracle-Device.Classに戻すには、cfgxodnc.plスクリプトをoffモードで実行します。
キャッシュ・キーの作成時にデバイス・クラスのかわりにデバイス名を使用するには、次のように、appConfig.xmlファイルを編集してuseDeviceNameCacheKeysを設定します。
次のディレクトリにあるappConfig.xmlファイルを開きます。
DOMAIN_HOME\config\fmwconfig\servers\WLS_PORTAL\applications\portal\configuration
次のエントリをファイルに追加します。
useDeviceNameCacheKeys
appConf.xmlファイルを保存します。
Oracle HTTP ServerとWLS_PORTALを再起動します。
Oracle HTTP ServerとWLS_PORTALのコンポーネントの再起動の詳細は、第5.6.3項「Fusion Middleware Controlを使用したポータル・コンポーネントの停止および起動」を参照してください。
デバイス名に基づいて新しいキャッシュ・キーを作成するには、Oracle Web CacheとOracle Portalファイル・システム・キャッシュの両方で、キャッシュされた全データを消去する必要があります。Oracle Web Cacheでキャッシュされたデータの消去については、第6.7.3項「WLSTを使用したPortalのWeb Cache設定の構成」を参照してください。ファイル・システム・キャッシュでキャッシュされたデータの消去については、第5.6.8項「ポータル・キャッシュの消去」を参照してください。
すべての新しいカテゴリ・ページまたはパースペクティブ・ページがエラーなしで作成され、すべての既存のカテゴリ・ページまたはパースペクティブ・ページに、関連付けられたアイテムおよびページが予想どおりに表示されるように、カテゴリおよびパースペクティブ・スクリプトを実行する必要があります。
必要なスクリプトは、次のとおりです。
ORACLE_HOME\portal\admin\plsql\wws\pstdefin.sql ORACLE_HOME\portal\admin\plsql\wws\pstpgshw.sql ORACLE_HOME\portal\admin\plsql\wws\pstundef.sql ORACLE_HOME\portal\admin\plsql\wws\pstpgcre.sql ORACLE_HOME\portal\admin\plsql\wws\pstprcpg.sql
これらのスクリプトを実行するには、次の手順を実行します。
現在のカテゴリまたはパースペクティブのテンプレートを削除します。
ポータル・スキーマ・ユーザーとしてSQL*Plusを使用して、Oracle Portalに接続します。
pstdefin.sqlファイルを次の情報を使用して構成します。
ページ・グループ情報。単一のページ・グループ、複数のページ・グループ、またはすべてのページ・グループのページを再作成できます。
ページ情報。カテゴリ・ページまたはパースペクティブ・ページのみ、あるいはその両方を再作成できます。
これらの設定の説明は、pstdefin.sqlファイルにあります。必要に応じて、スクリプトpstpgshw.sqlを使用して情報をOracle Portalから取得し、pstdefin.sqlファイルを構成します。
スクリプトpstpgcre.sqlを実行して変更内容を適用します。例:
SQL> @pstpgcre.sql
ページ・グループにテンプレートが存在する場合に、新しいページを作成すると、そのテンプレートに基づいて新しいカテゴリ・ページまたはパースペクティブ・ページが作成されます。スクリプトの実行前にテンプレートを削除した場合、またはテンプレートが存在しない場合、ページ・グループに新しいテンプレートが作成され、そのテンプレートに基づいて新しいページが作成されます。
プリファレンス・ストアとは、Oracle Portalの使用時、ユーザー・プリファレンスのデータ、ポートレットおよびプロバイダの設定、ポートレットのデータなどの情報を格納するメカニズムです。現在、PDK-JavaにはDBPreferenceStoreとFilePreferenceStoreの2つのPreferenceStoreが実装されています。DBPreferenceStoreにはJDBC対応のリレーショナル・データベースを使用するデータが保存され、FilePreferenceStoreにはファイル・システムを使用するデータが保存されます。
このユーティリティを使用すると、異なるプリファレンス・ストア間で既存のデータを移行したり(たとえば、FilePreferenceStoreからDBPreferenceStoreへ)、以前のリリースのPDK-JavaおよびOracle Portalをアップグレードすることによって、既存のポートレットで生成されたポートレット・プリファレンス・データを管理できます。このツールでのアップグレードによって、ロケール固有のポートレット・プリファレンスの既存データで、最新のPDKおよびOracle Portalリリースに対応したネーミング形式を使用できるようになります。
すでにOracleAS PDKをインストールしている場合は、プリファレンス・ストア移行/アップグレード・ユーティリティを使用してプリファレンス・ストアに保存されている情報を管理できます。このユーティリティはpdkjava.jarファイルにあります。
プリファレンス・ストア移行/アップグレード・ユーティリティの完全な構文を次に示します。
java -classpath $ORACLE_HOME/portal/jlib/pdkjava.jar; $ORACLE_HOME/portal/jlib/ptlshare.jar oracle.portal.provider.v2.preference.MigrationTool
|
注意:
|
プリファレンス・ストア移行/アップグレード・ユーティリティは、次のいずれかのモードで実行できます。このコマンドの実行時に-modeで選択します。
アップグレード・モード
移行モード
|
注意: このユーティリティの実行後、最新のプリファレンス・ストア情報が使用されるように、WLS_PORTALとOracle HTTP Serverを再起動します。 |
アップグレード・モード
使用されるネーミング形式がOracle Portalの現在のバージョンおよび指定されているlocalePersonalizationLevelの設定と対応するようにプリファレンス・ストア内の既存のロケール固有プリファレンスを変更して既存のデータをアップグレードするには、アップグレード・モード(fileまたはdb)を使用します。
表B-5に、このユーティリティのアップグレード・モードを示します。
表B-5 ユーティリティのアップグレード・モード
| モード | 説明 |
|---|---|
|
|
|
|
|
|
アップグレード・モード(fileまたはdb)は、次のようなシナリオで使用します。
OracleAS PDK 9.0.4.0.0以前のリリースからアップグレードする場合で、localePersonalizationLevelとしてデフォルトのlanguageの設定を使用して既存のポートレットを使用する場合(以前のリリースではデフォルト設定はlocale)。
Oracle Portal 9.0.2.0.0以前のリリースからアップグレードする場合で、localePersonalizationLevelの設定がlocaleである既存のポートレットを使用する場合(Oracle Portalでは現在、一部のロケール名が変更されているため、既存のデータには再マッピングが必要なものもあります)。
既存のポートレットのlocalePersonalizationLevelの設定をlocaleからlanguageに変更する場合。またはその反対に変更する場合。
アップグレード・モード(fileまたはdb)を使用する場合、アップグレード先のlocalePersonalizationLevelを指定する(languageまたはlocale)には-remapオプションを使用する必要があります。また、-countriesオプションを使用して、ISO国コードに優先順位を付けたリストを指定できます。このリストは、複数の国のプリファレンスを再マップして競合が発生した場合のプリファレンスの優先順位を示します。たとえば、コマンドで-remap language -countries GB,USと指定すると、プリファレンス・ストアでアメリカ英語のプリファレンスとイギリス英語のプリファレンス(en_USとen_GB)が検出された場合、イギリス英語のプリファレンスが英語全体のプリファレンス(en)として再マッピングされます。
|
注意: このユーティリティを |
移行モード
ソースのプリファレンス・ストアからターゲットのプリファレンス・ストアにデータをコピーするには、移行モード(filetodb、filetofile、dbtofile、または dbtodb)を使用します。このモードでユーティリティを実行すると、すべてのポートレット定義のプリファレンス・ストアが更新されます。
表B-6に、このユーティリティの移行モードを示します。
表B-6 ユーティリティの移行モード
| モード | 説明 |
|---|---|
|
|
データを |
|
|
別の場所にある |
|
|
データを |
|
|
別のデータベース表の |
移行モード(filetodb、filetofile、dbtofile、またはdbtodb)を使用するとき、-remapおよび-countriesオプションを使用して、ロケール固有のプリファレンスがデータの移行中に適切に再マップされてアップグレードされるよう指定できます。
このユーティリティのその他のオプションは、アップグレードまたは移行プロセスにおいて、プリファレンス・ストアのプロパティを指定するために使用します。これらのオプションは、provider.xmlに指定した、プリファレンス・ストア用に記述したタグと対応する必要があります。プリファレンス・ストアに設定できるプロパティの詳細は、次の場所にある『PDK-Java XML Provider Definition Tag Reference』を参照してください。
http://www.oracle.com/technology/products/webcenter/files/pdk_downloads/xml_tag_reference_v2.html
接頭辞が-pref1のプロパティは、ソース・プリファレンス・ストアのプロパティです。アップグレード・モード(fileまたはdb)では、このストアが唯一のプリファレンス・ストアです。たとえば、-pref1UseHashing true -pref1RootDirectory j2ee/home/applications/jpdk/jpdk/WEB-INF/providers/sampleと指定すると、ソースFilePreferenceStoreのuseHashingプロパティとrootDirectoryプロパティが設定されます。
|
注意: Portal Development Kitをインストールした場合、ソース・プリファレンス・ストアの場所は次のとおりです。
|
基本の移行モードのいずれかの場合、接頭辞が-pref2のプロパティは、ターゲット・プリファレンス・ストアのプロパティを指定します。たとえば、-pref2User portlet_prefs -pref2Password portlet_prefs -pref2URL jdbc:oracle:thin:@myserver.mydomain.com:1521:mysidを指定すると、ターゲットのDBPreferenceStoreにデータベース接続の詳細が設定されます。
次にUNIXでのユーティリティの使用例を示します。
java -classpath $ORACLE_HOME/portal/jlib/pdkjava.jar; $ORACLE_HOME/portal/jlib/ptlshare.jar oracle.portal.provider.v2.preference.MigrationTool -mode file -remap language -countries GB,US -pref1UseHashing true -pref1RootDirectory $DOMAIN_HOME/servers/WLS_PORTAL/tmp/_WL_user/jpdk/dir/war/WEB-INF/providers java -classpath $ORACLE_HOME/portal/jlib/pdkjava.jar; $ORACLE_HOME/portal/jlib/ptlshare.jar; $ORACLE_HOME/jdbc/lib/ojdbc6.jar oracle.portal.provider.v2.preference.MigrationTool -mode filetodb -remap locale -countries AR,MX -pref1UseHashing true -pref1RootDirectory $DOMAIN_HOME/servers/WLS_PORTAL/tmp/_WL_user/jpdk/dir/war/WEB-INF/providers -pref2User portlet_prefs -pref2Password portlet_prefs -pref2URL jdbc:oracle:thin:@myserver.mydomain.com:1521:mysid
スキーマ検証ユーティリティ(SVU)は、ポータル・スキーマ内のデータの不整合をクリーンアップおよびレポートするために使用します。SVUでは、ページ・グループ・オブジェクトおよびDBプロバイダ・オブジェクトが検証されます。
SVUの使用上の利点を次にいくつか示します。
これにより、ソースとターゲットのPortalインスタンス間のデータ不整合を原因とするOracle Portalインポートの失敗が防止されます。
Portalのバージョンをアップデートするためにパッチを適用する場合に、Oracle Portalパッチの失敗を防止します。
スキーマ検証ユーティリティは、次のようなシナリオで実行します。
Oracle Portalのエクスポートおよびインポート処理時。
ユーザー・インタフェースの使用時に、ORA-1403、ORA-1422、ORA-4088などのエラーが表示された場合。
検証の実行方法およびSVUスクリプトsvu_rept.sqlのダウンロード方法の詳細は、Oracle Metalink(http://metalink.oracle.com)にログインし、スキーマ検証ユーティリティに関する記事を参照してください。この記事のドキュメントIDは286619.1です。
スキーマ検証ユーティリティには、次の2種類の実行方法があります。
Oracle Portalのエクスポートとインポートでは、SVUはREPORTモードで自動的に実行されます。デフォルトでは、エクスポートとインポート時に、次の段階でバックグラウンドで実行されます。
エクスポート前 - ソース・インスタンスに存在するデータの不整合をクリーンアップします。
インポート前 - ターゲット・インスタンスに存在するデータの不整合で、インポート処理に影響を与える可能性のあるものをクリーンアップします。
インポート後 - インポート処理によって生じた可能性のあるデータの不整合をクリーンアップします。
SVUで不整合が報告されると、エクスポート処理やインポート処理は失敗し、ステータスはABORTになります。エクスポート処理またはインポート処理が中断されると、エラー・メッセージが表示され、不整合の詳細と「クリーンアップ・モード」リンクが示されます。このリンクをクリックするとSVUがCLEANUPモードで起動され、エクスポート処理またはインポート処理を完了できるようになります。
データ不整合がレポートまたは検出された場合、SVUをスタンドアロン・モードで実行できます。このユーティリティをスタンドアロン・モードで実行するには、スクリプトsvu_rept.sqlをOracle Portalスキーマ所有者(PORTAL)として実行します。
SQL> @svu_rept.sql
このスクリプトを実行するモードとタイプの指定が求められます。
モード:
REPORT - データの不整合をレポートします。
CLEANUP - データの不整合をクリーンアップします。
タイプ:
ALL - ページ・グループ・オブジェクトとDBプロバイダ・オブジェクトの両方を検証します。
PAGEGROUP - ページ・グループ・オブジェクトのみを検証します。
DBPROV - DBプロバイダ・オブジェクトのみを検証します。
モードとタイプを入力したら、ログ・ファイルを保存するパスの指定が求められます。ここではc:\temp\svu.logのようにパスを入力します。SVUをまずREPORTモードで実行してから、CLEANUPモードで実行します。
|
重要
|
