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, 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 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. And after the database discovery process was completed, the cloud database appeared in the list of Enterprise Manager database targets, and it can now be monitored and managed 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 appear in a short space of time, and the differences are 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, and configurations at a certain date and time can be saved as a “Gold” configuration to compare to current configurations at regular intervals, to detect configuration drift. Enterprise Manager is also able to enforce the same compliance standards on the Oracle public cloud as well as on premises, which is perfect for a hybrid database setup.
Next, we looked into the cloning of PDBs from on premises to cloud, one of the main features of the hybrid cloud. As part of this process, we checked the patch set level of the cloud database by going to the cloud service console or 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. 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 in order for the patching to complete successfully. After you have completed the PSU patch application, you can proceed with the actual PDB cloning, since the source and destination CDBs are now at the latest PSU.
We next went through the steps to preserve the agent home when patching the cloud database. Next, we started the Clone to Oracle Cloud process. Logged in as SYSMAN or a super administrator on the Enterprise Manager console, we could see both on-premises databases (ahuprod) and cloud databases (AHUTEST) in a single pane of glass, in Targets | Databases. We right-clicked on the on-premises PDB “SALES”, which is in the ahuprod CDB, and selected Oracle Database | Cloning | Clone to Oracle Cloud. The Source and Destination screen appeared, and we filled in the Credentials for the on-premises side, as well as the Cloud side. For the Cloud “Database Host credential”, we used the “NC_OPC_DBCS” credential which has been pre-created with the local (OMS) server private and public keys. For the cloud database “SYSDBA Container Database credential”, we created a new named credential using the sys password that was specified when creating the cloud database.
The name of the destination PDB on the cloud side was entered as “SALESTST”, since this will be a test pluggable database. We also select a user name and password for the PDB administrator of the new PDB.
At this point, you can click on “Clone” to start the procedure. Instead of that, click on the “Advanced” button at the top of the page. This switches to Advanced mode, and a multiple page workflow appears (Figure 27).
Figure 27: Advanced Mode
Click on Next. The “Clone to Oracle Cloud: Configuration” page appears (Figure 28).
Figure 28: Clone to Oracle Cloud: Configuration
As per cloud database standards that are based on Oracle Flexible Architecture (OFA) standards, the PDB data files will reside on /u02, in the /u02/app/oracle/oradata/<PDB name> directory. You can also enter storage limits if you wish, such as the maximum PDB size or the maximum shared TEMP tablespace size. The default logging attribute for tablespaces creating with the PDB can also be specified – Logging, No Logging or Filesystem Like Logging.
Click on Next. The Post Processing page appears (Figure 29).
Figure 29: Clone to Oracle Cloud: Post Processing
This page shows the importance of the Advanced mode, since it is possible to select a Data Masking Definition if it has been created for the source database.
Masking is seamlessly integrated with Enterprise Manager. This makes sure that confidential data is masked when being cloned from an on-premises production database to a cloud development database.
A simple masking definition has been created. This definition has been named “LatestDataMaskDefinitionHR” (no spaces should be included in the definition name) and can be selected at this point. This will mask some of the confidential columns in the Employees table, in the destination Cloud PDB that will be created.
We continue in the next part of this article series.