Fedora 36 and Oracle

Fedora 36 was released recently. Here comes the standard warning.

Here are the usual things I do when a new version of Fedora comes out.

Why do I do this? As mentioned in the first link, Fedora is a proving ground for future versions of RHEL, and therefore Oracle Linux. I like to see what is coming around the corner. Doing this has no “real world” value, but I’m a geek, and this is what geeks do. 🙂

As an aside, when Fedora 35 was released I was having a lot of trouble getting 19c and 21c installed on it. I tried a number of times over the course of a few weeks and failed each time. When I tried those same installations on Fedora 36 they just worked, so I went back and tried on Fedora 35 again, and they worked there too. Clearly there have been some changes to underlying Fedora 35 packages that have fixed whatever the problem was with the Oracle installations. As a result, I also produced these.

Now that Fedora 36 exists, these Fedora 35 installations are not really necessary, but it’s nice to do them for the sake of completeness.

I pushed Vagrant builds to my GitHub.

If you want to try these out, you will need to build the base Vagrant boxes using Packer. You can find the Packer builds on my GitHub too.

So now you know how to do it, please don’t! 🙂

What’s New?

So what’s new with Fedora 36? It’s a bleeding edge distribution, so as you might expect, loads of package version updates, bringing most things to the latest and greatest versions. The things that stand out for me are Ansible 5 and Podman 4.0. If you want a more complete perspective on this, you might want to look here.

Cheers

Tim…

ORDS : Migration of Legacy Configuration – Why You Shouldn’t Do It!

Just in case you didn’t get the memo, the installation and configuration of ORDS has changed in version 22.1 onward. As well has the changes to the command line, there is also a different structure for the configuration files. ORDS gives you an option to migrate your existing configuration from the legacy format to the new format, which is good right? Maybe not…

Let me start by saying, there is absolutely nothing wrong with doing this conversion if that’s what you want, but I’m going to explain why it’s a bad idea from my perspective. You are allowed to disagree, and I would like to hear your reasons, but I’m going to explain why I think you shouldn’t do this…

Build Scripts

We run ORDS using Tomcat in Docker containers. Each instance gets one or more ORDS containers. There is a load balancer in front of ORDS to handle CA certificates etc.

Every time we have an update of ORDS, Java, Tomcat or SQLcl, we build a new image, throw away the old containers and create new containers from the new image. As a result, it’s really important we are able to rebuild everything cleanly. The Docker image build is essentially our build script. Even if you don’t use containers, I would suggest you have a build script for everything. You want to be sure that in a nightmare scenario, you can rebuild everything quickly and cleanly.

What’s this got to do with migrating the old configuration? What is your build script? Build and configure in the old version of ORDS and convert the config to the new version? I don’t think so. IMHO you need to invest a little time and create new build scripts using the new version of ORDS. You can’t rely on a bunch of commands you ran in an old version of the product…

But we have a complex build!

I can hear the cries of, “but we have a complex build, so the conversion is easier!” If you have a complex build, replacing it is even harder should something go wrong, so having a version controlled build script is even more important for you than people with simple builds. I wouldn’t be happy about going live with something I couldn’t rebuild. Added to that, the time and effort of getting to grips with the new command line will teach you more about the product, which allows you to support it better.

Web Service Definitions

As I’ve said before, the changes for ORDS are mostly around installation and configuration. Your existing web service definitions will work just fine. They are stored in the database, and will remain untouched by the upgrade. You still need version controlled scripts for their definitions, but you shouldn’t need to run any of them when upgrading ORDS.

So when I’m talking about the migration of config, I am not talking about your web service definitions. I’m talking about the installation and configuration of ORDS at the top-level.

Conclusion

I completely understand why this conversion option exists. Someone will want to use it and giving people choices is typically a good thing. I just don’t think people should use it.

Remember, my thoughts are based on my experience of using ORDS, and I understand that can be a very limited view point. I would be interested to know if someone has a compelling reason why my view on this is wrong. It’s unlikely what you say will alter the way we use ORDS, but it’s always good to know of different approaches, because you never know when they will come in handy in the future…

Tim…

Oracle REST Data Services (ORDS) 22.1 : Article Updates

A couple of weeks ago I wrote about the big changes that have come with version 22.1 of ORDS (here). I mentioned that the changes meant I had to revisit a bunch of my content. I think that process is done now.

As I predicted, there are three new articles so far. I mentioned the first of these in my last post.

These had changed so much is made sense to do them as new articles, rather than trying to cope the “pre-22.1” and “22.1 onward” approaches in one article.

Since the changes are in the configuration, rather than feature usage, most of the other articles needed less work. Typically just references about how to enable/disable features. I’ve worked through all the articles now and I think I’ve sorted everything. I’m sure over time I’ll spot other things I want to add or edit. 🙂 Here’s a link to all the ORDS articles on my website.

ORDS : All Articles

Cheers

Tim…

ORDS and APEX 22.1 : Vagrant and Docker Builds

I was on top of the recent ORDS 22.1 release, but somehow I managed to miss the APEX 22.1 release. Here’s an update on what’s been going on with my builds…

Vagrant Builds

A number of my Vagrant database builds include APEX. Those that do have been updated to use APEX 22.1. You can find them here.

They had already been updated to use the latest versions of Java, Tomcat, ORDS and SQLcl where appropriate, so the APEX upgrade was a small change. The ORDS update was done 11 days ago. It was a bigger update, as the installation process for ORDS 22.1 has changed quite a bit. I wrote about that here.

You can read my beginner’s guide to Vagrant here.

Docker/Container Builds

I have some ORDS containers that include the APEX images, so those image builds have been updated to use ORDS 22.1 and APEX 22.1 images now.

APEX is also included in the database builds. You can find them here.

I was a little slow to add the updates to the Docker builds. The Tomcat and SQLcl changes were done a couple of weeks ago, but I’ve only added the Java, ORDS and APEX changes today. I held back a little on the ORDS 22.1 changes, as I was rewriting a bunch of articles that were affected by the installation and configuration changes.

You can read my Docker/Container articles here.

Real Life

We probably won’t be putting APEX 22.1 live until the next patching cycle, which will be July. In the past I could be quite aggressive about the upgrades, but as APEX is becoming more important in the organisation, the rollout of updates has to be a bit more considered. 🙂

The same will probably be true for the ORDS 22.1 rollout. We run ORDS in containers, so it’s really quick and easy to replace all the infrastructure, but I wanted to be a bit cautious because of all the changes in the new version. Having played with it a bit now, I’m feeling a lot more confident, but at the time we were starting our patching cycle I was too nervous to include it.

As far as home systems are concerned, I only use the latest and greatest, unless there is a compelling reason not to. 😉

Cheers

Tim…

Oracle REST Data Services (ORDS) 22.1 : All Change!

You may have heard version 22.1 of Oracle REST Data Services (ORDS) has been released. For the versions between 3.0 and 21.4 the installation process was pretty much the same. From version 22.1 it’s out with the old and in with the new…

I’ve put out an installation article, but remember it’s early days for me, so I will probably be revisiting this over the coming weeks as I learn more.

The Big News

  • We no longer run commands using “ords.war” directly. Instead we use an “ords” script/executable in the “bin” subdirectory. That kind-of makes every installation or configuration article you’ve ever read wrong.
  • The above change means standalone mode is also different, so even starting and stopping ORDS has changed.
  • The configuration location is no longer written into the “ords.war” file, so you have to make sure standalone, Tomcat, WebLogic knows where to find the config.
  • The contents/structure of the configuration has changed, so once again anything you’ve read about configuration has probably changed.

It all sounds quite dramatic, and it certainly confused the hell out of me, but I think a couple of weeks down the line I will forget it was ever any other way. 🙂

I’ve updated one of my Vagrant builds to use the new version. I’ll do the others over time…

Over the next few days/weeks I’ve got to visit all my ORDS content (over 30 articles) to check how these changes have impacted it. Off the top of my head I think I’ve got about 3 rewrites to do, and some corrections of other articles.

Don’t Panic

From a usage perspective, ORDS looks the same, so there is no need to panic. It’s just one of those administration evolutions you expect in the lifetime of a product.

Cheers

Tim…

PS. I’ve been making Jeff Smith‘s life miserable regarding the documentation. Thanks for the feedback and changes Jeff. 😉

VirtualBox 6.1.34

VirtualBox 6.1.34 has been released.

The downloads and changelog are in the usual places.

I’ve installed it on Windows 11 and macOS Big Sur hosts with no dramas. Some time in the next 24 hours I’ll upload updated versions of my Oracle Linux 7 and Oracle Linux 8 vagrant boxes.

This is going to get plenty of testing as I run all my Vagrant builds using the latest Oracle patches.

Cheers

Tim…

Operating Systems for Oracle Databases, Including Windows This Time… (Poll Results Discussed)

Last week I put out a post about operating systems used for running Oracle databases.

Operating Systems for Oracle Databases (Poll Results Discussed)

This was the first question from the previous post.

Which operating system are you using for your Oracle database servers?

Unfortunately I forgot to include Windows. A number of people contacted me about this, asking if I would ask the question again and include Windows this time, so I did. Also, this time I was explicit about production systems, because I suspect some people were answering about their home setup… 🙂

So here we go for the second time…

Which operating system are you using for the majority of your **production** Oracle Databases servers? Not demo kit on your PC at home. A repeat of last week, but remembering to include Windows this time…

We can see Linux is still the clear winner, with UNIX and Windows battling it out for the second place spot. Going back to my statement from the last post, there is no point in purposely making yourself a minority, which would clearly suggest Linux is the place to be. Windows is a slight exception to that, because if your company has no experience on Linux, but a good grounding in Windows administration, it might be a good idea for you to stick with Windows, rather than doing a bad job with Linux. I can’t imagine there are many places with good UNIX skills and no Linux skills, so I’m not going to give the same “get out of jail free card” for that. 🙂

So as I said before, Linux is dominating, so you can see why there is so few posts about Oracle on other platforms these days…

Cheers

Tim…

Operating Systems for Oracle Databases (Poll Results Discussed)

I put out some questions on Twitter a couple of days ago, asking about the operating systems people were using for their Oracle database servers.

As with all these polls, we have to discuss some caveats. Most of the people that follow me are from the Oracle community, so that puts a heavy bias on the outcome. The questions relate to Oracle databases, which also influences the results. Someone may choose one distribution to run Oracle workloads, and a different distribution to run non-Oracle workloads. We also have to remember the sample size is small. Despite this, I’m going to discuss the results as if this were a representative sample of people, even though I accept it may not be. 🙂

This was the first question I asked.

Which operating system are you using for your Oracle Databases servers?

You’ll notice I totally forgot to include Windows, which was a shame because it would have been nice to see that. My main focus was to see how many people were still holding on to the traditional UNIX systems. There was a really strong showing for Linux over UNIX, which was hardly surprising. Every year the dominance of Linux is increasing. A few years back a lot of big companies were still using the traditional UNIX systems, but I guess a lot of people have got sick of spending that sort of cash, and some have probably switched to buying Exadata kit instead. I cant say I’m surprised by this result.

Something I’ve said repeatedly over the years is you should stick to the operating system that is the most popular, as that is the one that is going to get tested the most. There is no point in purposely making yourself a minority IMHO. Having lived through the death of Oracle on Tru64 and HP-UX, I wouldn’t dream of using anything other than Linux now.

This was the next question.

For Linux users, which Linux distro are you using for your Oracle database servers?

Over 65% of the folks picked Oracle Linux, and about 27% picked RHEL. The fact this is a poll about Oracle database servers no doubt added to the skew in this result. Oracle have done a good job of promoting Oracle Linux, and the fact it is free probably helps a lot. I thought Oracle Linux would be the winner here, but I’m not sure I expected it to be by this much. Personally I wouldn’t run on anything other than Oracle Linux by choice. Remember, this is what Exadata uses, and this is what Oracle Cloud uses.

I suspect some of the people that picked “Other” were speaking about non-production systems. Perhaps I should have made it clear I was thinking about production, not test labs…

This was the final question.

For Enterprise Linux users, which version of Oracle Linux and/or RHEL are you using for your Oracle database servers?

It’s good to see that nobody is owning up to OL5/RHEL5. There are still a few things lingering on OL6/RHEL6, but I guess those are probably running old versions of the database.

OL7/RHEL7 is still the most common version, but I guess a lot of this is down to the long lifespan of database servers. I suspect many of these servers were provisioned some time ago. I’m hoping most new deployments are using OL8/RHEL8.

So nothing really that surprising about the outcome of this batch of questions. Pity I didn’t include Windows in the first question. Maybe next time…

Cheers

Tim…

The Oracle ACE Program : My 16 Year Anniversary

It’s April 1st, which means it’s my 16th year anniversary of being an Oracle ACE.

As usual I’ll mention some of the other anniversaries that will happen throughout this year.

  • 27 years working with Oracle technology in August. (August 1995)
  • 22 years doing my website in July. (Original name: 03 July 2000 or current name: 31 August 2001)
  • 17 years blogging in June. (15 June 2005)
  • 16 years on the Oracle ACE Program. (01 April 2006)
  • 7 years doing videos on my YouTube channel, with some breaks of course.
  • A combined 5 years as an Oracle Developer Champion, renamed to Oracle Groundbreaker Ambassador. (21 June 2017) This will be the last time I mention this, as the Groundbreaker Ambassador is now being merged back into the ACE program. It was fun while it lasted. 🙂

Fingers crossed for next year…

Cheers

Tim…

Death of the DBA… Again…

If you’ve followed the blog for a while you will know I’ve revisited this topic several times since I first wrote about it in 2007. Here are some links if you want to go down memory lane.

I think I’ve been pretty consistent with my opinion on this subject, but I still get people misunderstanding the argument, so I’m going to try again, without revisiting the contents of all those previous articles.

What is a DBA?

This means something different in each company and each person I speak to.

In some companies it can mean a basic operations job. Install, patch, check backups and run scripts that other people send to you. All of these tasks are easily automated on-prem, and essentially don’t exist on the cloud. If this is the role you do, and this is all you do, you are going to have a bad time unless you gain some new skills. In other companies it can mean something completely different. My official title is “Lead DBA”. What do I do? Just off the top of my head:

  • DBA work with Oracle, SQL Server, MySQL.
  • Administration of middle tier stuff like WebLogic, Tomcat, NGINX etc.
  • I look after the load balancer configuration for a big chunk of the back-end business systems, including writing iRules in TCL.
  • Support for a few proprietary 3rd party apps.
  • Docker/containers.
  • APEX and ORDS. I’m the worlds worst APEX developer (see here), but I have to look after it, and support the APEX developers.
  • I don’t do much traditional development in this company, but I provide support when people have SQL and PL/SQL questions, because I’ve done that for a minute. 🙂
  • I’m increasingly being drawn into automation using shell scripts, Ansible, Terraform, Liquibase etc.

I’ve already got rid of some of the operational aspects of my job. Over time I’m hoping more will go, but that mostly depends on external constraints holding me back. Even if my involvement with databases stopped completely, I can still remain busy. Am I saying my role is what a DBA should be? No. I think my position is a little more extreme than some. I’m saying DBA is a title that various people and companies use, but it doesn’t really mean anything now. It can be anything from basic operations to “Do Bloody Anything”.

When is it going to happen?

For some companies it already has. Some companies will hang on to the old ways until the bitter end. It won’t happen overnight, but if it is not happening already in your company, what you are likely to see is a gradual drop in operational tasks as they get automated. This allows either the same number of people to cover more systems, or less people to do all the current work.

If you are seeing pieces of your role disappearing, you have to do something else to add value!

But person X disagrees with you!

That’s fine. This is only my opinion and you don’t have to agree, but please check the context of what people are saying. Often the responses to my comments include mentions of performance tuning and diagnosing architectural issues. I have consistently said the “operations DBA” role would go. The job that focuses on the basic grunt work. There will be a continued need for people who can diagnose and solve performance problems, both in the databases and in the application architecture. Moving to the cloud won’t magically cure all performance issues, and some would say they will increase the number of issues. You can still deliver architecturally crap solutions on the cloud. You can still do bad database design and write bad applications. Good people will always find a home, provided they don’t stick rigidly to the past.

You also have to look at the person making the comments. If someone is a performance consultant to the stars, but identifies as a DBA, they are probably going to take these comments personally and hear me saying they are redundant, which I am not. If someone runs a DBA as a service company, they won’t like the sound of this and will go into defensive mode.

I’ve been a regular DBA for most of my working life, and I’ve watched the job evolve. You may have a different experience, and that is fine, but I speak to a lot of people, and I think my opinion on this subject tracks pretty well with what is happening out there.

You are really talking about the cloud aren’t you?

Not. Automation is the thing that is removing the need for the operational DBA and basic system admin roles. Even if your company is in cloud denial, it doesn’t mean they won’t want to take advantage of automation. The cloud makes some things easier from an automation perspective, because the cloud providers have done some of the leg-work for you, but automation existed long before the cloud…

What should I do?

When you know, please let me know so I can do it too. 🙂 Seriously though, keep your mind open to new opportunities, and if you get a chance to try something new, give it a go. Nothing is ever wasted. Some people will gravitate to the data and analytics side of things. Some to development. Some to the architectural end of things. In all cases, there is a lot to learn and the less you know when you start, the harder the journey will be, so get learning whatever you like the look of…

Cheers

Tim…

Update 1: In social media comments, some people have mentioned the term “Data Engineer”. To me a data engineer needs to understand data, and requires and understanding of the development process. I’ve met some operational DBAs that can barely string together a SQL statement. These types of operational DBAs have a lot to learn before they can consider themselves a data engineer. A DBA can become a data engineer, but being a DBA does not mean you are a data engineer.

Update 2: Don’t get distracted by the name DBA. I don’t care about the name of the role. I’m talking about the function the person is performing. If they are performing basic operational tasks, whatever they are called, they need to start getting some new skills.