Which Oracle Release are you using?

Post Date: August 2018!

Recently an awesome Oracle Guru friend of mine questioned someone who was installing with the word “seriously”, which is think shows that Oracle staff sometimes don’t live in the same technological world as the rest of business.

My response was: is normal. In the real world:

– large corps mostly use old versions
– consultants look at current versions
– Oracle staff look at unreleased versions

I have known instances of Oracle staff blogging about how a feature works when, in the officially released versions, it didn’t. It only worked that way in a version which was released some months later. There was no reference to the release and the fact that there was a significant functional change between releases (but I suppose that’s a blog and not “official” documentation – the official documentation said nothing at all about how that particular feature worked. Nothing! So thank you mystery blogger.)

Anyway, the point of this post was I then did a small twitter poll to my most excellent and cosy band of followers to see what Oracle releases people were using. I asked 2 questions (because twitter is limited) and here’s the results:


So more people have some form of 12 in the DB, but only 7% have 18 in Production. This at a time when most Oracle staff are thinking about Oracle 20 and 21, as Oracle 19 is done and just awaiting release. Think about that, Oracle… Whenever I am at a presentation by an Oracle PM, I think “wow – I might be able to use those new features in 2-5 years”.


So very few people have 12.x as their lowest version (which would include 18 as that’s really and MORE have 9, 8 or 7 as their major headache! Yes – there are more on 9, 8 and 7 than are using 18 in Production. Lets say that once more. There are more on 9, 8 and 7 than are using 18 in Production

So why upgrade? Very few databases take advantage of all of the latest sexy features. I suspect that many of the applications still being produced could run on Oracle 7.3.4. – more so as the proliferation of ORM’s like Hibernate has left a generation of developers with little appreciation of the database and how to take advantage of it**. So why upgrade? These days? Security. Patches. Support. Without those 3 things, you are living on hope, hope that nothing goes wrong as you’ll struggle to find anyone to fix it – including Oracle. Hoping that nobody tries to hack your 8.1.7 database as it’s a Swiss Cheese of vulnerabilities, like all 7, 8, 8i, 9i, 10G DB’s. Not that we hear about systems being compromised every day on the news.

Anecdote #1: By coincidence I was talking to a client at about the same time and whilst they are a mostly 12.1 shop, they still had an old 8i database hanging around… as usual it was going to  be “retired soon” (which in my experience means sometime in the next 15-20 years) and wasn’t worth the time and effort to be upgraded or even do a business case to upgrade it!

**Anecdote #2: At a client a few years ago, an excellent Java Developer asked me to put an index on a flag column. I pointed out that with only 3 values that an index wouldn’t help, and as this was OLTP a bitmap index wasn’t appropriate due to concurrency issues. He said that with 3 values indexed, his query would be 3 times faster! We sat down and I explained some database fundamentals to him, at which point he said “don’t put an index on there – that would be a stupid idea”. A few weeks later he came back over and asked about SQL queries “I’m trying to aggregate this data – can the database help?”. I spent 30 minutes showing him in-line views and windowing analytic functions and we wrote the code he needed for his output. “Wow! You have just saved me 3 days of Java coding…” – he was going to pull everything into Java and process it there, so as well as 3 days of coding, we also saved the SAN, the network and a whole bunch of CPU by dealing with data at the database layer – which is always the most efficient place to deal with it!


9 Responses to Which Oracle Release are you using?

  1. Regarding anecdote #2: …and also saving your client from some bugs that would certainly be in the newly written Java code. Not saying Oracle is bug-free, but definitely much, much more tried and tested than any custom-developed software.

    Liked by 2 people

  2. Boneist says:

    “I suspect that many of the applications still being produced could run on Oracle 7.3.4” … you will prise analytic functions from my cold, dead hands! *{;-)

    Liked by 1 person

  3. Iudith Mentzel says:

    The main reason for the “slow version upgrade” is that, at least in non-IT enterprises, the management is mostly interested to add business value to big applications, rather than keeping IT teams busy most of the time with performing “technical” actions, like version upgrades and all the applications testing cycles required by those.

    Yes, sometimes you have to be very clever and inventive even for being able to keep some older versions up and running, and even to find solutions for compatibility issues that Oracle support declares as being impossible to solve without upgrading.
    I personally never found myself frustrated for having to solve such problems …

    To be completely honest …
    Surely Oracle is already working on versions 20, 21 … but let’s not forget that even 18c is not yet
    released on all platforms … So, I’,m not sure that this high pace of “one version each year”
    is entirely justified … surely not for “real life” non-IT/business organizations.

    Liked by 1 person

    • The high pace of release is just marketing to seem like Oracle is advancing as fast as its competitors.


      12.2 and 18C aren’t terminal releases. Only 19C will go to extended support (well, probably 19C.)

      However, this is not without cost. It is a problem for those of us trying to justify to which release we should upgrade as Management see 11.2 to 12.2 as an expected step and 11.2 to 18 as a massive scary leap…

      Liked by 1 person

  4. Rich Soule says:

    To me, 12.2 or higher is VERY important. There’s a fundamental shift in capabilities there… Long object names. No longer do you have to attempt to squeeze standards into 30 characters. It’s a very big shift from a modeling perspective. At least I think so…


  5. Iudith Mentzel says:

    @Rich, it may sound funny to you, but in SAP there exists a principle that all column names are
    exactly 5 characters long … and table names are similar, or even shorter …
    so both entity names look very cryptic for a “normal” eye …
    But, they always say, also as a principle: “Why should that matter at all ?” …
    exactly as they say: “Why do you need to know which database stores your data ?” …


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.