(the details are investigated and specific to Oracle’s database implementation on Linux x86_64)
Exadata IO: This event is not used with Exadata storage, ‘cell single block physical read’ is used instead.
Despite p3 listing the number of blocks, I haven’t seen a db file sequential read event that read more than one block ever. Of course this could change in a newer release.
This just in from OTN Database Forum – a surprising little bug with “group by elimination” exclusive to 12c.
alter session set nls_date_format='dd-Mon-yyyy hh24:mi:ss'; select /* optimizer_features_enable('184.108.40.206')*/ trunc (ts,'DD') ts1, sum(fieldb) fieldb from ( select ts, max(fieldb) fieldb from ( select trunc(sysdate) - 1/24 ts, 1 fieldb from dual union all select trunc(sysdate) - 2/24 ts, 2 fieldb from dual union all select trunc(sysdate) - 3/24 ts, 3 fieldb from dual union all select trunc(sysdate) - 4/24 ts, 4 fieldb from dual union all select trunc(sysdate) - 5/24 ts, 5 fieldb from dual ) group by ts ) group by trunc (ts,'DD') /
You might expect to get one row as the answer – but this is the result I got, with the execution plan pulled from memory:
This is going to be a “KISS”, (Keep it Simple, Silly) post. I was offered a second Windows cluster to test on when my original one was required for QA. It was a gracious offer, but I also found out why a cluster should be kept simple and this cluster was anything but simple. Many times, issues are created and we’ll never see them coming until we go through the pain and the EM
One response to my series on reading execution plans was an email request asking me to clarify what I meant by the “order of operation” of the lines of an execution plan. Looking through the set of articles I’d written I realised that I hadn’t made any sort of formal declaration of what I meant, all I had was a passing reference in the introduction to part 4; so here’s the explanation.
By “order of operation” I mean the order in which the lines of an execution plan start to produce a rowsource. It’s worth stating this a little formally as any other interpretation could lead to confusion; consider the following simple hash join:
BLOG UPDATE 2014.09.11: Please note: the following is a link to a more recent update of the awr_info.sh script. This version adds DB Time, DB CPU and Logical I/O: click here. The MD5 sum for this version of awr_info.sh is: a28a38b11040bb94f08a8f817792c75c
The SLOB kit comes with a little script that extracts interesting information from the awr.txt file produced at the end of a SLOB test. This is just a quick blog entry to point folks to a patched version of awr_info.sh that works properly with all Oracle Database 11g releases as well as Oracle Database 12c.
Oracle changed AWR format in the 220.127.116.11 and 12c releases so the old awr_info.sh script (in the publicly available SLOB kit) has been faulty for some time now.
This is a quick blog post to help folks that are testing with SLOB at high user (session) counts. The situation may arise where you are testing SLOB on a large configuration, with or without SQL*Net, and the SLOB driver (runit.sh) is failing to produce Automatic Workload Repository (a.k.a AWR) reports.
This problem will generally be seen on RHEL 6 variants that implement the much maligned /etc/security/limits.d/90-nproc.conf method of preventing fork bombs. For more information on this configuration file please refer to Red Hat bug 919793.
If you are not getting AWR reports under the condition I describe then the problem is most likely due to 90-nproc.conf short circuiting the ulimit(3) tuning you’ve established.
A few more 12c articles went live over the last few days…
The DMU and In-Database Archiving are from the OCP syllabus. The Invisible Columns stuff seemed like a natural thing to mention, when discussing the In-Database Archiving.
The 12c journey continues…
A comment on one of my early blogs about the 12c in-memory database option asked how Oracle would deal with read-consistency. I came up with a couple of comments outlining the sort of thing I would look for in a solution, and this note is an outline on how I started to tackle the question – with a couple of the subsequent observations. The data is (nearly) the same as the data I generated for my previous article on the in-memory database (and I’m running 18.104.22.168, of course):