Professional Documents
Culture Documents
Dena Feinblat
Global Customer Services, EMEA Database Performance
Wrong Results
Wrong results issues are important since they can easily destroy confidence in
everything else however unrelated.
Customers cannot afford to return wrong results especially in financial situations.
The uncertainty of results is often as bad as actual wrong results.
Wrong results may be a result of how the optimizer puts the execution plan
together.
Example of Optimizer Wrong Results are: Missing Predicates or wrongly derived
predicates, Invalid Transformations
Sometimes the reason is not related to the optimizer. The wrong results maybe
related to different NLS settings, XDB , corruption (usually logical)
This presentation only deals with Wrong Results related to the optimizer
What is the nature of Wrong Results ?
• Different databases
• Different optimizer statistics or different environment/optimizer
parameters can result in wrong results being encountered
Consistently
Occurs consistently for all users
• Intermittently
• Certain users always get good results and others wrong results
• Does same session get intermittently wrong and correct results
• Is there a pattern ?
Information to Gather
It is vital to gather diagnostics that illustrate the query returning both the
correct and the wrong results
• Query Text
• Run-time Traces (10046 trace)
• Execution Plans and Optimizer Information (Explain Plan ,10053 trace)
• Workarounds and Environment
Run Time Traces
• 10046 trace with binds and waits (i.e. 10046 trace level 12)
• Recommended Method for Obtaining 10046 trace for Tuning (Doc ID 376442.1)
• Run time traces provide information about what actually happens when the query is
run.
• If rows are missing or added, it may be possible to spot this in the row source trace
and attribute this to a particular operation.
• Additionally comparing the run time trace with the optimizer estimate (explain plan)
*may* indicate implementation difficulties
Run Time Trace - Example
• Correct Results
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.27 0.31 0 0 0 0
Execute 1 0.01 0.00 0 0 0 0
Fetch 128 3.43 16.59 9198 10174 0 1893
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 130 3.71 16.90 9198 10174 0 1893
• Execution plans shows the access path that the optimizer has decided upon in
order to optimizer the query performance.
• If an invalid access paths is produced, predicates are missing or wrongly derived
or invalid transformations have occurred, then by comparing the access paths
for correct and incorrect cases a pattern or reason may be spotted.
• Check the execution plan for any kind of transformations or syntax that may be a
“different”
• Examples: "hash group by", VW_GBF_1 (group by placement) , ANSI query, function-
based index
• Check for constructs in predicate information that may look problematic
• Example: Null is not null
Execution Plan - Example
• Wrong Results
Bug 5462687: CHECK CONSTRAINT CAUSES WRONG RESULTS TO OCCUR
sqlplus scott/tiger
• If a potential issue has been identified, then there may be parameters or patches
that resolve the issue.
In-House Testing
• It is often easier and faster to solve wrong results by getting a testcase (including
data) in order to reproduce, test and diagnose in-house
• In this way certain workarounds and patch fixes can be tested without having to
involve customer with unnecessary “ping-ponging” and needless guessing
• Testcase should include
• pfile/spfile information
• Export dump file including data (or any other way to reproduce data)
• DDL for views and functions (sometimes errors received from export)
• Optimizer Statistics
Transferring Optimizer Statistics to Support (Doc ID 242489.1)