Infrastructure at your Service

Oracle Team

Question is: upgrade now to 12.1.0.2 or wait for 12.2 ?

By Franck Pachot

.
Let’s look at Release Schedule of Current Database Releases (Doc ID 742060.1)
12.2.0.1 is planned for 2HCY2016 on platforms Linux x86-64, Oracle Solaris SPARC (64-bit), Oracle Solaris x86-64 (64-bit).
2HCY2016 starts next week but we can imagine that it will not be released immediately and anyway we will have to wait a few months to download the on-premise(s) version. Add another couple of months to get at least one Proactive Bundle Patch to stabilize that new release. So maybe we can plan for production upgrade on Jan. 2017 for Linux platform, and Apr. or Jul. 2017 for Windows platform, right? How does that cope with 11.2.0.4 and 12.1.0.1 end of support?

Is delay for 12.2 a problem?

My opinion is that long time for new release is not a problem. Most of customers want stable supported release, not new features available only with options and that may introduce bugs. As long as we have support, PSUs and Proactive Bundle patchsets, everything is ok. We can’t blame software regressions after upgrade, and at the same time look forward to get new releases in a short period of time.
So in my opinion, waiting 6 months or 1 year to get 12.2 is not a problem except for book authors that wait for the general availability of 12.2 to release their book https://www.amazon.com/Oracle-Database-Release-Multitenant-Press/dp/1259836096 😉

Is ‘cloud first’ a problem?

I don’t think that ‘cloud first’ is a problem by itself. We will have to learn 12.2 features and test them before upgrading our databases, and the Oracle Public Cloud is good for that. But I fear that customers will feel forced to go to the cloud, which is wrong. Was the same when 12.1.0.2 was released for Enterprise Edition. They feel forced to qui Standard Edition but that was probably not the goal. Especially when those that have quit Standard Edition One did it to go to open-source RDBMS.

Is ‘multitenant first’ a problem?

Yes, ‘cloud first’ may mean ‘multitenant first’ because that’s the only architecture available for 12c on the Oracle DBaaS. First, you can install a non-CDB if you choose ‘virtual image’. And anyway, OPC trial is the good occasion to test 12.2 and multitenant at the same time. Let me repeat that multitenant architecture has lot of features available without the multitenant option.

Upgrade planning

Back to the ground, the problem in my opinion is the incertitude.
Free extended support for 11.2.0.4 ends on 31-May-2017 and we don’t know yet if we will have a stable (i.e with few PSUs) 12.2 release at that time for on-premises, especially for Windows which will come later than Linux.
Remember that 12.1.0.2 on Windows came two months after the Linux one. And another two months for AIX.

12.1.0.1 support ends on 31-Aug-2016 and 12.2 will not be out at that time, at least for on-premises.

So what?

Customers that expected to get 12.2 before the end of 12.1.0.1 or 11.2.0.4 support will now (since the announcement of 2HCY2016 last month and the ‘cloud first’ recent announcement) have to plan an intermediate upgrade to 12.1.0.2 before going to 12.2. And because of the ‘Release 1’ myth, they are afraid of that. Our mission, as consultants and Oracle partners, is to explain that the myth has no reason behind it. Look at Mike Dietrich blog about that. Hope you will be convinced that version, releases and patchsets can bring regressions and should be carefully tested, whatever it’s the 1st, 2nd or 4th number on the version identification that is incremented. New ORACLE_HOME is new software.

Then, once in 12.1.0.2 you will have the time to plan an upgrade to 12.2 after learning, testing, changing administration scripts/procedures/habits to the era of multitenant. And you will be ready for the future.

The customers in 11.2.0.4 that do not want to plan that intermediate upgrade will have the option to pay for extended support which ends on 31-DEC-2019.

8 Comments

  • Hey Franck,

    > We will have to learn 12.2 features and test them before upgrading our databases, and the Oracle Public Cloud is good for that.

    I am not a cloud guy, so please forgive my nescience.

    1) How does it work with one-off / interim patches in Oracle cloud? Do we (still) have access to these kind of patches with RDBMS running in the cloud? Can we still apply it on our own? I mean i learned from you that Oracle Cloud is not keeping up with the latest PSUs at all, so i can not imagine how this should be handled well for all the interim or merge patches for a brand new release.
    2) Are we allowed to change all (underscore) parameters with DBaaS? (afaik Amazon RDS limits these kind of settings)

    I guess most of this stuff is very important for evaluating a new RDBMS release and playing with it.

    Thanks and Regards
    Stefan

    P.S.: I am really disappointed about this “Cloud First strategy” as for me (as an independent consultant) it is essential to be one of the first playing with new releases to get knowledge for my clients. Now i have to pay for Oracle Cloud just to get access, run my load stuff and research all these new features / problems. This is ridiculous – especially when you have no own CSI (as an independent consultant).

  • Hi Stefan,
    Good to see your feedback here. Oracle Public Cloud PaaS is very different than Amazon RDS here. You have full access, can even sudo su root. You can choose to manage patching yourself. With ‘virtual image’ you can also create your databases yourself (don’t ask why it is called PaaS – it’s IaaS but with a Pay As You Go licence for Oracle Database and software provided as an ORACLE_HOME clone).
    We can imagine that with the ‘managed’ DBaaS – not yet available – where Oracle manages everything, you will not be able to patch yourself, nor change every parameters. I suppose that it will need some 12.2HCY2016 lockdown features for that.
    There is a 30 days trial for the Cloud that can be used to test/play with it, and you don’t have to pay anything for it.
    And I’m sure that your customers had some free cloud access (Oracle Sales are very generous with it) to play with. I don’t know what is the risk to use it. Problem with Cloud subscriptions is that you may have some surprise bills later…
    But for the moment, ‘virtual image’ or non-managed DBaaS trial is nice to play. I don’t think Amazon offers a free trial where you don’t have to fill your credit card.
    Cheers,
    Franck.

    • Hey Franck,
      now i am a little bit confused (or too dumb) or maybe just the terms are mixed 😉

      > Oracle Public Cloud PaaS is very different than Amazon RDS here. You have full access, can even sudo su root. You can choose to manage patching yourself. With ‘virtual image’ you can also create your databases yourself.

      OK, but does this mean that i also get access to MOS and patches, if i subscribe something in the cloud? I mean i pay for “as you go license for Oracle Database and software” and so i also need access to MOS and patches for applying them on my own in the cloud. This would be a “good” solution for me (to get MOS access and patches) as an independent consultant without a own CSI.

      > We can imagine that with the ‘managed’ DBaaS – not yet available – where Oracle manages everything, you will not be able to patch yourself, nor change every parameters. I suppose that it will need some 12.2HCY2016 lockdown features for that.

      Yes, that is the point. In your blog post you wrote “Yes, ‘cloud first’ may mean ‘multitenant first’ because that’s the only architecture available for 12c on the Oracle DBaaS”. So i assumed that it will be “a real” DBaaS with “12.2 cloud first” where patches are bundled, provided and applied by Oracle (or via Webinterface by your own) and you are restricted.

      Thank you.

      Regards
      Stefan

  • Ok, I’ve answers from our Cloud Specialist Olivier Toussaint

    To subscribe to a Cloud Service (!= than free trial) you need a CSI and you have access to all patches on MOS, no matter you are on BYOL or PAYG. Same whether you are in metered or unmetered services.

    In all service levels (including the future ‘managed’) you can do whatever you want on the system – at your own risk.
    In ‘virtual image’ you have to manage patching yourself
    In ‘automated’ you can apply available patches with simple click, or download/apply what you want from the system.
    In ‘managed’, well even if you can you should not do it yourself.

    In all of those ‘PaaS’ services you can connect to the VM and wget / OPatch what you want.

    • Hey Franck,
      wow this was quick. Thank you very much for clarification.

      Unfortunately the result is even worse. No own CSI = No 12.2 on Oracle cloud first = No access to 12.2 (aside from the 30 day trial) at all for independent consultants. No idea what Oracle is thinking or if they have thought about this at all.

      This “cloud first” decision is getting more and more ridiculous.

      Thank you.

      Regards
      Stefan

      • LAURENT LETURGEZ says:

        Just a question that gos through my mind: when 12.2 will be available in the cloud, what about if you set up a virtual image with 12.2 on a zip on the machine, you download the zip file on your on prem machine, and eventually a relink to your server.
        Will it work ? (with a small amount of extra work)

  • Bernard Polarski says:

    My dear, time is money, even big money. An Upgrade process, whatever insignifiant it is, is still and upgrade. I am working in a bank and the bugdet of any upgrade of the central DB is superior to the cost of a confortable detached house.
    So when you write :

    “once in 12.1.0.2 you will have the time to plan an upgrade to 12.2 after learning, ….
    The customers in 11.2.0.4 that do not want to plan that intermediate upgrade will have the option to pay for extended support .”

    This is lightly written but hardly acceptable to the hierarchy forced to decide either to pay for 2 upgrades instead of one, or pay more money to Oracle.

    In all case, my society is loosing money due to Oracle delay and policy.

    • Hi Bernard Polarski,

      It seems you are angry, and I can understand that. Sure, upgrading has a cost and running old software has also a cost. And sure we would like to get the dates of future release to be able to plan upgrades for future years.

      Technically, the software vendors cannot maintain many versions of their software. So we have to upgrade or to pay extended support. When you talk about doing 2 upgrades (11.2.0.4->12.1.0.2->12.2.0.x) instead of one (11.2.0.4->12.2.0.x) you are talking about at least a 4 years window. The 11.2.0.4 came out in July 2013 and 12.2 will be there in 2017 and you may wait for a first patchset (12.2.0.x) that may come in 2018 or even later. Upgrading every 2 or 3 years is not something totally abnormal nowadays. This is how IT works today. In comparison, what is the frequency of your in-house Central DB banking application releases? Don’t you have a few application releases every year? Do your developers maintain more than two version of the software?

      Now, we can complain or adapt. Today, lot of automation can be done to run non-regression tests. An idea: just try to upgrade one of the database used for continuous integration and you will quickly see how your application works in 12.1 and maybe an upgrade can be done without being too expensive.
      Lot of features come with the oracle optimizer to ensure that you can upgrade without regression (optimizer_features_enable, SQL Plan Baselines, etc). Yes you can choose to upgrade for support reason and run the optimizer as in previous version. Not that I recommend it, but it’s still better than running unsupported software or risking critical regression. You can also think of upgrades like a continuous project: use logical replication to always maintain a database in higher version. Then switch to it as soon as everything looks good. Then built for the next version.

      Rather that looking at the time it takes to upgrade, you can look at the time it saves. Each new version comes with more automation, online operation, etc. where you save lot of time. Remember the time wasted years ago on sizing tablespaces, rollback segments, memory pools, etc.? Thanks to software evolution we spend no time on that today. If you compare, over the last 15 years, the time saved to the time spent for the upgrade, then the result may be positive.

      Regards,
      Franck.

Leave a Reply

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

Oracle Team
Oracle Team