The OCI tool is easy to use. I had a very interesting conversation with Simon Haslam ( here on Twitter @simon_haslam ) about this. In this blogpost we will highlight the cause (and the solution) of this particular case and in a second part, there is a general workflow which did not let me down for my last deployments.

404 NotAuthorizedOrNotFound

Simon and his colleagues are working with ansible and Terraform for automatic provisioning of their full environment which at a certain point in time failed with a 404 error like this

Not very descriptive right? But actually this brings us deeper to how OCID’s are build up.

I take my sandbox environment as an example. We come back to the oci tool later in the post, but I will use it here to show some output. This command lists the databases in my compartment, but using jq, I take the first entry and show all the id’s which are present.

Important when dealing with databases, is that you use the Database id. Now you say, “There is no such thing as database ocid”. The answer is “oh yes there is”. The database is “id”.

There is logic behind it and in fact the id’s are really simple to recognise. When you take the ocid it looks like

so first we have

• ocid1 (never saw something else, but feel free to comment)
• This is what the ocid defines. A compartment, dbhome, dbsystem, database,… basically the component that has the id
• the region / availability domain
• the id itself.

This is a pretty clever system as based on this, you (we) could define all we need based on a single OCID. It looks complex, but once you understand how it works it is very simple.

Going into the console, it might lead to confusion when you want to copy paste for using the ocid in the oci tooling.

For example, when we go to my DB systems page:

When you pay close attention, you know that you are copying the DB-system OCID here, but I get why you might think that you copy the Database id. However, the database ocid is a little deeper down.
Click on the db system display name (or view details in the drop down menu)

When you then select “Databases” (down on the left) there you find the “Copy OCID” you are looking for when you need to specify the Database ID in an OCI command.

If you specify another OCID in a command that expects a database id, you might run into 404 NotAuthorizedOrNotFound error. Logical, as it is true! When you look for a database and tell the tool to look in a compartment or something else, it cannot find that resource, hence … Page Not found.

OCI cli

The OCI cli is a useful piece of software, which you can install on your laptop/terminal to manage your resources in your compartment. Digging into the installation of it would bring us a bit too far, but it is outlined here in the documentation.

The installation script will ask you some questions to setup your client for your environment by creating the configuration file. So pay attention to the ocid’s you enter in that setup flow.

So let’s look at the OCI tool itself.

oci works by oci and then specifying what you are interested in. To be honest, I like the tool. I am not a hero in memorising commands, so I type oci db and it gives me the list what I could do with a db.

First things first, I would like to have a Data Guard installation. So that starts with a primary database, right? Lets follow the flow to setup a basic data guard installation using oci.
In this post I assume that your tenant and compartment are setup correctly. Also that you have a vnc and subnet configured correctly according your needs and that you have specified correct routing and security lists. As that is OCI Configuration, we won’t cover that here.

Setup the primary database

First of all we need a primary database. I like to use scripts. So to avoid typing too much I used some environment variables

This clears up the commands a bit as they are pretty long, but that is ok for automation, isn’t it?

The command used for creating a VM based (entry level for oci) primary database would look like this for me

When you launch the command, it returns a json, which you could parse if you would want to.

After a while, the primary database is ready to use.
With this command you can find the database ocid:

Creating the standby

I have exported that Database id in the ${NEW_DB_ID} environment variable and then creating a Data Guard association, with a new db system is as simple as running one command:

This also return you a Json:

Then you need to wait a while again and upon completion of this process, your Data Guard installation is ready for use!

Verifying the Data Guard Association

The proof of the pudding is the eating. Not only in the browser you can see the Data Guard association

Also using the cli you can show the Data Guard association using following command

And yes! Correct, this also returns a json with the status

Conclusion

Of course the mandatory disclaimer, make sure you setup your backups and all the rest of the necessary good practices when you take this in production. This is just meant to show the bare necessities to make it working in the cloud. A lot more practical and good documentation for DBCS is available here. To use Oracle Data Guard with Exadata, see Using Oracle Data Guard with Exadata DB Systems.

The bottom line is, this works very well and I was also very pleased to see how easy it is to setup full installations. Also setting up a RAC to RAC Data Guard suddenly becomes a very easy task. I think this is useful to automate the setup process and when you want a small environment, perfect way to achieve this. For bigger installations, of course we advise to use ExaCS, but that story is for a future blog post.

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