"Latch free"/"Real-time plan statistics latch" wait events seen during slow system performance

Tonight provides us an opportunity to learn more about the SQL Monitor interface from MOS document "Slow Performance Featuring Contention on "latch free" with "Real-time plan statistics latch" Having the Most Sleeps and Causing High Operating System Activity" by searching for article ID 2030320.1 which will lead you not only to the Database SQL Tuning Guide if you were not already familiar with it, but ALSO the section detailing the Real-Time SQL Monitoring and Real-Time Database Operations.  Why would you be concerned with this?  Well, do you know how your system is setup to monitor SQL?  Would you like to AND feel comfortable that this feature will not cause you problems in the future?

Weekend Learning: 12c and SQL performance with In Database Row Archiving

This weekend make sure that you read the My Oracle Support document "Potential SQL Performance Degradation When Using "In Database Row Archiving"" from note ID 1579790.1 so that you are aware of a. how In Database Row Archiving works and b. how it affects SQL performance tuning.  Everybody wants to upgrade right?  Everybody wants to use the latest and greatest features right?  Find out what happens when you do both with 12c and In Database Row Archiving!

11.2.0.4: Parse time can be increased for same query on 11.2.0.3

If you have been in the Oracle space for any amount of time you will know that a new version or the latest files can actually introduce problems, but even knowing that it is surprising to read MOS article "Increased Parse Times for Queries Using Subqueries Containing Multiple OR And AND Statements on 11204 Compared to 11203" from note 1980761.1!  Not only do we learn what is going on here, but we get to learn a few ALTER SESSION commands that we may not have otherwise had to know about plus this is a good warning that your performance may be suffering for no other reason than you are on the latest patchset of 11gR2!

Performance tuning: Rows or blocks?

In today's article from Ric Van Dyke he teaches us some of the finer points of performance tuning by making us question some "conventional wisdom" about tuning for rows.  With a great example showing two identical tables that have their data packed differently, he is able to show how the focus on row returns is not always the best idea for SQL performance tuning.  Why is this so important?  Ric gave a great talk at Hotsos this year that opened my eyes to how Oracle deals with blocks and combined with the information in this article gives me a better idea of how to measure and tune our performance!

Jonathan Lewis on how to hint

With this post Jonathan shares a recent example of how hinting can not work, go horribly wrong, and what you need to be doing in order to resolve the issue by addressing not just 1 hint but several in order to have the CBO actually do what you want it to be doing.  This also has a link to an article by him on SQL Baselines which starts a very interesting discussion in the comments of the post on if you should manually code in the hints (with comments of course) or introduce SQL Baselines instead.  I lean towards the code updates, because having it available to us visually when there is a problem instead of having another step of checking for SQL Baselines is potentially a better avenue since it would be easy for us to forget about that step and be spinning our wheels for hours.

Not all tests are created the same

Coming at us from this blog entry, the author wants us to know that the SQL Tuning certification test I mentioned a few months ago is not a joke and should be taken quite seriously.  Great news and a warning for me personally, because this is something I see as being on my horizon over the next 12-18 months.