Observability of SQL Hints in Oracle
Krishna Kantikiran Pasupuleti Dinesh Das
Oracle America Inc. Oracle America Inc.
Redwood City CA USA Redwood City CA USA
kanti.kiran@oracle.com dinesh.das@oracle.com
Mohamed Zait†
Oracle America Inc.
Redwood City CA USA
mohamed.zait@gmail.com
ABSTRACT
Observability is a critical requirement of increasingly complex
and cloud-first data management systems. In most commercial
databases, this relies on telemetry like logs, traces, and metrics,
which helps to identify, mitigate, and resolve issues
expeditiously. SQL monitoring tools, for example, can show how
a query is performing. One area that has received comparatively
less attention is the observability of the query optimizer whose
inner workings are often shrouded in mystery. Optimizer traces
can illuminate the plan selection process for a query, but they
are comprehensible only to human experts and are not easily
machine-parsable to remediate sub-optimal plans.
Hints are directives that guide the optimizer toward specific
directions. While hints can be used manually, they are often
used by automatic SQL plan management tools that can quickly
identify and resolve regressions by selecting alternate plans. It is
important to know when input hints are inapplicable so that the
tools can try other strategies. For example, a manual hint may
have syntax errors, or an index in an automatic hint may have
been accidentally dropped.
In this paper, we describe the design and implementation of
Oracle's hint observability framework which provides a
comprehensive usage report of all hints, manual or otherwise,
used to compile a query. The report, which is available directly
in the execution plan in a human-understandable and machine-
readable format, can be used to automate any necessary
corrective actions. This feature is available in Oracle
Autonomous Database 19c.
†Research conducted when employed at Oracle America Inc.
Permission to make digital or hard copies of all or part of this work for personal
or classroom use is granted without fee provided that copies are not made or
distributed for profit or commercial advantage and that copies bear this notice
and the full citation on the first page. Copyrights for components of this work
owned by others than ACM must be honored. Abstracting with credit is
permitted. To copy otherwise, or republish, to post on servers or to redistribute
to lists, requires prior specific permission and/or a fee. Request permissions
from Permissions@acm.org.
CIKM '22, October 17–21, 2022, Atlanta, GA, USA.
© 2022 Association for Computing Machinery.
ACM ISBN 978-1-4503-9236-5/22/10…$15.00.
DOI: https://doi.org/10.1145/3511808.3557124
3441
Satyanarayana R Valluri†
Oracle America Inc.
Redwood City CA USA
satya.valluri@gmail.com
CCS CONCEPTS
• Information systems~Query optimization • Information
systems~Autonomous database administration
KEYWORDS
Observability; Autonomous Database Administration; SQL Hints;
SQL Plan Management; Query optimization
ACM Reference format:
Krishna Kantikiran Pasupuleti, Dinesh Das, Satyanarayana R Valluri and
Mohamed Zait. 2022. Observability of SQL Hints in Oracle. In Proceedings
of the 31st ACM International Conference on Information and Knowledge
Management (CIKM ’22), October 17—21, 2022, Atlanta, GA, USA. ACM,
New York, NY, USA, 10 pages. https://doi.org/10.1145/3511808.3557124
1 INTRODUCTION
The performance of SQL queries is critical to the overall cost of
database ownership. These queries may be complex and operate
on varied data (including relational or unstructured). Moreover,
the data themselves may be arbitrarily large and constantly
evolving. Modern databases have cost-based optimizers that do
a fairly good job of generating optimal execution plans, relying
on automatically collected statistics. A few poorly performing
queries, however, can cause havoc in an otherwise well-tuned
system. Many databases provide tools to automatically monitor,
analyze, and tune such queries [1, 2, 3, 4, 5, 6].
Oracle provides several SQL performance management tools,
including SQL Plan Management [7], Automatic SQL Tuning [8],
SQL Repair Advisor [9] and SQL Quarantine [10]. These tools
identify and resolve query performance issues by automatically
creating and managing directives, collectively called SQL
Management Objects (SMOs). These SMOs are used during
query compilation and help the optimizer to pick an optimal
plan. Three of these SMOs are as follows:
SQL Plan Management: SQL plan baselines are collections of
verified good execution plans for SQL statements. The optimizer
chooses plans from these SMOs, providing plan stability and
thus, predictable performance. New plans found by the
CIKM ’22, October 17–21, 2022, Atlanta, GA, USA Krishna Kantikiran Pasupuleti, Dinesh Das, Satyanarayana R Valluri, & Mohamed Zait

optimizer are automatically verified for their quality and if parent query blocks) and the hints in them may not be
satisfactory, are added to existing SQL plan baselines. This carried to the final stages of compilation.
prevents performance regressions and allows the database to 4. In a large code base, attempting to modify all places of code
gracefully adapt to system changes. adding hint tracking capability is laborious and error prone.
It is also not maintainable as new hints are regularly added.
SQL Profiles: Oracle automatically tunes high-load SQL
To address the above issues, our solution performs an
statements and recommends SMOs called SQL Profiles to
independent validation at the end of compilation to determine
improve their performance. These profiles contain a set of hints
whether input hints were used. It doesn’t derive any data from
which steer the optimizer towards a better plan.
the query optimizer’s examination of hints during compilation,
but instead relies only on the outcome i.e., the final query plan.
SQL Patches: The SQL Repair Advisor attempts to correct
certain errors that occur during query processing by applying
The rest of the paper is organized as follows. Section 2 describes
error-correcting hints as “patches”.
how hints are represented and managed in Oracle, and the
naming mechanism of objects in a SQL statement that allows
Hints are the foundation of SMOs; each SMO is a collection of
hints to target all objects during all stages of optimization. In
hints that direct the optimizer toward making good decisions1.
Section 3, we describe how validation of input hints is performed
As such, it is vital that these hints always work. When they
using reference hints generated at the end of compilation.
don’t, it is equally important that this information be available to
Section 4 gives examples of reports generated for certain queries
the SQL performance management tools, so that the SMOs can
with input hints, that help showcase their utility. It also gives
be re-generated with working hints. Our work provides a
examples of corrective actions that can be taken by autonomous
framework to uniformly track and report (in a standardized
tasks based on the reports.
format) on the hundreds of possible hints that are routinely used
in SMOs.
2 BACKGROUND
Tracking whether a hint is used is non-trivial because of several
reasons. A naïve way of marking hints as used when they are Hints can be specified by users or generated internally by the
examined by the optimizer is insufficient and often incorrect for database. Figure 1 shows an example of a query with a user-
the following reasons: specified hint (identified by the de-limiting strings “/*+” and
“*/”). The hint instructs the optimizer to use an “index range
1. Code-complexity: Hints may be examined multiple times scan in ascending order” access path on table T1. Examples of
within the database before a decision is made if they need to hints generated internally by Oracle are shown in Figure 4.
be applied. Further the point of examination and the point Oracle’s optimizer is obligated to honor hints if they are valid.
of final decision may be different.
2. Global Decision: Hints may be valid and applied at a local
point of search-space exploration but may not be honored
in the final plan. For example, consider a join method hint
USE_NL specified on a table that indicates the table must be
joined to any table that appears on its left using a Nested-
Loop join. The hint may be applied in some join orders but
if the best join order has the table positioned in the Figure 1: Query with two query blocks and a hint.
beginning, the hint cannot be applied. In another example, a
“join elimination” transformation [11] that removes We first briefly describe how queries and hints are represented
redundant tables in a query block renders hints specified on
in Oracle before we elaborate on how hints are used to target
such tables inapplicable, even though the hints may have
been applied prior to the transformation. As a third different stages of optimization.
example, consider a join order hint that specifies three
tables. The three tables may appear in a query block only 2.1 Query Representation
when a view is merged into its containing query block. If A query should be represented in such a way that any object
view is not merged, the three tables will not appear within it can be uniquely and unambiguously identified. For
together, and the join order hint will be inapplicable. Usage instance, a table can be specified in a query at more than one
of the hint is thus conditional on the alternatives that the
position using aliases. It can also be specified in multiple query
optimizer evaluates.
3. As optimizer transforms a query, query block structures blocks with the same alias. A hint that needs to target such a
may be dropped (e.g., view query blocks merged into their table must unambiguously identify the specific instance of it.

The parsed structures of a SQL query consist of 1) Query block

1 Users can manually hint queries as well, but this is discouraged due to the
increasing sophistication of the optimizer and because these hints are difficult for
users to manage.
objects that correspond to SQL command (SELECT, INSERT,
UPDATE etc.) sections of a query 2) Table (or View) objects that
appear in the FROM clause of a query block and 3) Statement

3442
Observability of SQL Hints in Oracle
object that refers to the entire SQL statement. For example,
query Q1 has two query blocks that are named SEL$1 and SEL$2.
Query block SEL$1 has a table t_5k with alias T1, and a view V.
Query block SEL$2 (the view) has two tables t_4k and t_10k with
aliases T1 and T2 respectively.
Query Block Names: Query blocks are assigned “names”.
Initially when the SQL text is parsed, they are assigned names
based on the order in which they appear in the query. When the
optimizer transforms a query block during optimization, it
renames it by generating a hash as described further in Section
2.2. For example, in Q1, when SEL$2 is merged into SEL$1, the
parent query block SEL$1 is renamed to SEL$F5BB74E1.
Object Identifiers: Every object (table or view) that appears in
the FROM clause of a query block is assigned a globally unique
(within the SQL statement) identifier that is composed of the
object alias and the query block name in which it first appears.
For instance, table t_4k that appears in SEL$2 of Q1 is assigned
an identifier of “T1”@”SEL$2”. The identifier is fixed and doesn’t
change during the lifetime of optimization. For instance, if the
view query block SEL$2 in Q1 is merged into its outer query
block, the object t_4k inside it retains its identifier -
“T1”@”SEL$2”.
Figure 2: Query Q2.
The following sections describe how query block names are
tracked during the compilation of a SQL statement.
2.2 Query Block Registry
Query block names are uniquely and deterministically generated
during compilation. As mentioned earlier, when transformations
are applied on a query block, its subsequent names are generated
by a hash function that uses the old name, the type of
transformation and its arguments. This ensures that across
database versions, different statistics etc., whenever the same
transformation is applied to the same old query block name, it
generates the same new name. This is a vital property of query
block naming that is necessary to apply global hints, as they rely
on deterministic generation of names. It also ensures portability
of plans.
A per-SQL repository called the query block registry (QB
Registry) is maintained to track the names generated during
compilation. Initially, it consists of all query blocks that are
created by the parser for the statement. As new names are
3443
CIKM ’22, October 17–21, 2022, Atlanta, GA, USA
generated, they are recorded in the registry which is a directed
acyclic graph (Figure 3). Nodes in the graph represent query
blocks and the directed edges between nodes represent query
transformations. A node can have more than one edge incident
on it in which case the node is a result of a query transformation
involving multiple nodes. For example, a query block that
contains multiple views may be transformed by merging the
view query blocks into it. A query block registry can consist of
disconnected components; query blocks in disconnected
components are unrelated to each other. Final nodes are all
nodes whose query blocks appear in the final plan selected by
the optimizer.
The QB Registry graph generated for query Q2 (Figure 2) is
shown in Figure 3. It has one final node (marked by a double
ellipse) which is derived through a sequence of transformations.
The graph shows that a “view merge” transformation was
applied on query block SEL$1 using query block SEL$2 as an
argument, generating SEL$F5BB74E1. Subsequently, “subquery
unnest” transformation was applied on SEL$F5BB74E1 using
SEL$3 as an argument generating the final query block
SEL$1F949E82.
Figure 3. Query block registry graph for Q2 at the end of
compilation. The final node is shown in double ellipse.
2.3 Global Hints
In order to control every aspect of query optimization, hints
should have the capability to target any object including one that
is not present in the beginning but created on-the-fly during
optimization. Global hint specification allows a hint to do that
by specifying a name for the target query block (as its first
argument) and optionally a name for the object that would
appear in the query block. When the named object is generated
during compilation, the hint is automatically applied. The SMOs
described in Section 1 contain global hints in them as they may
need to target objects that are created during compilation.
Consider query Q2 (Figure 2) that is subject to multiple
transformations. The view ‘v’ can be merged into the outer
query block and the “EXISTS” subquery can be unnested into its
outer query block and converted into a join. If SEL$1F949E82 is
the resulting name of the query block that is generated after both
the transformations, a hint INDEX(@SEL$1F949E82 T4@SEL$3)
forces an index scan on the table T4 (that is initially present in
CIKM ’22, October 17–21, 2022, Atlanta, GA, USA Krishna Kantikiran Pasupuleti, Dinesh Das, Satyanarayana R Valluri, & Mohamed Zait
the subquery) inside the resulting query block SEL$1F949E82. If
one of the transformations does not take place, the query block
SEL$1F949E82 would not be generated and consequently the hint
would not be applied.
If all the relevant operations during optimization are captured in
the form of fully specified global hints, the hints can be used to
represent complete query plans.
Plan Outline: An outline of a query plan is a collection of global
hints that is equivalent to its logical representation. When a
query is re-compiled using the outline as input, the hints direct
the optimizer through the same sequence of operations of
compilation that were applied when the original plan was
generated. A sample outline that is generated at the end of
compilation of query Q2 is shown in Figure 4. It consists of
transformation hints (shown in bold) and physical optimizer
hints generated on query blocks. Physical optimizer hints
correspond to operations such as join orders, join methods,
access paths on tables etc., within each query block. In addition,
there are hints that apply to the entire SQL statement which are
essential to reproduce the plan. For example, the ALL_ROWS
hint specifies that the query needs to be optimized to fetch all
rows during execution. The outline is stored in XML format in a
system metadata table that stores the plan information.
Figure 4: Outline of the final generated plan for Q2.
Transformation hints are shown in bold.
For the purpose of the following discussion, we make a
distinction between two classes of hints that conflict with each
other. Positive hints are hints that enforce an operation (e.g.,
MERGE(@SEL$2)) and negative hints are the ones that prohibit
an operation (e.g., NO_MERGE(@SEL$2)). In addition, some
positive hints are mutually exclusive of each other. For example,
FULL(T1) and INDEX(T1) cannot both be honored as the former
3444
enforces a full scan operation on the table while the latter
enforces an index scan.
3 HINT REPORT
When the final plan of a SQL statement is available, the input
hints to the statement are “validated” i.e., classified into “used”
and “unused” categories along with the reasons for being
unused. A report is generated in XML format that contains the
results of validation and is stored along with the plan.
Reference Hints – Sources of Truth: We solve the problem of
input hint validation by examining the final generated plan and
checking whether each hint is consistent with the actual decision
in the plan. This is an independent assessment that de-couples
the validation from query compilation. A set of “reference hints”
is constructed from the QB-Registry graph which represents the
actual actions that lead to the final plan (because the QB-
Registry contains all the steps optimizer took to arrive at the
final plan). By comparing the reference hints with the
corresponding input hints (which indicate “intended” actions), it
is inferred whether the input hints were used. The input hints
can be present in any query block and are located by traversing
the QB-Registry. This approach has the benefit of centralized
code that is extensible and maintainable even as new hints are
added. Figure 5 depicts the overview of the hint-validation
process.
Figure 5: Input-Hint validation using reference hints
generated from a query plan.
During compilation, hints corresponding to operations that are
rejected by the optimizer are marked with errors along with the
appropriate reasons.
1. Syntax and Semantic errors: Hints with syntax errors are
identified during parsing. Certain semantic errors are
caught during early stages of compilation when hints are
resolved. E.g., an INDEX hint that specifies a non-existent
index on a table.
2. Validity: A hint can be rejected by the optimizer if it is
invalid for the structure of the query. For instance, a hinted
view that is semi-joined with a table may not be eligible for
Observability of SQL Hints in Oracle
view merging [11]. If a hint is rejected, the optimizer
annotates it with the appropriate reason code.
The bulk of hint validation happens at the end of compilation
when reference hints are generated and compared with input
hints.
3.1 Hint Validation
When hints are created by the parser, positive hints are marked
with an initial state of “unused”. Negative hints are marked with
an initial state of “used” and if a positive action is identified to
have taken place, the corresponding negative hint is marked
“unused”. This is because the optimizer can quickly detect
presence of positive actions in the final plan.
Superset semantics for positive hints: The reference hint
generated from the outline is a full specification of the hint that
includes the target query block name, object specification if
applicable and fully specified arguments (Figure 4). An input hint
on the other hand can be a partial specification (e.g., a user may
omit certain arguments). Hence when a reference hint is
compared with an input hint, a successful match is the one in
which the action specified by the reference hint includes (is a
superset of) the action specified in the input hint. For e.g., a
PLACE_GROUP_BY input hint that indicates grouping views to
be created, may specify one view, whereas the reference hint
may have two views including the view specified in the input
hint.
Intersection semantics for negative hints: When the
reference hint generated from the outline needs to be compared
with a negative input hint (NHi), it needs to be determined if the
reference hint “intersects” with the input hint. This is because if
an input hint disallows a certain operation and the outline shows
a part of that operation occurred in the final plan, the negative
hint hasn’t been honored completely. For example, consider an
input hint NO_INDEX(T1 I1 I2) that prohibits both indices I1, I2
of the table T1 from being used. Further consider another hint in
an outer query block that specifies index I2 must be used,
overriding part of the negative hint. If the reference hint
indicates an index I2 is used in the final plan, the input hint,
NO_INDEX, must be marked unused.
3.1.1 Validating Transformation Hints (QB-Registry
Graph Traversal): Transformation hints are validated by
traversing the QB Registry graph. The optimizer first gathers
names of query blocks present in the final query plan in a list.
The graph traversal starts from this list of “final” (leaf) nodes and
proceeds bottom-up to the root nodes. During this traversal,
hints are validated based on the name of the node encountered
and the type of edge incident on the node. Other arguments used
by the transformation are retrieved from the information stored
in the edge. A reference hint Hg is generated that represents the
edge information along with its arguments. For instance, when
the edge for “VIEW MERGE” is traversed in the graph shown in
3445
CIKM ’22, October 17–21, 2022, Atlanta, GA, USA
Figure 3, the corresponding reference hint would be
MERGE(@SEL$2 > SEL$1).
If a positive input hint Hi is specified in the query for the
transformation it must be present in the parent node of the edge
(or in one of the secondary parent nodes for some specific
transformations). Similarly, if a negative hint NHi is specified for
the transformation, it will also be found in the same parent node.
Note that either of Hi or NHi may be present in the parent node
of the edge. Table 1 describes the logic.
Table 1: Comparing input hints with reference
transformation hints.
Hi : Input Hint
Hg : Reference Hint from QB-Registry graph
If Hi is found in target query block and is not already marked
with an error and Hg ⊇ Hi
• Hi is marked as “used” because the reference hint
representing the final plan “covers” the operation
specified in the input hint.
If NHi is found in target query block and Hg ∩ NHi ≠ ∅
• NHi is marked “unused” because the reference hint
representing the final plan contradicts a part of the
operation specified by the negative input hint.
As an example, a part of the QB registry graph for query Q2
along with sample input hints specified for query-block SEL$2 is
shown in Figure 6. When the edge from SEL$1 to SEL$F5BB74E1
is traversed (indicated by the red arrow), for the “View Merge”
transformation, the corresponding input hint is fetched from the
hint chain of query block SEL$2 and marked appropriately. The
example shown has a positive input hint (MERGE) that is
marked “used”. On the other hand, if a negative hint
(NO_MERGE) is specified, it would be marked “unused”.
Figure 6: Locating and matching input hints during
bottom-up traversal of QB Registry graph.
3.1.2 Validating Physical Optimizer Hints: While the
transformation hints are derived from the edges between nodes
in the graph, the hints for physical operations (e.g., join order,
join methods, access paths) if any, will be found in the final (leaf)
nodes of the graph. The optimizer visits the leaf nodes of the QB
Registry graph and for every node it, i) generates a reference
hint Hp for each physical operation in the node and ii) locates
CIKM ’22, October 17–21, 2022, Atlanta, GA, USA Krishna Kantikiran Pasupuleti, Dinesh Das, Satyanarayana R Valluri, & Mohamed Zait
the corresponding input hint - Hi or NHi inside the query block
and validates it (Table 2).
For example, SEL$1F949E82 is a final query block in the query
plan of Q2 (Figure 3). Consider the access path (reference) hint,
Hp, generated on table F shown as follows:
Hp: INDEX(@"SEL$1F949E82" "F"@"SEL$1"
("T_10K"."THOUSAND"))
The hint specifies an index on column THOUSAND of table
T_10K.
Further, consider a sample input hint Hi, specified by the user on
table F that uses the name of an index - IDX_THOUSAND -
shown as follows:
Hi: INDEX(F IDX_THOUSAND)
If the index IDX_THOUSAND is on the column THOUSAND,
the comparison Hp ⊇ Hi succeeds.
On the other hand, if the input hint specified is NHi:
NO_INDEX(F) that indicates no index on table F should be used,
the check Hp ∩ NHi ≠ ∅ succeeds and NHi is marked “unused”.
If NHi is NO_INDEX(F IDX_TEN) specifying the index named
IDX_TEN must not be used on table F, the check H p ∩ NHi ≠ ∅
fails and NHi remains “used”.
Table 2: Comparing input hints with reference physical
optimizer hints.
Hi : Input Hint
Hp : Reference Physical Optimizer Hint from QB-Registry
graph’s leaf nodes
If Hi is found and Hp ⊇ Hi, Hi is marked “used”.
If NHi is found and if Hp ∩ NHi ≠ ∅ , NHi is marked
“unused”.
3.1.3 Statement Hints: Statement hints input to the plan are
present in a global context and are not attached to any query
block as they apply to the entire statement. Reference statement
hints for the plan are generated by deriving information from
the environment settings, plan annotations etc. For example, if
the final plan is a parallel plan, a reference hint PARALLEL is
generated. The corresponding input hint is fetched from the
global context and marked appropriately.
3.1.4 Hint Matching: For all the categories of hints described
earlier, the hint validation logic is executed in two phases using
the reference hint for comparison.
1. Phase 1 (Positive Hints): In the first traversal of the hint
chain, positive hints that match the reference hint are
fetched and marked as “used”.
2. Phase 2 (Conflicting Hints): In the second phase, the hint
chain is re-traversed and hints that conflict with the
reference hint are identified and marked as “unused”. There
can be multiple such hints.
3446
For instance, the reference hint generated on a table can be
INDEX_RS_ASC that indicates the access path chosen is an
index-range ascending scan, and there can be multiple input
hints specified on the table as follows:
a) INDEX_SS, specifying an index skip scan must be used.
b) NO_INDEX_RS_ASC, specifying that index-range
ascending scan must not be used.
Both the above input hints need to be marked “unused”.
3.2 Storage and Display of Hint Report
After input hints are validated and marked appropriately, the
hint report is persisted in the query plan in XML format. PL/SQL
stored procedures are provided that parse this information and
display the report along with the plan. Internal modules of the
database that need the report access it by executing appropriate
XML queries.
3.3 Feedback to Autonomous Components
The feedback obtained from query compilation in the form of a
hint report can be useful to multiple components of the database
like maintenance and tuning processes that run in the
background.
SQL Plan Management: As described in Section 1, SQL Plan
baselines are SMOs that contain verified good plans for SQL
statements. These SMOs, also referred to as “accepted” plans are
used by the optimizer in preference over regular cost-based
plans. They are automatically created when plan regressions are
detected for SQL statements. The outlines of these plans contain
the full set of hints that reproduce them. Subsequently, if the
system fails to reproduce an accepted plan due to some outline
hints being unused, it can isolate the SMO so that the optimizer
stops using it. Section 4 gives an example of such an event and
how a corrective action can be triggered.
SQL Auto Tune: The auto-tune component of Oracle attempts
to tune high-load or regressing SQL statements. It can use the
hint report to derive correlation between plan performance and
unused hints. If a regressing SQL statement has unused hints, the
tuning strategy can begin by fixing them to improve
performance. This is described in Section 4 using an example.
Alerts: The autonomous database has an infrastructure
component called Auto SQL Tuning Set (Auto STS) that captures
and stores all statements executed in the database and their
plans. The hint report captured along with the plans enables
detection of events in history like hints flipping from being used
to unused. Alerts can be generated that can be further correlated
to, for instance, DDL events like an index being dropped,
partitioning being removed on a table etc.
Observability of SQL Hints in Oracle CIKM ’22, October 17–21, 2022, Atlanta, GA, USA

4 SAMPLE REPORTS AND CORRECTIVE The query plan, its objects and the hint report are shown in
ACTIONS Figure 8. There are three hints out of which two are unused and
one has a syntax error. The summary of the hint report in the
In this section we present
header shows the total number of input hints to the statement
and the number of errors if any. The hints are shown ordered by
1. Sample hint reports and how users can benefit from them
the plan line numbers of the objects they apply to, grouped by
2. How the information from the report can be used to correct
objects in the plan. When available, the reason for non-usage of
plan issues by autonomous components of the database.
a hint is also displayed.
Example 1 – Feedback to users
The ‘place_group_by’ hint forces a grouping operation on
The following example shows a sample set of hints added by a table(s) before they are joined with other tables and is used to
user to TPCH query 13 and the corresponding hint report when reduce the size of joins. The hint specified in SEL$2 of Q13
the query is compiled. Query Q13 has two query blocks as instructs tables ‘customer’ and ‘orders’ be grouped into one view
shown in Figure 7. and the table ‘customer’ into another view before joining both
the views. This is not possible as the same table cannot be placed
in two groups. The report displays the reason the hint is unused.
The index ‘c_idx’ specified in the index hint doesn’t exist on the
table as shown by the reason in the report. The hint “nounnest”
is incorrectly spelt and is shown as a syntax error in the report.
The correct specification is “no_unnest”.

Example 2 – Feedback to users

The next example shown in Figure 9 is query Q6 from TPCH.

The hint in the query forces an index “i_l_orderkey” on
Figure 7: TPCH Query Q13.
LINEITEM table to be used in the plan. Consider a situation in
which the index has been marked “invisible” and cannot be used
by the optimizer. The hint report shown in Figure 10 gives quick
feedback alerting the user.

Figure 9: TPCH Query Q6.

Figure 8: Query Plan and Hint Report for Q13. Figure 10: Hint Report of TPCH Query Q6

3447
CIKM ’22, October 17–21, 2022, Atlanta, GA, USA Krishna Kantikiran Pasupuleti, Dinesh Das, Satyanarayana R Valluri, & Mohamed Zait
Example 3 – Corrective Actions
Consider a workload in which some accepted plans are created
as SMOs, and a user drops an index that is used in some of those
plans. When optimizer tries to reproduce such a plan, it fails to
generate it as the index is no longer present and a different
access path must be chosen for the table. The index hint is
identified as unused in the hint report and the optimizer takes
note of it. When multiple plans are affected similarly by the
dropped index, it becomes a candidate for the automatic
indexing (AI) [12] component to re-create it. The AI process
periodically creates and verifies candidate indices by test
executing the statements in the workload for performance.
Indices that were part of accepted plans and dropped are
candidates for plan stability and can be verified accordingly by
the AI process.
Figure 11 shows the outline hints of an accepted plan for the
TPCH query, Q13 shown in Figure 7. It shows an index hint on
the “customer” table used in the plan in query block
SEL$7363DADF (shown in bold). The index is on the column
C_CUSTKEY.
Figure 11: Outline of an accepted plan for Q13.
If the index is dropped and the optimizer attempts to reproduce
the accepted plan, the hint report identifies the index as unused
(Figure 12 - only the relevant part of the report is shown for
brevity).
Figure 12: Hint Report for Q13A using its outline when the
index is unavailable.
3448
Example 4 – Corrective Actions
Hints present in queries can become ineffective over time
sometimes resulting in poor plans. As plan history along with
hint reports and execution statistics is available in Auto STS,
background maintenance tasks can examine it and detect
changes in hint report i.e., hints changing status from used to
unused. This indicates correlation between the changes and plan
performance, and the system can automatically create a SQL
Patch that contains correcting hints to restore the performance,
as demonstrated in the following example. Query Q3 shown in
Figure 13 has a “push_pred” hint (a query transformation hint)
that instructs optimizer to push the join predicate[11] between
table T1 and view V (i.e., predicate T1.hundred = V.hundred)
onto the corresponding table T2 inside the view. (Note that the
argument, “SEL$2”, of the hint identifies the target view query
block of the push).
Figure 13: Query Q3 with a hint to push predicate into
view.
The query plan when the hint is effective is shown in Figure 14.
The hint report indicates the hint is used.
Figure 14: Hint Report for Q3 with join predicate pushed
into view
Observability of SQL Hints in Oracle
In the course of time, if the cost-based optimizer finds it optimal
to merge the view V into its containing query block, the join
predicate can no longer be pushed because the view disappears.
The plan with the view merged, for the same query is shown in
Figure 15. The hint report indicates that the “push_pred” hint is
unused having been discarded during view-merging.
Figure 15: Hint Report for Q3 when view is merged.
If the new plan performs poorly, the problem can be
automatically fixed by noting the reason indicated in the hint
report and injecting a new hint - “NO_MERGE(@SEL$2)” - into
the view query block through a SQL Patch created for the query.
When the query is compiled subsequently, the NO_MERGE hint
prevents the view from being merged. The original “push_pred”
hint can now be applied, and the previous good plan is
generated.
Overhead
The overhead introduced by hint tracking and report generation
is linearly proportional to the number of input hints in the plan.
The additional compute resources required to track the usage of
input hints is minimal as most of the activity is piggybacked on
query compilation and outline generation code. In our
experience, across many in-house and customer queries,
additional CPU overhead for an outline-driven compilation (that
has many input hints) is less than 0.1% and there is negligible
impact on the query compilation time. The report is stored in
encoded form in the plan cache and adds <1% of memory
overhead to the plan. It is decoded and persisted to disk along
with the plan when required.
5 RELATED WORK
Hinting SQL queries has been a common practice by the users of
databases to influence query plans generated by the optimizer.
3449
CIKM ’22, October 17–21, 2022, Atlanta, GA, USA
All popular databases allow users to hint queries. Microsoft SQL
Server [13] provides OPTION clause to specify hints. MySQL
[14] hints can be specified on named query blocks like Oracle,
and in some cases a warning is displayed if the specified hints
conflict. But a comprehensive report is not provided to the users.
IBM DB2 [15] uses optimization guidelines and profiles that
allow the user to control certain stages of compilation like query
rewrite, plan generation etc. However, they do not offer fine-
grained control over application of hints on query objects and a
detailed report regarding their usage is not available. HP
Tandem NonStop SQL[16] provides control directives like
CONTROL QUERY, CONTROL TABLE etc. that can be executed
prior to executing queries to influence query shapes and
operations like join orders, join methods etc. A report of whether
the directives were used is not provided.
The authors of [17] propose a language abstraction (called
Phints) that allows specification of hints through expressions
defined as tree patterns annotated with constraints. These
expressions are matched with the optimizer search-space,
captured as a graph, that represents all possible execution plans.
While Phints expressions can target any sub-structure of the
place space, they require prior generation of the complete plan
space as an additional step. Database optimizers may not
generate the entire plan space and then apply hints as the space
is often exponential in nature and generating it is expensive. In
Oracle, the shape of the plan that leads to a particular state is
captured by the query block name at that point as it is based on a
specific ordered sequence of names each of which represents an
operation that modifies the query block. Additionally, our work
provides feedback for input hints by performing an independent
validation which is not addressed by the Phints framework.
Oracle provides a comprehensive set of hints that covers all SQL
operations and can represent query plans. The hints form the
basis for automatic plan management and tuning within the
database. To the best of our knowledge, although other database
products provide hints as tools to users, they do not provide
automatically generated feedback on whether the hints were
successfully used.
REFERENCES
[1] Oracle SQL Monitor. https://docs.oracle.com/en/database/oracle/oracle-
database/21/tgsql/monitoring-database-operations.html#GUID-C941CE9D-
97E1-42F8-91ED-4949B2B710BF
[2] Oracle SQL Performance Analyzer.
https://docs.oracle.com/en/database/oracle/oracle-
database/21/ratug/introduction-to-sql-performance-analyzer.html
[3] Snowflake Activity Monitoring. https://docs.snowflake.com/en/user-guide/ui-
snowsight-activity.html
[4] Spark Monitoring. https://spark.apache.org/docs/latest/monitoring.html
[5] SQL Server Monitoring. https://docs.microsoft.com/en-us/sql/relational-
databases/performance/performance-monitoring-and-tuning-tools?view=sql-
server-ver16
[6] SQL Server Tuning. https://docs.microsoft.com/en-us/sql/relational-
databases/automatic-tuning/automatic-tuning?view=sql-server-ver16
[7] Mohamed Ziauddin, Dinesh Das, Hong Su, Yali Zhu, and Khaled Yagoub. 2008.
Optimizer plan change management: improved stability and performance in
Oracle 11g. Proc. VLDB Endow. 1, 2 (August 2008), 1346-1355.
https://doi.org/10.14778/1454159.1454175.
[8] Benoit Dageville, Dinesh Das, Karl Dias, Khaled Yagoub, Mohamed Zait, and
Mohamed Ziauddin. 2004. Automatic SQL tuning in oracle 10g. In Proceedings
CIKM ’22, October 17–21, 2022, Atlanta, GA, USA Krishna Kantikiran Pasupuleti, Dinesh Das, Satyanarayana R Valluri, & Mohamed Zait

of the Thirtieth international conference on Very large data bases - Volume 30 [21] Dana Van Aken, Dongsheng Yang, Sebastien Brillard, Ari Fiorino, Bohan
(VLDB '04). VLDB Endowment, 1098–1109. Zhang, Christian Bilien, and Andrew Pavlo. 2021. An inquiry into machine
[9] Oracle SQL Repair Advisor. https://docs.oracle.com/en/database/oracle/oracle- learning-based automatic configuration tuning services on real-world
database/21/admin/diagnosing-and-resolving-problems.html#GUID- database management systems. Proc. VLDB Endow. 14, 7 (March 2021), 1241–
D9F481EA-C9C0-4FFF-BC7E-47DD522E0C5F 1253. https://doi.org/10.14778/3450980.3450992
[10] SQL Quarantine in Oracle. https://docs.oracle.com/en/database/oracle/oracle- [22] Gerhard Weikum, Axel Moenkeberg, Christof Hasse, and Peter Zabback. 2002.
database/21/admin/diagnosing-and-resolving-problems.html#GUID- Self-tuning database technology and information services: from wishful
1CF7E2B7-1BF8-4907-889E-1107CAA83E51 thinking to viable engineering. In Proceedings of the 28th international
[11] Rafi Ahmed, Allison Lee, Andrew Witkowski, Dinesh Das, Hong Su, Mohamed conference on Very Large Data Bases (VLDB '02). VLDB Endowment, 20–31.
Zait, and Theirry Cruanes. 2006. Cost-based query transformation in Oracle. In [23] Agrawal, Sanjay & Bruno, Nicolas & Chaudhuri, Surajit & Narasayya, Vivek.
Proceedings of the 32nd international conference on Very Large data bases (2006). AutoAdmin: Self-Tuning Database Systems Technology. IEEE Data
(VLDB ‘06). VLDB Endowment, 1026-1036. Eng. Bull.. 29. 7-15.
[12] Automatic Indexing in Oracle. [24] Dana Van Aken, Andrew Pavlo, Geoffrey J. Gordon, and Bohan Zhang. 2017.
https://docs.oracle.com/en/database/oracle/oracle- Automatic Database Management System Tuning Through Large-scale
database/19/admin/managing-indexes.html#GUID-FAE533D7-9C9E-48C9- Machine Learning. In Proceedings of the 2017 ACM International Conference
9A61-EBC060BF3D70 on Management of Data (SIGMOD '17). Association for Computing
[13] Hints in SQL Server. https://docs.microsoft.com/en-us/sql/t-sql/queries/hints- Machinery, New York, NY, USA, 1009–1024.
transact-sql?view=sql-server-ver15 https://doi.org/10.1145/3035918.3064029
[14] Hints in MySQL. [25] Belknap, P., Dageville, B., Dias, K., & Yagoub, K. (2009). Self-Tuning for SQL
https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html Performance in Oracle Database 11g. 2009 IEEE 25th International Conference
[15] Query Optimization Guidelines in IBM DB2. on Data Engineering, 1694-1700.
https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.d [26] Rafi Ahmed, Randall Bello, Andrew Witkowski, and Praveen Kumar. 2020.
b2.luw.admin.perf.doc/doc/c0060613.html Automated generation of materialized views in Oracle. Proc. VLDB Endow. 13,
[16] HP NonStop SQL/MP Reference Manual. 12 (August 2020), 3046–3058. https://doi.org/10.14778/3415478.3415533
http://www.nonstoptools.com/manuals/SqlMp-Reference.pdf [27] Surajit Chaudhuri and Vivek Narasayya. 1998. AutoAdmin “what-if” index
[17] N. Bruno, S. Chaudhuri and R. Ramamurthy, "Power Hints for Query analysis utility. In Proceedings of the 1998 ACM SIGMOD international
Optimization," 2009 IEEE 25th International Conference on Data Engineering, conference on Management of data (SIGMOD '98). Association for Computing
2009, pp. 469-480, doi: 10.1109/ICDE.2009.68. Machinery, New York, NY, USA, 367–378.
[18] Nicolas Bruno, Surajit Chaudhuri, and Ravishankar Ramamurthy. 2009. https://doi.org/10.1145/276304.276337
Interactive plan hints for query optimization. In Proceedings of the 2009 ACM [28] Surajit Chaudhuri. 1998. An overview of query optimization in relational
SIGMOD International Conference on Management of data (SIGMOD '09). systems. In Proceedings of the seventeenth ACM SIGACT-SIGMOD-SIGART
Association for Computing Machinery, New York, NY, USA, 1043–1046. symposium on Principles of database systems (PODS '98). Association for
https://doi.org/10.1145/1559845.1559976 Computing Machinery, New York, NY, USA, 34–43.
[19] Hints in Oracle Database. https://doi.org/10.1145/275487.275492
https://docs.oracle.com/cd/B19306_01/server.102/b14211/hintsref.htm#i8327 [29] Jayant R. Haritsa and S. Sudarshan. 2019. Turbocharging database query
[20] Surajit Chaudhuri and Vivek Narasayya. 2007. Self-tuning database systems: a processing and testing. Commun. ACM 62, 11 (November 2019), 48–49.
decade of progress. In Proceedings of the 33rd international conference on https://doi.org/10.1145/3347861
Very large data bases (VLDB '07). VLDB Endowment, 3–14.

3450