WORKAROUND: Unable to monitor Oracle XE 11gR2 with Oracle Enterprise Manager 13c

I have recently switched to using Oracle Enterprise Manager 13c (EM13c – 13.1), replacing my previous EM12c installation.  I elected to install a clean new environment instead of an upgrade, because my old install had been upgraded repeatedly going back to the initial release of EM12c and I wanted a fresh start.

I encountered only one difficult issue during the process. When I attempted to add one production Oracle XE 11gR2 database target, EM13c could not compute the target’s dynamic properties, leaving the target broken. Since you cannot submit jobs against a broken target, this prevented me from using EM13c to back up this database.  I had no comparable issues with XE as a target under EM12c.

The key metric errors that showed during this process included:
“Metric evaluation error start – Target {oracle_database.SID.domain.com} is broken: Dynamic Category property error,Get dynamic property error,No such metadata – No valid queryDescriptor or executionDescriptor found for target [oracle_database.SID.domain.com$30]”

and for the database system target:

“Metric evaluation error start – Received an exception when evaluating sev_eval_proc for:Target name = SID.domain.com_sys, metric_name = Response, metric_column = Status; Error msg = Target encountered metric erros; at least one member in in metric error”

I enabled debugging for the agent logs and attempted again to add the XE target.  Errors showing up in the logs included:

2016-01-15 12:10:05,905 [1806:4CE3192] DEBUG – Computing of dynamic property: [ComputeVC] is done (1 msec, error=true)

2016-01-15 12:10:06,452 [1806:F917F5F8] DEBUG – Computing of dynamic property: [GetDumpDestination] is done (0 msec, error=true)

2016-01-15 12:10:06,508 [1813:6EEEAC87] DEBUG – Computing of dynamic property: [DeduceAlertLogFile] is done (1 msec, error=true)

2016-01-15 12:11:18,779 [1830:CD3A325D] DEBUG – Error was added to oracle_database.SID.domain.com$23(0|MONITORED|false|true|<UF>): Invalid Input

2016-01-15 12:11:18,779 [1831:3657AE55] DEBUG – abandoning long op “CDProps:oracle_database.SID.domain.com:ComputeVC:GENERIC_TASK:Fri Jan 15 12:11:18 EST 2016”

2016-01-15 12:11:18,780 [1830:CD3A325D] DEBUG – Error during dynamic property ComputeVC calculation: critical=true, missingCatProps=[VersionCategory], missingProps=[VersionCategory] oracle.sysman.emSDK.agent.fetchlet.exception.FetchletException: Invalid Input

2016-01-15 12:35:38,038 INFO – Finished dynamic properties computation (total time 817 ms). Number of DP computed: 19. Number of DP with error: 3. Number of dynamic properties that were added: 132.

After reviewing the logs carefully (and posting this as a question in the MOS Oracle XE forum – https://community.oracle.com/thread/3892946) I eventually narrowed the issue down to a query that EM13c runs against DBA_REGISTRY_HISTORY in a target database when added. For database versions greater than 11.2 but less than 12.1.0.2, EM13c assumes that DBA_REGISTRY_HISTORY contains a BUNDLE_SERIES column.  This column does not exist in Oracle XE 11gR2, which reports a version string of 11.2.0.2.

This bug should eventually get a fix as EM13c gets patched, but in the meantime if you need to monitor an Oracle XE target with EM13c, the following workaround took care of the problem for me: create a new DBA_REGISTRY_HISTORY table containing a BUNDLE_SERIES column in your monitoring user’s schema in XE.  So, as user DBSNMP on XE, I ran:

SQL> create table dba_registry_history (ACTION_TIME TIMESTAMP(6), ACTION VARCHAR2(30), NAMESPACE VARCHAR2(30), VERSION VARCHAR2(30), ID NUMBER, BUNDLE_SERIES VARCHAR2(30), COMMENTS VARCHAR2(255));

Since one cannot patch XE, the real DBA_REGISTRY_HISTORY view has no rows and so you do not need to populate any data into this new table.

After adding the table, force a recalculation of dynamic properties by running the following against the EM13c management agent on the XE server:

$ emctl reload agent dynamicproperties SID.domain.com:oracle_database
Oracle Enterprise Manager Cloud Control 13c Release 1
Copyright (c) 1996, 2015 Oracle Corporation.  All rights reserved.
---------------------------------------------------------------
EMD recompute dynprops completed successfully

Once that completed successfully my XE target started to show the correct status in EM13c and I can submit jobs against the target.  All fixed.  I recommend deleting the DBSNMP.DBA_REGISTRY_HISTORY table once the bug gets fixed in OEM.

[EDIT 20160216: Oracle has documented this issue in MOS note EM13c: Database Target Status Shows “Dynamic Category property error” In 13c Cloud Control (Doc ID 2105001.1) and in bug 22592461 DATABASE TARGET STATUS SHOWS “DYNAMIC CATEGORY PROPERTY ERROR” IN 13C CONSOLE. Users on supported databases (e.g., not Oracle XE) should follow the resolution steps in that document instead to correct the real error.]

4 thoughts on “WORKAROUND: Unable to monitor Oracle XE 11gR2 with Oracle Enterprise Manager 13c

  1. Jacob Mossin Andersen

    Are you sure that we are allowed to monitor an XE database from OEM 13.3 under the licence terms?
    https://docs.oracle.com/en/enterprise-manager/cloud-control/enterprise-manager-cloud-control/13.3.1/oemli/enterprise-manager-base-functionality.html#GUID-534AFAC0-3F0E-47D7-A538-C9A5CBC90299
    ‘The base installation of Enterprise Manager Cloud Control 13c includes several features free of charge with the purchase of any Oracle software license or Support contract.’

    To my knowledge you cannot purchase an Oracle software license or Support contract for XE so I don’t think we are allowed to monitor XE via the OEM 13.3 basic monitoring (although it would be nice).

    Reply
    1. Brian Pardy Post author

      Hi Jacob,

      Since I do not work for Oracle and I am not a lawyer, the best I can really say is “that’s a great question” and that I do not know the true answer.

      I am very confident that it would be a license violation if an OEM admin enabled any of the OEM management packs against an Oracle XE database, as they are specific extra-cost options.

      My understanding is the licensing documentation falls under the same “this is not part of your contract” exclusion as most other non-signed documents from Oracle, so I am not sure we can rely on the wording in the licensing manual other than as advice of what is strictly not permitted, but I might say that “free of charge with the purchase of any Oracle software license or Support contract” could be interpreted to mean that by purchasing a license or support contract for ANY other, non-XE databases, would be enough to permit usage of OEM base functionality for your XE databases. I know that without a support contract you don’t get access to any of the patches/etc required to maintain OEM, so I would not feel comfortable installing OEM solely to monitor XE databases (both because of having no demonstrable license, and because of running unpatched software).

      I can say that I once passed an audit from Oracle’s compliance team that looked at my OEM environment so they saw that I had both the licensed SE-1 DB and a single XE DB in my OEM system. That certainly doesn’t mean that is an approved configuration, but it means at least they did not immediately flag it and demand any payment.

      I can also say that I have seen posts on the public-facing Oracle forums going back to 2005 asking about OEM and XE and I haven’t seen any comments from employees or moderators that this was a forbidden use or topic.

      Unfortunately as with all things Oracle licensing, nobody but lawyers you pay will be willing to stand behind an opinion on just about anything. Since Oracle doesn’t offer any added-cost monitoring tools for XE, I don’t think monitoring XE with OEM deprives Oracle of any revenue.

      Really a great question.

      (Oh, and for the record to any Oracle Corp crew reading this… my XE database is now retired and I am no longer monitoring any XE databases with OEM. I did this because the application running on that DB dropped support for Oracle, not due to any licensing concern.)

      Reply

Leave a reply to Brian Pardy Cancel reply