Hybrid cloud management is an interestingly hot topic for today’s cloud world, since not all companies want to move everything to the cloud. In this article series, we are looking at the detailed steps for setting up the Oracle Hybrid Cloud via the latest version – Oracle Enterprise Manager Cloud Control 13c installed on premises.
Our main intention is to install an Enterprise Manager hybrid cloud agent on our database cloud servers (on the Oracle public cloud) 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 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 had been 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.
We compared Oracle 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” and the cloud database AHUTEST. Effectively, we 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. Oracle 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. To proceed with the actual PDB cloning, we made sure the source and destination CDBs were at the latest PSU. We then went through the steps to preserve the Enterprise Manager agent home when patching the cloud database. Next, we started the Clone to Oracle cloud process. This was done via right-clicking on the on-premises PDB “SALES”, which is in the ahuprod CDB, and selecting Oracle Database | Cloning | Clone to Oracle Cloud.
The name of the destination PDB on the cloud side was entered as “SALESTST”, since this will be a test pluggable database. We also selected a user name and password for the PDB administrator of the new PDB. Then, we could have clicked on “Clone” to quickly start the procedure, but instead we clicked on the “Advanced” button at the top of the page. This switched to advanced mode, and a multiple page workflow appeared on the same screen.
We clicked on Next. The “Clone to Oracle Cloud: Configuration” page appeared. As per cloud database standards, which 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 that are created with the PDB can also be specified – Logging, No Logging or Filesystem Like Logging.
After this, the Post Processing page appeared. Here we noted the importance of the Advanced mode, since it is possible on this page to select a Data Masking Definition if one has been created for the source database. Masking is seamlessly integrated with Enterprise Manager. This ensures that confidential data is masked when being cloned from an on-premises production database to a cloud development database.
A simple masking definition had already been created. This definition was named “LatestDataMaskDefinitionHR” (no spaces should be included in the definition name) and was 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.
In the Schedule screen that appeared next, we scheduled the job, then reviewed and clicked on Clone. The procedure started to execute. Among the steps in the procedure, we also observed a Secure Copy files step. Note that the “rsync” UNIX command was used by the procedure to fast-copy files to the cloud.
The clone to cloud completed successfully in under 16 minutes (depending on the PDB size and the Internet connectivity). When we moved to Targets | Databases, we saw the new SALES Test PDB under the cloud CDB AHUTEST, and then drilled down to the Sales Test PDB Home page.
If we selected the Masking definition as a part of the cloning workflow, we need to verify that the employees table data has been masked. We connected to the on-premises ahuprod cdb as sysdba, and selected from the hr.employees table to examine the original unmasked data. Then we checked the same rows in the cloud PDB. We observed that the employee data had been masked successfully, as per the masking definition that was selected during the clone to cloud procedure.
Another point to note is that if the APEX versions of the two databases (on-premises and cloud) do not tally, the plug-in of the PDB to the cloud database during the cloning process may not complete successfully. The PDB on the cloud database may be left open in restricted mode. This will be seen when you try to drill down to the new cloned PDB in Enterprise Manager, and it tries this for a few minutes and then reports that the PDB is in restricted mode.
The reason can be seen in the view PDB_PLUG_IN_VIOLATIONS on the cloud database; the Message column shows an “APEX mismatch” between the PDB installed version and CDB installed version.
We verified that the APEX versions are different via the commands “select version_no from apex_release;” and “select comp_name, status, schema from dba_registry where upper(comp_name) like '%EXPRESS%'”.
The solution for this issue was to download the APEX 5.0 version (not the 5.0.1 version) from http://www.oracle.com/technetwork/developer-tools/apex/downloads/index.html, and then to apply this APEX version on the on-premises database, before starting the cloning. The runtime APEX was installed by the single command: @apxrtins.sql SYSAUX SYSAUX TEMP /i/
After this was complete, the on-premises database had the correct APEX version. This was verified again via the commands “select version_no from apex_release;” and “select comp_name, status, schema from dba_registry where upper(comp_name) like '%EXPRESS%'”.
The cloning from the on-premises PDB to the cloud CDB then proceeded without any issues. However, if the cloud database had reported a new version of APEX higher than 5.0, then we would have needed to follow the procedure as outlined above while using the higher version of APEX and installing it on the ahuprod database.
Clone from Oracle Cloud
It is also possible to clone PDBs from the cloud back to on premises. For example, you complete your development on the cloud PDB, and then bring back the PDB to an on-premises CDB for testing purposes.
Select the Cloud PDB, right-click, and select Oracle Database | Cloning | Clone from Oracle Cloud. This procedure will bring the PDB back to the on-premises CDB. This brings up the Clone details page (Figure 37), where you can select the source PDB, and the destination CDB, which is on premises.
Figure 37: Source and Destination
You specify the credentials on either side, and click on Clone. The procedure will clone the PDB from the cloud back to an on-premises CDB.
This should complete successfully in the majority of cases, but at times, when a special cloud patch has been applied at the cloud database level by the Oracle Cloud team, that patch is not available to be rolled back by the Datapatch utility at the on-premises PDB level. This will result in the clone procedure’s failing at the “Apply Datapatch” stage.
In such a case, ignore the step and continue the procedure. The PDB will be cloned but opened in restricted mode. You will then have to resolve the patching issue manually.
We will continue in the next part of this article series.
Start the discussion at forums.toadworld.com