Patching a DBaaS Database in the Oracle Cloud

To apply a Patch on a Database which is hosted by Oracle is done with one mouse click. This service is available only if you have selected the full database service during the DBaaS order process.

To the manual: https://docs.oracle.com/cloud/latest/dbcs_dbaas/CSDBI/GUID-50BDEF7D-A30E-4B32-BAE7-486538413E2D.htm#CSDBI3422

Patchset Availability

As soon as a new Oracle patchset is available, you can see that in the database management dashboard of the selected database. The precheck function verifies if the selected database is ready to patch.


Precheck Result

After 2 until 3 minutes and a refresh of the page you see the result.









Command Line Interface dbpatchm

If you have no web access, all these steps can be executed manually in the shell. Therefore a command line tool called dbpatchm is available. You have to login as user root before using this tool.

List of available commands:

To the dbpatchm Documentation: https://docs.oracle.com/cloud/latest/dbcs_dbaas/CSDBI/GUID-50BDEF7D-A30E-4B32-BAE7-486538413E2D.htm#CSDBI3422

Patch Apply

If the prerequisite check is successful, we can apply the patch by selecting Patch.


If there are any Java Cloud Services (Weblogic Servers) which are using the selected database too, you can force to apply the patchset.


The patch progress is show in the dashboard.


In the background, Oracle transfers a new Oracle image where the selected PSU is already applied, extract it and changes the /u01/app location afterwards. During the patch apply process, the image is located under /u01/donwload:

Patch installed

After 45 minutes, the database is patched and up and running again.


The verification with OPatch shows the correct patch numbers. Here is an extract from the OPatch output. You can see that the apply-date is the 14th of July and that Oracle has installed bundle patch with patches for the RDBMS and the OJVM. I remember, in the background Oracle extracts a fully patched ORACLE_BASE / ORACLE_HOME directory for later usage.

The data dictionary is up to date too – the query on dba_registry_patch shows the correct PSU number:

Patching kills the EM12c Agent

Oracle is creating a new directory for the software, the old stuff which was in directory /u01/app is copied in /u01/app.ORG. So the EM12c Agent is not available anymore.


You have two possibilities to get the EM12c agent back:

  • Copy the installation directories from /u01/app.ORG back into /u01/app and re-attach the Agent Home in the inventory
  • Clean up the agent in EM12c and execute a reinstall

To avoid future problems, you can attach a new disk and use them for the agent or for other tools.


Patching a DBaaS database in the Oracle Cloud is very easy. All important steps are done automatically. In the background Oracle creates a new ORACLE_BASE directory in /u01. But you have to take care about installing your own tools or for example an EM12c agent. Also the database logs are no more available in the base directory. But you can find the in an subfolder of the direcory /u01/app.ORG where the old stuff is located.

Oracle Enterprise Manager 12cR5 – Clone a PDB to the Oracle Cloud

Cloning an on-premise PDB to the Oracle Cloud is basically done in three steps. 1. Select your PDB – 2. Start Clone Menu – 3. Verify new PDB. In the basic clone menu, Oracle uses some default settings in the background, for example the source datafiles will be packed in a compressed file which is located in /tmp directory of the source server. When your /tmp directory is too small, the clone process fails. Why this directory is used? I don’t know. But it could be a problem when you clone bigger databases. Maybe we can edit the clone procedure, but this is a task for me for a day when it’s raining outside… All cloning steps are well monitored, in case of an error you see a detailed error message so you can go on from the step where the error occurred.

To clone a PDB, there are some prerequisites which has to be fulfilled like same characterset, endianess and options. Don’t worry, if your source database has a wrong characterset, the clone procedure will be stopped.

The source PDB

My source PDB is a small database called CRM02 located in a Trivadis Datacenter – the container database is called TVD12CDB. I want to clone the local PDB to the Cloud database TVDHIPER.


Start the Clone Procedure

In the menu Oracle DatabaseCloning select “Clone to Oracle Cloud”.


Source and Destination Information

Enter the source and destination information like credentials, passwords etc. As destination Database Host Credentials select the SSH credential.This credebtial will be used to copy the files to the new server. In the right top corner you have the buttons Advanced and Clone. Clone starts the process with default settings immediately, if you select Advanced you can set destination directory, scheduler the execution etc. I select Clone.


The Process starts immediately

This is the main menu where all the steps are monitored. You see all the details which are executed in the background. It’s an excellent overview.


I one of the firsts steps, Oracle creates the PDB XML manifest and puts all datafiles in a compressed tar.gz file. As I said in one the first lines in this blog post, the directory is /tmp…

The tar.gz file will be transferred to the new target and after the transfer it’s deleted. But you have to clean up the datafiles manually.

What happens on Target Server

The tar.file will be extracted in a new folder and then the database will be plugged in. Here is the tar.gz file on target server. After the successful plug-in, the files will be deleted at this location. Oracle uses OMF – Oracle Managed Files, the extracted files are then located in this directory structure.

If the plug-in action fails, you can see that immediately in EM12c. During my clone process, an error occured when Oracle wants to apply a patch to the new PDB.


In this case, the plugged in PDB has a wrong state. Oracle was not able to apply the datapatch because the pluggable database was not in UPGRADE state.


As workaround I logged in as SYSDBA into the target database in the Oracle cloud and changed the mode manually.

Then I restarted the procedure from the position where the error occurred.


Welcome to the cloned PDB

After some minutes, all steps are done, no errors. the pluggable database is now cloned and up and running. The task has status succeeded.


EM12c Integration

EM12c target discovery is not required, the new pluggable database CRM02_CL will be added automatically as new target.



First I wanted to try to clone a PDB from cloud database to cloud database, but this is not implemented at the moment. So I tried out to clone an on-premise database to the cloud. I have tested the basic functionality with a small database and it works fine. There are some issues like why does Oracle write files to /tmp or why has the plugged-in PDB the wrong state to apply the patches. But in general when you fulfill all the prerequisites to clone a PDB like character set etc. as you have to to on conventional way too, it runs. One of my next tests will be how it works when the source PDB version is not, when it’s a PDB. But I assume it works as designed, there will be a message in PDB_PLUG_IN_VIOLATIONS view and the I have to solve it manually. Or do you think Oracle will upgrade my PDB automatically? We will see… 🙂

Oracle Enterprise Manager 12cR5 – Let’s connect to the Oracle Cloud

Since EM12c Release 5 Oracle has integrated the connection to the Oracle cloud, databases can be monitored and handled very easy, on-premise databases and cloud databases are now managed in one tool. Adding a cloud database to an on-premise EM12c from cloud.oracle.com is very easy and done in a few steps:

  • Create a SSH key
  • Create a DBaaS instance on cloud.oracle.com
  • Configure a local Linux agent as Hybrid Cloud Gateway Agent
  • Create an EM12c credential for SSH login
  • Install EM12c Agent via push method on the DBaaS machine
  • Discover and add the new targets
  • Enjoy

A few documents are available how this setup has to be done. But the best way to get some experience is just to do it. We do not start from scratch with the EM12c integration, I have already created a new DbaaS instance which is up and running:


Configure a local Linux Agent as Hybrid Cloud Gateway Agent

A local agent has to be configured to communicate to the Oracle cloud as gateway. This has to be an existing Agent. I have decided to use the local OMS agent as Hybrid Cloud Gateway agent. The concept behind the Hybrid Cloud Gateway and the configuration is well described here, also how to configure it high available, the used ports etc.


Create an EM12c Credential for SSH Login

The credential contains an username and the private ssh key for the passwordless connection to the new host of the DBaaS. The scope is global, so all new cloud connections can use it. You can create the credential in menu Setup – Security – Named Credential. A test run is not possible because there were no other cloud targets configured at the moment.


Install EM12c Agent via Push Method on the DBaaS Machine

The installation of the agent is simple, it’s almost like local installations. The only two changes are a) to use the SSH credential and b) to choose the Hybrid Cloud Gateway Agent.

Setup – Add Target – Add Targets Manually – Add Host Targets – Add Host …

Information: During tests I ran into errors when I wanted to resolve the cloud hostname via /etc/hosts file. I was able to install the agent, but not to configure the databases. So I used the IP address here instead of the hostname, this works fine.


Select Named Credential and activate Checkbox to enable the Hybrid Cloud Gateway Agent. This port will be set automatically.


Deploy the agent and run root.sh on cloud host.


In the agent details via Setup – Manage Cloud Control – Agents you can verify if it’s a cloud agent or not.


Discover and add new Targets

After the successful agent installation, the cloud database can be added. Target – Databases – Add Enter Hostname – Next.


The fresh added database is available after a few minutes. The look and feel is as usual, only the small cloud icon on top shows you that the database is hosted at Oracle.



The integration of a cloud database into a on-premise EM12c is well done by Oracle. This is only the beginning, in the next days I will test more features like cloning a on-premise pluggable database to the cloud, set up a cloud database in the EM12c Self Service Portal and many more. It’s important to verify what it’s possible – and what’s not. Have fun with in the cloud!


  • https://cloud.oracle.com/database
  • http://docs.oracle.com/cloud/latest/dbcs_dbaas/index.html
  • http://docs.oracle.com/cd/E24628_01/doc.121/e24473/hybrid-cloud.htm#EMADM15141