-
For years, SQL Plan Management was a powerful but somewhat manual tool in the DBA’s belt — capture baselines, evolve them, accept or reject new plans… rinse and repeat. It worked, but it required attention.With 23ai, Oracle takes a bold step toward self-driving databases: Automatic SQL Plan Management. The database now watches for regressions, evaluates…
-
Short reminder, in the two previous articles I made up two test scenarios of delving into the Auto SQL Plan Management. In the first part I constructed some fairly obvious conditions for Automatic SQL Plan Management to operate — it worked exactly as expected.The choice was based on obvious metrics: lower CPU usage, fewer logical…
-
In the previous article I went through setting up the Auto-SPM functionality, so turned the SPM to true “auto”. I then constructed some fairly obvious conditions for Automatic SQL Plan Management to operate.And yes — it worked exactly as expected. The engine kicked in on its own, activated a clearly better SQL plan, and did…
-
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…
-
This post is the continuation of the previous part True price of High Clustering Factor: elapsed time, SGA and CPU This time let’s try to quantify the usage of the resources applying much broader index range scan.I’ll force retrieving 10% (1 million) of rows and will pay close attention to :– Elapsed times with low…
-
This post is the continuation of the previous part. Clustering Factor – tests with 10046 Let’s go through the cases represented by SELECT statements and examine the true effort measured with the number of physical reads which are hidden behind a query retrieving its data from the table, yet by the means of either one:…
-
This post is the continuation of the previous part. Clustering Factor – tests with block dumps My test environment comprises a table with 10 million rows and three columns with two indexes:– ID_SORTED (unique, generated as sorted) with the index on it– ID_MESS (almost unique, generated as scattered) with the index on it– PAD (filler…
-
Clustering Factor – theory Some time ago I wrote a post diving into, what I like to call the “younger siblings” of Clustering Factor (aka CLUF – this is how it’s called in the 10053 trace): AVG_DATA_BLOCKS_PER_KEY and AVG_LEAF_BLOCKS_PER_KEY—While they represent close relationship to Clustering Factor, the CLUF tends to be more recognized in the…
-
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…
