Oracle Hybrid Database Cloud using Enterprise Manager – Part VII

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-premises as well as on the Oracle public cloud, and then to look at hybrid cloud management using Enterprise Manager.

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-premises 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 database 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. 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 visible in Enterprise Manager after the hybrid agent had been installed; however, the database had to be discovered manually via Targets | Databases, Add | Oracle Database from the Enterprise Manager menu. After the discovery process completed, the cloud database appeared in the list of Enterprise Manager database targets. We noticed that the Home page of the database appeared 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 “ahuprod.sainath.com” as the Reference Target (Current). In the Compared Targets list, we selected and added the cloud database AHUTEST. On submitting, 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. 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 – in shor,t to find if there is any configuration drift.

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. This is perfect for the hybrid cloud.

Next, we looked into cloning PDBs from on premises to cloud. One of the main features of the hybrid cloud is that it is possible to easily move on-premise 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. As part of this process, we first checked the patch set level of the cloud database by going to the cloud service console, drilling down to the cloud database, and drilling down on “View Patch Information” in the Administration box on the screen. As an example date, if on December 2015, 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.

You can also check the current PSU by moving to the OPatch directory under the Oracle Home on the cloud server, and issuing the command “opatch lsinventory”. This will display the patches that have been applied on the Oracle Home.

Please be sure to read the next section “Preserving the Agent Home when patching the Cloud Database” before you start the patching process.

Note that if there are any patch conflicts and the patch application on the cloud database fails, you may need to “force apply” the patch, for the patching to complete successfully.

After you have completed the PSU patch application, you can proceed with the actual cloning, since the source and destination CDBs are now at the latest PSU.

Preserving the Agent Home when patching the Cloud Database:

If you have installed the Enterprise Manager agent under /u01/app/oracle (the Oracle base directory), and if you then use the cloud database patching menu to apply a later PSU to the database, then the agent home will be moved to /u01/app.ORG/oracle as part of the database patching process. You can either move the agent subdirectory back manually after the patching is completed, or use the following workaround before you start the patching process.

Log in to the cloud database server as the Qracle UNIX user, and create the file “/var/opt/oracle/patch/files_to_save.ora”. In this file, add the agent directory (full path) to preserve. Then, log in again to the cloud database server as the OPC UNIX user. Issue the following commands:

sudo –s
cd /var/opt/oracle/patch
vi dbpatchm.cfg

In this root-owned file, locate these lines:

# create /var/opt/oracle/patch/files_to_save.ora with full path of directory or
# files to preserve any special files you may have in your /u01/app directory.
# set this to yes, if you have files_to_save.ora

special_files="no"

Change the line special_files="no" tospecial_files="yes". Save the file.

We continue in the next part of this article series.