About The Oracle Query Optimizer Component Query Optimization Process

4-16 Oracle Fusion Middleware System Administrators Guide for Oracle Content Server ■ Section 4.2.5.13, Updating the Hint Cache

4.2.5.1 About The Oracle Query Optimizer Component

Oracle database does not automatically select the best execution plan for certain types of user queries. To counter this, the Oracle Query Optimizer adds hints to queries that force Oracle database to perform searches more efficiently. The hints are based on an intrinsic knowledge of Oracle Content Servers table data distribution and its index selectivity. To take advantage of this knowledge, Oracle Query Optimizer uses a pre-defined Hint Rules Table to analyze the database query and then add appropriate hints to the query. In turn, the added hints improve Oracles search performance. Oracle Query Optimizer takes advantage of Content Servers data distribution in database tables and its index selection preferences. Based on these characteristics, the Hint Rules Table included with Oracle Query Optimizer contains pre-defined rules. The feature uses these rules to analyze a database query and to add one or more appropriate hints to the query to optimize the search performance. In very large collections containing millions of content items, the Oracle Content Server software generally has a difficult time selecting an appropriate optimization strategy to resolve even simple queries. To counteract this problem, Oracle Query Optimizer examines the submitted query and, based on its analysis, reformats the query by adding appropriate hints to optimize the search process. To add hints, the feature uses Oracle Content Server hints, The Hint Rules Table , and The Hint Cache .

4.2.5.2 Query Optimization Process

The stages of the optimization process are completed in the following sequence: 1. The submitted query is analyzed to verify if it contains one or more hints and, if so, determine the type of hint; see Stage 1: Query Analysis on page 4-17. 2. If the querys WHERE clause does not contain a hint, the optimization feature must parse out the WHERE clause; see Stage 2: Parsing on page 4-17. 3. After parsing, each condition in the querys WHERE clause is evaluated against the Hint Rules Table in an attempt to qualify the condition and normalize the query; see Stage 3: Normalization on page 4-17. 4. After the WHERE clause conditions are qualified and the query is normalized, a hint is selected or retrieved from the hint cache; see Stage 4: Select Hint on page 4-18. 5. The query is reformatted using the selected hint; see Stage 5: Reformat Query on page 4-18. Managing System Settings 4-17 Figure 4–2 Optimization Process Sequence

4.2.5.2.1 Stage 1: Query Analysis In this stage, a query is checked for both Oracle

native and Content Server hints. This is determined based on the hint syntax: Query Hints Syntax . A query that contains Oracle hints is passed through. A query that contains Content Server hints bypasses Stage 2: Parsing and Stage 3: Normalization . If a query contains multiple Content Server hints, the best hint is chosen. Queries that do not contain any hints must be parsed and normalized.

4.2.5.2.2 Stage 2: Parsing In this stage, a query that does not contain any hints is sent

through the query parser and the WHERE clause is parsed out. A WHERE clause consists of one or more conditions joined with either AND or OR conjunctions. For each condition, the field name, operator, and field value are extracted. The ANDOR conjunctions of the clause are preserved; the parentheses are dropped. Conditions must use the following format: fieldname operator value For example, a properly formatted condition would be dID = 3. An incorrect condition would be 3 = dID.

4.2.5.2.3 Stage 3: Normalization In this stage, normalization simplifies conditions,

finalizes query operators, and provides a stable view of the WHERE clause for additional steps. The result of the normalization process produces a base for generating the cache key and the list of fields to use to search for hints. ■ Qualifying WHERE Clause Conditions: Note: To establish which database tables and columns have indexes, the Hint Rules Table is defined on Content Server resources and on the running system. 4-18 Oracle Fusion Middleware System Administrators Guide for Oracle Content Server Each condition in the WHERE clause is checked against The Hint Rules Table . If a conditions field name is included in the Hint Rules Table, then it is qualified and the condition is considered to be normalized. The condition contains its table name and alias. Then the normalized conditions are sorted to ensure that the same set of conditions is always listed consistently. ■ Discarding WHERE Clause Conditions During Normalization: During normalization, the following conditions are not considered relevant and are eliminated from further processing: – Join conditions. – Conditions that contain subqueries. – Conditions whose field names do not have entries in the Hint Rules Table and cannot be qualified. – OR conditions that contain more than one field. For example: dSecurityGroup = Secure or dDocAccount LIKE prj – Conditions that contain the LIKE operator whose value begins with a wildcard. ■ Reformatting WHERE Clause Conditions: In the normalization step, the query conditions are rewritten to consolidate complex query conditions. OR conditions are reevaluated as follows: – If all the fields are the same and all the operators are equal or all the operators are LIKE and no values begin with a wildcard, the conditions are combined and changed to an IN query. – If the fields are the same but have different operators, the conditions are combined and the generic operator is assigned. – If the fields are different, the conditions are dropped. For example, during normalization, the following condition is reformatted: dReleaseState = Y OR dReleaseState = O It is reformatted as follows: dReleaseState IN Y, O ■ Finding Potential Range Queries: The parsed query is analyzed to find potential range queries that are then consolidated during the normalization process. For example, the conditions dIndate date1 and dInDate date2 are changed to one condition with the operator range.

4.2.5.2.4 Stage 4: Select Hint In this stage, the normalized conditions are checked

against the hint cache. If one or more conditions have applicable hints in the cache, they are included. If applicable hints are not found in the cache, the conditions are analyzed and the preference orders are compared to determine the best possible hint.

4.2.5.2.5 Stage 5: Reformat Query In this stage, the query is reformatted by adding in the

selected hint. For more information about how reformatting queries with hints helps to optimize searches and some examples of reformatted queries, see Section 4.2.5.3, How Reformatted Queries Optimize Searches. Managing System Settings 4-19

4.2.5.3 How Reformatted Queries Optimize Searches