Monday Mar 17, 2014

Installing a JDBC patch to an EM agent

If you have an Enterprise Manager 12c Release 3 or older agent monitoring database targets, Support may recommend that you install a JDBC (Java database connectivity) patch, such as patch 17591700, to prevent high CPU consumption by the agent.

JDBC patches, including 17591700, have readme files containing instructions for installing the patches to a database, not to an EM agent. This post provides an example of how to install a JDBC patch to an EM agent. It walks through the steps of installing patch 17591700 to an EM12c Release3 agent.

Here are the steps:

1.  Identify the version of the JDBC client in the Agent Binaries home.

  • Set the ORACLE_HOME environment variable to the Agent Binaries home.

$ setenv ORACLE_HOME /u01/em12/core/

Note: One way to find out the Agent Binaries home is to look in file /etc/oragchomelist on the agent host. It should contain an entry for an agent install in the format of:

<Agent Binaries home>:<Agent home>

For example, file /etc/oragchomelist contains:


  • Run the following command to identify the version of the JDBC client.

$ $ORACLE_HOME/OPatch/opatch lsinv -details | grep 'Oracle JDBC/OCI Instant Client'
Oracle JDBC/OCI Instant Client 

In this case, the version of the JDBC client is

2.  Download the patch from MOS (My Oracle Support) website. The version of the JDBC client should match the version of the database for which the patch is intended. Stage the patch zip file,, on the agent host. I stage the patch in directory /u01/stage/jdbc_patch. I will refer to this location as the patch stage directory.

3.  Go to the patch stage directory and extract files from the zip file.

$ cd /u01/stage/jdbc_patch

$ unzip


creating: 17591700/

inflating: 17591700/README.txt

creating: 17591700/files/

creating: 17591700/files/jdbc/

creating: 17591700/files/jdbc/lib/

inflating: 17591700/etc/xml/GenericActions.xml

inflating: 17591700/etc/xml/ShiphomeDirectoryStructure.xml

4.  Stop the agent.

$ /u01/em12/agent_inst/bin/emctl stop agent

Oracle Enterprise Manager Cloud Control 12c Release 3

Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved.

Stopping agent ..... stopped.

5.  Install the patch.

  • Go to the <patch stage directory>/<patch number>.

$ cd /u01/stage/jdbc_patch/17591700

  • Run opatch apply command.

$ $ORACLE_HOME/OPatch/opatch apply

Oracle Interim Patch Installer version

Copyright (c) 2013, Oracle Corporation. All rights reserved.

Oracle Home : /u01/em12/core/

Central Inventory : /u01/app/oraInventory

from : /u01/em12/core/

OPatch version :

OUI version :

Log file location : /u01/em12/core/

Applying interim patch '17591700' to OH '/u01/em12/core/'

Verifying environment and performing prerequisite checks...

Patch 17591700: Optional component(s) missing : [ oracle.dbjava.jdbc, ]

Interim patch 17591700 is a superset of the patch(es) [ 16087066 ] in the Oracle Home

OPatch will roll back the subset patches and apply the given patch.

All checks passed.

Backing up files...

Rolling back interim patch '16087066' from OH '/u01/em12/core/'

Patching component oracle.dbjava.ic,

Updating jar file "/u01/em12/core/" with "/u01/em12/core/$EventType.class"

Updating jar file "/u01/em12/core/" with "/u01/em12/core/"

Updating jar file "/u01/em12/core/" with "/u01/em12/core/$AdditionalEventType.class"

Updating jar file "/u01/em12/core/" with "/u01/em12/core/$EventType.class"

Updating jar file "/u01/em12/core/" with "/u01/em12/core/"

Updating jar file "/u01/em12/core/" with "/u01/em12/core/"

Updating jar file "/u01/em12/core/" with "/u01/em12/core/"

Updating jar file "/u01/em12/core/" with "/u01/em12/core/"

Updating jar file "/u01/em12/core/" with "/u01/em12/core/"

Updating jar file "/u01/em12/core/" with "/u01/em12/core/"

Updating jar file "/u01/em12/core/" with "/u01/em12/core/"

Updating jar file "/u01/em12/core/" with "/u01/em12/core/$EventType.class"

Updating jar file "/u01/em12/core/" with "/u01/em12/core/"

Updating jar file "/u01/em12/core/" with "/u01/em12/core/$AdditionalEventType.class"

Updating jar file "/u01/em12/core/" with "/u01/em12/core/$EventType.class"

Updating jar file "/u01/em12/core/" with "/u01/em12/core/"

Updating jar file "/u01/em12/core/" with "/u01/em12/core/"

Updating jar file "/u01/em12/core/" with "/u01/em12/core/"

Updating jar file "/u01/em12/core/" with "/u01/em12/core/"

Updating jar file "/u01/em12/core/" with "/u01/em12/core/"

Updating jar file "/u01/em12/core/" with "/u01/em12/core/"

Updating jar file "/u01/em12/core/" with "/u01/em12/core/"

RollbackSession removing interim patch '16087066' from inventory

OPatch back to application of the patch '17591700' after auto-rollback.

Patching component oracle.dbjava.ic,

Verifying the update...

Patch 17591700 successfully applied

Log file location: /u01/em12/core/

OPatch succeeded

6. Start the agent.

$ /u01/em12/agent_inst/bin/emctl start agent

Oracle Enterprise Manager Cloud Control 12c Release 3

Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved.

Starting agent ............. started.

The above step completes the process of installing patch 17591700 to the agent.

Tuesday Jan 07, 2014

Create a Database Instance without DB Control Schema

When using Database Configuration Assistant (DBCA) to create a database instance to house the repository of Enterprise Manager Cloud Control, people often end up with an instance containing DB Control schema, and they have to remove the schema from the instance before installing EM12c. To create an instance without DB Control or SYSMAN schema in the first place, make the following selections in the DBCA database creation process.

1. In the Database Template step, select the Custom Database option.

2. In the Management Options step, uncheck the Configure Enterprise Manager option.

Note: If DBCA locates an agent installation on the host, it will provide an option to register the database instance that you are creating with the corresponding Management Service. If you choose that option, DBCA will add the database instance to the Enterprise Manager site as a managed target upon completion of instance creation. This option, however, does not create SYSMAN schema in the database instance.

3. In the Database Content step, uncheck the Enterprise Manager Repository option.

Remember to make the above-mentioned selections, and you will have an instance without DB Control, which is fit for housing an EM repository.

Note: From EM12c Release 2, there is an option to create an database instance with a pre-configured EM repository. For instructions see:

Creating a Database Instance with Preconfigured Repository Using Database Templates

Installing Oracle Database and Creating a Database

Friday Feb 01, 2013

Network Ports Used in Oracle Enterprise Manager 12c

When planning and configuring your Oracle Enterprise Manager 12c implementation, you will have many infrastructure considerations. One of the most often discussed pieces is the network ports that are used and how to configure load balancers, firewalls and ACLs for communication.

This blog post will help identify the typical default port and range for each component, how to identify it and how to modify the port usage.

[Read More]

Tuesday Oct 09, 2012

Oracle Enterprise Manager Ops Center : Using Operational Profiles to Install Packages and other Content

Oracle Enterprise Manager Ops Center provides numerous ways to deploy content, such as through OS Update Profiles, or as part of an OS Provisioning plan or combinations of those and other "Install Software" capabilities of Deployment Plans.  This short "how-to" blog will highlight an alternative way to deploy content using Operational Profiles.

Usually we think of Operational Profiles as a way to execute a simple "one-time" script to perform a basic system administration function, which can optionally be based on user input; however, Operational Profiles can be much more powerful than that.  There is often more to performing an action than merely running a script -- sometimes configuration files, packages, binaries, and other scripts, etc. are needed to perform the action, and sometimes the user would like to leave such content on the system for later use.

For shell scripts and other content written to be generic enough to work on any flavor of UNIX, converting the same scripts and configuration files into Solaris 10 SVR4 package, Solaris 11 IPS package, and/or a Linux RPM's might be seen as three times the work, for little appreciable gain.   That is where using an Operational Profile to deploy simple scripts and other generic content can be very helpful.  The approach is so powerful, that pretty much any kind of content can be deployed using an Operational Profile, provided the files involved are not overly large, and it is not necessary to convert the content into UNIX variant-specific formats.

The basic formula for deploying content with an Operational Profile is as follows:

  • Begin with a traditional script header, which is a UNIX shell script that will be responsible for decoding and extracting content, copying files into the right places, and executing any other scripts and commands needed to install and configure that content.
  • Include steps to make the script platform-aware, to do the right thing for a given UNIX variant, or a "sorry" message if the operator has somehow tried to run the Operational Profile on a system where the script is not designed to run.  Ops Center can constrain execution by target type, so such checks at this level are an added safeguard, but also useful with the generic target type of "Operating System" where the admin wants the script to "do the right thing," whatever the UNIX variant.
  • Include helpful output to show script progress, and any other informational messages that can help the admin determine what has gone wrong in the case of a problem in script execution.  Such messages will be shown in the job execution log.
  • Include necessary "clean up" steps for normal and error exit conditions
  • Set non-zero exit codes when appropriate -- a non-zero exit code will cause an Operational Profile job to be marked failed, which is the admin's cue to look into the job details for diagnostic messages in the output from the script.

That first bullet deserves some explanation.  If Operational Profiles are usually simple "one-time" scripts and binary content is not allowed, then how does the actual content, packages, binaries, and other scripts get delivered along with the script?  More specifically, how does one include such content without needing to first create some kind of traditional package?   All that is required is to simply encode the content and append it to the end of the Operational Profile.  The header portion of the Operational Profile will need to contain the commands to decode the embedded content that has been appended to the bottom of the script.  The header code can do whatever else is needed, and finally clean up any intermediate files that were created during the decoding and extraction of the content.

One way to encode binary and other content for inclusion in a script is to use the "uuencode" utility to convert the content into simple base64 ASCII text -- a form that is suitable to be appended to an Operational Profile.   The behavior of the "uudecode" utility is such that it will skip over any parts of the input that do not fit the uuencoded "begin" and "end" clauses.  For that reason, your header script will be skipped over, and uudecode will find your embedded content, that you will uuencode and paste at the end of the Operational Profile.  You can have as many "begin" / "end" clauses as you need -- just separate each embedded file by an empty line between "begin" and "end" clauses.

Example:  Install SUNWsneep and set the system serial number

Script: ( <- right-click / save to download)



# Required variables:
OC_SERIAL="$OC_SERIAL" # The user-supplied serial number for the asset

Above is a good practice, showing right up front what kind of input the Operational Profile will require.   The right-hand side where $OC_SERIAL appears in this example will be filled in by Ops Center based on the user input at deployment time.

The script goes on to restrict the use of the program to the intended OS type (Solaris 10 or older, in this example, but other content might be suitable for Solaris 11, or Linux -- it depends on the content and the script that will handle it).

A temporary working directory is created, and then we have the command that decodes the embedded content from "self" which in scripting terms is $0 (a variable that expands to the name of the currently executing script):

# Pass myself through uudecode, which will extract content to the current dir
uudecode $0

At that point, whatever content was appended in uuencoded form at the end of the script has been written out to the current directory.  In this example that yields a file,, which the rest of the script proceeds to unzip, and pkgadd, followed by running "/opt/SUNWsneep/bin/sneep -s $OC_SERIAL" which is the command that stores the system serial for future use by other programs such as Explorer.   Don't get hung up on the example having used a pkgadd command.  The content started as a zip file and it could have been a tar.gz, or any other file.  This approach simply decodes the file.  The header portion of the script has to make sense of the file and do the right thing (e.g. it's up to you).

The script goes on to clean up after itself, whether or not the above was successful.  Errors are echo'd by the script and a non-zero exit code is set where appropriate.

Second to last, we have:

# just in case, exit explicitly, so that uuencoded content will not cause error

# The rest of the script is ignored, except by uudecode

# UUencoded content follows
# e.g. for each file needed, 
#  $ uuencode -m {source} {source} > {target}.uu5
# then paste the {target}.uu5 files below
# they will be extracted into the workding dir at $TDIR

The commentary above also describes how to encode the content.

Finally we have the uuencoded content:

begin-base64 444
That last line of "====" is the base64 uuencode equivalent of a blank line, followed by "end" and as mentioned you can have as many begin/end clauses as you need.  Just separate each embedded file by a blank line after each ==== and before each begin-base64.

Deploying the example Operational Profile looks like this (where I have pasted the system serial number into the required field):



The job succeeded, but here is an example of the kind of diagnostic messages that the example script produces, and how Ops Center displays them in the job details:


This same general approach could be used to deploy Explorer, and other useful utilities and scripts.

Please let us know what you think?  Until next time...

Leon Shaner | Senior IT/Product Architect
Systems Management | Ops Center Engineering @ Oracle

The views expressed on this [blog; Web site] are my own and do not necessarily reflect the views of Oracle.

For more information, please go to Oracle Enterprise Manager  web page or  follow us at : 

Twitter | Facebook | YouTube | Linkedin | Newsletter


Latest information on Oracle Enterprise Manager and Oracle Management Cloud.

Related Blogs


« June 2016