-
Let’s take a look at the point within the 10053 trace which, albeit usually not critical, sometimes may be a tip turning the scales. You have surely noticed that a total cost reported in the trace involves two summands: IO_COST and CPU_COST, where although in real the latter being just a fraction of the entire…
-
While preparing the series of posts about Clustering Factor (aka CLUF in 10053 traces) I came across an interesting caveat which I decided to explore.I will make an attempt to explain its matter, although I encourage you to reach out to the part3 of the mentioned series and navigate to “Quantifying physical reads for low CLUF” and…
-
Resp: you might have spotted it “here and there” in the 10053 trace file.It may turn out important if, for example, all of sudden your SQL similar to the one below starts running in parallel (of what you may not be aware straight away), visibly slower – and most of all wasting I/O and CPU…
-
Analysis of joins with 10053 CBO trace This post continues from the previous one diving deeper into the challenges posed by a suboptimal SQL query that led the optimizer to select a Cartesian Join combined with an overly expensive Hash Join.But do not treat its content as limited to just a Cartesian Join.It will also…
-
One day, while browsing publicly available resources (blogs, white papers), I realized there’s a lack of easily accessible information on the following topic: How to map the cost-based optimizer (CBO) formulas and numbers to the SQL Plan for the most basic scenario — comparing index range scan access vs. full table scan. As we know,…
