Impressions of the OEM13c app from Oracle Cloud marketplace

Intrigued by the announcement that Oracle Enterprise Manager 13 (OEM13c) is available as an ‘app’, I decided to give it a go and try this app out. Before going into more detail, I must note that even though it’s called an app, it doesn’t come close to the definition of an app as we know it: intended for mobile devices. Having said that, it seems a useful addition for playing around with OEM13c and the cloud, and maybe any further.

I followed this announcement blog for preparation and installing, and wrote down my findings.

Later on, I found out there’s an Oracle by Example, which may be even better to follow.

I’m using the free tier environment of Oracle Cloud. Be aware though, that the OEM13c app lands on a VM that’s too big for being part of the free environment. The costs are quite reasonable, however. In any case, for testing purposes. You can switch it off when you don’t need it for example. But to be sure, I created a budget after creation of the compartment. I’ll come back to this item later on.

Steps in this post:

  1. Preparation: creating compartment, budget (!), dynamic group, policies, VCN, Ingress rules
  2. Installing the app: generate public key, decide which VM to use, launch instance, follow and check installation
  3. Create an Autonomous Database in my free-tier environment (creation not part of this post)
  4. Connect to the GUI and check the usability of OEM13c with my Autonomous Database
  5. Reflections


I followed the blog about the preparation and decided to put the VM in a separate compartment ‘eminfra’ according to the post.

I created a budget for that compartment of $ 50 a month.

Created a dynamic group ‘OEM_Group’  with rules.

Created policy – cut and paste from the blog:

And an error occurred:

InvalidParameter – Failed to transform meta-verb to permissions. [// ALLOW any { dynamic_group OEM_Group } to ERROR in tenancy // From:create20160918, Index:0 // ACTION error: ‘metaverb-resource pair (manage instancefamily) unknown’@’MetaverbPermissionTransform’]

That’s right, there should be a dash in instance-family and volume-family 😊:

Created a Virtual Cloud Network in my EMINFRA compartment

Add Ingress Rules in your OEM_VCN (networking –> virtual cloud networks –> security lists ). Be aware that you choose the right compartment:

Installing the app

Again, I followed the installation-blog and chose the app from the marketplace.

Launch instance (I chose the 13.3 PG Release from August 2019)

Details of the version:

Now it’s time to generate a public key. You can use the ‘Puttygen’ software to generate a key, but don’t use the ‘save public key button’. Otherwise you will get the following error:

A good tutorial on how to generate a right key can be found here.

Summary: save the private key, use ‘Conversion’ to export the public key in an OpenSSH format, and make a .pub file with a text-editor.

Create the instance with this public key:


Choose the shape, network and storage:

Compute costs

2x $ 0.0638 per Hour = $ 0.1276

Roughly $ 92 a month compute power. For testing purposes a reasonable amount, especially when you switch it off when not needing

it. It’s another story when using a larger shape for production purposes.

Public ip-address

The following is quite important. You can assign a public IP address while creating. You will get a so-called ‘ephemeral’ IP address. It exists for the lifetime of the instance. This is alright for a test situation, but when you expect that this instance will be in production, you should create a ‘Reserved’ IP address and assign this to the instance.

In short:

For a testing situation, don’t forget to assign a public IP address while creating. You can add it later, but it’s simply more convenient to do it now. For an assumed production instance: don’t assign a public IP address. Assign a ‘Reserved’ public address to this instance later on.

And when creating you get a message that’s it’s done within a minute or two:

But… however the VM is created, the installation and configuration of OEM is still running on this newly created VM.

In the end, it took 20 minutes to complete before I was able to access OEM. That’s quite fast! And it’s easy to follow the progress during those 20 minutes of deployment.

The next step: connect to my VM instance with the ssh key created earlier

ssh -I rsa-key-20191101.ssh

Check the progress in /var/log/emgc_setup.log

$ sudo –s

root@emcc opc]# tail -f /var/log/emgc_setup.log

Finished execution of  /u01/app/em13c/emagent/agent_13.
.. success
Starting the Oracle Management Server

All the ports, home- and file information can to be found in /home/oracle/README.FIRST.

Everything took about 22 minutes to complete… Not bad at all.

Creating an Autonomous Database (ADB)

Not part of this blog, but I created a standard, free-tier Autonomous Database. Quite a straightforward process.

Connect to the GUI and to my free-tier ADB

Let’s see if it works:  https://<public-ip-address>:7803/em



One of my goals is to connect to an autonomous database. But an autonomous database doesn’t need to be monitored by OEM13c, does it? So why do I want this? Oracle documentation gives the following reasons:

Discover Autonomous Databases.

Monitor the health and performance of Autonomous Databases and perform deep diagnostics on the Performance

Perform database administration tasks such as storage management, and schema management tasks such as creating database objects.

This very documentation also states the following:


Although this topic provides information on the different types of Autonomous Databases, currently, Oracle Enterprise Manager only supports the Autonomous Transaction Processing – Dedicated database.

Most likely, this has something to do with the agent-architecture of OEM. The free-tier autonomous database (ADB) is actually a PDB, one of a number of PDBs on a server, and the agent on the server can’t cope with different Oracle Management Servers.

But an Autonomous Transaction Processing – Dedicated database is not part of my free-tier environment, so it stops here for me.

Looking at the users in the ADB: there should be a separate user addbsnmp next to the old dbsnmp. And there isn’t one in my own ADB.

My next goal is of course to manage database instances on-premises or on IaaS. For on-premises, there’s a blogpost for me to analyze and use if I want to try out a few things.

And… can I scale this thing easily? Not a topic for now, but I will check this out.

Some reflections

OEM13c app may not be an app, but it’s relatively easy to deploy a working OEM13c in Oracle Cloud with. It could be very helpful. It’s license free – when you have already licenses for an Oracle database – but it’s not part of the free-tier environment. So you’ll have to pay compute- and storage-power for example.

Be aware of the public IP address, and choose a ‘reserved’ one when you are going to use it for production purposes.

After the deployment, it’s not so different from an installation on-premises. You have to install patches, plugins, users, deploy agents, configure metrics and all the other stuff. And also migrating to this new OEM isn’t automated. Conclusion: it’s up to you now.

It does help to quickly get started. There’s just one thing I’m afraid of. Upscaling to more CPUs or more memory (another shape) will have consequences, and might break the installation or configuration, because of the way upscaling works in Oracle Cloud: detach boot volume, terminate instance, create instance with another shape, attach boot volume.

But this definitely something to investigate.



Announcement and install blog:

Oracle by Example :


Installing the app: .


Generate public key:



Network setup for managing on-premises targets: .




Exit mobile version