Skip navigation.


Syndicate content DBASolved
Helping Oracle DBAs solve problems
Updated: 2 hours 18 min ago

Discovery and Monitor Oracle Database Appliance (#ODA) using #EM12C

Mon, 2015-09-14 09:40

A few months ago, I heard that Oracle was releasing a plug-in for the Oracle Database Appliance (ODA (Oh Dah). At first I couldn’t find anything on this plug-in, then I was able to find it in the Self-Update for Plug-ins (Extensibility -> Self Update -> Plug-ins).

After finding the plug-in, it needed to be deployed to the Oracle Management Server (OMS). Once deployed, it can be used to monitor the ODA; however, this plug-in is different from plug-ins like the Exadata, where you have a wizard to configure monitoring of the hardware associated with the engineered system. In order to use this plug-in, the two servers in the ODA have to have the EM agents installed on them. Here is a list of articles, by some great guys plus myself, that relate to installing agents in EM12C (if you don’t know how to do that already).

Tim Hall
Gavin Soorma
Gokhan Atil
Javier Ruiz

Once the agents are installed, then the plug-in has to be added to the agent. This is achived by pushing the plug-in from the same screen where the plug-in was deployed to the OMS. Only this time, it is deployed to the newly added agents (Extensibility -> Plug-Ins -> Deploy On -> Management Agent)

Once the plug-in is deployed to the new targets for the ODA servers; then the ODA can be added to OEM.

To add the ODA with the plug-in, it can now be done through the Add Targets Manually process. This step is a wizard that walks through adding the ODA; is done through the Add Targets Using Guided Process.


When starting the discovery, OEM will provide you a Discover Now button which initiates the wizard for discovering the ODA componenets such as ILOM and the servers.

When the wizard starts, it asks for an agent URL. This is the agent installed on the first node of the ODA. Then provide the host root login that is stored in Named Credentials or a new login.

The next step of the wizard, will provide a list of all the discovered targets in the ODA.

On the credential screen, the wizard asks for the root password for both the host and the ILOM. If the passwords are the same across the ODA there is a n option to use the password for both items being granted.

The Tag Cloud step is interesting. You really don’t have to put anything here; however, you can tag the ODA to help identify what is being added. There is a Create Tag button at the bottom if you want to create a tag. (I didn’t create one so I didn’t include a picture in this post).

Finally, the review step shows what is going to be added to OEM as the ODA. Once the targets have been promoted successfully, you will see a green flag in the Discovery Stataus block. At this point the ODA has been added to OEM.

Now that the ODA has been added to OEM, it can be viewed from Targets -> All Targets -> Target Type -> Engineered Systems -> Oracle Database Appliance System. From here, OEM takes you to the home page for the ODA.

From the ODA home page, it provides an overview of all the item going on with the ODA. Click around and have some fun reviewing what is happening with the ODA being monitored.


Filed under: OEM
Categories: DBA Blogs

ZFS Storage monitoring with #EM12C

Thu, 2015-09-10 11:03

How do you monitor an ZFS Storage Appliance with Oracle Enterprise Manager 12c? This is a question that has been asked a few times and I needed to solve this issue. You hear a lot about the em agents and that they need to be used to monitor many different targets. Let’s just say, that is not the case when wanting to monitor a ZFS Storage Appliance.

In order to monitor a ZFS Storage Appliance, there are a few things that have to be setup first. After configuring your ZFS the way you want it, you have to create an oracle_agent user and role within the ZFS.

To create a user on the ZFS, you need to login to the ZFS and then go to Maintenance -> Workflows and click the “Edit” option next to Configure for Oracle Enterprise Manager Monitoring.

The workflow will create a user and role named “oracle_agent” when complete. Click the OK button to allow the workflow to perform the actions needed. (It may take a few minutes to pop-up the status window)


After clicking the OK button, the ZFS will configure a worksheet that is used to monitor the ZFS from OEM. At this point, the ZFS is ready to be monitored from OEM.

In order to set up the ZFS within OEM, it needs to be added manually. This is done by using the Setup -> Add Target -> Add Targets Manually. Once on the Add Targets Manually page, the ZFS needs to be added by using the Add Targets Declaratively by Specifying Target Monitoring Properties. On this page, select the Target Type for the ZFS and the monitoring agents should be the EM Agent for the OMS.

Note: The monitoring agent, can be any agent that you want to monitor the ZFS with. The agent will act as a proxy to the ZFS.

The next screen, within OEM, will ask you for the specific information needed to add the ZFS to be monitored. The target name can be anything you would like to call the ZFS. Username and Password are what you configured when setting up the worksheet (oracle_agent). The management port (215) is the default port. Lastly, the IP address or DNS name of the ZFS to be monitored.

After clicking OK, the ZFS will be added to OEM. To verify this, the ZFS can be found under Targets -> All Targets -> Oracle ZFS Storage Appliance

Finally, the ZFS can be viewed and monitored from within OEM.

Keep in mind that the metrics being collected will update over time. The image above is captured from a newly discovered ZFS and has not had time to populate.


Filed under: OEM
Categories: DBA Blogs

Issue with Perl in $ORACLE_HOME during installs

Mon, 2015-08-24 01:14

I’ve been doing some Enterprise Manager installs a bit more lately. At the same time, I’ve been working on Data Integration items such as GoldenGate and ODI.  What these products have in common are that they require an Oracle Database for a repository.  Needless to say I’ve been installing a lot of databases in test and production environments.  The one thing that has been consistent is the issue I keep seeing with PERL that is packaged with the Grid Infrastructure and/or Database.

Tip: This may not be happening to everyone and I may have a bad set of binaries.  In discussing this with a co-worker, the md5sum sets were the same for my set of binaries as they were for his. So I couldn’t say if this issue was bad binaries or something else.

As I was doing installs of Grid Infrastructure or Database on Oracle Enterprise Linux 6.6, I would get the following issue when trying to run the scripts from either the OUI or from the command line.

[root@rac1 grid]./
Performing root user operation.</p>
<p>The following environment variables are set as:
<br> ORACLE_OWNER=oracle 
<br> ORACLE_HOME=/u01/app/grid/12.1.0/grid 
<br> Copying dbhome to /usr/local/bin...
<br> Copying oraenv to /usr/local/bin...
<br> Copying coraenv to/usr/local/bin&nbsp;...</p>
<p>Entries will be added to the /etc/oratab file as needed by <br>Database Configuration Assistant when a database&nbsp;is&nbsp;created <br>Finished running generic part of root script.<br>Now product-specific root actions will be performed.<br><strong>/u01/app/grid/12.1.0/grid/crs/config/ line 131: 20862 Segmentation fault  (core dumped) $ROOTSCRIPT $ROOTSCRIPT_ARGS</strong><strong>The command '/u01/app/grid/12.1.0/grid/perl/bin/perl -I/u01/app/grid/12.1.0/grid/perl/lib -I/u01/app/grid/12.1.0/grid/crs/install /u01/app/grid/12.1.0/grid/crs/install/ ' execution failed</strong>

You will notice that the execution failed with a “Segmentation fault”. In looking at the command, I noticed that this is running perl from the $ORACLE_HOME/perl/bin directory. When I did a “which perl”, the perl that the operating system is using is coming from /usr/bin/perl. This is not the correct one being used by the script. Also if I did a “perl -v” from the command line it returns that the version of perl is 5.10.

Now that it is established that the operating system installed perl is fine, I took a look at the perl in $ORACLE_HOME/perl/bin. When I navigated to the $ORACLE_HOME/perl/bin directory and executed “perl -v”; I was met with the “Segmentation fault” issue. Knowing that the problem is within the Oracle binaries; how can this be resolved?

To resolve this “Segmentation fault” issue, I had to recompile the perl binaries that Oracle uses in the $ORACLE_HOME path. To do this, I had to download and recompile the perl binaries in the $ORACLE_HOME directories.

<br>$cd ~/Downloads 
<br>$tar -xzf perl-5.14.4.tar.gz 
<br>$cd perl-5.14.4 <br>$./Configure -des -Dprefix=$GI_HOME/perl <br>$make 
<br>$make test 
<br>$make install 

With the binaries recompiled, I was now able to run a “perl -v” from the $ORACLE_HOME and get a successful result set.

<br>[oracle@rac1 ~] cd /u01/app/grid/ 
<br>[oracle@rac1 grid] cd perl/bin 
<br>[oracle@rac1 bin]./perl -v 
<p>This is perl 5, version 14,subversion 4 (v5.14.4) built for x86_64-linux </p>
<p>Copyright 1987-2013,Larry&nbsp;Wall </p><p>Perl may be copied only under the terms of either the Artistic License or the <br>GNU General Public License, which may be found in the Perl 5 source kit.</p><p>Complete documentation for Perl, including FAQ lists, should be found on 
<br>this system using "man perl" or "perldoc perl".  If you have access to the <br>Internet, point&nbsp;your browser at, the Perl Home Page.

This process can be done if the OUI is running and the step that hung can be retried.  If you closed out the OUI, then the scripts will run successfully now from the $ORACLE_HOME directories.


Filed under: Database, General
Categories: DBA Blogs

Error referenced ‘irman ioracle’ during binary installation

Thu, 2015-07-16 19:27

This week I decided to redo a few of my virtual box machines and build a few new ones for testing. Getting the Oracle Linux 6.6 installed was a breeze; however, when I started to install the Oracle Database 12c binaries I was hitting errors during the linking phase. This had me puzzled for a bit to say the least. I kept getting this error:

After driving myself nuts, I decided to look closer to what is going on. The file listed in the error message contained a reference to ‘irman ioracle’. The actual message was:

So how did I get past this issue? The message is referring to a linking issue of the Oracle binaries. The issue is due to the libjavavm12.a file not being placed in the $ORACLE_HOME/lib. In order to fix this, I had to run:

cp /opt/app/oracle/product/ /opt/app/oracle/product/

Once this was ran, the installation completed without error and other configuration assistants within the binaries were able to complet successfully.


Filed under: Database
Categories: DBA Blogs

Possible Truncation Attack? logged in #em12c nodemanager.log file

Mon, 2015-07-06 08:38

Recently I’ve come across issues with restarting Oracle Enterprise Manager and seeing messages in the nodemanager.log. The message that I’m referring to is (followed by a java trace stack):

<Jul 2, 2015 11:46:11 PM> <WARNING> Uncaught exception in server 
Inbound closed before receiving peer's close_notify: possible truncation attack? 
Inbound closed before receiving peer's close_notify: possible truncation attack?

What is interesting about this message is the panic that may come over a person when they see the word “attack”. The first time I saw this message, I was working on a client site and I was distressed because I was worried about an “attack” on EM. After some investigation, this message is a bit misleading. So, what was the cause of the message?

The “possible truncation attack” is due to the IP address of the host where the OMS runs changed. Here in my test environment, I recently upgraded my wireless router which effected my whole network. The router upgrade changed all the addresses on the network. When OEM was initially installed, the host had an address of after the upgraded the addressed changed to Not a big deal; how to fix though?

In the case of my test lab, I needed to change the /etc/hosts files to ensure that the correct IP address was picked up. In the enterprise, what needs to happen is your local DNS needs to be updated along as the /etc/hosts file. OEM upon start up will look at DNS then /etc/hosts when trying to resolve host to IP resolution. The order of preference can be changed in the /etc/resolv.conf as well.


Filed under: OEM
Categories: DBA Blogs

Create #em12c users fast and easy!

Thu, 2015-06-18 11:57

Over the last few months, I’ve been working a project where I’ve started to dive into EM CLI and the value that EM CLI brings to cutting down on doing things like creating Enterprise Manager users. Hence the reason for this post.

Note: If you haven’t looked into EM CLI yet, I encourage you to do so. A good starting point is here. Plus there is a whole book written on the topic by some friends and guru’s of mine, here.

Creating users in Enterprise Manager 12c is pretty simple as it is. Simply go to Setup -> Security -> Administrators. When you get this screen, then click on either the Create or Create Like buttons.

After clicking Create or Create Like, Enterprise Manger takes you to a five (5) step wizard for creating a user. This wizard allows you to provide details about the user, assign roles, assign target privileges, assign resource privileges and then review what you have done.

Depending on how many users you have to create, this wizard is either an great way of creating user or a slow way for creating users. Using EM CLI, users can be created from the command line very quickly and easily and no need to use the GUI wizard either.. :)

The syntax to create a user from the command line is as follows:

emcli create_user

The beautiful part of EM CLI is that is can be used with any scripting language. Since I like to use PERL, I decided to write a simple script that can be used to create a user from the command line using EM CLI.

#!/usr/bin/perl -w
use strict;
use warnings;

my $oem_home_bin = “$OMS_HOME/bin";
my ($username, $passwd, $email) = @ARGV;
my $pwdchange = ‘false';

if (not defined $username or not defined $passwd or not defined $email)
    print "\nUsage: perl ./ username password email_address\n\n";    

system($oem_home_bin.'/emcli login -username=sysman);
system($oem_home_bin.'/emcli sync');
my $cmd = 'emcli create_user -name='.$username.' -password='.$passwd.' -email='.$email.' -prevent_change_password='.$pwdchange;
#print $cmd."\n";
system($oem_home_bin.'/emcli logout');

Now using this bit of code, I’m able to create users very rapidly using EM CLI with a command like this:

perl ./ <username> <password for user> <email address>

Well, I hope this helps other look at and start using EM CLI when managing their EM environments.


Filed under: EMCLI, OEM
Categories: DBA Blogs