Alex Gorbachev at COLLABORATE 08

I guess I have only one and a half posts about COLLABORATE 08 this year. It’s a bit unfortunate that I couldn’t make the whole conference, but only last day-and-a-half. In addition, I’ve been speaking at the two lasts slots of the conference so it’s been quite busy for me.

As I mentioned already, the scheduling for my presentation got a bit screwed-up due to the last minute call to participate in the speaker panel — “To RAC or Not To RAC: What’s Best for HA”. Thanks to Dan Norris, my session was finally moved to 11:00, which is right after the panel. On the other hand, 11:00 slot is the last IOUG session of the conference. This fact, coupled with last minutes re-scheduling, brought the number of participants down. Even though there were about 30 people and the hall (Korbel 1C) was small enough not to seem empty.

Back to the RAC speaker panel, I enjoyed the discussion and especially the fact that speaker’s opinions on how wide RAC adoption should be were a little different. I took the liberty of starting the discussion with a quite provocative quote — “complexity is the enemy of availability”. Interesting that the other panel speakers seemed to disagree to it to some extent by countering it — use knowledge to fight complexity. Not that I don’t agree with it (on the contrary) but my point was rather, “why make it complex when you can keep it simple?”

Speakers seemed to agree that expectations of RAC are commonly overstated, particularly how expensive highly-available RAC is. Another interesting split of opinions, this time on the audience side, was about the definition of a highly-available environment. While some agreed that a few minutes of recovery from a failure make systems highly-available, the majority believed that high-availability must provide a failure recovery time in the range of seconds rather than minutes. I couldn’t get rid of the impression that the majority still didn’t realize how much it actually costs to put in place and support an environment with the service recoverability time the in range of several seconds for unplanned outages.

The summary was that RAC is a great and unique technology but commonly misused, and not without help of Oracle marketing. Surprisingly, even with such conclusion, there were still some controversial recommendations given that you should try to use RAC even if you don’t need it now as you *might* need it in the future. It’s either a paradox or a good example of brain washing.

I would also like to say that I was very pleased to finally meet Matt Zito from GridApp, and Jeremy Schneider, who were also on the panel. I knew them already via Oracle-L, blogs, email and even speaking on the phone, but it was the first time face-to-face. I’m only a bit disappointed with myself that I missed Matt at the end while I was distracted preparing to run to my own presentation. Matt seemed to be even more in a hurry and I couldn’t see him around anymore. I was also pleased to meet Neil Greene, who was the fourth panel speaker.

Back to my presentation. I didn’t mention it previously, but the original abstract was submitted by Christo Kutrovsky. However, traveling from Dubai for a single presentation is somewhat difficult to justify, so it was proposed that I do that instead. I would probably not pick that topic myself — Christo was far more involved with the 11g beta program and spent more time playing with it — but it actually went better than I expected, and I managed to make myself sufficiently interested in the subject. Otherwise, I would hate myself for presenting on a topic I’m not enthusiastic about. It was also helpful to use slides from Christo’s Oracle Open World presentation as a draft even though the accent of the presentation was different.

It was one of the rare cases when I managed to keep just the right amount of content and be able to get to the end without rush, and still get five minutes for the follow up questions at the end. Sweet. I was thinking of organizing a live demo, and even prepared an 11g installation, but I abandoned this idea. It was for the good — otherwise, I would have run out of time and rushed the presentation.

Did the audience like it? I think so — there were some questions during the session, and some follow-up at the end. I also saw a few people taking notes, which is always a good sign. My jokes were probably not the most brilliant, but they seem to work even at the last session. In the end, I’m satisfied.

After the presentation I had few hours left unallocated, and I used the chance to catch up with Jeremy Schneider. I had been looking forward to having a good chat with him for a while, and the time had finally come! It was even better, as Dan Norris joined later, too. Thanks for the good company, Jeremy and Dan.

Now back to the previous day of the conference, Wednesday. Carol Dacko did a very good job on the DBMS_XPLAN and opened up a few new uses of this package that I didn’t know before. Indeed, the current version of DBMS_XPLAN is one of the best performance tools (if not absolutely the best) that Oracle has ever provided.

I popped in on a quick 30-minute session by Tom S. Reddy on 11g RMAN New Features. My objective was to make sure that I didn’t miss something obvious for my presentation and didn’t misrepresent anything, which is easy to do when you have limited experience with the new release. I managed to uncover some of the issues like the the half-working ASMCMD cp command, but I’m sure I probably missed something.

Then it was time for a quick lunch followed by the RAC SIG Birds of a Feather session. It was an informal discussion about RAC SIG activities, and few RAC topics that deserve more attention. One of those topics was RAC upgrades. Apparently, it’s a most confusing topic — in what sequence you should upgrade your RAC components — CRS, ASM and database? Having third-party clusterware or upgrading from 9i adds its own “spice” to the mix. Well, I think lots of questions are easily answered by… reading the standard Oracle documentation, MAA documents, or relevant Metalink notes. However, only the experience of “playing with it” and testing it gives you the unforgettable feeling of comfort. Again, back to using knowledge to fight complexity.

Dan Norris made an interesting comment during the follow up discussion later: a typical Oracle shop performs upgrades once in a while and if single-instance upgrades are more or less known, RAC upgrades require much more knowledge, planning, and preferably experience doing various upgrade scenarios. Getting to the point — why would a company want its DBA(s) to learn all the quirks of RAC upgrade to use them once in a few years if you can simply hire an expert to do just that? An expert that did dozens of RAC upgrades, knows most of the details and is able to quickly develop and implement an upgrade for another unique environment?

I hope it won’t sound like a shameless plug, but we do a few upgrades per month here at Pythian, and I’m sure we are not the only ones. Drawing the parallel to our non-IT life — a regular household doesn’t need to redo or fix their plumbing every month so it’s not really worth learning how to do it yourself — that’s what plumbers are for. (Well, I do make some small fixes myself when I have the time and inclination, but that’s because I learned it before, back in Russia. You might not want to invite a Russian plumber to your house for every minor issue.)

To summarize the lesson — if you don’t know how to implement one your needs, make sure you evaluate whether it’s cheaper for the business to actually hire a professional to do it.

The RAC SIG Birds of a Feather was the place where I caught Logan MacLeod. I met Logan last year in Las Vegas during COLLABORATE 07, and it was a pleasure to see him again and find out what they are working on these days.

The last session of the day was “A New Database from Oracle: TimesTen”. The presentation was good as an overview of the TimesTen technology and its integration with Oracle, but I felt that it was a little shallow at times. Anyway, it did give me a general idea of how TimesTen is supposed to work and integrate with Oracle. I could see that TimesTen will be often seen as a quick workaround for bad application design introducing potential issues such as synchronization across application tiers. There are definitely some good use cases to implement TimesTen but it requires careful planning during application design.

It doesn’t look like integration of Oracle and TimesTen was thought-out very carefully. For example, incremental replication of change from Oracle to TimesTen is done using… triggers. And this is supposed to be high-throughput, scalable solution. Interesting if update “restarts” are accounted in the replication mechanism (see Tom Kyte’s blog posts — 1, 2, 3).

The reception dinner was scheduled to start at 7:30 PM and I definitely planned to show up — you can’t beat free drinks and food, and there were much more than that. However, even after the last session, we still had couple hours to kill. What can be better than a good chat with good mates at the pub? Only a pub with good beer!

Due to the blizzard conditions outside, the only feasible option was actually the Hyatt Regency Hotel’s pub across the road and I can’t complain about these couple of hours! David Kurtz and I showed up at the pub and met Peter Scott sipping a beer and suffering from loneliness. So we had the first ingredient — good company. 90 Shilling was a very decent beer, so ingredient number two was there as well. Success was guaranteed. But we got a bonus we couldn’t even hope for — we still had few minutes of happy hour at two bucks a pint. Needless to say, we were quick enough to consume more than one.

After such a good start, we happily followed through to the reception back at the Convention Center. Wow! A huge hall with a dozen of drinks service points, buffets serving decent roast beef, plus lots of entertainment, including rock climbing, bull-riding and surfboard simulators as well as a bunch of pool tables, pile of casino tables (not for real money though — that would probably require licensing), and other entertainment including a decent DJ.

The only disadvantage to the scale of this was that it was difficult to find anyone there, and from time to time I had to walk around for a while to find a familiar face (do I sound like an old grumpy man)? Shame on me, but I left relatively early, and even had some free drink tickets left. Of course, I couldn’t throw them away and managed to pass into good hands on my way out. If you know me, then you must understand how exhausted I must have been to leave early. On the other hand, the thought of getting older won’t leave me alone.

My accommodation was quite far (a 30-minutes drive). I decided to take the light rail instead of taxi. That was a very good experience — it took me only 20 minutes to get to the required station where I was kindly picked up by the Fink’s Bed and Breakfast shuttle service. I wish all accommodation could be as pleasant as mine was these two days. Thanks FBB!

I hope this one long blog post will be accepted in place of several smaller ones, but there probably very few, if any, readers who have got this far, anyway. You must be one of them, so thanks!