DbaaS, but on metal: Rac on Oracle Cloud Infrastructure

DbaaS, but on metal: Rac on Oracle Cloud Infrastructure

Let’s skip some networking stuff first and do some fun tests on this Cloud infrastructure.

One of the things which caught my attention is the RAC database as a service.

I will split this in two separate blog posts. This one will tell you about how to create a RAC database as a service and the next one will tell you about how it performs.

Let’s get started!


First step is of course log into your portal and make sure the networking is already installed too. If necessary, run through my first blogpost to set it up.

Think back about the “good old days” where it took some effort to create the infrastructure for a clustered database, set up the servers and all those fun things. Cool thing, the Oracle cloud does this for you. This is how.


In the DBaaS, they call it database systems and they control about them can be found here:

Just click the db systems link and in the next screen, at the left down select your own compartment and it’s easy as clicking on “launch db system”.

The “wizard”, basically it’s actually a one pager is very simple to use. The first part is some general database information.


The shape is interesting, you can choose different kinds of database shapes like:

So in this particular case we go for the RAC with local storage.

I chose only 4 cores as the first test will focus on storage tests, so not too much needed.

This is a test system, so I chose to use normal redundancy. I personally don’t think it’s an advanced choice, but it’s easy to find, so no big deal for me.


This is also very self-explanatory, easy to select what you want and give it a name. Make sure that for the client subnet, you select a public subnet.

DB information

Easy again and the choices of versions are these:

Cool that you also can select Maybe that’s something for later to play with.

So basically, that’s it folks, click on “Launch DB system” and it starts provisioning.

This will take around 90 minutes and then you have a fully operational rac database in the cloud.

This was not hard to do!

Sanity checks

A wise man and my teamlead (you can follow him on twitter on handle @geertdepaep) always taught me “Only trust what you see for yourself”. Thanks Geert for this advice.

So let’s verify if all went well. Sometimes I’m a bit stubborn, this is such a moment. I start verifying at the second node. Yes, I’m kind of a rebel 😉

First things first, do we really have a cluster?

This looks like a cluster to me. But do you see what I see? I see only one instance of my database. So let’s verify.

UPDATE2: (6-Oct-2017):

I was deploying a new db to do the failover/performance tests and I noticed that the DB is immediately a rac-db. I leave this post in place to show if it happens, what you can do, but for now the workaround is not necessary anymore.

Oops? Indeed, cluster doesn’t lie, I do have only one instance. Verify on node 1:

Ok … at least there is one. Let’s have a closer look.
The database is actually build as a single instance database:

So basically, that explains. I told Oracle that I was a bit surprised that it created only a single instance for me.

Anyhow, the cluster is a flex cluster:

And serverpools are configured:

but they’re both nicely in the Generic pool and nobody moved to “Free”. So this was a wrong track. Nice to know this *spoiler alert* appliance runs a flex cluster though.

In the meantime (yes they answer pretty quick! Thanks for that, it’s really helpful) Oracle answered with apologies that they have seen this behaviour and it will be fixed soon. In the meantime we can work around it using this link. Hang on …  dbcli? odacli? really? Is this running on an ODA?

Definitely yes! But oakd is not running. This explains also one of the questions I had. I was wondering on how to extend the diskgroups if they become full:

This looks also very ODA. So I think we can conclude the RAC on Oracle Cloud Infrastructure runs on a Database Appliance. This is not wrong, just a nice to know on how it behaves.

Anyhow! The workaround is basically creating a new database. I think it must be possible to reconfigure the one created to RAC as well, but I might want to play with that first.

If you’re used to the odacli, the move to dbcli will be small and will feel very familiar.

Sounds familiar, isn’t it? To get the id’s from the running home and database you can use following commands:

So I want a Odb4 then I do:

Until now I do not quite understand why -s Odb4 isn’t accepted, but I created a pretty default one then:

And this is definitely an ODA including derby repository and all 🙂 After a while it lists the database and you see that the db is ready to use:

So now we have RAC-db. One thing I find a little pity is, that this db is not displayed in the portal. Maybe it needs time to refresh, but ok time will tell.

UPDATE: (24-Sep-2017)

When I checked the portal, the database showed up as well. So it does reflect the changes. That’s great!

UPDATE2: (6-Oct-2017):

I was deploying a new db to do the failover/performance tests and I noticed that the DB is immediately a rac-db. I leave this post in place to show if it happens, what you can do, but for now the workaround is not necessary anymore.

So that’s it for now.

As always, questions, remarks? find me on twitter @vanpupi

Leave a Reply

Your email address will not be published. Required fields are marked *

2 + fourteen =

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: