Issues with OICA/OIC (OPTIMIZER_INDEX_COST_ADJ/OPTIMIZER_INDEX_CACHING) parameters have already been mentioned many times. Recently I’ve noticed one more and I think I didn’t see this case somewhere else on the Internet so I’ll share it.
Here’s a simple table T1 holding 1M rows with the indexed column X having 10 distinct values:
For only $299, you can access Virtual IOUG Collaborate 13 individually or set up a conference room at your company for the whole team. There will be two tracks broadcasted, so if you have demand for both tracks, it makes sense to purchase two access passes and setup two tracks broadcasted in parallel in your office so that members of your team can individually choose what to attend. I think that’s a steal even if you want to purchase this package individually.
Jonathan Lewis has already written about this behavior from the angle of PARALLEL hints.
I’m writing a similar article just because the word FORCE in the ALTER SESSION FORCE PARALLEL QUERY syntax. Force should mean that some behavior would always happen (when possible), right? Let’s test:
SQL> CREATE TABLE t AS SELECT * FROM dba_objects; Table created. SQL> CREATE INDEX i ON t(owner); Index created. SQL> @gts t Gather Table Statistics for table t... PL/SQL procedure successfully completed.
Now let’s “force” the parallel query in my session, run the query and check the execution plan:
Here’s an oddity that I ran into a little while ago while trying to prepare a sample trace file showing a particular locking pattern; it was something that I’d done before, but trace files can change with different versions of Oracle so I decided to use a copy of 22.214.171.124 that happened to be handy at the time to check if anything had changed since the previous (11gR1) release. I never managed to finish the test; here are the steps I got through:
I don’t have much time for a thorough blog post, so I’ll just paste in an example output of my asqlmon.sql script, which uses ASH sql_plan_line columns for displaying where inside your execution plan response time has been spent. Why not just use Oracle’s own SQL Monitoring reports? Well, SQL monitoring is meant for “long running” queries, which are not executed very frequently. In other words, you can’t use SQL Monitoring for drilling down into your frequently executed OLTP-style SQL. I am copying my recent post to Oracle-L mailing list here too:
The main performance impact of the old GATHER_PLAN_STATISTICS / statistics_level = ALL instrumentation came from the fact that expensive timing (gettimeofday()) system calls were used for getting A-Times of row sources.
Oracle Database implements a family of STDDEV functions for computing the standard deviation from the mean. If you think of the mean as beginning to paint a picture of the underlying data, then standard deviation is another brush-stroke toward a fuller picture that will help you draw meaning from the data you're studying.
AMIS is spending a lot of effort keeping our people up-to-date with the latest knowledge needed to help our customers the best way we can. Traditionally we also always try to share our knowledge with customers and others, via social media or conferences, and while abroad learning from others at the same time. It is …
Were you thinking, “I’ve got nothing better to do this weekend than to download the latest version of VirtualBox and update the guest additions on all my VMs”? Well your luck is in!