The Hint Cache Searching Content Using the Oracle Query Optimizer Component

4-26 Oracle Fusion Middleware System Administrators Guide for Oracle Content Server The hint rules configuration table is scheduled to reload every night and whenever a new rule is added or an existing rule is modified. The hint value is recalculated at each reload. Although any rule in the table can be enableddisabled, only the rules that are added through the Edit Hint Rules Form can be removed. The default hint rules that are included with the Oracle Query Optimizer component can only be disabled; they cannot be removed.

4.2.5.10 The Hint Cache

Oracle Query Optimizer also contains a hint cache to store dynamically generated hints. For example, a hint derived from a parsed query or data source is cached to maintain persistence. In this way, the hint cache provides stability for queries and data sources. The hint cache is used during the optimization process to select hints for queries that do not contain Oracle or Content Server hints. The hint cache provides a mechanism to fine tune query hints. In addition, administrator can checkedit cache and change hint for queries at run time. The hint cache is stored to disk every two hours and is reloaded when the Oracle Content Server instance is started. The characteristics of the hint cache include: ■ Reusing Hint Cache Entries ■ Hint Cache Management ■ Default Capacity Algorithm ■ Origin of Hint Cache Keys ■ Hint Cache Persistence

4.2.5.10.1 Reusing Hint Cache Entries The same query matches the same cache entry

regardless of its values unless the new value does not satisfy the hint rule conditions. Two examples are included below to demonstrate how the same hint cache entry can and cannot be used for multiple queries. Example 1: Using Similar Hint Cache Entries In the following two queries, the same hint cache entry is used because both queries match the hint rule requirements. ■ QueryA : SELECT FROM Revisions WHERE dDocName = name1 ■ QueryB : SELECT FROM Revisions WHERE dDocName = name2 Example 2: Using Different Hint Cache Entries In the following two queries, the same hint cache entry cannot be used because QueryB violates the requirements for the dReleaseState hint rule. The dReleaseState Managing System Settings 4-27 hint rule requires that the dReleaseState values are neither Y released nor O old revision. ■ QueryA : SELECT FROM Revisions WHERE dReleaseState = U AND dStatus = DONE ■ QueryB : SELECT FROM Revisions WHERE dReleaseState = Y AND dStatus = DONE

4.2.5.10.2 Hint Cache Management In the hint cache, you can add a new entry, edit an

existing entry, or remove an existing entry using the Hint Cache Updater Page . When adding or editing hint cache entries, you must use the Oracle Content Server Hint Syntax . The ability to manage the hint cache is very useful for fine tuning query hints. The example below demonstrates the benefits of fine tuning a hint cache entry. Example: Batchloading Unindexed Content If you have just batchloaded 100K content items into the Content Server and they are not yet indexed, the index-based query used above Example 2: Using Different Hint Cache Entries would match all of the batchloaded documents. ■ QueryA: If most of the batchloaded documents have not been indexed, the dReleaseState index that is used in this query is not the best choice. For the best results in this case, you should fine tune the hint cache entry to use both the dReleaseState and the dStatus indexes. Use the Hint Cache Updater Page to update hint cache entries. SELECT dID FROM Revisions WHERE Revisions.dReleaseState = NN AND Revisions.dStatus in NDONE, NRELEASED, NDELETED AND Revisions.dInDate={ts 2005-02-23 17:46:38.321} ■ QueryB: After updating the hint cache entry, the new optimized query is: SELECT+ LEADINGrevisions INDEX revisions dReleaseState dStatus dID FROM Revisions WHERE Revisions.dReleaseState = NN AND Revisions.dStatus in NDONE, NRELEASED, NDELETED AND Revisions.dInDate={ts 2005-02-23 17:46:38.321}

4.2.5.10.3 Default Capacity Algorithm By default, the hint cache has a maximum capacity

of 1000 hints. The hint cache uses the midpoint insertion least-recently-used LRU algorithm which is similar to the one used by Oracle and mySQL. A new entry is inserted into the middle of the queue and each subsequent execution moves the entry up one spot. When the number of hints in the cache exceed the maximum capacity, the entry at the bottom of the queue is removed from the cache. Thus, the LRU algorithm ensures that the most recently executed query hints are in the upper levels of the queue.

4.2.5.10.4 Origin of Hint Cache Keys The hint cache key is generated from the

normalized query; see Section 4.2.5.2.3, Stage 3: Normalization. It consists of the 4-28 Oracle Fusion Middleware System Administrators Guide for Oracle Content Server qualified columns columns that are qualified by tablealias names and columns that have a hint rule defined. The cache key excludes conditions that contain joins or subqueries. The following example illustrates how the cache key is generated from a given query: SELECT DocMeta., Documents., Revisions. FROM DocMeta, Documents, Revisions WHERE DocMeta.dID = Revisions.dID AND Revisions.dID=Documents.dID AND Revisions.dDocName=abc AND Revisions.dStatusDELETED AND Revisions.dReleaseState=U OR Revisions.dReleaseState=I OR Revisions.dReleaseState=Y AND Documents.dIsPrimary0 The generated cache key is as follows: documents.disprimary:notequal:documents|revisions.ddocname:equal:revisions|revisio ns.dreleasestate:in:revisions|revisions.dstatus:notequal:revisions

4.2.5.10.5 Hint Cache Persistence The hint cache is designed to be persistent. To ensure

the persistence, the hint cache is saved to the file system every two hours. The persisted hint cache is reloaded when the Oracle Content Server instance is started.

4.2.5.11 Using Hint Rules