Uncategorized

OCI Cloud Performance Management for On-Premises Databases – Part 1 – Management Agent Installation

The OCI Management Agent service collects data from services and sources for monitoring and management in Oracle Cloud Infrastructure. In this blog post series I will show you how you can monitor and manage an on-premises Oracle databases in OCI. The communication between an agent and OCI requires an Agent Install Key and is based on HTTPS. Service Plugins extend a Management Agent for example for Oracle database performance monitoring and management or log analytics.

This is a small blog post series

My Setup

  • An OCI Tenant in datacenter EU-FRANKFURT-1
  • An OCI compartment called datacenter-kestenholz
  • An on-premises Container Database called CDB114, running on Oracle Linux 7
  • Three on-premises Pluggable Databases
The goal is to manage the on-premises database in Oracle Cloud Infrastructure OCI. Output from the Trivadis TVD-Basenv(TM) framework which show the database up and running:

Prerequisites for Management Agent Installation

  • Oracle Linux 6 or higher
  • Red Hat Enterprise Linux 6 or higher
  • CentOS 6 or 7
  • SUSE Linux Enterprise Server 12 or 15
  • Windows Server 2012 R2, 2016 or 2019

There are other prerequisites on the target server like the correct Java version (e.g. version 11 does not work) and sudo permissions. For the complete list of prerequisites, see here:

https://docs.oracle.com/en-us/iaas/management-agents/doc/perform-prerequisites-deploying-management-agents.html#GUID-BC5862F0-3E68-4096-B18E-C4462BC76271

Setup for OCI Management Agent

It is recommended to handle the agents in a separate user group and with policies. This allows us to define the Management Agent management on an fine granular level.

Group AGENT_ADMINS

According the documentation, I have created an user group called AGENT_ADMINS.

Policy Datacenter_Kestenholz_Agent_Policy

A new policy is created that allows the admin group to interact with the management agents, handle keys etc.

Dynamic Group Management_Agent_Dynamic_Group

New added agents in the compartment belong automatically to this group. Replace the OCID with the OCID for your compartment.

Policy Datacenter_Kestenholz_Agent_Communication_Policy

A policy is required that allows the agents to communicate with the OCI endpoints. This policy is important, otherwise you run in an communication error (see below in section troubleshooting).

Install On-Premises Management Agent

Create Agent Install Key

Go to Management Agent Menu / Downloads and Keys, create a new Agent Install Key. Set the compartment and the time how long the key is valid. In this example, I need to replace the key after one month.

When click on Download Key to File, a textfile is created with the ManagementAgentInstallKey and all other (optional) parameters which can be used for install. You can use this file as responsefile template later.

Download the Software and Transfer it to the Target Server

I use the Agent for Linux and transferred it to the target on-premises server into a stage directory as OS user root.

Create a Local Response File

This is an example of a simple two-lines response file for agent installation in the same folder where the rpm is located, called input.rsp. The parameter managementAgentInstallKey is visible in the OCI web interface, the CredentialWalletPassword is your password for the wallet.

RPM Installation

As OS user root (or a user with sudo permissions) – install the rpm file. Here you can see that the minimum required Java version is not met.

After installing the jdk-8u281-linux-x64.rpm to update the server Java version, the installer runs fine.


2nd try – successful

Agent Configuration

Run the install script with the created response file as additional parameter. The agent will be started automatically.

A systemd service is created.

Verify the Management Agent in Oracle Cloud Infrastructure

Immediately after the setup, the Management Agent is visible with status Active in OCI and starts uploading data.

Agent details:

Troubleshooting

Management Agent logfiles are located in directory /opt/oracle/mgmt_agent/agent_inst/log.

Example error when the policy for agent communication is not set properly:

From My Oracle Support: OCI : Management Agent Status Reporting As “Not Available” Post Installation (Doc ID 2745566.1)

Summary Part 1

The Management Agent installation and integration is easy to setup when all prerequisites are met. For troubleshooting you have full access on the agent logs. See you for blog post 2, where I try to integrate the  on-premises Oracle databases into OCI.

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.

patch01

Precheck Result

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

patch02

 

 

 

 

 

 

 

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.

patch03

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

patch04

The patch progress is show in the dashboard.

patch05

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.

patch07

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.

patch06

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.

Summary

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.