The rise and fall of read-only Oracle homes

Cast your mind back to the olden days of Oracle 18c, where one of the new features introduced was read-only Oracle homes. I wrote about it here.

Read-Only Oracle Homes in Oracle Database 18c

What was the problem?

Mixing executables, log files and configuration files is a really bad idea. Configuration files tend to have a long lifespan, while executables change all the time due to patches and upgrades. It can be difficult to find log files when they are spread across multiple subdirectories in the Oracle home, although the Automatic Diagnostics Repository (ADR) solved a lot of those problems for us.

Historically Oracle have had this mixed approach, with directories such as “dbs”, “network”, and some of the subdirectories of “rdbms” amongst others under the Oracle home.

The solution?

Read-only Oracle homes solve this problem by splitting out most of the common “problem files” into a separate location, leaving the contents of the Oracle home in a mostly read-only state.

The solution was nice enough, and didn’t require mental gymnastics to understand if you paid a little attention. If you have never tried it, check out the article linked about for the basics.

The Rise

When Oracle 21c was released one of the behaviour changes was that read-only Oracle homes were the default. You could still choose to go read/write, but there was a clear statement of direction. Read-only Oracle homes were the future!

The Fall

I noticed during the 23c beta that the read/write Oracle homes were the default again. I raised a question about it a couple of times. I noticed that Oracle 23c Free used a read/write Oracle home too, but figured that wasn’t a “proper installation”, so whatever.

More recently I was going through the 23c installation guide and I saw this.

“With Oracle Database 23c, an Oracle home is available in read/write mode by default. However, you can choose to configure an Oracle home in read-only mode after you have performed a software-only Oracle Database installation.”

So it looks like we’ve flipped back to the read-write Oracle homes by default in 23c. Read-only Oracle homes are still available. Just not by default.

So what?

I prefer the read-only Oracle homes, and of course I can still choose to use them. The difference now is I expect the vast majority of people will use the read/write homes, as people tend to stick with the path of least resistance. So the question is, do I want to turn myself into a minority?

I understand why this is better for backwards compatibility, but I’m a little disappointed. Forcing the change of the default behaviour would have been nice, and better for the product in the long run.

I’ve got plenty of time to consider my options

Ah well. Better to have loved and lost, than to have your eyes gouged out with rusty spoons… 🙂



PS. I think I may have given some people the impression that read-only Oracle homes are going away. That wasn’t my intention. I’m just talking about the change in default behaviour since Oracle 21c.

Deprecated and Desupported Features in Oracle Database 23c

Every time there is a new database release on the horizon it’s worth looking at the deprecated and desupported features in that release, so you can start planning for the future. Here is the full list from the documentation.

Behavior Changes, Deprecated and Desupported Features for Oracle Database

I’m going to comment on a few things that standout for me. You might find other things more interesting…


DBUA and Manual Upgrade Deprecation : About time! From 21c onward AutoUpgrade is the preferred upgrade approach. Signalling the deprecation of the other approaches is welcome in my opinion. If you’ve never used AutoUpgrade you can see some examples here.

Oracle Persistent Memory Deprecation : Intel killing Optane was the writing on the wall for Oracle Persistent Memory Database (PMEM) and Oracle Memory Speed (OMS) File System. This is not really a surprise.

Deprecation of the mkstore Command-Line Utility : Not a major thing, but I will probably need to revisit a handful of articles to do some small edits. As pointed out by Piotr Wrzosek, the mkstore utility is used for credentials when using a secure external password store. I’m guessing this will be baked into another utility like orapki going forward, but we will see. (see update 2)

DBMS_RESULT_CACHE Function Name Deprecations : I love this move. References to “black lists” are changed to “block lists”. I personally try to use “allow list” and “block list” instead of “white list” and “black list” in conversation. Regardless of any other motivation, I think they are more descriptive.


Non-CDB Architecture : This was deprecated in and desupported in 21c. I’m listing it here because 23c is the first long term released where this is desupported. Most people won’t have progressed past 19c, and may have resisted the multitenant architecture. You can’t resist any longer. I’ve written loads about pluggable databases here. Please get up to speed with it.

Original Export Utility (EXP) Desupported : For some reason this feels like a “WOW” moment, but in reality I can’t remember the last time I used imp/exp. The IMP utility is clearly still supported to allow direct upgrades from older releases. Can you believe it’s about 18 years since Data Pump was introduced? 🙂

Oracle Enterprise Manager Database Express (EM Express) Desupported : This feature never really hit home with me, so I’m not sorry to see it gone. For most stuff you can just use SQL Developer which replicates the functionality. Of course, if you have Cloud Control, you wouldn’t be using the express feature anyway.

Transport Layer Security versions 1.0 and 1.1 Desupported : Great! If you do still need to make database callouts to old services that don’t support TLSv1.2 or above, just put a load balancer or reverse proxy in front of them and you are sorted. We usually do that anyway to ease certificate management for database callouts. See here.

Traditional Auditing Desupported : Cool. I prefer unified audit policies anyway, and it’s been the preferred method since 12.1, so it’s hardly a surprise. I mentioned this here.

Desupport of 32-Bit Oracle Database Clients : I can’t remember the last time I used a 32-bit client or server, so this doesn’t phase me.


Deprecated is not desupported. You can continue to use deprecated features, but you should be looking to move away from them before they are desupported in a future version.

The desupported stuff shouldn’t come as a big surprise as most things have been deprecated for some time. In some cases over many releases.

Make sure you check the full list for yourself, as there might be something important you need to think about.



Update 1: As mentioned in Mike Dietrich’s blog post (here) the public docs are currently for Oracle Database 23c Free, so the final on-prem release may include some changes. Keep your eyes open. 🙂

Update 2: Martin Bach confirmed by assumption that the credentials functionality would be included in a later version of orapki, as mentioned in this post.

Oracle Documentation : The Redwood Look & Feel

If you take a look at the database documentation you will notice there has been a change. The new “Redwood” look and feel has been applied. I thought I would give my opinion, for what it is worth.

Remember, these are my first impressions.

Change is always bad!

As soon as you change something, people (like me) are going to come out of the woodwork and start criticising it. Within a week everyone will have forgotten what things used to be like, and a new steady state will be achieved.

Everything except My Oracle Support (MOS). I’ve never got used to the “new” interface, which we have probably had for a decade, and I still think it is bad… 😉

Expand (Not) All

The Expand/Collapse button only expands a single level down the hierarchy. That makes finding things in some manuals impossible. I regularly do an expand-all, then search using the browser search (CTRL+F) to find a feature or parameter. This change of behaviour is a complete disaster!

There is no way this was tested by anyone who actually uses the docs for their job. Either that, or their feedback was ignored.


The basic page is split into three columns, with a margin on each side (see here).

On the left is the index, which is similar to what we had before. The middle panel is the main bit of the text. The panel on the right is another sort-of mini index. I really don’t understand what the right panel is for. If the share links were put on the left index, the right panel could be removed entirely. The two side panels are collapsible, which is good. I get the feeling my first visit will always have an additional click to collapse the right panel.


The layout is responsive, so as you alter the width of the page some of the panels will collapse. Unfortunately the pointless right-hand panel seems to have priority over the useful left-hand panel. You quite often get this sort of look. Also, when you expand the screen again, the useful left-hand panel doesn’t reappear.

This happens to be the default when the docs are viewed on my work laptop. Yuck! You can manually correct it by collapsing the right panel and expanding the left. That’s two extra clicks. Yes. I am really so lazy that this bothers me.

The margins also expand as the page expands. At their biggest they are about 5cm (1.5 inches) on each side. That seems rather wide to me. I’ve read that most people find reading a narrower panel of text easier, but when I read the docs I like to have them wide. As a result the excessive margins annoy me. I’m sure the vast majority of people will not be bothered by them though. Once again, I am the victim of my large monitor. On a normal size screen the margins don’t seem excessive at all.

Text Size

The default text size for the central column is good for me. They’ve resisted the urge to make everything big and bubbly. Technical docs are not the same as normal websites, and I prefer some moderation in text size. If people need bigger text, the browser can zoom.

The left index is possibly a little smaller than I would like on my main monitor, but when I look at it on a “normal person” monitor, or on my work laptop, it looks great. In this case I’m the victim of my excessively sized monitor. 🙂


I’m no expert on accessibility, but suffice to say the docs fail. So does my website, so I’m not in a position to criticise that much, but it does seem odd that a big redesign like this was not done with accessibility in mind.

I imagine the colour contrast on the left and right panels are not great. They are fine for me, but I see these colour contrast issues all the time, including on my own website.

Community Feedback?

In the future, please reach out the the community to get feedback on important issues like this. You have a pool of Oracle ACEs who are under NDA, who are more than willing to help with feedback! The two glaring mistakes would have been picked up really quickly if you had asked for feedback from people who actually use the docs constantly.


The expand-all capability has to be returned to the index ASAP! Some docs, specifically the reference manuals, are unusable without it. This is a massive fail!

The right-hand panel has to go, or be collapsed by default! Its only value is to waste space. Please get rid of it!

As for everything else, it’s all different but the same. Nothing to see here. 🙂



Why are RHEL/Oracle Linux upgrades still so unreliable?

The RHEL distribution is still really popular in the enterprise Linux market. The stats sometimes look worse because the users are split across both RHEL and all of its many clones, but it still represents a massive chunk of the enterprise market. With that in mind, why are RHEL upgrades still so unreliable?

My history of OS upgrades

Over the years I’ve done loads of operating system upgrades. In “recent” times I’ve done Windows upgrades (8 -> 8.1 -> 10 -> 11) and loads of Intel macOS upgrades with minimal drama. That’s not the case with Linux.

About a decade ago I was using Fedup to upgrade between versions of Fedora. That was later replace by the DNF upgrade process. More recently I’ve tried my hand using Leapp to upgrade Oracle Linux. I’m no expert, but these upgrades always feel really janky. You never really know what you are going to get until the upgrade is complete. The milage varies depending on configuration of the server, and what software has been installed on it. In some cases you have a system that is running fine. In some cases you have a running server, but a bunch of the configuration has to be redone to make your application work. In some cases you have bricked your server. Not exactly confidence building.

So what is the alternative?

My overall feel has always been don’t upgrade! Build new kit, migrate across to it, then ditch the old kit.

In the past we would typically make that process fit with the lifespan of the physical kit, but now when we use virtual machines we could potentially have a VM that outlives the physical kit many times over, so the desire to migrate is not so pressing, and a reliable in-place upgrade process is more desirable.

Migrating to a new server comes with a hole bunch of overheads. It’s a lot more work than an in-place OS upgrade.

Infrastructure as Code

If you have true infrastructure as code, you can build new systems really quickly, including all the VMs, networking and firewalls, which just leaves you with the data migration to worry about. If you are not in that position, it’s a nightmare of service tickets and endless waiting.


Is it too much to ask for such a dominant operating system to have reliable upgrades?

I would love to know your experiences of OS upgrades for RHEL and its clones. Have I just been really unlucky with Leapp, or are upgrade really as bad as I think?



Update 1: I ran a poll on Twitter. There weren’t many responses, but at least I can see I’m not completely alone. 🙂

Update 2: There are some interesting responses in the comments. Well worth you giving them a look.

Oracle product certifications on Oracle Linux 9. What is going on?

See update at the end.

Warning. Rant mode enabled…

It’s over a year since Oracle Linux 9 was released and we still haven’t seen any certifications of Oracle products on it. What is going on?

Check out the really important update at the end of the post.

Setting the scene

Here are the current support dates for Oracle Linux.

ReleaseGA DatePremier Support EndsExtended Support Ends
OL6Feb 2011Mar 2021Jul 2024
OL7Jul 2014Jul 2024Jun 2026
OL8Jul 2019Jul 2029Jul 2031
OL9Jun 2022Jun 2032Jun 2034

So unless you want to start paying for extended support, you need to be getting rid of OL7 soon. The problem is, you can only move to OL8, because OL9 is not supported for Oracle 19c yet.

So if you are trying to do the right thing by migrating off OL7, you are being forced on to an old version of the OS, which in turn reduces the amount of time you can run before the next OS move.

The next long term release of the Oracle database is Oracle 23c. It’s still in beta, so we don’t know what it will be supported on yet, but 23c Free is only available for RHEL8/OL8 at this time.

Your choices?

So your choices are:

  • Migrate on to OL8, which solves your OS support issue, and will allow you to upgrade to 23c when it is released.
  • Wait for 23c to be released and hope it is supported on OL9. If it is, do a big bang migration to OL9 and 23c, hoping you can get it all done before the OL7 support deadline.

I don’t like either of these choices.

What do I want?

Apart from unlimited wishes, I want:

  • A definitive statement about if Oracle 19c will ever be supported on OL9. If it will be, when is that likely to happen? My guess is this will never happen, but I want an official statement ASAP.
  • A definitive statement about support for Oracle 23c on OL9. Will it be supported when 23c goes GA?
  • I guess it would also be nice if RHEL/OL upgrades actually worked reliably, but that is the subject for another rant!


I think like most people, I just want some clarity. It’s hard to plan when you don’t have any of the vital information. The thought of having to move to OL8 rather than OL9 is kind-of depressing… 😞



Update from Oracle: “Oracle Database product management has confirmed that when Oracle Database 23c ships, it will be certified for both OL8 and OL9. Also, Oracle Database 19c will be certified on OL9 before end of 2023.”

Update: Oracle have now certified Oracle 19c on Oracle Linux 9, as discussed here.