Oracle^® Marketing Segmentation Guide > Configuring Marketing Module Metadata > Setting Up Marketing Segmentation Metadata >

About Setting Up Cache for Target Levels

Marketing Server Cache has the following distinct properties:

• Criteria blocks are not cached by default. Users have to explicitly select the criteria blocks that they want to cache. This behavior is different than that of the Oracle BI Server cache. The exception is with segment trees where segment and remainder nodes are automatically marked for caching. In general, these nodes make good candidates for caching because the SQL to compute these nodes are usually expensive.
• Marketing Server Cache is temporary and it expires after a certain time. This is unlike the Oracle BI Server cache that is recycled based on disk size limit specified. The expiration time is configurable and is set in the following file:

  SiebelAnalyticData\Web\Config\instanceconfig.xml file

  The name of this parameter is MarketingCacheMaxExpireMinutes. When this value is not set, the default value used by the Marketing Server is 24 hours.

• Marketing Server Cache is stored in multiple tables with a fixed schema for each target level, unlike the Oracle BI Server cache that is stored in a file system.
• Marketing Server Cache entries are managed through the Administration link in the Oracle BI user interface, unlike the Oracle BI Server cache that is managed through the Administration Tool. These entries can be found under the Database Cache section after you click Manage Marketing Jobs link.
• Caching of the same entity with different sampling factors creates different cache entries for each sampling factor for which the counts were run. If a criteria block was cached for a 20 percent sample and then, if counts are run for a sampling factor that is different, cache is not used.
• When updating counts, you can select the Refresh Query Cache property to make sure that you only query against the latest data. Any cache entries that would have been reused are deleted during this job.

Managing Marketing Cache

If you purchased the Siebel Data Warehouse version 7.7.1, the cache tables have been preconfigured and appropriately modeled in the Administration Tool. Use this topic to support users, troubleshoot issues, and maintain the cache tables. Perform the steps outlined in this topic if you create new target levels that were not preconfigured with the product.

To understand and maintain the Marketing Server cache, follow these guidelines:

• Set the expiration parameter for the marketing cache to a value such that maximum response time efficiency is gained. The value is typically less than the database refresh frequency.
• After the database is refreshed, purge the affected caches before you start using segmentation.
• Cache can be removed for each user. For example, the cache entries that were created by a particular user can be removed without deleting all of the cache entries.
• Individual cache entries for a user cannot be deleted. You can delete all cache for a user or none.
• There is a limit to the number of cache entries that can be managed by the Marketing Server at any given time. This information is specified by the MarketingCacheMaxEntries parameter in the SiebelAnalyticData\Web\Config\instanceconfig.xml file. After the limit is reached then the oldest cache entries are removed approximately 20 percent at a time. The entries are removed from Oracle BI and the specific Cache information is deleted from the database table.
• When Caching a criteria block, if the criteria block SQL can be fully function shipped to the database, then evaluation of the criteria block and the population in the cache is done in one single operation for efficiency purposes. If the criteria block SQL cannot be function-shipped then cache is created in two steps where the first one evaluates the criteria block and the second step populates the target-level IDs into the cache.
• The references to the cache entries are maintained in the Oracle BI Web Catalog. Therefore, if the Catalog file is replaced, then entries from the old catalog file are typically moved to the new catalog file.

Recommendations for Using Cache

The following are some recommendations for when to use cache:

• Criteria blocks that are used in segmentation by a user might be used frequently across the segments created by that user. For example, a product manager for a particular product might only be interested in customers who own that product. Most of the segments created by this manager might include a criteria block that specifies owners of that product. To minimize resource-intensive database operations, cache the results of frequently used criteria blocks and use this cache for subsequent queries.
• When using complex criteria in a criteria block, especially against a large table, it may take a long time for the counts to return.
• When you use complex segmentation logic that spans criteria blocks and issues a large number of queries against the database, it usually takes a lot of time to evaluate. Save the segmentation logic as a separate segment and use it as a nested segment inside the full segment report. This type of nested segment is a good candidate for caching.
• When the use of a segmentation logic issues a query that is not directly supported by the database, these queries might be evaluated by the Oracle BI Server. For example, a database platform might not support the intersect operator in its SQL syntax. This operator is used when the you use the Keep operator for a criteria block in the Marketing module user interface. When such a criteria block is evaluated with other blocks, the intersect operation does not occur in the database and is evaluated by the Oracle BI Server. To improve response time for users of Oracle BI Server (Marketing module and BI reports), cache the results of such a logic.

  NOTE:  If you need to run the same query again, the results can be retrieved directly from a database cache.

• Caching is automatically used by the Marketing Server when splitting nodes in a segment tree, where the splitting logic requires the calculation of intermediate results. For example, when Random Splitting is used.
• When Caching a criteria block the gross count and not the cumulative count is cached. This is because if criteria block is moved within the segment, the cached results can be reused.