Oracle is implementing a cloud first approach and hence the newest releases such as Oracle Database 18c first appear in the Oracle Database Cloud Service (ODBCS). But only in the Container DB architecture for this PaaS offering. However, that doesn’t mean that non-CDB databases can’t still be created and used in the ODBCS PaaS by simply creating new instances using the DBCA.

CDB vs. Non-CDB

Since Oracle Database 12c, Oracle has been pushing the container database architecture. Some important points regarding this:

This is Oracle’s strategic direction and while the traditional non-CDB architecture is possible but is officially “deprecated”.

The multitenant option is only required for CDBs with more than user-created PDB. The Oracle documentation quote on this is: “The multitenant architecture with one user-created pluggable database (single tenant) is available in all editions without the Multitenant Option” Source: https://docs.oracle.com/database/121/DBLIC/options.htm#DBLIC2166

There are very few limitations or technical restrictions with the multi-tenant option as of Oracle18c. The official documentation currently doesn’t list any.

Consequently it really makes the most sense to adopt the container database architecture now, even if you only ever intend on having a single PDB (single tenant). Plus of course, the traditional non-CDB architecture will officially be removed as an option in some release in the future.

However, that all being said, if for whatever reason (i.e. an application vendor requirement) you still must use the traditional non-CDB architecture, then it is still possible to do so with Oracle Database 18c in the Oracle Cloud using the Oracle Database Cloud Service (ODBCS) – this article will explain how for both the OCI and Database Classic Oracle Cloud environments.

An example of why people may want to do this is to get a jump start on validating and certifying their applications with Oracle 18c using the Oracle Cloud and ODBCS prior to the on-premises release becoming available.

The Cloud First Strategy

Oracle has adopted a cloud first strategy meaning that the newest databases releases are deployed to the Oracle Database Cloud Service (ODBCS) in both the Oracle Cloud Infrastructure (OCI) and Classic Oracle Cloud environments prior to downloadable releases for on-premises. As of the time of writing this, Oracle Database 18c is only available in the ODBCS (meaning PaaS) and is not downloadable. But that doesn’t mean that you can’t still test it both with and without the CDB architecture.

The catch is that when you deploy 18c ODBCS instances as PaaS, Oracle will automatically create the database as a container database. There are no options for non-CDB database creations through the cloud instance creation wizards. And for reference, Francisco Munoz Alvarez has documented how to create ODBCS instances step-by-step in the Database Classic Cloud in his blog: http://oraclenz.org/?p=4219

However, the ODBCS isn’t quite a true PaaS. Rather, I think it’s more like a pre-configured IaaS offering with a database installed. Which really means that once we get access to the underlying server, we can essentially do anything we want. This includes spinning up new instances for which we can choose the architecture to use.

Considerations

The first thing to consider is resources. If you want to add additional instances to the ODBCS then you’ll need to ensure that you provision a machine shape (virtual or bare metal) with enough resources beforehand. Or alternatively, shut-down the PaaS Oracle templated instance if you want to create your own.

The next thing to consider is supportability. But since Oracle generally licenses by the processing unit (CPU or oCPU) or machine shape in the cloud, this shouldn’t be an issue.

Hence, it appears that we can add additional databases as needed as long as we’re paying for the machine or “DB System”.

Creating a Non-CDB Instance in the Database Classic Cloud

The first thing to do is provision a ODBCS database in the Database Classic Cloud. There is no option to create a non-CDB database:

After creating, we can view some basic architectural properties:

Nothing surprising there. But of course it is a CDB with the one PDB called “PDB1”.

We can’t really “change” this instance to a non-CDB but we can stop it, optionally remove it, and re-create it as a non-CDB from our ODBCS machine (meaning logging into the machine and sudo to “oracle”) using a DBCA command as simple as:

In the first few steps of the above, I simply assign some parameter data into environment variables for command reusability, and then echo them to ensure they’re set correctly. Notice that for clarity (differentiation), I’ve changed the instance name from ORCL to TRAD.

The actual DBCA command doesn’t really differ from what we’ve used in previous versions. And of course the DBCA command arguments including initialization parameters can further be customized as needed. Finally, we could also use the DBCA to remove the Oracle PaaS created CDB instance if we wanted to.

Once the command runs, that’s it – the new non-CDB database is ready for use. Running the same architectural checks confirms it has been created as intended:

And that’s all we have to do. We now have an Oracle18c non-CDB database in the Oracle Cloud to test or certify our applications against. And it’s created in the ODBCS prior to the release of the downloadable on-premises version of Oracle18c.

Creating a Non-CDB Instance in the Oracle Cloud Infrastructure (OCI)

The process in the OCI is almost exactly the same. There are however some key (general) differences between ODBCS in OCI and Database Classic:

The Database Templates provided in the Oracle Homes are different. Rather than the regular “General Purpose” template that we’re used to, in the OCI there is only a single template called “seed_db”.

The Oracle home paths are slightly different: classic uses the full version “18.0.0” in the path where as OCI uses “18.1”. (Incidentally, there are numerous places with inconsistencies in the ODBCS as to whether the version is 18.1 or 18.0.)

After creating a database in OCI, there’s no obvious indication that it’s a CDB:

However, checking the database, it obviously is:

Not much difference than the “Classic” Database.

Hence, again the process is pretty simple: stop the pre-created CDB, optionally remove, create a new non-CDB instance. Only slight modifications to the required command, mostly path related:

Also, notice the change in template name required to manually create a database in the OCI.

Once run, the new, non-CDB instance looks as expected:

Conclusion

It’s important to remember that the non-CDB architecture is deprecated and certainly not promoted by Oracle. And it makes sense to switch to the CDB architecture as soon as possible as it will eventually be mandatory.

However, that day hasn’t come yet and hence if you really must continue to use the non-CDB architecture then you can still get a jump start with testing Oracle Database 18c using the Oracle Database Cloud Service (either Classic or OCI) before the on-premises downloadable version of Oracle Database 18c is available.

About the Author

Simon describes himself as a technology enthusiast who is passionate about collecting and sharing interesting database tips. If you want to see his eyes light up, let him teach you something new. Based out of Calgary, Alberta, Simon is known for his contributions to various online Oracle communities, and being very thorough in his work. A self-proclaimed stereotypical Canadian, Simon can be found watching hockey with his family in his spare time.

Working in a VMWare environment with one database/application/VM; I don’t see us ever needing multi-tenant databases. The complexity they add just doesn’t see worth it. Also, adding something else to our list of things not to do to avoid license incidents doesn’t seem wise. How much push-back is Oracle getting on this?

If you’re in a VMWare environment, then you’ll use the downloaded software when it’s released for on-premises. That will mean you can choose whichever type you want want creating your database. This article was really about doing the same specifically on the ODBCS.

PYTHIAN®, LOVE YOUR DATA®, and ADMINISCOPE® are trademarks and registered trademarks owned by Pythian in North America and certain other countries, and are valuable assets of our company. Other brands, product and company names on this website may be trademarks or registered trademarks of Pythian or of third parties. Use of trademarks without permission is strictly prohibited.