Top 60 Oracle Blogs

Recent comments

June 2016

Using OSWatcher for system diagnostics

OSWatcher is a superb tool that gathers information about your system in the background and stores it in an (optionally compressed) archive directory. As an Oracle DBA I like the analogy with statspack: you make the tool available on the host in a location with – very important – enough available disk space and then start it. Most users add it to the startup mechanism their O/S uses- SysV init, upstart, or systemd for example on Linux to allow it to start in the background. OSWatcher will then gather a lot of the interesting O/S related statistics that you so desperately need in an “after the fact” situation. There are plenty of reasons where you might want that information.

Example use cases

You Scratch Your Head And Ponder Why It Is You Go With Maximum Core Count Xeons. I Can’t Explain That, But This Might Help.

Folks that have read my blog for very long know that I routinely point out that Intel Xeon processors with fewer cores (albeit same TDP) get more throughput per core. Recently I had the opportunity to do some testing of a 2-socket host with 6-core Haswell EP Xeons (E5-2643v3) connected to networked all-flash storage. This post is about host capability so I won’t be elaborating on the storage. I’ll say that it was block storage, all-flash and networked.

Even though I test myriads of systems with modern Xeons it isn’t often I get to test the top-bin parts that aren’t core-packed.  The Haswell EP line offers up to 18-core parts in a 145w CPU.  This 6-core part is 135w and all cores clock up to 3.7GHz–not that clock speed is absolutely critical for Oracle Database performance mind you.

Gluent New World #04: Next Generation Oracle Database Architectures using Super-Fast Storage with James Morle

Update: The video recording is available in Vimeo (see below)

Other relevant reading is James’es Sane SAN 2010 whitepaper and his legendary book!

Bitmap Counts

A question came up on the Oracle-L list server a few days ago about a query whose plan showed several bitmap operations. The problem was that the A-Rows column reported by a call to dbms_xplan.display_cursor() was showing numbers that semed to be far too small. In fact the query was producing a parallel execution plan, so the “actuals” for the parallel server operations were reporting zeros because the OP had used the “allstats last” formatting option rather than just “allstats” – but the numbers were still far too small even after this error had been corrected.

Moving to Seattle! Our beautiful rental available in San Francisco


More news coming, but for now, we (family and I) are moving to Seattle! We will be giving up our gorgeous rental house in San Francisco thus it will be available to the next lucky family.

Beautiful large house a block from San Francisco’s most prestigious neighborhood St Francis Woods.

New Canberra Event

For those that are based in or near Canberra, I’ve created a new page on my website to host information on upcoming events that might be of interest to you. The first of these is a session for Oracle partners on the data challenges that customers face. Just to give you a few more reasons to come along, it’s also the first in a series of Beer and Pizza nights we will be hosting, so have a look at the information here and RSVP to Kylie (email address is on that page) if you’re interested in coming!

The post New Canberra Event appeared first on

Uniquely parallel

Here’s a surprising (to me) execution plan from – parallel execution to find one row in a table using a unique scan of a unique index – produced by running the following script (data creation SQL to follow):

CPU profiling using perf utility in Linux

After reading my blog entry about a performance issue due to excessive HCC decompression ( Accessing HCC compressed objects using index access path, a reader asked me about the CPU profiling method I mentioned in that blog entry. I started responding to that comment, and realized that the response was too big for a comment. So, in this blog entry, I will cover basics of the CPU profiling in Linux. Other platform provides similar utilities, for example, Solaris provides an utility dtrace.

Tool Box

Parsing … no big deal eh ?

Most of us have probably seen the standard demo when it comes to emphasizing the need for sharable SQL, aka, using bind variables where appropriate.  The demo traditionally compares two similar scripts, where one of them generates a lot of SQL statements with literals, and the other recasts the same script with bind variables for dramatic improvement.

Here’s a simple version I’ve whipped up: