Since 2016 we’ve had an Oracle community day where we push out content on the same day to try and get a bit of a community buzz. The name has changed over the years, but in 2021 it was renamed to the “Joel Kallman Day”. Joel was big on community, and it seems like a fitting tribute to him.
When is it?
The date is Wednesday October 11th. That’s just over a week away from today!
How do I get involved?
Here is the way it works.
Write a blog post. The title should be in the format “<insert-the-title-here> #JoelKallmanDay“.
The content can be pretty much anything. See the section below.
Tweet/X out the blog post using the hashtag #JoelKallmanDay.
Publishing the posts on the same day allows us to generate a buzz. In previous years loads of people were on twitter retweeting, making it even bigger. The community is spread around the world, so the posts will be released over a 24 hour period.
Oracle employees are welcome to join in. This is a community day about anything to do with the Oracle community.
Like previous years, it would be really nice if we could get a bunch of first-timers involved, but it’s also an opportunity to see existing folks blog for the first time in ages!
The following day I write a summary post that includes links to all the posts that were pushed out through the day. You can see examples here.
Whatever you want to write about. Here are some suggestions that might help you.
My favourite feature of {the Oracle-related tech you work on}.
What is the next thing on your list to learn.
Horror stories. My biggest screw up, and how I fixed it.
How the cloud has affected my job.
What I get out of the Oracle Community.
What feature I would love to see added to {the Oracle-related tech you work on}.
The project I worked on that I’m the most proud of. (Related to Oracle tech of course)
It’s not limited to these. You can literally write about anything Oracle-related. The posts can be short, which makes it easy for new people to get involved. If you do want to write about something technical, that’s fine. You can also write a simple overview post and link to more detailed posts on a subject if you like. In the previous years the posts I enjoyed the most were those that showed the human side of things, but that’s just me. Do whatever you like.
Do I have to write in English?
No! It’s great to see people contributing to their own community. Google Translate does a pretty good job of translating them, so we can still read them.
Do I need to write about Joel or APEX?
I’m sure people would be happy to read stories about Joel, or content about APEX, but you don’t have to write about that. You can write about whatever you want, so long as it has an Oracle and/or community spin…
So you have a little over a week to get something ready!
Oracle Cloud World is happening, which typically means lots of announcements. One of the welcome announcement was the release of Oracle 23c on OCI Oracle Base Database Service, so there is a production version generally available… Sort of… Why do I say “sort of”?
OCI Oracle Base Database Service
This is a single cloud service, and it’s not available on the free tier, so it’s only available for paying customers that want to use this particular service.
At the time of writing there is no Autonomous Database service for this version, and there is still no full on-prem release.
I thought it was unavailable in my data centre, but Jeff Smith told me 23c GA is only available for Intel shapes at the moment. Once I switched from the default AMD shape to an Intel shape and 23c release was in the database version list. Happy days.
Oracle Database 23c Free
In addition to the OCI Oracle Base Database Service, the announcement post mentions a new version of Oracle Database 23c Free. It is now a “Developer Release”, not a “Developer Preview”. You can get hold of it here.
The slightly confusing thing is there is no difference in the file name, so my immediate impression was it had not actually been released yet. I downloaded the file and did an installation, and sure enough it was version 23.3. It would have been nice if there was an indication of the update on the page, or a version number in the file name…
For those that previously used Oracle XE, Oracle Database 23c Free is now the natural replacement, so go crazy with it. 🙂
The documentation links we’ve been using for 23c Free are no longer marked as “Free”. It is the normal GA documentation now.
My 23c Articles
You can see all my 23c articles here. There are still some I can’t publish until the on-prem GA release happens…
On-Prem Release
As mentioned previously, there is no full on-prem release for Oracle 23c, so you can’t start planning your upgrades from 19c yet. It’s really good to have an updated version of Oracle Database 23c Free so quickly for home use, but from a work perspective 23c won’t really exist for me until there is an on-prem release.
I’m hoping that won’t be long, but time will tell.
This is a very interesting development for a number of reasons. Here are some of my thoughts…
The database is not a driving factor in cloud provider selection
Over the years Oracle have been playing the game of making Oracle Cloud look like the most attractive place to run Oracle databases. What I think they had lost sight of is the database is not the driving factor in the choice of which cloud provider to pick. It might not even be part of the decision process. Quite often there are other factors that have much more sway.
This move is a welcome step, but I feel like it should just be the beginning!
Software should run on every cloud
I’m sure some people in Oracle now consider themselves a “cloud company”, but I think most of us still consider Oracle as a software company. Oracle rely on sales/licensing to make their money. As a result, anything that blocks the sale of a product is a problem.
Whatever cloud provider I pick, Oracle should be hoping I choose their software to run on my systems.
Not only are companies multi-cloud, but they already use multiple database engines. If there is any friction to using your product, they can go elsewhere.
A welcome start, but…
I’m really glad Oracle have taken this step. Microsoft are the second largest cloud provider, and anything that simplifies using Oracle databases on Azure is a good thing. IMHO this should be the start of the journey. Oracle should be trying to get similar partnerships with other cloud providers too.
Unless I’m missing something, or it’s not been amended yet, this document looks unchanged to me.
The pricing of Oracle on Azure seems to be unchanged, and we are still limited to AWS and Azure as “Authorized Cloud Environments”.
What would I do?
There are two main things:
I would make the pricing consistent across all cloud providers and on-prem.
I would increase the number of “Authorized Cloud Providers”.
The stats vary, but a quick Google shows me the following market share information.
AWS : 32%
Azure : 22%
Google : 11%
Alibaba : 4%
Oracle : 2%
Just adding Google and Alibaba would add another 15% of the cloud market as potential customers.
What do I know?
I’m sure someone will tell me I don’t know what I’m talking about, and maybe they are right. I just think Oracle should be making sure most/all of their software is available to run anywhere people want to run it.
As I said before, I’m really happy about this announcement, but I think it needs to be the first step on a longer journey.
We recently had an issue, which I suspect was caused by overlapping CRON jobs. By that I mean a CRON job had not completed its run by the time it was scheduled to run again.
CRON
If you’ve used UNIX/Linux you’ve probably scheduled a task using CRON. We’ve got loads of CRON jobs on some of our systems. The problem with CRON is it doesn’t care about overlapping jobs. If you schedule something to run every 10 minutes, but the task takes 30 minutes to complete, you will get overlapping runs. In some situations this can degrade performance to the point where each run gets progressively longer, meaning there are more and more overlaps. Eventually things can go bang!
Fortunately there is a really easy solution to this. Just use “flock”.
Let’s say we have a job that runs every 10 minutes.
The Oracle Scheduler (DBMS_SCHEDULER) doesn’t suffer from overlapping jobs. The previous run must be complete before the next run can happen. If we have a really slow bit of code that takes 30 minutes to run, it is safe to schedule it to run every 10 minutes, even though it may seem a little stupid.
The Oracle Scheduler also has a bunch of other features that CRON doesn’t have. See here.
Conclusion
I’m not a massive fan of CRON. For many database tasks I think the Oracle Scheduler is far superior. If you are going to use CRON, please use it safely. 🙂
Upgrading a database is not about the technical side of things. It’s about the planning that is required. I can upgrade a database in a few minutes, but the project to upgrade all the environments for a specific application can take months to complete. In this post I want to discuss some of the issues we are discussing at the moment regarding our future Oracle 23c upgrades.
What support dates are relevant?
Here are the support dates for the Oracle database.
To upgrade directly to 23c we must be running Oracle 19c or 21c.
All our databases are on 19c, so this puts us in a good position. It took a lot of pain and effort to get us to 19c, but it was worth it!
PDB or non-CDB architecture?
The non-CDB architecture was deprecated in 12.1.0.2, but it has remained supported up to, and including, 19c. So Oracle 23c will be the first long term release where the non-CDB architecture is not an option. If you’ve not got up to speed on pluggable databases, you better get started soon! (Multitenant Articles)
With one exception, we have PDBs across the board, so there is nothing new for us here. It sometimes felt like I was swimming against the tide by pushing PDBs so hard over the years, but it all seems worth it now.
What OS are you running on?
I’m going to conveniently forget that anything other than RHEL/OL exist, because other operating systems don’t exist for me in the context of running Oracle databases.
It took us a long time to migrate from OL6 to OL7. The majority of our Oracle databases are currently still running on OL7, which is fast approaching end of life. Since Oracle 23c will not be supported on OL7, we are going to need to migrate to a newer operating system. I wrote about my scepticism around in-place RHEL/OL upgrades (here), so that leaves us two choices.
Move our existing databases to a new OS now, then upgrade to 23c later.
Wait for the 23c upgrade, and do a big-bang OS migration and database upgrade.
What’s stopping us from doing the first option now? Nothing really. We could migrate our 19c databases to OL8 servers. It would be nicer to migrate them to OL9, but it is not supported for 19c yet. I recently wrote a rant about product certifications on Oracle Linux 9, which resulted in this response 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.”
That’s really good news, as it gives us more options when we move forward.
Will Oracle Linux exist in the future? Yes!
Just as I thought I had got my head around the sequence of events, RHEL dropped the bombshell about how they would distribute their source in future (see here). This raised concerns about if RHEL clones such as Oracle Linux, Rocky Linux and AlmaLinux could even exist in future.
Without knowing the future of our main operating system, we were questioning what to deploy on new servers. Do we continue with OL or switch to RHEL? Rocky and Alma released some “don’t panic” messages, but Oracle were very quiet. I wasn’t surprised by that, because Oracle don’t say anything until it has passed through legal, but as a customer it was a very nervy time.
A couple of days ago we got a statement from Oracle (here), with a firm commitment to the future of Oracle Linux. I immediately spoke to our system admins and said OL8/OL9 is back on the table. Phew!
I have my own opinions on the RHEL vs clones situation, but as a customer it’s not about politics. I just need to know the OS we are using is still going to exist, and will be supported for our databases. In that respect the statement from Oracle was very welcome!
Do you need a hardware refresh?
If you are running on physical kit, you need to check your maintenance agreements. You may need a hardware fresh to keep everything up to date.
We run everything on virtual machines (VMs), so the hardware changes to the clusters have no impact on our VMs. We’ve had at least one hardware refresh during the lifespan of some of our database VMs.
We use a lot of third party applications, and some of the vendors are really slow to certify their applications on new versions of the database and operating systems.
Ultimately we will make a choice on destination versions and timings based on application vendor support.
Manual or AutoUpgrade?
In Oracle 23c manual upgrades are deprecated (but still supported). I was late to the party with AutoUpgrade, but now I’ve used it I will never do manual upgrades again. We will definitely be using AutoUpgrade for our 23c upgrades!
If you are new to AutoUpgrade I have some examples of using it when I was doing 21c upgrades (see here). That should help you get started.
What are you going to test?
Testing is always a big stumbling block for us. We are not very far down the path of automated testing, which means we need bodies to complete testing. The availability of testing resource is always an issue. There are times of the year when it is extremely unlikely people will be made available, so planning this resource is really important.
So what’s the plan?
It’s always a balancing act around support for the OS, database and application vendors. Ultimately each project will have to be dealt with on a case by case basis, as the allocation of testing resources and potential disruption to the business have to be factored in. Everything is open to change, but…
Our default stance is we will upgrade to Oracle 23c on OL9. We will build new OL9 servers and install 23c on them, then use AutoUpgrade to migrate and upgrade the databases. For some of our internal developments I feel this could happen relatively quickly (kiss of death).
Application vendor support is often a sticking point for us, and timing will have to factor in the OL7 end of life. If support for 19c on OL9 comes in time, we may migrate our 19c databases to OL9, while we wait for a vendor to support Oracle 23c. Alternatively we could pay for extended support for OL7, and do the OS and database in one go once the application vendor is happy.
I realise this has been a bit of a ramble, but I just wanted to write it down to get things straight in my own head. 🙂
Cheers
Tim…
PS. I have some technical posts on upgrading to 23c that will be released once the on-prem version of 23c goes GA.
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… 🙂
Cheers
Tim…
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.
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.
I’m going to comment on a few things that standout for me. You might find other things more interesting…
Deprecated
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.
Desupported
Non-CDB Architecture : This was deprecated in 12.1.0.2 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.
Remember
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.
Cheers
Tim…
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.
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.
Layout
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.
Responsive?
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. 🙂
Accessibility
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.
Conclusion
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. 🙂
I’ve installed it on Windows 11 machine with no drama. I’ll be running my Packer builds of all my Vagrant boxes later today, which you can find on Vagrant Cloud here.
