Search

OakieTags

Who's online

There are currently 0 users and 38 guests online.

Recent comments

Affiliations

Oakies Blog Aggregator

Up the Villa…

I had a bit of good news the other day. Nephew #2 (6 years old) is now playing for Aston Villa Academy. He’s quite small for his age and he trialed with a group of boys a year older than him, so my brother said he looked tiny and the kit they gave him was gigantic on him. He’s used to playing with Nephew #1, who’s just turned 10, so playing with bigger kids doesn’t phase him and he’s a bit more cocky than Nephew #1, which they seem to like at these places. Anyway, at the end of the session they said they want him. They are not allowed to sign exclusively until they are 8 years old, so he can keep playing for Wolverhampton Wanderers Academy and Telford.

So now I have to support:

  • West Brom and Telford because Nephew #1 plays for them.
  • Villa, Wolves and Telford because Nephew #2 plays for them.
  • Man United because Nephew #1 and #2 (and their parents) support them.

I don’t even like football really, but if they can keep improving for the next 10 years and be in the freakishly small percentage of people that actually make it to become professional footballers, I’ll be able to live in the manner I would like to become accustomed to. Muhahaha (little finger in the corner of the mouth)… :)

Cheers

Tim…




I wish

Here are a few thoughts on dbms_stats – in particular the procedure gather_index_stats.

The procedure counts the number of used leaf blocks and the number of distinct keys using a count distinct operation, which means you get an expensive aggregation operation when you gather stats on a large index. It would be nice efficiency feature if Oracle changed the code to use the new Approximate NDV mechanism for these counts.

Then there are a couple of additions I’d like to see to the actual stats gathered: the average space used by a key (including the rowid), calculated as sum(space used) / count(index entries), so that we could do a quick comparison of the index size compared to the space allocation without resorting to complex estimates. The code would, of course, have to handle the prefix and the tail for compressed indexes, so possibly it would be better to record the two figures for space used, and include the figure for number of prefix entries. Note, the number of prefix entries is not the same as the number of distinct values for prefixes, as the same combination of prefix values may appear in several consecutive leaf blocks – and this brings me to another feature enhancement, to match SQL Server.

For a multi-column index, how about a new structure to hold the number of distinct values for each of the possible prefixes for that index. This could piggy-back on the existing extended statistics feature, and wouldn’t be too expensive to operate if it used the approximate NDV mechanism; it could, of course,  be a bit of a threat since this approach would be using some of the 1,000 column limit that you’re allowed for a single table; there are also a few messy details to handle relating to multiple indexes starting with the same combination of columns in different orders – and the side effects of dropping one index from a set with such an overlap.

Footnote 1: When gathering stats for a Unique index, the code copies num_rows to distinct_keys, so that’s one aggregation optimisation already in place.

Footnote 2: There may be some empty blocks which don’t get counted – see my book Cost Based  Oracle – Fundamentals for the impact this can have on costing index fast full scans … I need to check if the optimizer still uses the number of used leaf blocks to cost the fast full scan, or whether it has switched to using the high water mark of the segment.

Getting Started with Dtrace

Structure of a dtrace script

#!/usr/sbin/dtrace -s

something_to_trace
/ filters /
{ actions }

Something_else_to_trace
/ filters_optional /
{ take some actions }

The script has sections that fire if the specified probe fires in the OS. For example, if  do a  send over TCP then my “something_to_trace” could be a probe (an event) called “tcp:::send” . I could further filter by receiving machine’s IP address. Then when a packet is sent over TCP and the receiver is the IP in the filter I can take some actions like state the size of the packet.

What can I trace?  What are the possible “something_to_trace”, ie the probes?
To get a list run of OS probes, run

  dtrace -l
    -l = list instead of enable probes
The list will be long. It’s a good to have some idea what one is searching for like “io”, “tcp”, “zfs” etc and grep for areas of interest.
The output format is 5 columns , first the probe id  and followed by the name in 4 parts
 id  provider  module  function  name
One can get the list of probes just for a subset using “-ln” flag and include part of the probe  either provider, module, function or name.  The provider, module,function and name are concatenated together with colons (:).  I commonly only use provider and name, for example
  sudo dtrace -ln tcp:::
   ID   PROVIDER            MODULE                          FUNCTION NAME
 7301        tcp                ip                    tcp_input_data receive
 7302        tcp                ip                tcp_input_listener receive
 7303        tcp                ip          tcp_xmit_listeners_reset receive
 7304        tcp                ip                   tcp_fuse_output receive
    -n = Specify probe name to trace or  list
Now if I have a specific probe I want to trace, I can get more information about the data available for that probe using the verbose flag as in:
    dtrace -lvn tcp:ip:tcp_input_data:receive
       ID   PROVIDER            MODULE                          FUNCTION NAME
     7301        tcp                ip                    tcp_input_data receive

        Argument Types
                args[0]: pktinfo_t *
                args[1]: csinfo_t *
                args[2]: ipinfo_t *
                args[3]: tcpsinfo_t *
                args[4]: tcpinfo_t *
Now I see the arguments for this probe and I have access to these arguments when this probe fires, but what do these arguments contain? Here a crucial trick. You can look up these arguments on:
        http://src.illumos.org

(also, can look  in /usr/lib/dtrace  or previously http://cvs.opensolaris.org/source/)

For example, I see that  args[3] is “tcpsinfo_t. ” What is “tcpsinfo_t?”   I can type “tcpsinfo_t” into the Symbol field as in

http://src.illumos.org

I get a list of appearances of this structure. I click on the first one as it looks like it’s probably the structure definition and get:

So now I can see the contents of the structure and variable  types of each field in the structure. From the above I see the receivers address is “tcps_raddr” in arg[3] so I can now filter for the receivers address.

A good example of trying to understand dtrace probes and arguments is found here: http://blogs.oracle.com/observatory/entry/d_script_archeology

And now I’m ready to put together a script accessing the contents of these structures

#!/usr/sbin/dtrace -s
#pragma D option quiet
tcp:::send
/ args[3]->tcps_raddr == "192.168.1.1" /
{ printf("send     %6d \n",args[2]->ip_plength);
}
tcp:::receive
/ args[3]->tcps_raddr == "192.168.1.1" /
{ printf("receive %6d  \n", args[2]->ip_plength );
}

(added the line “#pragma D option quiet” to suppress the default output of the names of probes that fired and limit the output to only the print statements)

My main point of this blog was to show how to get a list of OS probes to trace and for those probes how to find out the contents of  the data structures available for that probe. The access to these structures depends on “translators.” See

http://www.solarisinternals.com/wiki/index.php/DTrace_Topics_Features

The translators are defined in /usr/lib/dtrace.  So instead of looking up structures in the Illumos source one can look for them in the translator files in /usr/lib/dtrace. The translators provide a stable way to access the OS structures. The OS structures can be accessed directly without the translators but it’s more complicated and not stable across versions of the OS not to mention types of OS.

For Oracle,  there are no translators though you could write them.

For Oracle, to get an idea what you can trace, get the PID of a running Oracle process, say in my case 11602

    dtrace -ln pid11602:oracle:kcbr*:

The list will be quite large. It more or less requires knowing what you are looking for. Above I give “kcbr*”  for Kernel Cache Buffer Recent. Checkout http://www.orafaq.com/wiki/X$_Table  for an idea of the layers that make up the start of some of the function names. ( it would be a lot more fun trace Oracle with DTrace if one had access to the source!)

The best references for  dtrace are first the dtrace book  and dtrace community then Brendan Gregg’s blog at:

If you are specifically interested in TCP then Alan Maguire’s blog is good

And for some specific examples with Oracle check out:

A few other notes:

Useful variables that can be filtered on or printed out

  • pid – process id
  • execname – executable name
  • timestamp – timestamp in nano-seconds
  • tid – thread id
  • cwd – current working directory
  • probeprov, probemod, probefunc, probename – probe’s provider, module, func and name

Dtrace variables (from Brendan’s blog see: http://dtrace.org/blogs/brendan/2011/11/25/dtrace-variable-types/ )

#444444; font-family: Arial,Verdana,sans-serif; font-size: 13px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 20px; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; background-color: #ffffff;">

DTrace variable types, in order of preference:

type prefix scope overhead multi-CPU safe example assignment
aggregation @ global low yes @x = count();
clause local this-> clause instance[1] very low yes this->x = 1;
thread local self-> thread medium yes self->x = 1;
scalar none global low-medium no[2] x = 1;
associative array none global medium-high no[2] x[y] = 1;

 

The above list is a nice cheat sheet.
I started off using scalar global variables but the right way is to use aggregations, clause local and thread local variables
Definitely read about aggregates when getting started with Dtrace as aggregates are key to getting useful data out of dtrace

http://wikis.sun.com/display/DTrace/Aggregations

For formatting output data, wrap scripts with something like Perl and post process the data. Here is an example of wrapping (piping) dtrace data to perl and having perl format the output (Perl code is set up to aggregate similar types of data coming from I/O, ZFS an NFS, but  below is just the code for monitoring NFS, )

/usr/sbin/dtrace -n '
#pragma D option quiet
nfsv3:::op-read-start, nfsv3:::op-write-start ,nfsv4:::op-read-start {
        tm[args[1]->noi_xid] = timestamp;
        sz[args[1]->noi_xid] = args[2]->count    ;
}
nfsv4:::op-write-start {
        tm[args[1]->noi_xid] = timestamp;
        sz[args[1]->noi_xid] = args[2]->data_len ;
}
nfsv3:::op-read-done, nfsv3:::op-write-done, nfsv4:::op-read-done, nfsv4:::op-write-done
/tm[args[1]->noi_xid]/
{       this->delta= (timestamp - tm[args[1]->noi_xid]);
        this->type =  probename == "op-write-done" ? "W" : "R";
        @nfs_tm[this->type]=sum(this->delta);
        @nfs_mx[this->type]=max( (this->type == "R" ? this->delta : 0));
        @nfs_mx[this->type]=max( (this->type == "W" ? this->delta : 0));
        @nfs_ct[this->type]=count();
        @nfs_sz[this->type]=sum(sz[args[1]->noi_xid]);
        tm[args[1]->noi_xid] = 0;
        sz[args[1]->noi_xid] = 0;
}
profile:::tick-1sec
{      printa("nfs_tm ,%s,%@d\n",@nfs_tm);
       printa("nfs_mx ,%s,%@d\n",@nfs_mx);
       printa("nfs_ct ,%s,%@d\n",@nfs_ct);
       printa("nfs_sz ,%s,%@d\n",@nfs_sz);
       clear(@nfs_mx);
       clear(@nfs_tm);
       clear(@nfs_ct);
       clear(@nfs_sz);
       printf("!\n");
}
' | perl -e '
while (my $line = ) {
       $line=~ s/\s+//g;
       if ( $line eq "!"  ) {
          printf("--|------| %10s %10s %10s %10s\n", "avg_ms","MB/s","mx_ms","count");
          foreach $type ('R','W') {
            foreach $class ('nfs') {
             $ct=${$class . "_ct"}{$type}||0;
             $sz=${$class . "_sz"}{$type}||0;
             $mx=${$class . "_mx"}{$type}||0;
             $tm=${$class . "_tm"}{$type}||0;
               if ( $ct > 0 ) {
                   $ms=(($tm/1000000)/$ct);
                   printf("$type | $class  : %10.2f",$ms);
               } else {
                   printf("$type | $class  : %10.2f",0) ;
               }
               printf(" %10.2f",$sz/(1024*1024));
               $mx_ms=$mx/1000000;
               printf(" %10.2f",$mx_ms);
               printf(" %10d",$ct);
               print "\n";
            }
          }
       } else {
          ($area, $r_w, $value)=split(",",$line);
        ${$area}{$r_w}=$value;
       }
}'

 

PS I tried using AWK for formating but the data seems to get buffered so there isn’t immediate output. I tried using “fflush” and print /dev/stdout but couldn’t get it to consistently work

dtrace [code] | awk  '
{
       # hack to get AWK to flush out immediately
       printf("%s\n",$0) > "/dev/stdout"
       close("/dev/stdout")
       #fflush(stdout)
       #system("")
}'

 

PS one thing to keep in mind is overhead. The overhead of Dtrace is small but it's not zero. See

http://dtrace.org/blogs/brendan/2011/02/18/dtrace-pid-provider-overhead/

For more info. From the above link from Brendan Gregg, here is the key part:

I'd suggest considering pid provider overhead as follows:

Don't worry too much about pid provider probe cost at < 1000 events/sec.
At > 10,000 events/sec, pid provider probe cost will be noticeable.
At > 100,000 events/sec, pid provider probe cost may be painful.

Let's discuss these using the 6 us per probe result from the previous tests. This could be faster (~2 us) or slower (> 15 us) depending on architecture and the probe action.

  • at 1000 events/sec, that could cost 6 milliseconds of CPU time. If the application was 100% on-CPU, it may slow by 0.6% - ie, don't worry.
  • At 10,000 events/sec, that could cost 60 milliseconds of CPU time. For a 100% on-CPU application, then the slow down may be 6%. If it was idle some of the time (systems often are), then the overhead may be less, as there are spare cycles to run DTrace (really depends on the location of the probe in the code-path, though).
  • At 100,000 events/sec, the CPU cost could be 600 milliseconds. This can significantly slow down an application. Whether that's a problem depends on the app and its function - how sensitive it is to latency.

 

DTrace is quite terse and limited in actions and functions. As I said above, for formatting data, wrap DTrace in perl and do calculations and formating in perl. Why? A few examples

  • DTrace doesn't have floating point operations
  • DTrace aggregate arrays don't have a method allowing you to query the keys and step through them, thus there is no way to do calculations on values in one aggregate array with values in another.

Just save yourself time and head ache and do calculations and formatting in perl.

DTrace is limited in functions. Many of the functions are hard to track down and/or have little documentation. Here is a list of functions:

http://www.solarisinternals.com/wiki/index.php/DTrace_Topics_Internals

http://developers.sun.com/solaris/articles/dtrace_quickref/dtrace_functions.html

 

 

 

Provision Oracle RDBMS software via RPM

I have always asked myself why Oracle doesn’t package their software as an RPM-surely such a large organisation has the resources to do so!

Well the short answer is they don’t give you an RPM, except for the XE version of the database which prompted me to do it myself. The big problem anyone faces with RPM is that the format doesn’t seem to support files larger than 2GB. Everybody knows that the Oracle database installation is > 2G which requires a little trick on our side. And the trick is not even obscure in any way as I remembered: some time ago I read an interesting article written by Frits Hoogland about cloning Oracle homes. It’s still very relevant and can be found here:

http://fritshoogland.wordpress.com/2010/07/03/cloning-your-oracle-database-software-installation/

Now that gave me the idea:

  1. You install the oracle binaries on a reference host
  2. Apply any patches and PSUs you need
  3. Wrap the oracle home up in a tar-ball just the way Frits describes by descending into $ORACLE_HOME and creating a tar archive of all files, excluding those ending in “*.log”, network config files in $ORACLE_HOME/network/admin and anything in $ORACLE_HOME/dbs. We don’t want to proliferate our database initialisation files …
  4. You make that tarball available on a central repository and export that with CIFS/NFS or whatever other mechanism you like
  5. Mount this exported file system in /media, so that /media/db11.2.0.3/ has the database.tar.gz file available
  6. Install the RPM

Simple! Piet de Visser would be proud.As it turned out creating (or building) the RPM is the hard part! I have spent a fair amount of time to understand it, and realised that it’s amazing! However IMO RPM is primarly aimed at packaging/building software from the source, something the oracle installer doesn’t really do in the same way.

To get you started, here’s a sample spec file I used, named Oracle11203.spec.

%define name            Oracle11203EE
# package release
%define release         1.0
# vendor release
%define version         11.2.0.3

Buildroot:              %{_topdir}/BUILDROOT/%{name}-%{release}-rootdir
Summary:                Oracle Database 11.2.0.3 EE
License:                Commercial
Name:                   %{name}
Version:                %{version}
Release:                %{release}
Group:                  Applications/Databases
Vendor:                 Martin Bach Consulting
URL:                    http://martincarstenbach.wordpress.com
Requires:               oracle-validated

%description
Oracle 11.2.0.3 Enterprise Edition installation. Requires the binaries
in tar-compressed format in /media/db11.2.0.3/database.tar.gz ready for
cloning. A good source for how to package your system up for cloning can
be found here:

http://fritshoogland.wordpress.com/2010/07/03/cloning-your-oracle-databa...

The oracle-validated is used on Oracle Linux 5 to create a sensible installation
environment. Ensure you review the environment before you build oracle!

%post
if [ -d "/u01/app/oracle/product/11.2.0.3/" ];
then echo "ORACLE_HOME directory exists-aborting";
exit 127
fi

echo "cloning the oracle home now to /u01/app/oracle/product/11.2.0.3/"
mkdir -p /u01/app/oracle/product/11.2.0.3
tar --gzip -xvf /media/db11.2.0.3/database.tar.gz -C /u01/app/oracle/product/11.2.0.3
cd /u01/app/oracle/product/11.2.0.3/clone/bin
./clone.pl ORACLE_HOME="/u01/app/oracle/product/11.2.0.3" ORACLE_BASE="/u01/app/oracle" -defaultHomeName

%files
%defattr(-,root,root,-)

How RPM normally works

When building RPMs, a certain directory structure is assumed, such as a top directory (/home/martin/rpm) and certain subdirectories:

  • BUILD
  • BUILDROOT
  • RPMS
  • SOURCES
  • SPECS
  • SRPMS
  • tmp

The RPM build process is controlled via a “SPEC” file. Documentation of these isn’t too great, especially since the format and process has changed over time (see references). The SPEC file follows the process you would normally follow when compiling a piece of software from source. The SPEC file puts more structure around it.

Your source code goes into SOURCES (still tar-compressed). RPM can be instructed to prepare (=uncompress and patch) the tarball, which by default goes into BUILD. When running the configure command, you usually set the prefix to BUILDROOT. After the build completed (using make), you install the package in BUILDROOT. RPM then catalogs the files inside BUILDROOT and uses the defattr() clause in the SPEC file to assign permissions. This is a big relief-in earlier versions of RPM each file that went into the RPM had to be listed under the %files section.

How this process works

The above SPEC skips almost all of these steps. In our example it’s not necessary to download any sources, all the logic is contained in the SPEC file %POST section.In other words, all you need to do to build the RPM is to copy and paste the above code into the Oracle11203EE.spec file. You build the actual RPM using “rpmbuild -ba Oracle11203EE.spec”. At the end, you find a RPM file in the RPMS/x86-64 directory which can from then on be used to install Oracle on any server. And yes, the RPM is empty except for some header information and a few lines of code.

Note that the SPEC file isn’t really complete: add mount commands and error checking as you see fit. You might also want to replace literals with variables etc-the idea was to give the principle away.

Reference

Mike Carey: The Naming of the Beasts…

“The Naming of the Beasts” is book 5 in the Felix Castor series by Mike Carey. Juliet, the succubus, has gone all wild, beaten up her human wife and is on the verge of feasting on aroused men’s souls again. Felix’s friend Rafi, still possessed by the demon Asmodeus, has gone AWOL and started a killing spree. Life’s never easy when you’re a freelance exorcist… :)

This is the last in the series so far and it maintains the pace of the other books, while tying up a lot of loose ends. According to Wikipedia the next book is out late 2001 (imminently). It will be interesting to see what Felix does next, since the main thrust of the story of the first 5 books is now concluded.

Cheers

Tim…




And so the evenings start drawing out (honest!)

I know I’ve blogged about this before, but it was early on when very few people read my ramblings, so I am mentioning it again…

For those of us in the Northern Hemisphere, today is the day when the evenings start drawing out, which personally I find a relief as going home in the dark depresses me. Sunset tomorrow will be later than today – by all of a few seconds but, heck, later is later. {If I am out by a day, please don’t tell me – don’t shatter my good mood!}

However, as many of you are probably thinking, shortest day in the Northern hemisphere is not until the 22nd December (it’s the 21st or 22nd, depending on how long ago the last leap year was). Mornings continue to get later until around the 3rd January. It is because the earth is not “standing totally upright” in it’s orbit. If you think of the plane in which the earth circles around the sun as a flat surface, the north pole is at the top of the planet and that there is a pole sticking though the earth that it spins around every day, that pole is leaning back away from the sun today and slightly to one side, like a staggering drunk.

For the timing of sunrise and sunset for the city nearest you, check out this nice website here. This link will show London but you can change that.

The original post is here. It does not say any more but there are a couple of pretty sunset pictures on it.

Of course, if you are in the Southern Hemisphere {say Perth, Australia} then your sunrises have just started getting later by today. But time for the Barby in the evening is still drawing out for a week or two. We can all be happy :-)

WordPress 3.3 Released…

WordPress 3.3 is now live and ready for download.

The automatic upgrade was as smooth as ever. A couple of themes needed to be upgraded too. The menus are a little different and there is now a new persistent dashboard header, but it all seems like business as usual for the casual blogger like me.

Cheers

Tim…




UKOUG 2011 - OAK Talks and Unconference

There were a couple of new and related features at this years conference - the Unconference and OAK Talks.

The idea of an Unconference will be familiar to those who have attended Openworld - an unscheduled part of the conference that anyone can sign up for to present during a one hour slot. First come, first served. I was a little concerned about how this might take off because it needs a lot of advertising or to be in a prominent location, otherwise it just passes people by. Even at OOW, where they do a reasonable job of pushing it, it's not uncommon for sessions to be attended by a handful of people, although that in itself can lead to an interesting experience as I had several major OEM luminaries in my OEM session one year and it turned into a discussion of the finer points of the Performance Pages and potential improvements!

I feel the UKOUG could have done better here and I suspect they know that. The Unconference area was far from clearly marked and stuck out of the way on the balcony of the exhibition hall and my heart sank when I checked out how many people had signed up to present :-( Really, people should take this kind of opportunity to speak when perhaps their presentation abstracts weren't accepted or they want to talk on a subject that would have no chance of making it on to the main agenda. They could even try and be funny or entertaining! Then again, if you don't think you'll have attendees, you're hardly likely to sign up and so it becomes a vicious circle. I hope the UKOUG don't give up on it, though, and try to improve the promotion of it next year because I like even more opportunities for new speakers and more off-beat presentations where possible. I know that Greg Rahn had a 2-hour session there that people raved about and I was sorry I missed it.

It was at least partly to promote the conference that a few of us came up with the idea of getting Oak Table Network members to give some presentations and James Morle suggested OAK Talks. 5 x 10 minute presentations which would hopefully be short, entertaining and make an interesting point or two. By holding them in the Unconference area over lunchtime, we hoped to promote it. I discussed the background to this more here.

I'd agreed to be one of the speakers in the first lunchtime slot and when we all finally worked out where the Unconference area was, my heart sank again. It looked like the OAK Talks might become too literal as a bunch of Oakies talked to other Oakies.  Might as well have been in the pub, in that case! But, true to form, James took the thing by the scruff of the neck and an announcement was made in the Exhibition Hall so that the occasional person wondered in, if only for a place to sit down and eat their lunch ;-)

The main problem on the first day was that the noise-levels from the Exhibition Hall made it very difficult to hear people and the level of concentration killed the atmosphere a bit but, as new speakers took their turns, we started to realise that the only option was to shout a bit which wasn't too difficult in my case. Yet again, problems were identified and resolved and a small PA appeared for the next two days which made things better. It was still a pretty noisy location, though!

With 15 different talks of such varying messages and styles, I won't bore you with them all, but just pick out a few personal memories. Apologies to those who didn't make it - it's because you weren't very good. << Scottish humour.

- Tuomas Pystynen kicked off proceedings talking about RMAN and levels of backup compression and performance. Tuomas deserves a medal for being the first speaker because, as well as the noise and gradually growing audience, others would later discover that doing one of these talks was petrifying compared to giving a standard 45-60 minute presentation with the crutch of presentation slides and space to veer off track. Between the intimacy of the audience, the tight timescale and the lack of easy props, several of us discussed what a challenge it had been! Of course, it probably doesn't help that I suspect a lot of these talks had been developed entirely in a few minutes in a bar or airport somewhere ;-) Well done, Tuomas, for having the guts to get the show on the road!

- Me (of course) talking about You Probably Don't Need Exadata. This was inspired by Moans Longballs Nogood's much earlier paper You Probably Don't Need RAC and, whilst I planned it to be much more withering and sarcastic than I think I was (because I forgot most of my mini-speech as soon as I started), I was essentially making the point that Exadata is not the only solution out there and that the right solution for you depends on your workload and, erm, maybe some optimisation of your application might be a better first step? Just a thought. A personal highlight was Greg Rahn walking in 2/3 of the way through and the only available seat being right under my nose as I ranted and raved about Exadata, but it all added to the fun ;-) By this time, the area was pretty full and, when it was, it was actually a cool and unusual atmosphere to present in.

Here's a tiny version of the wide-screen shot, courtesy of Neil Chandler.

- The only thing missing from Neil's picture of Jonathan Lewis presenting on how to build test data rapidly for experiments is that he missed the moment when, after some discussion about whether Jonathan had made a mistake or not, Jonathan solved the problem by screwing up the bit of paper and deciding to eat it! A perfect informal presentation moment and exactly what the Oak Table Network is about. Are you sure you've written that properly? Cracking talk, too.

- Alex Gorbachev talking about the Oracle Database Appliance. I and others have questioned the value of the ODA and whether it hasn't perhaps been over-played a little by partner consulting companies? ;-) Alex, never one to avoid a challenge, decided he would pick this moment to say why he thought it was a worthwhile proposition. It keeps coming back to ease of deployment and he contrasted it with the somewhat more tricky work that had been going on at RAC Attack. At the end of the presentation he looked over and wondered whether he might have persuaded certain grumpy old people and got a begrudging and limited nod of approval! LOL

- Ever since I sat in a presentation audience with John Beresniewicz (JB) several years ago and he had murmured - "that's because DB Time is fungible", I'd become mildly obsessed with this property of DB Time and was hoping to hear him talk about it at UKOUG last year, but his abstract didn't make the cut. So an OAK Talk was the perfect opportunity for him to at least let a few more people know! As he'd thought about the subject longer, though, it turned out that maybe DB Time is more liquid than fungible but the practicalities are that maybe DB Time is a good metric to use when implementing charge-back for system resource usage because most metrics don't give a great idea of how much a system is actually being used by specific business exercises? He also higlighted how it can be sliced and diced across different application components, users, SQL statements and all the other nice dimensions that ASH gives you so it's easy to apportion time-based usage to the proper charging pot!

Updated Later: Oh, I almost forgot to mention the hilarious moment when JB, picking on a couple of people he knew in the room to make a simple point about costs, seemed to imply that my consulting rate might be higher than Cary Millsap's. In ... my ... dreams ... ;-)

There were lots of other talks I could mention and this became an immutable slot on my agenda. The opportunity to sit and chill out and not be bored senseless. It could have used a better venue, it definitely needed the PA and, as with anything so informal, it was at times sprawling and variable, but I wouldn't have missed it for the world, although most of us who presented wouldn't have minded missing out on the stress levels leading up to our individual moment!

I was discussing this later in the conference with a few of my many friends who are not Oak Table Network members. (Yes, it's true, I really have some.) They would have been keen to participate too and so the quesiton arises, should someone try to organise more slots in a similar vein next year? I'm interested in hearing further comments on that ....

Oh, and well done to James for herdiing cats and doing the most to pull the whole thing together.

Usual disclosure: My travel and accommodation expenses were covered
by the Oracle ACE Director
program.

UKOUG 2011 Conference OakTable Sunday by Alex Gorbachev

This blog post covers day 0 of UKOUG 2011 — Sunday, 4th of December, 2011. Since there were so many of us from Pythian at the conference, I’m adding my name in the blog post title. I think I will be doing it for all conference posts as I think I’ve been doing for some [...]

Getting started with FusionIO

I have been lucky enough to do some work with Fusion IO cards in a blade server, soon to be followed by another set of tests on a full rack mounted server. I didn’t know exactly where model I was given, but powered my server down in eager anticipation of the events to come.

After the engineer plugged the card in, and powered the server up I logged in as root to find out what about the pre-christmas present. I knew it was a PCI card, so surely lspci would tell me more. Here’s the output:

lspci -vvvv

41:00.0 Mass storage controller: Fusion-io ioDimm3 (v1.2) (rev 01)
Subsystem: Hewlett-Packard Company Unknown device 324d
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

So it’s indeed a FusionIO card (an ioDrive to be precise), and it’s plugged into a x4 slot, the mimimum required.

What to do next? Always good to read the docs. The fusionio.com website allows you to download documentation and drivers after a free registration. Luckily the website didn’t have kernel modules for Oracle Linux I’m using (RHEL 5 only), which gives me the opportunity to build the software from source. I don’t like surprises, therefore I created my ~/.rpmmacros with the following content:

[root@computer1 rpm]# cat ~/.rpmmacros
%_topdir /home/martin/rpm
%_tmppath /home/martin/rpm/tmp

This obviously requires the full tree underneath the topdir, namely

  • BUILD
  • BUILDROOT
  • RPMS
  • SOURCES
  • SPECS
  • SRPMS
  • tmp

With these directories in place it’s as simple as running rpmbuild –rebuild iomemory-vsl-2.3.1.123-1.0.src.rpm as a non-root user (martin in my case) and wait for the RPMs to be created in the RPMs/x86-64 directory. Following the documentation again I installed the needed software:

[root@computer1 x86_64]# rpm -ihv iomemory-vsl-2.6.18-194.26.1.0.1.el5-2.3.1.123-1.0.x86_64.rpm
Preparing...                ########################################### [100%]
1:iomemory-vsl-2.6.18-194########################################### [100%]
[root@computer1 fusionio]# rpm -Uvh lib*.rpm
Preparing...                ########################################### [100%]
1:libfio                 ########################################### [ 50%]
2:libfusionjni           ########################################### [100%]
[root@computer1 fusionio]# rpm -Uvh fio*.rpm
Preparing...                ########################################### [100%]
1:fio-common             ########################################### [ 14%]
2:fio-util               ########################################### [ 29%]
3:fio-remote-util        ########################################### [ 43%]
4:fio-smis               ########################################### [ 57%]
5:fio-snmp-agentx        ########################################### [ 71%]
6:fio-snmp-mib           ########################################### [ 86%]
7:fio-sysvinit           ########################################### [100%]
[root@computer1 fusionio]#

Note that you don’t actually need the fio-sysvinit package if your distribution is reasonably modern. UDEV will load any drivers automatically.

With that completed as well it’s time to load the kernel module and watch Linux do the rest. The fio-status tool queries the card’s helth:

[root@computer1 x86_64]# fio-status

Found 1 ioDrive in this system
Fusion-io driver version: 2.3.1 build 123

fct0    Attached as 'fioa' (block device)
HP StorageWorks 320GB IO Accelerator, Product Number:AJ878A SN:07902
Alt PN:507152-001
PCI:41:00.0
Firmware v5.0.5, rev 43674
322.55 GBytes block device size, 396 GBytes physical device size
Sufficient power available: Unknown
Internal temperature: 40.4 degC, max 40.9 degC
Media status: Healthy; Reserves: 100.00%, warn at 10.00%

That’s it! so simple-another blog post will detail how I ran a first orion benchmark on it and show some impressive numbers.