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.
I have a release of SLOB in the works that will include this awr_info.sh as well as improved data loader and improvements to the driver script (runit.sh) that includes optional, tunable think time between iterations of the SLOB work loop in slob.sql. For the time being please get a copy of the patched version.
This version of awr_info.sh also gleans and outputs logical read (SGA buffer pool cached block accesses) data.
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.
Thanks to everyone who attended my August 27th webinar entitled In Search of Plan Stability - Part 1. You can download the presentation materials from these links:
I'll update this post to provide a link to the recording shortly.
Come back in November for Part 2. Hope to see you then!
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):
Oracle’s 22.214.171.124 was released a few weeks ago (You can download it from OTN here: Oracle 126.96.36.199 Download). While technically a minor point release, it contains a couple of major features that would normally be rolled out in a more substantial version change like 12cR2 or perhaps V13. Of course the most highly anticipated feature is a new option (Oracle In-Memory Option) that provides a column oriented, in-memory store. Enkitec was in the Beta program, so we’ve been testing it out for quite a while now and we are impressed.
As well as losing the ACED OpenWorld confirmation email, it turns out my website/mailbox move also caused me to lose the email about being accepted on the OTN APAC Tour 2014. I saw a tweet this morning saying that I was on the agenda for the NZOUG event and checked with Francisco to see what was going on. That’s when I found out that yet another important email had gone missing…
The good news is I had already agreed the time off work, so everything is good for the tour.
When installing Enterprise Manager 12c, the host value can come from a number of places for different applications/tiers. For most, it comes from the environment variable $ORACLE_HOSTNAME, (for Windows Servers, %ORACLE_HOSTNAME%).
As much as KSCOPE 14 fixed any and all Low-T levels, it couldn’t do anything for our the WiFi problems we were experiencing back in May. I’ve been a telecommuter for almost 4 straight years now and was quite frustrated when our WiFi service became dismal back then.