This is a case i was working on a few days ago.I was asked to tune a specific query on our production server, so here is a quick test case to model the problem (i only kept the interesting part of the original query which was much more longer)
Unused Index although they seem not needed , dropping them must be carefully tested as it can have some side effect. As explained by Jonathan Lewis, due to index sanity check cardinality miss estimate can happen after dropping the unused index.
“The reason for this is the “index sanity check”. When the optimizer is doing its cardinality estimates, if it see equality conditions on the set of columns that make up an index it can use the distinct_keys statistic from the index in the calculation rather than using the standard calculation of multiplying together the num_distinct of the separate columns. ”
There is also a good example of the impact this can have on the query execution plan(switching join method from hash join to nested loop due to the drop of the estimated number of rows returned).Link
In this post i will show another interesting case when this can have an impact on query performance.As Franck Pachot Said :
The introduction of adaptive-ticks CPUs (Dynamic ticks) in UEK R4 represent a significant step forward on getting rid of the timer tick/interrupt (Full tickless operation).
“That interrupt is the CPU’s cue to reconsider which process should be running, catch up with read-copy-update (RCU) callbacks, and generally handle any necessary housekeeping.” Ref
This periodic timer interpret “interference” (based on CONFIG_HZ) have an effect on performance and power consumption which makes developers wish to abolish it. In previous version, a partial solution was used that consist on disabling timer tick for idle CPU which is controlled by the configuration option CONFIG_NO_HZ.This mode reduced considerably the power usage as it allowed idle CPU to stay in deeper c-state. What adaptive ticks feature bring us is the possibility to reduce the timer interrupt to 1 tick/second (1HZ) for non idle CPU having only one runnable task. This feature minimizes kernel overhead (up to 1%) and the potential latency problem , it was primarily targeted for High-performance computing (HPC) and real time application so it’s not necessary for every one.
For more info on Nearly full tickless operation please check this articles as most of the information here come from there :
TIME TO TEST :
- ORACLE 220.127.116.11.6
- OEL : 4.1.12-32.1.2.el6uek.x86_64
- 4 CPU : 2 sockets / 2 cores per socket Continue reading
I am pleased to announce that classroom (Only in Tunisia) and online training are now available 😀
Information on training schedule and registration details are available on the Training Page.
Last week i was called by multiple users signaling a total slowdown of the the “system”. After a few check i decided to trace one of the affected user action.There was only a single SQL statement consuming mostly of the time and it was as simple as this :
Recently when playing with adaptive cursor sharing i observed a strange behavior when activating the row source statistics.Here is a quick test case to demonstrate the finding : (Tested database 18.104.22.168.9 and 22.214.171.124)