Skip navigation.

DBASolved

Syndicate content DBASolved
Helping Oracle DBAs solve problems
Updated: 13 hours 54 min ago

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 12.1.0.2 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 root.sh scripts from either the OUI or from the command line.

[root@rac1 grid]./root.sh
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/rootconfig.sh: 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/rootcrs.pl ' 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 root.sh 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>$wget http://www.cpan.org/src/5.0/perl-5.14.4.tar.gz
<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 
<br>

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/12.1.0.2/grid 
<br>[oracle@rac1 grid] cd perl/bin 
<br>[oracle@rac1 bin]./perl -v 
</p>
<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 http://www.perl.org/, the Perl Home Page.
<br>

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 root.sh scripts will run successfully now from the $ORACLE_HOME directories.

Enjoy!


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/12.1.0.2/dbhome_1/javavm/jdk/jdk6/lib/libjavavm12.a /opt/app/oracle/product/12.1.0.2/dbhome_1/lib/

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

Enjoy!

about.me: http://about.me/dbasolved


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 handlerjavax.net.ssl.SSLException: 
Inbound closed before receiving peer's close_notify: possible truncation attack? 
javax.net.ssl.SSLException: 
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 192.168.65.67 after the upgraded the addressed changed to 192.168.65.7. 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.

Enjoy!

about.me: http://about.me/dbasolved


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
-name="name"
-password="password"
[-type="user_type"]
[-roles="role1;role2;..."]
[-email="email1;email2;..."]
[-privilege="name[;secure-resource-details]]"
[-separator=privilege="sep_string"]
[-subseparator=privilege="subsep_string"]
[-profile="profile_name"]
[-desc="user_description"]
[-expired="true|false"]
[-prevent_change_password="true|false"]
[-department="department_name"]
[-cost_center="cost_center"]
[-line_of_business="line_of_business"]
[-contact="contact"]
[-location="location"]
[-input_file="arg_name:file_path"]

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;

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

#Program
if (not defined $username or not defined $passwd or not defined $email)
{    
    print "\nUsage: perl ./emcli_create_em_user.pl username password email_address\n\n";    
    exit;
}

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.'/'.$cmd);
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 ./emcli_create_em_user.pl <username> <password for user> <email address>

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

Enjoy!

about.me: http://about.me/dbasolved


Filed under: EMCLI, OEM
Categories: DBA Blogs

Adding internal targets to #em12c agents manually

Wed, 2015-05-27 09:23

This post is meant to be more of a note for me to refer to later, but it is also good to share knowledge so here you go.

Note: Hostnames are blacked out for a reason. Commands are the same though.

Recently, I just installed an em agent using the silent install method I blogged about earlier (here). After installing the agent, everything was working fine and the agent could upload to the OMS. As I started to look around, within EM, I noticed that the host was not being monitored. I confirmed this by using “emctl config agent listtargets” in $EM_AGENT_HOME/bin.

In most cases, the agent installation, silent or otherwise, will pick up the host and turn the host from unmanaged host to manage host. Not in this case. So how can the host be discovered now?

In order to re-discover the host target on the machine, I needed to run “emctl config agent addInternalTargets”. This forced the agent to go out and rediscover the host and any potential targets on the host. Once it returns to the command prompt, then I ran “emctl config agent listtargets” again to verify that the host is now discovered.

Enjoy!

about.me: http://about.me/dbasolved


Filed under: OEM
Categories: DBA Blogs