In this article series, we are looking at the steps for setting up the Oracle Hybrid Cloud via the latest version - Enterprise Manager Cloud Control 13c installed on premises. The main intention is to install an Enterprise Manager hybrid cloud agent on our database cloud servers via the hybrid gateway, in the scenario where our company has databases running on-premise as well as on the Oracle public cloud.

In the previous parts of the article series, we completed the pre-setup steps for the hybrid cloud – such as setting up one of our on-premise Enterprise Manager Oracle Management Service (OMS) agents as the Hybrid Gateway agent, creating SSH keys for the OMS server, and creating a named credential with SSH key credentials for the hybrid cloud. At the same time, we also created an Oracle Database Service (a server with an Oracle database) on the Oracle public cloud.

Next, we completed the installation of the hybrid cloud agent via Oracle Enterprise Manager, which performed a background transfer of the agent software to the destination host. On the cloud server, we examined the contents of the “/etc/oragchomelist” file, found where the hybrid cloud agent has been installed; i.e., the agent home, and verified that the agent was running on the cloud server. Next, we logged into the on-premises Enterprise Manager console as SYSMAN or a super administrator and drilled down to the Cloud Host home page. On this page, we could see the Enterprise Manager configuration and performance metrics for the host; these metrics were uploaded by the hybrid cloud agent.

The host was obviously visible in Enterprise Manager after the hybrid agent had been installed, but the database was not, so it had to be discovered. First, we unlocked the “dbsnmp” user in the Oracle public cloud database and changed the user password. Then, under Targets | Databases, we selected Add | Oracle Database from the menu and specified the IP address of the Oracle public cloud database server.  The OPC database and listener were discovered, and the Monitor Username used was “dbsnmp”. After the discovery process completes, the cloud database appeared in the list of Enterprise Manager database targets.

We drilled down to the cloud database home page, which appears just like a normal database target in Enterprise Manager, except that the “Oracle Cloud” words and icon are visible at the top left of the page. You can monitor and manage it just like a normal on-premises database.

Next, we compared database configurations by selecting Enterprise | Configuration | Comparison and Drift Management from the Enterprise Manager console, and creating a comparison. We selected the on-premises 12c database “” as the Reference Target (Current). In the Compared Targets list, we selected and added the cloud database AHUTEST. In addition, we selected the “Database Instance Template” as the comparison template. A comparison template helps avoid alerting on obvious differences. The Advanced mode button also allows you to alternatively select a saved reference target.

When you clicked on Submit, the results of the configuration comparison job appeared in a short space of time, and the differences were displayed. Effectively, you have compared the configuration of a local on-premises database with that of a cloud database. This comparison can be done at the server level as well – i.e., between two database servers or two WebLogic servers.

For the licensing, the on-premises side needs the DBLM (Database Lifecycle Management) pack for database comparisons, and the WLS Management Pack EE for WebLogic Server comparisons. On the Oracle public cloud side, you need the appropriate packs as well to be included in the cloud database version you select, such as Enterprise Edition Extreme Performance. This applies to other capabilities such as compliance checks as well.

You can save a configuration at a certain date and time as a “Gold” configuration (for example, immediately after setting up a database server) and then run a configuration comparison of your current configuration to the gold configuration at regular intervals, to alert you if there are any differences.

You can also set up compliance standard enforcement for the hybrid cloud, so that you can apply your corporate compliance standards to all your enterprise databases, no matter where they are. When this is set up, Enterprise Manager is able to enforce the same compliance standards on the Oracle public cloud as well as on premises.

Cloning PDBs from On-Premise to Cloud

One of the main features of the hybrid cloud is that it is possible to easily move on-premises PDBs to an Oracle Cloud CDB. For example, you may be moving a PDB to the cloud so that some development work can be completed.

Before you start this test, please note a few things. There is a current restriction in the process that says that the patch set level of the PDB being cloned needs to be the same as the cloud CDB.

Suppose the 12c CDB “ahuprod” has been patched to the October 2015 Database PSU (Patch Set Update). This means all the PDBs in this CDB are also on this PSU.

The cloud database, on the other hand, may have a different patch set level depending on when you created it. Up to the first week of a particular month, all cloud databases when created may have an older PSU automatically applied. In the next few weeks of the month, all new cloud databases created may have the latest PSU automatically applied.

You can check this by going to your cloud service console, drilling down to your cloud database, and drilling down on “View Patch Information” in the Administration box on the screen. Figure 24 is displayed.

Figure 24: Patching your Cloud Database to the latest PSU

Using an example date – if on December 2015, if this screen tells you “No patches available”, it means the cloud database is on the latest October PSU, which should be fine. If it shows the October PSU on this screen, then it means the cloud database is on the earlier PSU, so you should apply the October PSU first on the database.

We will continue in the next part of this article series.