Snapper used to require access to DBMS_LOCK, so it could sleep for X seconds between the “before” and “after” performance data snapshots. Now it is possible to get away without using DBMS_LOCK. Instead you will run Snapper twice, once for taking the “before” snapshot, then run your workload and then run Snapper again for taking the “after” snapshot and print the output.
So, the usual way of running snapper is this:
@snapper4 all 5 1 152
This would take 1 5-second performance snapshot SID 152′s V$ views.
With Snapper4 you can use the old way or just add BEGIN or END keywords to the 1st parameter, like this:
I have fixed most of the bugs that showed up during the Snapper launch party session and uploaded the new version (v4.02) of Snapper here:
I have also uploaded the launch party hacking session video to enkitec.tv:
I have not updated the snapper documentation yet, but here are the main improvements:
Troubleshooting Runaway Processes
Everyone reads Tanel Poder’s material—for good reason.
I took particular interest in his recent post about investigating where an apparently runaway, cpu-bound, Oracle foreground process is spending its time. That article can be found here.
I’ve been meaning to do some blogging about analyzing Oracle execution with perf(1). I think Tanel’s post is a good segue for me to do so. You might ask, however, why I would bother attempting to add value in a space Tanel has already blogged. Well, to that I would simply say that modern systems professionals need as many tools as they can get their hands on.
Tanel, please ping me if you object, for any reason, to my direct links to your scripts.
Here’s a little follow-on from Friday’s posting. I’ll start it off as a quiz, and follow up tomorrow with an explanation of the results (though someone will probably have given the correct solution by then anyway).
I have a simple heap table t1(id number(6,0), n1 number, v1 varchar2(10), padding varchar2(100)). The primary key is the id column, and the table holds 3,000 rows where id takes the values from 1 to 3,000. There are no other indexes. (I’d show you the code, but I don’t want to make it too easy to run the code, I want you to try to work it out in your heads).
I run the following pl/sql block.
Followers of the blog will know I dig virtualization. I first ran Oracle in virtualized environments over a decade ago.
In my current company there is a strong virtualization presence in the Windows space. Pretty much all Windows servers, including those running MS SQL Server, are actually VMs running on a VMware farm. The UNIX/Linux side is a little different. Most stuff is still done on physical boxes and what little virtualization is done, uses CentOS and KVM for freebie open source solutions.
There are a lot of architectural changes going on at the moment and I’ve been pushing *very hard* for a switch to the virtual infrastructure (VI) for all our middle tier servers and a few of our databases. It is looking very likely (but not guaranteed) that this will happen.
I’ve recently realized that I hadn’t posted the second version of my presentation — Under The Hood of Oracle Clusterware 2.0: Grid Infrastructure, codenamed UTHOC2. I think it would be very useful as I still see lots of questions being asked, and UTHOC1 covers Oracle RAC 10g and 11gR1 only. 11g Release 2 brought many changes in the clusterware, and the slides needed some good refresh.
Update 7-May-2013: Almost 100 people filled in the survey and here are the result:
It’s very easy to get a lot of information from an AWR (or Statspack) report – provided you remember what all the numbers represent. From time to time I find that someone asks me a question about some statistic and my mind goes completely blank about the exact interpretation; but fortunately it’s always possible to cross check because so many of the statistics are cross-linked. Here’s an example of a brief mental block I ran into a few days ago – I thought I knew the answer, but realised that I wasn’t 100% sure that my memory was correct:
In this Load Profile (for an AWR report of 60.25 minutes), what does that Transactions figure actually represent ?
The promised hacking session about Exadata performance troubleshooting will happen on Thursday 21st February 9am-11am PST (2 hours). I will show a number of examples and demos where the Exadata Snapper shows what was going on in storage cells when running Smart Scans or just doing IO.
Register here (free stuff!):
I will post the scripts on the day of this session.
I was recently involved in an upgrade project to go from 22.214.171.124 to 126.96.36.199 on an Exadata V2. We hit some snags during the upgrade specifically related to OEM 12c Cloud Control. We performed an out-of-place upgrade and OEM 188.8.131.52.0 had some difficulty in dealing with this.
12c Cloud Control is supposed to run a daily check that looks for new targets on each server. When it finds something new, it places this in a queue to wait for admin approval. With a single click, you can promote the newly discovered target to an OEM managed object.