プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle WebCenter Sitesの管理
12c (12.2.1.2.0)
E82736-03
目次へ移動
目次
前
前 		次
次

37 WebCenter Sitesのデータベース表

WebCenter Sitesデータベースの動的テーブルは、管理不可能なサイズに拡大する可能性があります。管理者は、WebCenter Sitesデータベースを効率的に管理する必要のない、そのようなテーブルから非アクティブなデータを削除できます。

トピック

37.1 キャッシュ管理の表

WebCenter SitesではCacheManagerが提供されます。これは、WebCenter Sitesのページ・キャッシュとSatellite Serverのキャッシュの両方を管理するページ・キャッシング・ユーティリティです。

キャッシュされたページを期限切れにする必要があるのは、有効期限が切れた場合となんらかの方法でそのページが参照するアセットが変更された場合の両方なので、CacheManagerは、有効期限だけでなく、キャッシュ内に格納されているページとページレットの間に存在する依存性を追跡する必要があります。この情報は、SystemPageCache表とSystemItemCache表に格納されます。

どのWebCenter SitesシステムもCacheManagerを使用します。つまり、これらの表はシステムの開発時、管理時、配信時に動的に拡大します。次の表は、キャッシュ追跡表がどのように増大するかを示しています。

表37-1 キャッシュ管理の表

表 行数

SystemPageCache

キャッシュされたページごとに1行。

ページの有効期限が切れたら、行は削除されます。

SystemItemCache

SystemPageCache表にあるキャッシュされたページによって参照されるアセット、ページレット、その他のアイテムごとに1行。たとえば、キャッシュされたページが、3つの記事アセットに対するアソシエーションを持つページ・アセットから作成されたものである場合、そのキャッシュされたページに対して4行が存在することになります。

37.2 承認システムの表

WebCenter Sitesの承認システムは、承認された各アセット、その承認されたセットの他のアセットに対する依存性、アセットの承認ターゲットを追跡します。この情報は、ApprovedAssets表とApprovedAssetDeps表に格納されます。

これらの表は、管理システム上で非常に大きくなる可能性がありますが、配信システムでは使用されません。次の表は、承認システムの表がどのように増大するかを示しています。

表37-2 承認システムの表

表 行数

ApprovedAssets

承認ターゲットのそれぞれについて、承認されたアセットごとに1行。つまり、1つのアセットが2つのターゲットに対して承認された場合、表にはこのアセットに対して2行が存在することになります。

ApprovedAssetDeps

承認ターゲットのそれぞれについて、承認された各アセットの依存性ごとに1行。

たとえば、承認されたアセットが他の4つのアセットに依存している場合、この表には4行が存在することになります。その同じアセットが2つのターゲットに対して承認された場合、各ターゲットの各依存性ごとに1行が存在することになります。

37.3 パブリッシュ・システムの表

WebCenter Sitesのパブリッシュ・システムは、アセットのパブリッシュされた日時とパブリッシュ先を追跡します。この情報は、PubKey表とPublishedAssets表に格納されます。

WebCenter Sites管理システムのアセット数が増加すると、これらの表の行数も増加します。次の表は、パブリッシュ・システムの表がどのように増大するかを示しています。

表37-3 パブリッシュ・システムの表

表 行数

PubKey

ミラー・パブリッシュの場合: ターゲット宛先のそれぞれについて、ミラーリングされるアセットごとに1行。

エクスポート・パブリッシュの場合: エクスポート時に作成されるページごとに1行。つまり、14のアセットが1ページにレンダリングされた場合、この表には、(14行ではなく)アセットのグループ全体に対する1行のみが存在することになります。

PublishedAssets

ミラー・パブリッシュの場合: ターゲット宛先のそれぞれについて、ミラーリングされるアセットごとに1行。

エクスポート・パブリッシュの場合: エクスポートされるアセットごとに1行。前述の例を続けるなら、14アセットが1ページにレンダリングされた場合、表にはそのページについてアセットごとに1行が存在することになります。

37.4 ワークフローの表

ワークフロー・システムは、あらゆる時点でワークフロー・プロセスに関与したすべてのアセットを追跡します。この情報は、Assignment表とWorkflowObject表に格納されます。

ワークフロー・プロセスに配置されたアセット数が増加すると、これらの表の行数も増加します。次の表は、ワークフローの表がどのように増大するかを示しています。

表37-4 ワークフローの表

表 行数

Assignment

ワークフローの割当てごとに1行。たとえば、ワークフロー・プロセスの過程で1つのアセットが4人のユーザーに割り当てられた場合、表にはそのアセットについて4行が存在することになります。

これらの行は、そのアセットに対してワークフロー・プロセスが完了しても削除されません。

WorkflowObjects

ワークフロー内のアセットごとに1行。

アセットがワークフローを離れると、この行は削除されます。

37.5 ベーシック・アセットの表

ベーシック・アセット・タイプには、1つのプライマリ・ストレージ表があります。たとえば、articleアセット・タイプのプライマリ・ストレージ表の名前はArticleで、HelloArticleアセット・タイプのプライマリ・ストレージ表の名前はHelloArticleになります。

1つのタイプのアセットの数が増加すると、そのタイプのアセットを保持している表のサイズも増大します。ベーシック・アセットのプライマリ・ストレージ表には、そのタイプのアセットごとに1行が存在しています。

37.6 フレックス・アセットの表

フレックス・ファミリ内のアセット・タイプには、それぞれ複数のデータベース表があります。非常に大きくなる可能性のあるフレックス・ファミリ内の3つのタイプの表は次のとおりです。

  • フレックス・アセット・タイプのプライマリ・ストレージ表。たとえば、avisportsサンプル・サイトで、articleという名前のアセット・タイプのプライマリ・ストレージ表の名前はAVIArticleになります。

  • フレックス・アセットまたはフレックス親アセット・タイプの_AMap表。(例: AVIArticle_AMap。)

  • フレックス親アセット・タイプの_Group表。(例: ArticleCategory_Group。)

  • フレックス・アセット・タイプの_Mungo表。(例: AVIArticle_Mungo。)

  • フレックス親アセット・タイプの_Mungo表。(例: ArticleCategory_Mungo。)

  • Mungo_Blobs表。

次の表は、フレックス・アセットの表がどのように増大するかを示しています。

表37-5 フレックス・アセットの表

表 行数

FlexAssetType

(例: AVIArticle)

このタイプのすべてのアセットに対してアセットごとに1行。

FlexAssetType_AMap

(例: AVIArticle_AMap)

そのタイプのアセットそれぞれについて、(属性値が継承されたものでも、直接割り当てられたものでも)属性値ごとに1行。

FlexAssetType_Group

(例: ArticleCategory_Group)

フレックス親アセットとフレックス・アセットの間の親子関係ごとに1行(親の親、さらにその親などの関係を含む)。

FlexAssetType_Mungo

(例: AVIArticle_Mungo)

このタイプの各アセットのすべての属性値に対して属性値ごとに1行。

場合によっては、この等式の結果が1000万行を超えることもあります。

FlexParent_Mungo

(例: ArticleCategory_Mungo)

このタイプのすべての親アセットのすべての属性値に対して属性値ごとに1行。

Mungo_Blobs

blobタイプの属性に対して保存されたすべての属性値に対して属性値ごとに1行。

37.7 訪問者の表(Engage)

Oracle WebCenter Sites: Engageは訪問者情報をキャプチャして、訪問者データ表に格納します。これらの表には訪問者のセッションIDなどの情報が格納されており、これによって、以前のセッションや、収集しているデータを表す属性の値にリンクすることができます。

オンライン・サイトを訪問する訪問者の数が増加すれば、これらの表の行数も増加します。次の表は、訪問者の表がどのように増大するかを示しています。

表37-6 Engageの訪問者の表

表 行数

scratch

訪問者に対して作成される訪問者コンテキスト・セッション・オブジェクトごとに1行。

訪問者コンテキスト・セッション・オブジェクトとは、プロモーション・リスト、セグメント・リスト、ショッピング・カートなどのようなものです。各セッションの各訪問者に対して、少なくとも5行がこの表に追加されます。

VMVISITOR

各ブラウザ・セッションの訪問者ごとに1行。

Engageでは、各セッションの各訪問者に対して一意の訪問者IDが作成されます。

VMVISITORALIAS

データベース中心の訪問者追跡では、返される訪問者についても、各ブラウザ・セッションの訪問者ごとに1行が作成されます。この方法では、訪問ごとに1行が作成されます。

メモリー中心の訪問者追跡では、返される訪問数に関係なく、訪問者ごとに1行が作成されます。

注意: 1行の中には、別名の名前/値のペアと、セッションをマークする訪問者ID (VMVISITORにもリストされているもの)が保持されています。

VMVISITORSCALARVALUE

保存されている訪問者の属性値(バイナリ・タイプの属性を除く)ごとに1行。

注意: メモリーベースの訪問者追跡が有効である場合は、この表には値が移入されません。

VMVISTORSCALARBLOB

保存されているバイナリ・タイプの訪問者属性値(スカラー・オブジェクトとも言われる)ごとに1行。

注意: メモリーベースの訪問者追跡が有効である場合は、この表には値が移入されません。

VMz ------------

動的に生成される表で、履歴属性の値が保存されたときに作成されます。

Engageによって履歴タイプごとに1つの表が作成され、この表には履歴タイプのレコードが保存されるたびに1行ずつ追加されます。

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

37.7.1 属性の表の管理

属性値を保持している表は急速に拡大する可能性があるので、非アクティブなデータを定期的にこの表から消去する必要があります。

これらの表から非アクティブなデータを削除するには、次に示すEngage XMLオブジェクト・メソッドか、これと同等のJSPを使用します。

<VDM.FLUSHINACTIVE STARTDATE="cutoffDate"/>

非アクティブな訪問者データとは、最新と考えられるデータに別名を介して接続されていない訪問者IDでマークされているデータのことです。使用するEngageに対してカットオフ日付(STARTDATE)を設定します。その日付より前の訪問者レコードはすべて、その日付より後に記録されたデータと別名を介してリンクされていないかぎり、以前リストされた訪問者表から削除されます。

VDM.FLUSHINACTIVEタグの使用方法は複数あります。例:

  • タグを呼び出してカットオフ日付の入力を求める管理エレメントを作成できます。

  • なんらかのパラメータに基づいてカットオフ日付を計算する等式をこのエレメントに指定して、このエレメントを定期的にスケジュールされた時間に自動的なイベントとして実行するように設定できます。自動的なイベントとして設定するには、WebCenter SitesのAPPEVENTタグ(kronのように機能する)を使用します。このタグの詳細は、Oracle WebCenter Sitesリファレンス・タグ・リファレンスと『Oracle WebCenter Sitesでの開発』のシステム表への追加に関する項を参照してください。

STARTDATEパラメータに渡す値はイベント内の時間にする必要があります。WebCenter SitesのDATE.CONVERTタグを使用して、使用するイベント日付の値を取得できます。例:

<DATE.CONVERT VARNAME="flushtime" 
   YEAR="four digit year" MONTH="number in the range 1-12"
   DAY="number in the range 1-31" 
   [HOUR="number in the range 0-11 where 0 is midnight" AMPM="am
   or pm" MINUTE="number in the range 0-59" TIMEZONE="timezone"]/>
<VDM.FLUSHINACTIVE STARTDATE="Variables.flushtime"/>

これらのタグの詳細は、Oracle WebCenter Sitesリファレンス・タグ・リファレンスを参照してください。

37.7.2 セッション・オブジェクト(Scratch)表の管理

各セッションの各訪問者に対して少なくとも5つのセッション・オブジェクトが格納されているため、scratch表は急速に拡大する可能性があります。各オブジェクトにはタイムスタンプがあるので、それぞれのタイムスタンプに基づいて、古いオブジェクトを定期的に消去する必要があります。

scratch表から古いセッション・オブジェクトを削除するには:

  • 削除するには、次に示すEngage XMLオブジェクト・メソッドか、これと同等のJSPを使用します。

    <SESSIONOBJECTS.FLUSH TIMESTAMP="cutoffTime"/>

    セッション・オブジェクトにはカートが含まれているので、そのカートが放棄されたと見なされる時点を表すカットオフ時刻を設定する必要があります。

    STARTDATEパラメータに渡す値はイベント内の時間にする必要があります。WebCenter SitesのDATE.CONVERTタグを使用して、使用するイベント日付の値を取得できます。たとえば、次の項に示すVDM.FLUSHINACTIVEタグのコード例を参照してください。

    これらのタグの詳細は、Oracle WebCenter Sitesタグ・リファレンスを参照してください。

    注意:

    このオブジェクト・メソッドはVMSCALARBLOB表には影響しません。つまり、バイナリ・タイプの訪問者属性(スカラー・オブジェクト)として格納したカートは削除されません。

37.7.3 不要な.classファイルの削除

EngageはJavaベースのアプリケーションなので、イベントが発生するたびにJavaの.classファイルが生成されます。

  • セグメント、推奨またはプロモーションが作成されたとき。

  • 関連アイテムの推奨用に製品が構成されたとき。

  • セグメント、推奨またはプロモーションがEngageによって計算または起動されたとき。

通常、古い.classファイルは、セグメント、推奨、プロモーションまたは製品が更新されて新しい.classファイルによって置き換えられたときに削除されます。ただし、更新済バージョンがパブリッシュされたときに、セグメント、推奨、製品またはプロモーションが使用中の場合、古い.classファイルはロックされているために、Engageによって自動削除されません。

古い.class ファイルが積み重なってディスクを満たし、メモリーを占拠する可能性があります。したがって、実行中の開発作業の量と配信システムのパブリッシュ頻度に基づいて、これらの.classファイルを定期的にスケジュールされた時間に手動で削除する必要があります。

古い.classファイルを削除するには、次の手順を実行します。

  1. プロパティ管理ツールを使用して、vis.genclasspathプロパティを調べ、パラメータによって指定されているディレクトリ名をメモします。これは、Engageによって.classファイルが格納されているディレクトリです。

  2. サイトに動きがないときに、実行中のJREランタイムの各インスタンスをシャットダウンして再起動します。このプロセスによって、JREランタイムによってロックされた古い.classファイルが解放されます。

  3. 任意のファイル管理ツールを使用して、.classファイルを保持しているディレクトリに移動し、このディレクトリのコンテンツを削除します。

必要なときには、Engageにより、どのような.classファイルでも再生成されます。

前
前 		次
次
目次へ移動
目次