Oracle Database 20c : Cloud Preview, Docs and Desupport

A little while ago Dominic Giles tweeted about the release of an Oracle Database 20c preview on Oracle Cloud and the Oracle Database 20c documentation. Some lucky people have already deployed the 20c preview. 🙂

Should we upgrade ASAP?

Dominic was quick to point out 19c is the long term support (LTS) release, and your focus should be to upgrade to that release. You should probably only upgrade to 20c if you really need some of the functionality it delivers, and are prepared to upgrade and patch regularly until you hit the next long term support release, which is likely to be 22c according to a slide from Sangham 2019, posted on Twitter by Patrick Jolliffe. 🙂

Most people will probably jump between LTS releases every 3-4 years.

I only care about LTS releases, so 20c is irrelevant right?

Wrong! {in flashing red lights}

It’s important to check out what is happening in the 20c release, because it may alter how you use the earlier releases now. There is no point launching into a new development using a feature that is about to disappear. Remember Oracle Streams anyone?

I’ve been banging on about Multitenant for over 6 years now, and I know a lot of people out there have stuck with the non-CDB architecture. If your intention is to jump between LTS releases, you need to get your CDB/PDB-foo up to scratch before the next LTS release, because as of 2oc, non-CDB has gone.

What should I do?

Take a look at this section of the Upgrade Manual.

Just scan down it to see if anything stands out as problematic for you. There are sections for 12.2, 18c and 19c too, if you are starting from further back. Think about the impact of this stuff on new and existing database deployments.

My advice. Stop using deprecated features ASAP. Start your migration away from them before you have to start worrying about upgrades.

Hopefully this will stop you making some bad decsions!

What stood out to you Tim?

I went on a Twitter frenzy as I was reading this section. Sorry about the spam if you follow me. 🙂

This is what jumped out at me. I’m not saying these all affect me, but they are interesting to me.

“Starting with Oracle Database 20c, Oracle Database is only supported using the multitenant architecture.”

I hope you knew this before this post. If this fills you with dread, don’t panic. I have articles here, and a YouTube playlist here. It’s going to be OK. You will get through this trauma! 🙂

“Traditional auditing is deprecated in Oracle Database 20c. Oracle recommends that you use unified auditing, which enables selective and more effective auditing inside Oracle Database.”

I’m not sure how this affects me. Further investigation is needed.

“Starting with Oracle Database 20c, older encryption and hashing algorithms contained within DBMS_CRYPTO are deprecated.”

This is giving me a bit of a panic attack. I don’t know how big an impact this is. It’s a deprecation notice, not a desupport notice, so there is still time… Maybe…

“Starting with Oracle Database 20c, Transport Layer Security protocol version 1.0 (TLS 1.0) is deprecated.”

When SSLv3 got pulled it killed us. Why? Because too many people were complacent and not willing to patch/upgrade their systems. As a result, on the day some of our external services turned off SSLv3, internal stuff broke and panic patching started! Patching without planning or testing.

Once again, this is a deprecation notice, so you’ve got time to start doing the right thing, but don’t leave it to the last minute. I always say it takes work to remain stationary in tech. You are swimming upstream and just keeping at the same spot takes effort. If you don’t make that effort, you are just floating downstream.

“Starting in Oracle Database 20c, the package DBMS_OBFUSCATION_TOOLKIT is desupported, and replaced with DBMS_CRYPTO.”

I’m hoping I’ve got everything moved across to DBMS_CRYPTO, but who knows?

“Starting in Oracle Database 20c, the Large Object (LOB) features DBMS_LOB.LOADFROMFILE and LOB buffering are desupported.”

Some time ago someone pointed out the deprecation notice in a previous release and I revisited all my website stuff (I think). It’s pretty easy to move to loadblobfromfile and loadclobfromfile, but that’s a piece of work and some testing that needs doing!

“Starting with Oracle Database 20c, the Oracle Grid Infrastructure feature Automatic Storage Management Cluster File System (Oracle ACFS) is desupported with Microsoft Windows”

This doesn’t affect me, but when you look at this alongside all the other ACFS deprecation and dessupport notices is makes rather grim reading. On the one had I’m thinking ACFS is for the chopping block, but on the other hand there are new features. Who knows what’s going on here?

“Desupport of Vendor Clusterware Integration with Oracle Clusterware”

I only included this one because it took me back to the glory days of Oracle 9i RAC on Tru64 and TruCluster. For quite some time since then, combining Oracle Clusterware with other clustering solutions as resulted in a clusterf*ck!

“Starting in Oracle Database 20c, the IGNORECASE parameter for the orapwd file is desupported. All newly created password files are case-sensitive.”

If I’m honest, I kind-of forgot this was possible. I think I only have one project that still uses case-insensitive passwords generally, and as of December last year, that is no longer necessary. I can’t remember needing case-insensitive passwords in the password file.

Is that it?

No, but it’s what stood out to me. Check the documentation for yourself and see what stands out for you.

What if it makes me depressed?

Check out the New Features Guide and look at all the new stuff you get to play with. Anyone want a new JSON data type with better performance? 🙂



Multitenant : Massive Changes in 19c and 20c

Is it safe to talk about this now? The announcement has happened and Mike Dietrich has posted about it, so I think so…

A couple of massive things have happened regarding the multitenant architecture in Oracle 19c and 20c.


Prior to 19c, you were only allowed to have a single user-defined pluggable database (plus a root container and a proxy) without having to license the full multitenant option. I’ve been a big proponent of single-tennant or lone-PDB, but I can understand the reluctance of people to go that way, as it’s harder to realise the benefits, even though they do exist.

Oracle have now announced from 19c onward you can have 3 user-defined PDBs, without having the multitenant option. This is similar to what we got with 18c XE. As Mike points out, the documentation has already been changed to reflect this.

“For all offerings, if you are not licensed for Oracle Multitenant, then you may have up to 3 PDBs in a given container database at any time.”

Database Licensing Information User Manual

I think this is will be a massive boost for the uptake of the multitenant architecture. I’ve got some 19c stuff that will probably make use of this within days of me getting back to work!



Are you one of those people that have been saying, “Screw that multitenant stuff. I’m sticking with non-CDB architecture!” Good luck with that. In 20c the non-CDB architecture will be desupported.

You probably know the non-CDB architecture was deprecated since, but in 20c non-CDB is no longer an option, unless you are happy about running without support I guess.

This means your 20c upgrade will also include a migration to the multitenant architecture. What I would suggest is you start down that road today by moving to multitenant in 19c, then when you have to move to the next long term support release (2?c), you won’t be getting any surprises. What’s more, the 3 PDBs thing in 19c makes that all the more attractive!

If this announcement has made you panic, don’t worry. I’ve written a bunch of stuff about multitenant over the years, and there’s a YouTube playlist too.



PS. Smiles smugly to himself that he invested the time into learning multitenant from 12.1 onward…

PPS. I will be going through my existing articles amending any mention of licensing and PDB limits and desupport etc. Those changes won’t happen overnight. 🙂