As you have no doubt heard, Oracle database 21c was released on Friday. I went to work over the weekend doing the relevant articles and builds. They’ve been on the front page of the website since Sunday, but I was waiting for the release of the 21c preinstall package before announcing them. That has arrived now, so this is what I was up to at the weekend.
First the articles for single instance, Data Guard, RAC and RPM installations.
To cut a long story short, an innovation release is only supported for a short time, so you are expected to upgrade very soon after the next release is available. The next release will be Oracle 23c, which will be a long term release.
So what should I do?
There is a reason why Oracle 19c is still top of the downloads page and you have to scroll down to see the 21c downloads. Oracle 19c is the latest long term release, so your main focus should be getting all your databases to Oracle 19c, and preferably running on pluggable databases.
If you have a pressing need for some of the features of Oracle 21c, then by all means test it out and consider going to production with it, but only if you *know* you will be upgrading to Oracle 23c as soon as it’s released.
Of course, this doesn’t stop you playing with Oracle 21c now. I always recommend using the latest release for your playgrounds.
What should I expect of 21c?
Let’s be honest. The Oracle database is a very mature product, so the vast majority of new features will not be of interest to most people. That’s not to say there isn’t any cool stuff, there is, but you know you are still using the database like it is Oracle 7… 🙂
A couple of things that may confuse people with 21c are:
Non-CDB instances are desupported, so you have to use PDBs. I’ve been telling you to learn this stuff since Oracle 12.1! Remember, you can use up to 3 user-defined PDBs without having to pay for the multitenant option, so there is no licensing cost implication to switching to multitenant provided you stay within this limitation.
Read-only Oracle homes are the default in 21c. This functionality was introduced Oracle 18c (see here), but I get the impression most people don’t know it even exists. Well, you better learn! It’s going to take a little time to get used to the new locations of things, but I think it’s a better solution in the long run.
Don’t be stupid, stupid!
Oracle 21c is an innovation release, so make sure you know what you are getting into before launching into using it. If someone is pressuring you into moving to Oracle 21c for real systems, you need to question their motivation.
Over the next few days there will be installation articles appearing here, as well as Vagrant and Docker builds. I’ve already done a first cut of a basic Vagrant build here, but it will probably change a bit over the coming days/weeks as I play with the new release. There will also be RAC and Data Guard builds, but first things first…
Happy upgrading, or not… 🙂
PS. There are still some people that haven’t got the memo yet. There will be no 22c. Oracle is skipping it and the next release after 21c will be 23c.
When I shutdown some VMs before the VirtualBox upgrade, I noticed Vagrant 2.2.18 had been released. Downloads here.
I’ll need to rebuild my Vagrant boxes again, so I thought I should check if there was a new Packer version. Sure enough, Packer 1.7.4 was available. Downloads here. It came out just over a week ago, but I hadn’t noticed.
They are all installed now, so I’ve just got to start doing some Vagrant box builds. Happy days… 🙂
Update: I used Packer to rebuild my OL7 and OL8 vagrant boxes. They are now uploaded to Vagrant Cloud.
The 21.2 version of ORDS and SQLcl dropped at the start of the month. I guess I missed that, as the first I noticed was Alex Nuijten talking about SQLcl 21.2 nearly two weeks later. As soon as I realised they had arrived I downloaded them and went to work.
All of the relevant Vagrant and Docker builds were updated to use ORDS 21.2, SQLcl 21.2 and Tomcat 9.0.50.
The Oracle security patches come out next week, so these builds will be updated again to include the latest versions of OpenJDK (AdoptOpenJDK) and the Oracle database patches where necessary.
SQL Developer and Database Modeler
These aren’t anything to do with my builds, but thought is was worth mentioning. The 21.2 version of SQL Developer and Data Modeler have been available for the last few days. You can read Jeff’s announcement here.
This started a bit of a debate on Twitter about how people patch their databases. In this post I want to touch on a few points that came out Pete’s post an some of the other Twitter comments.
You have to have a plan!
An extremely important point made by Pete was you have to have a plan. That doesn’t have to be the same for everyone, and there may be compromises due to constraints in your company, but that doesn’t stop you making a plan. Your plan might be:
We will start a new round of patching immediately when a new on-off patch is released, and every quarter with the security announcements. I can’t see how this is possible.
We will patch every quarter with the security announcements. That’s what my company does.
We will patch once per (six months, year etc.)
Hopefully your plan will not be:
We will never patch and person X will take the blame when we have a problem.
Release Updates (RUs) or Release Update Revisions (RURs)
Database quarterly patches are classified as release updates (RUs) and release update revisions (RURs). First let’s explain what they are.
Release Updates (RUs) : These are like the old proactive bundle patches. They contain bug fixes, security fixes and limited new features. Let’s call that “extra stuff”. In 19c the blockchain tables and immutable tables features were introduced in RUs. Backporting and new features can introduce new risks.
Release Update Revisions (RURs) : These are just bug fixes and security fixes. In theory these are safer than RUs as less new stuff is introduced, but… See below.
So from first glance you are saying to yourself I want the safest option, so I want to go for RURs. The problem is RURs aren’t like the old security patches that you could continue applying forever. Ultimately you have to include all the “extra stuff” from the previous RUs, but you get the option of doing it later. This page in the documentation explains things quite well.
This table from that link is quite useful, showing you what version you will be on during a quarterly patching cycle.
What does this mean?
If you patch using the RUs, you are going to the latest and greatest each quarter.
If you use RUR-1, you are constantly 1 quarter behind on the RUs extra content, but you add in the missing bug fixes and security fixes using the RUR-1 patch.
If you use RUR-2, you are constantly 2 quarters behind on the RUs extra content, but you add in the missing bug fixes and security fixes using the RUR-2 patch.
In all cases you have the latest bug fixes and security fixes. You are just delaying getting the “extra bits”. So at first glance it seems like you might as well go with the RUs. The issue is some of the RUs are a bit buggy. If you go for the RUR-1 or RUR-2 there is a chance the bugs introduced in the base RU have been fixed in the subsequent RURs for that RU. So we could say this.
RUs: Oracle have zero time to identify and fix the bugs they’ve introduced in the RU.
RUR-1: Oracle have 3 months to find and fix the bugs they’ve introduced in the base RU.
RUR-2: Oracle have 6 months to find and fix the bugs they’ve introduced in the base RU.
I tend to stick with the RUs, although I am considering changing. Ilmar Kerm said he’s found RUs too buggy and tends to stick with the RUR-1 approach. I guess a more conservative approach would be to stick with the RUR-2 approach.
Your experience of the RUs verses the RURs will depend on what features you use, what extra stuff Oracle decide to include in the RU and what they break by including that extra stuff. The biggest problem I got was 19.10 breaking hot-cloning of PDBs, which was kind-of important. If I had used the RUR-1 approach I would never have seen that issue. Different people using different features see different bugs.
How good is your testing?
The biggest factor in the decision of which approach to take is probably the quality of your testing.
If your testing of applications against new patches is good, you can probably stick with the RUs. If the RU fails testing, go with the RUR-1 that quarter.
If you just work on the “generally considered safe” approach, meaning you apply the patches and don’t do any testing, maybe you should be using the RUR-1 or RUR-2 approach!
The ultra-conservative approach would be to stick with the RUR-2 approach.
Regardless of which approach you take, you’ve got to have a plan, and you should be patching. I know some of you don’t care about patching, and you are fools. I know some of you would like to patch, but your companies are dinosaurs. All I can say to you is keep trying.
In my current company we never used to patch. I spent years sending out quarterly reports summarising all the vulnerabilities in our systems and still nothing. Eventually a few other people jumped on the bandwagon, we had a couple of embarrassing issues, and the constant threat of GDPR gave us some more leverage. Now we have a quarterly patching schedule for all our databases and middle tier servers. We are not perfect, but it can be done.
Even now, we still have questions like, “can we miss out this quarter?”, but we push back very hard against this. One quarter becomes two, becomes three, becomes never.
New patches on the 20th July (see here). Good luck everyone!
PS. If you are not patching externally facing WebLogic servers you might as well close your company now. You have already given all your data away. Good luck with that GDPR fine…
I’ve mentioned database upgrades a few times over the last year or more. Like many others, we are pushing hard to get everything upgraded to 19c. Over the last couple of weeks a bunch more systems got upgraded, and we are now looking like this.
The remaining 11.2 and 12.1 databases are all in various stages of migration/upgrade. I would not curse us by giving a deadline for the final databases, but hopefully soon!
The reason for mentioning that theme song is it starts with the words, “It’s been a long road getting from there to here”, and that is exactly how it feels.
Many of the database upgrades are technically simple, but the projects surrounding them are soul destroying. Getting all the relevant people to agree and provide the necessary resources can be really painful. This is especially true for “mature” projects, where the, “if it ain’t broke, don’t fix it”, mentality is strong. I wrote about the problems with that mentality here.
We always go for the multitenant architecture (CDB/PDB) unless there is a compelling reason not to. I think we only have one non-CDB installation of 19c because of a vendor issue. None of our other 3rd party applications have had a problem with using PDBs, provided we’ve made sure they connect with the service, not a SID. We don’t use the USE_SID_AS_SERVICE_listener_name parameter. I would rather find and fix the connection issues than rely on this sticking plaster fix.
In know I’ve said some of these things before, but they are worth repeating.
Oracle 19c is the current long term release, so it’s going to have support for a longer time than an innovation release.
Oracle 21c is an innovation release. Even when the on-prem version does drop, you probably shouldn’t use it for your main systems unless you are happy with the short support lifespan.
I recently heard there won’t be an Oracle 22c, so the next release after Oracle 21c will be Oracle 23c, which is currently slated to be the next long term release.
In short, get all your databases to Oracle 19c, and you should probably stick there until Oracle 23c is released, unless you have a compelling case for going to Oracle 21c.