Author: Lukas Vysusil

Most people start with free databases and eventually get to know the enterprise products. I started the other way around. After being trapped for eight years in the Oracle world, I felt like exploring another database platform. For some reason I can’t get myself to fiddle around with MySQL. There’s nothing rational about this–no benchmarks, reviews, or co-worker horror stories. I feel it’s just not my type. So when looking for free database, I reached out for PostgreSQL, again for no objective reason–only the gut feeling that this could be what I’m looking for.

This post might seem outside of our focus, but life brings all kinds of challenges. A friend of mine bought a MacBook when she was on vacation in the USA. Her Mac completely broke down. The service guys told her she’d need to replace the motherboard, which would cost almost the same as a new computer. The problem was her Mac wouldn’t even start, and all the data she had on a hard-drive was stuck in the neat white box without any signs of life. Sure, I said, I’m a computer guy I can recover it, can’t I?

In the first part of this blog I tried to shed some light on EBS patch terminology and naming conventions. In this post, I’ll show you how to check your patchset levels and query applied patches.

E-Business Suite patching is very broad topic. I’m going to cover just a fraction of this vast theme, one that I believe is often overlooked. I decided to split it into two logical parts; Part 1) Oracle E-Business Suite patch terminology, and Part 2) Querying patches, patchsets, family packs. This blog could also be called “Oracle EBS patch evolution theory.” Like any other theory, it can be challenged and proven wrong. I tried to make it unbiased based purely on my experience and to present it in the way that makes sense in context of general patching activities.

If you ever thought it was easy to kill an oracle job, let me show you something that gave me a headache today. The steps are simple enough: remove/break all jobs in question, kill the jobs that are running, recompile the packages with new the version, and submit/un-break the jobs again. This time, however, things were not going as smoothly as I expected. Let’s have a look.

Recently, I had an opportunity to participate in a database stress-testing exercise. The objective is to make sure the particular hardware can handle the expected load and also to test where the physical limit of the machine lies if we keep increasing the number of concurrent users. I searched for tools available out there. The open source Hammerora turned out to be excellent tool for the purpose of simulating a typical transactions load in any number of threads. It’s built with the Tcl scripting language and it can simulate a real workload with as many client user sessions as your system can handle. If you’re looking for an easy way to measure throughput performance of your database, keep reading.

Tonight I returned from my first UKOUG conference. I’ve been to smaller conferences like Microsoft Technet and big ones like European Oracle Open World before, but this was without a doubt best one so far (measured by the value of content and amount of fun). I couldn’t attend all the sessions that aroused my interest, there were simply too many of them. From those I attended, there are few I’d like to mention as highlights of the conference. Here they are…

I built a Dual Core box with 8G of RAM for an install of E-Business Suite R12. For OS I chose Oracle EL5U2, mainly because I’m used to the RH/OEL clones, and also because I expected it to be less painful than other distributions. I started slowly, as time allowed, spending some time chasing various libraries and packages on the Net. Eventually it took me a week to realize how tedious it is to go the manual way. I got so frustrated by the dependencies that I gave up and purchased access to the ULN network.